소스·출력·공개 응답을 먼저 구분하기
2026년 11월 4일 확인한 RAONIZ의 Hosting 설정은 dist를 배포합니다. 소스를 수정해도 빌드하지 않았다면 예전 HTML이 올라갈 수 있고, 빌드만 하고 배포하지 않았다면 공개 사이트는 그대로입니다. 먼저 어느 단계까지 끝났는지 확인합니다.
다음으로 페이지 주소와 배포 대상을 대조합니다. 하나의 Firebase 프로젝트에서 여러 Hosting 사이트를 관리할 수 있으므로 프로젝트 이름만으로 게시할 도메인을 추정하면 안 됩니다. Hosting 사이트, 배포 타깃, 사용자 지정 도메인이 원하는 사이트를 가리키는지 확인한 뒤 공개 응답을 봅니다.
HTML과 자산에 다른 정책을 쓰기
현재 설정은 HTML·XML·텍스트에 public, max-age=0, must-revalidate, /assets/**에 public, max-age=31536000, immutable, 이미지에 public, max-age=604800을 지정합니다. 각각 재검증, 긴 보관, 일주일 보관을 의도한 설정입니다.
HTML은 새 배포를 확인하고, 해시가 붙은 자산은 같은 URL의 내용이 바뀌지 않는다는 전제로 오래 저장하는 조합입니다. max-age=0은 저장 자체를 금지하는 no-store와는 다릅니다. 실제 헤더 동작은 Cache-Control 문서에서 확인할 수 있습니다.
이미지를 덮어썼다면 파일 이름도 확인하기
스타일과 스크립트는 HTML에 해시 파일명으로 연결됩니다. 반면 같은 이름의 이미지 파일을 덮어쓰면 이미 저장한 브라우저가 이전 이미지를 계속 쓸 수 있습니다. 소개 이미지를 바꿀 때 새 이름을 붙이고 참조를 함께 바꾸면 어느 버전을 받는지 구분하기 쉽습니다.
설정상 긴 캐시 대상에는 해시가 없는 파일도 들어갈 수 있습니다. 경로 규칙만 보고 모든 파일을 안전하게 덮어쓸 수 있다고 가정하지 않습니다. HTML에 연결된 실제 자산 주소와 그 주소가 가리키는 내용을 함께 확인해야 합니다.
응답 헤더를 직접 읽기
터미널이 있는 환경에서는 아래처럼 공개 페이지의 응답 헤더를 확인할 수 있습니다. 이어서 페이지 HTML의 src에서 실제 자산 URL을 복사하고 그 주소에도 curl -I를 실행합니다. 임의의 해시를 만들면 404 응답을 검사하게 됩니다.
curl -I https://raoniz.com/ko/
# Next: run curl -I with the exact asset URL found in that HTML.- 상태 코드와 최종 URL을 확인합니다. 리디렉션 뒤 다른 페이지를 보고 있지 않은지 봅니다.
- HTML 응답의 Cache-Control과 본문의 수정 내용을 함께 확인합니다.
- HTML이 참조하는 CSS·JS·이미지 주소의 응답과 파일 내용을 확인합니다.
- 캐시를 끈 개발자 도구와 보통 방문 상태를 비교합니다. 한 번의 강력 새로고침으로 모든 방문자의 문제가 해결됐다고 판단하지 않습니다.
캐시 정책과 가용성 약속은 다르다
긴 캐시는 반복 방문에서 같은 자산을 다시 받는 일을 줄일 수 있지만 사이트 가용성이나 특정 응답시간을 입증하지는 않습니다. 장애 여부는 Hosting 상태, 실제 응답, 자산 누락, DNS와 인증서 등 관찰 가능한 원인을 따라 확인해야 합니다.
이 글은 로컬 설정을 읽는 방법이며 현재 모든 CDN 노드의 동작을 측정한 보고서가 아닙니다. Firebase가 캐시를 다루는 방식은 Hosting 공식 문서를 참고하세요. 배포 전 생성 과정은 정적 빌드 글에 정리했습니다.