476. 세션 (Session) - 서버 측 상태 저장 값 (SID 발급)

핵심 인사이트 (3줄 요약)

본질: 세션(Session)은 클라이언트를 식별할 수 있는 중요 정보(로그인 상태 등)를 쿠키(클라이언트)에 맡기지 않고, 서버의 메모리나 외부 저장소(Redis 등)에 보관한 뒤 클라이언트에게는 그 키(Key) 값인 세션 ID(SID)만 발급하는 상태 관리 아키텍처다.

가치: 클라이언트가 데이터를 임의로 위변조하는 것을 원천 차단하여 결제, 인가(Authorization) 등 무결성이 필수적인 비즈니스 로직을 안전하게 수행할 수 있게 한다.

융합: 서버에 상태(State)가 귀속되므로 서버 증설(Scale-out) 시 사용자가 다른 서버로 라우팅되면 로그인이 풀리는 치명적 단점이 있으며, 이를 해결하기 위해 로드밸런서의 Sticky Session이나 분산 인메모리 DB(Session Clustering) 아키텍처가 필수적으로 요구된다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 세션(Session)은 웹 환경에서 사용자가 웹 브라우저를 열어 서버에 접속한 시점부터, 로그아웃하거나 브라우저를 닫을 때까지의 논리적인 연결 상태와 그 유지 기간을 의미한다. 기술적으로는 서버 측(Server-side)에 상태 정보(Key-Value 형태)를 저장해두고, 클라이언트에게는 이 저장소의 열쇠인 세션 ID (Session ID, SID)를 교부하여 서로를 추적하는 메커니즘이다.
필요성: 쿠키(Cookie)만으로 상태를 유지할 경우 치명적인 결함이 있다. 첫째, 클라이언트 로컬에 데이터가 저장되므로 사용자가 개발자 도구를 열어 정보를 조작(예: isAdmin=true, price=100)할 수 있다. 둘째, 브라우저가 매번 무거운 데이터를 통신에 실어 보내므로 트래픽 낭비가 심하다. 민감한 정보(비밀번호, 권한 레벨)와 무거운 데이터는 서버라는 안전한 금고 안에 은닉하고, 클라이언트에게는 "무의미한 난수표(열쇠)"만 쥐여주어 보안과 경량화를 동시에 획득해야 했다.
💡 비유: 목욕탕의 보관함 시스템과 같습니다. 목욕탕(서버)은 손님의 비싼 지갑과 옷(중요 상태 정보)을 안전한 락커(세션 저장소)에 넣고 굳게 잠급니다. 그리고 손님(클라이언트)에게는 플라스틱 번호표 열쇠(세션 ID) 하나만 줍니다. 손님은 목욕하는 내내(연결 기간) 무거운 짐을 들고 다니지 않고 가벼운 열쇠만 손목에 차면 되며, 절대 남의 락커를 함부로 열 수 없습니다.
등장 배경:
1. 쿠키 위변조 사고의 속출: 초기 웹 상거래에서 상품 가격이나 사용자 등급을 쿠키에 저장했다가 대규모 위변조(Spoofing) 해킹 사고가 일어났다.
2. 서버 측 메모리 집중화: 중요 로직을 서버로 끌어오면서, 자바 서블릿(Java Servlet)의 HttpSession 등 프레임워크 차원의 메모리 기반 세션 관리 기술이 표준화되었다.
3. 분산 아키텍처의 도래: 한 대의 서버 메모리에서 세션을 관리하다가, 트래픽 폭증으로 서버가 수십 대로 스케일아웃(Scale-out)하면서 서버 간 세션을 공유해야 하는 세션 클러스터링(Session Clustering) 아키텍처가 발전했다.

