웹 애플리케이션에서 로그인 기능을 구현하다 보면 Cookie, Session, Token이라는 용어가 반복해서 등장한다.
세 가지 모두 로그인과 인증 과정에서 함께 사용되기 때문에 비슷한 개념처럼 보이지만 실제로 담당하는 역할은 다르다.
| 개념 | 역할 |
| Cookie | 브라우저가 값을 저장하고 요청에 전달하는 메커니즘 |
| Session | 서버가 사용자의 상태를 유지하는 방식 |
| Token | 클라이언트가 서버에 제시하는 Credential |
특히 Cookie와 Session은 서로 경쟁하는 인증 방식이 아니다.
예를 들어 Session 방식에서는 서버가 로그인 상태를 Session Store에 저장하고, 그 Session을 찾기 위한 Session ID를 Cookie에 담아 브라우저에 전달하는 경우가 많다.
Token 역시 Cookie에 저장할 수도 있고 Authorization Header로 전달할 수도 있다.
즉 Cookie, Session, Token을 이해하려면 세 가지를 같은 종류의 기술로 비교하기보다 어떤 문제를 해결하는지를 구분해서 보는 것이 중요하다.
그 출발점은 HTTP가 요청 사이의 로그인 상태를 자동으로 기억하지 않는다는 점이다.
목차
- HTTP 요청만으로는 이전 로그인 상태를 알 수 없다
- Cookie는 브라우저가 값을 저장하고 전달하는 메커니즘이다
- Session은 서버가 로그인 상태를 유지하는 방식이다
- Session ID와 Session Store
- 여러 서버에서 Session을 공유하는 방법 - Token은 클라이언트가 서버에 제시하는 Credential이다
- Opaque Token
- Stateless Token - Cookie, Session, Token은 실제 시스템에서 조합해서 사용한다
- Cookie + Session
- Cookie + Token
- Authorization Header + Token
1. HTTP 요청만으로는 이전 로그인 상태를 알 수 없다
HTTP 요청은 기본적으로 각각 독립적으로 처리된다.
예를 들어 사용자가 로그인을 요청한다고 하자.
POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded
email=user@example.com&password=...
서버가 사용자 정보를 확인하고 로그인에 성공한다.
HTTP/1.1 200 OK
이후 사용자가 자신의 프로필을 요청한다.
GET /profile HTTP/1.1
하지만 /profile 요청만 보면 서버는 이 요청이 조금 전에 로그인한 사용자에게서 온 것인지 알 수 없다.
HTTP가 이전 요청에서 발생한 애플리케이션의 로그인 상태를 다음 요청에 자동으로 연결해 주지는 않기 때문이다.
따라서 로그인 이후에도 사용자를 식별하려면 이후 요청에서 서버가 확인할 수 있는 정보를 계속 전달해야 한다.
전체 흐름은 다음과 같다.
로그인 요청 → 사용자 인증 → 식별 또는 인증 정보 발급 → 이후 요청마다 해당 정보 전달 → 서버가 사용자 확인
Cookie, Session, Token은 이 과정의 서로 다른 부분을 담당한다.
2. Cookie는 브라우저가 값을 저장하고 자동으로 전달하는 메커니즘이다
Cookie는 브라우저가 웹사이트와 관련된 값을 저장하고, Cookie의 적용 조건에 맞는 요청에 자동으로 포함하는 메커니즘이다.
서버는 응답의 Set-Cookie Header를 이용해 Cookie를 설정할 수 있다.
HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; Path=/; HttpOnly
브라우저는 Cookie를 저장하고 이후 조건에 맞는 요청을 보낼 때 Cookie Header에 값을 포함한다.
GET /profile HTTP/1.1
Host: example.com
Cookie: session_id=abc123
여기서 중요한 점은 Cookie 자체가 로그인 상태를 의미하는 것은 아니라는 것이다.
Cookie는 값을 저장하고 전달하는 방법이다.
Cookie에는 인증과 관계없는 값도 저장할 수 있다.
- 언어 설정
- 사용자 환경 설정
- Session ID
- 인증에 사용하는 Token
예를 들어 다음 Cookie 값은 서버의 Session을 찾기 위한 ID일 수 있다.
Cookie: session_id=abc123
반대로 Token 자체를 Cookie에 저장할 수도 있다.
Cookie: access_token=eyJ...
따라서 Cookie가 해결하는 문제는 어떤 인증 방식을 사용할 것인가 보다는
브라우저가 어떤 값을 어디에 저장하고, 어떤 요청에 전달할 것인가
에 가깝다.
실제 Cookie에는 Domain, Path, Secure, HttpOnly, SameSite 같은 속성이 있으며, 이 속성들이 Cookie의 저장과 전송 범위를 결정한다.
이 글에서는 Cookie의 역할만 구분하고, 이러한 세부 속성은 이후 글에서 따로 살펴본다.
3. Session은 서버가 로그인 상태를 유지하는 방식이다
Session 방식에서는 사용자의 로그인 상태를 서버 측에 저장한다.
사용자가 로그인하면 서버는 ID와 Password 등의 Credential을 검증한다.
인증에 성공하면 해당 사용자를 위한 Session을 생성한다.
예를 들어 Session Store에는 다음과 같은 정보가 저장될 수 있다.
| Session ID | 사용자 상태 |
| abc123 | user_id = 42 |
| role = admin | |
| expires_at = ... |
그리고 서버는 해당 Session을 찾을 수 있는 Session ID를 Client에 전달한다.
브라우저 기반 웹 애플리케이션에서는 Session ID를 Cookie에 저장하는 방식이 흔하다.
HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; Path=/; HttpOnly
브라우저는 이후 요청에 Session ID를 전달한다.
GET /profile HTTP/1.1
Cookie: session_id=abc123
서버는 전달받은 Session ID를 이용해 Session Store를 조회한다.
Browser → session_id=abc123 → Server → Session Store 조회 → user_id=42 확인
이 구조에서 Cookie와 Session의 역할은 명확하게 나뉜다.
| 구성 요소 | 역할 |
| Cookie | Session ID를 브라우저에 저장하고 요청에 전달 |
| Session ID | 서버의 Session을 찾기 위한 식별자 |
| Session Store | 실제 로그인 상태 저장 |
Session ID는 일반적으로 그 값 자체만 보고 사용자 정보를 알아낼 필요가 없다.
예를 들어,
abc123이라는 값만으로는 어떤 사용자에게 해당하는지 알 수 없고 서버가 Session Store를 조회해야 실제 상태를 확인할 수 있다.
이처럼 내부 정보를 직접 담지 않고 서버 측 데이터를 가리키는 식별자를 Opaque Identifier 형태로 사용할 수 있다.
Session 방식의 장점 중 하나는 서버가 로그인 상태를 직접 통제하기 쉽다는 점이다.
사용자를 강제로 로그아웃시키고 싶다면 해당 Session을 삭제하거나 무효화할 수 있다.
session_id=abc123 → Session 조회 → Session 없음 → 인증 실패
반면 서버가 Session 상태를 유지해야 한다는 특성도 있다.
애플리케이션 서버가 여러 대라면 어느 서버가 요청을 처리하더라도 동일한 Session에 접근할 수 있어야 한다.
[이미지: Browser → Load Balancer → Server A / Server B / Server C → Shared Session Store 구조]
그래서 여러 서버가 동일한 Session을 사용해야 하는 환경에서는 Redis 같은 외부 저장소를 Shared Session Store로 사용하는 경우가 많다.
4. Token은 클라이언트가 서버에 제시하는 Credential이다
Token 방식에서는 로그인 이후 Client가 서버가 검증할 수 있는 값을 가지고 있다가 요청할 때 제시한다.
예를 들어 로그인에 성공하면 서버가 Access Token을 발급할 수 있다.
Client는 이후 요청에 Token을 포함한다.
대표적인 방법이 Authorization Header다.
GET /profile HTTP/1.1
Authorization: Bearer <token>
서버는 Token을 검증하고 요청자를 식별한다.
Client → Token 전달 → Server → Token 검증 → 사용자 식별
여기에서 중요한 점은 Token이라는 개념 자체가 저장 위치나 검증 방법을 결정하지 않는다는 것이다.
Token은 Client가 서버에 제시하는 Credential이라는 역할에 가깝다.
Token을 서버 측 데이터와 연결해서 사용할 수도 있다.
예를 들어 서버가 임의의 값을 발급한다고 하자.
f83a2e4c...
요청이 들어올 때마다 서버가 이 값을 데이터베이스에서 조회할 수 있다.
Token → Database 조회 → 사용자 및 권한 확인
이 경우 서버 측 상태를 조회한다는 점에서 구조적으로 Session 방식과 비슷한 부분이 있다.
반대로 JWT처럼 Token 자체에 Claim을 포함하고, 서버가 서명 등을 검증하여 정보를 확인하는 방식도 있다.
따라서 흔히 말하는
- Session = Stateful
- Token = Stateless
라는 구분을 항상 성립하는 규칙으로 받아들이면 안 된다.
Token을 사용해도 서버가 Token 상태나 폐기 목록을 저장할 수 있고, Opaque Token처럼 매 요청마다 서버 측 저장소를 조회하는 구조도 만들 수 있다.
핵심적인 차이는 Token이라는 값 자체가 Client가 서버에 제시하는 Credential로 사용된다는 것이다.
참고로 Token이라는 용어는 범위가 넓다. Session ID 역시 서버가 발급하고 Client가 제시한다는 점에서는 일종의 bearer credential 역할을 할 수 있다.
이 글에서는 개념을 구분하기 위해 Session Store를 가리키는 Session ID와 API 인증에서 사용하는 Access Token 같은 Token을 나누어 설명한다.
5. 실제 시스템에서는 Cookie, Session, Token을 조합한다
Cookie, Session, Token은 같은 계층의 기술이 아니기 때문에 하나만 선택해서 사용하는 관계가 아니다.
각각 해결하는 문제가 다르다.
| 개념 | 해결하는 문제 |
| Cookie | 브라우저가 값을 어떻게 저장하고 전달할 것인가 |
| Session | 로그인 상태를 서버에서 어떻게 유지할 것인가 |
| Token | Client가 서버에 어떤 Credential을 제시할 것인가 |
따라서 실제 시스템에서는 여러 방식으로 조합할 수 있다.
Cookie + Session
브라우저는 Session ID를 Cookie에 저장하고 서버는 Session Store에 실제 로그인 상태를 저장한다.
Browser → Cookie: session_id=abc123 → Server → Session Store
웹 애플리케이션에서 흔히 말하는 Cookie + Session 방식이다.
Cookie + Token
Token 자체를 Cookie에 저장할 수도 있다.
Cookie: access_token=...
이 경우 Cookie는 Token의 저장 및 전달 방법이고, Token은 서버에 제시하는 Credential이다.
Authorization Header + Token
Cookie를 사용하지 않고 Token을 명시적으로 Header에 넣을 수도 있다.
Authorization: Bearer <token>
API Client나 모바일 애플리케이션 등에서는 이런 형태도 흔하게 사용된다.
전체 관계를 하나로 정리하면 다음과 같다.
HTTP 요청만으로는 이전 로그인 상태를 자동으로 알 수 없음
→ 이후 요청에서 사용자를 확인할 정보가 필요함
→ Cookie는 브라우저가 값을 저장하고 전달할 수 있게 함
→ Session은 서버가 로그인 상태를 유지할 수 있게 함
→ Token은 Client가 서버에 Credential을 제시할 수 있게 함
이 역할을 구분하면 이후 등장하는 개념도 어느 영역에 속하는지 이해하기 쉬워진다.
- Secure, HttpOnly, SameSite는 Cookie가 어떤 조건에서 저장되고 전송되는지와 관련된다.
- Access Token과 Refresh Token은 Token을 어떤 목적과 수명으로 사용할지와 관련된다.
- JWT는 Token을 어떤 형식으로 구성하고 검증할 수 있는지와 관련된다.
이번 글에서는 Cookie, Session, Token이 각각 어떤 역할을 담당하는지만 정리했다.
다음 글에서는 각각의 동작 방식과 보안 속성을 더 자세히 살펴본다.
'보안' 카테고리의 다른 글
| JWT와 JWKS — Token을 서명하고 검증하는 방법 (0) | 2026.09.27 |
|---|---|
| 공개키와 개인키 — 암호화와 디지털 서명의 원리 (0) | 2026.09.27 |
| Token 기반 인증 이해하기 — Bearer, Access·Refresh Token (0) | 2026.09.26 |
| Session의 동작 원리 — Session ID와 서버 측 상태 관리 (1) | 2026.09.26 |
| Cookie의 동작 원리 — Scope와 보안 속성 (0) | 2026.09.25 |
