무상태(stateless)는 서버가 이전 요청을 기억하지 않아도 요청 하나만 보고 처리할 수 있는 구조이고, 상태 유지(stateful)는 서버가 요청 사이에 클라이언트 상태를 저장해 두고 다음 요청을 처리할 때 그 상태를 찾아보는 구조다.
두 층을 구분한다
- 프로토콜: HTTP는 무상태 프로토콜이다. 요청 메시지 하나의 의미가 따로 이해되어야 하고, 서버는 같은 연결로 온 두 요청이 같은 클라이언트에서 왔다고 가정하면 안 된다(그 클라이언트 전용 보안 연결이 아니라면). 이 성질 덕분에 프록시가 연결을 재사용하고 요청을 여러 서버로 나눌 수 있다
- 애플리케이션: HTTP 위에서 서버가 로그인·장바구니 같은 상태를 저장하느냐는 별개의 선택이다. 세션 쿠키 방식도 HTTP 수준에서는 요청마다 세션 id를 실어 보내지만, 서버가 그 id로 저장소를 조회하므로 애플리케이션은 상태 유지다
인증에서의 차이
| 무상태 인증 | 상태 유지 인증 | |
|---|---|---|
| 대표 | 서명된 토큰(JWT) | 세션 인증 |
| 검증 | 서명과 만료만 확인 | 세션 저장소 조회 |
| 서버 확장 | 검증 키만 나눠 주면 된다 | 저장소를 공유해야 한다(Redis (인메모리 저장소)) |
| 즉시 로그아웃·권한 변경 | 어렵다. 토큰 안의 권한은 만료 전까지 그대로다 | 저장된 세션을 지우거나 고치면 다음 요청부터 반영된다 |
| 비용 | 토큰이 요청마다 실려 크기가 부담 | 요청마다 저장소 왕복 |
- "검증 키만 나눠 준다"는 서명 알고리즘에 따라 다르다. HMAC(HS256 등)이면 검증 서버도 서명할 때 쓴 공유 키를 가져야 한다. RSA(RS256 등)·ECDSA(ES256 등) 서명은 개인 키로 서명하고 짝이 되는 공개 키로 검증하므로, 검증 서버에는 공개 키만 두면 된다
- 무상태 토큰을 만료 전에 막으려면 서버 쪽 차단 목록(denylist)을 조회해야 한다. 그 순간 저장소가 다시 생겨 무상태의 장점이 줄어든다
- 그래서 흔히 섞어 쓴다. 수명이 짧은 액세스 토큰은 무상태로 검증하고, 재발급에 쓰는 리프레시 토큰은 서버가 저장해 폐기·회전을 관리한다
- Auth.js는
session.strategy로'jwt'(무상태)와'database'(상태 유지)를 고른다. DB 어댑터가 없으면'jwt'가 기본이다(2026 기준)
서버 설계에서의 의미
웹 서버가 상태를 메모리에 들고 있으면 같은 사용자를 같은 서버로 보내야 해서 서버를 자유롭게 늘리고 줄이기 어렵다. 상태를 공유 저장소나 클라이언트로 빼서 웹 계층을 무상태로 만드는 것이 수평 확장과 오토스케일링의 전제다. 상태는 사라지지 않고 DB·캐시 같은 상태 유지 계층으로 모일 뿐이다.
명세: RFC 9110 §3.3 — Connections, Clients, and Servers · RFC 9110 §16.4.2 — Considerations for New Authentication Schemes · RFC 7518 §3.1 — "alg" Header Parameter Values for JWS · RFC 7518 §3.3 — RSASSA-PKCS1-v1_5 · RFC 7518 §3.4 — ECDSA