┌─────────────────────────────────────────────────────────────┐
│                세션(Session) 동작 메커니즘 흐름도               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ [Client / Browser]                           [Web Server]   │
│         │                                         │         │
│         │ 1. POST /login (ID: user, PW: 123)      │         │
│         │────────────────────────────────────────▶│         │
│         │                             [서버 메모리(세션 저장소)] │
│         │                             ➔ 회원 인증 완료        │
│         │                             ➔ 임의의 난수 생성:       │
│         │                                "SID=xyz987"     │
│         │                             ➔ 매핑: "xyz987" = user │
│         │ 2. 200 OK                               │         │
│   ┌─────│    Set-Cookie: session_id=xyz987        │         │
│저장│     │◀────────────────────────────────────────│         │
│   │     │                                         │         │
│   └────▶│ (이후 페이지 이동 시)                         │         │
│         │                                         │         │
│         │ 3. GET /my_profile                      │         │
│         │    Cookie: session_id=xyz987            │         │
│         │────────────────────────────────────────▶│         │
│         │                             [서버 메모리 검색]        │
│         │                             ➔ "xyz987" 이 누구지?   │
│         │                             ➔ 아, user 구나!      │
│         │ 4. 200 OK (user의 개인정보 화면)             │         │
│         │◀────────────────────────────────────────│         │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 세션 메커니즘의 본질은 클라이언트와 서버의 역할 분담이다. 보안 검증(인증)을 통과하면, 서버는 64바이트 이상의 복잡한 무작위 난수 문자열(session_id=xyz987)을 찍어낸다. 그리고 서버 내부의 거대한 딕셔너리(해시맵)에 {"xyz987": "관리자권한, 접속시간..."}을 기록한다. 브라우저로 내려가는 것은 오직 껍데기(난수 문자열)뿐이다. 해커가 통신을 훔쳐보더라도 알 수 없는 난수표일 뿐이며, 조작(예: session_id=admin123)하려 해도 서버의 해시맵에 그런 키가 없으면 접근이 거부된다. 즉, 상태를 유지하기 위해 쿠키라는 '배달원'을 쓰되, 중요한 알맹이(State)는 서버에 귀속시키는 방어 체계다.

📢 섹션 요약 비유: 클라이언트에게 진짜 금괴(상태 데이터)를 쥐여주는 대신, 스위스 은행의 개인 금고 열쇠(세션 ID)만 쥐여주어, 도둑이 열쇠를 복사하려 해도 본인 검증을 통과하지 못하면 은행이 금고를 열어주지 않는 철벽 방어 시스템과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

세션 아키텍처 비교: 쿠키 방식과의 본질적 차이

기준	쿠키(Cookie) 위주 아키텍처	세션(Session) 위주 아키텍처
데이터 저장 위치	클라이언트 (브라우저 디스크/메모리)	서버 (메모리, DB, Redis)
보안성 (위변조 방어)	낮음 (네트워크 스니핑 및 조작에 취약)	매우 높음 (의미 없는 난수표 SID만 전송)
통신 페이로드 부하	높음 (저장된 모든 데이터가 매번 전송됨)	낮음 (SID 하나만 가볍게 전송됨)
서버 자원(RAM) 소모	낮음 (서버는 기억할 필요가 없음)	높음 (동시 접속자 수가 많을수록 메모리 터짐)
스케일 아웃 (확장성)	자유로움 (무상태성 유지)	어려움 (서버 간 세션 동기화 로직 필수)
만료 제어권	클라이언트 브라우저 설정에 의존	서버가 통제 (즉시 파기, 타임아웃 강제 가능)

스케일 아웃(Scale-out) 시 발생하는 세션 불일치 문제

현대의 웹 아키텍처는 한 대의 웹 서버(WAS)로 버틸 수 없어 수십 대의 서버를 로드밸런서(L4/L7) 뒤에 병렬로 둔다. 이 분산 환경에서 세션을 어떻게 처리하느냐가 벡엔드 엔지니어링의 핵심 과제다.

초기처럼 세션을 "서버 1번의 램(RAM)"에만 저장해 두면 치명적인 버그가 발생한다. 사용자가 첫 요청에서 로그인하여 1번 서버 램에 세션을 만들었다. 하지만 다음 클릭 때 로드밸런서가 트래픽 분산을 위해 사용자의 요청을 2번 서버로 보내버리면(Round Robin), 2번 서버의 램에는 사용자의 세션 정보가 없으므로 "너 누구야? 다시 로그인해!"라며 튕겨버리는 **세션 불일치(Session Inconsistency)**가 발생한다.

