Stateless

1. Stateless

서버가 이전 요청의 상태를 기억하지 않음. 각 요청(Request)은 완전히 독립적이어야 함.

→ 즉, 서버는 이번 요청 안에 정보를 다 담아서 보내길 원함.

 

2. 예시

Stateful 방식 (옛날 방식)은

1. 로그인
2. 서버가 세션을 메모리에 저장
3. 다음 요청부터 서버는 세션을 보고 사용자 식별

하지만 이 방식은 서버가 죽으면 세션도 날아가고, 서버가 여러 대면 세션 공유 문제가 발생하며, 확장성도 떨어짐.

 

Stateless 방식은 

1. 로그인 → JWT 발급
2. 이후 모든 요청에 JWT 포함
3. 서버는 매번 토큰을 보고 사용자 검증

서버는 요청 안에 정보가 있으면 처리하고 없으면 401

즉, 서버는 기억하지 않고 요청이 자기 완결적임.

 

3. HTTP 

HTTP 프로토콜 설계 철학 자체가 Stateless임.

GET /api/users
Authorization: Bearer eyJhbGciOiJIUzI1...

이 요청 하나만 보고 판단해야 함.

 

4. 왜 웹은 Stateless를 지향할까?

(1) 확장성 (Scalability)

서버를 여러 대 띄워도 문제 없음.

Client → Load Balancer → Server1
Client → Load Balancer → Server2

어느 서버가 받아도 동일하게 처리가 가능함.

 

(2) 장애 복구 쉬움

특정 서버가 죽어도 다른 서버가 처리 가능.

 

(3) 마이크로서비스 구조에 적합

서비스 간 호출도 Statelss가 기본.

 

5. 그럼 로그인 상태는 어떻게 유지할까?

웹이 Stateless를 지향한다고 해서 상태가 아예 없다는 뜻은 아님.

상태는 클라이언트가 가지고 있음.

 

예:

• JWT
• Access Token
• Refresh Token
• 쿠키

서버는 매번 검증만 함.

 

6. 그럼에도 완전한 stateless는 불가

• DB는 상태를 가짐
• Redis 캐시 있음
• 세션 저장소 있음
• 채팅 기록 있음

stateless의 실제 의미 → 서버 프로세스가 요청 간 상태를 직접 보관하지 않음.

 

API 레벨은 꼭 Stateless로 설계.

POST /chat
body:
{
  "session_id": "...",
  "message": "..."
}

session_id를 매번 전달하면 서버는 상태를 기억할 필요가 없음.

 

7. 정리

Stateless 란

• 서버가 이전 요청을 기억하지 않음.
• 각 요청은 독립적.
• 상태는 클라이언트가 보관
• 확장성과 장애 대응에 유리