웹사이트를 이용할 때 로그인 상태가 유지되거나 장바구니에 담아둔 상품 정보가 사라지지 않는 것은 모두 인증 및 상태 유지 메커니즘 덕분입니다. 특히 HTTP 통신은 기본적으로 무상태(Stateless)라서, 이 세 가지 핵심 기술(쿠키, 세션, 토큰)이 없다면 매 페이지 이동 시마다 로그인을 다시 해야 하는 불편함이 발생합니다.
이 글에서는 이 세 가지 기술의 동작 원리, 장단점, 그리고 차이점을 그림과 함께 쉽게, 하지만 깊이 있게 설명해 드릴게요.
1. 🍪 쿠키 (Cookie) 기반 인증: 클라이언트 저장소
쿠키는 클라이언트(브라우저) 측에 데이터를 저장하여 상태를 유지하는 방식입니다.
1) 동작 원리
- 클라이언트 요청: 브라우저가 서버에 로그인 요청을 보냅니다.
- 서버 응답: 서버는 사용자가 인증되면, 사용자 정보를 담은 쿠키 또는 세션 ID를 포함한 쿠키를 만들어 HTTP 응답 헤더에 넣어 클라이언트에게 보냅니다.
- 클라이언트 저장: 브라우저는 이 쿠키를 로컬 저장소에 저장합니다.
- 다음 요청: 이후 클라이언트가 같은 서버에 요청을 보낼 때마다, 이 쿠키를 HTTP 요청 헤더에 자동으로 포함하여 서버로 전송합니다.
- 서버 인증: 서버는 이 쿠키를 확인하여 사용자를 식별하고 상태를 유지합니다.
2) 장단점
| 장점 | 단점 |
| 구현이 간단하고 설정이 편리함 | 보안 취약: 클라이언트(브라우저)에 저장되므로, XSS 공격 등에 취약하여 민감 정보 저장에 부적합. |
| 클라이언트 측 상태 정보를 보존 가능 | 용량 제한: 쿠키당 약 4KB의 용량 제한이 있음. |
| 매 요청 전송: 모든 요청마다 쿠키가 자동으로 포함되어 네트워크 부하를 증가시킬 수 있음. |
2. 🖥️ 세션 (Session) 기반 인증: 서버 저장소
세션은 사용자 정보를 서버 메모리나 데이터베이스에 저장하고, 클라이언트에게는 그 정보에 접근할 수 있는 세션 ID(Session ID)만 쿠키 형태로 전달하는 방식입니다.
1) 동작 원리
- 클라이언트 요청: 브라우저가 로그인 요청을 보냅니다.
- 서버 세션 생성: 서버는 인증 후, 사용자 정보를 서버에 저장하고, 이 세션에 접근할 수 있는 고유한 세션 ID를 발급합니다.
- 세션 ID 전달: 서버는 이 세션 ID를 담은 쿠키(세션 쿠키)를 클라이언트에게 전달합니다.
- 다음 요청: 클라이언트는 이후 요청마다 이 세션 ID를 담은 쿠키를 서버로 전송합니다.
- 서버 인증: 서버는 전달받은 세션 ID를 이용해 자신의 저장소에서 사용자 정보를 찾아 인증합니다.
2) 장단점
| 장점 | 단점 |
| 보안 강함: 민감한 정보는 서버에만 저장되므로 쿠키보다 보안이 훨씬 강력함. | 서버 부하: 사용자가 늘어날수록 서버 메모리나 DB에 부담이 커짐. |
| 데이터 용량 제한이 없음 | 확장성 문제 (Scale-out): 서버를 여러 대로 확장(Scale-out)할 때 세션 데이터의 공유(Sticky Session 또는 Redis/Memcached 사용)가 복잡해짐. |
3. 🔑 토큰 (Token) 기반 인증: 자체 검증 티켓 (JWT)
토큰 방식은 클라이언트가 서버에 인증을 요청하면, 서버가 사용자 정보를 암호화한 인증 토큰(Authentication Token)을 발급하고, 이 토큰을 클라이언트가 보관했다가 매 요청 시 서버에 전달하는 방식입니다. 가장 대표적인 토큰 방식이 JWT (JSON Web Token)입니다.
1) 동작 원리 (JWT 기준)
- 클라이언트 요청: 브라우저가 로그인 요청을 보냅니다.
- 토큰 발급: 서버는 사용자 인증 후, 사용자 정보(Payload)를 담고 서버 비밀 키로 서명(Sign)한 JWT를 생성하여 클라이언트에게 전달합니다.
- 클라이언트 저장: 클라이언트는 토큰을 로컬 저장소 (localStorage 또는 Cookie)에 저장합니다.
- 다음 요청: 클라이언트는 토큰을 HTTP 헤더 (보통
Authorization: Bearer [토큰])에 담아 서버로 전송합니다. - 서버 검증: 서버는 토큰을 받으면 자신의 비밀 키로 서명을 검증합니다. 토큰이 유효하면 바로 사용자 정보(Payload)를 추출하여 인증을 완료합니다. 별도의 저장소 조회가 필요 없습니다.
2) 장단점
| 장점 | 단점 |
| 확장성/서버 부하 감소: 서버가 토큰을 저장할 필요 없어(Stateless), 서버를 늘리거나 마이크로서비스 환경에서 유리함. | 토큰 용량: 토큰이 너무 크면 매 요청 시 네트워크 부하가 증가. |
| 크로스 도메인: 쿠키와 달리 헤더를 사용하므로 다른 도메인에서도 인증 처리가 쉬움. | 토큰 탈취: 토큰이 탈취되면 유효 기간이 끝날 때까지 막을 방법이 없음 (Refresh Token 도입으로 보완). |
4. 📊 세 가지 인증 방식 비교 요약
| 구분 | 쿠키 | 세션 | 토큰 (JWT) |
| 정보 저장 위치 | 클라이언트 (브라우저) | 서버 (메모리, DB 등) | 클라이언트 (로컬 저장소 또는 쿠키) |
| 서버 상태 | Stateless | Stateful (서버가 상태를 기억) | Stateless (서버가 상태를 기억하지 않음) |
| 보안 | 가장 취약 (XSS 노출 위험) | 가장 강력 (정보가 서버에만 있음) | 강력 (서명 검증), 탈취 시 위험 |
| 확장성 (Scale-out) | 쉬움 | 어려움 (세션 공유 필요) | 매우 쉬움 (Stateless) |
| 사용 환경 | 간단한 상태 유지 (장바구니 등) | 전통적인 웹 애플리케이션 | SPA/모바일, 마이크로서비스 (가장 선호) |
🔑 가장 딥한 차이점: 상태(State)와 서버의 부담
가장 근본적인 차이는 서버가 사용자의 상태를 기억하느냐(Stateful) 아니면 기억하지 않느냐(Stateless)에 있습니다.
- 세션: 서버가 모든 사용자의 상태(세션 데이터)를 기억해야 하므로 Stateful입니다. 서버에 부하가 집중되지만 보안성이 높습니다.
- 쿠키 & 토큰: 서버가 사용자의 상태를 저장하지 않고, 클라이언트가 보내온 정보(쿠키 자체 또는 토큰)만으로 인증을 처리하므로 Stateless입니다. 서버 부하가 낮고 확장성이 좋습니다. 특히 JWT는 토큰 자체에 검증 정보가 있어 서버의 부담이 극도로 낮아집니다.