2024-12-05

Stateless와 Stateful은 컴퓨터 시스템이나 네트워크에서 상태(State)를 어떻게 관리하는지를 기준으로 나누는 개념이다. 쉽게 설명하면, Stateless는 요청과 응답 간의 "연결된 상태"를 기억하지 않는 방식이고, Stateful은 그 상태를 기억하는 방식이다.

---

Stateless (상태 없음)

정의

각 요청이 독립적으로 처리되며, 이전 요청이나 응답에 대한 정보를 서버가 유지하지 않는 방식이다.

특징

독립적 요청: 클라이언트가 서버에 요청할 때마다 이전에 어떤 요청을 했는지에 대한 정보가 서버에 남지 않는다.
확장성: 서버는 클라이언트의 상태를 관리하지 않으므로 여러 서버에 요청을 분산하기 쉽다.
단순성: 서버는 각 요청을 독립적으로 처리하므로 설계가 단순하다.

예시

HTTP: 웹 브라우저와 서버 간의 통신은 기본적으로 Stateless하다. 예를 들어, 사용자가 웹 페이지를 새로 고침하면 서버는 이 사용자가 이전에 어떤 페이지를 방문했는지 모른다.
REST API: REST는 Stateless 설계를 기본으로 한다. 클라이언트는 요청마다 필요한 모든 정보를 포함해야 한다.

---

Stateful (상태 유지)

정의

요청 간의 상태를 서버가 유지하며, 이전 요청에 대한 정보를 바탕으로 현재 요청을 처리하는 방식이다.

특징

1. 연속적 상태 관리: 서버는 클라이언트의 상태 정보를 메모리에 저장하거나 데이터베이스에 기록해 두고, 이를 활용해 요청을 처리한다.
2. 복잡성 증가: 상태를 유지하기 때문에 설계가 더 복잡하고, 서버의 자원을 더 많이 소모한다.
3. 연결 의존성: 클라이언트가 이전 요청을 보낸 서버와 연결이 끊어지면, 다른 서버로 연결을 전환하기 어려울 수 있다.예시

• 온라인 게임: 게임 서버는 플레이어의 위치, 점수, 진행 상태 등을 유지해야 하므로 Stateful하다.
• 채팅 애플리케이션: 사용자가 보낸 메시지를 서버가 기억하고, 실시간으로 다른 사용자에게 전달해야 하므로 Stateful하게 동작한다.

---

장단점 비교

구분	Stateless	Stateful
장점	- 확장성 우수- 서버 부하 적음- 설계 간단	- 사용자 경험 향상- 상태 기반 기능 제공 가능
단점	- 상태 정보가 없어 클라이언트가 모든 정보를 보내야 함	- 서버 리소스 소비 많음- 확장성 저하 가능
예시 사용처	REST API, HTTP, 서버리스 컴퓨팅	온라인 게임, 채팅 앱, 비디오 스트리밍 서비스

---

언제 어떤 방식을 선택할까?

1. Stateless를 선호하는 경우:

• 대규모 시스템에서 확장성이 중요한 경우.
• 각 요청을 독립적으로 처리해야 하는 경우.
• 간단한 데이터 전송/처리가 필요한 경우.

1. Stateful이 적합한 경우:

• 사용자 맞춤형 경험이 중요한 경우(예: 쇼핑몰, 게임).
• 클라이언트의 상태 정보를 바탕으로 연속적인 처리가 필요한 경우.