쿠키와 세션은 어떻게 다를까?

위치:

네트워크 관련 정리

9월 10, 2026
0
127 words

웹사이트를 이용하다 보면 한 번 로그인한 뒤 다른 페이지로 이동해도 로그인 상태가 계속 유지되는 것을 볼 수 있다.

예를 들어 쇼핑몰에 로그인한 뒤 상품을 보고 장바구니에 들어가거나 마이페이지로 이동해도 매번 아이디와 비밀번호를 다시 입력하지 않는다.

그런데 여기서 조금 이상한 점이 있다.

HTTP는 기본적으로 각각의 요청을 독립적으로 처리하는 방식이다. 그렇다면 서버는 지금 요청을 보낸 사람이 아까 로그인했던 그 사용자라는 것을 어떻게 알 수 있을까?

이때 자주 등장하는 것이 쿠키(Cookie)와 세션(Session)이다.

둘 다 웹에서 사용자의 상태를 유지하는 데 사용되지만 역할과 저장되는 위치가 다르다.

처음 공부하면 둘을 거의 같은 개념처럼 생각하기 쉬운데, 실제로는 구분해서 이해하는 것이 좋다.

HTTP는 기본적으로 상태를 기억하지 않는다

먼저 HTTP의 특징을 다시 생각해보자.

브라우저가 서버에 요청을 보내면 서버는 응답을 돌려준다.

브라우저
   │
   │ HTTP Request
   ▼
서버
   │
   │ HTTP Response
   ▼
브라우저

그리고 다음 요청이 들어오면 또 하나의 요청으로 처리한다.

요청 1 → 서버 → 응답 1

요청 2 → 서버 → 응답 2

요청 3 → 서버 → 응답 3

HTTP 자체만 놓고 보면 서버가 요청 사이의 사용자를 자동으로 기억해주는 기능은 없다.

그렇다면 로그인한 사용자를 어떻게 구분할까?

바로 쿠키나 세션 같은 상태 관리 기술을 이용한다.

쿠키란 무엇일까?

쿠키는 웹사이트가 브라우저에 저장해두는 작은 데이터라고 생각하면 된다.

서버가 브라우저에 쿠키를 저장하도록 응답하면 브라우저는 해당 쿠키를 보관하고, 이후 조건에 맞는 요청을 보낼 때 쿠키를 함께 전송한다.

가장 단순한 흐름은 다음과 같다.

서버
 │
 │ Set-Cookie
 ▼
브라우저
 │
 │ Cookie
 ▼
서버

예를 들어 서버가 다음과 같은 응답을 보낼 수 있다.

Set-Cookie: user=12345

브라우저는 이 값을 저장한다.

그리고 이후 요청에서

Cookie: user=12345

처럼 쿠키를 서버에 전달할 수 있다.

이렇게 하면 서버는 요청을 보낸 브라우저를 구분하는 데 쿠키를 활용할 수 있다.

쿠키는 어디에 저장될까?

가장 중요한 특징 중 하나가 이것이다.

쿠키는 기본적으로 클라이언트인 브라우저에 저장된다.

개념적으로 보면 다음과 같다.

[브라우저]
 └─ Cookie
     ├─ 이름
     ├─ 값
     ├─ 만료시간
     └─ 기타 속성

따라서 쿠키는 서버가 가지고 있는 데이터가 아니라 브라우저가 가지고 있는 데이터다.

그리고 쿠키는 단순히 로그인 상태를 유지하는 데만 사용하는 것은 아니다.

예를 들어

로그인 상태 유지
사용자 설정 저장
장바구니 정보
광고 및 분석을 위한 식별 정보

등 다양한 용도로 사용될 수 있다.

다만 어떤 데이터를 쿠키에 저장할지는 서비스 구조와 보안 요구사항에 따라 달라진다.

세션은 무엇일까?

세션은 조금 다르다.

세션은 일반적으로 서버 측에서 사용자의 상태를 관리하는 방식을 말한다.

예를 들어 사용자가 로그인하면 서버가 사용자를 위한 세션을 만들고 특정 세션 ID를 발급할 수 있다.

사용자
  │
  │ 로그인
  ▼
서버
  │
  ├─ 사용자 인증
  │
  ├─ 세션 생성
  │
  └─ 세션 ID 발급

예를 들어 세션 ID가

abc123

이라고 해보자.

서버에는 다음과 같은 정보가 저장되어 있을 수 있다.

세션 ID: abc123
사용자: user123
로그인 상태: 로그인

그리고 브라우저에는 세션 ID를 전달한다.

이후 사용자가 요청을 보내면 서버는 세션 ID를 확인해서 해당 사용자의 세션 정보를 찾는다.

브라우저
   │
   │ 세션 ID
   ▼
서버
   │
   │ 세션 ID 검색
   ▼
