Cache-Control 헤더 빌더

RFC 9111을 따르는 유효한 Cache-Control 헤더를 조합합니다. 필요한 지시어(no-cache, no-store, immutable 등)를 체크하고 신선도 구간(max-age, s-maxage, stale-while-revalidate, stale-if-error)을 설정한 뒤 결과 헤더를 복사하면 됩니다. 가장 흔한 배포 형태를 담은 프리셋 네 가지가 있습니다. 불변 정적 자산, 개인화된 렌더링 페이지, 만료본 제공을 허용하는 공개 API 응답, 완전한 no-store입니다.

사람들이 가장 많이 틀리는 지시어는 no-cache인데, 이것은 캐시하지 말라는 뜻이 아닙니다. 저장은 해도 되지만 재사용하기 전에 원본 서버와 재검증하라는 뜻이라, 캐시는 여전히 사본을 갖고 있고 조건부 요청이 304로 답할 수도 있습니다. 실제로 저장을 금지하는 지시어는 no-store입니다. 둘을 함께 쓰는 것은 흔하고 해롭지 않지만, no-store를 뜻하면서 no-cache를 집으면 의도하지 않은 캐시에 응답이 그대로 남습니다.

신선도는 방문자가 응답을 받은 시점이 아니라 원본이 응답을 만든 시점부터 셉니다. 공유 캐시는 그 시계가 얼마나 흘렀는지를 Age 헤더로 알려 주므로, max-age=600인 응답이 CDN에서 500초를 보냈다면 남은 수명 100초로 도착합니다. s-maxage는 공유 캐시에 대해서만 max-age를 덮어쓰는데, CDN 수명은 길게 두면서 브라우저는 더 일찍 재검증하게 만드는 방법이 이것입니다.

immutable이 값어치를 하는 경우는 하나뿐입니다. 사용자가 새로고침을 눌러도 재검증하지 말라고 브라우저에 알리는 것인데, 새로고침이야말로 긴 max-age를 무시하는 유일한 동작입니다. 내용이 절대 바뀔 수 없는 URL에서만 안전하며, 현실적으로는 파일명에 내용 해시가 들어 있다는 뜻입니다.

헤더가 할 수 없는 일은 이미 캐시된 응답에 손대는 것입니다. 오늘 max-age를 줄여도 어제 옛 값으로 나간 사본에는 아무 영향이 없고, 그 사본들은 원래 구간이 끝날 때까지 신선한 상태로 남습니다. 이 비대칭이 정적 자산을 헤더가 아니라 URL로 버전 관리하는 이유입니다.