쿠키 vs 세션 vs 토큰 — 웹 인증 방식 비교

쿠키 vs 세션 vs 토큰. 웹 인증의 3대 개념. 비슷해 보이지만 인증 정보를 어디에 저장하느냐가 다르다. 셋의 차이와 동작 원리, 그리고 언제 무엇을 써야 하는지를 그림과 함께 정리한다.

---

들어가며

로그인 기능을 만들다 보면 쿠키, 세션, 토큰이라는 단어를 반드시 만난다. 그런데 이 셋이 어떻게 다른지, 어떤 관계인지 명확히 설명하기는 의외로 어렵다. "쿠키에 세션을 저장한다"거나 "토큰을 쿠키에 담는다" 같은 말이 섞여 나오면 더 헷갈린다.

핵심은 하나다. HTTP는 상태가 없다(stateless). 그래서 "이 요청을 보낸 사람이 방금 로그인한 그 사람"임을 증명할 방법이 필요하다. 쿠키·세션·토큰은 모두 그 문제를 푸는 방법이다.

이 글에서는 왜 인증이 필요한지부터 시작해, 세 가지 방식의 차이와 동작 원리를 정리한다.

---

왜 필요한가 — HTTP는 기억하지 못한다

HTTP는 무상태(stateless) 프로토콜이다. 요청 하나하나가 독립적이고, 서버는 이전 요청을 기억하지 않는다. 즉, 로그인 요청과 그다음 요청을 서버는 별개로 본다.

[로그인 요청]   "나 영희야, 비밀번호는 1234"   → 서버: "확인, 맞네"
[다음 요청]     "내 주문 내역 보여줘"          → 서버: "...누구세요?"

매 요청마다 아이디·비밀번호를 다시 보낼 수는 없다. 그래서 로그인 후 "당신이 그 사람"임을 증명할 증표가 필요하다. 그 증표를 어디에 어떻게 저장하느냐가 쿠키·세션·토큰을 가른다.

---

1. 쿠키 (Cookie) — 브라우저에 저장하는 작은 데이터

쿠키는 그 자체가 인증 방식이라기보다, 브라우저에 데이터를 저장하는 그릇이다. 서버가 응답에 쿠키를 담아 보내면, 브라우저가 저장해뒀다가 이후 같은 도메인 요청마다 자동으로 첨부한다.

서버 → 브라우저:  Set-Cookie: user=younghee
브라우저 → 서버:  Cookie: user=younghee   (이후 모든 요청에 자동 첨부)

이 "자동 첨부"가 쿠키의 핵심 특징이자, 양날의 검이다. 편리하지만 CSRF 공격의 빌미가 되기도 한다.

쿠키만으로 인증하면 위험하다. user=younghee를 누군가 user=admin으로 바꾸면 끝이기 때문이다. 그래서 쿠키는 보통 세션이나 토큰을 담는 그릇으로 쓰인다. 쿠키 자체에 중요 정보를 넣지 않는 게 원칙이다.

주요 속성:

속성	역할
HttpOnly	JS에서 접근 불가 → XSS로 인한 탈취 방지
Secure	HTTPS에서만 전송
SameSite	다른 사이트發 요청에 첨부 제한 → CSRF 방지
Expires / Max-Age	만료 시점

---

2. 세션 (Session) — 서버가 기억한다

세션 방식은 인증 정보를 서버에 저장한다. 로그인에 성공하면 서버가 세션을 만들어 자기 저장소(메모리, Redis 등)에 보관하고, 그 세션을 가리키는 세션 ID만 쿠키에 담아 브라우저에 준다.

1. 로그인 성공
2. 서버: 세션 생성 → 저장소에 보관
   { "sess_abc123": { userId: 1, name: "영희" } }
3. 서버 → 브라우저:  Set-Cookie: SESSIONID=sess_abc123
4. 이후 요청:  Cookie: SESSIONID=sess_abc123
5. 서버: 세션 ID로 저장소 조회 → "아, 영희구나"

브라우저는 의미 없는 ID(sess_abc123)만 들고 있고, 진짜 정보는 서버에 있다. ID를 탈취당해도 그 자체로는 정보가 없고, 서버가 세션을 지우면(로그아웃) 즉시 무효화할 수 있다. 서버가 통제권을 쥔다는 게 세션의 가장 큰 장점이다.

단점은 서버가 모든 세션을 저장해야 한다는 것이다. 사용자가 늘면 저장 부담이 커지고, 서버가 여러 대면 "세션을 어느 서버가 갖고 있느냐" 문제가 생긴다(그래서 Redis 같은 공유 저장소를 둔다).

