CDN 및 캐싱 문제 해결: stale content 문제와 Cloudflare 설정 오류 트러블슈팅

개요: 왜 CDN과 캐싱 이슈는 어렵고, 어떻게 접근해야 할까

CDN과 캐싱은 웹 성능을 비약적으로 개선하지만, 한 번 꼬이면 원인 파악과 해결이 생각보다 복잡합니다. 특히 게시물이나 자산이 업데이트되었는데도 오래된 버전이 보이는 stale content 문제와, Cloudflare 설정 충돌로 인해 캐시가 의도와 다르게 동작하는 문제는 많은 팀이 겪는 대표적인 이슈입니다.

이 글에서는 실무에서 바로 활용할 수 있는 진단 절차, 올바른 헤더 설계, Cloudflare 중심의 설정 모범사례, 그리고 실제로 자주 발생하는 시나리오별 해결책을 상세히 다룹니다. 마지막에는 재발 방지를 위한 체크리스트와 운영 팁도 제공하니, 트러블슈팅 가이드로 활용해 보세요.

Stale Content란 무엇이며, 어디에서 발생하는가

Stale content는 최신 버전이 배포되었는데도 사용자에게 이전 버전(오래된 캐시)이 제공되는 현상입니다. 이 문제는 단일 지점이 아니라 여러 계층에서 발생할 수 있어 진단이 어렵습니다.

대표적인 캐시 계층은 다음과 같습니다.

• 브라우저 캐시: 각 사용자의 로컬 캐시. Cache-Control, ETag, Last-Modified, Service Worker 등에 영향.
• CDN 엣지 캐시: Cloudflare 같은 엣지 POP의 캐시. cf-cache-status로 상태 확인 가능.
• 중간 프록시/ISP 캐시: 일부 네트워크 환경에서 발생.
• 오리진 앞단의 리버스 프록시/애플리케이션 캐시: Nginx, Varnish, Rails/Express/WordPress 플러그인 캐시 등.

포인트는 “어느 계층에서 stale이 발생했는지”를 먼저 좁히는 것입니다. 이를 위해서는 올바른 도구와 절차가 필요합니다.

빠르게 원인 범위를 좁히는 진단 절차

아래 순서대로 확인하면 대다수 stale 문제는 10~20분 내에 원인 범위를 좁힐 수 있습니다.

1. 브라우저 캐시 우회 확인

• 개발자 도구 → Network → Disable cache 체크 후 새로고침.
• 시크릿 모드에서 재현 여부 확인.

2. CDN 캐시 상태 확인 (Cloudflare 기준)

• curl로 헤더 확인:

  curl -I https://example.com/page
  

  또는 브라우저 개발자 도구 Network 패널에서 응답 헤더 확인.
• cf-cache-status 값 해석:
  • HIT: 엣지에서 캐시된 응답 제공
  • MISS: 캐시 미스, 오리진에서 가져옴
  • BYPASS/DYNAMIC: 캐시하지 않음 (규칙, 쿠키, Authorization 등 영향)
  • EXPIRED: TTL 만료로 재검증/재패치
• cf-ray, date, age, cache-control도 함께 확인합니다.

3. 강제 재검증으로 최신 응답 비교

• If-None-Match/If-Modified-Since를 활용한 조건부 요청 확인:

  curl -I -H "Cache-Control: no-cache" https://example.com/page
  

  no-cache는 “재검증 후 제공”을 의미합니다(무조건 미캐시가 아님).

4. 특정 POP(지역)만 stale인지 확인

• VPN 또는 Cloudflare Trace를 활용해 지역별 재현 여부를 확인.
• 일부 POP에서만 stale인 경우, 캐시 전파 지연 또는 엣지 TTL/규칙 문제 가능성이 큼.

5. 오리진 응답 헤더와 CDN 전달 헤더 비교

• 오리진 직접 요청(가능하면 특정 포트/호스트 헤더)으로 원본 헤더를 확인:

  curl -I https://origin.example.com/page -H "Host: example.com"
  

