Stateless하게 개발하기

Stateless하게 개발한다는 것은 무엇을 의미할까? HTTP는 무상태(stateless)라고 하고, 아키텍처에서도 stateless라는 말이 자주 등장한다. 처음에는 이 개념이 잘 이해되지 않았다. 왜냐하면 상태를 가진다는 것은 결국 어딘가에 데이터가 저장된다는 의미이기 때문이다. 그렇다면 DB나 Redis 같은 저장소를 사용하는 순간 stateless하지 않은 것이 아닌가라는 생각이 들었다. 하지만 이는 잘못된 이해였다. Stateless의 기준은 인프라 전체가 아니라 서버이다. DB나 Redis를 사용하는 것은 상태를 없애는 것이 아니라, 서버 외부로 분리하는 것이다. 즉, stateless하게 개발한다는 것은 서버가 데이터를 전혀 저장하지 않는다는 의미가 아니라, 서버가 이전 요청의 상태를 기억하지 않도록 만드는 것이다. 각 요청은 독립적으로 처리되어야 하며, 서버는 이전 요청이 무엇이었는지 알 필요가 없다. 필요한 상태는 요청에 포함되거나, DB나 Redis와 같은 외부 저장소에서 조회한다. 결국 stateless 아키텍처란 상태를 제거하는 것이 아니라, 상태를 서버 밖으로 이동시키는 설계 방식이라고 볼 수 있다.

Stateless하게 개발한다는것은 무슨말일까?

Stateless하게 개발한다는 것은 무엇을 의미할까?
Stateless하게 개발한다는 것은 서버가 이전 요청을 기억하지 않도록 만드는 것이다.
간단하게 말하면 stateless는 '상태 없음'으로 보이지만, 실제로는 서버가 상태를 가지고 있지 않다는 의미에 가깝다.

그렇다면 stateful하다는 것은 무엇일까? 상태를 저장한다는 의미를 가지고 있는데, 다음의 예시를 보자.
사용자의 로그인 여부를 확인해야 하는 상황을 생각해보면, stateful 구조에서는 서버가 사용자 세션을 메모리에 저장한다.
이 경우 해당 사용자의 이후 요청은 같은 서버로 전달되어야 한다.
왜냐하면 상태가 특정 서버에 있기 때문이다. 따라서 서버가 죽으면 세션 정보도 함께 사라지게 된다.

반대로 stateless 구조에서는 서버가 "나는 아무것도 기억하지 않는다. 필요한 정보를 요청에 담아달라"고 가정한다.
요청마다 토큰이나 사용자 ID가 포함되고, 필요한 정보가 있다면 DB나 Redis 같은 외부 저장소에서 조회한다. 즉, 특정 서버에 상태가 묶이지 않기 때문에 어떤 서버든 동일하게 요청을 처리할 수 있다. 결국 stateless 아키텍처란 상태를 없애는 것이 아니라, 상태를 서버 외부로 분리하는 방식이라고 볼 수 있다.

이것을 확실하게 보여줄수있는 예시가 바로 세션 로그인과 JWT로그인이다.

그렇다고 해서 Staless가 마냥좋고 Stateful이 마냥 나쁜것은 아니다.

Stateless를 하게 되면 어떤 점을 신경을 써야 하는지 알아보자.

Statless 구조는 서버가 상태를 가지지 않기 때문에 확장성과 유연성 측면에서 큰 장점을 가진다.
하지만 상태를 외부로 분리한 만큼 이로 인해 새롬게 고려해야 할 문제들도 생기게 된다.

첫 번째는 네트워크 비용 증가이다.
Stateless 환경에서는 요청마다 필요한 정보를 모두 포함해야 한다.
예를 들어, JWT를 사용하는 경우, 매 요청마다 토큰이 함께 전달된다. 또한 필요한 데이터를 조회하기 위해 DB나 Redis와 같은 외부 저장소를 호출해야 한다. 이로 인해 네트워크 트래픽이 증가할 수 있다.

두 번째는 데이터 일관성 문제이다.
상태가 여러 저장소에 분산되면서 데이터가 즉시 반영되지 않을 수 있다. 특히 분산 캐시나 복제된 데이터베이스를 사용하는 경우, 어느 시점에서는 다른 데이터를 바라보는 상황이 발생할 수 있다. 이를 궁극적 일관성이라고 한다.

세 번째는 멱등성이다.
Stateless 환경에서는 동일한 요청이 여러 번 들어올 수 있다. 예를 들어 네트워크 문제로 인해 요청이 재시도되는 경우, 같은 요청이 중복 실행이 될 수 있다. 이때 요청을 여러 번 처리하더라도 결과가 동일하게 설계해야 한다.

 네 번째는 보안 문제이다.
JWT와 같은 토큰 기반 인증을 사용할 경우, 토큰이 탈취되면, 만료 전까지는 계속 사용할 수 있다. 
세션 기반 방식처럼 서버에서 즉시 무효화하기 어렵기 때문에 토큰의 만료 시간이나 재발급 전략을 신중하게 설계해야 한다.

마지막으로 운영 복잡성 증가이다.
서버는 단순하지만, 대신 DB, Redis, 메시지 큐 등 여러 외부 시스템을 함께 운영해야 한다. 이로 인해 전체 시스템의 복잡도가 증가하고 문제 발생 시 디버깅 난이도가 높아질 수 있다. 

출처
https://blog.bytebytego.com/p/stateless-architecture-benefits-and