쿠키의 용량 제한은 얼마인가요?

쿠키 용량 제한 가이드: 개별 4KB 용량 및 도메인당 최대 180개 제한 규격

웹 서비스 개발이나 운영 시 쿠키 용량 제한을 정확하게 파악하는 과정은 데이터 손실을 방지하는 핵심적인 단계입니다. 브라우저가 허용하는 범위를 초과하면 중요한 사용자 정보가 제대로 저장되지 않아 예기치 못한 서비스 오류가 발생합니다. 효율적인 웹 환경 구축과 안정적인 데이터 관리를 위해 상세한 저장 규격과 정책을 미리 확인하여 대응하십시오.

쿠키 용량 제한의 핵심 수치와 브라우저의 기본 동작

웹 브라우저에서 개별 쿠키의 최대 용량 제한은 4KB(4,096바이트)입니다. 이 수치는 쿠키의 이름(Name), 값(Value), 그리고 만료일이나 경로와 같은 속성(Attributes)을 모두 합산한 크기를 의미합니다. 하나의 도메인당 쿠키 제한 개수는 브라우저마다 차이가 있지만 보통 50개에서 180개 사이입니다. ^[2]

최근 벤치마크 데이터에 따르면 구글 크롬과 마이크로소프트 엣지는 도메인당 최대 180개의 쿠키를 허용하는 반면, 사파리와 파이어폭스는 약 150개 수준에서 제한을 거는 경우가 많습니다. 전체 쿠키의 총 용량이 도메인당 10KB를 넘어가면 네트워크 요청 헤더가 비대해져 서버에서 431 Request Header Fields Too Large 에러를 반환할 가능성이 있습니다. 성능 최적화를 고려한다면 실제 데이터는 2KB 이내로 유지하는 것이 가장 안전합니다. ^[3]

저도 예전에 JWT(JSON Web Token)를 쿠키에 담아 보냈다가 특정 사용자들만 로그인이 안 되는 기이한 현상을 겪은 적이 있습니다. 알고 보니 그 사용자의 토큰에 담긴 권한 정보가 너무 많아 4KB를 살짝 초과했던 것이었죠. 브라우저는 용량 제한을 넘기는 순간 아무런 경고 없이 쿠키 저장을 거부합니다. 정말 당혹스러운 순간이었습니다. 그 이후로는 쿠키 크기를 체크하는 로직을 반드시 넣게 되었습니다. 단순하지만 치명적인 규칙입니다.

브라우저별 쿠키 제한의 세부 사항

대부분의 현대적 브라우저는 RFC 6265 표준을 따르지만, 실제 구현 방식에서는 사용자 경험을 위해 미세한 차이를 둡니다. 이는 개발자가 서비스의 타겟 사용자가 주로 사용하는 브라우저 환경을 이해해야 하는 이유이기도 합니다.

도메인당 개수와 총 용량의 상관관계

일반적으로 브라우저가 보장해야 하는 최소 기준은 쿠키당 4,096바이트, 도메인당 최소 50개입니다. 하지만 실제 환경에서는 브라우저 쿠키 개수 제한에 다음과 같은 변동폭이 존재합니다. 크롬 및 엔진 기반 브라우저: 도메인당 180개까지 허용하며, 개별 크기가 4,096바이트를 넘으면 즉시 무시됩니다. 파이어폭스: 최대 150개의 쿠키를 저장할 수 있으며, 용량 계산 시 세미콜론과 공백 등 구분자까지 엄격하게 포함합니다. 사파리: 개수 제한은 관대한 편이지만, 전체 헤더 크기 제한에 걸려 요청 자체가 차단될 위험이 다른 브라우저보다 높습니다.

재미있는 점은 서브도메인 간의 공유 문제입니다. 만약 blog.example.com과 shop.example.com이 각각 쿠키를 생성한다면, 이들은 example.com이라는 부모 도메인의 전체 개수 제한을 공유하게 됩니다. 통계에 따르면 복잡한 서브도메인 구조를 가진 엔터프라이즈 급 웹사이트의 15% 가량이 자신도 모르는 사이에 도메인 총 개수 제한에 도달하여 기존 쿠키가 삭제되는 현상을 경험합니다.

왜 쿠키는 4KB로 제한될까요?

이 제한은 단순히 과거의 유물이 아닙니다. 쿠키는 로컬 스토리지와 달리 모든 HTTP 요청이 발생할 때마다 서버로 전송됩니다. 만약 쿠키 용량이 5MB였다면, 웹사이트 내에서 이미지를 하나 클릭할 때마다 5MB의 데이터를 서버에 업로드해야 한다는 뜻입니다.

