Cloudflare 캐시와 브라우저 캐시를 나눠서 확인한 배포 비교 노트

같은 URL인데 결과가 달랐다

새 JS 번들을 배포한 뒤 동료의 휴대폰에서는 새 화면이 나왔지만 내 노트북에서는 이전 버튼이 보였다. 처음에는 배포가 실패했다고 판단했지만, 시크릿 창에서는 새 화면이 보였다. 이때부터 문제를 서버, CDN, 브라우저 세 층으로 나눴다.

헤더가 먼저였다

브라우저 개발자 도구의 Disable cache는 도구가 열린 동안만 적용된다. 그래서 같은 주소를 curl로 두 번 조회하고 응답 헤더를 저장했다.

curl -sS -D /tmp/headers.txt -o /tmp/page.html https://example.com/
cat /tmp/headers.txt

cache-control, age, etag, cf-cache-status를 비교했다. HTML은 짧게 캐시하고 해시가 붙은 JS/CSS는 오래 캐시하는 구성이 일반적이지만, HTML까지 오래 남으면 새 번들 주소를 가리키지 못한다. 반대로 JS 파일을 무조건 no-cache로 만들면 배포마다 성능을 잃는다.

두 전략의 차이

**무효화(purge)**는 이미 캐시된 객체를 즉시 지우는 방법이다. 긴급 배포에는 빠르지만 모든 엣지를 대상으로 하면 비용과 실행 누락을 확인해야 한다. 버전이 바뀐 파일명은 URL 자체가 달라지는 전략이다. Vite처럼 해시 파일명을 쓰면 오래 캐시해도 안전하지만, HTML은 새 파일명을 가리키기 때문에 적절한 TTL이 필요하다.

내 프로젝트에서는 HTML에 max-age=0, must-revalidate를 두고 해시 자산에는 긴 max-age를 유지했다. 설정을 바꾼 뒤에도 기존 탭은 이미 메모리에 번들을 올렸을 수 있어 강제 새로고침만으로 결론 내리지 않았다.

점검 순서

1. 시크릿 창과 일반 창의 결과를 비교한다.
2. curl 응답 헤더와 HTML 안의 번들 주소를 확인한다.
3. CDN 상태와 브라우저의 Age/ETag를 각각 본다.
4. purge 뒤 새 URL이 내려오는지 확인한다.
5. 새 탭, 기존 탭, 모바일 네트워크에서 다시 접속한다.

캐시 문제는 “새로고침하면 된다”로 끝내면 재현 조건이 사라진다. 어느 계층이 오래된 응답을 들고 있었는지 남겨야 다음 배포에서 같은 추측을 반복하지 않는다.