[개발 일기] 2025.06.06 - FilterChainProxy

💡 개요

 

 

 

Spring Security 공식 문서를 읽다가 FilterChainProxy라는 것을 보게 되었다.

 

 

FilterChain은 여러 개의 Filter을 체인처럼 묶어서 요청이 타고 넘어가는 것(Filter1 → Filter2 → …)을 의미한다.

 

 

그런데 위 이미지를 보다시피 중간에 끼어있는 FilterChainProxy가 있는게, 이게 뭐지..?

 

 

 

🛠️ FilterChainProxy

 

아래 글은 Spring 공식 문서에 있는 FilterChainProxy에 대한 내용이다.

 

SecurityFilterChain에 포함된 보안 필터들은 보통 Spring Bean으로 등록되지만, 이들은 DelegatingFilterProxy가 아니라 FilterChainProxy에 등록됩니다. FilterChainProxy는 서블릿 컨테이너나 DelegatingFilterProxy에 직접 등록하는 것보다 여러 가지 장점을 제공합니다.

첫째, FilterChainProxy는 Spring Security의 서블릿 지원 기능에 대한 시작점 역할을 합니다. 따라서 Spring Security의 서블릿 지원을 문제 해결할 때는 FilterChainProxy에 디버그 포인트를 추가하는 것이 좋은 출발점이 됩니다.

둘째, FilterChainProxy는 Spring Security에서 핵심적인 역할을 하므로 선택적인 기능이 아닌 필수 작업들을 수행할 수 있습니다. 예를 들어, 메모리 누수를 방지하기 위해 SecurityContext를 정리하고, Spring Security의 HttpFirewall을 적용하여 특정 유형의 공격으로부터 애플리케이션을 보호합니다.

 

 

보다시피 FilterChainProxy는 우리가 아는 필터의 역할을 수행하는 것이 아니라 Bean 객체로 등록된 각 Filter들을 실행 및 관리하는 관리자 같은 느낌인 것 같다.

 

 

그렇기 때문에 만약 Spring Security에 문제가 발생할 경우 FilterChainProxy에 로그와 같은 디버깅을 수행한다면 문제 해결에 좋은 시작이 될 수 있다.

 

 

[클라이언트 요청]
        ↓
[서블릿 컨테이너 (Tomcat 등)]
        ↓
[DelegatingFilterProxy] ← 웹 서버에 등록된 필터
        ↓
[FilterChainProxy] ← 보안 필터 체인을 관리
        ↓
[Spring Security의 각종 보안 필터들] ← 로그인/권한 등 처리
        ↓
[DispatcherServlet] ← 실제 컨트롤러로 전달

 

 

우리가 실제로 수행하는 보안 작업들(예를 들어 인증, 인가, JWT 검증 등)은 모두 FilterChainProxy가 적절한 보안 필터들을 실행하면서 처리된다.

 

 

 

🛠️ DelegatingFilterProxy

 

그런데 여기서 중요한 점은, Tomcat과 같은 서블릿 컨테이너는 Spring을 모르는 것이다.

 

 

하지만 인증이나 인가에 사용되는 대부분의 보안 필터들은 Spring 컨테이너에 Bean으로 등록되어 있다.

 

 

따라서 서블릿 컨테이너에서 들어온 요청을 Spring의 보안 필터들에게 전달해주기 위해, DelegatingFilterProxy라는 프록시 객체가 사용되고, 이 객체는 서블릿 컨테이너와 Spring 사이에서 요청을 연결해주는 대리자 역할을 수행한다.

 

 

 

🤔 참고

 

https://docs.spring.io/spring-security/reference/servlet/architecture.html#servlet-delegatingfilterproxy