Phase 1레슨 2
Client / Server
Request, Response, Stateless, Stateful — 웹의 기본 모델
💡ELI5·
Client-Server를 우체국에 비유하면
핵심 질문: 왜 Stateless가 Horizontal Scaling에 유리한가? 서버가 클라이언트 상태를 기억하지 않아도 되기 때문에, 어떤 서버든 어떤 요청이든 처리할 수 있다.
Client (브라우저) Server (API)
│ │
│── Request (편지) ──────→│
│ │ 처리
│←── Response (답장) ─────│
│ │💡 비유 — Client = 편지 보내는 사람, Server = 우체국. 편지(Request)에 목적지(URL)와 내용(Body)을 적어 보내면, 우체국이 처리하고 답장(Response)을 보내준다.
🔬Deep Dive·
Stateless vs Stateful
HTTP는 기본적으로 Stateless 프로토콜이다. 서버는 이전 요청을 기억하지 않으며, 매 요청마다 필요한 정보를 모두 보내야 한다. 이는 확장성에는 유리하지만, 로그인 상태 유지 등에는 추가 메커니즘(Cookie, JWT, Session)이 필요하다.
| 구분 | Stateless | Stateful |
|---|---|---|
| 상태 저장 | 서버에 저장 안 함 | 서버 메모리에 저장 |
| 확장성 | 용이 (어떤 서버든 처리) | 어려움 (세션 공유 필요) |
| 장애 복구 | 단순 (상태 유실 없음) | 복잡 (상태 유실) |
| 예시 | REST API, JWT | WebSocket, 게임 서버 |
💻Code·
HTTP Request/Response 예시
# Request
POST /api/orders HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOi...
{"productId": 123, "quantity": 2}
# Response
HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/orders/456
{"orderId": 456, "status": "created"}⚖️Trade-off·
Trade-off
Stateless의 장점은 확장성이지만, 매 요청마다 인증 비용이 발생하고 토큰 크기만큼 오버헤드가 있다. Stateful은 연결 유지 비용이 들지만, 한 번 인증하면 빠르다.
❓ 체크포인트 질문
- 1.Stateless가 Horizontal Scaling에 유리한 이유는?
- 2.Stateful 서버의 문제점은 무엇인가?
- 3.Client-Server 모델에서 '관심사의 분리'가 어떻게 나타나는가?
- 4.브라우저가 서버에 요청을 보낼 때 거치는 단계는?
- 5.Stateless와 Stateful 중 언제 어떤 것을 선택해야 하는가?