안녕하세요, 오늘은 Filter와 Interceptor의 차이에 대해서 자세히 알아보고자 합니다, 최근 포스팅 한 글들 중에서 AOP 기술을 적용해서 ArgumentResolver랑 Interceptor를 만든적이 있는데요, 근데 과거 프로젝트에서 OAuth2.0으로 로그인 하는 과정에서 Filter도 사용한 적이 있는데, 그때는 구현이 시급한 상황이었는지라 제대로 차이를 인지하고 만들지는 않아서.. 이번 기회에 제대로 알아보고자 합니다 ~ !

기존에 알고 있던 차이점

일단 Filter와 Interceptor가 차이점이 있는 기능이라는 사실은 알고 있었습니다, 하지만 두 기능의 차이점을 아주 간략하게 알고 있다는 점이 문제인데요, 지금부터 저가 어느정도 까지 알고 있는지 확인하는 시간을 가져보겠습니다.

• 두 기능은 동일하게 요청과 응답 사이에 동작한다
• Spring Context 내부에서 동작하는지, 외부에서 동작하는지 차이이다
• 즉 사용되는 영역이 다르다.

근데 사용되는 영역이 굳이 왜 다른걸까?
 -> 그거에 대해서 지금부터 알아보자.

Filter란?

개념

필터는 Servlet API에서 제공하는 컴포넌트로, Servlet Container 내부에서 동작하며 요청의 전처리 및 후처리 작업을 수행합니다, 즉 DispatcherServlet에 요청이 전달되기 전후에 URI 패턴에 맞는 모든 요청에 대한 추가작업을 처리할 수 있는 기능을 제공합니다.

• HTTP 요청과 응답을 변경할 수 있는 코드
• 재사용성을 높여준다
• 객체의 형태로 존재한다
• 보안, 로깅 등의 공통 작업에 사용됩니다.

즉 DispatcherServlet은 Spring Context에서 가장 처음으로 존재하는 프론트 컨트롤러인데, Filter는 이러한 DispatcherServlet 전후에 동작하기에 Spring Context 외부에서 동작한다, 이때 Filter는 Servelt Container 내부에서 관리되며 자세한 과정은 아래 그림을 참고하시면 됩니다.

• 그리고 더 자세한 과정은 아래와 같습니다.

메서드

• init()
  : Filter 객체가 최초로 생성될 때 호출됩니다, 이 메서드를 통해 필터 초기화 작업을 수행하며 주로 필요한 자원을 로드하거나 설정을 초기화하는 용도로 사용됩니다.

  public void init(FilterConfig filterConfig) throws ServletException {
         System.out.println("CustomFilter initialized");
  }

• doFilter()
  : 이 메서드가 실제 필터링 작업을 수행합니다, 모든 HTTP 요청이 이 메서드를 거치게 되며, 요청 전처리나 후처리 작업을 여기서 수행하게 됩니다.

  public void doFilter(
     ServletRequest request, 
     ServletResponse response, 
     FilterChain chain
  ) throws IOException, ServletException {
         // 요청 전처리 작업 수행
         System.out.println("Before doFilter() in Filter");
  
         // 다음 필터로 요청 전달
         chain.doFilter(request, response);
  
         // 응답 후처리 작업 수행
         System.out.println("After doFilter() in Filter");
  }
  

• destroy()
  : Filter 객체가 소멸되기 직전에 호출됩니다, 이 메서드를 사용하여 필터에서 사용한 자원을 정리하거나 해체할 수 있습니다.

  public void destroy() {
         // 필터 해제 작업 수행
         System.out.println("CustomFilter destroyed");
  }

Interceptor란?

개념

인터셉터는 Spring MVC에서 제공하는 컴포넌트로, DispatcherServlet이 Controller로 요청을 전달 및 응답을 호출할 때 사용됩니다. 즉 DispatcherServlet이 HandlerMapping을 통하여 적절한 컨트롤러를 찾도록 요청하는데 그 과정에서 Interceptor가 등록되어 있다면 순차적으로 Interceptor를 거쳐 컨트롤러가 실행되도록 합니다.

• HTTP 요청과 응답을 변경할 수 있는 코드
• 재사용성을 높여준다
• 객체의 형태로 존재한다
• 인증(로그인 체크), 권한 검사, 로깅 등의 공통 작업에 사용됩니다.

즉 인터셉터는 스프링 컨테이너 내에서 동작하며 요청 -> Filter -> DispatcherServlet -> HandlerMapping -> Interceptor(PreHandle) -> HandlerAdapter -> Controller -> Service -> Repository -> Interceptor(postHandle) -> 응답 순으로 동작하게 됩니다, 아래 그림을 통해 동작을 더 이해하실 수 있습니다.

메서드

• preHandle()
  : 핸들러가 실행되기 전에 호출됩니다. 요청에 대한 전처리 작업을 수행하고, 핸들러 실행 여부를 결정하는데 사용됩니다. 예를 들어, 인증이나 권한 검사를 수행하여 요청을 허용 또는 거부할 수 있습니다.

  public boolean preHandle(
      HttpServletRequest request, 
      HttpServletResponse response,
      Object handler
  ) throws Exception {
         // 핸들러 실행 전에 실행될 작업 수행
         System.out.println("Before preHandle() in Interceptor");
         return true; // 핸들러 실행 허용
  }

• postHandle()
  : 핸들러 실행 후, View가 렌더링되기 전에 호출됩니다. 주로 모델 데이터를 변경하거나 View를 변형하는 용도로 활용됩니다.

   public void postHandle(
       HttpServletRequest request, 
       HttpServletResponse response, 
       Object handler, ModelAndView modelAndView
   ) throws Exception {
         // 핸들러 실행 후, View가 렌더링되기 전에 실행될 작업 수행
         System.out.println("After postHandle() in Interceptor");
  }

