쿠키, 세션, jwt 개념

김대은·2026년 7월 23일

쿠키

1. 쿠키(Cookie)란?

웹 서버가 사용자의 브라우저(기기)에 저장하는 작은 텍스트 데이터 파일입니다. 여기에는 사용자를 식별할 수 있는 간단한 정보들이 담깁니다.

2. 쿠키가 왜 필요할까요?

인터넷(HTTP 프로토콜)은 기본적으로 무상태성(Stateless)이라는 성질을 가집니다. 사용자가 방금 전에 무슨 행동을 했는지 서버가 아무것도 저장하지 않고 다 까먹어 버리는 성질입니다.

Q. 그냥 서버가 다 저장(기억)하면 안 되나요?

과부하 위험: 수많은 사용자가 몰릴 때 서버가 모든 사람을 다 기억하려고 하면 서버가 터져버립니다.
서버 확장 불가: 여러 대의 서버로 일을 나눠서 처리하기도 힘들어집니다.

➔ 해결책은 '쿠키'입니다.
서버가 모든 정보를 직접 기억하는 대신, 사용자(브라우저) 주머니에 쿠키(번호표)를 쥐어줍니다. 다음에 이 번호표를 들고 오면 서버는 "아, 이 사람이구나" 하고 알아차립니다.

단, 쿠키 자체는 번호표일 뿐이고, 그 번호표가 가리키는 실제 정보(로그인 여부 등)는 서버(세션) 또는 번호표 안(JWT)에 따로 저장됩니다.

3. 쿠키의 동작 원리

쿠키는 다음과 같이 주고받으며 작동합니다.

서버의 발급
* 서버는 HTTP 응답 헤더의 Set-Cookie 필드를 통해 쿠키를 보냅니다.
브라우저의 저장
* 브라우저는 전달받은 이 쿠키를 자체 저장소에 저장해 둡니다.
자동 제출
* 이후 같은 서버로 요청을 보낼 때마다, 브라우저는 HTTP 요청 헤더의 Cookie 필드에 이 값을 자동으로 포함시켜 보냅니다.

4. 쿠키의 역할

서버는 브라우저가 매번 들고 오는 쿠키를 보고 사용자를 알아차립니다.

로그인 상태 유지 (페이지를 이동해도 로그아웃되지 않음)
장바구니 정보 유지
사용자 선호 설정 저장 (언어, 다크모드 테마 등)
사용자 행동 추적과 분석 (광고 타겟팅 등)

5. 쿠키의 유효 기간(종류)

세션 쿠키 : 만료일이 따로 지정되지 않은 쿠키 ( 브라우저 전체를 종료하면 자동으로 삭제 )
지속 쿠키 : 만료일이나 유지 시간(Max-Age, Expires)을 지정한 쿠키입니다. 브라우저를 꺼도 컴퓨터에 남아있다가 지정한 시간이 지나야 삭제됩니다. (예: "일주일간 이 창 보지 않기", "아이디 저장")

6. 쿠키의 한계와 취약점

보안에 취약함 : 쿠키는 사용자 컴퓨터에 텍스트로 저장되고 매번 네트워크를 통해 왔다 갔다 하므로, 해커가 가로채거나 임의로 조작하기 쉽습니다. (비밀번호 같은 민감한 정보를 담으면 안 되는 이유)
용량 제한 : 브라우저마다 다르지만, 쿠키 하나의 크기는 4KB로 아주 작고, 한 사이트당 담을 수 있는 개수도 제한되어 있어서 큰 데이터를 담을 수 없습니다.
모바일 앱(App) 환경에서의 불편함: 웹 브라우저와 달리 모바일 앱 환경에서는 쿠키를 자동으로 주고받고 저장하는 기능이 잘 갖춰져 있지 않아, 관리가 까다롭고 불편합니다.

세션

1. 세션(Session)이란?

위에서 쿠키의 약점이 "보안이 취약하다"였습니다
➔ 이 문제를 해결하기 위해서 등장한게 세션(Session)입니다.

세션 : 세션(Session)은 클라이언트와 서버 간의 연결을 유지하고, 특정 사용자에 대한 상태를 저장하는 기술이다.

사용자의 민감한 정보(개인 정보, 비밀번호 등)를 브라우저에 직접 저장하는 대신
서버 메모리(또는 데이터베이스)에 저장하고, 브라우저에는 오직 이 정보를 접근할 수 있는 세션 ID만 쿠키를 통해 쥐어주는 방식입니다.

2. 세션의 동작 방식

1. 세션 생성

사용자가 로그인해서 고유한 세션 ID를 생성
세션 ID는 *UUID와 같이 예측할 수 없는 값으로 생성
서버는 이 세션ID를 키(key)로 하고, 사용자의 정보를 값(value)으로 하는 세션을 저장소에 저장