┌─────────────────────────────────────────────────────────────┐
│          분산 서버 환경에서의 세션 아키텍처 3가지 해결책          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ [문제 상황] 로드밸런서(LB)가 트래픽을 분산시키면 로그인이 풀린다!      │
│                                                             │
│ [해결책 1: Sticky Session (스티키 세션)]                        │
│                                                             │
│   Client A ──(항상)──▶ [ WAS 1 ] (A의 세션 보관)              │
│   Client B ──(항상)──▶ [ WAS 2 ] (B의 세션 보관)              │
│  ➔ 로드밸런서가 쿠키를 보고, A는 죽을 때까지 WAS 1번으로만 꽂아준다.   │
│  ⚠️ 단점: 트래픽 쏠림 발생. WAS 1이 죽으면 A는 영원히 로그아웃됨.      │
│                                                             │
│ [해결책 2: Session Clustering (톰캣 세션 복제)]                 │
│                                                             │
│   Client ────▶ [ WAS 1 ] ◀─(세션 데이터 100% 복제)─▶ [ WAS 2 ] │
│  ➔ WAS 1에 세션이 생기면, 내부망 멀티캐스트로 WAS 2에도 똑같이 복사.  │
│  ⚠️ 단점: 서버가 10대, 100대 늘어나면 복제 트래픽 폭주로 네트워크 마비. │
│                                                             │
│ [해결책 3: External Session Store (외부 분산 DB - Redis 등)]    │
│  🌟 현대 아키텍처의 표준                                        │
│                                                             │
│   Client ────▶ [ WAS 1 ] ──┐                                │
│   Client ────▶ [ WAS 2 ] ──┼─▶ [ 🚀 거대한 Redis 메모리 DB ]  │
│   Client ────▶ [ WAS 3 ] ──┘   (모든 세션을 중앙 집중형으로 캐싱)  │
│  ➔ 서버들은 자기를 Stateless로 비우고, 상태는 전부 Redis에 위임!     │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 분산 아키텍처에서 상태(State)를 유지하는 것은 서버의 수평 확장(Scale-out)을 가로막는 가장 큰 장애물이다. '스티키 세션'은 로드밸런서가 클라이언트 IP나 라우팅 쿠키를 씹어보고 한놈만 패는 방식으로 가용성(서버 다운 시 장애)과 로드밸런싱 효율이 떨어진다. '세션 클러스터링'은 노드 간 풀 메시(Full-mesh) 동기화를 유발하여 서버가 늘어날수록 급격히 느려진다. 결국 현대의 대규모 클라우드 아키텍처는 3번째 방식인 외부 인메모리 저장소(Redis, Memcached 등) 아키텍처로 수렴했다. 웹 서버(WAS)들의 RAM에서는 상태를 싹 다 빼버려(Stateless화) 마음대로 서버를 죽이고 살리게 만들고, 1초에 수십만 건을 처리하는 Redis 클러스터가 세션의 전역 저장소 역할을 전담하는 분업화다.

📢 섹션 요약 비유: 은행 지점(서버)이 여러 개일 때, 내가 통장을 만든 지점(Sticky Session)에만 가야 돈을 찾을 수 있다면 너무 불편합니다. 본사의 거대한 중앙 전산망(Redis)에 내 정보를 다 모아두면, 전국 어느 지점(WAS 1, 2, 3)을 가든 똑같이 신분증(SID)을 내밀고 돈을 찾을 수 있는 것과 같습니다.

Ⅲ. 융합 비교 및 다각도 분석

비교 1: Session 기반 인증 vs JWT(JSON Web Token) 기반 인증

세션을 외부 저장소(Redis)로 뺐음에도 불구하고, "결국 백엔드가 어딘가에 상태(State)를 쌓아둬야 하고, 매 요청마다 디비(Redis)를 한 번씩 찔러봐야 한다"는 아키텍처의 근본적 무거움은 피할 수 없었다. 이 무거움을 아예 박살내기 위해 등장한 것이 토큰(Token) 기반 아키텍처, 즉 JWT다.

항목	Session 기반 아키텍처	JWT 기반 아키텍처
상태 저장 위치 (State)	서버 측 (Redis, DB, Memory)	클라이언트 측 (쿠키, 로컬스토리지 등)
서버의 부담	매 요청마다 SID로 Redis를 조회해야 함 (부하 발생)	토큰에 찍힌 암호화된 '서명'만 CPU로 뜯어보면 끝남 (DB 조회 0)
세션 통제력 (강제 로그아웃)	완벽함. 어뷰저 발견 시 서버의 Redis에서 그 줄만 삭제하면 즉각 쫓겨남.	불가능. 한 번 발급된 토큰은 유효기간 전까지 서버가 중간에 뺏을 수 없음. (Refresh 토큰 등 보완책 필요)
페이로드 크기	가벼움 (예: `xyz123` 32바이트)	무거움 (사용자 권한, 만료시간 등이 암호화되어 있어 수백 바이트~킬로바이트)
어울리는 서비스	금융, 결제, 넷플릭스(동시접속 차단 등) - 통제력이 생명인 곳	마이크로서비스(MSA), 무한 스케일아웃이 필요한 대규모 B2C 서비스

