RFC 9111 HTTP 캐싱 표준과 stale-while-revalidate 기반 CDN 엣지 아키텍처
stale-while-revalidate는 RFC 5861 확장으로, 지원 캐시가 지정 기간 stale 응답과 비동기 검증을 선택할 수 있게 합니다. CDN별 동작과 데이터 허용 노후도를 확인해야 합니다.
발행·오류 제보: infostoa · 편집 기준
이 글의 개별 작성자와 전문 검토자 정보는 제공되지 않습니다.
HTTP 캐시 신선도와 stale-while-revalidate 적용 범위
RFC 9111은 HTTP 캐시의 저장·재사용·검증 규칙을 정의합니다. max-age는 응답의 신선도 수명에 영향을 주며 공유 캐시는 s-maxage를 사용할 수 있습니다. ETag와 Last-Modified는 오래된 응답을 조건부 요청으로 재검증하는 데 쓰입니다. stale-while-revalidate 지시어는 RFC 9111이 아니라 RFC 5861에서 정의한 확장입니다. 해당 기간에 캐시가 오래된 응답을 즉시 제공할 수 있고, 백그라운드 검증을 시도하도록 지시하지만 모든 캐시가 이를 지원하거나 동일하게 구현한다는 뜻은 아닙니다.
전문가 관점: Fastly 캐시 운영 자료의 적용 조건
Fastly 문서는 자사 캐시에서 응답이 cacheable하고 객체가 실제로 남아 있으며 요청이 해당 캐시 경로를 통과하는 경우, stale-while-revalidate 기간에 stale 응답을 제공하면서 원본을 비동기 재검증할 수 있다고 설명합니다. 캐시 객체가 이미 퇴출됐거나 요청이 pass 처리되면 같은 동작을 기대할 수 없습니다. 이는 Fastly 제품 동작에 대한 실무 지침입니다. 모든 CDN edge가 동일한 refresh 동작이나 글로벌 동시 갱신을 보장하지 않습니다. 트래픽이 드물면 지시어 기간 중 재검증 요청이 발생하지 않을 수도 있습니다.
stale 기간은 허용할 수 있는 데이터 노후도
Cache-Control: max-age=300, stale-while-revalidate=60은 응답을 300초 동안 fresh로 취급하고, 그 뒤 최대 60초 범위에서 stale 제공을 허용하는 예입니다. 이 기간은 곧바로 오래된 값을 전달해도 되는 제품 정책입니다. 오래되면 안 되는 잔액·권한·재고 응답 등에 무분별하게 적용하지 마세요. RFC 5861은 캐시가 stale 값을 주는 동안 비차단 재검증을 시도하도록 권고하지만 stale 응답 제공 자체는 MAY이며, 기간 종료 후에는 다른 근거가 없는 한 계속 제공하지 말아야 합니다. stale-if-error는 오류 때 별도로 stale 반환을 허용하는 지시어이며 재검증과 같은 기능이 아닙니다.
Age 값으로 stale 창을 읽는 가상 타임라인
다음은 Cache-Control: max-age=300, stale-while-revalidate=60 응답이 캐시에 남아 있고, 캐시가 이 확장을 지원하며, must-revalidate, s-maxage 등 결과를 바꾸는 다른 지시자나 별도 정책이 없다고 가정한 예입니다. Age는 응답의 현재 나이를 나타내며, 표의 응답 동작은 규격이 허용하는 범위이지 모든 CDN의 관측 결과를 보장하지 않습니다(RFC 9111 §4.2, RFC 5861 §3).
요청 시 Age | 나이 판정 | 이 지시자에 따른 판단 |
|---|---|---|
| 250초 | max-age=300 이내의 fresh | 저장 응답을 재검증 없이 사용할 수 있습니다. |
| 320초 | stale 20초, SWR 60초 이내 | 캐시는 stale 응답을 제공할 수 있고, 제공한다면 비차단 재검증을 시도해야 합니다. |
| 370초 | stale 70초, SWR 60초 초과 | SWR만으로 stale 제공을 계속할 수 없습니다. 다른 허용 근거가 없으면 다음 요청은 재검증을 기다리거나 원본에서 새 응답을 받아야 합니다. |
따라서 stale-while-revalidate=60은 응답을 60초 더 fresh하게 만드는 값이 아닙니다. 320초 시점에 오래된 응답이 실제 제공됐는지 확인하려면 관측 지점의 Age, 원본 재검증 시각과 CDN 캐시 로그를 함께 확인하세요. RFC 9111에서 obsolete로 지정된 Warning 헤더는 검증의 필수 근거나 지표가 아닙니다. 캐시가 확장을 지원하는지, 다른 Cache-Control 지시자나 사업자별 설정이 적용되는지도 별도로 확인해야 합니다.
공유 캐시 안전성과 실측
공유 캐시에서는 URL·메서드와 Vary 등 cache key가 사용자별 응답을 구분하는지 확인해야 합니다. private, no-store, Authorization 요청 응답에 대한 RFC 규칙과 예외를 살피고, CDN의 자체 cache rule이 이를 덮어쓰지 않는지 검증하세요. 쿠키나 개인별 토큰이 섞인 응답은 명시적으로 분리·우회하는 편이 안전합니다. 각 CDN의 브라우저·edge 지원, Age 헤더, 조건부 요청, shield·purge 설정, 재검증 트래픽을 실제 응답과 로그로 시험하세요. SWR은 지연을 숨길 수 있지만 원본 부하 감소나 항상 최신 콘텐츠를 보장하지 않습니다.