PromleeBlog
sitemap
aboutMe

posting thumbnail
쿠키와 세션의 동작 원리
How Cookies and Sessions Work

📅
🚀 들어가기 전에
🚀 Stateless HTTP와 상태를 기억하려는 노력
🚀 쿠키: 클라이언트 측의 작은 '멤버십 카드'
🚀 세션: 서버 측의 '비밀 고객 장부'
🚀 주요 면접 예상 질문
✅ 1. 쿠키와 세션의 차이점은 무엇인가요?
✅ 2. 세션은 확장성 측면에서 어떤 문제점을 가질 수 있나요?
✅ 3. JWT는 세션 기반 인증과 비교했을 때 어떤 장단점이 있나요?
🚀 결론
✅ 참고
🚀

들어가기 전에 🔗

이번 시간에는 웹 애플리케이션이 사용자를 어떻게 기억하고 상태를 유지하는지에 대한 근본적인 이야기, 바로
쿠키(Cookie)
와
세션(Session)
에 대해 깊이 있게 탐구해 보겠습니다.

이 두 기술은 '로그인' 기능을 구현하는 가장 전통적이고 기본적인 방법입니다.
오늘은 두 기술의 단순한 차이점을 넘어, '왜 이 기술들이 필요했는지'부터 시작하여 함께 동작하는 과정, 각각의 보안적 고려사항, 그리고 이를 바탕으로 한 주요 면접 질문까지 폭넓게 알아보겠습니다.
🚀

Stateless HTTP와 상태를 기억하려는 노력 🔗

쿠키와 세션을 이해하려면, 먼저 웹 통신의 기반이 되는 HTTP 프로토콜이
상태가 없다(Stateless)
는 특징을 알아야 합니다.

'상태가 없다'는 것은 서버가 클라이언트의 이전 요청을 전혀 기억하지 못한다는 의미입니다.
마치 방금 대화한 손님을 전혀 기억하지 못하는 가게 점원과 같습니다.
손님이 "아메리카노 한 잔 주세요"라고 요청하고, 잠시 뒤 "제 커피 나왔나요?"라고 물어보면, 점원은 "어떤 커피를 주문하셨었죠?"라고 되물을 수밖에 없습니다.

이런 식으로는 '로그인 상태 유지'나 '장바구니' 같은 기능을 만들 수 없습니다.
그래서 우리는 이 점원(서버)에게 손님(클라이언트)을 기억할 수 있는 수단을 만들어 주기로 했습니다.
그것이 바로 쿠키와 세션의 시작입니다.
🚀

쿠키: 클라이언트 측의 작은 '멤버십 카드' 🔗

쿠키는 서버가 클라이언트의 브라우저에 저장하도록 요청하는 작은 텍스트 조각입니다.

다시 가게 비유를 들어보겠습니다.
점원(서버)이 손님(클라이언트)에게 "이 멤버십 카드(쿠키)를 가지고 계세요. 다음부터 오실 때마다 이 카드를 보여주시면 제가 손님인 줄 알겠습니다."라고 말하는 것과 같습니다.

동작 과정
  1. 클라이언트가 서버에 처음 요청을 보냅니다.
  2. 서버는 응답을 보낼 때, HTTP 헤더의 Set-Cookie 필드에 정보를 담아 보냅니다. (예: Set-Cookie: userId=123)
  3. 클라이언트의 브라우저는 이 쿠키를 저장해 둡니다.
  4. 이후 클라이언트는 같은 서버에 요청을 보낼 때마다, HTTP 헤더의 Cookie 필드에 저장해 둔 쿠키를 자동으로 실어 보냅니다.
  5. 서버는 클라이언트가 보낸 쿠키를 보고 "아, 123번 회원이구나"라고 식별합니다.
🚀

세션: 서버 측의 '비밀 고객 장부' 🔗

쿠키는 편리하지만, 중요한 정보를 담기에는 보안에 취약하고 용량도 작다는 단점이 있습니다.
'멤버십 카드'에 이름, 주소, 비밀번호를 모두 적어두는 것은 위험한 것과 같습니다.

그래서 서버는 중요한 정보를 직접 보관하기로 합니다.
이것이 바로
세션
입니다.
서버는 각 클라이언트마다 고유한 저장 공간(세션)을 만들고, 여기에는 오직 서버만 접근할 수 있습니다.