최근 아키텍처는 Session과 JWT 중 양자택일을 하는 것이 아니라, 강력한 통제가 필요한 코어 뱅킹(결제) 도메인은 Redis 세션을 유지하고, 인증을 가볍게 뿌려야 하는 게이트웨이나 퍼블릭 API 도메인은 JWT를 활용하는 하이브리드 형태로 진화하고 있다.

과목 융합 관점

데이터베이스 (DB): 세션 스토리지를 RDBMS(MySQL) 등에 저장하는 것은 최악의 안티패턴이다. 1초에 수천 번 발생하는 SELECT/UPDATE 트랜잭션을 디스크 기반 DB가 버틸 수 없다. 세션 저장은 철저히 Key-Value 형태의 인메모리(In-Memory) NoSQL인 Redis가 담당하는 것이 표준 설계다.
보안 (Security): 세션 하이재킹(Session Hijacking)은 해커가 XSS나 스니핑으로 피해자의 세션 ID 쿠키를 훔쳐, 자기 브라우저에 박아 넣고 피해자 행세를 하는 해킹이다. 서버는 쿠키값(SID)만 보고 사람을 판단하므로 깜빡 속아 넘어간다. 이를 막으려면 쿠키에 HttpOnly, Secure를 걸고, 서버 측에서는 요청하는 IP가 갑자기 훅 바뀌거나 User-Agent(브라우저 정보)가 바뀌면 즉각 세션을 파기해버리는 다차원 검증 방어 로직이 필요하다.
📢 섹션 요약 비유: 세션(Session) 방식이 호텔 프론트에 신분증을 맡기고 얼굴 대조를 철저히 거쳐 들어가는 '철통 보완 시스템'이라면, JWT 방식은 한 번 1주일짜리 VIP 출입증을 끊어주면 그 사람이 범죄를 저질러도 1주일 동안은 막을 방법이 없는 '초고속 게이트 프리패스'입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 동시 접속자 제한 (Duplicate Login Prevention) 기능 구현: 넷플릭스나 유료 인강 서비스에서 "한 계정당 기기 1대만 시청 가능"이라는 비즈니스 룰을 구현해야 한다.
- 판단: JWT 토큰 방식으로는 이 로직을 100% 실시간으로 구현하기 불가능하다(클라이언트에 토큰이 가 있고 서버는 상태를 모르기 때문). 반드시 **서버 기반 세션 아키텍처(Redis)**를 채택해야 한다. 로그인 시 Redis에 [UserId] : [SessionId] 쌍을 기록하고, 동일한 UserId로 새로운 로그인이 발생하면 기존 매핑된 SessionId를 덮어써서 날려버린다. 기존 사용자가 클릭하는 순간 Redis에 자기 SID가 없으니 강제로 로그아웃 처리되는 구조다. 중앙 집중형 상태 관리의 강력한 통제력을 보여주는 사례다.
시나리오 — 세션 스토어(Redis) 장애로 인한 전면 로그인 마비: 대규모 포털 사이트에서 세션을 관리하는 Redis 클러스터의 마스터 노드가 OOM(Out of Memory)으로 죽고, Failover가 지연되며 세션 저장소가 5분간 마비(Downtime)되었다. 이 5분간 새로 고침을 누른 수천만 명의 유저가 동시에 강제 로그아웃되고 접속이 마비되는 사태가 벌어졌다.
- 판단: 세션을 외부 인메모리 DB로 빼는 아키텍처(SPOF, 단일 장애점 발생)의 뼈아픈 부작용이다. 이런 크리티컬 패스(Critical Path)를 설계할 때는 Redis 클러스터를 다중화(Replication, Sentinel)하는 것은 기본이고, Redis 장애 시 백업용 쿠키 기반 세션(암호화된 JWT 토큰 폴백)으로 일시 전환되도록 서킷 브레이커(Circuit Breaker) 로직을 백엔드에 설계해두어야 한다.

  ┌─────────────────────────────────────────────────────────────┐
  │         실무 아키텍처: 세션 하이재킹 방어 다차원 검증 로직          │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │ [해커의 공격] 💥                                              │
  │ 서울에 있는 해커가 부산에 있는 희생자의 세션 ID(XYZ) 쿠키를 훔쳤다! │
  │ 해커 ──(SID: XYZ)──▶ [웹 서버] (로그인 시도)                     │
  │                                                             │
  │ [서버 내부의 다차원 세션 검증 로직]                              │
  │  1. Redis 조회 ➔ SID: XYZ 존재함? (통과)                     │
  │                                                             │
  │  2. IP 주소 검증 (Location Check)                           │
  │     이 세션을 처음 만든 사람은 부산(IP: 1.1.1.1)이었는데,         │
  │     지금 요청을 보낸 애는 서울(IP: 8.8.8.8)이잖아?                 │
  │                                                             │
  │  3. User-Agent 검증 (Device Check)                          │
  │     이 세션은 어제 모바일 아이폰으로 만들었는데,                   │
  │     지금 찌른 애는 PC 크롬 브라우저네?                          │
  │                                                             │
  │  ❌ 판정: "세션 훔쳤구나! 당장 파기해!"                       │
  │  ➔ 서버가 즉시 Redis에서 XYZ 세션을 날려버림 (강제 로그아웃)        │
  │  ➔ 해커 브라우저로 401 Unauthorized 반환                       │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 단순히 세션 ID만 일치한다고 모든 요청을 프리패스 시켜주는 것은 하수들의 구현이다. 금융권 등 높은 보안이 요구되는 시스템에서는 세션을 생성할 때 사용자의 IP 앞자리 대역, User-Agent, 심지어 디바이스 핑거프린트까지 함께 Redis 세션 객체 안에 결합(Binding)시켜 둔다. 이후 매 요청이 들어올 때마다 헤더에 적힌 정보와 세션에 저장된 정보를 대조하여 오차 범위(IP 변경 등)가 비정상적으로 크면 곧바로 세션을 무효화(Invalidation)시키는 방어벽을 친다.

