⚡ 네트워크 - Cookie와 Session의 차이

🔹 쿠키(Cookie)

▫️ 개요

• 클라이언트, 즉 브라우저에 저장되는 작은 데이터 조각
• 웹 서버가 사용자의 브라우저에 데이터를 저장하도록 지시하고, 이후 같은 사이트를 방문할 때 브라우저가 해당 데이터를 서버에 자동으로 전송
• 서버의 부담을 줄이기 위한 방법

▫️ 주요 특징

• 저장 위치: 클라이언트
• 데이터 크기 제한: 약 4 KB
• 만료 기간 설정 가능

▫️ 단점

• 클라이언트에서 쿠키 조작 가능하므로 보안 취약
• 민감한 정보 저장에 부적합
• 탈취 시 인증 정보 유출 위험 있음
• 이를 방지하기 위해 HttpOnly, Secure, SameSite 속성 설정 필요

🔹 세션(Session)

• 서버에 저장되는 사용자 상태 정보
• 사용자가 웹사이트에 접속하면 서버는 고유한 세션 ID를 생성하고 이를 클라이언트에 전달
• 클라이언트는 세션 ID를 쿠키에 저장해 요청마다 서버에 전송하며, 서버는 이 ID로 사용자를 식별하고 관리

▫️ 주요 특징

• 저장 위치: 서버
• 보안성 높음
• 구조적으로 직관적

▫️ 단점

• 서버 메모리에 세션 상태를 저장해야 해서 확장성 낮음
• 서버 재시작 시 세션 사라질 수 있음
• 클라이언트가 세션 ID를 쿠키에 저장하기 때문에, 쿠키가 탈취되면 세션이 탈취되는 것과 같음. 이를 세션 하이재킹이라고 함
• 이를 막기 위해 HttpOnly, Secure, SameSite 설정과 HTTPS 사용이 필수적이며, 세션 만료 시간과 사용자 환경 검사 등을 함께 사용해야 함

🔹 JWT: Json Web Token

• 로그인 시 서버는 사용자 정보를 포함한 JWT 토큰을 발급
• 클라이언트는 이 JWT를 Cookie 또는 Authorization 헤더에 담아 요청에 포함
• 서버는 JWT를 검증하여 사용자 인증하고, Session을 별도로 저장하지 않음
• 이러한 특성을 Stateless라고 함
• Spring Security에서도 커스터마이징을 통해 JWT 방식 사용 가능

▫️ 장점

• 서버는 Session을 별도로 저장하지 않음
• 서버 간 세션 공유 필요 없으므로 수평 확장에 유리
• 토큰에 사용자 정보가 포함되어 있어 인증 빠름

▫️ 단점

• 토큰 자체가 민감 정보를 포함하기 때문에 노출 위험 있음
• 토큰 탈취 시 서버 상태와 무관하게 인증된 사용자인 척 할 수 있음
• 토큰 만료 시 재발급 과정 필요 Refresh token 등 별도 설계 필요
• 서버가 상태를 갖지 않기 때문에 토큰 무효화 어려움
• 이를 보완하기 위해 토큰 암호화, 짧은 만료 시간, Refresh Token, 블랙 리스트 관리 등의 보안 대책 필요

🔹 비교 표

항목	Cookie 기반	Session 기반	JWT 기반
인증 정보 저장 위치	클라이언트	서버	클라이언트
Stateless	Depends	X	O
보안성	낮음	높음	구현에 따라 상이
서버 부하	낮음	높음	낮음
확장성	중간	낮음	높음