클라이언트의 작은 기억상자, 쿠키

2023-06-09약 4분

웹에서 서버와 클라이언트는 HTTP 프로토콜을 통해 통신합니다.
하지만 HTTP는 본질적으로 Stateless(무상태) 한 프로토콜입니다.
즉, 서버는 사용자가 누구인지, 어떤 행동을 했는지를 기억하지 못합니다.

마치 점원이 손님을 기억하지 못해, 주문을 받을 때마다
“죄송하지만... 어떤 메뉴를 주문하셨죠?”라고 되묻는 것과 같습니다.
이런 특성 때문에 웹은 “사용자의 상태를 기억하는 방법”이 필요했습니다.

그리고 그 해답이 바로 쿠키(Cookie) 였습니다.

기억의 시작, 쿠키의 탄생

쿠키는 1994년, 당시 넷스케이프 커뮤니케이션즈(Netscape Communications) 의
직원이었던 루 몬툴리(Lou Montulli) 라는 엔지니어에 의해 처음 만들어졌습니다.

그가 쿠키를 개발한 이유는 바로 앞에서 이야기한 HTTP의 Stateless 문제 때문이었습니다.
당시 그는 온라인 상점 구축 프로젝트를 돕고 있었는데,
사용자가 물건을 장바구니에 담아도 다른 페이지로 이동하면 정보가 사라지는 문제가 있었습니다.

이 “상태를 기억하는” 문제를 해결하기 위해
루 몬툴리는 브라우저에 작은 데이터를 저장하는 아이디어를 떠올렸습니다.
이는 기존 컴퓨터 네트워크 분야에서 사용되던 ‘매직 쿠키(Magic Cookie)’ 개념을
웹 환경에 적용한 것으로, 오늘날 우리가 알고 있는 HTTP 쿠키의 시작이 되었습니다.

잊지 않기 위한 약속, 쿠키의 역할

쿠키는 브라우저에 작은 데이터 조각을 저장해두고,
사용자가 같은 사이트를 방문할 때 이 데이터를 서버로 다시 전달합니다.
이 과정을 통해 서버는 사용자가 누구인지, 어떤 행동을 했는지를 인식할 수 있습니다.

예를 들어:

로그인 상태 유지
장바구니 정보 저장
사용자 맞춤형 설정(언어, 테마 등) 유지

이 모든 것이 쿠키 덕분에 가능합니다.

쿠키는 어떻게 생겼을까?

쿠키는 실제로 어떻게 생겼을까요? 개발자 도구를 열어보면 쿠키의 진짜 모습을 마주할 수 있습니다.

alt text

쿠키는 기본적으로 이름(Name)과 값(Value)이 한 쌍으로 이루어진 단순한 텍스트 데이터입니다. key=value 형태로 되어있죠. 예를 들면 language=ko 나 theme=dark 와 같은 식입니다. 하지만 쿠키가 강력한 이유는 이 이름-값 쌍에 여러 가지 규칙(속성, Attributes) 을 부여할 수 있기 때문입니다. 서버는 브라우저에게 쿠키를 전달할 때(Set-Cookie 헤더 사용), 다음과 같은 규칙들을 함께 알려줍니다.

Expires / Max-Age: 이 쿠키가 언제 만료될지 (쿠키의 수명)
Domain / Path: 이 쿠키가 어떤 주소(도메인, 경로)에서만 유효할지 (쿠키의 활동 범위)
Secure: HTTPS 연결에서만 이 쿠키를 전송할지 (쿠키의 보안 채널)
HttpOnly: 스크립트가 이 쿠키에 접근하는 것을 막을지 (쿠키의 접근 제어)

브라우저는 이 규칙들을 이름-값 데이터와 함께 고스란히 저장해두었다가, 다음 요청 때 규칙에 맞춰 서버로 쿠키를 다시 전송(Cookie 헤더 사용)합니다. 이제부터 우리는 이 규칙들을 하나씩 자세히 살펴볼 것입니다.

언제까지 기억할까요? - 쿠키의 유효기간

모든 기억이 영원하지 않듯, 쿠키에도 유효기간이 있습니다. 언제까지 기억될 것인가에 따라 쿠키는 두 종류로 나뉩니다.