---

3. 토큰 (Token) — 정보를 클라이언트가 들고 다닌다

토큰 방식은 발상을 뒤집는다. 서버가 정보를 저장하는 대신, 인증 정보를 토큰에 담아 클라이언트에게 통째로 넘긴다. 대표적인 게 JWT(JSON Web Token)다.

1. 로그인 성공
2. 서버: 정보를 담은 토큰 생성 + 서명
   eyJhbGci... (헤더.페이로드.서명)
3. 서버 → 클라이언트:  토큰 전달
4. 이후 요청:  Authorization: Bearer eyJhbGci...
5. 서버: 토큰의 서명만 검증 → 저장소 조회 없이 "영희구나"

핵심은 서버가 아무것도 저장하지 않는다(stateless) 는 점이다. 토큰 안에 정보가 들어 있고, 서버는 서명만 검증하면 된다. 위조하면 서명이 깨지므로 가짜 토큰은 걸러진다.

장점은 확장성이다. 서버가 상태를 안 가지니, 서버를 여러 대로 늘려도 세션 공유 문제가 없다. MSA나 여러 서비스가 인증을 공유할 때 특히 유리하다.

단점은 한 번 발급하면 만료 전까지 회수가 어렵다는 것이다. 세션은 서버가 지우면 끝이지만, 토큰은 이미 클라이언트 손에 있어서 서버가 일방적으로 무효화하기 어렵다. 그래서 만료 시간을 짧게 두고 리프레시 토큰으로 갱신하는 전략을 함께 쓴다.

---

세션 vs 토큰 — 핵심 비교

쿠키는 "저장 그릇"이고, 진짜 비교 대상은 세션과 토큰이다. 정보를 서버가 갖느냐(세션), 클라이언트가 갖느냐(토큰)의 차이다.

	세션 방식	토큰 방식 (JWT)
정보 저장 위치	서버	클라이언트(토큰 자체)
서버 상태	Stateful (저장 필요)	Stateless (저장 불필요)
확장성	세션 공유 필요 (Redis 등)	서버 증설에 유리
무효화(로그아웃)	즉시 가능	어려움 (만료까지 유효)
저장 부담	사용자 수만큼 서버에 부담	서버 부담 없음
주 사용처	전통적 웹, 모놀리식	MSA, 모바일, API

---

그래서 무엇을 쓸까

정답은 없고, 상황에 맞게 고른다.

• 전통적인 웹 서비스, 서버가 한두 대 → 세션이 단순하고 안전하다. 로그아웃·강제 만료 통제가 쉽다.
• MSA, 모바일 앱, 여러 서비스가 인증 공유 → 토큰(JWT)이 확장성에서 유리하다.
• 둘 다 흔히 쓰는 조합 → 짧은 수명의 액세스 토큰 + 리프레시 토큰. 토큰의 확장성과 세션 비슷한 통제력을 절충한다.

저장 위치도 중요하다. 토큰을 localStorage에 두면 XSS에 취약하고, 쿠키(HttpOnly)에 두면 CSRF를 신경 써야 한다. 어느 쪽이든 트레이드오프가 있으니, XSS·CSRF 대응을 함께 챙겨야 한다.

---

마치며

세 개념을 한 줄로 정리하면 이렇다. 쿠키는 브라우저에 데이터를 저장하는 그릇, 세션은 정보를 서버가 기억하는 방식, 토큰은 정보를 클라이언트가 들고 다니는 방식이다. 쿠키는 세션 ID나 토큰을 담는 운반 수단으로 쓰이고, 진짜 선택은 세션이냐 토큰이냐다.

핵심 질문은 "인증 정보의 통제권을 서버가 쥘 것인가, 확장성을 위해 클라이언트에 넘길 것인가"다. 세션은 통제가 쉽고, 토큰은 확장이 쉽다. 이 트레이드오프를 이해하면, 면접에서든 설계에서든 "왜 이걸 골랐는지"를 설명할 수 있다.

인증은 한 가지 방식만 외우는 게 아니라, 서비스의 구조와 규모에 맞게 고르는 선택의 문제다.

---

참고 출처

• MDN: HTTP cookies — https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
• MDN: Session — https://developer.mozilla.org/en-US/docs/Web/HTTP/Session
• jwt.io — https://jwt.io/introduction
• Auth0: Cookies vs Tokens — https://auth0.com/blog/cookies-vs-tokens-definitive-guide/