쿠키와 세션의 차이

[9ga0]

🗓️ 2026년 8월 17일 월요일

💡오늘의 질문?

HTTP는 기본적으로 상태를 유지하지 않는 프로토콜입니다. 그런 웹 애플리케이션에서 쿠키(Cookie)와 세션(Session) 은 사용자 상태를 관리하는 핵심 요소입니다.
핵심키워드와 꼬리질문은 필수가 아닙니다.

1. 쿠키와 세션의 차이점을 설명해 주세요.

핵심 키워드와 꼬리 질문

핵심 키워드: 클라이언트 저장, 서버 저장, 세션 ID, 만료 시간
꼬리 질문: 세션 방식에서도 쿠키를 사용하는 이유는 무엇인가요?

2. 쿠키와 세션 중 보안성이 더 높은 것은 무엇인가요?

핵심 키워드와 꼬리 질문

핵심 키워드: XSS, 세션 하이재킹, HttpOnly, Secure, SameSite
꼬리 질문: 쿠키에 HttpOnly와 Secure 속성을 설정하면 어떤 공격을 방어할 수 있나요?

3. JWT(JSON Web Token)와 세션 기반 인증은 어떻게 다른가요?

핵심 키워드와 꼬리 질문

핵심 키워드: Stateful, Stateless, 서버 저장 공간, 확장성, 토큰 폐기
꼬리 질문: JWT를 사용하면 서버에서 로그아웃을 즉시 처리하기 어려운 이유는 무엇인가요?

참고해도 좋을 듯한 블로그 : https://velog.io/@gloom/%EC%BF%A0%ED%82%A4-%EC%99%80-%EC%84%B8%EC%85%98%EA%B7%B8%EB%A6%AC%EA%B3%A0%ED%86%A0%ED%81%B0JWT

[k9425mino]

0. Stateful과 Stateless이란?

둘의 차이의 핵심은 서버가 이전 요청의 상태를 기억하고 있느냐 이다.

[ Stateful ] : 서버가 클라이언트의 이전 상태를 기억하는 방식

로그인
 ↓
서버: "이 사용자는 로그인했다" → 세션 저장
 ↓
다음 요청
 ↓
서버: 세션 확인 → "아, 이 사용자구나"

즉, 서버가 상태(State)를 가지고 있다.

대표적인 예: 세션 기반 인증

[ Stateless ] : 서버가 이전 요청의 상태를 저장하지 않는 방식

예를 들어 JWT 인증에서는:

요청 + JWT
 ↓
서버
 ↓
JWT 자체를 검증
 ↓
사용자 확인

서버가 "이 사용자가 이전에 로그인했었다"라는 상태를 별도로 저장하지 않아도 된다.

대표적인 예: JWT 기반 인증

1. 쿠키와 세션의 차이점을 설명해주세요.

쿠키는 클라이언트에 데이터를 저장하고, 세션은 서버에 사용자 상태를 저장한다는 점이 가장 큰 차이이다.

구분	쿠키	세션
저장 위치	클라이언트(브라우저)	서버
주요 목적	상태/정보 저장	사용자 상태 관리
식별 방식	쿠키 자체에 데이터 저장 가능	Session ID를 통해 서버의 세션 식별
서버 부담	상대적으로 적음	세션 데이터를 서버에서 관리
만료	Expires, Max-Age 등으로 설정	서버의 세션 만료 정책에 따라 결정
보안	클라이언트에 저장되므로 변조·탈취에 주의	중요 데이터가 서버에 저장되어 상대적으로 안전

세션의 동작 과정에서 예를 들어 로그인한다고 하면:

① 사용자 → 서버
  로그인 요청

② 서버
  사용자 인증 성공
  → 세션 생성
  → Session ID 생성

③ 서버 → 브라우저
  Set-Cookie: SESSIONID=abc123

④ 브라우저
  이후 요청마다 SESSIONID=abc123 전송

⑤ 서버
  Session ID로 서버에 저장된 사용자 정보 조회

