HTTP Cookie

웹에서 가장 근본적인 불편 하나는, HTTP가 이전 요청을 기억하지 않는다는 것입니다. 사용자가 로그인 폼에 아이디와 비밀번호를 입력하고 확인을 누르면 서버는 그 순간에는 누구인지 압니다. 하지만 바로 다음 페이지로 넘어가면 서버 입장에서 이 요청은 완전히 새로운 낯선 요청입니다. 장바구니에 상품을 담고 결제 페이지로 가면 장바구니가 비어 있고, 다크 모드를 켜고 새로고침하면 밝은 화면이 다시 나옵니다. 매 요청마다 사용자에게 다시 로그인하라고 할 수는 없습니다. 서버 혼자서 모든 사용자의 상태를 기억하자니, 그 사용자가 보낸 요청인지 식별할 고리가 없습니다. HTTP의 무상태 설계는 프로토콜을 단순하게 만들지만, 연속적인 사용자 경험을 만드는 데는 빈 공간을 남깁니다.

1990년대 초 웹은 문서를 가져다 읽는 용도였습니다. 한 페이지를 요청하고 응답받으면 그걸로 끝이었고, 이전 요청을 기억할 이유도 없었습니다. 하지만 전자 상거래가 등장하면서 상황이 바뀌었습니다. 사용자가 상품을 고르고, 장바구니에 담고, 결제까지 이어지려면 여러 요청에 걸쳐 같은 사용자라는 사실을 어딘가에 묶어 둬야 했습니다. 1994년 Netscape의 엔지니어 루 몬톨리(Lou Montulli)가 제안한 해결책이 쿠키입니다. 서버가 응답에 작은 텍스트 조각을 실어 보내고, 브라우저가 그걸 저장해 두었다가 다음 요청에 다시 붙여 보내는 방식이었습니다. HTTP를 바꾸지 않고도 상태를 이어 붙일 수 있는 실용적인 우회였고, 이후 RFC 2109와 RFC 6265로 표준화되면서 웹의 기본 인프라가 됐습니다.

쿠키의 동작은 서버가 심고 브라우저가 돌려보내는 순환 구조입니다. 서버가 HTTP 응답에 Set-Cookie 헤더를 포함하면, 브라우저는 그 이름-값 쌍을 해당 도메인의 쿠키 저장소에 보관합니다. 이후 같은 도메인으로 요청을 보낼 때 브라우저는 저장된 쿠키를 Cookie 헤더에 자동으로 실어 보냅니다. 개발자가 별도로 요청 코드를 수정할 필요가 없습니다. Set-Cookie에는 이름과 값 말고도 여러 속성이 붙습니다. Domain과 Path는 이 쿠키가 어떤 요청에 첨부될지 범위를 정합니다. Expires나 Max-Age는 수명을 정하는데, 이 속성이 없으면 브라우저를 닫을 때 사라지는 세션 쿠키가 됩니다. 보안 측면에서는 Secure를 붙이면 HTTPS 연결에서만 전송되고, HttpOnly를 붙이면 JavaScript에서 접근할 수 없어 XSS 공격에 쿠키가 탈취되는 위험을 줄입니다. SameSite 속성은 다른 사이트에서 온 요청에 쿠키를 포함할지를 제어해 CSRF 공격을 방어하는 데 쓰입니다. 브라우저마다 도메인당 저장할 수 있는 쿠키 수와 전체 크기에 제한이 있고, 보통 하나의 쿠키는 4KB 정도가 상한입니다. 쿠키는 매 요청에 자동으로 포함되기 때문에, 쿠키가 많고 크면 그만큼 요청마다 네트워크 오버헤드가 늘어납니다.

쿠키와 Web Storage(localStorage, sessionStorage)는 둘 다 브라우저에 데이터를 저장한다는 점에서는 비슷합니다. 결정적 차이는 서버 전송 여부입니다. 쿠키는 해당 도메인으로의 모든 HTTP 요청에 자동으로 포함됩니다. Web Storage는 브라우저 안에서만 존재하고, 서버로 보내려면 개발자가 직접 꺼내서 요청에 실어야 합니다. 이 차이가 용도를 나눕니다. 서버가 매 요청에서 사용자를 식별해야 하는 인증, 세션 관리에는 쿠키가 적합합니다. 서버로 보낼 필요 없이 클라이언트 쪽에서만 쓰는 UI 상태, 임시 데이터에는 Web Storage가 낫습니다. 용량 면에서도 쿠키는 4KB, Web Storage는 5~10MB로 차이가 크기 때문에, 대량의 데이터를 쿠키에 넣으면 매 요청의 크기가 불필요하게 커집니다. 쿠키와 JWT도 자주 비교됩니다. 쿠키는 데이터를 나르는 운반체이고, JWT는 데이터의 포맷입니다. 실제로 JWT를 쿠키에 담아 보내는 것이 일반적인 조합이고, JWT를 쿠키 대신 Authorization 헤더에 담는 방식도 있습니다. '쿠키 vs JWT'라는 질문은 성격이 다른 둘을 비교하는 것이라, '서버 세션 + 쿠키 vs JWT + 쿠키(또는 헤더)'로 보는 것이 더 정확합니다.

쿠키는 웹 인증의 가장 기본적인 고리로, 로그인 후 세션 ID를 쿠키에 담아 이후 요청마다 사용자를 식별하는 패턴이 오래전부터 표준처럼 자리잡았습니다. 서버 렌더링 기반 사이트에서는 페이지 요청 자체에 인증 정보가 필요하기 때문에, 자동 전송되는 쿠키가 거의 유일한 선택지입니다. 쿠키를 다룰 때 실무에서 자주 마주치는 판단은 보안 속성 설정입니다. HttpOnly를 빠뜨리면 XSS 취약점이 생겼을 때 스크립트가 세션 쿠키를 그대로 읽을 수 있고, SameSite를 None으로 두면 CSRF에 노출됩니다. Secure 없이 HTTP로 쿠키를 보내면 중간에서 가로챌 수 있습니다. 보안 사고 상당수가 이 속성 설정 누락에서 시작되기 때문에, 쿠키를 발급할 때 속성부터 점검하는 습관이 중요합니다. 한편 서드파티 쿠키는 개인정보 보호 규제 강화와 브라우저의 차단 정책으로 제약이 커지고 있습니다. 추적 목적의 쿠키 사용은 점점 줄어드는 추세이고, 퍼스트파티 쿠키 중심의 설계가 앞으로의 기본 방향입니다.

다음에 볼 개념

함께 보면 좋은 개념