브라우저를 끄면 사라지는 기억, 세션 쿠키

세션 쿠키(Session Cookie)는 사용자가 웹사이트를 이용하는 동안, 즉 '브라우저 세션'이 살아있는 동안에만 유지되는 임시 기억입니다. 브라우저를 완전히 종료하면 이 기억은 깔끔하게 사라집니다.

여기서 많은 분들이 오해하는 지점이 있습니다. '탭 하나를 닫는 것'과 '브라우저를 종료하는 것'은 다릅니다. 대부분의 최신 브라우저는 탭 하나를 닫아도 다른 탭이 열려있다면 브라우저 프로세스는 살아있습니다. 따라서 탭을 닫고 다시 열어도 로그인이 유지되는 경험, 해보셨을 겁니다.

행동	브라우저 세션	세션 쿠키 상태
새로고침	유지	살아 있음
탭 닫기 후 새 탭 열기	유지 (대부분)	살아있음 (대부분)
브라우저 완전 종료	종료	삭제됨

주로 사용자의 현대 로그인 상태나, 비로그인 장바구니처럼 일시적인 정보를 담는 데 사용됩니다.

날짜를 약속한 기억, 영구 쿠키

영구 쿠키(Persistent Cookie)는 이름처럼 정해진 유효기간까지 사용자의 컴퓨터에 파일 형태로 저장되는 긴 기억입니다. '자동 로그인'이나 '일주일간 이 팝업 보지 않기' 같은 기능이 바로 이 영구 쿠키 덕분입니다. 브라우저를 껐다 켜도, 설령 컴퓨터를 재부팅해도 약속된 날짜가 되기 전까지는 이 기억이 사라지지 않죠. (물론 사용자가 직접 '쿠키 삭제'를 하면 언제든 지울 수 있습니다!)

이 이름표는 누가 만들었나요? - 쿠키의 발행 주체

쿠키는 브라우저에 저장되니 당연히 브라우저가 만드는 것 아니냐고요? 사실 쿠키를 만들고 발행하는 주체는 바로 웹 서버입니다.

마치 주차 관리소(서버)가 방문한 차량(브라우저)에 주차증(쿠키)을 발급해 앞유리에 붙여두라고 지시하는 것과 같습니다. 브라우저는 서버의 지시에 따라 쿠키를 저장하고, 다음 요청 때마다 이 주차증을 관리소에 다시 보여주는 역할을 할 뿐입니다.

이때, 이 주차증을 누가 발행했느냐에 따라 쿠키는 두 종류로 또 나뉩니다.

웹사이트의 기본 기능과 퍼스트파티 쿠키

사용자가 my-shop.com 이라는 쇼핑몰에 방문했을 때, my-shop.com 서버가 직접 발행한 쿠키를 퍼스트파티(First-Party) 쿠키 라고 합니다. 로그인 정보, 장바구니, 언어 설정 등 해당 사이트의 핵심 기능을 위해 사용되는, 가장 기본적이고 필수적인 쿠키입니다.

사용자 추적과 서드파티 쿠키

그런데 쿠키는 항상 내가 방문한 사이트에서만 발행하는 걸까요? 만약 my-shop.com 페이지 한편에 ad-company.com에서 제공하는 광고 배너가 걸려있다면 어떨까요?

웹 브라우저는 my-shop.com의 웹페이지를 화면에 그리기 위해, 페이지에 포함된 광고 배너 이미지를 ad-company.com 서버에 요청해야 합니다. 바로 이 지점에서 서드파티(Third-Party) 쿠키가 등장합니다. 광고를 요청받은 ad-company.com 서버가 응답하면서 자신의 쿠키를 브라우저에 발행하는 것이죠.

이 쿠키의 주인은 my-shop.com이 아닌 ad-company.com입니다.

별일 아닌 것 같지만, 이 작은 차이가 심각한 프라이버시 문제를 낳습니다. 이 쿠키를 이용하면 광고 회사가 여러 사이트에 걸쳐 사용자의 온라인 활동을 추적(Cross-Site Tracking) 할 수 있게 되기 때문입니다.

