🧠 18. 웹 캐싱 전략 완전 정리 — Cache-Control부터 ETag, Service Worker까지

사용자 경험을 개선하고, 서버 부하를 줄이며, 로딩 속도를 빠르게 하기 위한 방법 중 하나는 캐싱(Caching)이다.
하지만 캐시는 브라우저마다, 설정마다 다르게 동작하고,
"왜 이게 갱신 안 됐지?", "왜 API가 예전 값을 가져오지?" 같은 문제를 종종 마주하게 된다.
이번 글에서는 웹 프론트엔드 개발자가 꼭 알아야 할 캐싱 전략들을 정리해봤다.

---

✅ 1. 브라우저 캐시의 기본: Cache-Control

HTTP 응답 헤더에서 캐싱 동작을 지정하는 대표적인 방법

Cache-Control: public, max-age=3600

주요 옵션 정리

옵션	설명
public	모든 사용자에게 캐시 허용 (CDN 포함)
private	사용자 개별 브라우저에만 캐시 허용
no-cache	캐싱은 되지만 매번 서버에 확인
no-store	아예 캐시하지 않음 (보안 정보에 사용)
max-age=초단위	지정 시간 동안 캐시 유지 (초 단위)
s-maxage	공유 캐시에만 적용 (예: CDN)

---

실전 예시

Cache-Control: public, max-age=86400

• 하루(86400초) 동안 브라우저는 서버에 요청하지 않고 캐시된 자원을 사용

Cache-Control: no-cache

• 브라우저는 매번 서버에 확인 (Etag, Last-Modified와 함께 사용)

---

✅ 2. 변경 감지 기반 캐시: ETag, Last-Modified

🏷️ ETag (Entity Tag)

리소스의 고유한 식별자(해시)를 설정 → 요청 시 서버가 비교

ETag: "abc123"

클라이언트 → 서버 요청 시:

If-None-Match: "abc123"

• 서버 리소스와 동일하면 → 304 Not Modified 응답 (캐시 사용)
• 다르면 → 200 OK + 새 리소스 응답

---

🏷️ Last-Modified

Last-Modified: Wed, 24 Apr 2024 10:00:00 GMT

클라이언트 요청:

If-Modified-Since: Wed, 24 Apr 2024 10:00:00 GMT

• 변경이 없으면 304 반환
• 변경이 있으면 200 + 새 리소스

📌 ETag가 더 정확한 비교 방식
(단, 서버 CPU 연산을 더 많이 쓰므로 상황에 따라 선택)

---

✅ 3. Service Worker를 활용한 캐시 전략

오프라인에서도 작동하는 앱을 위한 핵심 기술 (PWA)

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((cachedResponse) => {
      if (cachedResponse) {
        return cachedResponse;
      }
      return fetch(event.request);
    })
  );
});

사용 전략 예시

전략	설명
Cache First	캐시된 응답 우선, 없으면 네트워크
Network First	네트워크 우선, 실패 시 캐시
Stale-While-Revalidate	캐시 응답 후 백그라운드 갱신
Cache Only	항상 캐시만 사용
Network Only	항상 네트워크만 사용

---

✅ 실전에서 흔한 문제 & 해결 전략

🔄 변경된 JS/CSS가 적용되지 않음

• 원인: Cache-Control: max-age가 너무 김
• 해결: 빌드 시 해시(main.abc123.js)를 파일명에 포함

🔁 API 응답이 최신이 아님

• 원인: 브라우저가 이전 응답을 캐싱함
• 해결: Cache-Control: no-cache, 또는 ETag 비교

🔌 이미지가 오래된 버전으로 보임

• 해결: ?v=1.2.3 등의 쿼리 스트링 추가로 캐시 무효화

---

✅ 정리 요약

기술	캐시 방식	갱신 방식
Cache-Control	시간 기반 (max-age)	일정 시간 후 새 요청
ETag / Last-Modified	리소스 비교 기반	변경 여부에 따라 304 or 200
Service Worker	직접 코드로 제어	fetch 요청 인터셉트 가능

---

📝 내가 느낀 점

SWR, React Query, CDN 최적화 등을 할 때 캐시 전략을 모르면 버그를 만든다는 걸 체감했다.
특히 HTTP 캐시가 예상과 다르게 동작할 때 디버깅이 어렵기 때문에
기본적인 캐시 전략을 이해하고 있으면 실무에서 훨씬 빠르게 문제를 해결할 수 있다.

지금은 배포 시 JS/CSS에 hash를 붙이고,
API는 ETag + Cache-Control: no-cache 조합으로
정확한 변경 여부만 판단하게 설정하고 있다.

---

🧩 “캐시는 속도의 문제이자 정확성의 문제다.
그 둘을 동시에 만족시키는 것이 진짜 최적화다.”