그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Security
Security

백엔드 관점에서 쿠키와 세션의 차이는 무엇인가요?

실무5/5
설계4/5
인간4/5
기초3/5

면접관의 질문 의도

두 개념을 평행 나열하는지, 아니면 "언제 무엇을 쓰는지"의 선택 기준까지 들고 있는지를 가른다. 보안 옵션과 다중 인스턴스 운영 이야기를 자연스럽게 꺼낼 수 있는지가 깊이의 분기점이다.

큐레이션 답변

학습 자료

쿠키는 클라이언트가 들고 다니는 키-값 저장소다. 브라우저가 같은 도메인의 모든 요청에 자동으로 실어 보내고, 서버는 그 값을 신뢰할 수 없는 입력으로 본다. 세션은 서버가 사용자별 상태를 들고 있고, 클라이언트에는 그 상태를 가리키는 식별자(보통 세션 ID 쿠키)만 넘긴다. 즉 쿠키와 세션은 대립 개념이 아니라 "상태를 어디에 두느냐"의 선택이고, 실제 운영에서는 세션 ID를 쿠키에 담아 둘이 함께 굴러간다.

좋은 답변 구조

  1. 01쿠키와 세션 각각이 무엇을 어디에 저장하는지부터 짧게 정의한다
  2. 02두 방식이 갈리는 축(상태 보유 주체·보안 통제·확장성 비용)을 정리한다
  3. 03실제로는 세션 ID를 쿠키에 담아 함께 쓰는 구조라는 점을 짚는다
  4. 04민감도와 트래픽 특성을 기준으로 어느 쪽에 무게를 둘지 선택 기준으로 마무리한다

자주 실수하는 포인트

쿠키와 세션을 대립 개념으로 설명하고 둘이 함께 굴러간다는 구조를 놓친다
민감 정보를 쿠키에 그대로 담아도 HTTPS면 괜찮다고 답한다
세션을 메모리에 두면 서버를 늘리는 순간 로그인이 풀린다는 점을 빠뜨린다
Secure/HttpOnly/SameSite 같은 쿠키 속성을 묻는 후속 질문에서 막힌다

실무 맥락

  • 로그인 인증을 다중 인스턴스로 띄워야 해서 세션 저장소를 Redis 같은 외부로 빼는 환경
  • 장바구니·사용자 설정처럼 비민감 상태는 클라이언트에 두고 인증만 서버가 쥐는 웹 서비스
  • 모바일 앱과 웹이 같은 백엔드를 쓰면서 쿠키 기반과 토큰 기반을 함께 굴려야 하는 상황
  • 서드파티 소셜 로그인을 연동하면서 쿠키의 SameSite 정책이 크로스 사이트 요청을 막는 환경

본인 경험에 녹이는 힌트

서버를 늘렸을 때 로그인이 풀리는 문제를 겪고 세션 저장소를 분리해본 경험이 있다면 "왜 세션을 어디에 두느냐가 아키텍처 문제인지"와 바로 연결할 수 있다

쿠키에 SameSite·Secure 옵션을 바꿔서 CSRF나 크로스 사이트 이슈를 잡아본 적이 있다면 보안 옵션 선택 기준으로 풀어낼 수 있다

민감 정보를 클라이언트에 두는 게 부담스러워 세션이나 토큰으로 옮긴 결정 과정이 있다면 "신뢰 경계를 어디에 긋는가" 관점으로 정리할 수 있다

JWT나 세션 중 하나를 골라 도입했던 경험이 있다면 그때 본 트레이드오프를 이 질문의 선택 기준 부분에서 끌어올 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1서버를 여러 대로 늘렸을 때 세션을 어떻게 공유하나요
Q2Secure·HttpOnly·SameSite 옵션은 각각 무엇을 막아주나요
Q3세션 방식 대신 JWT를 쓰면 무엇이 좋아지고 무엇이 나빠지나요
Q4로그아웃을 즉시 반영하기 어려운 인증 방식과 그 이유는 무엇인가요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문