Daily Dev Q&A: Cookie vs Session

Topic (오늘의 주제)

Cookie (쿠키) vs Session (세션)

Why (왜 사용하는가? 왜 중요한가?)

• 실무: HTTP는 상태를 저장하지 않는 Stateless 프로토콜입니다. 쿠키와 세션이 없으면 페이지를 이동할 때마다 로그인이 풀리거나, 장바구니에 담은 물건이 사라지는 등 사용자를 식별할 수 없습니다.
• 구조적 의미: 클라이언트(브라우저)와 서버 간의 **상태 데이터를 어디에 저장하느냐(Client vs Server)**의 차이로, 보안성과 서버 부하 간의 트레이드오프(Trade-off)를 조절하는 역할을 합니다.
• 면접 의도: 웹의 동작 원리(HTTP)를 제대로 이해하고 있는지, **"보안(민감 정보 처리)"**과 "서버 확장성(Scale-out 시 세션 처리)" 문제를 어떻게 해결할 것인지 확인합니다.

Core Concept (핵심 개념 정리)

비교 항목	Cookie (쿠키)	Session (세션)
개념 정의	클라이언트(브라우저)에 저장되는 키-값(Key-Value) 형태의 작은 데이터 파일.	쿠키를 기반으로 하되, 실제 데이터는 서버에 저장하고 클라이언트는 **ID(식별자)**만 갖는 방식.
저장 위치	Client (웹 브라우저)	Server (메모리, DB, Redis 등)
보안성	취약함. 요청 시 스니핑 당하거나 로컬에서 변조될 위험이 있음.	비교적 안전함. 중요 데이터는 서버에 있고, 알 수 없는 ID값만 노출됨.
속도	빠름. (서버 처리가 필요 없고 로컬에서 바로 읽음)	느림. (서버의 처리를 거쳐야 함)
용량 제한	도메인당 20개, 개당 4KB 제한.	서버 용량이 허용하는 한 제한 없음.
라이프사이클	만료 시간 설정 가능 (브라우저 종료 후에도 유지 가능).	브라우저 종료 시 삭제 (설정에 따라 다름).

Interview Answer Version (면접 답변식 요약)

"HTTP의 비상태성(Stateless)을 보완하기 위해 쿠키와 세션을 사용합니다.

쿠키는 사용자의 브라우저에 데이터를 저장하는 방식이고, 세션은 서버 측에 데이터를 저장하고 브라우저에는 '세션 ID'만 부여하는 방식입니다.

쿠키는 서버 자원을 사용하지 않아 빠르지만 보안에 취약한 반면, 세션은 보안성은 높지만 사용자가 많아지면 서버 메모리에 부하를 줄 수 있습니다. 따라서 비밀번호 같은 민감한 정보는 세션에, '오늘 하루 팝업 보지 않기' 같은 단순 편의 정보는 쿠키에 저장하는 것이 일반적입니다."

Practical Tip (사용시 주의할 점 or 활용 예)

1. 보안 필수 옵션 (Security Flags)

쿠키(혹은 세션 ID 쿠키) 설정 시 아래 옵션을 누락하면 해킹 위험이 급증합니다.

• HttpOnly: 자바스크립트(document.cookie)로 쿠키에 접근하지 못하게 막아 XSS(교차 사이트 스크립팅) 공격을 방지합니다.
• Secure: HTTPS 연결에서만 쿠키를 전송하도록 설정하여 스니핑을 방지합니다.
• SameSite: 외부 사이트에서의 요청 시 쿠키 전송을 제한하여 CSRF(사이트 간 요청 위조) 공격을 방지합니다.

2. 서버 확장성(Scale-out) 문제와 해결

• 문제: 세션은 기본적으로 서버 메모리에 저장됩니다. 서버를 1대에서 3대로 늘리면(Scale-out), A서버에 로그인한 사용자가 B서버로 요청을 보낼 때 **"세션 정보 없음"**으로 팅기게 됩니다.
• 해결:
  1. Sticky Session: 특정 사용자는 처음 접속한 서버로만 계속 연결해주는 방식.
  2. Session Clustering: 모든 서버가 세션 정보를 복사해서 동기화하는 방식 (비효율적).
  3. Redis와 같은 별도 저장소 사용 (Best): 세션 저장소를 외부(In-memory DB)로 분리하여 모든 서버가 공유하게 만듭니다. (실무에서 가장 많이 사용)

3. 잘못된 사용 예시

• 사용자의 비밀번호나 주민등록번호 같은 민감한 정보를 암호화하지 않고 쿠키에 저장하면 절대 안 됩니다. (브라우저 개발자 도구에서 바로 보임)

예상 꼬리질문 정리

Q1. 세션 대신 토큰 기반 인증(JWT)을 사용하는 이유는 무엇인가요?

• 핵심 키워드: 세션은 서버 메모리를 차지하고 Scale-out 시 별도 처리가 필요하지만, JWT는 Stateless하여 서버 확장성이 좋고 모바일 앱 등 다양한 환경에서 공통으로 쓰기 편합니다. 다만, 토큰 탈취 시 강제 만료가 어렵다는 단점이 있습니다.

Q2. 브라우저를 닫았다가 다시 열어도 로그인이 유지되는 기능은 어떻게 구현하나요?

• 핵심 키워드: 세션 쿠키 대신 만료 기간(Expires/Max-Age)이 길게 설정된 **영속 쿠키(Persistent Cookie)**를 사용하거나, Refresh Token을 로컬 스토리지나 쿠키에 저장하여 액세스 토큰을 재발급받는 방식을 사용합니다.

Q3. 로컬 스토리지(Local Storage)와 세션 스토리지(Session Storage)는 쿠키와 어떻게 다른가요?

• 핵심 키워드: 쿠키는 매 요청마다 서버로 전송되지만, 웹 스토리지는 클라이언트에만 존재하여 트래픽 낭비가 없습니다. 로컬 스토리지는 영구 저장, 세션 스토리지는 브라우저 닫으면 삭제됩니다.