Enterprise Infrastructure Intelligence ● Certified engineers online · Fast response guaranteed
웹서버/DB

Cache-Control과 ETag: HTTP 캐시 검증 메커니즘의 원리와 실무

Cache-Control 헤더와 ETag는 HTTP 캐싱의 두 축으로, 응답의 신선도(Freshness)와 유효성(Validation)을 관리합니다. RFC 9111과 RFC 7232 기준으로 이들의 동작 원리, 강약 검증자의 차이, 그리고 웹 서버·DB 환경에서의 실제 운영 전략을 해설합니다.

2026.10.13  ·  1회  · 

1. Cache-Control과 ETag의 역할 구분

HTTP 캐싱은 두 가지 독립적인 메커니즘으로 동작합니다. Cache-Control은 응답의 신선도 수명(max-age, s-maxage 등)을 지정하여 캐시가 원본 서버에 접촉 없이 얼마나 오래 재사용할 수 있는지를 제어합니다. ETag(Entity Tag)

2. 강 검증자(Strong Validator) vs 약 검증자(Weak Validator)

ETag는 강/약 두 가지 형태가 있습니다. 강 검증자는 표현 데이터가 바뀔 때마다 값이 변하므로 부분 콘텐츠(Range) 요청이나 낙관적 동시성 제어에 사용 가능합니다. 약 검증자(W/ 접두사)는 의미상 등가인 표현들을 묶을 수 있어 캐시 검증에만 적합합니다. 예를 들어 같은 콘텐츠의 gzip/비압축 버전이나 매 초 변경되는 날씨 정보는 약 ETag로 관리하는 것이 효율적입니다.

3. 조건부 요청의 우선순위와 304 응답

캐시가 If-None-Match(ETag 기반)와 If-Modified-Since(시간 기반)를 동시에 전송할 때, RFC 7232에 따라 If-None-Match가 먼저 평가됩니다. 서버가 조건을 만족하면 304(Not Modified) 상태로 응답하며, 이때 Cache-Control, ETag, Vary 헤더를 포함해야 캐시의 신선도가 갱신됩니다. 단순한 동작이지만 헤더 누락 시 캐시 일관성이 깨질 수 있으므로 주의가 필요합니다.

4. 실무 운영 체크리스트

정적 자산(CSS, JS, 이미지)은 Cache-Control: public, max-age 지정 후 ETag 필수. API 응답은 must-revalidate로 검증 의무화, 동시에 약 ETag로 네트워크 부하 감소. DB 기반 콘텐츠는 수정 시간(Last-Modified)과 강 ETag 병행, 캐시 무효화 전략은 no-cache 또는 max-age=0으로 강제 검증하기. 공유 캐시(프록시)는 s-maxage로 별도 제어하되 private 응답 절대 저장 금지.

WIKIDATA WORKSTATION
AI·렌더링에 최적화된
전문가용 워크스테이션
NVIDIA RTX GPU · 최대 192GB 메모리 · ECC 지원