Stateless

stateless, 무상태, Stateless 서버, stateless server

정의

Stateless (무상태) 서버는 클라이언트의 요청 간 상태를 기억하지 않는다. 각 요청은 완전히 독립적이며, 처리에 필요한 모든 정보는 요청 자체에 담겨 있어야 한다.

같은 요청이라면 어느 서버 인스턴스가 처리하든 결과가 같다는 게 핵심 속성. 이게 수평 확장을 단순하게 만든다.

전체 비교는 Stateless vs Stateful 페이지를 참조.

핵심 특성

측면	동작
세션 상태	서버 메모리에 없음
수평 확장	무제한, round-robin LB
장애 복원	서버 교체 시 사용자 무영향
인증 정보	매 요청마다 토큰/키 첨부
캐싱	URL 기반 캐시 매우 효율적

어떻게 stateless 를 유지하는가

상태가 정말 필요 없는 경우는 드물다. 보통은 “상태를 서버 메모리에 두지 않는다” 가 핵심이다. 어디에 두는가가 선택이다.

1. 외부 store 위임

세션·캐시·잠금 등을 Redis, DynamoDB, DB 에 둔다. 모든 서버 인스턴스가 같은 store 에 접근.

요청 → 어느 서버든 OK → Redis 에서 세션 조회 → 응답

비용: 매 요청마다 store I/O (보통 1-3 ms). 운영 단순성을 위한 합리적 trade-off.

2. 클라이언트 측 상태 (JWT, Cookie)

상태를 클라이언트가 들고 다님. 서버는 검증만.

로그인 → JWT 발급 → 클라이언트가 보관
이후 요청 → Authorization: Bearer <JWT> → 서명 검증으로 사용자 식별

3. URL/Query 에 상태 인코딩

페이지네이션 커서, 필터 조건 등을 URL 에 담는다.

GET /products?cursor=eyJpZCI6MTIzfQ&limit=20

서버는 cursor 만 읽고 응답.

실무 예시

REST API

GET /api/users/42
Authorization: Bearer eyJhbGc...

→ 서버: JWT 검증, DB 에서 user 42 조회, 응답
   메모리에 세션 X

CDN / 정적 자원

GET /static/main.css
→ 어느 edge 서버든 같은 응답
→ 캐시 적중률 매우 높음

Serverless 함수 (AWS Lambda 등)

함수 실행마다 컨테이너가 새로 만들어질 수 있음 → stateless 가 강제됨. 세션은 DynamoDB / Redis 등에 위임 필수.

함정과 한계

1. “Stateless 인데 외부 store 가 단일 장애점”

Redis 다운 → 모든 서버가 세션 조회 실패. Stateless 한 서버를 만들어놓고 외부 store 에 의존하면 그게 SPOF 가 된다. 고가용성 Redis 클러스터, fallback 전략 필요.

2. JWT 즉시 취소 어려움

JWT 는 만료 전까지 유효. 사용자 권한 변경/로그아웃을 즉시 반영하려면 블랙리스트 같은 별도 store 가 필요 → 일부 stateful 화.

3. Per-request 토큰 검증 비용

매 요청마다 JWT 서명 검증 (CPU) + 외부 store 조회 (I/O). 트래픽이 많으면 누적된다.

통신 프로토콜과의 관계

프로토콜	Stateless 친화도
HTTP/1.1, 2, 3	✓ 완벽 (메시지 의미상)
Short Polling	✓
Long Polling	✓ (HTTP 의미상, 운영상은 연결 점유)
Server-Sent Events	✗ Stateful (지속 연결)
WebSocket	✗ Stateful
WebRTC	✗ Stateful

대부분의 REST API · CDN · 정적 사이트는 자연스럽게 stateless.

관련 위키

• Stateful
• Sticky Session, Stateful 의 회피책
• Stateless vs Stateful (전체 비교, 애니메이션 포함)