앞선 글에서는 Cookie가 브라우저에 값을 저장하고, 조건에 맞는 HTTP 요청에 자동으로 포함하는 메커니즘이라는 점을 살펴봤다.
웹 인증에서는 Cookie에 다음과 같은 값을 저장하는 경우가 많다.
Cookie: session_id=abc123
하지만 abc123이라는 값 자체에 사용자의 로그인 상태가 모두 들어 있는 것은 아니다.
실제 인증 상태는 서버에 저장하고, 브라우저에는 그 상태를 찾기 위한 Session ID만 전달할 수 있다.
Browser → Session ID → Server → Session Store → 사용자 상태
이 구조가 일반적인 Session 기반 인증이다.
이번 글에서는
- Session이 어떻게 생성되고 요청마다 사용되는지
- Session ID를 왜 안전하게 관리해야 하는지
- 만료와 로그아웃은 어떻게 처리하는지
- 여러 서버 환경에서는 Session을 어떻게 공유하는지 살펴본다.
목차
- Session은 서버가 사용자 상태를 유지하는 방식이다
- 로그인과 Session 생성
- 이후 요청에서 Session 조회 - Session ID는 인증 상태를 찾는 Credential이다
- Opaque Identifier
- Session ID를 안전하게 관리해야 하는 이유 - Session은 만료와 로그아웃을 서버에서 제어할 수 있다
- 로그아웃과 Session 폐기
- Absolute Expiration
- Idle Timeout - 여러 서버에서는 Session 상태를 공유해야 한다
- 서버 메모리에 Session을 저장할 때의 문제
- Shared Session Store
- Sticky Session
1. Session은 서버가 사용자 상태를 유지하는 방식이다
HTTP는 요청 사이의 애플리케이션 상태를 자동으로 기억하지 않는다.
사용자가 로그인에 성공했더라도 이후 /profile 요청만 보면 HTTP 자체에는 이 요청이 이전 로그인 요청과 같은 사용자에게서 왔다는 정보가 없다.
Session 방식에서는 이 문제를 해결하기 위해 로그인 상태를 서버 측에 저장하고, Client에는 해당 상태를 찾기 위한 식별자를 전달한다.
로그인과 Session 생성
사용자가 다음과 같이 로그인 요청을 보낸다고 하자.
POST /login HTTP/1.1
Content-Type: application/json
{
"email": "user@example.com",
"password": "..."
}
서버는 사용자가 전달한 Credential을 검증한다.
인증에 성공하면 새로운 Session을 생성하고 Session Store에 사용자 상태를 저장한다.
| Session ID | 저장된 상태 |
| abc123 | user_id = 42 |
| role = admin | |
| created_at = ... | |
| expires_at = ... |
그리고 해당 Session을 다시 찾을 수 있는 Session ID를 Client에 전달한다.
브라우저 기반 웹 애플리케이션에서는 Session ID를 Cookie에 저장하는 방식이 흔하다.
HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; HttpOnly; Secure
여기서 Cookie와 Session의 역할은 다르다.
- Cookie는 Session ID를 브라우저에 저장하고 요청에 전달한다.
- Session은 실제 사용자 상태를 서버에 저장한다.
이후 요청에서 Session 조회
로그인 이후 브라우저는 조건에 맞는 요청을 보낼 때 Session ID Cookie를 포함한다.
GET /profile HTTP/1.1
Cookie: session_id=abc123
서버는 요청에서 Session ID를 확인하고 Session Store에서 해당 Session을 조회한다.
session_id=abc123 → Session Store 조회 → user_id=42 → 현재 사용자 식별
Session이 존재하고 아직 유효하다면 서버는 해당 Session에 연결된 사용자의 요청으로 처리한다.
반대로 Session Store에 해당 ID가 없거나 Session이 만료되었다면 인증된 요청으로 처리할 수 없다.
즉 Session 기반 인증에서는 일반적으로 인증이 필요한 요청마다 Session ID를 이용해 서버 측 인증 상태를 확인하는 과정이 포함된다.
Session 요청 처리 흐름
2. Session ID는 인증 상태를 찾는 Credential이다
Session ID에는 일반적으로 사용자 정보를 직접 담을 필요가 없다.
예를 들어 다음 값만 봐서는 어떤 사용자에 해당하는지 알 수 없다.
abc123
실제 의미를 확인하려면 서버가 Session Store를 조회해야 한다.
abc123 → Session Store → user_id=42, role=admin
이처럼 값 자체를 해석해서 사용자 정보를 얻는 것이 아니라 서버 측 데이터와 연결해야 의미를 알 수 있는 식별자를 Opaque Identifier 형태로 사용할 수 있다.
하지만 Session ID에 사용자 정보가 들어 있지 않다고 해서 중요하지 않은 값은 아니다.
Session ID 자체가 이미 인증된 Session을 사용할 수 있게 하는 Credential 역할을 하기 때문이다.
누군가 유효한 Session ID를 획득하면 서버는 그 값을 기존 사용자의 Session과 연결할 수 있다.
따라서 Session ID는 비밀번호처럼 직접적인 사용자 Credential은 아니지만, 인증 이후에는 Bearer Credential과 비슷하게 보호해야 하는 값이다.
Session ID를 안전하게 관리해야 하는 이유
Session ID를 사용자 ID처럼 쉽게 예측할 수 있는 값으로 만들면 안 된다.
session_id=42
또는 다음처럼 사용자 정보를 그대로 사용하는 방식도 적절하지 않다.
session_id=user@example.com
Session ID는 일반적으로 충분히 긴 예측 불가능한 난수로 생성한다.
브라우저에서 사용하는 경우에는 Cookie의 Secure, HttpOnly, SameSite 같은 속성도 Session ID의 노출 범위를 줄이는 데 함께 사용할 수 있다.
또한 로그인 전후에 같은 Session ID를 계속 사용하는 구조는 Session Fixation 공격의 원인이 될 수 있기 때문에, 인증에 성공한 뒤 Session ID를 새 값으로 교체하는 방식도 일반적으로 사용한다.
권한이 크게 변경되는 시점에도 Session을 새로 발급하거나 기존 Session을 재검증하는 정책을 사용할 수 있다.
즉 Session 보안에서 중요한 것은 Session Store 자체뿐 아니라 Session ID가 생성되고, 저장되고, 전달되고, 폐기되는 전체 과정이다.
3. Session은 만료와 로그아웃을 서버에서 제어할 수 있다
Session 방식의 중요한 특징은 서버가 현재 인증 상태를 직접 관리한다는 점이다.
로그아웃과 Session 폐기
사용자가 로그아웃하면 서버는 해당 Session을 Session Store에서 삭제하거나 무효화할 수 있다.
abc123 Session 삭제 → 이후 같은 Session ID가 들어와도 인증 실패
브라우저가 이전 Session ID Cookie를 가지고 있더라도 서버에 유효한 Session이 없다면 더 이상 인증 상태로 사용할 수 없다.
실제 로그아웃에서는 서버 측 Session을 폐기하는 것과 함께 브라우저의 Session Cookie도 만료시키는 것이 일반적이다.
Set-Cookie: session_id=; Max-Age=0; Path=/; HttpOnly; Secure
이처럼 서버가 Session 상태를 가지고 있기 때문에 특정 사용자의 Session을 강제로 종료하거나 여러 Session 중 일부만 폐기하는 정책도 구현할 수 있다.
Absolute Expiration
Session은 일정 시간이 지나면 더 이상 사용할 수 없도록 만료 시간을 설정할 수 있다.
Absolute Expiration은 Session을 만든 시점부터 정해진 시간이 지나면 사용자의 활동 여부와 관계없이 만료하는 방식이다.
예를 들어 Session의 최대 수명이 2시간이라면 오후 10시에 로그인한 Session은 계속 사용하더라도 자정에 만료된다.
22:00 로그인 → 최대 수명 2시간 → 00:00 만료
Idle Timeout
Idle Timeout은 마지막 활동 이후 일정 시간 동안 요청이 없으면 Session을 만료하는 방식이다.
예를 들어 Idle Timeout이 30분이고 마지막 요청이 오후 10시에 발생했다면 이후 활동이 없을 경우 오후 10시 30분에 Session을 만료할 수 있다.
22:00 마지막 활동 → 30분 동안 활동 없음 → 22:30 만료
Absolute Expiration과 Idle Timeout은 서로 대체하는 방식이 아니다.
보안 요구사항에 따라 두 정책을 함께 적용할 수 있다.
| 방식 | 기준 | 사용자가 계속 활동할 때 |
| Absolute Expiration | Session 생성 시점부터 정해진 최대 수명 | 계속 활동해도 최대 수명에 도달하면 만료 |
| Idle Timeout | 마지막 활동 시점부터 경과 시간 | 요청이 계속되면 만료 시점이 갱신될 수 있음 |
4. 여러 서버에서는 Session 상태를 공유해야 한다
애플리케이션 서버가 한 대라면 Session을 해당 서버의 메모리에 저장하는 구조도 가능하다.
Browser → Server A → Memory Session Store
하지만 서버가 여러 대로 늘어나면 Session 상태를 어디에 저장할 것인지가 중요한 문제가 된다.
서버 메모리에 Session을 저장할 때의 문제
다음과 같이 Load Balancer 뒤에 Server A와 Server B가 있다고 하자.
Browser → Load Balancer → Server A / Server B
사용자가 처음 로그인했을 때 Server A의 메모리에 다음 Session이 저장되었다고 하자.
Server A: abc123 → user_id=42
다음 요청이 Server B로 전달되면 Server B의 메모리에는 abc123이라는 Session이 존재하지 않을 수 있다.
Client가 동일한 Session ID를 보내더라도 어느 Server가 요청을 처리하느냐에 따라 로그인 상태가 달라지는 문제가 생긴다.
Shared Session Store
이 문제를 해결하는 대표적인 방법이 Shared Session Store다.
Session을 각 Application Server의 Local Memory에 저장하는 대신 모든 Server가 접근할 수 있는 외부 저장소에 둔다.
예를 들어 Redis 같은 저장소를 Session Store로 사용할 수 있다.
Server A / Server B / Server C → Shared Session Store
이 구조에서는 어느 Application Server가 요청을 처리하더라도 동일한 Session ID를 이용해 같은 인증 상태를 조회할 수 있다.
session_id=abc123 → Shared Session Store → user_id=42
다만 Shared Session Store 자체도 인증 경로의 중요한 의존성이 되므로 가용성, 데이터 만료 정책, 장애 대응을 함께 고려해야 한다.
Sticky Session
또 다른 방법은 Load Balancer가 같은 사용자의 요청을 가능한 한 같은 Application Server로 보내는 Sticky Session을 사용하는 것이다.
- User A → 항상 Server A
- User B → 항상 Server B
이 방식에서는 Session을 각 Server의 Local Memory에 두면서도 동일한 사용자의 요청이 같은 Server로 전달되도록 할 수 있다.
하지만 특정 Server에 사용자 상태가 묶이기 때문에 Server 장애, Scale Out, 재배포 시 Session 유지와 Traffic 분산에 제약이 생길 수 있다.
따라서 여러 Application Server가 동일한 인증 상태를 안정적으로 사용해야 하는 환경에서는 Shared Session Store를 사용하는 구조가 흔하다.
정리
Session 기반 인증은 사용자의 인증 상태를 서버가 유지하고, Client가 Session ID를 전달해 해당 상태를 찾는 방식이다.
전체 흐름은 다음과 같다.
Login → 사용자 인증 → Session 생성 → Session ID 발급 →
Browser가 Session ID 저장 → 이후 요청에서 Session ID 전달 →
Session Store 조회 → 사용자 식별
Cookie, Session, Session ID의 역할도 구분할 수 있다.
| 구성 | 역할 |
| Cookie | 브라우저가 Session ID를 저장하고 조건에 맞는 HTTP 요청에 전달 |
| Session ID | 서버에 저장된 Session을 찾는 식별자이자, 유효한 Session을 사용할 수 있게 하는 Credential |
| Session | 서버가 유지하는 실제 사용자 인증 상태 |
Session 방식의 가장 큰 특징은 서버가 인증 상태를 직접 통제할 수 있다는 점이다.
- Session을 삭제하면 해당 인증 상태를 즉시 무효화할 수 있다.
- Absolute Expiration이나 Idle Timeout을 적용할 수 있다.
- 사용자별 또는 Device별 Session을 개별적으로 관리할 수 있다.
반면 인증이 필요한 요청에서는 Session Store의 상태를 확인해야 하고, 여러 Application Server가 같은 인증 상태를 사용한다면 Shared Session Store 같은 구조도 필요하다.
다음 글에서는 서버가 인증 상태를 직접 보관하는 Session 방식과 달리, Client가 Credential을 가지고 요청에 제시하는 Token 기반 인증을 살펴본다.
'보안' 카테고리의 다른 글
| JWT와 JWKS — Token을 서명하고 검증하는 방법 (0) | 2026.09.27 |
|---|---|
| 공개키와 개인키 — 암호화와 디지털 서명의 원리 (0) | 2026.09.27 |
| Token 기반 인증 이해하기 — Bearer, Access·Refresh Token (0) | 2026.09.26 |
| Cookie의 동작 원리 — Scope와 보안 속성 (0) | 2026.09.25 |
| 웹 인증의 기본 — Cookie / Session / Token (0) | 2026.09.25 |
