network · high priority
HTTP 캐싱 전략 완전 이해
Cache-Control, ETag, CDN — 빠른 웹을 만드는 핵심
학습 개요
탄생 배경
쉬운 설명
복잡한 개념을 실생활 비유로 설명합니다.
“편의점 재고 관리”
캐시는 집 냉장고에 미리 사다 둔 식재료입니다. max-age는 유통기한입니다. ETag는 재고 번호 — 편의점(서버)에 "이 번호 맞나요?" 물어보고 같으면 새로 안 사고, 다르면 새걸 삽니다. Cache-Control: no-cache는 "집에 있어도 매번 편의점에 재고 확인 전화하고 써라"입니다.
핵심 개념
max-age=N
N초 동안 캐시 사용. 서버에 재요청 없음
Cache-Control: max-age=86400 (1일)no-cache
캐시에 저장하지만 매번 서버에 유효성 검사 (ETag/Last-Modified)
HTML 파일에 적합 — 변경 여부 항상 확인no-store
캐시 자체를 하지 않음. 매번 서버에서 받음
민감한 개인 정보 응답public
CDN, 프록시 서버도 캐시 가능
정적 자원 (이미지, CSS, JS)private
브라우저만 캐시. CDN 캐시 안 됨
개인화된 응답 (사용자 프로필)immutable
max-age 내에 절대 변경 안 된다고 선언. 조건부 요청 안 함
content hash 포함된 번들 파일stale-while-revalidate
캐시 만료 후에도 스테일 응답 즉시 반환 + 백그라운드 업데이트
API 응답, 뉴스 피드실무 핵심 전략
정적 자원(JS, CSS, 이미지)에는 content hash를 파일명에 포함하고 max-age를 1년으로 설정합니다. 파일이 바뀌면 파일명이 바뀌므로 자동으로 캐시 무효화됩니다. HTML 파일에는 no-cache로 항상 최신 버전을 확인합니다.
실무 적용
어떤 상황에서 사용하는가
Next.js/Vite 앱 배포 시 캐싱 전략 수립
어떻게 적용하는가
Vite/webpack의 content hash 파일명([name].[hash].js)으로 JS/CSS 번들을 1년 캐시. HTML은 no-cache. API 응답은 React Query의 staleTime/gcTime으로 클라이언트 캐시 제어. CDN(Cloudflare, Vercel Edge)에서 정적 자원 캐시.
흔한 실수와 안티패턴
- HTML에 max-age를 길게 설정하면 배포 후에도 이전 HTML을 받아 새 JS 파일을 못 찾음
- Content hash 없이 같은 파일명으로 배포하면 CDN 캐시 무효화 안 됨
- private/public 설정 실수 — 개인화 응답이 CDN에 캐시되면 다른 사용자가 받을 수 있음
- API에 no-store 남발 — 필요 이상으로 캐시를 끄면 성능 저하
면접 질문
답변 방향 힌트
캐시 저장 여부 vs 서버 재검증
반드시 언급할 키워드
- no-cache: 저장하되 매번 서버 검증
- no-store: 아예 저장 안 함
- ETag와의 연계
예상 꼬리 질문
- s-maxage와 max-age의 차이는?
- Vercel/Cloudflare에서 캐시 무효화를 어떻게 하나요?