Spring Security 6부터 보안 설정 방식이 크게 변경되었다. 기존에 널리 사용되던 WebSecurityConfigurerAdapter 기반 설정 방식은 더 이상 권장되지 않으며, 컴포넌트 기반의 SecurityFilterChain 구성 방식으로 전환되었다.
처음 Spring Security 6을 접하면 설정이 복잡해 보일 수 있지만, 정책에 맞게 필터를 분리하고 도메인별로 관리하면 오히려 구조는 더 명확해진다. 이 글에서는 Spring Security 6 환경에서 제공하는 필터를 도메인 정책에 맞게 다양하게 구성하고, 다중 필터를 적용했을 때 실제로 어떤 필터가 동작하는지 확인하는 방법까지 정리한다.
SpringSecurity6 HttpSecurity 변경점
Spring Security 6 이전에는 WebSecurityConfigurerAdapter를 상속받아 configure(HttpSecurity http) 메서드를 오버라이드하는 방식이 일반적이었다. 하지만 이 방식은 현재 deprecated 되었으며, SecurityFilterChain을 Bean으로 등록하는 방식을 권장하고 있다.
이러한 변화의 핵심은 설정을 상속이 아닌 조합 방식으로 구성하도록 유도한다는 점이다. 보안 설정을 명시적으로 Bean으로 관리할 수 있어 필터의 재사용성과 가독성이 크게 개선된다.
즉, Spring Security 6에서는 “어떤 요청에 어떤 필터 체인을 적용할 것인가”를 보다 명확하게 표현할 수 있게 되었다.
SpringSecurity6 도메인 시나리오
여러 도메인이 존재하는 REST API 서버를 가정해보자. 각 도메인은 공개 엔드포인트와 인증이 필요한 엔드포인트를 함께 가지고 있다.
예를 들어 Apple 도메인과 Banana 도메인이 존재하며, 각각 /get 은 누구나 접근 가능하고, /secret 은 인증된 사용자만 접근 가능하다고 가정한다.
이러한 구조에서 모든 요청을 하나의 필터 체인으로 처리하면 정책 변경 시 유지 보수가 어려워진다. Spring Security 6에서는 도메인별 SecurityFilterChain을 분리해 이 문제를 깔끔하게 해결할 수 있다.
SpringSecurity6 공통 필터 구성
각 도메인에 개별 필터를 적용하기 전에, 공통으로 적용할 보안 정책을 하나의 모듈로 분리하는 것이 좋다. 이를 위해 AbstractHttpConfigurer를 상속받아 공통 설정 클래스를 구성할 수 있다.
CSRF 비활성화, 세션 정책을 STATELESS로 설정, 공통 예외 처리 핸들러 등록과 같은 설정은 모든 도메인에서 반복적으로 사용되기 때문이다.
이러한 공통 설정을 모듈화하면 정책 변경 시 한 곳만 수정해도 전체에 반영할 수 있어 유지 보수성이 크게 향상된다.
SpringSecurity6 SecurityFilterChain 설계
SecurityFilterChain은 HttpSecurity를 기반으로 어떤 요청에 어떤 보안 정책을 적용할지 정의하는 핵심 구성 요소다.
securityMatcher를 사용하면 특정 엔드포인트 패턴에만 필터 체인을 적용할 수 있다. 이를 통해 Apple 도메인 요청과 Banana 도메인 요청을 완전히 분리된 보안 정책으로 처리할 수 있다.
authorizeHttpRequests를 통해 허용할 요청과 인증이 필요한 요청을 명확히 구분하면 정책 의도가 코드에 그대로 드러난다.
SpringSecurity6 필터 순서 중요성
Spring Security에서 필터의 실행 순서는 매우 중요하다. 필터 체인은 순서대로 매칭되며, 먼저 매칭된 필터 체인이 요청을 처리하면 이후 필터는 실행되지 않는다.
예를 들어 가장 앞에 모든 요청을 처리하는 필터가 존재한다면, 그 뒤에 정의된 세부 도메인 필터는 결코 실행되지 않는다.
따라서 도메인 범위가 좁은 필터를 먼저, 범위가 넓은 필터를 나중에 배치하는 것이 핵심 원칙이다.
SpringSecurity6 필터 순서 정의
Spring에서는 @Order 어노테이션을 통해 SecurityFilterChain의 실행 순서를 명시할 수 있다. 숫자가 작을수록 우선순위가 높다.
Apple 도메인 필터를 1번, Banana 도메인 필터를 2번, 마지막으로 모든 요청을 처리하는 기본 필터를 3번으로 설정하면 의도한 대로 필터가 순차적으로 매칭된다.
이 방식은 다중 도메인 API 서버에서 보안 정책을 체계적으로 관리하는 데 매우 효과적이다.
SpringSecurity6 필터 실행 결과 확인
필터가 실제로 어떻게 동작하는지는 로그 설정을 통해 확인할 수 있다. Spring Security 관련 로그를 TRACE 레벨로 설정하면 요청이 어떤 SecurityFilterChain과 매칭되었는지 콘솔에서 상세하게 확인할 수 있다.
이를 통해 예상한 필터가 실행되는지, 혹은 잘못된 필터가 먼저 매칭되고 있는지 빠르게 검증할 수 있다.
SpringSecurity6 다중 필터 정리
Spring Security 6의 필터 구성 방식은 처음에는 다소 복잡해 보일 수 있다. 하지만 도메인별로 필터를 분리하고, 공통 설정을 모듈화하며, 실행 순서를 명확히 관리하면 보안 정책은 오히려 더 명확해진다.
특히 대규모 REST API 서버나 여러 도메인을 동시에 운영하는 서비스라면 다중 SecurityFilterChain 전략은 필수적인 설계 요소가 된다.
Spring Security 6의 새로운 필터 구조를 이해하고 나면, 보안 설정은 더 이상 두려운 영역이 아니라 정교하게 설계할 수 있는 하나의 아키텍처 요소가 된다.