쿠키 세션 토큰(JWT) 차이 — 면접에서 명확히 설명하기
쿠키 세션 토큰(JWT) 차이, 면접에서 자주 헷갈리는 인증 질문
쿠키, 세션, 토큰(JWT) 차이는 웹 인증 CS 면접에서 매우 자주 나오는 단골 질문입니다. 셋은 서로 대체 관계가 아니라 역할이 다릅니다. 쿠키는 데이터를 저장하는 '수단', 세션은 서버가 상태를 관리하는 '방식', 토큰(JWT)은 인증 정보를 담은 '문자열'입니다. 흔한 비교는 '세션 기반 인증 vs 토큰(JWT) 기반 인증'이고, 쿠키는 둘 다에서 저장 수단으로 쓰일 수 있습니다.
먼저 개념부터 정리
| 구분 | 정의 | 저장 위치 |
|---|---|---|
| 쿠키(Cookie) | 브라우저에 저장되는 key-value 데이터. 요청마다 자동 전송 | 클라이언트(브라우저) |
| 세션(Session) | 서버가 로그인 상태를 저장하고 세션 ID로 식별 | 서버(클라이언트엔 세션 ID만) |
| 토큰/JWT | 인증 정보를 자체적으로 담은 서명된 문자열 | 클라이언트(쿠키 또는 스토리지) |
세션 기반 인증 vs 토큰(JWT) 기반 인증
세션 방식 (Stateful)
로그인 성공 시 서버가 세션을 생성해 메모리나 DB에 저장하고, 클라이언트에는 세션 ID만 쿠키로 내려줍니다. 이후 요청마다 쿠키의 세션 ID로 서버가 사용자를 식별합니다. 상태를 서버가 갖고 있어(Stateful) 서버가 여러 대면 세션 공유(스티키 세션, 중앙 세션 저장소)가 필요합니다.
토큰(JWT) 방식 (Stateless)
로그인 성공 시 서버가 JWT를 발급합니다. JWT 안에 사용자 정보가 들어 있고 서버 서명이 붙어 있어, 서버는 별도 저장 없이 토큰의 서명만 검증해 인증합니다. 서버가 상태를 안 가져(Stateless) 수평 확장에 유리합니다.
JWT의 구조
xxxxx.yyyyy.zzzzz (점으로 구분된 3부분, Base64URL 인코딩)
Header : 토큰 타입(JWT)과 서명 알고리즘(예: HS256)
Payload : 클레임(sub, exp, 사용자 id 등 실제 데이터)
Signature: Header+Payload를 비밀키로 서명한 값 (위변조 검증용)주의: Payload는 암호화가 아니라 Base64로 '인코딩'만 된 것이라 누구나 디코딩해 내용을 볼 수 있습니다. 따라서 비밀번호 같은 민감 정보를 넣으면 안 됩니다. 서명(Signature)은 '내용이 변조되지 않았음'을 보장할 뿐 '내용을 감추는' 게 아닙니다.
세션 vs JWT 비교
| 구분 | 세션 | JWT(토큰) |
|---|---|---|
| 상태 | Stateful(서버 저장) | Stateless(서버 미저장) |
| 확장성 | 세션 공유 필요 | 수평 확장 용이 |
| 무효화(로그아웃) | 즉시 삭제 가능 | 만료 전 강제 무효화 어려움 |
| 저장 부담 | 서버 메모리/DB | 없음(클라이언트 보관) |
| 크기 | 세션 ID만(작음) | 토큰 자체가 큼 |
면접 답변 예시
"쿠키는 브라우저에 저장돼 요청마다 자동 전송되는 데이터 저장 수단이고, 세션과 토큰은 인증 방식입니다. 세션 방식은 서버가 로그인 상태를 저장하고 클라이언트엔 세션 ID만 쿠키로 주는 Stateful 방식입니다. 서버가 상태를 갖고 있어 즉시 로그아웃 처리가 쉽지만, 서버 확장 시 세션 공유가 필요합니다. JWT 방식은 사용자 정보를 서명된 토큰에 담아 클라이언트가 보관하고, 서버는 서명만 검증하는 Stateless 방식입니다. 확장에 유리하지만, 토큰을 만료 전에 강제 무효화하기 어렵고 페이로드는 암호화가 아니라 누구나 볼 수 있다는 점에 주의해야 합니다. 그래서 보통 짧은 만료의 Access Token과 Refresh Token을 함께 씁니다."
면접 꼬리질문 대비
Q1. JWT는 왜 즉시 로그아웃이 어렵나요?
서버가 토큰을 저장하지 않고 서명만 검증하기 때문에, 한 번 발급된 토큰은 만료 시각까지 유효합니다. 강제 무효화하려면 블랙리스트를 서버에 두거나 토큰 버전을 관리해야 하는데, 이러면 다시 서버가 상태를 갖게 되어 Stateless 장점이 약해집니다. 그래서 Access Token은 만료를 짧게 두고 Refresh Token으로 갱신하는 전략을 씁니다.
Q2. JWT를 어디에 저장해야 안전한가요?
localStorage에 저장하면 XSS 공격 시 자바스크립트로 탈취될 수 있습니다. HttpOnly + Secure + SameSite 속성을 준 쿠키에 저장하면 자바스크립트 접근을 막아 XSS에 강하지만, CSRF에 대비해야 합니다. 일반적으로 HttpOnly 쿠키 + SameSite + CSRF 토큰 조합이 권장됩니다.
Q3. Access Token과 Refresh Token을 나누는 이유는?
Access Token은 자주 쓰여 탈취 위험이 크므로 만료를 짧게(수 분~수십 분) 둡니다. 대신 매번 로그인하지 않도록, 안전하게 보관하는 긴 수명의 Refresh Token으로 Access Token을 재발급합니다. 탈취 시 피해 시간을 줄이면서 사용자 편의를 유지하는 절충안입니다.