• CDN을 거친 헤더와 비교해 Cache-Control, ETag, Vary, Set-Cookie 등의 차이를 확인.

6. 서비스 워커와 애플리케이션 레벨 캐시 확인

• Service Worker가 fetch 이벤트에서 커스텀 캐시를 제공하는지 확인.
• WordPress/Drupal/Next.js/NGINX/Varnish 레이어 캐시 룰 확인.

캐싱의 핵심 헤더 이해하기

정확한 헤더 설계는 stale 문제의 80%를 예방합니다.

• Cache-Control

  • public/private: 공유 캐시(CDN) 허용 여부
  • max-age=seconds: 브라우저/공유 캐시 TTL
  • s-maxage=seconds: 공유 캐시 전용 TTL (브라우저보다 CDN에 더 공격적으로 캐시 가능)
  • no-cache: 저장은 가능하지만, 제공 전 재검증 필요
  • no-store: 저장 자체 금지 (민감 데이터)
  • must-revalidate: 만료 후 반드시 재검증
  • stale-while-revalidate, stale-if-error: 만료 후에도 일정 시간 신선하지 않은 응답을 제공하는 정책(지원 여부는 CDN별 상이)

• ETag / Last-Modified

  • 조건부 요청(If-None-Match/If-Modified-Since)로 304 Not Modified를 활용해 효율적인 재검증이 가능.

• Vary

  • Vary: Accept-Encoding, Accept, User-Agent, Cookie 등.
  • 과도한 Vary는 캐시 조각화를 유발하고, 잘못된 Vary: Cookie는 HTML 전체 미캐시를 야기할 수 있음.

• Surrogate-Control / CDN 전용 헤더

  • 일부 CDN은 Surrogate-Control 또는 Cloudflare Cache Rules로 엣지 TTL을 별도 제어 가능.

실전 예시(정적 자산):

Cache-Control: public, max-age=31536000, immutable
ETag: "asset-v123"

실전 예시(HTML 문서):

Cache-Control: public, s-maxage=600, max-age=0, must-revalidate
ETag: "page-v456"

Cloudflare 캐시 동작의 기본 이해

• 기본 동작

  • 기본적으로 Cloudflare는 파일 확장자 기반의 정적 자산만 캐시합니다(HTML은 기본 미캐시).
  • cf-cache-status로 캐시 히트 여부를 확인 가능합니다.

• Cache Everything

  • HTML 포함 모든 응답을 캐시하게 만드는 강력한 옵션.
  • 잘못 설정하면 로그인 사용자/개인화 콘텐츠가 캐시되어 중대한 stale/보안 문제가 발생할 수 있음.
  • 반드시 “Bypass on Cookie(예: 세션/로그인 쿠키)”, “Preview/관리페이지 제외” 등과 함께 사용.

• Edge Cache TTL vs Browser Cache TTL

  • Edge(Cloudflare) TTL과 브라우저 TTL은 별도 제어.
  • 오리진 헤더를 존중할지(Respect Existing Headers) 또는 무시하고 엣지 TTL을 강제할지 결정.

• Authorization 헤더

  • Authorization 헤더가 있으면 기본적으로 캐시 우회합니다(보안상 안전).
  • 이를 무시하고 캐시하려면 엔터프라이즈 전용 옵션이 필요할 수 있습니다. 신중히 검토하세요.

• 규칙의 우선순위

  • 새 대시보드에서는 Rules(예: Cache Rules, Origin Rules, Transform Rules)가 페이지 규칙(Page Rules)보다 정교합니다.
  • 규칙의 매칭 순서/우선순위를 명확히 하여 충돌을 방지하세요.

자주 발생하는 stale 시나리오와 해결법

1) 정적 자산이 업데이트되지 않는다: 캐시 무효화 실패 또는 버전 관리 미흡

