Stateless vs Stateful

웹 서비스에서 상태 관리

출처: https://youtu.be/20tpk8A_xa0?si=OL8HpTFcCZ61hDzJ

웹 서비스를 개발하거나 기획하다 보면 반드시 마주하게 되는 개념이 있다.
바로 “상태(State)”이다.

우리는 일상적으로 로그인 상태를 유지하고, 장바구니를 이어서 사용하며, 결제까지 자연스럽게 이어지는 경험을 당연하게 생각한다. 하지만 이 모든 기능은 사실 웹의 기본 구조와는 반대되는 방향 위에서 구현되고 있다.

그 출발점은 HTTP의 특징인 “Stateless”에 있다.

---

웹은 왜 Stateless인가

HTTP는 기본적으로 무상태 프로토콜이다.
즉, 서버는 각 요청을 독립적으로 처리하며 이전 요청의 정보를 기억하지 않는다.

사용자가 로그인 요청을 보냈다고 해서, 이후의 상품 조회 요청이나 결제 요청에서 그 사용자를 자동으로 인식하지 않는다. 서버 입장에서는 모든 요청이 “처음 보는 요청”일 뿐이다.

이러한 구조는 단순함과 확장성이라는 큰 장점을 가진다. 서버는 특정 사용자의 상태를 기억할 필요 없이 요청이 들어올 때마다 처리만 하면 되기 때문에 시스템 구조가 단순해지고, 서버를 여러 대로 늘리는 것도 훨씬 수월해진다.

하지만 문제는 여기서 발생한다.

---

우리는 왜 상태가 필요한가

실제 서비스에서는 상태가 없다면 사용자 경험이 성립하지 않는다.

사용자는 한 번 로그인하면 계속 로그인 상태를 유지하기를 기대하고, 장바구니에 담은 상품이 사라지지 않기를 원한다. 결제 과정에서도 이전 단계의 정보가 자연스럽게 이어져야 한다.

이처럼 서비스는 “사용자의 흐름”을 유지해야 한다.
그리고 이 흐름을 가능하게 만드는 것이 바로 상태 관리이다.

즉, 웹은 Stateless하게 설계되어 있지만, 서비스는 Stateful하게 동작해야 하는 모순적인 상황에 놓여 있다.

이 간극을 해결하기 위해 등장한 것이 세션과 토큰 기반 인증이다.

---

Stateful과 Stateless의 차이

Stateful 방식은 서버가 사용자 상태를 직접 저장하고 관리하는 구조이다.
반대로 Stateless 방식은 서버가 상태를 저장하지 않고, 요청 자체에 필요한 정보를 포함시키는 구조이다.

Stateful에서는 서버가 “이 사용자는 로그인된 상태다”라는 정보를 기억하고 있어야 한다. 반면 Stateless에서는 서버가 그 정보를 기억하지 않기 때문에, 요청마다 사용자 인증 정보를 함께 보내야 한다.

이 차이는 단순한 기술 선택이 아니라, 서비스 구조와 확장성, 그리고 사용자 경험에까지 영향을 미친다.

---

세션 기반 인증: 서버가 상태를 기억하는 방식

세션 기반 인증은 가장 전통적인 상태 관리 방식이다.

사용자가 로그인을 하면 서버는 해당 사용자에 대한 세션을 생성하고, 이를 식별할 수 있는 세션 ID를 발급한다. 이 세션 ID는 보통 쿠키를 통해 클라이언트에 저장되며, 이후 요청마다 자동으로 서버에 전달된다.

서버는 이 세션 ID를 기반으로 사용자를 식별하고, 로그인 상태를 유지한다.

이 방식의 가장 큰 특징은 “상태가 서버에 있다”는 점이다.
즉, 서버가 모든 사용자 상태를 직접 관리한다.

이로 인해 보안 측면에서는 장점이 있다. 필요할 경우 특정 세션을 즉시 무효화할 수 있기 때문이다. 하지만 동시에 서버 자원을 지속적으로 사용하게 되고, 서버가 많아질 경우 세션을 공유해야 하는 문제가 발생한다.

