[Spring]Filter와 Interceptor, 공통 업무를 처리하는 비슷하지만 다른

Intro

오늘은 Filter와 Interceptor의 이야기입니다. Spring의 중요한 요소 중 하나입니다. 하지만 업무 특성 때문인지 개인적으로는 자주 접하질 못해 매번 까먹는 부분이기도 합니다.

...생각해보면 접했던 게 손에 꼽을 만큼 보지 못한 거 같네요.

Filter & Interceptor

Filter와 Interceptor를 사용하는 이유에는 중복 코드 문제가 있습니다.

웹 개발을 하다보면 공통 업무(혹은 공통 관심사)에 관련된 것들이 생깁니다. 이를테면 로그인 관련 처리나 권한 확인과 같은 부분이죠. 이런 공통 업무는 다수의 페이지(혹은 요청)에 똑같은 코드가 필요하게 됩니다. 결국 중복 코드가 생기는거죠.

이런 공통 업무들을 처리할 수 있는 기능이 바로 Filter와 Interceptor입니다.

**AOP도 있습니다. 이건 다음 글에서

Filter

Filter, 정확하게는 Servlet Filter는 Servlet 컨테이너와 Servlet 사이를 오가는 요청과 응답에 추가로 부가 작업을 진행할 수 있는 기능입니다. 이러한 과정을 그림으로 표현한다면 아래와 같습니다.

조금 오래된 문서지만 참고용으로 적합한 거 같아서 가져와봤습니다. (Oracle이니까 괜찮아!)

또한 Filter는 J2EE(Java 2 Enterprise Edition)의 표준 스펙 기능입니다.(위에서 참고한 문서의 타이틀도 ‘Oracle9iAS Containers for J2EE Servlet Developer’s Guide’입니다.)

즉, Filter는 Spring만의 기능이 아닌 Web 컨테이너(혹은 Servlet 컨테이너)에서도 동작 가능한 기능이라는 점이죠. 그리고 이 부분이 Interceptor와 Filter를 사용하는데 중요한 구분점이 됩니다.

Filter 구현

Filter를 구현하기 위해서는 javax.servlet의 Filter 인터페이스를 implements 해야 합니다.(org.springframework.boot:spring-boot-starter-web 의존성 추가하시면 있습니다.)

Filter 인터페이스는 아래의 3가지 메서드를 가지고 있습니다.

package javax.servlet;

import java.io.IOException;

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

Filter를 서비스에 추가하기 위해 만들어진 메서드입니다. init 메서드는 web 컨테이너에 의해 정확히 한 번 호출됩니다.

◽doFilter

FilterChain을 통해 요청/응답이 전달될 때마다 컨테이너에서 순차적으로 호출됩니다. 파라미터로 전달된 FilterChain을 사용하여 프로세스 진행 여부를 결정할 수 있습니다.

◽destroy

Filter에 서비스가 중단되고 있음을 나타내기 위한 메서드입니다. web 컨테이너에 의해 호출되고 그 후에는 해당 Filter 인스턴스의 doFilter 메서드가 동작하지 않습니다.

Interceptor

Interceptor는 요청과 응답에 대해서 추가로 부가 작업을 수행합니다. Filter와 같은 기능을 하죠. 하지만 Filter와 달리 Interceptor는 Spring에서 제공하는 기능입니다. Filter의 경우에는 javax.servlet 패키지 아래에 위치하고 있다면, Interceptor는 org.springframework.web.servlet 아래에 위치하고 있죠.

때문에 둘의 실행 위치는 차이가 납니다. 그걸 그림으로 표현하면 아래와 같습니다.

Interceptor 구현

Filter를 구현하기 위해서 Filter 인터페이스를 이용해야 했다면 Interceptor의 경우에는 HandlerInterceptor를 implements 하면 됩니다. HandlerInterceptor는 3개의 메서드를 가지고 있습니다.

package org.springframework.web.servlet;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.springframework.lang.Nullable;
import org.springframework.web.method.HandlerMethod;

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

HandlerMapping이 적절한 핸들러(혹은 컨트롤러) 객체를 결정한 후 그리고 아직 HandlerAdapter가 핸들러를 호출하기 전에 실행됩니다. 때문에 세 번째 파라미터인 Handler에는 HandlerMapping이 결정한 컨트롤러가 매핑된 HandlerMethod가 담겨있습니다.

또한 preHandle의 return type은 Booolean입니다. true가 리턴되는 경우에는 다음 단계로 진행이 되지만, false라면 이후의 작업이 진행되지 않습니다.

◽postHandle

HandlerAdapter가 실제로 핸들러를 호출한 후(혹은 Dispatcher Servlet이 뷰를 랜더링하기 전)에 호출됩니다.

또한 파라미터로 주어지는 ModelAndView를 통해 뷰에 정보를 추가할 수 있습니다.

◽afterCompletion

요청 처리 완료 후, 즉 뷰를 랜더링한 후 실행됩니다.

특이한 점은 핸들러 실행 중에 에러가 발생되어도 afterCompletion은 호출됩니다.(postHandle은 호출되지 않습니다.)

Filter vs Interceptor

Filter와 Interceptor는 결국 요청과 응답에 대해서 추가로 부가 작업을 진행한다라는 측면에서 똑같습니다. 물론 세부적으론 조금 다릅니다.

Filter는 doFilter 하나만 제공되고, Interceptor에서는 진행 단계에 따라 다르게 사용할 수 있게 pre, post, after로 세분화된 것처럼 말이죠.

하지만 Filter와 Interceptor의 차이점을 조금 더 명확하게 느끼려면 둘의 실행 위치를 눈여겨봐야 합니다.

◽Filter

는 web 컨테이너 영역에서 Dispatcher Servlet 앞에서 동작합니다.

예를 들면 보안이나 로그인 관련 공통 업무는 Filter가 Interceptor보다 더 유용합니다. 왜냐하면 인증되지 않은 사용자를 한 단계라도 밖(앞)에서 걸러낼 수 있기 때문입니다.

또한 Filter는 Servlet(Dispatcher Servlet)에 도착하기 전에 동작하기 때문에 Servlet 바꿔치기가 가능합니다.

◽Interceptor

는 Spring 영역에서 Dispatcher Servlet 뒤에서 동작합니다.

앞서 얘기했던 로그인 관련 공통 업무와 비슷하지만 조금 다른 권한 관련 업무는 Filter보단 Interceptor가 더 유용할 수 있습니다. 예를 들면 권한에 따라 화면에 노출되는 항목을 다르게 하기에는 Interceptor의 postHandle이 적합하죠.

또한 각 권한에 따른 에러 처리를 Spring 영역에서 할 수 있기 때문에 관리가 쉬워지는 측면도 있습니다. 권한 관련 업무뿐만 아니라 만약 예외 처리를 전역(공통)으로 하고 싶다면 Interceptor가 유용하겠죠.

Ending

Filter와 Interceptor. 차이점이 있긴 하지만 크진 않습니다. 요구사항에 따라서는 무엇을 써도 무방한 경우도 있을 거라 생각합니다. 하지만 어느 때에는 둘 중 하나가 조금 더 유용할 수 있습니다. 그런 때가 오면 제가 이 글을 작성하며 얻었던 것들이 조금이라도 도움이 되길 바랍니다.

(이 글에서 활용했던 소스 코드는 이곳에서 확인 가능하십니다.)

빈성