HTTP Cache-Control을 운영자가 이해하는 방식
CloudPlare 편집 노트 · 최초 작성 2026-06-03 · 최종 검토 2026-06-10 · 9분 읽기
캐시는 속도를 올리지만 잘못 쓰면 오래된 화면을 배포합니다. 헤더 이름을 외우기보다 어떤 리소스를 얼마나 믿고 재사용할지 결정하는 관점이 필요합니다.
캐시는 저장이 아니라 약속이다
Cache-Control은 브라우저와 중간 캐시에게 응답을 어떻게 재사용할지 알려주는 HTTP 헤더입니다. 단순히 “캐시한다”와 “캐시하지 않는다”로 나누기보다, 어떤 응답을 얼마나 오래 신선하다고 볼지, 다시 확인할지, 아예 저장하지 말지를 정하는 약속에 가깝습니다.
정적 파일, 글 페이지, 개인화 페이지는 같은 정책을 쓰면 안 됩니다. 해시가 붙은 자바스크립트 번들은 오래 캐시해도 비교적 안전하지만, 로그인 후 개인 정보가 담긴 응답을 공유 캐시에 저장하면 심각한 문제가 됩니다. 작은 사이트라도 페이지 성격별로 정책을 나눠야 합니다.
no-cache는 저장 금지가 아니다
이름 때문에 자주 헷갈리지만 no-cache는 저장하지 말라는 뜻이 아닙니다. 저장할 수는 있지만 다시 사용할 때 원 서버에 검증하라는 의미입니다. 정말 저장 자체를 피해야 하는 민감한 응답에는 no-store가 더 적절합니다.
운영자가 이 차이를 모르면 “no-cache를 넣었는데 왜 캐시가 남아 있지?” 같은 혼란이 생깁니다. 브라우저가 응답을 저장하고 매번 재검증하는 것과, 아예 저장하지 않는 것은 전혀 다른 동작입니다. 정책을 읽을 때는 이름보다 실제 지시 내용을 봐야 합니다.
정적 자산은 오래, 문서는 짧게
파일명에 해시가 들어간 정적 자산은 내용이 바뀌면 URL도 바뀌므로 오래 캐시하기 좋습니다. 반면 HTML 문서는 같은 URL에서 내용이 바뀔 수 있습니다. 글 수정, 메타 변경, 정책 페이지 업데이트가 잦다면 HTML에 너무 긴 max-age를 주면 방문자가 오래된 설명을 볼 수 있습니다.
CDN을 쓰는 경우 브라우저 캐시와 CDN 캐시를 구분해야 합니다. s-maxage는 공유 캐시에 적용되고, max-age는 일반 캐시에 적용됩니다. 둘을 섞어 쓸 때는 어느 계층이 어떤 시간 동안 응답을 들고 있는지 운영 메모에 남겨야 장애 때 빠르게 지울 수 있습니다.
stale-while-revalidate는 만능이 아니다
stale-while-revalidate는 오래된 응답을 잠시 보여주면서 뒤에서 새 응답을 확인하는 전략입니다. 읽기 중심 페이지에는 체감 속도를 좋게 만들 수 있지만, 즉시 반영이 중요한 공지나 가격, 보안 관련 안내에는 조심스럽게 써야 합니다.
캐시 정책은 성능 도구 점수만 보고 정하지 않습니다. 방문자가 오래된 정보를 봐도 되는지, 배포자가 캐시를 언제 무효화할 수 있는지, 문제가 생겼을 때 어떤 계층부터 지울지까지 함께 결정해야 합니다.
운영 체크리스트
- no-cache와 no-store의 차이를 이해하고 적용했다.
- HTML 문서와 해시 기반 정적 자산의 캐시 정책을 분리했다.
- CDN 공유 캐시에 적용되는 s-maxage 사용 여부를 확인했다.
- 오래된 정보가 노출되면 위험한 페이지를 별도로 분류했다.
- 캐시 제거 방법과 확인 URL을 운영 기록에 남겼다.
확인한 공식 자료
아래 자료를 바탕으로 운영 관점의 설명을 덧붙였습니다. 세부 동작은 서비스와 배포 환경에 따라 달라질 수 있습니다.