인프런 커뮤니티 질문&답변

저는 그래도 최신버전으로 테스트 하면서 비교를 해가며 학습하는게 좋겠다 싶어 학습중입니다.

현재 springboot 3.5으로 학습중이며 security는 6.3인것 같습니다.

그런데 학습 중 바뀐부분이 있는것 같아 확인 부탁 드리고 자 글을 남깁니다.

아래 내용이 맞는지 알고 싶어요..ㅠㅠ

🍜 비유로 설명: "라면 공장"

🥣 Spring Boot 3.2 (옛 구조)

• **HttpSecurityConfiguration**이 먼저 출근해요

• "물 끓이고, 면 넣고, 스프 넣고" 직접 다 해요

• 마지막에 포장(= SecurityFilterChain)도 본인이 함

즉, 한 사람이 보안 설정 전체를 다 하는 구조

🍱 Spring Boot 3.5 (새 구조)

• **WebSecurityConfiguration**이라는 총괄 매니저가 먼저 출근

• 이 사람이 여러 명의 담당자 (HttpSecurity 설정)에게 일을 시켜요

• 그리고 포장은 SecurityFilterChain으로 조립해서 내보냄

즉, 분업된 구조 — 공장은 커졌고, 매니저가 통제함

🔍 왜 이런 변화가 있었을까?

이유설명설정이 너무 복잡해졌음HttpSecurityConfiguration 혼자 하다 보니 커지고 유지보수가 어려움커스터마이징이 어려웠음사용자 정의 체인 추가가 어렵고 제한적이었음다중 체인 지원 부족API별 다른 보안 적용이 힘들었음 (/api/**, /admin/**)새 구조가 더 유연SecurityFilterChain을 빈으로 만들면 순서, 조건, 분리 모두 명확해짐

🧠 구조 비교 요약

항목Spring Boot 3.2 (Security 6.2)Spring Boot 3.5 (Security 6.3)먼저 실행HttpSecurityConfigurationWebSecurityConfiguration중심 클래스HttpSecurityConfigurationWebSecurityConfiguration책임 방식거의 혼자 다 함분업 (매니저 + 여러 체인)구성 방식내부적으로 HttpSecurity 설정외부에서 SecurityFilterChain 등록유연성다중 체인 어려움다중 체인, 조건부 설정 매우 쉬움

✅ 결론

• Spring Boot 3.2에서는 여전히 옛 구조(약간의 WebSecurityConfigurerAdapter 잔재)를 끌어와서
  → HttpSecurityConfiguration이 보안 설정의 진입점 역할을 했고,

• Spring Boot 3.5에서는 완전 리팩토링된 구조라서
  → WebSecurityConfiguration이 보안 설정의 시작점(매니저)이 되었어요.