배포형 호스팅의 캐시, 배포마다 응답이 달라지는 이유
플랫폼 캐시의 적중 상태와 배포 시 무효화 범위를 이해해 오래된 응답을 막습니다.

- 문제 경로의 응답 헤더로 적중 상태를 분류했다
- 정적 자원에 이름 기반 식별자를 적용했다
- 경로별 허용 지연을 정했다
응답 헤더로 캐시 상태를 먼저 확인합니다
배포형 호스팅에서 '예전 내용이 보인다' 또는 '왜 느리다'는 문제를 다룰 때 가장 먼저 할 일은 응답 헤더를 보는 것입니다. 대개 캐시 적중 여부를 알려 주는 헤더가 있고, 적중과 미적중과 우회 중 어느 상태인지 표시됩니다. 이 값을 보지 않고 추측하면 엉뚱한 설정을 고치게 됩니다. 확인 순서는 1단계 문제 경로의 응답 헤더 수집, 2단계 적중 상태 분류, 3단계 상태별 원인 대조입니다. 미적중이 계속 나오면 캐시 조건이 맞지 않는 것이고, 우회로 표시되면 캐시를 쓰지 않도록 설정된 경로입니다. 두 원인은 조치가 완전히 다릅니다.
배포가 캐시를 비우는 범위를 압니다
새 배포가 나가면 이전 결과가 더 이상 쓰이지 않아야 하므로 캐시가 비워집니다. 문제는 그 범위입니다. 전체가 비워지면 배포 직후 모든 요청이 원본으로 가서 응답이 느려지고 원본 처리 요금이 늘어납니다. 그래서 자주 배포하는 사이트는 배포 직후 구간의 지표를 따로 봅니다. 완화 방법은 두 가지입니다. 첫째, 내용이 바뀌지 않는 정적 자원은 이름에 식별자를 넣어 배포와 무관하게 재사용되게 합니다. 둘째, 자주 바뀌지 않는 페이지는 미리 생성해 두는 방식으로 두어 원본 계산을 건너뜁니다. 두 방법을 함께 쓰면 배포 직후의 충격이 줄어듭니다.
적중률을 올렸을 때의 금액을 냅니다
학습용 가정으로 계산합니다. 가정값은 월 요청 1,000,000건이고 현재 적중률 60퍼센트에서 90퍼센트로 올린다고 두겠습니다. 원본으로 가는 요청은 400,000건에서 100,000건으로 줄어듭니다. 원본 처리 단가를 건당 0.2원으로 가정하면 각각 80,000원과 20,000원입니다. 중간 계산값인 절감액은 월 60,000원입니다. 최종 효과에는 응답 시간 개선이 더해집니다. 원본 계산을 건너뛴 요청은 더 빠르게 응답하므로 사용자 체감이 함께 좋아집니다. 다만 적중률을 올리려고 보관 시간을 길게 두면 내용 갱신이 늦어지므로, 경로별로 허용 지연을 정해야 합니다.
개인화 응답을 캐시하면 사고가 됩니다
결론을 뒤집는 조건은 응답의 개인화입니다. 로그인 사용자 이름이나 권한에 따라 달라지는 내용을 공용 캐시에 저장하면 다른 사용자에게 그 내용이 보일 수 있습니다. 이것은 성능 문제가 아니라 사고입니다. 그래서 적중률을 올리는 작업 전에 경로별로 개인화 여부를 표로 적고, 개인화 경로는 공용 캐시 대상에서 제외한다고 명시합니다. 두 번째 조건은 쿠키입니다. 요청에 쿠키가 있으면 캐시를 쓰지 않도록 동작하는 경우가 많으므로, 분석용 쿠키가 모든 요청에 붙어 있으면 적중률이 올라가지 않습니다. 그래서 쿠키 사용 범위를 함께 점검합니다.
웹호스팅 실행 전 점검표
- 문제 경로의 응답 헤더로 적중 상태를 분류했다
- 정적 자원에 이름 기반 식별자를 적용했다
- 경로별 허용 지연을 정했다
- 개인화 경로를 공용 캐시 대상에서 제외했다
이 가이드의 근거 문서
출처 확인일: 2026-10-19. 공식 문서에 기반한 편집 가이드이며 직접 수행한 벤치마크가 아닙니다. 비용 사례는 명시된 가정에 한합니다.
오류 제보 방법