[Spring] 필터와 인터셉터, 왜 예외 처리 메커니즘이 서로 다를까?

joyful·2026년 2월 8일

Java/Spring

목록 보기

34/47

김영한 강사님의 스프링 MVC 2편 예외 처리 파트를 학습하다 보면, WAS가 오류 페이지 처리를 위해 내부적으로 재요청을 보낸다는 사실을 배운다. 이때 필터와 인터셉터 각각의 중복 호출 방지법을 실습하게 되는데, 여기서 한 가지 의문이 생겼다.

"필터는 요청의 '성격'을 보고 판단하는데, 인터셉터는 왜 요청의 '경로'를 보고 판단해야 할까?"

강의에서 배운 기술적 사실을 바탕으로, 두 도구가 예외라는 특수한 상황을 필터링하는 '판단의 근거'가 서로 다른지 그 설계 차이를 정리해봤다.

필터는 서블릿 표준 기술이다. 즉, 스프링보다 더 바깥쪽인 서블릿 컨테이너(WAS) 수준에서 동작한다. 그래서 WAS가 제공하는 요청의 성격, 즉 DispatchType 메타데이터를 직접 활용할 수 있다.

동작 원리 및 판단 근거: 요청이 들어올 때 이 요청이 일반적인 고객의 요청(REQUEST)인지, 에러 처리를 위한 서버 내부의 재요청(ERROR)인지 그 성격(Type)을 보고 실행 여부를 결정한다.
학습 포인트(메커니즘): 스프링 부트는 필터 등록 시 기본값을 REQUEST로 설정한다. 따라서 별도 설정을 하지 않으면 ERROR 타입의 요청은 필터 로직 근처에도 가지 못한다.
결론: 필터는 서블릿 컨테이너가 제공하는 시스템 정보를 활용해 본인이 수행되어야 할 상황인지를 판단한다. 로직이 실행되기도 전, 시스템 설정에 의해 입구에서 컷(Cut) 당하는 방식을 취하는 것이다.

인터셉터는 스프링 MVC 내부 기술이다. 필터와 달리 서블릿 컨테이너가 관리하는 DispatchType이라는 메타데이터에 의존하지 않는다.

동작 원리 및 판단 근거: 인터셉터에게는 WAS가 보낸 재요청도 결국 DispatcherServlet을 거쳐가는 하나의 URL 요청일 뿐이다. 인터셉터는 요청의 성격을 파악하기보다 "어디로 가는 요청인가(Path)"에 더 집중한다.
해결 방법(메커니즘): 인터셉터는 이를 필터링할 '시스템적 스위치'가 없다. 그래서 에러 처리를 위한 전용 컨트롤러 경로(예: /error-page/**)를 excludePathPatterns에 직접 등록하여 차단한다.
결론: 인터셉터는 시스템 정보보다 스프링이 관리하는 고도의 경로 매칭 로직을 활용해 호출 여부를 결정한다.

여기서 핵심적인 질문이 남는다. "인터셉터도 DispatchType을 판단 근거로 삼으면 더 편하지 않았을까?"
Baeldung의 아티클과 스프링의 구조를 살펴보며 나름의 이유를 추론해 보았다.

필터의 관심사(Infrastructure/Low-level): 웹 애플리케이션의 최전방에서 모든 요청에 공통 적용되는 인프라(보안, 인코딩)를 처리한다. 따라서 HTTP 요청의 시스템적 상태인 DispatchType을 활용하는 것이 가장 원자적이고 확실한 방법이다.
인터셉터의 관심사(Application Context/High-level): 컨트롤러(Handler)와 밀접하게 맞닿아 비즈니스 흐름을 제어한다. 인터셉터에게 중요한 것은 "이 요청이 어떤 비즈니스 핸들러에게 도달하는가"이다. 따라서 시스템 정보보다는 스프링이 고도화해둔 '경로 패턴'과 '핸들러 정보'에 집중하도록 설계된 것이다.

결국, "서 있는 위치가 다르면 판단의 근거(보이는 정도)도 다르다"는 점이 두 도구의 예외 처리 메커니즘을 가른 근본적인 차이라고 생각한다.

단순히 오류 페이지 재요청 시 필터와 인터셉터가 중복 호출되는 문제를 설정으로 해결하는 데 그치지 않고, 왜 두 도구의 필터링 방식이 다른지 그 기저의 설계 의도를 정리해 보았다.

시스템 메타데이터(DispatchType)를 활용하는 필터와 애플리케이션 문맥(Path)을 활용하는 인터셉터의 차이는, 결국 각 도구가 서 있는 태생적 위치와 그에 따른 책임 영역이 어디인지 보여준다.

이번 정리를 통해 서블릿과 스프링 MVC가 요청을 바라보는 관점 차이를 조금 더 명확하게 구분할 수 있게 되었다.

기쁘게 코딩하고 싶은 백엔드 개발자