우리가 흔히 쓰는 Filter와 Interceptor 둘다 요청을 가로채서 동작하는 것은 할겠는데 둘의 차이는 뭘까? 한번 알아보자
1. Filter
Filter는 웹 애플리케이션에 오는 모든 요청이 한번은 거쳐가는 관문이라고 생각하면 이해가 쉽다.
보통 사용 목적은 요청을 분석하거나 필요없는 요청을 걸러내고 응답에 공통적으로 필요한 데이터를 추가하는 등 요청과 응답에 전처리 및 후처리를 진행하고 주로 서블릿 컨테이너에 실행이 된다.
주로 사용되는 곳은 인증 정보 확인을 하거나 특정 로그 기록을 남기는 작업에 사용된다.
예시를 들어보면 로그인이 안된 사용자가 특정 api를 요청할 때 우리는 컨트롤러에 접근하기 전에 필터에서 해당 요청을 걸러내 로그인 페이지로 리다이렉트 할 수 있다.
2. Interceptor
그렇담 interceptor는 스프링 애플리케이션 컨트롤러 전후에 필요한 작업을 할 수 있는 중간자 역할을 한다.
즉 Dispatcher Servlet이 컨트롤러를 호출하기 전후에만 요청을 처리할 수 있다. 이는 Filter보다 범위가 작다는 것을 알 수 있다.
주로 아래와 같은 어노테이션으로 사용이 된다.
- preHandle 메서드: 컨트롤러의 메서드가 호출되기 전에 실행
- postHandle 메서드: 컨트롤러의 메서드가 실행된 후, 뷰가 렌더링되기 전에 실행
- afterCompletion 메서드: 뷰가 렌더링된 후 실행
쉽게 말해서 Interceptor는 특정 핸들러 메서드 실행 전후에 공통 기능을 구현하고 사용 목적은 주로 요청 로깅, 인증, 권한 검사, 세션 검사, 성능 모니터링 등을 수행하는데 사용된다.
아니 Filter가 범위가 더 크면 Interceptor안쓰고 Filter만 쓰면 되는거 아니요?
이와 같은 질문을 할 수 있다. 하지만 Interceptor는 좀 더 컨트롤러 요청에 밀접하게 연관이 되어 있는데 아래에서 좀더 살펴보자!
왜 Interceptor가 필요한지
-
Spring MVC와의 밀접한 연계: Interceptor는 Spring MVC에서 제공하는 기능으로, 컨트롤러 요청과 밀접하게 연관되어 있어서 컨트롤러에 전달되는 데이터(예: 모델, 세션)와 쉽게 연계가 가능하다
- 예시: 로그인 사용자의 세션 정보를 기반으로 권한을 체크하거나 요청 시간을 기록할 때 Interceptor가 적합합니다. -
더 세밀한 제어 가능: Interceptor는 컨트롤러 실행 전, 실행 후, 뷰 렌더링 전에 특정 작업을 지정할 수 있어, 컨트롤러의 요청 흐름에 따라 세밀하게 작업을 나누어 실행할 수 있다.
- 예시: 요청 전후에 로깅을 하고, 뷰 렌더링 전에는 부가적인 데이터 검증을 추가하고자 할 때 Interceptor는 편리한 옵션입니다. -
Servlet과 Spring MVC 간의 추상화 차이: Filter는 서블릿 레벨에서 동작하기 때문에 Spring과 별개로 작동하고, 특정 Spring MVC 컨텍스트(예: 컨트롤러 내 작업)와 연결하기 어렵다는 단점이 있다.
그렇담 언제 뭐를 써야되나요...?
언제 Filter를 써야 하는지
-
모든 요청에 대한 전반적 제어 필요: Filter는 Spring과 관계없이 웹 애플리케이션에 들어오는 모든 HTTP 요청에 대해 처리할 수 있기 때문에, 인증, 로깅과 같이 전역적으로 필요한 작업에 적합
-
예시: 모든 API 요청에서 공통적으로 인증 헤더를 확인해야 한다면 Filter가 적합합니다.
다른 프레임워크와 함께 사용해야 할 때: Filter는 Spring MVC 외에도 모든 서블릿 요청에 적용될 수 있어, 특정 프레임워크와 독립적으로 작동해야 할 때 유용하다.
요약하자면
Filter
- 애플리케이션 전반적인 웹 요청에 대한 제어(보안, 인증, 로깅 등 전역 작업)에 적합하고 Spring에 종속적이지 않음.
Interceptor
- Spring MVC에 밀접하게 연결된 작업(권한, 요청 시간 기록 등)에 적합하며, 컨트롤러 전후로 세밀한 제어가 필요할 때 유리함.