어떻게 그게 가능할까요? 비밀은 쿠키의 고유 ID와, 요청 정보에 담긴 리퍼러(Referer) 헤더의 조합에 있습니다. 리퍼러는 "어느 페이지를 통해 이곳에 접속했는지"를 알려주는 정보입니다.

A 뉴스 사이트 방문: 사용자가 A 뉴스 사이트를 방문합니다. 이 페이지에 있던 광고 회사(ad-company.com)는 "ID가 abc123인 사용자가 A 뉴스 사이트에서 나를 호출했군"이라는 정보를 기록하고, tracker_id=abc123 쿠키를 발행합니다.
B 쇼핑몰 사이트 방문: 잠시 후 사용자가 B 쇼핑몰로 이동합니다. 여기에도 같은 광고 회사의 배너가 있습니다. 광고를 요청하면서, 브라우저는 이전에 저장했던 tracker_id=abc123 쿠키를 광고 회사 서버로 보냅니다.
광고 서버의 추리: 광고 서버는 abc123 쿠키를 보고 "아는 사람이군!"이라고 인식합니다. 그리고 함께 들어온 리퍼러(Referer) 정보를 통해 "이번엔 B 쇼핑몰에서 나를 호출했네"라는 사실을 알게 됩니다.

결국 광고 회사는 쿠키로 '누구'인지 식별하고, 리퍼러로 '어디에' 있는지 파악하여 사용자의 온라인 행적을 파노라마처럼 수집하게 됩니다. 이 심각한 프라이버시 침해 문제 때문에, 최근 구글 크롬을 비롯한 대부분의 브라우저가 이 서드파티 쿠키를 차단하는 방향으로 나아가고 있습니다.

"이 길은 안전하지 않아요!" - Secure 쿠키

쿠키에는 보안을 위해 강력한 옵션들을 추가할 수 있습니다. 그 첫 번째가 바로 Secure 입니다.

HTTPS는 통신 내용을 암호화하여 중간에 가로채도 알아볼 수 없게 만드는 안전한 통로입니다. 반면 HTTP는 모든 내용이 그대로 노출되는 위험한 통로죠. Secure 옵션이 붙은 쿠키는 브라우저에게 이렇게 말합니다.

"나는 오직 안전한 HTTPS 길로만 다닐 거야! 위험한 HTTP 길로는 절대 가지 않겠어."

만약 개발자의 실수로 사이트의 링크 하나가 'http://'로 연결되어 있더라도, 브라우저는 이 Secure 쿠키를 HTTP 요청에 포함시키지 않아 민감한 정보가 유출되는 것을 원천적으로 막아줍니다.

"스크립트, 내 정보에 손대지 마!" - HttpOnly 쿠키

웹사이트 게시판에 심어진 악성 스크립트가 document.cookie 라는 명령어로 브라우저에 저장된 쿠키를 훔쳐 공격자의 서버로 전송하는 공격을 XSS(Cross-Site Scripting) 라고 합니다. 만약 로그인 세션 ID가 담긴 쿠키를 도둑맞는다면, 공격자는 내 계정으로 마음대로 로그인할 수 있게 되겠죠.

HttpOnly 옵션은 이 공격을 막는 결정적인 방패입니다. 이 옵션이 붙은 쿠키는 브라우저에게 이렇게 명령합니다.

"나는 오직 서버와 통신할 때만 사용될 거야. 이 웹페이지의 어떤 JavaScript도 나를 읽거나 접근할 수 없어."

브라우저는 이 명령을 충실히 이행하여, document.cookie가 실행되어도 HttpOnly 쿠키 정보는 쏙 빼고 보여줍니다. 악성 스크립트는 가장 중요한 정보를 훔치지 못하고 좌절하게 됩니다. 세션 ID처럼 민감한 정보에는 이제 선택이 아닌 필수로 여겨지는 옵션입니다.

맺으며

지금까지 클라이언트의 작은 기억상자, 쿠키에 대해 알아보았습니다. 쿠키는 단순히 정보를 저장하는 조각이 아니라, 언제 사라질지(유효기간), 누가 만들었는지(발행 주체), 그리고 어떤 보안 규칙을 따를지(Secure, HttpOnly)가 정해지는 매우 정교한 장치였습니다.