브라우저 캐시 완벽 가이드 - HTTP 캐싱의 모든 것

캐시가 필요한 이유

웹 페이지를 열 때마다 HTML, CSS, JavaScript, 이미지 등 수많은 리소스를 서버에서 내려받습니다. 매번 동일한 리소스를 반복해서 받는 것은 네트워크 트래픽 낭비이자 사용자 경험 저하의 원인이 됩니다.

HTTP 캐싱은 이전에 가져온 리소스를 재사용하여 이 문제를 해결합니다. 캐시의 핵심은 저장(Store)과 재사용(Reuse) 두 단계로 구성되며, 브라우저는 이 과정을 강력 캐시와 협상 캐시라는 두 가지 전략으로 처리합니다.

이 글에서는 캐시의 종류부터 동작 흐름, 각 전략의 세부 동작, 리소스별 캐시 설정, 무효화 방법까지 순서대로 정리합니다.

캐시의 종류

저장 위치에 따른 분류

브라우저 캐시는 저장 위치에 따라 Memory Cache와 Disk Cache로 나뉩니다.

캐시 계층에 따른 분류

캐시는 브라우저에만 존재하는 것이 아닙니다. 클라이언트에서 서버까지의 경로에 여러 계층의 캐시가 존재합니다.

클라이언트 (브라우저)
  └── Private Cache (개인 캐시)
        ├── 특정 사용자 전용
        └── Cache-Control: private
 
중간 서버
  └── Shared Cache (공유 캐시)
        ├── Proxy Cache ─ ISP, 기업 프록시 서버
        └── Managed Cache ─ CDN, Reverse Proxy, Service Worker
 
원본 서버 (Origin Server)

• Private Cache: 브라우저에만 저장되는 캐시입니다. Cache-Control: private으로 설정하면 CDN이나 프록시 서버에서는 캐시하지 않습니다.
• Shared Cache: 여러 사용자가 공유하는 캐시입니다. CDN(CloudFront, Cloudflare 등)이나 Reverse Proxy(Nginx, Varnish)가 대표적입니다.

캐시 동작 흐름

브라우저가 리소스를 요청할 때, 캐시를 확인하는 과정은 다음과 같습니다.

핵심은 강력 캐시가 먼저, 만료되면 협상 캐시가 동작한다는 점입니다. 이제 각 전략을 자세히 살펴보겠습니다.

강력 캐시 (Strong Cache)

강력 캐시는 서버에 요청하지 않고 로컬 캐시에서 즉시 리소스를 반환하는 방식입니다. 네트워크 통신이 전혀 없으므로 가장 빠릅니다.

Cache-Control 헤더

Cache-Control은 HTTP/1.1에서 도입된 캐시 제어 헤더입니다.

Cache-Control: max-age=31536000

주요 디렉티브를 표로 정리하면 다음과 같습니다.

no-cache vs no-store

이름이 혼동을 주는 대표적인 디렉티브입니다.

no-cache
├── 캐시에 저장한다
├── 사용할 때마다 서버에 검증 요청을 보낸다
├── 서버가 304 응답하면 캐시 재사용 (본문 전송 없음)
└── "캐시하되, 항상 확인하고 써라"
 
no-store
├── 캐시에 저장하지 않는다
├── 매번 서버에서 전체 리소스를 다시 받는다
└── "절대 캐시하지 마라"

must-revalidate의 역할

max-age가 만료된 후의 동작에 차이가 생깁니다.

네트워크가 불안정한 환경에서 오래된 데이터가 표시되는 것을 방지할 때 유용합니다.

Expires와 Pragma (레거시)

HTTP/1.0에서 사용하던 헤더입니다.

Expires: Wed, 21 Oct 2026 07:28:00 GMT
Pragma: no-cache

• Expires: 절대 시간으로 만료일을 지정합니다. 클라이언트와 서버의 시계가 다르면 문제가 발생할 수 있습니다.
• Pragma: Cache-Control: no-cache와 동일한 역할입니다. HTTP/1.0 하위 호환용으로만 사용합니다.

헤더 우선순위는 Cache-Control > Expires > Pragma 순입니다. Cache-Control: max-age와 Expires가 함께 있으면 max-age가 우선됩니다.

협상 캐시 (Negotiated Cache)

강력 캐시가 만료(Stale)된 후, 서버에 "리소스가 변경되었는지" 확인하는 방식입니다. 변경이 없으면 본문 없이 304 Not Modified만 응답하므로, 전체 리소스를 다시 받는 것보다 훨씬 효율적입니다.

ETag / If-None-Match (권장)

ETag는 리소스의 내용을 기반으로 생성된 고유 식별자(해시값)입니다.

