JWT는 세션과 무엇이 다를까? (Stateless 인증의 명과 암)
웹 애플리케이션에서 사용자 인증을 구현할 때 가장 많이 고민하는 주제 중 하나는 **"세션(Session) vs 토큰(Token)"**입니다.
과거에는 서버 메모리에 사용자 정보를 저장하는 세션 방식이 주류였지만, 최근에는 모바일 앱과 MSA(Microservices Architecture)의 확산으로 **JWT(JSON Web Token)**가 표준처럼 자리 잡았습니다.
그렇다면 JWT는 정확히 무엇이며, 왜 이렇게 인기가 많을까요? 그리고 정말로 세션보다 무조건 좋을까요?
1. JWT의 구조 (Anatomy of JWT)
JWT는 .(점)으로 구분된 세 부분으로 이루어져 있습니다.
Header.Payload.Signature
각 부분은 Base64Url로 인코딩되어 있습니다.
- Header: 토큰의 타입(JWT)과 서명 알고리즘(HS256, RS256 등) 정보를 담습니다.
- Payload: 클레임(Claim)이라고 불리는 실제 데이터(사용자 ID, 만료 시간 등)를 담습니다.
- Signature: 헤더와 페이로드가 변조되지 않았음을 검증하는 서명입니다.
주의: Header와 Payload는 암호화된 것이 아니라 단순히 인코딩된 것입니다. 누구나 디코딩하여 내용을 볼 수 있으므로, 비밀번호 같은 민감한 정보는 절대 담아서는 안 됩니다.
2. Stateless(무상태)의 매력
세션 방식은 서버가 사용자 상태(로그인 여부 등)를 메모리나 DB에 저장하고 있어야 합니다. 이를 Stateful하다고 합니다.
반면, JWT는 Stateless합니다.
서버는 클라이언트가 보낸 토큰의 서명만 검증하면 됩니다. 별도의 저장소(Session Store)를 조회할 필요가 없습니다.
이로 인해 얻는 장점은 명확합니다:
- 확장성(Scalability): 서버를 여러 대 늘려도(Scale-out) 세션 동기화 문제를 고민할 필요가 없습니다.
- 유연성: 웹, 모바일, 다른 서버 등 다양한 클라이언트 환경에서 공통적으로 사용할 수 있습니다.
3. JWT의 그림자 (단점)
하지만 모든 기술에는 트레이드오프가 있습니다.
- 토큰 크기: 세션 ID는 짧은 문자열이지만, JWT는 많은 정보를 담을수록 길어집니다. 이는 네트워크 대역폭 낭비로 이어질 수 있습니다.
- 강제 로그아웃 불가: 한 번 발급된 토큰은 만료 시간까지 유효합니다. 사용자가 기기를 분실하거나 계정이 해킹당해도, 서버에서 해당 토큰을 즉시 무효화하기 어렵습니다. (Blacklist를 운영하면 해결되지만, 그러면 다시 Stateful해집니다.)
결론
JWT는 현대적인 웹 아키텍처에 매우 적합한 인증 방식입니다.
하지만 "무조건 JWT가 좋다"는 맹신은 위험합니다.
서비스의 규모, 보안 요구사항, 아키텍처 복잡도를 고려하여 세션과 JWT 중 적절한 방식을 선택하는 것이 중요합니다.
때로는 구관이 명관일 수 있습니다. 단일 서버에 소규모 서비스라면 세션 방식이 훨씬 안전하고 구현하기 쉬울 수 있습니다.
관련 도구 둘러보기
Pockit의 무료 개발자 도구를 사용해 보세요