
Q. 세션 기반 인증에 대해 설명해 주세요.
서버는 사용자 정보를 확인하고 인증에 성공하면, 고유한 세션 ID를 생성한다.
이 세션 ID는 서버 내 저장소(메모리, Redis, DB 등)에 사용자 정보와 함께 저장된다.
서버는 생성된 세션 ID를 쿠키(Cookie)에 담아 클라이언트에게 응답한다.
클라이언트는 이후 요청마다 이 쿠키를 함께 보낸다.
1. 로그인 요청
POST /login
→ 서버: 세션 ID 'abc123' 생성 후, 사용자 정보와 함께 서버 저장소에 저장
→ 클라이언트: 쿠키에 'abc123' 저장
2. 인증된 요청
GET /my-page
→ 클라이언트: 쿠키에 'abc123' 포함
→ 서버: 세션 저장소에서 'abc123' 찾기 → 인증 성공 → 응답 전송
구현이 간단하다: 오래된 방식이라 프레임워크 지원이 잘 되어 있어 빠르게 적용 가능하다.
보안성이 좋다: 세션 데이터가 서버에 저장되므로, 클라이언트가 직접 데이터를 조작할 수 없다.
자동 로그아웃 처리 가능: 세션 만료 시간을 설정해 자동 로그아웃 구현 가능하다.
서버에 부하가 크다: 사용자 수가 많아질수록 세션 데이터를 저장하는 서버 리소스가 증가한다.
수평 확장에 불리하다: 서버가 여러 대로 분산될 경우, 세션 동기화(Sticky Session 또는 Redis 사용 등)가 필요하다.
모바일·SPA에서 쿠키 기반 인증은 불편할 수 있다.
| 구분 | 세션 기반 인증 | 토큰 기반 인증 (JWT) |
|---|---|---|
| 저장 위치 | 서버 | 클라이언트 (로컬스토리지 등) |
| 상태 | 상태 유지 (Stateful) | 상태 없음 (Stateless) |
| 확장성 | 낮음 (세션 동기화 필요) | 높음 (무상태 처리) |
| 보안 | 상대적으로 안전 | 토큰 탈취 시 위험 |
| 만료 처리 | 서버에서 직접 관리 | 토큰 내 정보로 판단 (재발급 필요) |
세션 기반 인증은 다음과 같은 상황에 적합하다.
서버-클라이언트 구조가 단순할 때 (ex: 서버 렌더링 기반 웹사이트)
인증 보안이 중요한 내부 서비스
사용자 수가 상대적으로 적은 서비스
서버에 상태를 유지할 수 있는 환경