ETag는 Strong ETag("33a64df5")와 Weak ETag(W/"33a64df5")로 나뉩니다. Strong ETag는 바이트 단위 완전 일치를 요구하고, Weak ETag는 의미적 동등성만 확인합니다.

Last-Modified / If-Modified-Since

파일의 마지막 수정 시간을 기준으로 비교하는 방식입니다.

ETag vs Last-Modified 비교

휴리스틱 캐싱

휴리스틱 캐싱은 Cache-Control이나 Expires가 없을 때, 브라우저가 자체적으로 캐시 기간을 추정하는 방식입니다.

동작 조건

• Cache-Control 헤더 없음
• Expires 헤더 없음
• Last-Modified 헤더 있음

캐시 기간 계산

캐시 기간 = (현재 시간 - Last-Modified) × 10%

예를 들어, 마지막 수정 후 1년(365일)이 경과했다면 캐시 유효 기간은 약 36.5일로 추정됩니다.

HTTP/1.1 200 OK
Last-Modified: Tue, 22 Feb 2025 22:22:22 GMT
Date: Tue, 22 Feb 2026 22:22:22 GMT

GET vs POST 캐시 동작

HTTP 메서드에 따라 캐시 동작이 다릅니다.

GET 요청은 URL이 같으면 캐시가 적중합니다. 쿼리 파라미터가 다르면 별도의 캐시 엔트리로 저장됩니다.

GET /api/servers?keyword=web     → 서버 요청 → 캐시 저장 [A]
GET /api/servers?keyword=db      → 서버 요청 → 캐시 저장 [B]
GET /api/servers?keyword=web     → 캐시 히트 [A]
GET /api/servers?keyword=web&page=2  → 서버 요청 → 캐시 저장 [C]

POST는 HTTP 스펙(RFC 7231)에서 부수 효과(side effect)가 있는 메서드로 정의됩니다. 같은 요청을 보내도 서버 상태가 변경될 수 있으므로, 브라우저는 POST 응답을 캐시하지 않습니다.

// GET → 캐시 대상
fetch('/api/list.do?page=1');
 
// POST → 캐시 안 됨
fetch('/api/save.do', { method: 'POST', body: formData });

Vary 헤더

같은 URL이라도 요청 헤더에 따라 다른 응답을 제공해야 할 때 사용합니다.

Vary: Accept-Language

이 경우 캐시 키가 URL + Accept-Language 값으로 구성됩니다.

GET /index.html  (Accept-Language: ko)  → 한국어 HTML 캐시
GET /index.html  (Accept-Language: en)  → 영어 HTML 캐시 (별도 저장)

Vary 사용 시 주의사항

리소스 유형별 캐시 전략

실무에서 리소스 유형에 따라 어떤 캐시 전략을 적용하면 좋은지 정리합니다.

실제 사례: 토스의 캐시 전략

HTML 파일:
  Cache-Control: max-age=0, s-maxage=31536000
  → 브라우저: 매번 서버 검증 (ETag/304)
  → CDN: 1년 캐시 (배포 시 CDN Invalidation)
 
JS/CSS 파일 (해시 포함):
  Cache-Control: max-age=31536000
  URL: /static/bundle.a1b2c3d4.js
  → URL에 콘텐츠 해시가 포함되어 영구 캐시 안전
  → 파일 변경 시 해시가 바뀌어 새 URL로 요청됨

max-age=0과 s-maxage=31536000을 조합하면, 브라우저는 매번 서버에 검증하면서도 CDN에서는 1년간 캐시를 유지할 수 있습니다. 배포할 때 CDN Invalidation만 수행하면 됩니다.

캐시 무효화 방법

클라이언트 측

서버 측

Cache Busting 전략

캐시 버스팅은 URL을 변경하여 브라우저가 새 리소스로 인식하게 만드는 기법입니다.

방법 1: 쿼리 스트링 (간단하지만 일부 프록시에서 무시될 수 있음)
  /js/common.js?v=1.2.3
  /js/common.js?v=1.2.4
 
방법 2: 파일명에 해시 삽입 (권장)
  /js/common-a1b2c3d4.js
  /js/common-e5f6g7h8.js
 
방법 3: 경로에 버전 포함
  /v1.2.3/js/common.js
  /v1.2.4/js/common.js

DevTools에서 캐시 확인하기

Chrome DevTools의 Network 탭에서 캐시 동작을 확인할 수 있습니다.

Status / Size 컬럼 해석

• from memory cache는 0ms에 가까운 속도로 로딩됩니다.
• from disk cache는 수 ms 정도 소요됩니다.
• 304는 수백 바이트의 헤더만 전송됩니다.

정리

참고 자료

• HTTP Caching - MDN Web Docs
• 헷갈리는 캐시 설정, 쉽게 정리해 드립니다(feat Cache-Control)