즉, 브라우저가 실제 사용자 정보를 가지고 있는 것이 아니라 Session ID를 가지고 있고, 실제 세션 데이터는 서버에 있다.

[ 꼬리질문: 세션 방식에서도 쿠키를 사용하는 이유는? ]

Session ID를 클라이언트가 계속 유지하고 서버에 전달하기 위해서이다.

HTTP는 기본적으로 Stateless하기 때문에 서버는 각각의 요청이 같은 사용자의 요청인지 자동으로 알 수 없다.

따라서:

로그인
 ↓
서버가 Session ID 생성
 ↓
Session ID를 쿠키에 저장
 ↓
브라우저가 이후 요청마다 쿠키 전송
 ↓
서버가 Session ID로 사용자를 식별

하는 방식으로 HTTP의 Stateless한 특성을 보완한다.

세션 = 서버 저장 방식, 쿠키 = Session ID를 전달하는 수단 으로 사용할 수 있다.

2. 쿠키와 세션 중 보안성이 더 높은 것은 무엇인가요?

일반적으로 민감한 인증 상태를 직접 저장한다면 세션 방식이 더 안전하게 설계하기 쉽다.

하지만 쿠키와 세션 자체를 단순히 비교해서 어느 하나가 무조건 더 안전하다고 할 수는 없다. 실제 보안성은 HttpOnly, Secure, SameSite, HTTPS, 세션 관리 등의 설정에 크게 좌우된다.

보안 요소 별 방어하는 대표적인 위협

• HttpOnly: XSS를 통한 쿠키 직접 탈취 방지
• Secure: 암호화되지 않은 HTTP 통신에서 쿠키 노출 방지
• SameSite: CSRF 방지
• HTTPS: 네트워크 구간에서 세션/쿠키 탈취 방지
• 세션 만료: 탈취된 Session ID의 장기 사용 방지
• Session ID 재발급: 세션 고정(Session Fixation) 위험 감소

[ HttpOnly ]

Set-Cookie: SESSIONID=abc123; HttpOnly

JavaScript에서 해당 쿠키에 접근할 수 없도록 한다.

따라서 공격자가 XSS를 통해 실행한 JavaScript로 인증 쿠키를 직접 탈취하는 것을 어렵게 만든다.

document.cookie

로 HttpOnly 쿠키를 읽을 수 있다.

[ Secure ]

Set-Cookie: SESSIONID=abc123; Secure

HTTPS 연결에서만 쿠키를 전송하도록 한다.

따라서 HTTP와 같은 암호화되지 않은 통신 구간에서 쿠키가 노출되는 위험을 줄인다.

[ SameSite ]

Set-Cookie: SESSIONID=abc123; SameSite=Lax

다른 사이트에서 발생한 요청에 쿠키를 얼마나 전송할지를 제한한다.

특히 CSRF(Cross-Site Request Forgery) 공격을 방어하는 데 중요한 역할을 한다.

[ 꼬리질문: 쿠키에 HttpOnly와 Secure 속성을 설정하면 어떤 공격을 방어할 수 있나요? ]

HttpOnly는 JavaScript의 쿠키 접근을 막아 XSS를 통한 세션 쿠키 탈취를 어렵게 하고, Secure는 HTTPS에서만 쿠키가 전송되도록 해서 네트워크 상에서 쿠키가 평문으로 노출되는 것을 방지한다. 다만 HttpOnly가 XSS 자체를 막는 것은 아니고, Secure 역시 HTTPS 자체를 활성화하는 것은 아니다.

그리고 HttpOnly + Secure만으로 CSRF까지 방어되는 것은 아니다. CSRF 방어에는 SameSite 설정이나 CSRF Token 등의 추가적인 방어책이 필요하다.

3. JWT(JSON Web Token)와 세션 기반 인증은 어떻게 다른가요?

가장 중요한 차이는 인증 상태를 서버에서 관리하느냐이다.

• 세션 기반 인증 → Stateful
• JWT 기반 인증 → Stateless

