설계 원칙
정의
서버는 클라이언트의 상태를 저장하지 않는 구조
각 HTTP 요청이 서로 독립적으로 처리되며, 서버가 이전 요청의 상태 정보를 유지하지 않는 설계 방식을 의미합니다.
클라이언트는 모든 요청에 필요한 정보를 포함시켜야 하며, 서버는 이전 요청의 맥락을 기억하지 않습니다.
클라이언트는 모든 요청에 필요한 정보를 포함시켜야 하며, 서버는 이전 요청의 맥락을 기억하지 않습니다.
왜 중요할까?
확장성, 단순성, 캐싱, REST 설계의 기반
무상태성은 대규모 시스템에서 서버 간 부담을 줄이고, 요청의 자율성과 가독성을 높입니다.
또한 REST API의 핵심 조건 중 하나로, 리소스 기반의 아키텍처에 적합합니다.
또한 REST API의 핵심 조건 중 하나로, 리소스 기반의 아키텍처에 적합합니다.
특징
독립성: 요청 하나하나가 독립적이며, 요청 간 연관이 없습니다.
서버 단순화: 서버는 상태를 저장하지 않으므로 구현이 단순해집니다.
확장성 향상: 상태 정보를 유지하지 않기 때문에 수평 확장에 유리합니다.
클라이언트 책임 증가: 필요한 상태 정보는 클라이언트가 직접 포함시켜야 합니다.
장점
서버 부하 감소 및 메모리 사용 최소화
장애 복구 및 무중단 배포에 유리함
로드 밸런싱이 쉬워짐 (상태 정보가 없으므로 어느 서버에 요청해도 동일 처리 가능)
테스트 및 디버깅 용이성 증가
단점
모든 요청마다 필요한 상태 데이터를 함께 보내야 하므로 트래픽 증가 가능성 있음
로그인/세션 유지가 필요한 시스템에는 부적합 (별도 토큰 기반 인증 필요)
복잡한 사용자 흐름에서는 관리가 어려워질 수 있음
Stateless 시스템의 대표 사례들
REST API: HTTP 프로토콜의 무상태성을 기반으로 설계
클라우드 서비스: Stateless 구조로 서버 자동 확장 및 분산 처리 가능
JWT 인증: 세션을 저장하지 않고 토큰에 사용자 정보 포함
CDN/캐싱 서버: 요청 상태에 따라 다르게 처리하지 않음
728x90