이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- Sticky Session, Session Store, Token 방식은 각각 어떤 전환 상황에 적합한가?
- 세션 전략 선택은 배포, 장애, 보안, 비용을 어떻게 바꾸는가?
- 기존 메모리 세션 서비스를 어떤 단계로 더 안전한 구조로 옮길 수 있는가?
선택 문서의 초점
이 문서는 세션을 외부화해야 한다는 원칙을 다시 설명하지 않는다.
이미 로컬 세션이 한계에 닿았을 때 Sticky Session, Session Store, Token 중 무엇을 어떤 순서로 선택할지 판단한다.
예시는 단일 서버 쇼핑몰을 다중 인스턴스로 전환하는 상황이다.
기존 코드는 서버 메모리 세션에 로그인 정보와 장바구니 일부를 저장한다.
이때 가장 빠른 선택은 sticky session이지만, 장기적으로는 배포와 장애 때 세션 유실 문제가 남을 수 있다.
선택은 기술 취향이 아니라 사용자 영향과 운영 감당 능력으로 결정한다.
이 문서가 바꾸는 설계 축
| 축 | Sticky Session | Session Store | Token |
|---|---|---|---|
| 성능 | 로컬 접근이라 빠르지만 부하 불균형 가능 | 저장소 왕복이 추가됨 | 매 요청 저장소 조회를 줄일 수 있음 |
| 정합성 | 인스턴스별 세션이 갈라질 수 있음 | 중앙 기준으로 만료와 삭제 가능 | 만료 전 권한 변경 반영이 어려움 |
| 장애 격리 | 인스턴스 장애가 해당 사용자 세션 유실 | store 장애가 인증 경로 장애가 됨 | token 탈취와 revoke가 별도 문제 |
| 운영 복잡도 | LB cookie와 drain 관리 | Redis/DB 용량, failover, TTL 관리 | rotation, refresh, blacklist 관리 |
같은 로그인 기능이라도 요구하는 보안 수준, 배포 빈도, 장애 허용 범위에 따라 답이 달라진다.
선택 전 질문
먼저 다음 질문에 답한다.
- 배포 중 일부 사용자가 로그아웃되어도 되는가?
- 권한 변경이나 계정 정지가 즉시 반영되어야 하는가?
- 다중 기기 세션을 관리해야 하는가?
- multi-AZ 또는 multi-region failover에서 로그인 상태를 유지해야 하는가?
- 장바구니, 2FA, 결제 draft가 세션 안에 있는가?
- 인증 저장소 장애 때 전체 API를 막을 것인가, 일부 공개 기능은 유지할 것인가?
질문에 답하지 않으면 token이 좋아 보이거나 Redis가 좋아 보이는 식의 기술 이름 논쟁이 된다.
Sticky Session이 맞는 경우
Sticky Session은 기존 구조를 크게 바꾸지 않고 서버를 여러 대로 늘리는 임시 완화책이다.
적합한 조건은 다음과 같다.
| 조건 | 이유 |
|---|---|
| 세션 유실 비용이 낮다 | 인스턴스 장애 때 재로그인이 허용된다. |
| 배포 빈도가 낮다 | drain과 세션 유실 관리 부담이 작다. |
| 전환 기간이 짧다 | 장기 구조로 굳어질 위험을 줄인다. |
| 세션에 비즈니스 draft가 없다 | 장바구니나 결제 상태 유실 비용이 작다. |
Sticky는 나쁜 기술이 아니라 상태 위치 문제를 당장 크게 바꾸지 않는 선택이다.
그래서 반드시 종료 조건이 있어야 한다.
Sticky 운영 조건
Sticky를 쓴다면 load balancer 설정과 배포 절차를 같이 설계한다.
load_balancer:
route_cookie: APP_ROUTE
cookie_ttl: 30m
connection_draining: 120s
scale_in_policy: low_traffic_onlycookie TTL, drain 시간, scale-in 기준이 맞지 않으면 사용자는 죽은 route를 계속 시도하거나 배포 중 로그아웃될 수 있다.
운영 문서에는 허용할 로그아웃 범위와 store 전환 조건을 함께 남긴다.
Session Store가 맞는 경우
Session Store는 인스턴스 독립성을 높인다.
적합한 조건은 다음과 같다.
- rolling deploy가 잦다.
- 인스턴스 장애 때 로그인 상태를 유지해야 한다.
- 강제 로그아웃과 계정 정지 반영이 필요하다.
- 다중 기기 세션 목록을 관리해야 한다.
- 장바구니나 2FA 상태처럼 유실 비용이 있는 상태가 있다.
대신 store는 인증 경로의 핵심 의존성이 된다.
authenticated_qps = 4,000
session_read_per_request = 1
session_write_ratio = 0.05
redis_read_qps = 4,000
redis_write_qps = 200이 계산은 Redis가 단순 cache가 아니라 인증 write/read 경로라는 점을 보여준다.
store 장애 때 공개 API와 인증 API를 분리할 수 있는지도 봐야 한다.
Token 방식이 맞는 경우
Token 방식은 매 요청 중앙 저장소 조회를 줄이고 API 서버를 가볍게 만들 수 있다.
적합한 조건은 다음과 같다.
| 조건 | 설명 |
|---|---|
| 짧은 access token TTL을 허용 | 권한 변경 지연을 TTL 안으로 제한한다. |
| refresh token 저장소를 운영 가능 | 탈취 대응과 회전이 필요하다. |
| 즉시 revoke 요구가 낮음 | 강제 로그아웃이 많지 않다. |
| gateway 검증이 중요 | 여러 서비스 앞에서 공통 인증을 처리한다. |
JWT를 쓰더라도 refresh token, revoke list, device session을 저장하면 서버 측 상태가 다시 생긴다.
token은 session store의 반대말이 아니라 저장 위치와 검증 비용을 다르게 나누는 방식이다.
전환 경로
기존 메모리 세션 서비스는 다음 순서로 옮긴다.
1. 세션 안의 값 목록을 만든다.
2. 비즈니스 draft를 DB나 별도 store로 분리한다.
3. 로그인 principal을 최소화한다.
4. sticky로 단기 scale-out을 막을지 판단한다.
5. session store 또는 token 구조를 선택한다.
6. old/new cookie와 세션 format 호환성을 검증한다.
7. 배포 중 로그아웃률과 인증 오류율을 본다.세션 안의 모든 값을 한 번에 옮기지 않는다. 장바구니, 2FA, password reset, checkout draft는 로그인 세션과 수명이 다르다.
장애 응답과 사용자 경험
전략마다 장애 응답이 다르다.
401 Unauthorized
{
"code": "SESSION_EXPIRED",
"action": "LOGIN_REQUIRED"
}503 Service Unavailable
{
"code": "AUTH_STORE_UNAVAILABLE",
"action": "TRY_AGAIN"
}정상 만료, sticky route 유실, session store 장애, token revoke는 서로 다른 사건이다. 사용자 메시지는 단순해야 하지만 운영 metric은 원인별로 나뉘어야 한다.
보안 판단
세션 전략은 보안 요구와 함께 결정한다.
- 즉시 계정 정지가 필요하면 중앙 상태가 필요하다.
- access token TTL이 길면 탈취 피해 시간이 길어진다.
- refresh token rotation은 저장소와 재사용 감지가 필요하다.
- cookie 기반이면
HttpOnly,Secure,SameSite정책을 정해야 한다. - multi-device logout은 device session 목록이 있어야 한다.
성능만 보고 token을 고르면 revoke와 사고 대응이 비고, 보안만 보고 매 요청 store 조회를 강제하면 latency와 store 장애 영향이 커진다.
운영 지표
세션 전략 변경 후에는 다음 지표를 본다.
- login success rate
- logout 또는 forced logout count
- unauthorized rate by reason
- session store p95 latency
- Redis eviction과 failover count
- token refresh failure rate
- route cookie mismatch count
- deploy 중 재로그인 문의 수
HTTP 401 개수만 보면 부족하다. 만료, 사용자 로그아웃, store 장애, 배포 중 세션 유실을 나눠야 한다.
개인 프로젝트 기준
- 현재 세션 방식이 sticky, store, token 중 무엇인지 명시한다.
- 배포 때 사용자가 로그아웃되어도 되는지 적는다.
- JWT를 쓰면 refresh token과 logout 정책을 함께 적는다.
- Redis를 쓰면 장애 시 로그인 API와 공개 API의 동작을 나눈다.
- 세션에 들어간 비즈니스 draft를 목록화한다.
기업 운영 기준
- 세션 전략 변경은 migration plan, cookie 전환, rollback 조건을 포함한다.
- session store는 인증 SLO, failover test, capacity review 대상이다.
- token 방식은 rotation, revoke, device 관리 정책과 함께 승인한다.
- sticky session은 drain, scale-in, multi-AZ 장애 전환 runbook과 묶어 관리한다.
- 고객센터가 정상 만료와 장애성 로그아웃을 구분할 수 있어야 한다.
위험 신호
- sticky session을 장기 구조로 쓰면서 종료 조건이 없다.
- session store를 cache처럼 보고 eviction 정책만 둔다.
- JWT를 쓰면서 강제 로그아웃 요구사항을 무시한다.
- 세션 안에 장바구니, 2FA, 결제 draft가 섞여 있다.
- 배포 중 old/new cookie나 serialization 호환성을 검증하지 않는다.
- 인증 장애가 공개 조회 API까지 모두 막는다.
확인 질문
확인 질문
- 확인 질문: Sticky Session을 선택해도 되는 조건은 무엇인가?
- 답변: 세션 유실 비용이 낮고 전환 기간이 짧으며, 배포와 scale-in 중 사용자 영향을 허용할 수 있을 때다.
- 확인 질문: Session Store를 cache와 다르게 봐야 하는 이유는 무엇인가?
- 답변: store 장애가 인증 경로와 사용자 로그인 상태를 직접 바꾸므로 핵심 의존성으로 운영해야 하기 때문이다.
- 확인 질문: Token 방식 선택 전에 반드시 확인할 것은 무엇인가?
- 답변: access token TTL, refresh token 저장, revoke, 권한 변경 반영, 탈취 대응 요구사항이다.