🍪쿠키(Cookie) — HTTP부터 JWT까지 (4)

🍪 쿠키의 등장 배경 — HTTP는 무상태(Stateless)

HTTP는 기본적으로 Stateless한 프로토콜입니다.
즉, 사용자가 로그인한 후 다른 페이지로 이동하거나 새로고침을 해도
서버는 사용자를 기억하지 않습니다.

이 무상태 구조는 단순하고 확장에 유리하지만,
다음과 같은 기능을 구현하기 어렵게 만듭니다:

• 로그인 상태 유지
• 장바구니
• 사용자 테마 설정 등

이 문제를 해결하기 위해 등장한 것이 바로 쿠키(Cookie) 입니다.

---

쿠키란?

쿠키는 클라이언트(브라우저)에 저장되는 작은 데이터 조각입니다.

동작 원리

• 서버는 인증 성공 시, Set-Cookie 헤더를 통해 쿠키를 설정합니다.
• 브라우저는 쿠키를 저장하고, 이후의 모든 요청에 자동으로 전송합니다.
• 서버는 이 쿠키를 기반으로 사용자를 식별합니다.

---

쿠키는 어디에 쓰일까?

• 로그인 상태 유지
• 자동 로그인
• 최근 본 상품 정보 저장
• 사용자 환경설정 유지 (예: 다크모드)

---

쿠쿠키와 세션 흐름

1. 클라이언트 로그인 요청 (ID/PW)
2. 서버 인증 → 세션 생성 → 사용자 정보 저장
3. 서버: Set-Cookie: JSESSIONID=abc123
4. 브라우저: 쿠키 저장
5. 이후 요청 시: Cookie: JSESSIONID=abc123 자동 포함
6. 서버는 세션 ID 기반으로 사용자 정보 조회

즉,

• 쿠키는 세션 ID를 담는 통신 매개체
• 사용자 정보는 서버 메모리 또는 세션 저장소에 저장

이 구조 덕분에 HTTP는 여전히 Stateless하면서도 상태를 유지하는 것처럼 작동할 수 있습니다.

---

쿠키의 구성 요소

속성	설명
Name=Value	쿠키의 이름과 값
Path	어떤 URL 경로에 대해 쿠키를 전송할지
Domain	쿠키를 사용할 도메인/서브도메인
Expires / Max-Age	쿠키 만료 시점 (지속 여부)
HttpOnly	JS 접근 불가 → XSS 방어
Secure	HTTPS 연결에서만 전송
SameSite	CSRF 방지 옵션 (Lax, Strict, None)

---

쿠키의 보안 이슈

1. XSS (Cross Site Scripting)

• 악성 스크립트가 쿠키를 탈취 가능
• HttpOnly 옵션으로 JS 접근 차단

2. CSRF (Cross Site Request Forgery)

• 사용자의 인증된 쿠키를 이용해 위조 요청
• SameSite=Lax 또는 Strict 권장

3. 민감 정보 저장 금지

• 비밀번호, 카드번호 등의 민감 정보는 절대 쿠키에 저장 ❌

---

🆚 쿠키 vs 세션 요약 비교

항목	쿠키	세션
저장 위치	클라이언트 (브라우저)	서버 (메모리, Redis, DB)
데이터 내용	식별자, 설정 정보	사용자 정보 or 참조 ID
설정 방식	Set-Cookie 헤더	서버 내부 코드로 생성
보안성	낮음 (유출 위험)	높음 (서버 제어 가능)
로그아웃 처리	쿠키 삭제	세션 무효화 또는 삭제

---

마무리 정리

• 쿠키는 클라이언트가 들고 다니는 작은 열쇠
• 세션은 서버가 사용자 정보를 저장해 두는 캐비닛

서버는 쿠키에 담긴 식별자를 통해 사용자 상태를 유추하지만,
직접 상태를 기억하지는 않기 때문에 Stateless 구조는 유지됩니다.

쿠키에는 식별자(ID) 만 담고,
민감한 정보는 절대 저장하지 마세요.

---

다음 글 예고

다음 글에서는 쿠키/세션 기반 인증과는 달리
서버가 상태를 저장하지 않는 구조,
즉 JWT(Json Web Token) 기반 인증 방식에 대해 알아보겠습니다.