스프링 AOP, 장단점 / 스프링 시큐리티를 사용한다면 admin, 팀장, 직원 등 직급에 따른 권한은 어떻게 구현할 것인가요 / 스프링 시큐리티를 못쓰는 상황이라면 위와 같은 요구조건을 어떻게 구현할 것인가요? / MVC 패턴 / Spring DI / Interceptor 와 Filter 의 차이 / Dispatcher-Servlet
nakgopsae2024. 8. 1. 11:10
스프링 AOP, 장단점
AOP (Aspect-Oriented Programming)**는 관점 지향 프로그래밍의 줄임말로, 소프트웨어 모듈화를 위해 관심사의 분리를 목적으로 합니다. 스프링 AOP는 이러한 AOP 개념을 스프링 프레임워크 내에서 지원하는 기술로, 공통적으로 반복되는 기능(예: 로깅, 트랜잭션 관리 등)을 분리하여 코드의 중복을 줄이고 유지보수성을 높이는 데 사용됩니다.
장점:
관심사의 분리: 비즈니스 로직과 공통 관심사를 분리하여 코드의 가독성과 유지보수성을 높입니다.
중복 코드 감소: 공통 기능을 한 곳에 모아서 관리함으로써 중복된 코드를 줄입니다.
유연성 증가/상위 통제: 공통 기능을 여러 모듈에서 재사용할 수 있어 개발 생산성이 높아집니다.
단점:
복잡성 증가: AOP를 적용하면서 코드의 흐름이 복잡해질 수 있으며, 이는 디버깅을 어렵게 만듭니다.
성능 저하 가능성: 잘못 설계된 AOP는 성능에 악영향을 줄 수 있습니다.
학습 곡선: AOP 개념을 처음 접하는 개발자에게는 이해하기 어려울 수 있습니다.
스프링 시큐리티를 사용한다면 admin, 팀장, 직원 등 직급에 따른 권한은 어떻게 구현할 것인가요
시큐리티는 역할기반접근제어를 지원합니다 RBAC기법이란 시스템 사용자들이 가진 역할(ROLE)에 따라 시스템 리소스에 대한 접근 권한을 제어하는 방법입니다 각 역할에 특정권한을 설정할 수 있습니다
접근 제어: 특정 리소스나 메소드에 대해 어떤 역할이 접근 가능한지를 정의합니다. 예를 들어, 특정 API 엔드포인트나 메소드에 대해 @PreAuthorize 또는 @Secured 어노테이션을 사용하여 역할 기반으로 접근을 제한할 수 있습니다.
@PreAuthorize("hasRole('ROLE_ADMIN')")
public void adminMethod() {
// 이 메소드는 ROLE_ADMIN 역할을 가진 사용자만 접근할 수 있습니다.
}
스프링 시큐리티를 못쓰는 상황이라면 위와 같은 요구조건을 어떻게 구현할 것인가요?
스프링 시큐리티를 사용하지 않고 직급에 따른 권한을 구현하는 방법으로는 애플리케이션 내에서 직급정보를 저장하고 권한을 확인하는 로직을 작성하여 구현할 수 있습니다
예를 들어 직접 서블릿 필터를 구현하여 모든 요청을 가로채고 JWT 토큰을 검증하는 방식으로 사용자 인증을 처리합니다. 로그인 시 발급된 JWT 토큰을 요청 헤더에서 확인하고, 해당 토큰에서 사용자 역할(Role) 정보를 추출하여 특정 자원에 대한 접근을 허용하거나 거부합니다. ROLE_ADMIN이 필요한 요청은 필터에서 토큰의 역할 정보를 확인하여 관리자 권한이 있는지 검증하고, 권한이 없으면 403 Forbidden 응답을 반환하는 방식으로 역할 기반 접근 제어를 구현할 수 있습니다.
MVC 패턴
MVC (Model-View-Controller) 패턴은 사용자 인터페이스 로직을 비즈니스 로직과 분리하여 코드의 구조화와 유지보수성을 향상시키기 위해 사용되는 설계 패턴입니다. //뷰와 모델의 의존성을 최소화하고 이를 컨트롤러를 통해 해결하도록 합니다
Model: 데이터와 비즈니스 로직을 처리하는 부분으로, 데이터베이스와의 상호작용, 데이터 검증 및 처리 등을 담당합니다. model에는 순수한 어플리케이션 데이터만 포함되어 있으며 사용자에게 데이터를 제공하는 로직은 포함되지 않는다
View: 사용자에게 데이터를 표시하는 부분으로, UI와 관련된 로직이 포함됩니다. 모델에서 전달된 데이터를 기반으로 화면을 렌더링합니다. view는 사용자에게서 독립적이고 모델의 데이터를 엑세스 하는 방법은 알고있지만 이 데이터가 무엇을 의미하는지 사용자가 이를 조작하기 위해 무엇을 할 수 있는지는 모릅니다. 사용자 인터페이스를 변경하더라도 model에 영향을 주지 않습니다
Controller: 사용자 입력을 처리하고, 요청에 따라 모델을 업데이트하거나 뷰를 호출하는 역할을 합니다. 즉, Model과 View 사이의 중개자 역할을 합니다.
mvc 패턴 흐름
사용자 요청 (User Request): 사용자가 웹 애플리케이션에 액션(예: 버튼 클릭, 폼 제출)을 수행하면, 이 요청은 컨트롤러로 전달됩니다.
요청 처리 (Request Handling): 컨트롤러는 사용자의 요청을 분석하고, 해당 요청을 처리하기 위해 필요한 비즈니스 로직을 결정합니다. 이를 위해 모델과 상호작용합니다. 예를 들어, 데이터베이스에서 정보를 조회하거나 사용자가 제출한 데이터를 저장할 수 있습니다.
모델 업데이트 (Model Update): 컨트롤러가 모델을 호출하여 데이터베이스에서 필요한 데이터를 가져오거나, 새로운 데이터를 저장하는 등의 작업을 수행합니다.
데이터 준비 (Data Preparation): 모델에서 데이터를 가져온 후, 컨트롤러는 이 데이터를 적절한 형태로 가공하여 뷰에 전달합니다.
뷰 렌더링 (View Rendering): 뷰는 컨트롤러로부터 받은 데이터를 사용하여 사용자에게 보여줄 화면을 렌더링합니다. 여기서 사용자는 최신 데이터를 확인하거나, 피드백을 받을 수 있습니다.
사용자 인터랙션 (User Interaction): 사용자는 화면에서 데이터를 확인하고, 추가적인 요청을 할 수 있습니다. 이러한 요청은 다시 컨트롤러로 전달되어 위 과정이 반복됩니다.
Spring DI
DI (Dependency Injection)**는 객체 간의 의존성을 주입하는 디자인 패턴으로, 스프링 프레임워크의 핵심 개념 중 하나입니다. DI를 통해 객체의 생성과 관리를 컨테이너에 맡기고, 필요한 의존성을 주입받아 사용합니다. 이를 통해 결합도를 낮추고, 코드의 테스트 용이성과 유지보수성을 높일 수 있습니다.
Interceptor 와 Filter 의 차이
Filter: 서블릿 컨테이너 레벨에서 동작하며, 요청 전후의 공통 작업을 처리합니다.
요청, 응답을 수정할 수 있고, 체이닝을 통해 여러 필터를 순차적으로 적용할 수 있습니다.
필터(Filter)는 J2EE 표준 스펙 기능으로 디스패처 서블릿(Dispatcher Servlet)에 요청이 전달되기 전/후에 url 패턴에 맞는 모든 요청에 대해 부가작업을 처리할 수 있는 기능을 제공한다.
디스패처 서블릿은 스프링의 가장 앞단에 존재하는 프론트 컨트롤러이므로, 필터는 스프링 범위 밖에서 처리가 되는 것이다.
스프링 컨테이너가 아닌 톰캣과 같은 웹 컨테이너(서블릿 컨테이너)에 의해 관리가 되는 것이고(스프링 빈으로 등록은 된다), 디스패처 서블릿 전/후에 처리하는 것이다.
적용 대상: 필터는 서블릿 스펙의 일부로, 서블릿 컨테이너 수준에서 작동합니다. 즉, 모든 HTTP 요청과 응답에 대해 작동하며, 주로 웹 애플리케이션 전체의 요청 흐름을 제어하는 데 사용됩니다.
적용 순서: 필터는 디스패처 서블릿 전에 실행됩니다. 이는 애플리케이션에 들어오는 모든 요청이 필터를 먼저 거쳐 간다는 의미입니다.
기능:
요청을 사전 처리하거나 응답을 사후 처리하는 작업을 수행할 수 있습니다.
예를 들어, 필터는 요청에 대한 인증 토큰 검사, CORS 설정, 로깅, 요청 수정(헤더 추가 등) 등을 처리할 수 있습니다.
Interceptor: 스프링의 핸들러 레벨에서 동작하며, 특정 핸들러 실행 전후에 공통 작업을 수행합니다.
주로 컨트롤러 로직 전후의 전처리와 후처리에 사용되며, 요청 본문을 수정하지 않습니다.
인터셉터(Interceptor)는 J2EE 표준 스펙인 필터(Filter)와 달리 Spring이 제공하는 기술로써, 디스패처 서블릿(Dispatcher Servlet)이 컨트롤러를 호출하기 전과 후에 요청과 응답을 참조하거나 가공할 수 있는 기능을 제공한다.
즉, 웹 컨테이너(서블릿 컨테이너)에서 동작하는 필터와 달리 인터셉터는 스프링 컨텍스트에서 동작을 하는 것이다.
적용 대상: 인터셉터는 스프링 프레임워크 내에서 작동하며, 주로 컨트롤러 요청 처리에 관여합니다. 이는 스프링의 핸들러 매핑 과정에서 설정되며, 특정 컨트롤러 메소드나 경로에 대해서만 작동할 수 있습니다.
적용 순서: 인터셉터는 디스패처 서블릿과 컨트롤러 사이에서 동작합니다. 즉, 디스패처 서블릿이 적절한 컨트롤러에 요청을 전달하기 전과 후에 인터셉터가 실행됩니다.
기능:
요청 처리 전후의 추가 작업을 수행할 수 있습니다. 주로 권한 체크, 로깅, 요청 데이터 변환 등의 작업을 수행합니다.
preHandle(), postHandle(), afterCompletion()과 같은 메소드를 통해 요청 처리의 다양한 지점에서 개입할 수 있습니다.
Dispatcher-Servlet
DispatcherServlet은 스프링 MVC의 프론트 컨트롤러로, 모든 요청을 받아서 적절한 핸들러로 라우팅하고, 응답을 처리하는 역할을 합니다.
요청을 수신한 후, 핸들러 매핑을 통해 해당 요청을 처리할 컨트롤러를 찾고, 해당 컨트롤러에서 처리된 결과를 뷰로 전달하여 클라이언트에게 응답합니다.
이는 스프링 MVC의 핵심 구성 요소 중 하나로, 모든 웹 요청의 진입점이 됩니다.
DispatcherServlet은 javax.servlet.http.HttpServlet을 확장하여 구현된 서블릿입니다. 이는 서블릿 컨테이너(예: Tomcat)에서 실행되며, HTTP 요청을 처리하는 서버 측 컴포넌트입니다.
주요 기능:
요청 라우팅: 클라이언트의 HTTP 요청을 받아 적절한 컨트롤러로 전달합니다. 이를 위해 URL 패턴과 요청 메소드에 따라 핸들러 매핑을 수행합니다.
핸들러 매핑: 요청 경로를 분석하여 적절한 컨트롤러 메소드와 매핑합니다.
핸들러 어댑터: 매핑된 컨트롤러가 요청을 처리할 수 있도록 적절한 어댑터를 사용하여 요청을 처리합니다.
뷰 리졸버: 컨트롤러가 반환한 논리적 뷰 이름을 실제 뷰 객체로 변환하여 응답을 생성합니다.
인터셉터: 요청 처리 전후에 추가 작업을 수행할 수 있는 기능을 제공합니다.
DispatcherServlet의 동작 흐름
요청 수신:
클라이언트의 HTTP 요청이 서블릿 컨테이너에 도착하면, DispatcherServlet이 요청을 수신합니다.
요청 처리:
DispatcherServlet은 요청 URL에 따라 핸들러 매핑을 통해 적절한 컨트롤러를 찾습니다.
찾은 컨트롤러와 관련된 핸들러 어댑터를 통해 요청을 처리합니다.
응답 생성:
컨트롤러가 반환한 모델 데이터와 뷰 이름을 사용하여 뷰 리졸버가 실제 뷰를 생성합니다.
최종적으로 클라이언트에게 HTTP 응답을 반환합니다.
// 위랑 같은 말 흐름
1. 클라이언트 요청을 수신한다
2. DispatcherServlet이 요청을 적절한 컨트롤러를 찾고 전달한다
3. 컨트롤러는 모델을 생성하고 뷰이름을 반환한다
4. DispatcherServlet이 은 뷰이름을 기반으로 뷰를 결정한다.
5. 뷰는 생성된 모델을 사용하여 결과를 생성한다
6. DispatcherServlet이 은 클라이언트에게 결과를 전송한다
프론트 컨트롤러:
DispatcherServlet은 프론트 컨트롤러 패턴을 구현합니다. 프론트 컨트롤러 패턴은 모든 클라이언트 요청을 중앙에서 수신하여 요청을 처리할 적절한 핸들러(컨트롤러)로 분배하고, 최종적으로 응답을 생성하는 패턴입니다.
서블릿(Java Servlet)
서블릿은 Java EE (Enterprise Edition) 기술의 핵심 구성 요소로, Java 프로그래밍 언어를 사용하여 웹 서버에서 동작하는 서버 측 컴포넌트를 구현할 수 있도록 해줍니다.
서블릿 정의:
서블릿은 웹 애플리케이션에서 HTTP 요청을 처리하고 HTTP 응답을 생성하는 Java 클래스를 의미합니다. 서블릿은 javax.servlet 패키지에 정의된 인터페이스를 구현하여 생성됩니다.
요청 처리:
서블릿은 클라이언트(주로 웹 브라우저)로부터 오는 HTTP 요청을 처리하고, 적절한 HTTP 응답을 생성합니다. 서블릿의 주요 메소드로는 doGet(), doPost() 등이 있으며, 요청 메소드에 따라 처리 로직을 구현합니다.
서블릿 생명 주기:
서블릿의 생명 주기는 서블릿 컨테이너에 의해 관리됩니다. 주요 생명 주기 메소드로는 init(), service(), destroy()가 있습니다. init() 메소드는 서블릿 초기화 시 호출되며, service() 메소드는 요청이 들어올 때 호출되고, destroy() 메소드는 서블릿 종료 시 호출됩니다.
설정:
서블릿은 일반적으로 web.xml 파일에서 서블릿 매핑을 설정하거나, 어노테이션(@WebServlet)을 사용하여 설정할 수 있습니다.
J2EE (Java 2 Platform, Enterprise Edition)
2EE는 Java 기반의 엔터프라이즈 애플리케이션 개발을 위한 플랫폼입니다.
2EE는 기업 수준의 애플리케이션을 구축하기 위해 Java 플랫폼에서 제공하는 일련의 API와 서비스입니다. 이 플랫폼은 분산 시스템, 웹 애플리케이션, 엔터프라이즈 애플리케이션 등 다양한 기능을 지원합니다.
주요 구성 요소:
서블릿 (Servlet): 웹 애플리케이션에서 서버 측 로직을 구현합니다.
JSP (JavaServer Pages): 동적인 웹 페이지를 생성하는 데 사용됩니다.
EJB (Enterprise JavaBeans): 서버 측 컴포넌트를 구현하여 비즈니스 로직을 처리합니다.
JTA (Java Transaction API): 분산 트랜잭션을 관리합니다.
JPA (Java Persistence API): 데이터베이스와의 상호작용을 단순화하는 ORM(Object-Relational Mapping) 기술을 제공합니다.
JMS (Java Message Service): 메시지 기반의 통신을 지원합니다.
JavaMail: 이메일 송수신 기능을 제공합니다.
서블릿 컨테이너 (Servlet Container)
서블릿 컨테이너는 Java 웹 애플리케이션에서 서블릿을 관리하고 실행하는 서버의 핵심 구성 요소입니다. 대표적인 서블릿 컨테이너로는 Apache Tomcat, Jetty, JBoss EAP 등이 있습니다. 서블릿 컨테이너의 주요 역할과 기능은 다음과 같습니다:
서블릿 관리:
서블릿 컨테이너는 서블릿의 생명 주기를 관리합니다. 서블릿 객체를 생성하고 초기화하며, 요청을 처리하고, 종료 시에는 소멸합니다.
요청 및 응답 처리:
클라이언트(주로 웹 브라우저)로부터 HTTP 요청을 수신하고, 이를 서블릿에 전달합니다. 서블릿이 요청을 처리한 후, 응답을 서블릿 컨테이너를 통해 클라이언트에게 반환합니다.
서블릿 API 구현:
서블릿 API를 구현하여 서블릿의 요청 처리 메소드(doGet(), doPost())를 호출합니다. 서블릿 API는 javax.servlet 패키지에 정의되어 있습니다.
웹 애플리케이션 컨텍스트:
웹 애플리케이션의 환경을 설정하고 관리합니다. 웹 애플리케이션 컨텍스트를 통해 초기화 파라미터, 리소스 접근 등을 처리합니다.
필터와 리스너:
필터와 리스너를 관리하여 요청과 응답을 가로채거나, 웹 애플리케이션의 이벤트를 처리합니다.
