kimyenac
techblog
cs
쿠키 vs 세션 그리고 REST
2026-04-08

REST

REST 는 HTTP 기반 API 를 설계하는 규칙(스타일)을 말합니다.

REST 의 핵심 원칙

첫 번째, 자원(Resource) 중심 설계

/users        → 유저 목록
/users/1      → 특정 유저

여기서 URL 은 "행위"가 아니라 "데이터(자원)"를 표현합니다.


두 번째, HTTP Method 로 행동을 표현

GET    /users/1   → 조회
POST   /users     → 생성
PATCH  /users/1   → 수정
DELETE /users/1   → 삭제

세 번째, Stateless 로 서버는 클라이언트 상태를 기억하지 않는다.


정리하면, REST 서버는 이전 요청을 기억하지 않고, 매 요청마다 독립적으로 요청 하나만 보고 처리할 수 있어야 한다는 구조입니다. 여기서 중요한 점은 HTTP 는 원래 Stateless 입니다. 그래서 만약 로그인을 요청하고 상품 조회를 요청했을 때 서버 입장에서는 '이 사람이 로그인을 했었나?' 라고 할 때 모른다는 점입니다.

그래서 등장한 개념이 상태(state)를 유지하는 방법입니다.





쿠키 (Cookie)

상태를 유지하는 방법 중 첫 번째 쿠키는 브라우저(클라이언트)에 저장되는 작은 데이터로 동작 흐름은 아래와 같습니다.

1. 서버 → Set-Cookie 응답
2. 브라우저 → 쿠키 저장
3. 이후 요청마다 자동 전송

// 구조 그림
┌─────────────┐        요청         ┌─────────────┐
│  Browser    │ ───────────────▶ │   Server     │
│             │                 │             │
│ Cookie 저장 │ ◀────────────── │ Set-Cookie  │
└─────────────┘                 └─────────────┘

이후 모든 요청:
Cookie 자동 포함

쿠키의 특징은 클라이언트에 저장하는 거고, 자동으로 전송되며 용량 제한 (~4KB) 이 있다는 점, 변조가 가능해 보안이 취약하다는 점입니다.





세션 (Session)

상태를 유지하는 방법 중 두 번째 세션은 서버가 사용자 상태를 저장하는 방식으로, 클라이언트는 세션 ID만 보관하며 동작 흐름은 아래와 같습니다.

1. 로그인 요청
2. 서버 → 세션 생성
3. sessionId를 쿠키로 전달
4. 이후 sessionId로 사용자 식별

// 구조 그림
┌─────────────┐        요청         ┌─────────────┐
│  Browser    │ ───────────────▶ │   Server     │
│             │                 │             │
│ sessionId   │ ◀────────────── │ 세션 생성     │
│ (쿠키 저장) │                 │ (메모리/DB)   │
└─────────────┘                 └─────────────┘

이후:
sessionId → 사용자 정보 조회

세션의 특징은 실제 데이터는 서버에 저장되어 비교적 안전하지만, 서버 메모리를 사용하여 확장성 문제가 발생할 수 있다는 점입니다.





쿠키 vs 세션 vs REST

쿠키와 세션을 비교하면, 먼저 쿠키는 클라이언트, 세션은 서버에 저장되고, 데이터를 쿠키는 직접 저장하여 보안에 취약하지만, 세션은 ID 만 저장하여 보안에 강합니다. 서버에 저장하다보니 세션은 서버 부담이 있지만, 쿠키는 없고. 확장성 측면에서 보았을 때 쿠키는 상대적으로 좋은 편이지만, 세션은 제한적입니다.

세션은 서버가 사용자 상태를 기억하는 Stateful 구조지만, REST 는 Stateless 가 원칙 (서버는 상태를 저장하면 안 된다) 이기 때문에 REST 에서는 세션을 잘 안 쓰고, 토큰 기반 인증인 JWT 와 같은 방식으로 해결합니다. 동작 흐름은 다음과 같습니다.

1. 로그인 → 토큰 발급
2. 클라이언트가 저장
3. 요청마다 토큰 포함

// 구조 그림
┌─────────────┐        요청         ┌─────────────┐
│  Client     │ ───────────────▶ │   Server     │
│             │                 │             │
│ JWT 저장    │ ◀────────────── │ 토큰 발급     │
└─────────────┘                 └─────────────┘

이후 요청:
Authorization: Bearer <token>

세션은 서버에 상태를 저장하고, JWT 는 클라이언트에 상태를 저장한다는 차이로, JWT 는 REST 에 적합합니다.





마무리

전체적인 흐름은 다음과 같습니다.

HTTP → Stateless

→ 상태 유지 필요
    ├─ 쿠키 (클라이언트 저장)
    └─ 세션 (서버 저장)

REST → Stateless 유지 필요
    └─ 토큰 기반 인증 (JWT)

정리하면, HTTP 는 원래 상태를 기억하지 않습니다. 쿠키와 세션은 이를 보완하기 위한 방법이고, REST 는 아예 상태를 없애는 방향으로 설계됩니다.






Reference