HTTP Cache-Control은 왜 어려울까: max-age, no-cache, no-store를 구분하는 기준

HTTP Cache-Control은 왜 어려울까: max-age, no-cache, no-store를 구분하는 기준
Cache-Control은 저장 금지와 재검증, 유효 기간을 서로 다른 지시어로 표현합니다.

Cache-Control은 웹 성능을 높이는 핵심 헤더지만, `max-age`, `no-cache`, `no-store` 이름이 직관과 조금 다릅니다.

핵심은 캐시 저장 여부와 재사용 전 검증 여부를 분리해서 읽는 것입니다. 이 글은 MDN과 RFC 9111을 기준으로 HTTP Cache-Control 지시어, ETag, 브라우저 캐시와 CDN 캐시 차이를 정리합니다.

HTTP Cache-Control 지시어 차이 요약 카드
no-cache는 저장 금지가 아니라 재검증 요구이고, no-store는 저장 자체를 막는 지시어입니다.

Cache-Control을 먼저 두 질문으로 나누자

HTTP 캐시는 어렵게 느껴지지만, 먼저 두 질문으로 나누면 훨씬 단순해집니다. 이 응답을 저장해도 되는가, 저장했다면 다시 쓰기 전에 서버에 물어봐야 하는가입니다.

Cache-Control: max-age=3600
Cache-Control: no-cache
Cache-Control: no-store

세 헤더는 비슷해 보이지만 의미가 다릅니다. 특히 `no-cache`는 이름 때문에 저장 금지처럼 보이지만 실제로는 재검증에 가깝습니다.


max-age는 캐시의 신선한 시간

`max-age=3600`은 응답을 받은 뒤 3600초 동안 신선하다고 볼 수 있다는 뜻입니다. 이 시간 안에서는 캐시가 서버에 다시 묻지 않고 응답을 재사용할 수 있습니다.

HTTP/1.1 200 OK
Cache-Control: public, max-age=31536000, immutable

버전이 파일명에 포함된 정적 자산에는 긴 max-age가 잘 맞습니다. 반대로 자주 바뀌는 HTML 문서에 너무 긴 max-age를 주면 사용자가 오래된 화면을 볼 수 있습니다.


no-cache는 저장 금지가 아니라 재검증

`no-cache`는 캐시에 저장하지 말라는 뜻이 아닙니다. 저장은 할 수 있지만 재사용하기 전에 서버에 검증하라는 뜻입니다. 보통 ETag나 Last-Modified와 함께 쓰입니다.

HTTP/1.1 200 OK
Cache-Control: no-cache
ETag: "user-profile-v42"

GET /profile HTTP/1.1
If-None-Match: "user-profile-v42"

서버가 아직 같은 버전이라고 판단하면 304 Not Modified로 본문 없이 응답할 수 있습니다. 이때 네트워크 왕복은 있지만 응답 본문 다운로드는 줄어듭니다.


no-store는 저장 자체를 피하라는 지시어

`no-store`는 요청이나 응답을 저장하지 말라는 지시어입니다. 로그인 토큰, 결제 정보, 민감한 개인 정보가 담긴 응답처럼 캐시 저장 자체가 부담인 경우에 사용합니다.

HTTP/1.1 200 OK
Cache-Control: no-store

모든 API에 무조건 no-store를 붙이면 안전해 보이지만, 성능상 이점을 잃을 수 있습니다. 민감도와 갱신 빈도, 재검증 가능성을 보고 골라야 합니다.


브라우저 캐시와 CDN 캐시는 다르게 생각해야 한다

브라우저 캐시는 사용자 기기 안에서 동작합니다. CDN 캐시는 여러 사용자에게 응답을 전달하는 중간 캐시입니다. 그래서 사용자별 응답과 공용 정적 자산을 같은 기준으로 다루면 위험합니다.

  • 해시가 붙은 JS/CSS 파일: 긴 max-age 후보
  • 사용자별 HTML이나 API 응답: private, no-cache, no-store 검토
  • 공용 이미지와 폰트: public 캐시 후보
  • 권한에 따라 달라지는 응답: CDN 캐시 여부를 매우 조심

실무 체크리스트

  1. 응답이 사용자별인지 공용인지 먼저 구분한다
  2. 정적 자산은 파일명 버전 관리와 긴 max-age를 함께 검토한다
  3. 재검증이 적합하면 no-cache와 ETag를 함께 본다
  4. 민감 정보가 있으면 no-store를 우선 검토한다
  5. 브라우저 캐시와 CDN 캐시 정책을 분리해서 점검한다

정리

Cache-Control는 이름만 외우는 것보다 어떤 문제를 줄이기 위한 도구인지 보는 편이 좋습니다. 이 글에서는 공식 문서 기준으로 핵심 개념, 자주 하는 실수, 실무 판단 기준을 함께 정리했습니다.

함께 보면 좋은 내부 글은 SQL 인덱스는 왜 빠를까, JWT access token과 refresh token은 왜 나눌까, Dockerfile layer cache는 왜 중요할까입니다. 외부 기준은 MDN – Cache-Control, RFC 9111 – HTTP Caching, MDN – ETag를 확인했습니다.

함께보면 좋은 글