2. 세션 유지

서버는 생성된 세션id를 클라이언트에게 쿠키를 통해 전달
클라이언트는 이후 요청 시마다 이 쿠키(세션ID)를 서버에 전송

3. 세션 확인

서버는 요청에 전달된 세션ID를 확인하고, 세션 저장소에서 해당 세션을 조회
세션이 유효하면 사용자 정보를 가져와 인증 및 인가를 처리

4. 세션 종료

로그아웃하거나 세션이 만료되면 서버는 해당 세션을 삭제
클라이언트의 쿠키에 저장된 세션ID는 더 이상 유효하지 않음

UUID : UUID는 중앙 서버의 통제 없이도 전 세계에서 절대 중복되지 않도록 고유성을 보장하는 36자리의 범용 고유 식별자 문자열입니다.

3. 세션의 단점(한계)

메모리 부족 : 서버 메모리에 사용자 정보를 저장하므로, 접속자가 많아지면 메모리 사용량이 크게 늘어납니다
속도 저하 : 매 요청마다 세션 저장소를 조회해야 하므로, 요청이 많아지면 그 조회 비용만큼 서버에 부하가 걸려 응답이 느려집니다.
서버 확장 어려움 : 여러 대의 서버를 쓰는 환경에서는 다른 서버로 접속이 바뀔 때 기존 세션 정보를 찾지 못하는 문제가 있습니다
세션 탈취 : 해커가 세션 탈취(*세션 하이재킹)를 할 수도 있습니다.

세션 하이재킹 : 사용자의 로그인 번호표(세션 ID)를 중간에서 가로채(Hijack), 내가 그 사용자인 척 서버를 속이는 공격

JWT

1. JWT(Json Web Token)란?

JWT는 클라이언트와 서버 간에 정보를 안전하게 주고받기 위해 사용하는 JSON 객체 기반의 웹 표준 인증 토큰입니다.

2. JWT가 필요한 이유?

서버 확장성 (Scalability): 토큰 자체에 사용자 정보가 있어 여러 서버 중 어디로 요청해도 인증이 가능합니다.
무상태성 (Stateless): 서버가 사용자의 로그인 상태를 기억(세션 저장소 등)할 필요가 없습니다.
데이터베이스 부하 감소: 매 요청마다 DB나 세션 메모리를 확인하지 않고 서명으로 검증합니다.
다양한 플랫폼 지원: 웹 브라우저뿐만 아니라 모바일 앱 등 다양한 환경에서 간편하게 인증을 처리할 수 있습니다.

비교 항목	세션 (Session) 방식	JWT (JSON Web Token) 방식
데이터 저장소	서버의 메모리(RAM) 또는 데이터베이스(DB)	사용자 클라이언트 (로컬 스토리지 / 쿠키)
인증 방식	서버가 세션 ID를 확인하여 회원 정보 조회	서버는 토큰의 암호화 서명(Signature)만 검증
서버 확장성	구조가 복잡해지면 세션 동기화(Cluster) 필요	토큰만 검증하면 되므로 서버 확장이 매우 자유로움
메모리 부담	동시 접속자가 많을수록 서버 메모리 부하 급증	서버가 상태를 저장하지 않아(Stateless) 부하 없음
토큰 제어 권한	서버에서 세션을 삭제하여 강제 로그아웃 가능	한 번 발급된 토큰은 만료 전까지 강제 회수 불가
추천 환경	단일 서버 기반의 웹 서비스, 보안이 중요한 서비스	MSA(마이크로서비스), 모바일 앱, 대규모 분산 서버

3. JWT의 구성요소

JWT는 헤더(Header), 페이로드(Payload), 서명(Signature) 세 파트로 나눠져 있으며, 각 파트는 점(.)으로 구분됩니다.

헤더 (Header)
어떠한 알고리즘으로 암호화할 것인지, 어떠한 토큰을 사용할 것인지에 대한 정보가 들어있습니다.
페이로드 (Payload)
전달하려는 정보(사용자 ID, 데이터들)가 들어있습니다. 이 안에 들어가는 데이터 조각들을 클레임이라고 부릅니다. Payload에 있는 내용은 수정이 가능하며 더 많은 정보를 추가할 수 있습니다. 그러나 누구나 열어볼 수 있도록 노출된 지점이기 때문에 비밀번호 같은 민감한 개인정보는 절대 담으면 안 되며, 인증이 필요한 최소한의 정보(사용자 고유 식별 ID, 권한 범위, 토큰의 발급/만료 시간 등)만을 담아야 합니다.
서명 (Signature)
가장 중요한 부분으로 헤더와 정보를 합친 후 발급해 준 서버가 지정한 secret key로 암호화시켜 토큰을 변조하기 어렵게 만들어줍니다. 예를 들어 토큰이 발급된 후 누군가 Payload의 정보를 수정하면 Payload의 정보는 조작된 내용으로 바뀌지만, 서명 부분은 수정되기 전의 내용을 기반으로 이미 암호화되어 있기 때문에 결과값이 다르게 나옵니다. 서버는 이 두 값을 비교하여 토큰이 조작되었는지 쉽게 알 수 있고, 해커가 조작된 토큰을 악용하기 어렵게 만듭니다.

