왜 알아야 할까
브라우저 캐시와 CDN 캐시 불일치: 정상처럼 보이는 한 사례만으로는 동작 범위를 이해하기 어렵습니다. 대표 입력에서는 문제없다가 경계값, 느린 응답, 배포 직후처럼 조건이 달라질 때 결과가 바뀔 수 있습니다.
browser cache와 CDN cache는 서로 다른 key·TTL·재검증 규칙을 가지므로 응답 header와 cache 계층을 따로 확인해야 합니다.
동작을 나누어 보기
브라우저, CDN, 프록시, 애플리케이션과 데이터 저장소가 연결된 전체 요청 경로에서 어느 경계가 결과를 결정하는지 먼저 봅니다. 브라우저, CDN, framework, application과 DB cache를 각각 분리합니다. cache key, TTL, tag, 소유 instance와 변경 직후 허용할 stale 시간을 적어야 어디가 오래된 값을 주는지 알 수 있습니다.
| 구분 | 짧은 예시 |
|---|---|
| 기대 결과 | 브라우저 캐시와 CDN 캐시 불일치: 정상 조건에서 사용자가 받아야 할 결과 |
| 실제 결과 | 같은 입력에서 처음 달라진 값·상태·오류 |
| 판별 자료 | 요청 ID로 navigation timing, HTTP 상태, upstream 시간과 서버 trace를 같은 시간축에 놓는다 |
작게 적용하는 방법
실패 경계를 먼저 확정하고 가장 안쪽 원인을 수정한 뒤 timeout과 재시도 예산을 바깥 계층까지 맞춘다. 데이터 변경 지점에서 정확한 key나 tag를 무효화하고 사용자별 응답은 공유 cache에서 제외합니다. 다중 instance에서는 process local 무효화만으로 일관성이 생기지 않습니다.
대표 사례 하나, 값이 달라지는 경계 하나, 예상 가능한 실패 하나를 같은 순서로 확인합니다. 실사용자 지표와 부하 테스트에서 p50/p95/p99, 오류율, 처리량과 자원 포화를 함께 비교한다. cold, hit, stale, mutation 직후, 여러 instance와 rolling deployment 조건에서 응답 header와 실제 값을 함께 확인합니다.
공식 문서와 적용 범위
문서의 기본값과 동작은 version에 따라 달라질 수 있습니다. 지원하는 browser, viewport, 입력 방식과 실제 network 조건에서 다시 확인합니다.