작은 사이트에서 자주 겪는 CDN 캐시 실수
CloudPlare 편집 노트 · 최초 작성 2026-06-04 · 최종 검토 2026-06-10 · 8분 읽기
CDN은 느린 서버를 감추는 도구가 아니라 응답을 여러 위치에서 재사용하는 계층입니다. 작은 사이트에서 흔히 생기는 오해를 실제 점검 순서로 풀었습니다.
CDN은 배포물을 한 번 더 들고 있다
원본 서버에 새 파일이 올라갔는데 방문자는 예전 화면을 볼 수 있습니다. CDN이 이전 응답을 아직 신선하다고 판단하기 때문입니다. 이 상황에서 코드를 계속 다시 배포하면 원인은 그대로인데 변경 이력만 늘어납니다.
먼저 확인할 것은 어느 계층이 오래된 응답을 주는지입니다. 원본 URL, CDN이 붙은 도메인, 브라우저 강력 새로고침, 다른 네트워크를 나눠서 확인하면 원본 문제인지 CDN 문제인지 분리할 수 있습니다.
전체 삭제보다 경로 삭제가 안전하다
급할 때 전체 캐시 삭제를 누르기 쉽지만, 트래픽이 있는 사이트에서는 갑자기 모든 요청이 원본으로 몰릴 수 있습니다. 작은 사이트라도 이미지와 정적 자산이 많으면 배포 직후 원본 부하가 튈 수 있습니다. 문제가 특정 HTML이나 특정 이미지라면 경로 단위로 지우는 편이 낫습니다.
캐시 삭제 전에는 어떤 URL이 오래됐는지 정확히 적습니다. /about인지 /notes/foo인지, 이미지 파일인지 HTML인지에 따라 처리 방법이 달라집니다. 캐시 문제를 “사이트가 이상함”으로 묶으면 원인을 찾기 어려워집니다.
쿠키와 쿼리 문자열을 가볍게 보지 않는다
CDN은 설정에 따라 쿠키, 헤더, 쿼리 문자열을 캐시 키에 포함하거나 제외합니다. 같은 URL처럼 보여도 쿼리 문자열이 다르면 다른 캐시로 취급될 수 있고, 반대로 쿼리를 무시하면 실제로 다른 응답이어야 할 요청이 같은 캐시를 공유할 수 있습니다.
정적 블로그나 문서 사이트라면 쿼리 문자열을 거의 쓰지 않는 편이 단순합니다. 추적 파라미터가 붙은 URL이 색인되거나 공유되지 않도록 canonical과 내부 링크를 정리하는 것도 함께 봐야 합니다.
캐시 히트율보다 사용자에게 맞는 응답이 먼저다
캐시 히트율이 높으면 비용과 속도에는 유리하지만, 사용자마다 달라야 하는 응답까지 캐시하면 문제가 됩니다. 로그인, 장바구니, 지역별 가격처럼 개인화가 필요한 페이지는 공유 캐시 대상이 아닙니다. CloudPlare 같은 읽기 중심 사이트는 대부분 정적 문서라 비교적 단순하지만, 문의 폼이나 관리자 페이지가 붙으면 정책을 다시 나눠야 합니다.
읽기 중심 콘텐츠 사이트에서는 과한 캐시 설정보다 안정적인 최신 문서 노출이 더 중요합니다. 특히 소개, 정책, 편집 기준 같은 신뢰 페이지는 변경 후 실제 도메인에서 바로 확인하는 습관을 들이는 것이 좋습니다.
운영 체크리스트
- 오래된 응답이 원본 서버인지 CDN인지 분리해서 확인했다.
- 캐시 삭제 대상 URL을 기록하고 경로 단위 삭제를 우선 검토했다.
- 쿼리 문자열과 쿠키가 캐시 키에 미치는 영향을 확인했다.
- 개인화 응답을 공유 캐시에 저장하지 않도록 구분했다.
- 캐시 삭제 후 실제 도메인과 다른 네트워크에서 재확인했다.
확인한 공식 자료
아래 자료를 바탕으로 운영 관점의 설명을 덧붙였습니다. 세부 동작은 서비스와 배포 환경에 따라 달라질 수 있습니다.