캐시
Cache · 캐싱
캐시는 이전에 계산하거나 내려받은 응답을 가까운 저장 공간에 두고 조건이 맞을 때 다시 사용하는 방식입니다. 원본 저장소와 다르며 만료·무효화·재검증 때문에 화면과 원본의 갱신 시점이 달라질 수 있습니다.
AI 보조 조사·작성 후 원문과 대조한 설명입니다. 사례·계산은 별도 출처 표기가 없는 한 이해를 위한 가상 예시이며 실제 고객 성과가 아닙니다.
캐시는 어떤 역할을 하나요?
RFC 9111은 HTTP 캐시와 응답을 저장·재사용하도록 제어하는 헤더를 정의합니다. IETF HTTP 캐시 표준 브라우저, CDN, 서버, 분석 도구에 서로 다른 캐시가 있을 수 있어 새로고침 한 번으로 모든 단계가 갱신됐다고 볼 수 없습니다. 사용자가 최신 정보를 확인해야 하는 화면에서는 캐시 적중률만 높이는 대신 원본 변경 이벤트가 어느 단계의 캐시를 무효화하는지 정해야 오래된 값이 정상 응답처럼 제공되는 시간을 줄일 수 있습니다.
무엇과 구분해야 하나요?
| 구분 | 판단 기준 |
|---|---|
| 원본 저장소 | 가장 최신의 기준 데이터를 보관합니다. |
| 브라우저 캐시 | 사용자 기기에 응답을 저장합니다. |
| CDN 캐시 | 여러 지역의 중간 서버가 응답을 재사용합니다. |
| 애플리케이션 캐시 | 계산·쿼리 결과를 서비스 내부에서 보관합니다. |
실무에서는 어떻게 계산하거나 확인하나요?
가상의 단일 쿼리 캐시가 10시 10분에 값을 생성하고 TTL 30분으로 저장했다고 가정합니다. 원본이 10시 20분에 바뀌어도 별도 무효화가 없다면 이 캐시는 10시 40분까지 신선한 것으로 취급될 수 있습니다. 10시 40분이 지난 뒤에도 다음 요청이나 재검증이 없으면 새 값이 자동 생성된다고 단정할 수 없습니다. 이 타임라인은 최대 지연 보장이 아니라 캐시 생성 시각과 TTL의 관계를 설명하는 가상 예시입니다.
운영 설정과 데이터 신선도에서는 무엇을 확인하나요?
MDN은 max-age와 Expires로 신선도 수명을 정하고 오래된 응답을 재검증하는 방식을 설명합니다. MDN HTTP 캐시 안내 운영 문서에 캐시 키, TTL, 무효화 계기, 재검증 헤더, 개인정보 포함 여부를 적습니다. 공급사 대시보드의 내부 캐시는 HTTP 표준 밖일 수 있어 데이터 신선도 SLA와 강제 새로고침 API를 제품 문서에서 확인합니다.
한계와 검수 기준은 무엇인가요?
캐시를 모두 끄면 원본 부하와 지연이 커질 수 있습니다. 반대로 TTL이 길면 가격·재고·권한처럼 즉시 반영돼야 하는 정보가 오래 남습니다. 권한 철회나 삭제 요청 뒤 캐시·CDN·내보내기 파일에 잔여 데이터가 있는지 확인하고 숫자 지연을 원본 수집 실패와 구분합니다.
자주 묻는 질문
- 새로고침하면 캐시가 모두 지워지나요?
- 브라우저 일부만 재검증할 수 있으며 CDN·서버·대시보드 캐시는 남을 수 있습니다.
- TTL 30분이면 항상 30분 뒤 최신인가요?
- 원본 갱신 주기와 다른 캐시 단계가 있어 더 늦을 수 있습니다. 실제 시간표를 확인해야 합니다.
- 캐시와 백업은 같은가요?
- 아닙니다. 캐시는 빠른 재사용이 목적이고 백업은 장애·삭제 복구를 위한 사본입니다.
출처와 확인 범위
- RFC 9111: HTTP Caching · IETF · 확인 2026-10-27
캐시가 이전 응답을 저장·재사용하는 HTTP 표준 메커니즘이라는 근거입니다.
확인 범위: HTTP 캐시 표준이며 애플리케이션·데이터베이스·분석 도구 캐시 전체를 정의하지 않습니다.
- HTTP caching · MDN Web Docs · 확인 2026-10-27
만료·신선도·재검증 때문에 값 갱신 시점이 달라질 수 있다는 근거입니다.
확인 범위: 브라우저·중간 HTTP 캐시 설명이며 공급사 대시보드 내부 캐시는 별도입니다.