HTTP 캐싱 헤더 Cache-Control, ETag, Last-Modified의 역할을 설명해주세요.

HTTP 캐싱 헤더는 브라우저와 CDN이 응답을 저장해도 되는지, 얼마나 오래 재사용할 수 있는지, 원본 서버에 재검증해야 하는지를 결정합니다. Cache-Control은 정책, ETag와 Last-Modified는 재검증 기준이라고 이해하면 쉽습니다.

핵심 개념

• Cache-Control: max-age=...는 응답을 신선한 상태로 간주할 시간을 지정합니다.
• ETag는 리소스 버전 식별자이며, 클라이언트는 If-None-Match로 재검증합니다.
• Last-Modified는 마지막 수정 시간이며, If-Modified-Since와 함께 사용됩니다.

동작 방식 또는 판단 기준

이 주제를 이해할 때는 다음 순서로 보면 실무 적용이 쉬워집니다.

1. 무엇을 해결하려는가: 성능, 표현력, 안정성, 접근성 중 어떤 문제를 줄이려는지 확인합니다.
2. 전제 조건은 무엇인가: 정렬 여부, 브라우저 지원, 네트워크 특성, 동시성 조건처럼 성립해야 하는 조건을 점검합니다.
3. 비용은 어디서 발생하는가: 시간 복잡도, 메모리, 캐시, 재시도, 렌더링 비용처럼 병목 지점을 나눠 봅니다.
4. 실패 시 어떤 문제가 생기는가: 잘못 적용했을 때의 버그나 운영 리스크를 함께 고려합니다.

실제 예시

# 해시가 붙은 정적 파일
Cache-Control: public, max-age=31536000, immutable

# HTML 문서
Cache-Control: no-cache
ETag: "html-v42"

# 재검증 요청
GET /index.html HTTP/1.1
If-None-Match: "html-v42"

# 변경 없음
HTTP/1.1 304 Not Modified

실무에서 주의할 점

• no-cache는 저장하지 말라는 뜻이 아니라, 사용 전 재검증하라는 뜻입니다. 저장 금지는 no-store입니다.
• 사용자별 응답을 public으로 캐시하면 개인정보 노출 사고가 날 수 있습니다.
• 파일 이름에 해시가 없는데 긴 max-age를 주면 배포 후 사용자가 오래된 파일을 계속 볼 수 있습니다.

실무 적용 가이드

• 정적 assets는 content hash + 긴 캐시, HTML/API는 짧은 캐시 또는 재검증 전략을 사용합니다.
• 로그인 사용자 응답에는 private 또는 no-store를 신중히 적용합니다.
• CDN, browser, service worker 캐시가 각각 어떻게 동작하는지 분리해서 디버깅합니다.

함께 연결해서 보면 좋은 키워드

HTTP Cache, Cache-Control, ETag, Last-Modified, 304

정리

HTTP 캐싱 헤더는 브라우저와 CDN이 응답을 저장해도 되는지, 얼마나 오래 재사용할 수 있는지, 원본 서버에 재검증해야 하는지를 결정합니다입니다. 다만 개념 자체보다 중요한 것은 적용 조건과 한계를 함께 이해하는 것입니다. 작은 예제에서는 단순해 보여도 실제 서비스에서는 성능, 보안, 유지보수성, 접근성 요구사항이 함께 얽히므로, 문제의 성격을 먼저 파악한 뒤 적절한 도구로 선택하는 것이 좋습니다.