도입 체크리스트

기술적: 사용자 로그인 세션(SID)의 길이가 브루트포스(Brute-force) 공격으로 때려잡을 수 없는 충분한 길이(최소 128비트, 256비트 권장)와 무작위성(CSPRNG 난수 생성기 사용)을 가지도록 백엔드 프레임워크가 설정되어 있는가?
운영·보안적: 로그아웃 후 브라우저 뒤로가기 버튼을 눌렀을 때 남아있는 디스크 캐시를 방어하기 위해 응답 헤더에 Cache-Control: no-store가 박혀 있는가? (사용자가 공용 PC에서 로그아웃하고 일어났을 때, 다음 사람이 뒤로가기를 눌러 내 정보를 보는 것을 막기 위함).

안티패턴

세션 타임아웃 갱신 무한 루프: 세션 타임아웃을 30분으로 잡았는데, 사용자가 글을 길게 쓰거나 가만히 보고만 있어서 타임아웃이 끊기는 문제. 이를 막겠다고 프론트엔드에서 1분마다 무의미한 빈 API(Ping)를 찔러 서버의 세션 만료 시간을 계속 연장시키는 행위. 서버 CPU와 네트워크 커넥션 낭비의 극치다.
📢 섹션 요약 비유: 현관문을 열어주는 비밀번호(SID)를 너무 짧고 뻔하게 만들거나(난수성 부족), 이사 간 뒤에도 전 주인의 비밀번호를 그대로 놔두면(타임아웃 및 파기 미흡) 도둑이 제집 드나들 듯이 털어가게 됩니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	쿠키(Client) 위주 상태 저장	세션(Server) 기반 저장 아키텍처	개선 효과
정량	매 요청 수 KB의 무거운 쿠키 헤더	매 요청 수십 바이트의 얇은 SID 헤더	업로드 네트워크 트래픽 대역폭 기하급수적 절감
정량	강제 로그아웃/제어 불가능	서버 단의 중앙 즉시 무효화 통제	어뷰저, 다중 접속 차단 실시간(0초) 대응 100% 가능
정성	민감 데이터 조작 사고 빈발	데이터 서버 보관으로 위변조 원천 불가	결제/인증 아키텍처의 무결점 신뢰도(Trust) 구축

미래 전망

