웹 브라우저 캐시 완벽 정리: Cache-Control, ETag, 캐시 무효화까지

웹 브라우저 캐시의 개념과 작동 원리 상세 설명

웹 브라우저 캐시는 웹사이트의 정적 리소스(HTML, CSS, JS, 이미지 등)를 로컬 디스크에 저장함으로써, 동일한 리소스에 대한 불필요한 네트워크 요청을 줄이고, 웹사이트 로딩 속도를 높이기 위한 핵심 기술입니다.

캐시의 주요 목적

1. 페이지 로딩 속도 향상: 사용자는 동일한 리소스를 다시 다운로드하지 않고 로컬에서 불러올 수 있으므로 속도가 빨라집니다.
2. 서버 트래픽 감소: 중복 요청이 줄어들어 서버 부하가 감소합니다.
3. 모바일 네트워크 비용 절감: 사용자 측 데이터 사용량도 줄어듭니다.

---

웹 브라우저 캐시의 동작 구조와 흐름

1. 최초 요청 시

• 사용자가 웹사이트에 처음 접속하면, 브라우저는 서버로 HTML, CSS, JS 등 각종 리소스를 요청합니다.
• 이때 서버는 응답 헤더에 Cache-Control, ETag, Last-Modified, Expires 등의 정보를 포함시켜 브라우저가 이 리소스를 캐싱할 수 있는 조건을 전달합니다.

2. 브라우저의 캐시 저장

• 브라우저는 리소스를 다운로드한 후, 로컬 디스크에 캐시 파일을 저장하고,
  • 저장 경로: 일반적으로 운영체제의 사용자 디렉토리 내부에 브라우저 전용 디렉토리가 존재합니다.
  • 저장 대상: JS, CSS, 이미지 파일, 폰트 등

3. 재접속 시 처리 흐름

• 브라우저는 URL을 요청하기 전에, 로컬 캐시에 저장된 리소스를 먼저 확인합니다.
• 캐시 유효 조건에 따라 다음 2가지 방식 중 하나로 처리됩니다:

1) Fresh 캐시 (유효함)

• Cache-Control: max-age=31536000 등으로 설정된 만료 시간이 남아있는 경우
• 브라우저는 서버에 요청을 보내지 않고, 로컬 캐시만 사용합니다. (0 RTT 응답)

2) Stale 캐시 (만료됨)

• 브라우저는 조건부 요청(Conditional Request)을 서버에 전송하여 유효성 검사를 요청합니다.
  • If-None-Match: "etag값" → 서버는 ETag와 비교
  • If-Modified-Since: 날짜 → 서버는 Last-Modified와 비교
• 서버 응답:
  • 변경 없음 → 304 Not Modified와 함께 본문 없이 응답 (브라우저는 기존 캐시 사용)
  • 변경됨 → 새 리소스를 다운로드하고 캐시 갱신

---

HTTP 캐시 관련 헤더 상세 정리

Cache-Control (HTTP 1.1)

• max-age=초: 캐시 유효 시간
• no-cache: 캐시에 저장되긴 하지만 매 요청마다 서버 확인 필요
• no-store: 절대 저장 금지 (보안 데이터 등)
• public: 공유 캐시(프록시)도 저장 가능
• private: 브라우저 개인 캐시에만 저장 가능

Expires (HTTP 1.0)

• 리소스의 만료 시점을 명시 (절대 시간)
• Cache-Control이 함께 존재하면 무시됨

ETag

• 리소스의 고유 식별자 (서버가 리소스마다 생성한 해시값 등)
• 브라우저는 이를 저장하고, 서버에 조건부 요청 시 비교

Last-Modified

• 리소스 최종 수정 시각
• If-Modified-Since 요청 헤더와 짝을 이룸

---

실무에서의 캐시 활용 전략

1. 정적 리소스 캐싱

• Cache-Control: max-age=31536000, immutable 등의 헤더로 장기 캐싱 설정
• JS, CSS 파일은 빌드 시 해시값 포함 (e.g., main.abc123.js) → 변경 시 캐시 무효화
• HTML 문서는 일반적으로 no-cache로 설정 (실시간 콘텐츠 반영 필요)

2. 캐시 무효화(Cache Busting)

• 파일명에 버전 또는 해시 포함 (Webpack, Vite 등에서 자동 처리)
• URL 쿼리 스트링 사용: main.js?v=2.0.1

3. API 응답 캐싱

• 실시간 데이터가 아닌 경우, API 응답에도 ETag 또는 Cache-Control을 포함하여 네트워크 효율 개선
• 예: 상품 목록, 공지사항 등 빈번히 바뀌지 않는 데이터

4. SSR (Server Side Rendering)과 캐싱

• Cache-Control: public, max-age=60 → 사용자의 첫 요청에 대해 SSR 결과를 공유 캐시 서버(예: CDN)에서 60초간 재사용
• 서버와 CDN 사이에서도 stale-while-revalidate 정책을 적용 가능

---

고급 캐싱 전략

1. Lazy Update 캐싱 (Stale-While-Revalidate)

• 사용자에게는 기존 캐시 데이터를 즉시 제공하면서, 백그라운드에서 최신 데이터를 요청하여 캐시를 갱신합니다.
• Cloudflare, Fastly, Vercel 등 CDN에서 지원됨

2. Service Worker 기반 캐싱

• 브라우저 내에서 개발자가 직접 캐시 전략을 제어 가능
• 오프라인 지원 및 복잡한 캐싱 시나리오 구현 가능
• 예: Cache First, Network First, Stale While Revalidate 등 전략 구성 가능

---

요약

• 웹 브라우저 캐시는 성능 최적화의 핵심 도구이며, HTTP 헤더를 통해 정교하게 제어할 수 있습니다.
• 정적 리소스는 장기 캐싱 + 파일명 해시, 동적 콘텐츠는 조건부 요청 + ETag/Last-Modified 방식으로 전략을 나누는 것이 실무의 기본입니다.
• Lazy Update나 Service Worker를 활용하면 복잡한 캐싱 요구사항도 처리할 수 있습니다.
• 면접 질문으로 자주 등장하는 포인트는 Cache-Control 헤더 조합, ETag의 조건부 요청 동작, 캐시 무효화 전략입니다.