클레임(Claim) : 토큰 안에 담긴 사용자 ID, 이름, 권한 등의 회원 데이터 조각 하나하나를 의미합니다.

4. JWT의 동작 원리

사용자가 ID와 Password를 입력하여 로그인 요청을 한다.
서버는 회원 DB에 들어가 있는 사용자인지 확인한다.
확인이 되면 서버는 로그인 요청 확인 후, secret key를 통해 토큰을 발급한다.
발급한 토큰을 클라이언트에 전달한다. (출입증 발급)
서비스 요청: 클라이언트가 서버에 게시글 작성, 내 정보 보기 등 특정 서비스를 요청할 때, 앞서 받은 JWT를 HTTP 요청 헤더(Authorization)에 담아서 함께 보냅니다. (출입증 제시)
토큰 검증 및 인가: 서버는 헤더에 담긴 JWT의 서명(Signature)을 비밀키로 검증하여 위조되지 않았는지 확인하고, Payload의 정보를 읽어 이 사용자가 요청한 권한이 있는지 확인합니다. (출입증의 위조 여부 검사)
클라이언트 요청에 대한 응답과 요청한 데이터를 전달해 준다.

데이터(JWT) : 서버에서 발급받아 브라우저가 가지고 있던 토큰(JWT) 즉, '출입증 자체'를 의미합니다.

요약
토큰 기반 인증 방식은 사용자의 인증이 완료된 이후에 토큰(출입증)을 발급합니다. 클라이언트 쪽에서는 전달받은 토큰(출입증)을 저장해 두고 서버에 요청을 할 때마다 함께 전달하며, 서버는 이 출입증을 자체적으로 검증하고 응답하는 방식으로 작동합니다.

5. 클레임 토큰

클레임 토큰이란?

위에서 말한 여러 개의 클레임(정보 조각)들을 모아서 안전하게 포장해 놓은 '토큰 전체'를 의미합니다. 회사의 직인이 찍혀 있고 주인의 이름과 부서가 적힌 '완성된 사원증(출입증)'으로 비유할 수 있습니다. (우리가 배우는 JWT가 대표적인 클레임 토큰입니다.)

일반 토큰과 클레임 토큰의 차이점

기존 (세션 / 일반 토큰): 기존의 일반 토큰 기반 인증은 토큰을 검증할 때 필요한 관련 정보들을 서버에 저장해 두고 있었습니다. 그래서 정보를 확인하려면 항상 DB에 접근해야 했습니다. Session 방식 또한 서버 저장소에서 Session ID를 찾아와 검증하는 절차를 거쳐야 하므로 다소 번거롭게 느껴졌습니다.
JWT (클레임 토큰): 클레임 토큰 기반의 JWT는 사용자 인증에 필요한 모든 정보를 토큰 자체에 담고 있기 때문에 별도의 인증 저장소가 필요 없습니다. 서버가 여러 대로 쪼개져 있는 환경(MSA)에서도, 각 서버가 중앙 DB에 일일이 물어볼 필요 없이 토큰(출입증)만 보고 스스로 로그인 여부를 확인할 수 있어서 훨씬 편리합니다.

비교 항목	일반 토큰 방식 (의미 없는 랜덤 문자열)	클레임 토큰 방식 (정보를 담은 JWT)
토큰의 형태	유저 정보와 연결된 단순한 랜덤 문자열/Key	유저 정보가 인코딩되어 담겨 있는 데이터 덩어리
정보의 최신성	DB를 항상 새로 조회하므로 실시간 데이터 반영	발급 당시 정보가 고정되어 실시간 반영 불가
네트워크 부하	토큰 크기가 작아 네트워크 전송이 가벼움	유저 정보를 담고 있어 데이터 크기(무게)가 상대적으로 큼
인증 독립성	검증을 위해 항상 중앙 인증 DB에 의존해야 함	중앙 DB 없이 서버 단독으로 즉시 검증 가능

김대은

da2un

이전 포스트

Docker Hub(도커 허브),Docker Compose(도커 컴포즈)

다음 포스트