[Spring] Filter, Interceptor, AOP*

💡 Spring 핵심 개념 인터뷰 Q&A

Q. Filter란

• filter는 servlet에 정의된 컴포넌트로 클라이언트의 요청과 응답을 DispatcherServlet전에 가로채어 처리하는 기능

특징

• 전역으로 모든 요청,응답 처리 가능
• Spring과 무관하며 ServeltContainer에서 동작
• 인증, 인코딩, CORS처리, 로그 기록 등에 자주 사용
  
  

동작

• 클라이언트요청 -> Filter -> DispathcerServlet
• 응답 -> Filter -> DispathcerServlet
  
  

예시

• CORS제어방법1 : SpringMVC 전역 CORS 설정하는 방법 (WebMvcConfigurer, Spring 수준 설정)

   @Configuration
   public class WebConfig implements WebMvcConfigurer {
  
       @Override
       public void addCorsMappings(CorsRegistry registry) {
           registry.addMapping("/**") // 모든 경로에 대해
                   .allowedOrigins("https://example.com") // 허용할 Origin
                   .allowedMethods("GET", "POST", "PUT", "DELETE") // 허용할 메서드
                   .allowedHeaders("*")
                   .allowCredentials(true) // 쿠키 포함 여부
                   .maxAge(3600); // preflight 요청 캐시 시간
       }
   }

  
  

---

• CORS제어방법2 : Filter로 CORS 제어(Servlet 수준, 낮은 수준에서 직접 제어 가능)하는 방법

@Component
public class CorsFilter implements Filter {

    @Override
    public void doFilter(ServletRequest request, ServletResponse response,
                         FilterChain chain) throws IOException, ServletException {

        HttpServletResponse res = (HttpServletResponse) response;
        HttpServletRequest req = (HttpServletRequest) request;

        res.setHeader("Access-Control-Allow-Origin", "https://example.com");
        res.setHeader("Access-Control-Allow-Methods", "GET,POST,PUT,DELETE,OPTIONS");
        res.setHeader("Access-Control-Allow-Headers", "*");
        res.setHeader("Access-Control-Allow-Credentials", "true");

        if ("OPTIONS".equalsIgnoreCase(req.getMethod())) {
            res.setStatus(HttpServletResponse.SC_OK);
            return;
        }

        chain.doFilter(request, response);
    }
}

---

Q.interceptor란?

• SpringMVC에서 제공, controller실행 전후에 요청을 가로채어 전처리후처리 로직을 삽입
  
  

특징

• DispatcherServlet 이후, Controller 실행 전/후에 동작
• 비즈니스 관련 처리(권한 검사, 인증, 세션 체크) 에 사용
• 일반적으로 로그인 여부 검사에 사용
  
  

예시

• 로그인 여부 검사
• 로그인 상태가 HttpSession에 저장되어 있다고 가정하고, Interceptor를 이용해 로그인 여부를 확인하고 비로그인 사용자를 차단하는 예시
  
  

1. Interceptor 구현

public class LoginCheckInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request,
                             HttpServletResponse response,
                             Object handler) throws Exception {

        HttpSession session = request.getSession(false);

        if (session == null || session.getAttribute("loginUser") == null) {
            // 로그인 안된 경우
            response.sendRedirect("/login");
            return false; // 요청을 Controller로 보내지 않음
        }

        return true; // 로그인 되어있으면 Controller로 진행
    }
}

---

2. WebMvcConfigurer에 Interceptor 등록

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LoginCheckInterceptor())
                .addPathPatterns("/**") // 전체 경로 검사
                .excludePathPatterns("/", "/login", "/logout", "/css/**", "/js/**", "/images/**"); // 예외 경로
    }
}

인터셉터 동작흐름

클라이언트 요청
    ↓
DispatcherServlet
    ↓
LoginCheckInterceptor (preHandle)
    ↓
Controller
    ↓
LoginCheckInterceptor (postHandle / afterCompletion)

인터셉터 주의할 점

• preHandle()에서 false를 리턴하면 컨트롤러로 요청이 가지 않음
• 로그인된 유저 정보는 보통 session.getAttribute("loginUser") 또는 Spring Security 사용 시 SecurityContextHolder로 확인
• postHandle() → 컨트롤러 실행 후 View 렌더링 전
• afterCompletion() → 응답 완료 직후, 예외 처리용으로도 사용 가능
  
  
  
  

JWT 기반 로그인 검사 Interceptor 예시

• JWT 기반 인증에서는 Interceptor에서 Authorization 헤더에 포함된 토큰을 파싱하고 검증하여,유효하지 않은 경우 요청을 차단하고, 유효한 경우 사용자 정보를 추출하여 컨트롤러에서 사용할 수 있게 합니다.
  
  

