세션은 가고 토큰의 시대,
Spring Security & JWT 핵심 정리
안녕하세요, code-resting입니다. 백엔드 개발에서 기능 구현만큼 중요한 것이 바로 '보안'입니다. 특히 마이크로서비스(MSA)와 모바일 앱이 대세가 된 오늘날, 서버에 사용자 상태를 저장하지 않는 Stateless(무상태) 인증은 선택이 아닌 필수입니다. 오늘은 그 중심에 있는 JWT 인증의 흐름을 파헤쳐 보겠습니다.
1. 세션 기반 인증의 한계
전통적인 세션 방식은 서버 메모리에 사용자 정보를 저장합니다. 하지만 서버가 여러 대로 늘어나는 분산 환경에서는 세션 동기화(Session Clustering) 문제가 발생하며, 이는 확장을 방해하는 큰 요소가 됩니다.
- ❌ 확장성 저하: 서버가 늘어날 때마다 세션 데이터를 공유하기 위한 별도의 인프라가 필요함.
- ❌ 메모리 부담: 동시 접속자가 많을수록 서버 RAM 점유율이 급격히 상승함.
2. JWT(JSON Web Token)란 무엇인가?
JWT는 인증에 필요한 정보를 토큰 자체에 담고 있는 **자가 수용적(Self-contained)** 토큰입니다. 서버는 토큰의 유효성만 검증하면 될 뿐, 별도의 저장소를 조회할 필요가 없습니다.
JWT의 3가지 구성 요소:
- Header: 토큰의 타입과 사용된 암호화 알고리즘 (HS256, RS256 등)
- Payload: 유저 ID, 권한, 만료 시간 등 실질적인 데이터 (Claims)
- Signature: 서버만 알고 있는 Secret Key로 생성된 위변조 방지 서명
3. JWT 인증 시나리오 (Access & Refresh)
보안을 위해 유효기간이 짧은 Access Token과, 이를 재발급받기 위한 긴 유효기간의 Refresh Token을 사용하는 것이 2026년의 표준 방식입니다.
- 사용자가 로그인을 요청하면 서버는 두 종류의 토큰을 발급합니다.
- 클라이언트는 요청마다 헤더(Authorization: Bearer ...)에 Access Token을 담아 보냅니다.
- Access Token이 만료되면 클라이언트는 저장해둔 Refresh Token을 보내 새 Access Token을 요청합니다.
- 서버는 Refresh Token이 유효하다면 즉시 새 토큰을 내려줍니다.
4. 주의사항: 토큰은 탈취될 수 있습니다
⚠️ 반드시 기억하세요!
JWT의 Payload는 암호화가 아닌 Base64 인코딩일 뿐입니다. 누구나 디코딩해서 내용을 볼 수 있으므로, 민감한 개인정보(비밀번호, 주민번호 등)는 절대 토큰에 담아서는 안 됩니다.
💡 결론
Spring Security와 JWT의 조합은 현대 백엔드 개발의 정석입니다. 무상태성의 이점을 살리면서도 보안의 끈을 놓지 않는 설계가 중요합니다. 내일은 이를 실제 코드로 구현하는 'JWT 필터와 인증 아키텍처 구현 편'으로 돌아오겠습니다.
'스프링 > SpringSecurity' 카테고리의 다른 글
| [실전] Spring Security + OAuth2 소셜 로그인(구글, 카카오) & JWT 연동 마스터 (0) | 2026.03.18 |
|---|---|
| [실전] Spring Security + JWT 커스텀 필터와 인증 아키텍처 구현 가이드 (0) | 2026.03.17 |
| JWT + SpringSecurity (0) | 2021.03.20 |
| SPRING SECURITY (0) | 2021.02.09 |
댓글