• 현상: 이미지/CSS/JS 파일이 교체됐는데도 이전 버전이 계속 제공됨.
• 원인
  • 긴 max-age와 immutable을 사용했는데 파일명 버전 관리가 없음.
  • CDN 퍼지(purge)를 안 했거나 부분 퍼지 실패.
• 해결
  • 파일명에 해시/버전을 포함(예: app.7f3a2c.js).
  • 배포 파이프라인에서 “이전 자산은 영구 캐시, 새 자산은 신규 URL” 전략 사용.
  • 필요 시 Cloudflare에서 URL/태그 기반 purge를 자동화.
• 헤더 예시

  Cache-Control: public, max-age=31536000, immutable
  

2) HTML이 예상치 않게 캐시됨: Cache Everything 부작용

• 현상: 로그인했는데 다른 사용자 콘텐츠가 보이거나, 게시물 수정 반영이 지연.
• 원인
  • Cache Everything 규칙이 광범위하게 적용됨.
  • Bypass on Cookie 설정 부재(세션/로그인/관리자 쿠키).
• 해결
  • 로그인 상태를 나타내는 쿠키가 있을 때는 반드시 Bypass.
  • /wp-admin, /preview, /cart, /checkout 등 민감 경로는 캐시 제외.
  • 공개 페이지는 s-maxage로 CDN 캐시만 공격적으로, 브라우저는 no-cache로 재검증하게 설정.
• Cloudflare 팁
  • Cache Rules에서 If Cookie contains “logged_in” → Bypass 캐시.
  • 관리 경로는 별도 규칙으로 캐시 비활성화.

3) 쿼리스트링 무시/캐시 키 불일치

• 현상: ?v=2, ?lang=ko 등 쿼리스트링이 달라도 동일 응답이 제공되거나 반대로 과도한 변형으로 캐시 효율 저하.
• 원인
  • Cloudflare의 Cache Key가 “Ignore Query String”으로 설정되어 구분하지 않음.
  • 반대로 불필요한 파라미터까지 캐시 키에 포함해 캐시 조각화.
• 해결
  • “Standard”로 전환해 전체 쿼리 반영, 또는 필요한 키만 포함하는 커스텀 Cache Key 구성.
  • Analytics로 상위 쿼리 파라미터를 분석하여 화이트리스트/블랙리스트 관리.

4) 쿠키로 인한 캐시 우회 또는 캐시 조각화

• 현상: 특정 사용자만 느리거나 오래된 콘텐츠가 보임.
• 원인
  • 불필요한 Set-Cookie가 정적 파일/HTML에 섞여 공유 캐시를 무력화.
  • Vary: Cookie 또는 Cache Key에 Cookie가 반영되어 캐시 파편화.
• 해결
  • 정적 자산 응답에서 Set-Cookie 제거.
  • 개인화가 필요 없는 페이지는 쿠키 의존성 제거.
  • Cloudflare Cache Rules에서 “Bypass on Cookie”를 최소화하고, 꼭 필요한 쿠키만 조건에 사용.

5) WordPress + APO 사용 시 게시물 반영 지연

• 현상: 게시물 업데이트 후 일부 지역에서 오래된 페이지가 보임.
• 원인
  • 퍼지가 사이트 전체가 아닌 부분 퍼지로 끝나거나, 태그/카테고리 캐시 연쇄 무효화가 누락.
• 해결
  • 게시/업데이트 후 Cloudflare API로 관련 URL/태그 일괄 퍼지 자동화.
  • 페이지, 카테고리, 홈, RSS 등 연관 경로를 함께 퍼지.
  • 필요 시 Edge TTL을 짧게, stale-while-revalidate로 경험 품질 유지(지원 범위 확인).

6) 오리진 헤더와 Cloudflare 규칙 충돌

• 현상: 오리진은 no-cache를 보냈는데 Cloudflare에서 강제로 Edge TTL을 적용해 HTML이 캐시됨.
• 원인
  • Cache Rules에서 “Override cache TTL”이 오리진 의도와 충돌.