동작 과정
  1. 클라이언트가 서버에 처음 요청을 보냅니다.
  2. 서버는 해당 클라이언트를 위한
    고유한 세션 ID
    를 생성하고, 이 ID와 대응되는 세션 저장소를 서버 메모리나 데이터베이스에 만듭니다.
    (이 저장소에 사용자의 로그인 정보 등을 저장합니다.)
  3. 서버는 응답 시, 오직
    세션 ID
    만을 쿠키에 담아 클라이언트에게 보냅니다. (예: Set-Cookie: sessionId=xyz-abc-123)
  4. 클라이언트는 이 '세션 ID 쿠키'를 저장해 두고, 다음 요청부터 계속해서 서버로 보냅니다.
  5. 서버는 클라이언트가 보낸 세션 ID를 받고, 자신의 '비밀 고객 장부(세션 저장소)'에서 해당 ID를 찾아 사용자의 상태를 확인합니다.
Session
Session
🚀

주요 면접 예상 질문 🔗

지금까지 배운 내용을 바탕으로, 면접관은 여러분의 이해도를 확인하기 위해 다음과 같은 질문들을 할 수 있습니다.
✅

1. 쿠키와 세션의 차이점은 무엇인가요? 🔗

이것은 가장 기본적인 질문입니다.
핵심 차이점들을 명확히 짚어주는 것이 중요합니다.
가장 큰 차이점은
데이터의 저장 위치
입니다.
쿠키는 클라이언트의 브라우저에 저장되는 반면, 세션은 서버 측에서 데이터를 관리합니다.
이로 인해
보안
면에서는 중요한 정보를 서버에 보관하는 세션이 더 유리하며, 저장할 수 있는
데이터의 형식이나 용량
에도 차이가 있습니다.
세션 방식에서는 클라이언트 식별을 위한 세션 ID만을 쿠키를 통해 주고받습니다."
✅

2. 세션은 확장성 측면에서 어떤 문제점을 가질 수 있나요? 🔗

세션은 기본적으로 서버의 메모리에 저장되기 때문에, 서버가 여러 대로 늘어나는
스케일 아웃 환경에서 세션 불일치 문제
가 발생할 수 있습니다.
예를 들어, 첫 요청을 처리한 A 서버에 세션이 생성되었는데 다음 요청이 B 서버로 가면, B 서버는 해당 세션 정보를 모르기 때문에 사용자의 로그인 상태가 유실될 수 있습니다.
이를 해결하기 위해 모든 요청을 같은 서버로만 보내는
스티키 세션
, 또는 Redis와 같은
별도의 세션 스토어
를 두어 모든 서버가 세션 정보를 공유하는 방법을 사용할 수 있습니다.
✅

3. JWT는 세션 기반 인증과 비교했을 때 어떤 장단점이 있나요? (JSON Web Token) 🔗

현대적인 웹 개발 환경을 이해하고 있는지를 묻는 질문입니다.
JWT는 인증에 필요한 모든 정보를 토큰 자체에 담고 암호화 서명을 통해 유효성을 검증하는
상태 비저장(Stateless) 방식
입니다.
장점
으로는, 서버에 세션 저장소가 필요 없으므로
확장성이 매우 뛰어나고
다른 도메인 간의 인증 처리도 간편하다는 점이 있습니다.
반면
단점
으로는, 한번 발급된 토큰은 유효 기간이 만료될 때까지 계속 유효하기 때문에
강제 로그아웃이나 즉각적인 비활성화가 어렵습니다.
또한, 세션 방식보다 더 많은 정보를 담고 있어 토큰의 길이가 길어질 수 있다는 특징이 있습니다.
🚀

결론 🔗

오늘은 웹의 상태 유지를 위한 쿠키와 세션, 그리고 현대적인 대안인 JWT까지 깊이 있게 알아보았습니다.


각 기술의 장단점과 그 이면의 트레이드오프를 명확히 이해하고, 예상 면접 질문에 대한 답변을 자신만의 언어로 정리해 둔다면 훌륭한 개발자로 성장할 수 있을 것입니다.
✅

참고 🔗