구분	세션 기반 인증	JWT
서버 상태	저장함	기본적으로 저장하지 않음
방식	Session ID	JWT 자체에 인증 정보 포함
서버 저장공간	필요	기본적으로 불필요
Stateful/Stateless	Stateful	Stateless
서버 확장	세션 공유/저장소 고려 필요	상대적으로 수평 확장에 유리
즉시 로그아웃	상대적으로 쉬움	기본적으로 어려움
토큰 폐기	세션 삭제	별도 폐기 전략 필요

[ 세션 기반 인증 ]

Client
  │
  │ Session ID
  ↓
Server
  │
  └── Session Store
       ├── Session ID
       ├── User ID
       └── 로그인 상태

서버가 상태를 가지고 있기 때문에 로그아웃할 때:

Session ID 삭제
        ↓
해당 세션 즉시 무효화

[ JWT 기반 인증 ]

JWT에는 일반적으로 다음과 같은 정보들이 들어간다.

Header
Payload
Signature

예를 들어 Payload에:

{
	"userId": 123,
	"role": "USER",
	"exp": 1787000000
}

같은 정보가 들어갈 수 있다.

서버는 JWT의 서명과 만료 시간 등을 검증하여 유효성을 판단한다.

즉,

Client
  │
  │ JWT
  ↓
Server
  │
  └── 서명 검증
      만료 시간 검증
      Payload 확인

처럼 동작할 수 있다.

세션 방식에서는 서버가 세션 상태를 관리해야 한다.

서버가 여러 대라면:

       ┌─ Server A ─┐
Client ─┤            ├─ Session Store
       └─ Server B ─┘

처럼 세션 공유 문제를 고려해야 한다.

반면 JWT는 서버가 별도의 세션 상태를 저장하지 않는 구조라면:

       ┌─ Server A
Client ─┼─ Server B
       └─ Server C

각 서버가 JWT를 독립적으로 검증할 수 있다.

따라서 Stateless한 JWT 인증은 수평 확장에 유리하다.

[ 꼬리질문: JWT를 사용하면 서버에서 로그아웃을 즉시 처리하기 어려운 이유는 무엇인가요? ]

이 부분이 JWT의 핵심적인 단점이다.

JWT를 발급한 후 서버가 JWT 자체를 저장하지 않는다면:

JWT 발급
   ↓
Client가 JWT 보관
   ↓
요청마다 JWT 전송
   ↓
서버는 서명 + 만료 시간 검증

예를 들어 JWT의 만료 시간이 1시간이라면, 사용자가 로그아웃하더라도 서버 입장에서는 그 JWT가 아직 유효한 토큰인지 구분하기 어렵다.

로그아웃 요청
   ↓
서버에서 JWT 삭제?
   ↓
삭제할 JWT를 서버가 저장하고 있지 않음
   ↓
기존 JWT는 exp 전까지 계속 유효

즉시 폐기가 필요하다면? 대표적으로 다음과 같은 방법이 있다.

• 짧은 Access Token 만료 시간
• Refresh Token을 이용한 재발급 구조
• Token Blacklist
• 서버에서 토큰의 상태를 별도로 관리
• 토큰 버전(version)을 사용자 계정에 저장하고 JWT의 버전과 비교

다만 이렇게 서버가 JWT의 상태를 관리하기 시작하면 JWT의 Stateless라는 장점이 일부 감소하게 된다.

[9ga0]

1. 쿠키와 세션의 차이점을 설명해 주세요.

핵심 키워드: 클라이언트 저장, 서버 저장, 세션 ID, 만료 시간
쿠키는 브라우저에 데이터를 저장하고, 세션은 서버에 사용자 상태를 저장하는 방식입니다. 세션에서도 브라우저와 사용자를 식별해야 하므로, 브라우저에는 실제 사용자 정보 대신 무작위 세션 ID를 쿠키로 저장합니다.