특히 MSA 구조나 글로벌 서비스처럼 서버가 분산되는 환경에서는 세션 관리가 복잡해지고, Redis 같은 별도의 저장소를 사용하는 구조가 필요해진다.

---

토큰 기반 인증: 상태를 클라이언트에 맡기는 방식

토큰 기반 인증은 이러한 세션의 한계를 보완하기 위해 등장했다. 대표적인 방식이 JWT(JSON Web Token)이다.

사용자가 로그인을 하면 서버는 토큰을 발급하고, 클라이언트는 이 토큰을 저장한다. 이후 요청 시마다 이 토큰을 함께 전송하면 서버는 토큰을 검증하는 방식으로 사용자를 인증한다.

이 방식의 핵심은 서버가 사용자 상태를 저장하지 않는다는 점이다.
즉, 완전히 Stateless한 구조를 유지할 수 있다.

이로 인해 서버 확장성이 매우 좋아지고, 모바일 앱이나 다양한 클라이언트 환경에서도 일관된 인증 방식을 유지할 수 있다.

하지만 단점도 분명하다. 토큰이 탈취될 경우 그 자체로 인증 수단이 되기 때문에 보안 관리가 중요하며, 이미 발급된 토큰을 즉시 무효화하기 어렵다는 특징이 있다.

그래서 실무에서는 보통 Access Token과 Refresh Token을 함께 사용하는 구조를 통해 보안을 보완한다.

---

세션과 토큰, 무엇을 선택해야 할까

이 두 방식은 단순히 “어느 것이 더 좋은가”의 문제가 아니다.
서비스의 성격에 따라 선택이 달라진다.

보안이 중요한 서비스라면 서버에서 상태를 직접 통제할 수 있는 세션 방식이 더 적합할 수 있다. 반대로 사용자 수가 많고, 다양한 디바이스에서 접근하는 서비스라면 확장성이 뛰어난 토큰 기반 인증이 더 유리하다.

또한 단일 서버 구조인지, 분산 아키텍처인지에 따라서도 선택이 달라진다.

결국 중요한 것은 기술 자체가 아니라, 서비스 요구사항과 환경에 맞는 선택이다.

---

기획자 관점에서의 상태 관리

이 주제는 개발자만의 영역이 아니다.
오히려 기획자에게 더 중요한 개념이 될 수 있다.

로그인 유지 기간을 어떻게 설정할 것인지, 여러 기기에서 동시에 로그인할 수 있도록 할 것인지, 보안을 강화할 것인지 편의성을 높일 것인지 등은 모두 상태 관리 방식과 연결되어 있다.

예를 들어, 자동 로그인을 길게 유지하려면 토큰 기반 인증이 더 유리할 수 있고, 특정 상황에서 강제 로그아웃이 필요하다면 세션 방식이 더 적합할 수 있다.

또한 사용자 행동 데이터를 수집하고 분석하는 관점에서도 상태 관리 방식은 중요한 영향을 미친다. 특히 퍼스트 파티 데이터를 기반으로 서비스를 운영하는 경우, 사용자 식별과 인증 방식은 데이터 전략과도 직결된다.

---

결론

웹은 Stateless한 구조 위에서 동작하지만, 실제 서비스는 반드시 상태를 필요로 한다.
이 모순을 해결하기 위해 세션 기반 인증과 토큰 기반 인증이라는 두 가지 방식이 존재한다.

세션은 서버가 상태를 관리하는 방식이고, 토큰은 상태를 클라이언트에 위임하는 방식이다.

그리고 이 둘 중 무엇을 선택할지는 기술적인 우열이 아니라, 서비스의 목적과 구조, 그리고 사용자 경험에 따라 결정되어야 한다.

---

한 줄 정리

웹은 Stateless하게 설계되어 있지만, 사용자 경험을 위해 상태 관리가 필요하며, 이를 세션 또는 토큰 기반 인증으로 해결하고 서비스 상황에 맞게 선택하는 것이 핵심이다.