🔐 쿠키(Cookie), 세션(Session), 토큰(Token) 인증 방식 차이 완벽 해설! 🏠

웹사이트를 이용할 때 로그인 상태가 유지되거나 장바구니에 담아둔 상품 정보가 사라지지 않는 것은 모두 인증 및 상태 유지 메커니즘 덕분입니다. 특히 HTTP 통신은 기본적으로 무상태(Stateless)라서, 이 세 가지 핵심 기술(쿠키, 세션, 토큰)이 없다면 매 페이지 이동 시마다 로그인을 다시 해야 하는 불편함이 발생합니다.

이 글에서는 이 세 가지 기술의 동작 원리, 장단점, 그리고 차이점을 그림과 함께 쉽게, 하지만 깊이 있게 설명해 드릴게요.

---

1. 🍪 쿠키 (Cookie) 기반 인증: 클라이언트 저장소

쿠키는 클라이언트(브라우저) 측에 데이터를 저장하여 상태를 유지하는 방식입니다.

1) 동작 원리

1. 클라이언트 요청: 브라우저가 서버에 로그인 요청을 보냅니다.
2. 서버 응답: 서버는 사용자가 인증되면, 사용자 정보를 담은 쿠키 또는 세션 ID를 포함한 쿠키를 만들어 HTTP 응답 헤더에 넣어 클라이언트에게 보냅니다.
3. 클라이언트 저장: 브라우저는 이 쿠키를 로컬 저장소에 저장합니다.
4. 다음 요청: 이후 클라이언트가 같은 서버에 요청을 보낼 때마다, 이 쿠키를 HTTP 요청 헤더에 자동으로 포함하여 서버로 전송합니다.
5. 서버 인증: 서버는 이 쿠키를 확인하여 사용자를 식별하고 상태를 유지합니다.

2) 장단점

장점	단점
구현이 간단하고 설정이 편리함	보안 취약: 클라이언트(브라우저)에 저장되므로, XSS 공격 등에 취약하여 민감 정보 저장에 부적합.
클라이언트 측 상태 정보를 보존 가능	용량 제한: 쿠키당 약 4KB의 용량 제한이 있음.
	매 요청 전송: 모든 요청마다 쿠키가 자동으로 포함되어 네트워크 부하를 증가시킬 수 있음.

---

2. 🖥️ 세션 (Session) 기반 인증: 서버 저장소

세션은 사용자 정보를 서버 메모리나 데이터베이스에 저장하고, 클라이언트에게는 그 정보에 접근할 수 있는 세션 ID(Session ID)만 쿠키 형태로 전달하는 방식입니다.

1) 동작 원리

1. 클라이언트 요청: 브라우저가 로그인 요청을 보냅니다.
2. 서버 세션 생성: 서버는 인증 후, 사용자 정보를 서버에 저장하고, 이 세션에 접근할 수 있는 고유한 세션 ID를 발급합니다.
3. 세션 ID 전달: 서버는 이 세션 ID를 담은 쿠키(세션 쿠키)를 클라이언트에게 전달합니다.
4. 다음 요청: 클라이언트는 이후 요청마다 이 세션 ID를 담은 쿠키를 서버로 전송합니다.
5. 서버 인증: 서버는 전달받은 세션 ID를 이용해 자신의 저장소에서 사용자 정보를 찾아 인증합니다.

2) 장단점

장점	단점
보안 강함: 민감한 정보는 서버에만 저장되므로 쿠키보다 보안이 훨씬 강력함.	서버 부하: 사용자가 늘어날수록 서버 메모리나 DB에 부담이 커짐.
데이터 용량 제한이 없음	확장성 문제 (Scale-out): 서버를 여러 대로 확장(Scale-out)할 때 세션 데이터의 공유(Sticky Session 또는 Redis/Memcached 사용)가 복잡해짐.

---

3. 🔑 토큰 (Token) 기반 인증: 자체 검증 티켓 (JWT)

토큰 방식은 클라이언트가 서버에 인증을 요청하면, 서버가 사용자 정보를 암호화한 인증 토큰(Authentication Token)을 발급하고, 이 토큰을 클라이언트가 보관했다가 매 요청 시 서버에 전달하는 방식입니다. 가장 대표적인 토큰 방식이 JWT (JSON Web Token)입니다.

1) 동작 원리 (JWT 기준)

1. 클라이언트 요청: 브라우저가 로그인 요청을 보냅니다.
2. 토큰 발급: 서버는 사용자 인증 후, 사용자 정보(Payload)를 담고 서버 비밀 키로 서명(Sign)한 JWT를 생성하여 클라이언트에게 전달합니다.
3. 클라이언트 저장: 클라이언트는 토큰을 로컬 저장소 (localStorage 또는 Cookie)에 저장합니다.
4. 다음 요청: 클라이언트는 토큰을 HTTP 헤더 (보통 Authorization: Bearer [토큰])에 담아 서버로 전송합니다.
5. 서버 검증: 서버는 토큰을 받으면 자신의 비밀 키로 서명을 검증합니다. 토큰이 유효하면 바로 사용자 정보(Payload)를 추출하여 인증을 완료합니다. 별도의 저장소 조회가 필요 없습니다.

2) 장단점

장점	단점
확장성/서버 부하 감소: 서버가 토큰을 저장할 필요 없어(Stateless), 서버를 늘리거나 마이크로서비스 환경에서 유리함.	토큰 용량: 토큰이 너무 크면 매 요청 시 네트워크 부하가 증가.
크로스 도메인: 쿠키와 달리 헤더를 사용하므로 다른 도메인에서도 인증 처리가 쉬움.	토큰 탈취: 토큰이 탈취되면 유효 기간이 끝날 때까지 막을 방법이 없음 (Refresh Token 도입으로 보완).

---

4. 📊 세 가지 인증 방식 비교 요약

구분	쿠키	세션	토큰 (JWT)
정보 저장 위치	클라이언트 (브라우저)	서버 (메모리, DB 등)	클라이언트 (로컬 저장소 또는 쿠키)
서버 상태	Stateless	Stateful (서버가 상태를 기억)	Stateless (서버가 상태를 기억하지 않음)
보안	가장 취약 (XSS 노출 위험)	가장 강력 (정보가 서버에만 있음)	강력 (서명 검증), 탈취 시 위험
확장성 (Scale-out)	쉬움	어려움 (세션 공유 필요)	매우 쉬움 (Stateless)
사용 환경	간단한 상태 유지 (장바구니 등)	전통적인 웹 애플리케이션	SPA/모바일, 마이크로서비스 (가장 선호)

🔑 가장 딥한 차이점: 상태(State)와 서버의 부담

가장 근본적인 차이는 서버가 사용자의 상태를 기억하느냐(Stateful) 아니면 기억하지 않느냐(Stateless)에 있습니다.

• 세션: 서버가 모든 사용자의 상태(세션 데이터)를 기억해야 하므로 Stateful입니다. 서버에 부하가 집중되지만 보안성이 높습니다.
• 쿠키 & 토큰: 서버가 사용자의 상태를 저장하지 않고, 클라이언트가 보내온 정보(쿠키 자체 또는 토큰)만으로 인증을 처리하므로 Stateless입니다. 서버 부하가 낮고 확장성이 좋습니다. 특히 JWT는 토큰 자체에 검증 정보가 있어 서버의 부담이 극도로 낮아집니다.