• 해결
  • 민감 경로/리소스는 “Respect existing headers” 우선.
  • 정적만 강제 TTL, HTML은 오리진 제어 그대로 따르기.

7) 서비스 워커/프리렌더 캐시 영향

• 현상: CDN과 오리진 헤더를 수정해도 특정 사용자에게만 stale.
• 원인
  • Service Worker가 자체 캐시에서 응답 제공.
• 해결
  • 서비스 워커 스크립트에서 캐시 버전 관리 및 활성화/비활성화 시나리오 관리.
  • 배포 시 서비스 워커 버전 업데이트 및 clients.claim(), skipWaiting() 전략 검토.

Cloudflare에서 즉시 적용 가능한 설정 모범사례

1. 정적 자산

• 파일명 버전 전략 + 장기 캐시:
  • Cache-Control: public, max-age=31536000, immutable
• Cache Rules: 정적 확장자 그룹에만 Edge Cache TTL 강제(오리진 헤더 무시 OK).

2. HTML 문서

• 오리진:
  • Cache-Control: public, s-maxage=300, max-age=0, must-revalidate
  • ETag 또는 Last-Modified 제공
• Cloudflare:
  • Cache Everything는 신중히. 적용한다면:
    • Bypass on Cookie(세션/로그인/장바구니).
    • 관리 경로/프리뷰 경로 Bypass.
  • Edge TTL은 s-maxage와 일치 또는 약간 상향.
  • Respect Existing Headers 기본, 특정 경로에서만 Override.

3. 쿠키/Authorization

• Authorization 헤더 포함 요청은 기본 Bypass 유지(보안상 권장).
• 불필요한 Set-Cookie 제거. 정적 응답에는 절대 Set-Cookie 금지.

4. 캐시 키

• 기본 “Standard” 유지.
• 필요 시 커스텀 키로 주요 파라미터만 포함.
• 디바이스/언어 분기 시 헤더 기반 변형은 Vary 관리에 주의.

5. 퍼지 전략

• 태그 기반 퍼지 사용(가능한 경우). 예: Cache-Tag: post-123, category-45.
• 배포 파이프라인에서 관련 URL 일괄 퍼지.
• 글로벌 Purge Everything는 비상시에만.

실전: 헤더/규칙 예시와 커맨드

1. curl로 캐시 상태 빠르게 보기

curl -I https://example.com/
# 확인 포인트: cf-cache-status, cache-control, etag/last-modified, age

2. 브라우저 캐시 우회 재검증

curl -I -H "Cache-Control: no-cache" https://example.com/

3. 오리진 직접 확인(Cloudflare 우회)

curl -I https://origin.example.com/home -H "Host: example.com"

4. Cloudflare 퍼지 API(단일 URL)

POST https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache
Authorization: Bearer {API_TOKEN}
Content-Type: application/json

{
  "files": [
    "https://example.com/",
    "https://example.com/styles/app.7f3a2c.css"
  ]
}

5. HTML 캐싱 최소 안전 규칙(개념)

