162. 무상태성 (Statelessness)

핵심 인사이트: 서버가 클라이언트의 이전 질문을 기억해 주는 것은 친절해 보이지만, 접속자가 수백만 명이 되면 그 '기억력(메모리)' 때문에 서버가 터져버린다. REST의 무상태성은 "매번 처음 보는 사람처럼 대하라, 대신 네가 올 때마다 모든 서류(토큰)를 완벽히 챙겨 와라"는 대규모 분산 시스템의 생존 법칙이다.

Ⅰ. 무상태성(Statelessness)의 개념

REST 아키텍처의 가장 핵심적인 제약 조건 중 하나로, 서버가 클라이언트의 작업 상태(Session, Context)를 내부에 저장하거나 유지하지 않는 속성을 말합니다. 클라이언트가 보내는 각각의 요청(Request)은 그 자체로 서버가 작업을 수행하는 데 필요한 모든 정보(인증 토큰, 파라미터 등)를 완전하게 포함하고 있어야 합니다.

Ⅱ. Stateful(상태 유지) vs Stateless(무상태) 비교

[ ❌ Stateful (상태 유지 - 옛날 방식) ]
Client: "저 1번 상품 장바구니에 담을게요."
Server: (메모리에 기록) "알겠어, 너 1번 담았구나."
Client: "그거 결제해 주세요."
Server: (기억을 더듬으며) "아까 1번 담았지? 결제 완료!"
➔ 만약 중간에 서버가 재부팅되면, 장바구니 기억이 다 날아감!

[ ✅ Stateless (무상태 - REST 방식) ]
Client: "저 1번 상품 담아요."
Server: "응, DB에 1번 담았다고 써놨어. 난 널 기억 안 해."
Client: "나 (내 아이디는 홍길동이고 장바구니에 1번 담겨있어) 이거 결제해 줘."
Server: (받은 쪽지를 읽고) "아하, 홍길동이 1번 결제하네. 결제 완료!"
➔ 서버는 기억할 필요가 없고, 클라이언트가 항상 모든 문맥을 들고 옴.

Ⅲ. 무상태성을 지켜야 하는 이유 (장점)

  1. 무한한 확장성 (Scale-Out): 특정 서버가 클라이언트의 세션(기억)을 쥐고 있지 않으므로, 트래픽이 몰릴 때 단순히 서버(L4 로드밸런서 뒤)를 100대로 늘려 아무 서버에나 요청을 던져도 완벽하게 처리됩니다.
  2. 높은 가용성 (Fault Tolerance): 요청을 처리하던 서버 A가 갑자기 죽어버려도, 클라이언트가 다시 서버 B로 똑같은 정보를 담아 요청하면 그만이므로 시스템 장애에 매우 강합니다.
  3. 서버 리소스 절약: 수백만 명의 접속자 세션을 서버 메모리에 유지할 필요가 없어 서버가 가벼워집니다.

Ⅳ. 무상태성의 단점 및 극복 방안 (JWT 토큰)

매 요청마다 자신이 누구인지 증명해야 하므로 네트워크 트래픽(페이로드)이 커지는 단점이 있습니다. 실무에서는 클라이언트가 매번 아이디/비밀번호를 보낼 수 없으므로, 로그인 시 서버가 클라이언트에게 신분증(JWT 토큰)을 발급해 주고, 클라이언트는 매 요청 헤더에 이 JWT를 담아 보내어 무상태성을 우아하게 유지합니다.

📢 섹션 요약 비유: 단골 식당 주인이 내 얼굴만 보고 "늘 먹던 걸로 줘"(Stateful) 하는 것은 편하지만 분점(Scale-out)에 가면 안 통합니다. 반면 서브웨이 샌드위치 주문은 갈 때마다 "빵은 오트, 치즈는 빼고, 소스는 스위트 칠리요"(Stateless)라고 랩을 해야 하지만, 전 세계 어느 매장을 가든 똑같은 샌드위치를 지연 없이 받을 수 있는 완벽한 시스템입니다.