[Spring] 필터(Filter) vs 인터셉터(Interceptor)

개발을 하다보면 공통으로 처리해야할 업무가 많다.

공통 업무에서 중복 코드가 많아지거나 프로젝트 단위가 커질수록 서버에 부하를 주며, 소스 관리도 되지 않는다.

따라서, Spring에서 중복 코드를 제거할 수 있는 다음과 같은 기능을 제공한다.

필터(Filter)와 인터셉터(Interceptor)는 웹 어플리케이션에서 요청/응답 처리 전/후에 공통작업을 수행할 때 사용되는 기능

 

 

(Servlet)필터 => Java EE 표준 스펙 Dispatcher Servlet에서 제공 

(Spring)인터셉터 => Spring MVC에서 제공

HTTP 요청 → WAS →  "필터" →  서블릿 →  컨트롤러

HTTP 요청 → WAS →  필터 →  서블릿 →  "인터셉터" → 컨트롤러

---

1. Servlet Filter 

• 디스패처 서블릿 요청이 전달되기 전/후에 작업을 처리하므로 통캣과 같은 웹 컨테이너에 의해 관리되고, 스프링 범위 밖에서 처리됨
• jacax.servlet 에 등록된 Filter 인터페이스를 구현하고 등록하면, 서블릿 컨테이너가필터를 싱글톤 객체로 생성하고 관리함  javax.servlet.Filter의 3가지 메소드
  1. init() - 처음 1회
  2. doFilter()
  3. destroy() - 끝 1회

public interface Filter {
	// init() 메소드 (처음)
    // - 필터 객체를 초기화 하고 서비스에 추가
    // - 웹 컨테이너가 1회 init 메소드 호출하여 필터 객체를 초기화 하면 이후의 요청들은 doFilter를 통해 처리
    public default void init(FilterConfig filterConfig) throws ServletException {}
    
    // doFilter() 메소드
    // - url-pattern에 맞는 모든 HTTP 요청이 디스패처 서블릿으로 전달되기 전에 웹 컨테이너에 의해 실행됨
    // - 파라미터 : FilterChain => chain.doFilter() 전/후에 우리가 필요한 처리 과정을 넣어줌
    public void doFilter(ServletRequest request, ServletResponse response,
            		FilterChain chain) throws IOException, ServletException{
        System.out.println("Filter 실행 전");
        chain.doFilter(request, response); // 다음 필터 or 서블릿 호출
        System.out.println("Filter 실행 후");
    }
	
    // destroy() 메소드 (끝)
    // - 필터 객체를 서비스에서 제거
    // - 웹 컨테이너가 1회 호출되며, 이후는 doFilter에 의해 처리되지 않음
    public default void destroy() {}
}

• 용도
  • 인코딩 설정 (UTF-8)
  • 공통된 인증 처리
  • 모든 요청에 대한 로깅/모니터링
  • CORS 처리
  • 요청 파라미터 가공
  • Spring과 분리되어야하는 기

---

2. Spring Interceptor

• 디스패처 서블릿이 컨트롤러를 호출하기 전/후 요청과 응답을 참조하거나 가공할 수 있는 기능을 Spring Context에서 동작
• org.springframework.web.servlet의 HandlerInterceptor 인터페이스를 구현(3가지 메소드)
  1. preHandle() - 컨트롤러 호출 전
  2. postHandle() - 컨트롤러 호출 후
  3. afterCompletion() - 모든 작업이 완료된 후

public interface HandlerInterceptor {
    // preHandel() 메소드
    // - 컨트롤러가 호출되기 전에 실행. 컨트롤러 이전에 처리해야하는 전처리 작업이나 요청정보를 가공하거나 추가하는 경우에 사용
    // - handler 파라미터는 핸들러 매핑이 찾아준 컨트롤러 빈에 매핑되는 HandlerMethod라는 새로운 타입의 객체로써,
    //   @RequestMapping이 붙은 메소드의 정보를 추상화한 객체
    default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
    	System.out.println("🔹 preHandle: 컨트롤러 실행 전");
        return true; // false면 컨트롤러로 가지 않음
    }
	
    
    // postHandle() 메소드
    // - 컨트롤러가 호출된 후에 실행. 컨트롤러 이후에 처리해야하는 후처리 작업때
    // - ModelAndView 타입의 정보가 제공
    // - 최근에는 Json 형태로 데이터를 제공하는 RestAPI기반의 컨트롤러(@RestController)를 만들면서 자주 사용되지 않는다.
    // - 컨트롤러 하위 계층에서 작업을 진행하다가 중간에 예외가 발생하면 postHandle은 호출되지 않음
    default void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
        @Nullable ModelAndView modelAndView) throws Exception {
        System.out.println("🔸 postHandle: 컨트롤러 실행 후, 뷰 렌더링 전");
    }
	
    // afterCompletion() 메소드
    // - 모든 뷰에서 최종결과를 생성하는 일을 포함해 모든 작업이 완료된 후에 실행
    // - 요청 처리 중에 사용한 리소스를 반환할 때 사용
    // - 컨트롤러 하위 계층에서 작업 진행하다가 중간에 예외 발생하더라도 반드시 호출됨
    default void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler,
        @Nullable Exception ex) throws Exception {
        System.out.println("✅ afterCompletion: 뷰 렌더링 후, 리소스 정리");
        if (ex != null) {
            System.out.println("예외 발생: " + ex.getMessage());
        }
    }
}

 

• 용도
  • 세부적인 로그인 체크 / 권한 인증
  • API 호출 전 검증
  • 공통 데이터 삽입 (예: 메뉴 정보)
  • 성능 측정
  • Controller로 넘겨주는 정보(데이터)의 가

 

---

 

 

 

 

---

(참고 사항) 조금 오래된 책들을 보면 필터(Filter)는 서블릿 기술이라서 Spring의 빈으로 등록할 수 없으며 빈을 주입받을수도 없다는 내용이 나옴. 하지만 실제로 테스트를 해보면 Filter 역시 스프링 빈으로 등록이 가능하고, 빈의 주입도 받을 수 있다.

 

 

DelegatingFilterProxy와 SpringBoot의 등장

스프링 1.2부터 DelegatingFilterProxy가 나오면서 서블릿 필터 역시 스프링에서 관리가 가능해짐.

그리고, 이 DelegatingFilterProxy를 등록하는 과정은 Spring이기 때문에 필요한 것이고, SpringBoot라면 DelegatingFilterProxy조차 필요 없다!