상태가 있는 시스템 vs 상태가 없는 시스템

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

웹 개발

대상자

백엔드 개발자, DevOps 엔지니어, 시스템 아키텍처

(중간~고급 수준: JWT, Redis, 세션 관리 구현 방식 포함)

핵심 요약

• 상태가 있는 시스템은 세션 정보를 유지하고 Redis 같은 외부 저장소에 데이터를 저장해야 함 (예: express-session, WebSocket)
• 상태가 없는 시스템은 JWT 토큰을 사용해 각 요청에 모든 정보를 포함하고, 수평 확장이 용이함 (예: REST API, Serverless)
• 하이브리드 접근은 실시간 채팅(상태 유지)과 인증(JWT)을 동시에 처리할 때 유리

섹션별 세부 요약

1. 상태가 있는 시스템

• 세션 정보를 메모리/Redis에 저장해야 함
• 실시간 채팅, 게임 같은 장기 상호작용에 적합
• 확장성 문제: Sticky Session 또는 외부 저장소 필요
• 예: WebSocket, Database Connection Pool
• 코드 예시:

```ts

app.use(session({

store: new RedisStore({ client: redisClient }),

secret: process.env.SESSION_SECRET

}));

```

2. 상태가 없는 시스템

• 요청마다 JWT 토큰을 포함해야 함
• 수평 확장 가능, 클라우드 네이티브 아키텍처에 적합
• 예: REST API, AWS Lambda
• 코드 예시:

```ts

@Injectable()

class JwtAuthGuard extends AuthGuard('jwt') {}

```

3. 실무 예시 및 비교

• JWT

- 장점: 수평 확장, 클라이언트 제어 가능

- 단점: 로그아웃 처리 어려움

• 세션 + 쿠키

- 장점: 세션 데이터 서버 제어, 로그아웃 용이

- 단점: 확장성 제한 (Redis 필요)

• 하이브리드 모델

- 채팅 기록은 Redis에 저장, 인증은 JWT 사용

결론

• API/SPA 시스템: JWT 사용 (상태 없음)
• SSR 앱/내부 도구: 세션 + 쿠키 (상태 있음)
• 실시간 기능: 하이브리드 모델 (Redis + JWT) 사용

> 상태 관리 방식을 선택할 때는 확장성, 보안, 인증 복잡도를 종합적으로 고려해야 함.