웹 개발을 하다 보면 세션은 너무 당연하게 사용된다.
로그인을 유지하고, 사용자 상태를 기억하는 데 필수적인 요소다.
하지만 실제로 세션이 어떻게 동작하는지,
특히 멀티 WAS 환경에서 어떤 문제가 발생하는지 이해하고 있는 경우는 많지 않다.
이 글에서는 JSESSIONID를 중심으로
세션의 내부 동작과 구조를 조금 더 깊게 정리한다.
세션의 본질
세션은 단순히 말하면 다음과 같다.
- 서버에 저장된 사용자 상태
- 요청 간 상태를 유지하기 위한 장치
HTTP는 stateless(무상태)이기 때문에
요청마다 사용자를 식별할 방법이 필요하다.
이때 사용하는 것이 세션이다.
JSESSIONID의 역할
세션은 서버에 저장되지만,
클라이언트는 자신의 세션을 어떻게 식별할까?
그 역할을 하는 것이 JSESSIONID다.
전체 흐름
- 클라이언트 최초 요청
- 서버에서 세션 생성
- 세션 ID 생성 (예: ABC123)
- 응답에 쿠키로 전달
Set-Cookie: JSESSIONID=ABC123- 이후 요청마다 자동 포함
Cookie: JSESSIONID=ABC123- 서버는 해당 ID로 세션 조회
세션 저장 위치
세션은 일반적으로 다음 위치에 저장된다.
1. WAS 메모리 (기본)
- Tomcat, Tomee 등
- 가장 빠름
- 서버마다 따로 존재
2. 외부 저장소
- Redis
- DB
멀티 서버 환경에서 사용
중요한 오해
많이 하는 착각이 있다.
JSESSIONID에 사용자 정보가 들어있다?
아니다.
- JSESSIONID = 단순한 키
- 실제 데이터 = 서버 내부
즉, 클라이언트는 아무 정보도 가지고 있지 않다.
단일 WAS 환경
[Client] → [WAS1]- 세션 생성
- JSESSIONID로 계속 접근
문제 없음
멀티 WAS 환경 문제
[Client] → [LB] → [WAS1 / WAS2]시나리오
- 로그인 → WAS1 → 세션 생성
- 다음 요청 → WAS2
결과:
- 세션 없음
- 로그인 풀림
해결 방법
1. Sticky Session
- LB가 특정 WAS로 고정
장점:
- 간단
단점:
- 확장성 낮음
- 장애 시 문제
2. Session Replication
- WAS끼리 세션 공유
단점:
- 네트워크 비용 큼
- 성능 저하
3. Redis 기반 세션
- 외부 저장소 사용
구조:
Client → LB → WAS → Redis장점:
- 확장성 좋음
- 안정적
JSESSIONID + JVM Route
클러스터 환경에서는 이런 형태도 사용한다.
JSESSIONID=ABC123.node1여기서
- ABC123 → 세션 ID
- node1 → 서버 식별자
LB가 이 값을 보고 특정 서버로 라우팅
실무에서 자주 터지는 문제
1. 로그인 유지 안됨
- 멀티 WAS
- 세션 공유 없음
2. 특정 API에서만 세션 유실
- 다른 서버로 라우팅됨
3. 외부 콜백 이후 세션 사라짐
- 도메인 변경
- 쿠키 미전달
쿠키와 보안
JSESSIONID는 쿠키이기 때문에
보안 설정이 중요하다.
- HttpOnly
- Secure
- SameSite
설정에 따라
- XSS 방지
- CSRF 대응
가능
왜 이런 구조일까?
HTTP는 stateless이기 때문에
- 서버가 상태를 기억하려면
- 클라이언트가 식별자를 보내야 한다
그래서
- 서버 → 세션 저장
- 클라이언트 → ID만 보관
이 구조가 만들어졌다.
한 단계 더
세션 방식 외에도 다른 방식이 있다.
- JWT (Stateless)
- Token 기반 인증
세션은 상태 기반(stateful),
JWT는 무상태(stateless) 방식이다.
정리
- 세션은 서버에 저장된다
- JSESSIONID는 그 세션을 찾는 키다
- 단일 서버에서는 단순하다
- 멀티 서버에서는 전략이 필요하다
한줄 요약
세션은 서버에 있고,
JSESSIONID는 그 세션을 찾기 위한 식별자다.
선명한 삶을 살기 위하여