• afterCompletion()
  : View가 렌더링된 후에 호출됩니다. 요청의 처리가 완료된 후에 추가적인 작업을 수행하는데 사용됩니다. 주로 리소스를 해제하거나 로깅 작업을 수행하는 용도로 활용됩니다.

  public void afterCompletion(
        HttpServletRequest request, 
        HttpServletResponse response, 
        Object handler, Exception ex
  ) throws Exception {
         // 핸들러 실행 후, View가 렌더링된 후에 실행될 작업 수행
         System.out.println("After afterCompletion() in Interceptor");
  }

차이점

굳이 왜 나눠서 사용하는걸까?

우선 Filter와 Interceptor를 나누는 이유는 각자의 역할과 책임을 명확하게 구분하고, 다양한 요구 사항을 효과적으로 처리하기 위함인데요, 구체적인 이유로는 아래 내용을 확인하시면 됩니다.

• 적용 시점
  • Filter
    : Servlet API의 일부로, 서블릿 컨테이너 수준에서 요청을 처리합니다. HTTP 요청이 DispatcherServlet에 도달하기 전에 전처리 작업을 수행하며, 응답이 클라이언트에 전달되기 전에 후처리 작업을 수행합니다.
  • Interceptor
    : Spring MVC의 일부로, DispatcherServlet이 요청을 처리하는 과정에서 동작합니다. 주로 Controller의 실행 전후에 작업을 수행합니다.
• 적용 범위
  • Filter
    : URL 패턴에 기반하여 모든 요청에 대해 전역적으로 적용됩니다. 예를 들어, 모든 요청에 대해 인증, 인코딩 설정, 로깅 등을 수행할 수 있습니다.
  • Interceptor
    : 특정 컨트롤러나 핸들러에 대해 보다 세밀하게 적용할 수 있습니다. 주로 비즈니스 로직 전후에 추가적인 처리를 필요로 하는 경우 사용됩니다.
• 사용 목적
  • Filter
    : 보안, 로깅, 공통 헤더 추가, 인코딩 설정 등 전역적인 작업을 처리하기 위해 사용됩니다.
  • Interceptor
    : 인증 및 권한 검사, 특정 비즈니스 로직 전후 처리, 뷰 모델 데이터 추가 등 컨트롤러의 세부 작업을 처리하기 위해 사용됩니다.

그리고 아래 그림을 통하여 더 이해하실 수 있습니다.

오늘은 이렇게 Filter와 Interceptor의 차이에 대해서 알아보았는데요, 정리하자면 Filter는 매우 큰, 전역적인 작업을 처리하는데 사용되며, Filter에서 모든 검증을 할 수 없기 때문에 Interceptor를 통하여 추가로 필요한 부가작업을 이어서 해줌으로써 재사용성과 유지보수성을 높여준다고 보실 수 있습니다.

따라서, Filter와 Interceptor를 함께 사용하면 각기 다른 수준에서 요청을 처리하여 애플리케이션의 요청 처리 과정을 효과적으로 관리할 수 있습니다.

오늘의 문제

• 💡 Filter와 Interceptor의 동작 위치는 어디에서 차이가 나는가요?
  : 📙 Filter는 서블릿 컨테이너 수준에서 동작하여 DispatcherServlet에 요청이 도달하기 전후에 처리합니다. 반면에 Interceptor는 Spring MVC의 일부로 DispatcherServlet이 요청을 처리하는 과정에서 Controller의 실행 전후에 동작합니다.

• 💡 Filter와 Interceptor의 주요 사용 목적을 각각 설명하세요.
  • Filter
    : 보안, 로깅, 공통 헤더 추가, 인코딩 설정 등 전역적인 작업을 처리하는 데 사용됩니다.
  • Interceptor
    : 인증 및 권한 검사, 특정 비즈니스 로직 전후 처리, 뷰 모델 데이터 추가 등 컨트롤러의 세부 작업을 처리하는 데 사용됩니다.
• 💡 Filter의 주요 메서드와 그 역할을 설명하세요.
  • init()
    : Filter 객체가 생성될 때 호출되며, 초기화 작업을 수행합니다.
  • doFilter()
    : 실제 필터링 작업을 수행하며, 모든 HTTP 요청이 이 메서드를 거칩니다. 요청 전처리 및 후처리 작업을 수행합니다.
  • destroy()
    : Filter 객체가 소멸되기 직전에 호출되며, 자원 정리 작업을 수행합니다.
• 💡 Interceptor의 주요 메서드와 그 역할을 설명하세요.
  • preHandle()
    : 핸들러가 실행되기 전에 호출되며, 요청에 대한 전처리 작업을 수행하고, 핸들러 실행 여부를 결정합니다.
  • postHandle()
    : 핸들러 실행 후, View가 렌더링되기 전에 호출되며, 모델 데이터를 변경하거나 View를 변형하는 작업을 수행합니다.
  • afterCompletion()
    : View가 렌더링된 후에 호출되며, 요청 처리가 완료된 후 추가적인 작업을 수행합니다.
• 💡 Filter와 Interceptor를 함께 사용하면 어떤 이점이 있나요?
  : Filter는 전역적인 작업을 처리하고, Interceptor는 세부적인 비즈니스 로직 전후의 작업을 처리하여, 애플리케이션의 요청 처리 과정을 효과적으로 관리할 수 있습니다. 이로써 재사용성과 유지보수성이 높아집니다.

감사합니다.

참고
https://mangkyu.tistory.com/173
https://docs.spring.io/spring-security/site/docs/5.3.2.RELEASE/reference/html5/#servlet-architecture