토큰(JWT)과 세션(Redis)의 하이브리드 아키텍처 진화: 극단적인 MSA 유행 초기에는 "무상태(Stateless)가 최고"라며 모든 세션을 버리고 JWT로 갈아타는 열풍이 불었다. 하지만 통제력 상실(강제 로그아웃 불가)이라는 부작용에 데인 기업들이 다시 세션 중심으로 회귀하고 있다. 수십 만의 API 찌르기는 가벼운 JWT로 넘기고, 로그인과 로그아웃이라는 가장 치명적인 통제점만 Redis 기반의 'Refresh Token Session Store' 구조로 관리하는 하이브리드 설계가 향후 10년 백엔드 인프라의 마스터피스로 자리매김할 것이다.
Edge 컴퓨팅과의 결합: 글로벌 서비스에서는 서울과 미국의 Redis를 동기화하는 레이턴시(수십 ms)조차 아깝기 때문에, 분산 DB(Cloud Spanner, DynamoDB Global Table)나 CDN 엣지(Edge) 로케이션에서 사용자 세션을 각 지역별로 밀착시켜 관리하는 Edge Session 아키텍처로 진화하고 있다.

참고 표준

OWASP Session Management Cheat Sheet: 안전한 세션 식별자 생성, 저장, 전송, 파기 전주기 보안 권고안
RFC 6265: HTTP State Management Mechanism (쿠키/세션을 통한 상태 관리)

"상태를 서버에 저장한다"는 것은 개발자에게 인프라 확장(Scale-out)의 고통과 분산 동기화의 십자가를 짊어지우는 행위다. 그럼에도 불구하고 지난 20년간 세션 아키텍처가 결코 죽지 않고 분산 메모리 DB(Redis)를 등에 업고 끝까지 살아남은 이유는 단 하나다. 인간의 얄팍한 본성(조작과 위조)을 방어하고, 비즈니스의 생명줄인 통제권(Control)을 쥐는 데 있어서, "중앙 서버의 락커룸에 꽁꽁 가둬두고 난수표 열쇠만 교부한다"는 이 투박하고 직관적인 철학만큼 확실한 보안 해법을 인류가 아직 찾아내지 못했기 때문이다.

📢 섹션 요약 비유: 아무리 결제 수단이 가벼운 스마트폰 페이(토큰)로 진화해도, 진짜 전 재산은 거대하고 무거운 중앙은행의 콘크리트 금고(세션 서버) 안에 보관되어 있어야만 밤에 두 다리 뻗고 잘 수 있는 것과 같습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
Cookie (쿠키)	세션 아이디(SID)라는 난수표를 브라우저에 저장하고 매번 서버로 실어 나르는 우편배달부 역할을 한다. 세션과 쿠키는 적이 아니라 공생 관계다.
Redis / Memcached	WAS의 로컬 메모리가 터지는 한계와 로드밸런싱 스티키 세션의 한계를 부수기 위해 도입된 외부 인메모리 세션 스토어의 표준이다.
Sticky Session / Session Clustering	다중 서버 환경에서 사용자의 세션 정보가 끊어지지 않게 유지하기 위해 트래픽을 한 놈에게 몰아주거나, 서버끼리 세션을 100% 복사하는 과도기적 아키텍처 기법들이다.
Session Hijacking (세션 탈취)	해커가 XSS 등으로 타인의 SID 쿠키를 훔쳐 서버에 대신 내미는 공격으로, HTTPS 및 다차원 검증(IP 대조 등)으로 방어해야 한다.
JWT (JSON Web Token)	서버의 중앙 집중형 세션 저장소를 아예 폭파시키고, 모든 상태 정보를 암호화해 클라이언트 쪽에 던져버린 완벽한 무상태(Stateless) 대항마 아키텍처다.

👶 어린이를 위한 3줄 비유 설명

쿠키가 내 이마에 '나는 착한 아이'라고 직접 써붙이고 다니는 거라면, 세션은 놀이공원 매표소 금고에 내 정보를 꽁꽁 숨겨두는 거예요.
매표소 직원은 내 정보를 안전하게 금고(서버)에 넣고, 저한테는 의미 없는 **플라스틱 팔찌 열쇠(세션 ID)**만 하나 채워줍니다.
제가 놀이기구를 탈 때마다 팔찌를 내밀면, 직원이 금고를 열어 제 신분을 확인해요. 팔찌에 정보가 안 쓰여 있어서 도둑이 팔찌를 훔쳐봐도 제가 누군지 절대 알 수 없답니다!