구분	쿠키	세션
저장 위치	클라이언트 브라우저	서버 또는 Redis 같은 저장소
클라이언트 저장값	상태 데이터 또는 토큰	일반적으로 세션 ID
서버 전송	조건에 맞는 요청에 자동 첨부	세션 ID를 통해 서버 데이터 조회
만료 관리	Expires, Max-Age	서버의 세션 만료 정책
서버 부담	상대적으로 적음	세션 저장 공간과 조회 필요
데이터 노출	클라이언트에서 확인·변조 가능	실제 상태는 서버에 보관

서버에서 다음과 같이 응답하면, 
Set-Cookie: SESSION_ID=a8f12...; HttpOnly; Secure; SameSite=Lax
브라우저는 이후 요청에 세션 ID를 자동으로 첨부한다.
Cookie: SESSION_ID=a8f12...
서버는 이 ID를 이용해 메모리, 데이터베이스 또는 Redis에서 사용자 정보를 찾는다.

1-1. 세션 방식에서도 쿠키를 사용하는 이유는 무엇인가요?

HTTP는 각각의 요청을 독립적으로 처리하기 때문에 서버가 이전 요청의 사용자를 자동으로 기억하지 않습니다. 따라서 클라이언트가 요청할때마다 자신을 식별할 값을 전달해야합니다. 이 식별할 값(세션ID)를 전달하는 방법에는 쿠키, URL 파라미터, 요청 헤더 등이 있지만 일반적인 웹 애플리케이션에서는 쿠키를 사용합니다.
쿠키 사용 장점)

• 브라우저가 요청마다 자동으로 전송한다.
• HttpOnly, Secure, SameSite 같은 보안 속성을 적용할 수 있다.
• URL에 세션ID가 노출되는 것을 피할 수 있다. URL에 세션ID를 넣으면 브라우저 기록, 서버 로그, 공유된 링크나 Referer 헤더 등에 노출될 수 있으므로 권장되지 않는다.

2. 쿠키와 세션 중 보안성이 더 높은 것은 무엇인가요?

핵심 키워드: XSS, 세션 하이재킹, HttpOnly, Secure, SameSite
민감한 데이터를 서버에 저장하는 세션 방식이 더 안전하다고 볼 수 있습니다. 클라이언트에는 의미없는 세션 ID만 저장되기에 위험성이 낮다고 볼 수 있지만 세션 ID도 인증수단이므로 사칭 위험이 없는 것은 아닙니다. 따라서 "세션은 안전하고 쿠키는 위험하다"라고 단정하기는 어렵고, 진짜 보안성은 저장할 데이터와 쿠키 속성, HTTPS 적용, 만료 정책 등에 따라 달라집니다.
대표적인 위협으로 4가지가 있다.

• XSS**: 악성 스크립트가 실행되어 쿠키나 사용자 정보를 탈취할 수 있습니다.
  -세션 하이재킹**: 탈취한 세션 ID로 사용자를 사칭합니다.
• CSRF: 브라우저가 쿠키를 자동 전송하는 특성을 악용해 사용자가 의도하지 않은 요청을 보냅니다.
• 세션 고정 공격: 공격자가 미리 알고 있는 세션 ID를 피해자가 사용하게 만듭니다.

따라서 보통 세션 쿠키에는 다음과 같이 보안 속성을 설정합니다.
Set-Cookie: SESSION_ID=...; HttpOnly; Secure; SameSite=Lax; Path=/

• HttpOnly: JavaScript의 document.cookie를 통한 접근을 차단합니다.
• Secure: HTTPS 연결에서만 쿠키를 전송합니다.
• SameSite: 외부 사이트에서 시작된 요청에 쿠키가 전송되는 범위를 제한해 CSRF 위험을 줄입니다.
• Domain, Path: 쿠키가 전송되는 범위를 제한합니다.
• Max-Age, Expires: 쿠키의 유효기간을 제한합니다.

2-1. 쿠키에 HttpOnly와 Secure 속성을 설정하면 어떤 공격을 방어할 수 있나요?