1. JWT 검증 로직이 포함된 Interceptor

@Component
public class JwtAuthInterceptor implements HandlerInterceptor {

    private final JwtTokenProvider jwtTokenProvider; //직접구현한JWT 유틸클래스

    // 생성자 주입
    public JwtAuthInterceptor(JwtTokenProvider jwtTokenProvider) {
        this.jwtTokenProvider = jwtTokenProvider;
    }

    @Override
    public boolean preHandle(HttpServletRequest request,
                             HttpServletResponse response,
                             Object handler) throws Exception {

        String authHeader = request.getHeader("Authorization");

        // 토큰 없음
        if (authHeader == null || !authHeader.startsWith("Bearer ")) {
            response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
            return false;
        }

        String token = authHeader.substring(7); // "Bearer " 제거

        // 토큰 검증
        if (!jwtTokenProvider.validateToken(token)) {
            response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
            return false;
        }

        // 사용자 정보 추출 (Optional)
        String userId = jwtTokenProvider.getUserIdFromToken(token);
        request.setAttribute("userId", userId); // 컨트롤러에서 활용 가능

        return true;
    }
}

---

2. WebMvcConfigurer에 인터셉터 등록

@Configuration
public class WebConfig implements WebMvcConfigurer {

    private final JwtAuthInterceptor jwtAuthInterceptor;

    public WebConfig(JwtAuthInterceptor jwtAuthInterceptor) {
        this.jwtAuthInterceptor = jwtAuthInterceptor;
    }

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(jwtAuthInterceptor)
                .addPathPatterns("/api/**")
                .excludePathPatterns("/api/auth/**"); // 로그인, 회원가입은 예외
    }
}

Q. Filter, Interceptor, AOP의 차이

• 위 3가지는 요청-응답 흐름을 가로채는 구조이지만, 적용 계층과 목적이 다릅니다.
• Filter는 서블릿 레벨에서 동작하며, DispatherServlet이전에 요청을 가로채어 인코딩, 인증, 로깅 같은 전역 처리한다
• interceptor는 SpringMVC수준에서 동작하며 컨트롤러 실행 전/후에 세션체크, 권한 검사 등을 수행
• AOP는 메서드 단위에서 동작하며, 트랜잭션 로깅 예외 등 부가기능을 핵심 로직과 분리할 때 사용

요약

• Filter는 서블릿 레벨에서 모든 요청을 가로채고, Interceptor는 Spring MVC 레벨에서 컨트롤러 실행 전/후 처리를 위한 툴

Q. AOP를 쓰는 이유

• AOP는 심 비즈니스 로직과 부가적인 공통 관심사(트랜잭션, 로깅, 인증 등)를 분리하기 위한 기술
• 중복 코드를 줄이고, 핵심 로직에 집중할 수 있어 가독성과 유지보수성이 크게 향상됩니다.

Q.AOP가 동작하지 않는 경우(동작조건)

• Spring AOP는 프록시 기반으로 동작하기 때문에, 아래 조건에서 동작하지 않을 수 있습니다.
• Spring Bean이 아닌 객체에 적용한 경우
• private, final, static 메서드에는 AOP 적용 불가
• 같은 클래스 내부에서 자기 자신의 메서드를 호출하는 경우 (프록시 우회 발생)

Q. Filter와 Interceptor중 선택 기준은

• 전역적으로 HTTP 요청 전체를 제어해야 한다면 → Filter(예: CORS, 인코딩, XSS 필터링 등)
• 컨트롤러 실행 전후의 비즈니스 전처리/후처리가 필요하다면 → Interceptor

  (예: 로그인 체크, 특정 요청 로깅 등)

  
  
  

Q. Interceptor에서 컨트롤러 실행 막을 수 있는지?

• 막을 수 있다.
• Interceptor의 preHandle() 메서드에서 false를 반환하면, DispatcherServlet은 컨트롤러를 호출하지 않고 요청을 즉시 중단합니다.
• false를 반환하면 Spring MVC는 컨트롤러를 호출하지 않고 요청을 중단하므로, 로그인 또는 권한 검증시 효과적

동작순서

1. 클라이언트가 요청을 보냄
2. DispatcherServlet이 요청을 수신
3. 등록된 Interceptor의 preHandle() 메서드 호출
   → 이때 preHandle()에서 false를 반환하면 4번
4. 컨트롤러 호출 없이 요청 종료
   → 이후 View도 렌더링되지 않음
   → 응답 코드(예: 401) 또는 리다이렉트 처리 필요 
   끝

(반대로 preHandle()에서 true를 반환하면 5번)

5. 컨트롤러 실행
6. postHandle(), afterCompletion() 순서대로 실행
	끝