[Spring] 필터(Filter)와 인터셉터(Interceptor) 차이

Spring은 공통된 로직을 처리하여 컨트롤러에서 중복된 코드를 제거할 수 있도록 여러 기능을 제공하고 있습니다.

오늘은 그 중 필터(Filter)와 인터셉터(Interceptor)에 대해 알아보고 비교해보고자 합니다.

 

틀린 부분이 있다면 댓글로 알려주세요 :)

---

HTTP 요청이 들어오는 흐름 - 디스패처 서블릿을 중심으로

본격적으로 필터와 인터셉터의 개념을 알기 전에

클라이언트로부터 서버로 요청이 들어올 때 어떻게 컨트롤러까지 닿는지 이해할 필요가 있습니다.

필터와 인터셉터를 검색하면 디스패처 서블릿(Dispatcher Servlet)이라는 용어가 많이 언급되거든요.

 

이 글에서는 필터와 인터셉터를 이해하기 위한 최소한만 간략히 돌아보겠습니다.

 

클라이언트에서 요청을 보내면 이는 서버로 들어옵니다.

여기서 서버가 톰캣(Tomcat)이라고 하는 서블릿 컨테이너입니다.

 

• 서블릿 컨테이너란(Servlet Container)?
  • HTTP 요청을 처리할 수 있도록 하는 웹 서버
• 서블릿이란(Servlet)?
  • HTTP 요청/응답을 처리하는 자바 객체

서블릿 컨테이너는 실행 환경을 나타내는 서블릿 컨텍스트(Servlet Context)를 생성하고,

그 안에 여러 서블릿을 등록해 둡니다.

 

우리가 흔히 사용하는 컨트롤러를 포함하는 MVC 패턴에서는 디스패처 서블릿(Dispatcher Servlet)이

모든 요청을 받아 처리합니다. 이로 인해 프론트 컨트롤러 역할을 한다고도 합니다.

 

디스패처 서블릿은 요청을 직접 처리하지 않고,

스프링이 관리하는 빈이 등록된 컨테이너(=스프링 컨텍스트)에서

들어온 요청을 처리할 수 있는 적절한 컨트롤러 빈을 찾아 요청을 처리하도록 위임합니다.

 

이 요청들을 처리하는 스프링 컨텍스트 안에는 컨트롤러와 서비스, 레포지토리 빈 등이 담겨 있습니다.

---

필터(Filter)

필터는 요청과 응답을 가로채 전처리/후처리 로직을 추가할 수 있습니다.

다음 단계로 넘어가기 전에 부가 작업을 처리할 수 있죠.

 

필터는 스프링이 아니라 자바 서블릿에서 제공하는 기능으로

디스패처 서블릿에 요청이 전달되기 전후 url 패턴별 모든 요청에 대해 부가 작업을 처리할 수 있는 기능을 제공합니다.

요청에 대해 작업을 한다고 하니 헷갈릴 수 있지만, 디스패처 서블릿이 실행되기 이전 단계에서 요청/응답을 가로채 작업한다고 보면 됩니다.

 

즉, 스프링에서 코드를 작성하여 스프링 빈으로 등록해도

스프링 컨테이너가 아닌 서블릿 컨테이너에 의해 관리되는 영역입니다.

 

예시로 공통 로깅 또는 Spring Security 필터 설정이 있습니다.

Spring Security 설정에서 `/login` 요청을 가로채 컨트롤러까지 가지 않고도 유저를 인증하는 필터를 구현할 수 있죠.

아니면 인증이 필요한 url에 대해 인증된 유저인지 확인하는 필터도 포함됩니다.

 

필터를 사용하기 위해서는 `javax.servlet`의 Fitler 인터페이스를 구현해야 하며,

다음과 같은 핵심 메서드가 있습니다.

public interface Filter {
	public default void init(FilterConfig filterConfig) throws ServletException {}
    
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException;
    
    public default void destroy() {}
}

• `init()`
  • 필터 객체를 초기화하고, 서비스에 추가하기 위한 메서드
  • 이 메서드를 1회 실행하여 필터 객체를 초기화하면 이후 요청들은 `doFilter()`를 통해 처리됩니다.
• `doFilter()`
  • url 패턴에 맞는 모든 HTTP 요청이 디스패처 서블릿으로 전달되기 전에 실행되는 메서드
  • FilterChain을 통해 다음 단계로 요청이 전달됩니다.
• `destroy()`
  • 필터 객체를 제거하고 사용하는 자원을 반환하는 메서드

---

인터셉터(Interceptor)

인터셉터 역시 필터처럼

요청/응답을 가로채 추가 로직을 수행합니다.

필터와 달리, 스프링이 제공하는 기술이며 스프링 컨텍스트에서 동작합니다.

 

다만 디스패처 서블릿이 컨트롤러로 요청을 넘기기 전 또는 컨트롤러가 디스패처 서블릿으로 응답을 넘기기 전과 같이

디스패처 서블릿과 컨트롤러 사이에서 동작합니다.

 

 

 

인터셉터는 `org.springframework.web.servlet`의 `HandlerInterceptor` 인터페이스를 구현해 추가할 수 있습니다.

주요 메서드는 3가지가 있습니다.

 

public interface HandlerInterceptor {

    default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
        throws Exception {
        
        return true;
    }

    default void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
        @Nullable ModelAndView modelAndView) throws Exception {
    }

    default void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler,
        @Nullable Exception ex) throws Exception {
    }
}

 

• `preHandle()`
  • 컨트롤러가 호출되기 전에 실행되는 메서드
  • 컨트롤러 이전에 처리해야 하는 전처리 로직을 작성
• `postHandle()`
  • 컨트롤러를 호출한 후에 실행되는 메서드(뷰 렌더링 전)
  • 컨트롤러 이후에 처리해야 하는 후처리 로직을 작성
• `afterCompletion()`
  • 모든 뷰에서 최종 결과를 생성하는 일을 포함해 모든 작업이 완료된 후 실행되는 메서드(뷰 렌더링 후)

 

---

요약

구분	필터(Filter)	인터셉터(Interceptor)
관리 주체	서블릿 컨테이너	스프링 컨테이너
실행 시점(단계)	클라이언트와 디스패처 서블릿 사이	디스패처 서블릿과 컨트롤러 사이
스프링의 예외 처리 여부	X (스프링 예외 처리가 적용 안 됨)	O (스프링의 `@ExceptionHandler`, `ControllerAdvice`가 적용됨)
Request/Response 객체 조작 가능 여부	O	X
용도	- 요청 단위 보안/인증/인가 작업 (토큰 유효성 등 이 요청이 서버로 들어와도 되는지 1차적으로 거름) - 모든 요청에 대한 로깅(컨트롤러 호출 여부와 관계없이 동작) - Spring과 분리되어야 할 기능	- 세부적인 보안/인증/인가 작업 (특정 API별 Role 확인) - API 호출에 대한 로깅 - 컨트롤러로 넘겨주는 데이터의 가공

---

참고자료

[Spring] 필터(Filter)와 인터셉터(Interceptor)의 개념 및 차이
[Spring] 필터(Filter) vs 인터셉터(Interceptor) 차이 및 용도 - (1)
[Spring] Dispatcher-Servlet(디스패처 서블릿)이란? 디스패처 서블릿의 개념과 동작 과정
+ 같이 읽으면 좋은 글: Spring BOOT의 @RestController: HTTP 요청에 대한 응답 처리 과정