세션 저장소
   │
   │ user123
   ▼
사용자 확인

즉, 실제 사용자 상태를 서버에서 관리하고 브라우저에는 그 상태를 찾기 위한 식별자만 전달하는 구조가 전형적인 세션 방식이다.

쿠키와 세션의 가장 큰 차이

이제 둘의 차이가 조금 명확해진다.

구분	쿠키	세션
주요 저장 위치	클라이언트(브라우저)	서버
주요 역할	데이터를 브라우저에 저장/전달	서버에서 사용자 상태 관리
서버 부담	상대적으로 적음	세션 저장/관리 필요
브라우저 삭제 가능	가능	세션 ID 쿠키 등이 삭제되면 접근 어려움
대표 활용	설정, 식별자, 상태 정보 등	로그인 상태, 사용자 상태 관리

여기서 중요한 것은 쿠키와 세션이 서로 완전히 경쟁하는 별개의 기술이 아니라는 것이다.

실제로는 세션을 사용하면서 세션 ID를 쿠키에 저장하는 경우가 많다.

쿠키와 세션은 같이 사용할 수도 있다

이 부분이 처음 공부할 때 가장 헷갈릴 수 있다.

“쿠키와 세션 중 하나만 사용하는 것 아닌가?”

그렇지 않다.

오히려 전형적인 로그인 구조에서는 쿠키와 세션을 함께 사용한다.

예를 들어 사용자가 로그인을 한다고 해보자.

1. 브라우저
   │
   │ ID / Password
   ▼
2. 서버
   │
   ├─ 사용자 인증
   ├─ 세션 생성
   └─ Session ID 생성
   │
   ▼
3. 브라우저
   │
   └─ Session ID를 쿠키에 저장

이후 사용자가 마이페이지에 접속하면

브라우저
   │
   │ Cookie: SESSIONID=abc123
   ▼
서버
   │
   │ abc123으로 세션 조회
   ▼
사용자 user123 확인

이런 식으로 동작할 수 있다.

즉,

쿠키는 세션 ID를 전달하는 역할을 하고, 실제 로그인 상태는 서버의 세션에 저장하는 구조다.

로그인 과정을 전체적으로 보면

조금 더 구체적으로 보면 이해하기 쉽다.

사용자가 로그인 페이지에서 아이디와 비밀번호를 입력한다.

POST /login

id=user123
password=********

서버가 인증에 성공하면 세션을 만든다.

Session ID
= abc123

그리고 브라우저에 쿠키를 설정한다.

Set-Cookie: SESSIONID=abc123

브라우저는 이 쿠키를 저장한다.

이후 사용자가 /mypage를 요청하면 브라우저가 쿠키를 함께 보낸다.

GET /mypage
Cookie: SESSIONID=abc123

서버는 abc123이라는 세션 ID를 가지고 세션 저장소를 조회한다.

abc123
   ↓
user123
   ↓
로그인 상태 확인

그래서 서버는 사용자가 로그인한 상태라는 것을 알 수 있다.

전체 구조를 그려보면 다음과 같다.

                 로그인
브라우저 ─────────────────→ 서버
                           │
                           │ 세션 생성
                           ▼
                    Session ID 생성
                           │
                           ▼
브라우저 ←──── Set-Cookie ──┘
   │
   │ 쿠키 저장
   │
   │ 이후 요청
   ▼
서버 ←──── Cookie: Session ID
   │
   │ 세션 조회
   ▼
사용자 확인

쿠키에 비밀번호를 저장하면 안 될까?

여기서 중요한 보안 문제가 나온다.

쿠키는 브라우저에 저장되기 때문에 중요한 정보를 아무렇게나 넣어서는 안 된다.

특히 비밀번호 같은 민감한 정보를 쿠키에 저장하는 것은 적절하지 않다.

쿠키에는 로그인 상태를 나타내는 세션 ID나 적절하게 보호된 인증 정보 등을 저장하고, 서버에서 필요한 사용자 정보를 관리하는 방식이 일반적이다.

그리고 쿠키에는 보안을 위한 여러 속성이 존재한다.

대표적으로 다음과 같은 것들이 있다.

Secure

Secure 속성이 설정된 쿠키는 HTTPS 연결에서만 전송되도록 할 수 있다.

Set-Cookie: SESSIONID=abc123; Secure

앞에서 배운 HTTPS와 연결되는 부분이다.

HttpOnly

HttpOnly가 설정된 쿠키는 일반적인 JavaScript 코드에서 직접 접근하기 어렵게 만들어 쿠키 탈취 위험을 줄이는 데 도움을 준다.

Set-Cookie: SESSIONID=abc123; HttpOnly

SameSite

SameSite는 다른 사이트에서 발생하는 요청에 쿠키가 어떻게 전송될지 제어하는 데 사용된다.

Set-Cookie: SESSIONID=abc123; SameSite=Lax

