지난 8편 글에서는 스프링 시큐리티의 핵심 동작 원리와 내부 인증 흐름을 살펴보았습니다. 유저의 아이디와 비밀번호가 맞는지 검증하는 ‘인증’을 마쳤다면, 이제 다음 단계는 “이 사용자가 로그인 상태라는 것을 서버가 어떻게 기억하고 유지할 것인가?”에 대한 아키텍처 선택입니다.
전통적인 웹 애플리케이션에서는 서버의 메모리를 활용하는 세션(Session) 방식을 주로 사용해 왔습니다. 하지만 현대의 대규모 트래픽을 처리하는 마이크로서비스 아키텍처(MSA)나 앱 환경에서는 상태를 저장하지 않는 JWT(JSON Web Token) 방식이 각광받고 있습니다.
이번 글에서는 세션과 JWT의 명확한 동작 원리를 비교하고, 대규모 트래픽 환경에서 각 방식이 가지는 치명적인 장단점과 실무 선택 기준을 정리해 보겠습니다.
1. 전통적인 방식: 세션(Session) 기반 인증의 원리
세션 기반 인증은 서버가 사용자의 로그인 상태를 ‘서버 메모리(또는 DB)’에 직접 저장하고 관리하는 Statefull(상태 유지) 방식입니다.
1-1. 동작 흐름
- 사용자가 로그인을 요청하면 서버는 유저 정보를 검증합니다.
- 인증이 성공하면 서버는 메모리(세션 저장소)에 유저 정보를 저장하고, 이에 매칭되는 고유한 세션 ID(Session ID)를 발급합니다.
- 서버는 HTTP 응답 헤더의 쿠키(Cookie)에 세션 ID를 담아 클라이언트에게 보냅니다.
- 클라이언트는 이후 요청마다 브라우저 쿠키에 세션 ID를 실어 보내고, 서버는 세션 저장소에서 해당 ID를 조회해 신원을 확인합니다.
1-2. 세션 방식의 장점
- 높은 보안성과 통제력: 실제 유저의 중요한 정보는 서버에만 안전하게 보관됩니다. 또한, 특정 사용자의 중복 로그인을 막거나 강제 로그아웃(세션 만료) 처리를 서버가 원할 때 언제든 제어할 수 있습니다.
1-3. 대규모 트래픽에서의 단점 (Scale-out의 한계)
- 서버 메모리 과부하: 동시 접속자가 수만, 수십만 명으로 늘어나면 세션 저장소가 서버의 RAM 메모리를 대량으로 잡아먹어 서버가 다운될 수 있습니다.
- 확장성(Scalability) 문제: 트래픽 분산을 위해 서버를 여러 대(서버 A, 서버 B)로 늘리는 스케일 아웃(Scale-out)을 진행할 때 문제가 생깁니다. 유저가 서버 A에서 로그인해 세션을 생성했는데, 다음 요청이 서버 B로 가버리면 서버 B에는 세션 정보가 없어 로그인이 풀리는 현상이 발생합니다. (이를 해결하기 위해 Redis 같은 별도의 세션 서버를 구축해야 하는 인프라 비용이 듭니다.)
2. 현대적인 방식: JWT(JSON Web Token) 인증의 원리
JWT 인증은 로그인 상태를 서버에 저장하지 않고, 인증 정보를 암호화된 토큰 형태로 클라이언트가 직접 들고 다니게 하는 Stateless(무상태) 방식입니다.
2-1. 동작 흐름
- 사용자가 로그인을 요청하면 서버는 유저 정보를 검증합니다.
- 인증이 성공하면 서버는 유저의 ID, 권한 등이 담긴 JSON 데이터를 생성하고, 서버만 알고 있는 비밀 키(Secret Key)로 디지털 서명(Signature)을 하여 JWT 토큰을 발급합니다.
- 서버는 이 토큰을 클라이언트에게 반환하며, 서버 메모리에는 아무것도 저장하지 않습니다.
- 클라이언트는 이후 요청 시 HTTP 헤더(
Authorization: Bearer <Token>)에 토큰을 실어 보냅니다. - 서버는 토큰의 서명이 내 비밀 키로 만들어진 게 맞는지 복호화 검증(Verification)만 수행한 뒤 바로 서비스를 제공합니다.
2-2. JWT 방식의 장점
- 뛰어난 확장성 (MSA 최적화): 서버는 상태를 저장하지 않으므로 서버가 100대로 늘어나도 동일한 비밀 키만 가지고 있다면 어떤 서버에서든 토큰 검증이 가능합니다. 대규모 트래픽과 클라우드 환경에 매우 유리합니다.
- 모바일 앱과의 호환성: 쿠키와 세션은 웹 브라우저 환경에 종속적이지만, JWT 토큰은 단순한 문자열이기 때문에 안드로이드, iOS 앱 등 플랫폼에 구애받지 않고 어디서나 쉽게 사용할 수 있습니다.
2-3. JWT 방식의 치명적인 단점
- 통제 불가 (강제 로그아웃 불가능): 토큰이 한 번 발급되면 서버는 그 토큰의 생명주기를 강제로 제어할 수 없습니다. 토큰을 탈취당하더라도 유효기간이 만료될 때까지 해커의 접근을 막을 방법이 없습니다.
- 네트워크 트래픽 증가: 토큰 내부에 유저 정보(Payload)를 많이 담을수록 토큰 문자열이 길어집니다. 매 요청마다 무거운 토큰이 네트워크를 타고 오가므로 대역폭 낭비가 발생할 수 있습니다.
3. 실무에서의 취약점 보완 전략: Access / Refresh Token 시스템
JWT의 ‘탈취 시 통제 불가’라는 보안 취약점을 해결하기 위해 실무 백엔드에서는 토큰을 두 종류로 나누어 운영하는 이중 토큰 전략을 사용합니다.
- Access Token (액세스 토큰): 실제 API 요청에 사용되는 토큰으로, 유효기간을 30분~1시간 내외로 극단적으로 짧게 설정하여 탈취당했을 때의 피해를 최소화합니다.
- Refresh Token (리프레시 토큰): 액세스 토큰이 만료되었을 때 새로운 액세스 토큰을 발급받기 위한 인증용 토큰입니다. 유효기간을 1~2주 정도로 길게 설정하며, 안전을 위해 서버의 별도 DB(주로 고속 인메모리 DB인 Redis)에 저장해 두고 검증합니다.
액세스 토큰이 만료되면 클라이언트는 리프레시 토큰을 서버로 보내고, 서버는 Redis에 저장된 값과 대조하여 유효하다면 새로운 액세스 토큰을 발행해 줍니다. 만약 사용자의 계정을 정지시키고 싶다면 Redis에서 해당 리프레시 토큰을 삭제하면 되므로 JWT의 단점인 통제력 부재를 보완할 수 있습니다.
4. 핵심 요약: 세션 vs JWT 명확한 차이점 비교
| 비교 항목 | 세션 (Session) 기반 인증 | JWT (JSON Web Token) 인증 |
| 인증 상태 저장소 | 서버 메모리 또는 외부 세션 DB (Redis 등) | 클라이언트 (로컬 스토리지, 쿠키 등) |
| 서버 상태 성격 | Stateful (서버가 상태를 유지함) | Stateless (서버가 상태를 가지지 않음) |
| 대규모 서버 확장성 | 낮음 (서버 간 세션 동기화 인프라 필요) | 높음 (독립적인 토큰 검증 가능) |
| 강제 로그아웃 제어 | 언제든지 원격 제어 가능 | 기본적으로 불가능 (Refresh Token으로 보완) |
| 모바일 앱 친화도 | 낮음 (쿠키 관리가 번거로움) | 높음 (HTTP 표준 헤더 활용) |
5. 결론: 백엔드 아키텍처 선택의 기준
결과적으로 두 기술 중 절대적인 정답은 없습니다. 내가 구축하고자 하는 서비스의 트래픽 규모와 성격에 따라 선택해야 합니다.
- 동시 접속자 수가 제한적이고 보안이 극도로 중요하며 관리가 단순한 어드민(Admin) 시스템이나 사내 웹 서비스라면 관리가 편하고 안전한 세션 방식이 좋습니다.
- 대규모 사용자 트래픽을 감당해야 하고, 서버의 유연한 확장이 필요하며, 웹과 모바일 앱 서비스를 동시에 제공하는 현대적인 백엔드 시스템을 설계한다면 JWT 토큰(Access + Refresh) 방식을 도입하는 것이 올바른 아키텍처 선택입니다.