웹 배포 후 캐시 제어를 점검하는 실무 순서

웹 배포 후 캐시 문제는 ‘캐시를 비웠다’가 아니라 어느 계층이 어떤 응답을 언제까지 보관했는지로 해결합니다. 브라우저, CDN, 리버스 프록시, 애플리케이션 응답의 헤더를 각각 확인하고, HTML과 해시된 정적 파일에 서로 다른 정책을 적용해야 합니다. 새 HTML이 이전 JS를 부르는 조합이 깨지지 않는지도 함께 봐야 합니다.

HTTP 캐시 동작은 응답의 Cache-Control과 검증자 헤더를 바탕으로 결정됩니다. MDN의 HTTP 캐시 안내는 max-age, no-cache, must-revalidate와 ETag를 구분해 설명합니다.HTTP 캐싱 가이드를 기준으로 배포 후 실제 응답을 측정합니다.

장애 증상을 브라우저·엣지·원본으로 분리한다

내 브라우저에서만 이전 화면이면 브라우저 캐시나 서비스 워커를 의심하고, 여러 지역에서 동일하면 CDN이나 원본을 의심합니다. HTML은 새 버전인데 JS가 이전 파일이면 이름이 고정된 번들 또는 중간 캐시의 조합 문제입니다. 먼저 curl로 같은 URL을 여러 번 요청해 Age, ETag, Cache-Control, Via 같은 관찰값을 남깁니다.

• HTML: 짧은 캐시와 재검증으로 새 배포를 빠르게 반영

• 해시 정적 파일: 긴 max-age와 immutable을 사용할 수 있음

• 변경된 고정 URL: CDN 무효화 또는 파일명 교체 범위를 기록

헤더 증거로 HTML과 지문 자산을 진단한다

원본 응답과 CDN 응답을 비교해 정책이 중간 계층에서 덮어쓰였는지 확인합니다. 강제 새로고침은 사용자 한 명의 브라우저만 바꾸므로 완료 증거가 아닙니다. 새 HTML에서 참조하는 정적 파일이 실제로 존재하는지, 이전 HTML을 받은 캐시가 새 파일을 계속 요청해도 호환되는지 릴리스 전략에 따라 검증합니다.

샘플: HTML과 번들 정책을 결정하는 표

예시 입력은 /app/index.html이 고정 URL이고 app.8f3.js가 해시 파일인 배포입니다. 결정은 HTML에는 max-age=60과 재검증을 적용하고, 해시 번들에는 긴 캐시를 적용하는 것입니다. 중간 산출물은 URL·응답 헤더·배포 버전·관찰 위치 표이며, 기대 결과는 새 배포 후 60초 안에 HTML이 새 번들을 참조하고 기존 번들은 필요한 동안 계속 제공되는 것입니다.

purge 실패를 복구하고 다음 배포를 예방한다

실패 사례는 모든 경로를 한꺼번에 purge하고도 서비스 워커가 이전 앱 셸을 제공하는 경우입니다. 복구는 먼저 서비스 워커 등록과 캐시 이름을 확인하고, 필요하면 호환 가능한 HTML·번들을 유지한 뒤 점진적으로 활성 캐시를 교체하는 것입니다. 반대로 사용자별 응답이나 인증 페이지를 공개 CDN에 오래 저장하면 데이터 노출 위험이 있으므로 public 캐시를 적용하지 않습니다.

MISS·HIT와 호환 조합을 완료 증거로 남긴다

완료 조건은 원본과 엣지에서 기대한 Cache-Control·ETag가 확인되고, 대표 지역의 MISS 후 HIT가 기록되며, 새 HTML과 정적 파일의 버전 조합이 재현되는 상태입니다. 서비스 워커와 브라우저를 포함한 실패·복구 로그까지 남겼을 때 배포 후 캐시 점검을 검증 완료로 기록합니다.