이런 속성들은 웹 애플리케이션의 쿠키 보안을 구성할 때 중요하게 사용된다.

세션은 서버에 저장되기 때문에 무조건 더 안전할까?

여기서도 단순하게 생각하면 안 된다.

“쿠키는 브라우저에 저장되니까 위험하고 세션은 서버에 있으니까 안전하다.”

이렇게만 이해하면 정확하지 않다.

세션을 사용하더라도 세션 ID가 탈취되면 공격자가 해당 세션을 이용할 가능성이 있다.

예를 들어 정상 사용자의 세션 ID가 공격자에게 노출되면 서버는 해당 요청을 정상 사용자의 요청으로 판단할 수 있다.

그래서 세션 ID 역시 HTTPS를 통해 보호하고, 적절한 쿠키 보안 속성을 적용하며, 로그인 이후 세션 ID를 재발급하는 등 여러 보안 대책을 함께 사용하는 것이 중요하다.

요즘은 세션만 사용하는 것도 아니다

웹 개발을 공부하다 보면 JWT 같은 인증 방식도 자주 접하게 된다.

JWT(JSON Web Token)를 이용하는 방식에서는 서버가 사용자 정보를 담은 토큰을 발급하고 클라이언트가 이후 요청에서 해당 토큰을 보내는 구조를 사용할 수 있다.

이런 방식은 전통적인 서버 세션 방식과 구조가 다르다.

세션 방식

브라우저
  ↓ Session ID
서버
  ↓
세션 저장소


토큰 방식

브라우저
  ↓ Token
서버
  ↓
토큰 검증

따라서 현대 웹 서비스에서는 무조건 “로그인 = 세션”이라고 생각하기보다는 웹 서비스의 구조에 따라 세션, 토큰 등의 인증 방식을 사용할 수 있다고 이해하는 것이 좋다.

쿠키와 세션을 헷갈리지 않는 방법

처음 공부할 때는 다음 한 문장으로 기억해두면 편하다.

쿠키는 브라우저에 저장되는 데이터이고, 세션은 서버에서 사용자의 상태를 관리하는 방식이다.

그리고 로그인에서는 둘이 같이 사용될 수 있다.

쿠키
→ 브라우저가 가지고 있음

세션
→ 서버가 가지고 있음

세션 ID
→ 쿠키를 통해 브라우저와 서버 사이에서 전달

이렇게 구분하면 훨씬 이해하기 쉽다.

웹 요청에서 쿠키와 세션이 연결되는 위치

지금까지 공부했던 내용을 연결하면 웹의 로그인 과정이 조금씩 보이기 시작한다.

브라우저
   │
   ├─ DNS
   │
   ├─ TCP
   │
   ├─ TLS
   │
   ├─ HTTP Request
   │       │
   │       └─ Cookie
   │
   ▼
서버
   │
   ├─ 세션 조회
   ├─ 사용자 인증
   └─ 응답

앞에서 공부한 HTTPS가 통신 내용을 보호하는 역할을 한다면, 쿠키와 세션은 그 통신을 이용해 사용자의 상태를 유지하는 역할을 한다.

그래서 각각의 개념을 따로 외우기보다는 웹 요청의 흐름 안에서 연결해서 이해하는 것이 좋다.

마무리

쿠키와 세션은 웹에서 사용자의 상태를 유지하기 위해 자주 사용되는 개념이다.

쿠키는 브라우저에 저장되는 작은 데이터이고, 세션은 서버 측에서 사용자의 상태를 관리하는 방식이다.

특히 로그인 시스템에서는 다음과 같은 구조가 흔하다.

사용자 로그인
      ↓
서버가 사용자 인증
      ↓
세션 생성
      ↓
Session ID 발급
      ↓
브라우저 쿠키에 Session ID 저장
      ↓
이후 요청마다 쿠키 전송
      ↓
서버가 Session ID로 사용자 확인

여기서 중요한 것은 쿠키와 세션이 반드시 둘 중 하나만 선택하는 관계가 아니라는 것이다.

세션을 사용하는 구조에서도 세션 ID를 쿠키로 전달할 수 있다.

그리고 HTTPS를 함께 사용하면 세션 ID나 쿠키가 네트워크를 통해 전달되는 과정도 TLS로 보호할 수 있다.

결국 웹 로그인은 하나의 기술만으로 동작하는 것이 아니라 HTTP, HTTPS, 쿠키, 세션, 인증 같은 여러 개념이 서로 연결되어 만들어진다.

다음 단계에서는 이 흐름을 더 확장해서 웹 브라우저에 주소를 입력했을 때 DNS 조회부터 서버 응답과 화면 출력까지 실제로 어떤 일이 순서대로 일어나는지 살펴보면 지금까지 공부한 네트워크 개념을 한 번에 연결할 수 있다.