Stateless vs Stateful: 차이를 한 번에 파악하자

발행: (2026년 3월 9일 PM 12:10 GMT+9)
5 분 소요
원문: Dev.to

Source: Dev.to

애플리케이션 백엔드를 설계할 때 Stateful 또는 Stateless 아키텍처 중 하나를 선택하는 것은 가장 근본적인 결정 중 하나입니다. 이 선택은 시스템이 어떻게 확장되고 인증을 어떻게 처리하는지에 직접적인 영향을 미칩니다.

Stateful

Analogia

매일 같은 카페에 가는 상황을 상상해 보세요. 도착하면 직원이 이미 미소를 지으며 말합니다:
“좋은 아침이에요, 오타비오! 언제나와 같은 걸 원하시나요?”

직원은 당신의 이름과 좋아하는 주문을 기억하고 있기 때문에, “하나 더 주세요”라고만 말해도 정확히 무엇을 준비해야 할지 알 수 있습니다. 이는 상태가 상호작용 사이에 유지되기 때문입니다.

Conceito

서버가 사용자와 “대화”를 지속적으로 유지하면서 세션 정보를 자체 메모리(RAM) 또는 임시 데이터베이스에 저장합니다.

Exemplo prático

PHP, Java(HttpSession) 또는 ASP.NET의 전통적인 세션처럼, 사용자가 로그인한 동안 서버가 사용자 데이터를 보관합니다.

Prós e contras

  • Prós: 직관적이며 작은 애플리케이션(모놀리트)에서 관리하기 쉽다.
  • Contras: 수평 확장이 어렵고, Sticky Sessions와 같은 전략이나 외부 저장소(예: Redis)가 필요해 여러 인스턴스가 상태를 공유하도록 해야 한다.

Exemplo de código (.NET)

// O servidor guarda o nome na sessão (estado mantido na RAM do servidor)
HttpContext.Session.SetString("UsuarioNome", "Otávio");

// Para recuperar, o servidor busca na própria memória:
var nome = HttpContext.Session.GetString("UsuarioNome");

Stateless

Analogia

이제 셀프 서비스 카페를 떠올려 보세요. 도착해서 이름과 커피 종류를 알려주면 음료를 받고 직원은 바로 당신을 잊어버립니다. 또 다른 커피를 원한다면 모든 정보를 다시 제공해야 합니다.

Conceito

서버는 클라이언트에 대한 정보를 요청 사이에 전혀 저장하지 않는다. 작업을 처리하는 데 필요한 모든 정보는 요청 자체(보통 헤더)에 포함되어야 합니다.

Exemplo prático

현대적인 REST API와 JWT(JSON Web Token)를 이용한 인증.

Prós e contras

  • Prós: 확장성이 매우 뛰어나며 마이크로서비스와 클라우드 환경에 최적화되어 있다.
  • Contras: 각 요청에 인증 데이터(토큰)를 포함해야 하므로 약간 더 “무거워질” 수 있다.

Exemplo de código (Spring Boot)

@GetMapping("/perfil")
public ResponseEntity getPerfil(@RequestHeader("Authorization") String token) {
    // O servidor é "frio": não mantém lista de usuários logados na RAM.
    // Decodifica o JWT enviado pelo cliente para identificar o usuário.

    if (token != null && token.startsWith("Bearer ")) {
        String jwt = token.substring(7);
        String username = jwtService.extractUsername(jwt); // extrai o "sub" do payload

        return ResponseEntity.ok("Usuário identificado via Token: " + username);
    }

    return ResponseEntity.status(HttpStatus.UNAUTHORIZED).build();
}

Comparação

CaracterísticaStatefulStateless
Armazenamento서버 (메모리/RAM)클라이언트 (토큰/쿠키)
Escalabilidade어려움 (Sticky Sessions 또는 외부 저장소 필요)쉬움 (클라우드 및 마이크로서비스 중심)
Exemplo realPHP 세션, 오래된 장바구니REST API, JWT, OAuth2
Conexão대화 기록 유지각 요청은 새로운 대화

Conclusão

현대 웹 개발의 황금 규칙은 Stateless를 우선하는 것이다. AWS, Azure, Google Cloud와 같은 환경이나 Docker/Kubernetes를 사용할 때, Stateless 모델은 세션 손실에 대한 걱정 없이 10에서 100개의 인스턴스로 확장할 수 있다.

Stateful는 레거시 시스템이나 특정 모놀리트에서 여전히 사용될 수 있지만, 대부분의 애플리케이션 현재와 미래는 Stateless이다.

0 조회
Back to Blog

관련 글

더 보기 »

주간 챌린지 #2 : ME를 챌린지로 만들기

미션 다음에 내가 완료해야 할 프론트‑엔드 챌린지를 생각해 내라. 그것은 다음과 같을 수 있다: - 이상한 - 영리한 - 저주받은 - 매우 간단한 - 혹은 “누가 이런 걸 할까…”