HTTP 요청 헤더에 포함되는 쿠키의 크기가 증가할 때마다 페이지 로드 시간(TTFB)이 지연될 수 있습니다. 전 세계 웹 트래픽의 상당수가 모바일 환경에서 발생한다는 점을 고려하면, 쿠키 4KB 제한 이유는 네트워크 대역폭 낭비를 막기 위한 최후의 보루와 같습니다. 쿠키 크기를 최적화했을 때 모바일 환경에서의 페이지 반응 속도가 개선되었다는 지표도 있습니다. ^[5]

결국 기술적인 제약이라기보다 성능을 위한 강제적인 약속에 가깝습니다. 하지만 가끔은 이 좁은 공간이 답답하게 느껴질 때가 있습니다. 꼭 필요한 데이터만 넣어야 한다는 압박감은 개발자를 더 효율적인 설계로 이끌기도 하지만, 때로는 단순한 기능 구현조차 복잡하게 만듭니다. 적은 것이 많은 것이다라는 격언이 쿠키 설계만큼 잘 들어맞는 곳도 드뭅니다.

용량 제한 초과 시 발생하는 문제와 해결법

쿠키 용량 제한이 한계에 다다르면 브라우저는 가장 오래된 쿠키를 자동으로 삭제하거나 새 쿠키 저장을 거부합니다. 이는 사용자 세션이 갑자기 끊기거나 장바구니 데이터가 사라지는 등의 심각한 사용자 경험 저하로 이어집니다.

대표적인 증상과 진단 방법

용량 초과가 의심된다면 쿠키 사이즈 확인 방법으로 개발자 도구(F12)의 Application 탭을 확인해 보세요. Size 컬럼에서 각 쿠키의 실제 바이트 크기를 확인할 수 있습니다. 만약 특정 쿠키의 크기가 4,000바이트에 근접해 있다면 이미 위험 신호입니다. 서버 측 로그에서 431 혹은 400 Bad Request 에러가 빈번하게 찍힌다면 90% 이상의 확률로 쿠키를 포함한 헤더 크기 문제입니다.

해결 방법은 명확합니다. 쿠키에는 식별자(ID)만 담고, 실제 데이터는 서버의 데이터베이스나 세션에 저장하는 방식입니다. 혹은 브라우저에 데이터를 저장해야 한다면 쿠키가 아닌 웹 스토리지를 활용하는 것이 좋습니다. 웹 스토리지는 쿠키보다 약 1,000배 큰 용량을 제공하기 때문입니다. 잠깐, 그런데 이쯤에서 고민이 생길 겁니다. 언제 쿠키를 쓰고 언제 웹 스토리지를 써야 할까요?

클라이언트 사이드 저장소 비교: 쿠키 vs 웹 스토리지

쿠키 (Cookie)

• 개당 4KB (도메인당 총 10KB 내외 권장)
• 설정된 만료일 또는 세션 종료 시까지 유지
• 모든 HTTP 요청 시 헤더에 포함되어 자동 전송
• 세션 관리, 사용자 인증 토큰, 개인화 설정

로컬 스토리지 (Local Storage) ⭐

• 도메인당 5MB - 10MB (쿠키의 약 1000배)
• 영구적 (사용자가 직접 삭제하거나 코드로 지우기 전까지)
• 서버로 자동 전송되지 않음 (필요할 때만 수동 전송)
• 자동 완성 데이터, UI 상태 저장, 비민감 캐시 데이터

세션 스토리지 (Session Storage)

• 도메인당 약 5MB
• 탭이나 창을 닫으면 즉시 삭제됨
• 서버로 자동 전송되지 않음
• 일회성 입력 폼 데이터, 현재 탭의 상태 유지

스타트업 A사의 로그인 장애 탈출기

서울의 에듀테크 스타트업 개발자 김 씨는 서비스 고도화 중 특정 우수 회원들의 로그인이 반복적으로 풀리는 문제를 발견했습니다. 내부 테스트 서버에서는 멀쩡했기에 팀원들 모두 당황스러운 상태였죠.

초기에는 서버 세션 타임아웃 설정을 의심하며 며칠을 허비했습니다. 하지만 로그를 분석해 보니 서버에는 요청조차 도달하지 않는 경우가 허다했습니다. 원인은 사용자의 학습 진도 정보를 무분별하게 쿠키에 담았던 것이었습니다.

쿠키 크기가 4KB를 넘어서자 브라우저가 인증 쿠키까지 포함하여 전송을 거부하거나 서버 헤더 제한에 걸렸음을 깨달았습니다. 결국 김 씨는 진도 데이터를 로컬 스토리지로 옮기고 쿠키에는 세션 ID만 남겼습니다.

적용 후 로그인 성공률은 100%로 회복되었고, 요청당 헤더 크기가 80% 감소하면서 전체 API 응답 속도가 약 45ms 단축되었습니다. 김 씨는 기술 문서의 수치를 맹신하기보다 실제 네트워크 패킷을 보는 것의 중요성을 체감했습니다.