• Cache Rules
  • If Path matches “/wp-admin*” OR “/cart*” OR “/checkout*” → Cache: Bypass
  • If Cookie contains “logged_in” OR “session” → Cache: Bypass
  • Else if Path matches “/blog/*” → Cache: Eligible, Edge TTL: 300s, Respect Origin Headers

Cloudflare 설정 오류 트러블슈팅 가이드

아래는 실제로 자주 보는 설정 실수와 해결책입니다.

1. Cache Everything을 전역에 적용

• 증상: 로그인/장바구니/맞춤 콘텐츠가 캐시됨.
• 해결: 민감 경로/쿠키 기반 Bypass 규칙 추가. 공개 페이지에만 제한적으로 적용.

2. 규칙 충돌(우선순위 문제)

• 증상: 기대한 규칙이 적용되지 않음, cf-cache-status가 일관되지 않음.
• 해결: 규칙 평가 순서 재배치. 좁은 범위(특정 경로/도메인) 규칙을 상단에.

3. 오리진 헤더 무시

• 증상: 오리진이 no-cache지만 엣지에서 캐시됨.
• 해결: 해당 경로는 Respect existing headers. 강제 TTL은 정적 자산에만.

4. Authorization 헤더 포함 요청 캐시

• 증상: 민감 응답이 캐시되거나, 의도치 않은 BYPASS로 성능 저하.
• 해결: 기본 BYPASS 유지. 엔터프라이즈 옵션으로 바꿀 경우 보안 검토와 스코프 제한 필수.

5. 리디렉트 캐시 문제(301/302)

• 증상: 리디렉트가 오래 유지되어 경로 변경 반영 지연.
• 해결: 301은 장기 캐시됨. 변경 가능성이 있다면 302/307 + 짧은 TTL, 또는 리디렉트 헤더에 적절한 Cache-Control 부여. 변경 확정 시에만 301.

6. 무분별한 Set-Cookie

• 증상: 공유 캐시가 비활성화되어 TTFB 증가, 사용자는 stale 체감.
• 해결: 정적/공개 페이지에서 Set-Cookie 제거. 앱 레벨 중간웨어 점검.

7. Transform/Rewrite가 Cache Key를 바꿈

• 증상: 동일 리소스가 여러 캐시 키로 저장되거나, 반대로 동일 키로 충돌.
• 해결: Transform Rules 확인. Cache Key 커스텀 시 포함/제외 요소를 명시.

8. Development Mode/Bypass 전역 활성화 후 해제 누락

• 증상: 캐시가 전혀 작동하지 않음, 지속적인 MISS.
• 해결: 개발 모드 타이머/자동 만료 활용. 배포 스크립트에서 모드 전환 자동화.

9. APO/플러그인 퍼지 누락

• 증상: 부분 퍼지만 수행되어 관련 페이지 stale.
• 해결: 게시 이벤트에 연결된 퍼지 훅을 점검하고 관련 URL/태그를 포괄.

10. 원본 타임스탬프/시간대 문제

• 증상: Last-Modified가 미래/과거로 잘못 설정되어 재검증 비정상.
• 해결: 서버 시간 동기화(NTP). 빌드 시각과 헤더 일관성 유지.

퍼지 전략: 최소 다운타임으로 최신 콘텐츠 반영하기

• 파일명 버전이 최우선: 정적 자산은 퍼지 없이도 즉시 반영 가능.
• 태그 기반 퍼지: Cache-Tag 헤더로 관련 리소스를 하나의 태그로 묶어 퍼지. 대규모 사이트에 효과적.
• URL 리스트 퍼지: 배포 시 변경된 경로만 선택적 퍼지.
• 글로벌 퍼지는 최후의 수단: 전체 엣지 캐시 무효화는 성능에 큰 영향을 줌.
• 퍼지 전파 지연 감안: 일부 POP에서 수 초~수 분 차이 가능. 치명 경로는 TTL을 짧게 조정.

권장 캐싱 정책 템플릿

1. 정적(버전드) 자산

• 오리진:
  • Cache-Control: public, max-age=31536000, immutable
  • ETag(Optional)
• Cloudflare:
  • Edge TTL 1년(또는 Respect Origin). Purge 불필요.

2. HTML(공개 페이지)

• 오리진:
  • Cache-Control: public, s-maxage=300, max-age=0, must-revalidate
  • ETag 또는 Last-Modified
• Cloudflare:
  • Cache Eligible(또는 Cache Everything 제한적 적용)
  • Bypass on Cookie/관리 경로 제외
  • Edge TTL 300s, 오리진 헤더 존중

3. HTML(로그인/개인화)

• 오리진:
  • Cache-Control: private, no-store 또는 no-cache
• Cloudflare:
  • Bypass

4. API

• 인증 필요한 API: 기본 Bypass
• 공개 읽기 API:
  • Cache-Control: public, s-maxage=60, stale-if-error=60(지원 범위 확인)
  • 오류 시 stale 제공으로 가용성 개선

모니터링과 알림

• Edge Cache Hit Ratio(ECHR): 전체/경로별 확인. 급락 시 규칙/오리진 헤더 변경 여부 점검.
• 오리진 egress/TTFB: 캐시 미스 증가로 오리진 부하 급증 여부 모니터링.
• 퍼지 이벤트 로깅: 누가, 언제, 어떤 범위로 퍼지했는지 감시.
• 주요 페이지 합성 모니터링: 새 릴리스 후 stale/미스매치 감지.
• cf-ray 샘플링: 지역별 이슈 시 빠른 상관 분석.

운영 체크리스트(재발 방지를 위한 요약)

• 정적 자산:

  • 파일명 버전/해시 적용
  • 장기 캐시 + immutable
  • Set-Cookie 금지

• HTML/동적:

  • 공개 페이지: s-maxage 활용, 브라우저는 재검증
  • 로그인/장바구니/관리: Bypass 규칙
  • Cache Everything는 제한적, 규칙 우선순위 점검

• Cloudflare 규칙:

  • Cache Rules 순서 확인(좁은 범위 우선)
  • Respect existing headers 기본, 특정 정적에만 Override
  • Authorization 헤더 기본 Bypass 유지

• 퍼지:

  • 배포 시 URL/태그 퍼지 자동화
  • 글로벌 퍼지는 비상시에만
  • 퍼지 전파 시간 고려한 Edge TTL 설정

• 관측/도구:

  • cf-cache-status 모니터링
  • 오리진/엣지 헤더 비교 자동화
  • 서비스 워커 캐시 버전 관리

사례로 보는 종합 트러블슈팅 흐름

상황: 블로그 포스트 업데이트 후 일부 사용자가 이전 버전을 봄.

1. 재현 확인

• 시크릿 모드, 다른 지역 VPN에서 테스트 → 일부 지역에서만 stale.

2. 헤더 점검

• curl -I로 cf-cache-status=HIT, age가 오래됨 확인.
• 오리진 직접 조회 시 최신 콘텐츠, ETag 갱신됨.

3. 원인 추론

• Cloudflare Edge TTL이 길거나, 퍼지 미수행으로 일부 POP에 오래된 캐시 잔존.

4. 해결

• 관련 URL/태그 퍼지 API 호출.
• Cache Rules에서 HTML의 Edge TTL을 300s로 단축, 오리진 s-maxage 준수.
• 배포 파이프라인에 퍼지 자동화 추가(포스트, 홈, 카테고리, RSS 동시 퍼지).

5. 재발 방지

• 공개 페이지에는 s-maxage=300, 브라우저 max-age=0 설계.
• 워드프레스 편집 이벤트에 퍼지 트리거 연결.
• 모니터링 알림: 업데이트 후 10분 내 ECHR/TTFB 변동 감시.

마무리: “빠른 웹”과 “안정적 업데이트”는 설계와 습관의 산물

CDN과 캐싱은 빠른 웹을 만드는 필수 도구지만, 설계와 운영 습관이 없다면 stale content와 설정 충돌로 인해 오히려 위험 요소가 됩니다. 핵심은 다음입니다.

• 오리진 헤더를 바르게 설계하고, Cloudflare 규칙은 “필요한 곳에만” 정밀하게 적용할 것.
• 파일명 버전 전략과 자동 퍼지로 업데이트 동기화를 체계화할 것.
• Cache Everything 같은 강력한 옵션은 범위를 좁히고 예외를 명확히 할 것.
• 문제 발생 시 표준화된 진단 절차(curl, 헤더 비교, 지역 확인)로 빠르게 범위를 좁힐 것.

이 가이드를 팀의 런북으로 정리해두면, 다음 배포 때 더 빠른 속도와 더 적은 장애로 사용자에게 최신 경험을 제공할 수 있습니다.