◇ PART · WEB

무상태성과 쿠키·세션

웹의 동작 원리 — 읽기 자료

📍 지금 어디를 만지고 있나요?
브라우저
서버
Controller
Service
DB

이 차시의 핵심 용어

무상태성 (Stateless) HTTP 의 본래 성질. 서버는 한 요청이 끝나면 그 손님을 기억하지 못한다. 매번 처음 본 사람처럼 응대한다.
쿠키 (Cookie) 브라우저 쪽에 저장되는 작은 메모. 다음 요청 때 자동으로 함께 보내진다. 사용자가 직접 볼 수 있어서 민감한 정보 저장은 부적절.
세션 (Session) 서버 쪽에 저장되는 정보 보관함. 사용자에게는 「세션 ID」(손목 도장)만 쿠키로 발급. 진짜 정보는 서버 안에 안전히.
JSESSIONID 자바 진영에서 세션 ID 의 표준 이름. 쿠키 형태로 브라우저에 발급됨.

1. 이상한 일

지금까지 우리가 본 HTTP 는 「요청·응답」이 깔끔한 1회성 대화였습니다. 그런데 평소 웹사이트는 안 그렇잖아요? 한 번 로그인하면 페이지를 옮겨도 로그인 상태가 유지됩니다. 어떻게 이게 가능할까요?

서버의 본래 한계

HTTP 는 한 요청을 처리한 뒤 손님과의 연결을 끊습니다. 다음 요청이 오면 — 그게 같은 사람인지 알 길이 없습니다. 매번 잊어버리는 점원과 같습니다. 이를 「무상태성(Stateless)」이라고 부릅니다.

2. 비유 — 매번 잊어버리는 점원

① 손님 : "아메리카노 주세요" 가게 : "여기요" (응대 끝, 손님 잊음) ② 같은 손님 : "이번엔 라떼 주세요" 가게 : "처음 뵙겠습니다, 어떻게 도와드릴까요?" ↑ 방금 손님인 것도 모름

이게 HTTP 의 본래 모습입니다. 그러면 — 쇼핑몰의 장바구니나 로그인은 어떻게 유지되는 걸까요?

3. 두 가지 해결책

쿠키와 세션 — 무상태성을 우회하는 도구

HTTP 가 본래 망각증이니까, 그 위에 「기억할 방법」을 따로 얹어둡니다. 기억을 어디에 두느냐로 두 가지 방식이 생겼습니다.

3-1. 쿠키 — 손님 쪽에 메모

① 처음 방문 손님 → 가게 : "안녕" 가게 → 손님 : "안녕. 이 메모를 들고 다니세요" Set-Cookie: id=abc123 ② 다음 요청 손님 → 가게 : "왔어요. 메모 가지고 있어요" Cookie: id=abc123 가게 → 손님 : "아, 그 손님이군요!"

크롬에서 F12 → Application 탭 → Cookies 에 들어가면 지금 내 브라우저에 저장된 쿠키 목록을 볼 수 있습니다.

3-2. 세션 — 가게 쪽에 보관함

① 로그인 성공 가게 : 금고에 정보 넣음 (이름, 권한, 장바구니, ...) 가게 → 손님 : "이 손목 도장만 들고 다니세요" Set-Cookie: JSESSIONID=xyz789 ② 다음 요청 손님 → 가게 : "도장 보여드려요" Cookie: JSESSIONID=xyz789 가게 : 금고에서 xyz789 의 정보를 꺼냄 → "환영합니다 OO님"
잠깐, 세션도 쿠키를 쓰는 거 아닌가요?

맞습니다. 손님이 들고 다니는 「세션 ID」 자체가 쿠키 형태로 발급됩니다. 다만 진짜 민감한 정보(이름·권한·구매 내역 등)는 가게 안에 있고, 손님은 짧은 ID 만 들고 다닙니다.

4. 한 줄 비교

항목 쿠키 세션
저장 위치브라우저 (사용자 PC)서버 메모리
보안약함 (사용자가 볼·수정 가능)강함 (서버 내부에)
용량작음 (~4KB)
대표 용도장바구니, 다크모드, 비로그인 식별로그인 상태, 사용자 권한

5. 오늘은 여기까지

실제 코드는 Part 5 에서

쿠키와 세션을 코드로 만들고 다루는 건 Part 5 (회원과 게시판) 에서 본격적으로 합니다. 오늘은 「왜 이런 도구가 필요한가」와 「둘이 어디에 저장되는가」 의 큰 그림만 머릿속에 그려두면 충분합니다.

6. Before / After

전 차시 끝

HTTP 메시지의 글자 모양은 알지만, 페이지를 옮길 때마다 「누군지 모르는 문제」는 인식 못함.

이번 차시 끝

HTTP 의 무상태성을 알고, 쿠키·세션이 그 한계를 우회하기 위한 도구임을 안다.