HttpOnly는 JavaScript가 쿠키를 읽지 못하게 하므로, XSS를 이용한 세션 쿠키 탈취 위험을 줄입니다. 쿠키에 HttpOnly가 설정되어있으면, 해당 쿠키를 읽을 수는 없지만, 현재 브라우저에서 악성 요청을 전송할 수 있기에 XSS 자체를 막은 것은 아닙니다.

document.cookie //JavaScript가 해당 쿠키를 읽으려 하는 코드

Secure은 쿠키가 암호화되지 않은 HTTP 연결로 전송되지 않고 HTTPS에서만 전송되게 합니다. 따라서 네트워크 도청이나 중간자 공격을 통한 쿠키 노출 위험을 줄입니다. 하지만 Secure은 XSS를 통한 악성 요청 실행, 서버 내부의 쿠키 유출, 예측 가능한 세션ID, 잘못된 세션 만료 정책 등의 문제를 방어 하지 못합니다.

따라서 HttpOnly와 Secure은 함께 적용하고 CSRF 방어를 위해 SameSite또는 CSRF토큰도 같이 사용하면 방어력이 더욱 올라갑니다.

3. JWT(JSON Web Token)와 세션 기반 인증은 어떻게 다른가요?

핵심 키워드: Stateful, Stateless, 서버 저장 공간, 확장성, 토큰 폐기
세션 기반 인증은 서버가 로그인 상태를 저장하고 클라이언트에는 세션ID만 전달하는 Stateful방식입니다. 반면 JWT 기반 인증은 사용자 정보와 만료 시간 등의 Claim을 토큰에 포함하고 서명을 검증하는 방식으로, 서버가 개별 로그인 상태를 저장하지 않는 Stateless 구조로 사용할 수 있습니다.
셰션은 로그아웃이나 강제 만료를 즉시 처리하기 쉽지만, 서버에 세션 저장소가 필요합니다. 반면, JWT는 여러 서버에서 서명만 검증할 수 있어 확장에 유리하지만, 발급된 토큰을 만료 전에 폐기하기 어렵습니다.

구분	세션 기반 인증	JWT 기반 인증
서버 상태	세션 상태 저장	상태를 저장하지 않도록 구성 가능
클라이언트 값	무작위 세션 ID	Claim과 서명이 포함된 토큰
인증 확인	세션 저장소 조회	JWT 서명과 Claim 검증
확장 방식	공유 세션 저장소 필요	여러 서버가 서명 검증 가능
즉시 만료	서버에서 세션 삭제	별도 폐기 전략 필요
토큰 크기	비교적 작음	세션 ID보다 큼
정보 노출	실제 정보는 서버에 저장	Payload를 디코딩해 확인 가능

기타)

• JWT는 토큰 형식이고 쿠키는 브라우저의 저장·전송 방식이므로, JWT를 HttpOnly 쿠키에 저장할 수도 있습니다.

3-1. JWT를 사용하면 서버에서 로그아웃을 즉시 처리하기 어려운 이유는 무엇인가요?

JWT는 발급된 토큰 목록을 서버가 가지고 있지 않아 세션 상태를 관리하지 않기 때문에(Stateless), 클라이언트가 로그아웃하면서 토큰을 삭제해도, 공격자가 복사해 둔 토큰으로 만료시간까지 로그인 가능합니다.

JWT는 서버에서 폐기할 상태가 없으므로 다음과 같은 보완 방법을 사용합니다.

• Access Token의 만료 시간을 짧게 설정한다.
• Refresh Token은 서버에 저장하고 로그아웃 시 폐기한다.
• 폐기된 JWT의 jti를 블랙리스트에 저장한다.
• 사용자별 토큰 버전을 관리하고 로그아웃 시 버전을 변경한다.
• 중요한 보안 사고 발생 시 서명 키를 교체한다.

다만 블랙리스트나 토큰 버전을 조회하면 서버 상태를 다시 관리하게 되므로 JWT의 Stateless 장점이 줄어듭니다. 실무에서는 보통 수명이 짧은 Access Token과 서버에서 통제 가능한 Refresh Token을 함께 사용합니다.