목적
보통 우리는 JWT 토큰 인증/인가를 Filter 레벨에서 처리했다.
그러던 중 문득 이런 생각이 들었다.
이 API는 관리자만 호출할 수 있는데, 이런 권한 체크까지 Filter에서 다 처리하는 게 맞는 걸까?
Filter는 전역적인 기술 처리를 담당하는 레이어인데,
특정 비즈니스(관리자 권한 여부)와 관련된 로직이 들어가는 게 구조적으로 어색하게 느껴졌다.이 고민을 계기로 Filter / Interceptor 의 책임과 적절한 사용 위치를 다시 정리해보기로 했다.
그리고 각각을 활용해 로깅 구현 실습까지 진행하게 되었다.
목차
- Filter 역할과 책임
- Interceptor 역할과 책임
- 흐름 설계 이유 ( 중요 )
- 구현코드
- 구현 후 이점
구조
정리 : 대충 필터는 서블릿 레벨, 인터셉터는 MVC 레벨
Filter(Docs) Link
간단설명
서블릿 컨테이너 레벨에서 요청(Request)와 응답(Response)을 가로채는 기능을 제공한다.
가장 먼저 실행되며, DispatcherServlet 이전에 동작한다.주로 전역적이고 기술적인 처리를 위해 사용된다.
레벨
Servlet 레벨
- 톰캣과 같은 WAS 단계에서 처리된다.
책임
요청/응답에 대한 전역 처리
인증 필터 로깅 및 감사 필터 이미지 변환 필터 데이터 압축 필터 암호화 필터 토큰화 필터 리소스 액세스 이벤트를 트리거하는 필터 XSL/T 필터 마임형 체인 필터
Interceptor(Docs) Link
간단설명
Spring MVC 레벨에서 요청 흐름을 가로채는 기능을 제공한다.
컨트롤러(Handler)가 호출되기 전/후, 그리고 View가 렌더링되기 전 단계에서 동작한다.주로 비즈니스 로직과 밀접한 전처리/후처리 작업을 처리하는 데 사용된다.
레벨
Spring MVC 레벨 (DispatcherServlet 이후)
- 스프링 DispatcherServlet에서 HandlerMapping을 통해 실행된다.
책임 ( Baeldung )
애플리케이션 로깅과 같은 횡단 관심사 처리 세부적인 권한 검사 Spring 컨텍스트나 모델 조작
왜 권한검사는 Interceptor 에서? ( 흐름설계 이유 )
Q. 서블릿레벨에서 끝나면 더 효율적이지 않은가?
MVC 레벨까지 가지 않고, 서블릿(Filter) 레벨에서 권한 검사까지 하면 더 효율적인 것 아닌가?
애초에 권한 없는 사용자의 요청은 아예 빨리 차단하는 게 성능상 유리할 것 같다고 생각한다.
A. 권한검사는 기술적인가? 비즈니스적인가?
이 사용자가 요청한 기능을 수행할 수 있는가?
라는 질문은 결국 도메인 정책에 따른 판단이다.어떤 사용자는
읽기만 가능하고,
어떤 사용자는수정까지 가능하며,
어떤 사용자는접근조차 막아야하는 경우도 있다.
이러한 정책은 서비스가 제공하는 비즈니스 규칙에 기반한 판단이다.
따라서 자연스럽게 비즈니스 흐름과 맞닿아 있는 Interceptor에서 다루는 것이 더 적절하다.
이 외에도 관심이 있다면, A Deep Dive Into Spring Interceptors: A Comprehensive Guide 글을 참고하길 바란다. ( 우리는 권한만 알아볼 것이다. )
실제 코드로 예시
Before ( 필터레벨에서 권한검사 )
JwtFiler.java
필터 내부에서 실행중인 권한 검사.
After ( 인터셉터로 이동 )
등록방법은 스킵하겠다.
JwtFilter.java
권한 검사를 삭제하고 아래
LoggerInterceptor로 이동한다.
LoggerInterceptor.java
수확
이번 작업을 진행하면서 예상치 못한 수확이 하나 있었다.
기존에는 예외 발생 시 직접 JSON 응답을 만들어서 내려야 한다고 생각했는데,
- ( 서블릿 레벨은 예외를 직접 json 으로 작성해야 된다. )Interceptor 흐름에 맞추니 스프링의 예외 처리를 그대로 활용할 수 있어서,
별도로 JSON 형태를 직접 만들 필요가 없었다.
어떤 이점이 있었는가?
- 비즈니스 로직과 기술 로직의 분리 (관심사 분리)
- Handler(컨트롤러) 정보 기반으로 세밀한 권한 적용 가능
- 일관된 예외 처리
Daily Stack Overflow
Difference between Interceptor and Filter in Spring MVC
저는 Filter와 Interceptor의 목적에 대해 약간 혼란스럽습니다. 제가 문서를 보고 이해한 바로는, Interceptor는 요청들 사이에서 실행되고, 반면 Filter는 컨트롤러가 응답을 렌더링한 후, 뷰가 렌더링되기 전에 실행된다고 이해했습니다. 그렇다면 Interceptor의 postHandle()과 Filter의 doFilter()는 어떤 차이가 있는 건가요? Spring MVC 흐름도 상에서 어떤 경우에 각각을 사용하는 것이 가장 좋은 베스트 프랙티스인가요? 그리고 그 흐름도에서 Filter와 Interceptor는 어디쯤에서 동작하나요?
(본문 내용이 길어 총 정리) Interceptor는 Servlet Filter와 비슷한 개념이지만, 주로 Controller(핸들러) 실행 전/후에 동작한다. 특징은 핸들러 실행 자체를 막을 수도 있고(preHandle), 컨트롤러 실행 후 (postHandle), 뷰 렌더링 전에 후처리도 가능하다. 특히 Interceptor는 Spring MVC 흐름 안에서 동작하기 때문에 → 컨트롤러 메서드(HandlerMethod) 정보나 애너테이션(@AdminOnly 등)에 접근할 수 있다. → 그래서 권한 검사(Authorization)처럼 비즈니스 로직과 밀접한 사전 처리에 매우 적합하다.
