HTTP 캐싱은 이전에 받은 응답을 저장했다가 정책에 따라 재사용하는 방식이다. 반복 다운로드를 줄일 수 있지만, 공개 문서와 개인화 응답을 구분하지 않으면 오래된 내용이나 다른 사용자의 정보가 잘못 전달될 수 있다. MDN HTTP 캐싱
어디에 저장되는가
브라우저의 개인 캐시와 여러 사용자가 함께 이용하는 공유 캐시는 범위가 다르다. CDN이나 프록시의 캐시는 다수의 요청을 처리할 수 있으므로 사용자별 응답의 공유 여부가 특히 중요하다. URL만 같다는 이유로 로그인한 사람의 응답을 누구에게나 돌려주면 안 된다.
지시어 읽는 법
서버는 Cache-Control 헤더로 보관과 재사용 정책을 전달한다.
| 지시어 | 핵심 의미 |
|---|---|
| max-age | 새 응답으로 취급할 수 있는 시간 |
| private | 공유 캐시에 저장하지 않도록 지정 |
| no-cache | 저장할 수 있지만 재사용 전 검증 필요 |
| no-store | 캐시에 저장하지 않도록 지정 |
no-cache를 저장 금지라고 해석하는 것이 흔한 오해다. 이름만 보지 말고 재검증과 보관을 구분해야 한다. 여러 지시어의 조합과 다른 응답 헤더도 실제 동작에 영향을 준다. HTTP 캐싱 표준
위키의 적용 예시
본문이 갱신되는 문서는 짧게 캐시하거나 ETag로 재검증하고, 파일 이름에 버전이 포함된 정적 자산은 더 오래 재사용하는 구조를 고려할 수 있다. 개인 설정 페이지는 공유 캐시 대상에서 제외한다. 이것은 정책 설계 예시이며 실제 시간은 업데이트 빈도와 서비스 요구에 맞춰 정한다.
오래된 화면을 진단하기
원본 서버의 새 응답이 보인다는 사실만으로 모든 캐시가 갱신됐다고 판단하면 안 된다. 브라우저, 프록시, CDN 중 어느 계층에서 재사용하는지 응답 헤더와 실제 본문을 함께 확인한다. 같은 URL의 표현이 요청 헤더에 따라 달라지면 Vary 등 캐시 구분 규칙도 검토한다. 웹 성능 개선은 최신성과 정확성을 함께 만족해야 한다.