애플리케이션 보안. 개발자라면 누구나 한 번쯤은 이 단어 앞에서 좌절감을 맛본다. 로그인부터 권한 관리, 그리고 각종 해킹 공격 대응까지. 이 모든 것을 혼자서 구현하려면? 골치만 아플 뿐이다. 그래서 우리는 Spring Security를 찾는다.
이름만 들어도 뭔가 든든해 보인다. 맞다. 이 녀석은 단순한 라이브러리가 아니다. Spring 기반 애플리케이션을 지키는 최전방 방어선이자, 가장 냉철한 보디가드다. 인증과 인가라는 두 개의 검을 휘두르며, 당신의 비즈니스 로직이 온갖 악의적 공격으로부터 안전하게 숨 쉴 수 있도록 지켜준다.
왜 또 다른 보안 프레임워크인가? (그리고 왜 지금인가)
“우리는 이미 Shiro를 쓰고 있는데?” 이런 생각이 들 수 있다. 맞다. Shiro도 훌륭하다. 하지만 지금은 Spring Boot의 시대다.
과거 SSM(Spring + SpringMVC + MyBatis) 환경에서는 Shiro가 더 직관적이고 가벼워 인기가 많았다. 하지만 스프링 부트가 등장하면서 판도가 바뀌었다. Spring Security는 스프링 부트의 자동 설정(AutoConfiguration)이라는 마법을 만나, 복잡했던 XML 설정을 애노테이션 한 줄로 대체했다.
더 이상 web.xml에서 필터를 일일이 등록하고, 빈(Bean) 설정 파일을 수십 줄 작성할 필요가 없다. 프로젝트에 의존성만 추가하면, 기본적인 보안 설정은 이미 완료되어 있다. 이런 수준의 원활한 통합성은 스프링 생태계를 벗어나기 어렵게 만드는 강력한 무기다.
핵심은 단 두 가지: 너 누구야? (인증) & 뭘 할 수 있어? (인가)
Spring Security의 모든 기능은 결국 이 두 가지 질문으로 수렴한다.
1. Authentication: ‘신원 확인’
당신이 당신이라고 주장하는 사람이 맞는지 확인하는 과정이다. 이 프레임워크가 지원하는 방식은 정말 다양하다.
- 전통파: 우리에게 가장 익숙한 폼 로그인, HTTP Basic/Digest 인증.
- 현대파: REST API 시대의 필수 요소인 JWT (JSON Web Token).
- 외부 연동파: OAuth2.0 / OIDC를 이용한 구글, 페이스북 소셜 로그인. 더 나아가 LDAP, CAS(싱글 사인온) 등 기업 환경의 표준 프로토콜도 문제없다.
이 모든 인증 방식을 표준화된 인터페이스 안에서 처리해준다는 점이 Spring Security의 진가다.
2. Authorization: ‘권한 부여’
인증을 통과했다면, 이제 그 사람이 이 시스템에서 ‘무엇’을 할 수 있는지 정해야 한다. 단순히 “관리자는 모든 메뉴에 접근 가능” 같은 수준을 넘어선다.
- URL 기반:
/admin/**패턴은ADMIN롤만 접근 가능. - 메서드 기반: 특정 서비스 메서드 호출 전에
@PreAuthorize("hasRole('USER')")같은 애노테이션으로 사전 검증. - 객체 수준: “자신이 작성한 글만 수정할 수 있다”는 식의 ACL(Access Control List)까지 지원한다.
프리즘 너머: 우리가 몰랐던 방어막
인증과 인가만 잘 처리하면 끝일까? 아니다. 현대의 웹 공격은 훨씬 교묘하다. Spring Security는 기본적인 필터 체인만으로도 아래와 같은 공격을 자동 방어해준다.
- CSRF (Cross-Site Request Forgery): 사용자가 의도하지 않은 요청을 강제로 실행시키는 공격. 기본적으로 토큰 기반으로 막아준다.
- 세션 고정(Session Fixation) 공격: 로그인 시 자동으로 세션 ID를 변경해 공격자의 사전 세션 탈취를 차단한다.
- 클릭재킹(Clickjacking):
X-Frame-Options헤더를 기본 설정으로 제공해 프레임 내에서의 사이트 노출을 제한한다. - 비밀번호 암호화:
BCryptPasswordEncoder를 강제하여, 데이터베이스에 저장되는 비밀번호는 절대 평문으로 존재하지 않게 한다.
이 모든 것이 당신이 코드 한 줄 건드리지 않아도 기본 설정으로 동작한다. 이게 바로 스프링 시큐리티의 위엄이다.
아키텍처: 그들은 어떻게 움직이는가
Spring Security의 심장은 필터 체인(Filter Chain)이다. 모든 HTTP 요청은 DispatcherServlet에 도달하기 전에 약 10~15개에 달하는 필터를 순차적으로 통과한다.
| 필터명 (Filter) | 역할 (The Golden Rule) |
|---|---|
| UsernamePasswordAuthenticationFilter | 폼 로그인에서 넘어온 아이디/패스워드를 가로챈다. |
| BasicAuthenticationFilter | HTTP Basic 인증 헤더를 해석한다. |
| CsrfFilter | 요청에 포함된 CSRF 토큰을 검증한다. |
| ExceptionTranslationFilter | 인증/인가 과정에서 발생하는 예외(403, 401)를 잡아 적절한 응답으로 변환한다. |
| FilterSecurityInterceptor | 최후의 보루. 실제 요청을 처리하기 직전에 최종적인 권한을 판별한다. |
각 필터는 자신의 역할에만 집중하고, 성공하면 다음 필터로 요청을 넘긴다. 만약 이 필터 중 하나라도 “이 요청은 위험하다”고 판단하면, 그 즉시 요청은 차단된다. 마치 나이트클럽 입구에서 신분증과 복장, 수갑 검사까지 하는 깐깐한 경비원 같은 셈이다.
당신이 가져야 할 태도: ‘Zero Trust’와 ‘확장’
스프링 시큐리티를 제대로 활용하는 방법은 생각보다 간단하다. “일단 다 막고, 필요한 것만 열어둬라.”
기본 설정은 모든 요청을 차단한다. WebSecurityConfigurerAdapter (또는 최신 버전의 SecurityFilterChain)를 상속받아 특정 경로만 열어주는 방식이 정석이다.
그리고 커스터마이징에 두려워하지 마라. UserDetailsService를 구현해 데이터베이스와 연동하고, PasswordEncoder를 빈으로 등록해 암호화 방식을 바꾸는 것은 이 프레임워크가 제공하는 가장 기본적인 확장 포인트다. REST API를 만든다면, 세션 대신 JWT를 처리하는 필터를 직접 구현해 체인에 끼워 넣으면 된다. Spring Security는 당신이 원하는 방식으로 커스터마이징할 수 있는 자유도를 보장한다.
마치며: 안전은 선택이 아닌 필수다
누군가는 물을지도 모른다. “우리 서비스는 규모가 작아서 굳이?”
아니다. 해킹은 규모를 가리지 않는다. 개인정보 유출로 인한 법적 리스크, 그리고 신뢰도 하락은 한 번의 실수로 돌이킬 수 없는 결과를 낳는다. Spring Security는 그 ‘한 번의 실수’를 방지하기 위해 스프링 생태계가 준 가장 완벽한 해결책이다.
복잡해 보이지만, 일단 프로젝트에 추가하고 기본 설정을 켜보라. 그 순간부터 당신의 애플리케이션은 최소한의 방어막을 갖추게 된다. 그리고 하나씩 설정을 풀어가며 커스터마이징할수록, 당신은 단순한 개발자가 아닌 보안 아키텍트로 성장하고 있음을 느낄 수 있을 것이다.
지금 바로 당신의 프로젝트에 spring-boot-starter-security를 추가해보길 권한다. 그 작은 의존성 하나가 당신의 애플리케이션을 지키는 가장 든든한 동료가 되어줄 테니까.
궁금한 점이 생겼다면?
댓글로 당신이 구상 중인 프로젝트의 인증/인가 전략을 공유해보자. 복잡한 JWT 설정이 고민이라면, 또는 OAuth2 소셜 로그인에 막혔다면. 당신의 고민에 대한 해결책을 함께 찾아보자.
