서블릿 필터와 스프링 인터셉터의 활용법
최근에 진행한 프로젝트에서 공통 관심사(Cross-Cutting Concern), 즉 로그인 인증 처리나 요청 로그 기록과 같이 공통적으로 처리해야 할 기능이 많았다. 이때 서블릿 필터와 스프링 인터셉터를 사용하면서 알게 된 내용을 정리해보았다.
서블릿 필터(Servlet Filter)
서블릿 필터는 서블릿(스프링의 경우 디스패처 서블릿)이 호출되기 전에 요청을 가로채서 공통 로직을 처리할 수 있는 기술이다.
필터의 주요 특징
흐름: HTTP 요청 → WAS → 필터 → 서블릿 → 컨트롤러
URL 패턴 기반으로 특정 경로에만 적용 가능하다.
여러 개의 필터를 체인 형태로 연결하여 순서를 정할 수 있다.
필터의 주요 메서드
init(): 최초에 한번만 호출, 필터 초기화
doFilter(): 매 요청마다 호출되는 메서드, 실질적인 로직 처리
destroy(): 필터가 소멸될 때 호출실제로 프로젝트에서는 요청 로그를 기록하거나 로그인 인증을 확인하는 용도로 많이 활용했다.
스프링 인터셉터(Spring Interceptor)
서블릿 필터가 서블릿 호출 이전에 실행된다면, 스프링 인터셉터는 디스패처 서블릿 이후 컨트롤러 호출 직전에 실행된다.
인터셉터의 주요 특징
흐름: HTTP 요청 → WAS → 필터 → 디스패처 서블릿 → 인터셉터 → 컨트롤러
세부적인 URL 패턴 설정이 가능하고, 매우 정밀하게 제어할 수 있다.
컨트롤러 호출 전, 후 그리고 요청 완료 후로 단계적으로 나누어 로직을 구현할 수 있다.
인터셉터의 주요 메서드
preHandle(): 컨트롤러 호출 전 실행. 인증 로직 등 필수 체크 가능
postHandle(): 컨트롤러가 실행된 후, 뷰가 렌더링되기 전에 실행
afterCompletion(): 뷰 렌더링 후 항상 호출, 예외 발생 시에도 실행됨실무에서는 특히 로그인 체크와 요청에 대한 상세한 로그 기록에 매우 유용했다.
필터와 인터셉터 선택 기준
일반적인 HTTP 요청 처리, 응답 객체 변형이 필요하면 필터가 적합하다.
스프링 MVC 기반에서 컨트롤러 호출 전후의 세밀한 작업이 필요하다면 인터셉터를 사용하는 것이 더 효율적이다.
스프링 MVC 환경에서는 대부분의 경우 인터셉터가 사용하기 더 편리했으며, URL 패턴을 정밀하게 설정할 수 있어 편의성도 더 뛰어났다.
ArgumentResolver 활용
ArgumentResolver를 이용하면 로그인된 회원 정보와 같은 반복적으로 필요한 객체를 매번 세션에서 직접 꺼내는 대신, 자동으로 컨트롤러 메서드에 주입할 수 있어 코드의 중복을 줄이고 더욱 깔끔한 컨트롤러를 유지할 수 있었다.
실제 사용하면서 느낀 점은 특별한 이유가 없는 한 스프링 MVC 환경에서는 인터셉터를 적극적으로 활용하는 것이 좋다는 점이다.
