견고한 Cloudflare CDN 캐싱 정책을 구성하는 것은 2026년 엔터프라이즈 웹사이트의 속도를 최적화하기 위한 가장 영향력 있는 엔지니어링 작업 중 하나입니다. 많은 웹 플랫폼은 모든 사용자 요청이 페이지를 렌더링하기 위해 오리진 데이터베이스 서버까지 이동해야 하기 때문에 높은 지연 시간에 시달립니다. 이러한 오리진 의존성은 First Contentful Paint(FCP)와 Largest Contentful Paint(LCP) 속도 지표를 지연시키는 반면, 정적 페이지 레이아웃과 자산 구성 요소를 전 세계 엣지 위치에 저장하면 가장 가까운 엣지 위치에서 빠르고 지연 시간이 낮은 응답을 제공합니다. 이 가이드는 캐싱 메커니즘, Edge Cache TTL 규칙, 동적 쿠키 우회 구성을 자세히 설명합니다.
[!TIP] 캐싱 최적화 팁: 로그인한 사용자 정보가 포함된 HTML 페이지는 캐싱하지 마세요. 특정 세션 쿠키(예: WordPress 쿠키 또는 사용자 지정 인증 토큰)가 요청 헤더에서 감지되면 엣지 캐싱을 우회하도록 항상 Cache Rules를 구성하세요.
핵심 요점:
- Cloudflare CDN 캐싱은 백엔드 서버의 데이터베이스 쿼리를 줄여 호스팅 비용을 절감합니다.
- Cache Rules를 통해 개발자는 콘텐츠 유형과 디렉터리에 따라 사용자 지정 TTL 값을 설정할 수 있습니다.
- Cache Everything 규칙을 배포하려면 사용자 데이터 유출을 방지하기 위해 세션 쿠키 우회를 구성해야 합니다.
- 엣지 위치에서 정적 페이지를 직접 제공하면 웹사이트가 모바일 기기에서 Core Web Vitals를 통과하는 데 도움이 됩니다.
캐싱 구성: Page Rules 대 Cache Rules
전송 파이프라인을 최대한 활용하려면 적절한 대시보드 제어 모델을 선택해야 합니다. Cloudflare Developer Docs 의 캐싱 가이드라인에 따르면, 기존 Page Rules는 모듈식 Cache Rules로 대체되고 있습니다. 따라서 개발자는 다음 구성을 구현해야 합니다:
기본적으로 CDN 네트워크는 미디어 형식, 스타일시트, 스크립트만 캐싱합니다. 따라서 세 가지 핵심 자산 옵션을 구성해야 합니다:
- HTML 캐싱: 즉각적인 페이지 로딩을 달성하려면 CDN에 HTML 문서 구조를 캐싱하도록 지시해야 합니다. 따라서 이는 데이터베이스 쿼리를 중단시킵니다.
- Cache-Control 헤더: Symfony 또는 PHP 백엔드 서버가 사용자 지정
s-maxage지시문을 전송하도록 구성하여 엣지 서버에 페이지를 얼마나 오래 저장할지 지시하세요. 또한 이를 통해 사용자 지정 TTL 규칙이 가능해집니다. - 브라우저 캐시 TTL: 사이트 레이아웃을 수정할 때 사용자가 업데이트를 받을 수 있도록 더 짧은 브라우저 캐시 수명(예: 4시간)을 설정하세요. 따라서 이는 레이아웃 불일치 문제를 방지합니다.
대화형 웹 포털의 경우 모든 페이지를 일괄적으로 캐싱할 수 없습니다. 따라서 두 가지 동적 우회 규칙을 설정해야 합니다:
- 세션 우회: 요청에 인증 또는 세션 쿠키가 포함된 경우 CDN이 캐싱을 우회하도록 지시하는 규칙을 만드세요. 이렇게 하면 로그인한 사용자는 항상 개인화된 응답을 받고, 익명 방문자는 여전히 엣지 캐시에서 콘텐츠를 제공받습니다.
- 쿼리 문자열 정렬: 캐시 키를 평가할 때 엣지 데이터베이스 캐시가 사소한 분석 변수(예: UTM 태그)를 무시하도록 구성하세요. 따라서 이는 캐시 단편화를 방지합니다.
엔터프라이즈 엣지 캐싱 전략을 안전하게 배포하려면 이 기술 검증 순서를 따르세요. 다음 네 가지 최적화 단계를 채택하세요:
- HTTP 헤더 감사: 오리진 서버가 인증 차단 없이 깔끔한
Cache-Control및Vary헤더를 전송하는지 확인하세요. - 모듈식 Cache Rules 작성: 정적 카테고리 디렉터리를 최대 30일간 저장하도록 대상 Cache Rules를 구성하세요.
- 인증 예외 구축: 로그인 쿠키가 감지되면 엣지 캐시를 우회하는 규칙을 만드세요.
- Purge API 웹훅 배포: 페이지를 업데이트할 때 자동화된 Purge API 요청을 트리거하도록 데이터베이스 저장 작업을 구성하세요.
성능 비교: 엣지 캐싱 대 오리진 페치
속도 이점을 설명하기 위해 다음 표는 실제 로딩 지표를 자세히 보여줍니다:
| 성능 지표 | 오리진 서버 페치(CDN 캐시 없음) | 엣지 캐시 히트(CDN 활성) | 예상 속도 개선 |
|---|---|---|---|
| Time to First Byte (TTFB) | 450 - 800밀리초 | 15 - 35밀리초 | 초기 서버 응답 최대 95% 향상 |
| 모바일 LCP(가장 큰 이미지) | 3.8초(나쁨) | 1.4초(좋음) | Core Web Vitals 지표를 깔끔하게 통과 |
| 오리진 CPU 부하 | 높음(모든 페이지가 데이터베이스를 쿼리) | 최소(엣지가 히트의 90%를 처리) | 호스팅 비용 절감 및 안정성 향상 |
사전 요구 사항
대시보드를 다루기 전에 다음 사항이 준비되어 있는지 확인하세요:
- 이미 Cloudflare를 통해 프록시된 도메인(회색/DNS 전용이 아닌 주황색 구름 DNS 설정).
- 응답 헤더를 설정할 수 있도록 오리진 구성(Nginx, Apache 또는 애플리케이션 계층)에 대한 액세스.
- 퍼지를 자동화하려는 경우 Zone → Cache Purge 범위로 지정된 API 토큰. My Profile → API Tokens에서 생성하세요.
- 원시 HTTP 헤더를 검사할 수 있는 방법: 명령줄의
curl또는 Chrome DevTools의 Network 탭. - 사이트 전체에 배포하기 전에 실험할 수 있는 스테이징 URL 또는 트래픽이 적은 경로.
아래의 모든 단계를 따르는 데는 Free 또는 Pro 요금제로 충분합니다. Cache Rules는 모든 요금제에서 사용할 수 있지만, 일부 캐시 키 옵션과 Tiered Cache는 상위 등급에서만 제공됩니다.
1단계: 오리진에서 올바른 Cache-Control 헤더 전송
Cloudflare는 오리진이 적극적으로 금지하지 않는 경우에만 응답을 캐싱 가능한 것으로 처리합니다. HTML이 절대 캐싱되지 않는 가장 흔한 이유는 오리진이 모든 요청에 대해 Set-Cookie 헤더 또는 제한적인 Cache-Control을 반환하는 것입니다.
오리진에서 명시적인 지시문을 설정하세요. Nginx의 경우:
1location ~* \.(css|js|woff2|jpg|png|webp|svg)$ {
2 add_header Cache-Control "public, max-age=31536000, immutable";
3}
4
5location / {
6 # HTML: short browser life, long shared (edge) life
7 add_header Cache-Control "public, max-age=0, s-maxage=86400";
8}
s-maxage 지시문은 Cloudflare 엣지와 같은 공유 캐시를 대상으로 하며, max-age=0은 방문자의 브라우저가 계속 재검증하도록 하여 배포 후 오래된 HTML을 절대 보지 않게 합니다. 핑거프린트된 자산의 immutable 토큰은 브라우저에 이를 전혀 재검증하지 말라고 지시합니다.
애플리케이션 기반 응답(PHP 또는 Symfony)의 경우 코드에서 동일한 의도를 표현하세요:
1$response->setPublic();
2$response->setMaxAge(0); // browser
3$response->setSharedMaxAge(86400); // edge / s-maxage
인증되거나 개인화된 응답은 명시적으로 옵트아웃해야 하며, 그렇지 않으면 광범위한 규칙이 한 사용자의 페이지를 다른 사용자에게 제공할 수 있습니다:
1Cache-Control: private, no-store
2단계: Cache Rule로 HTML을 캐시 대상으로 만들기
기본적으로 Cloudflare는 HTML을 DYNAMIC으로 표시하고 절대 저장하지 않습니다. 이를 변경하려면 Caching → Cache Rules → Create rule에서 규칙을 만드세요.
동적인 것을 모두 제외하면서 캐싱하려는 페이지와 일치하는 표현식을 작성하세요:
1(http.host eq "example.com"
2 and not starts_with(http.request.uri.path, "/wp-admin")
3 and not starts_with(http.request.uri.path, "/cart")
4 and not starts_with(http.request.uri.path, "/checkout")
5 and not starts_with(http.request.uri.path, "/my-account"))
그런 다음 규칙 작업을 설정하세요:
- Cache eligibility: Eligible for cache — 기존 “Cache Everything” 동작의 최신 대응 항목입니다.
- Edge TTL: Use cache-control header if present — 1단계에서 설정한
s-maxage가 우선하도록 합니다. 헤더가 없으면 1일과 같은 고정 값으로 대체됩니다. - Browser TTL: Respect origin.
3단계: 로그인한 사용자가 절대 캐싱되지 않도록 쿠키 우회 추가
이는 대부분의 가이드가 건너뛰는 단계이며, 건너뛸 경우 데이터가 유출되는 단계입니다. 실제 세션 쿠키가 있을 때마다 우회를 강제하는 두 번째 규칙을 적격성 규칙 위에 배치하세요. Cloudflare는 Cache Rules를 위에서 아래로 평가하므로, 앞선 우회 규칙이 인증된 방문자에 대해 항상 우선합니다.
1http.cookie contains "wordpress_logged_in_"
2or http.cookie contains "wp-postpass_"
3or http.cookie contains "woocommerce_items_in_cart"
4or http.cookie contains "comment_author_"
작업을 Bypass cache로 설정하세요. WordPress가 아닌 스택의 경우 쿠키 이름을 프레임워크의 세션 식별자(PHPSESSID, laravel_session, connect.sid 등)로 교체하세요. 범위를 엄격하게 지정하세요. 여기서 _ga와 같은 광범위한 분석 쿠키를 매칭하면 모든 익명 방문자에 대해서도 실수로 캐시를 우회하게 됩니다.
4단계: 캐시 키 정규화
추적 매개변수만 다른 두 URL은 하나의 캐싱된 객체를 공유해야 합니다. 적격성 규칙 내에서 Cache Key → Query String을 열고 Ignore specific query string parameters를 선택한 다음 분석 키를 나열하세요:
1utm_source, utm_medium, utm_campaign, utm_term, utm_content, fbclid, gclid
이렇게 하면 /pricing?utm_source=newsletter와 /pricing?gclid=123이 하나의 캐싱된 항목으로 통합되어, 수천 개의 거의 중복된 키로 분산시키는 대신 히트율을 높입니다.
캐시 HIT 또는 MISS 확인 방법
규칙이 작동한다고 절대 가정하지 말고 측정하세요. Cloudflare가 제공하는 모든 응답에는 cf-cache-status 헤더가 포함되어 있습니다. 동일한 URL을 두 번 요청하고 변화를 지켜보세요:
1curl -sI https://example.com/ | grep -i cf-cache-status
2# First request: cf-cache-status: MISS
3# Second request: cf-cache-status: HIT
접하게 될 값과 각각의 의미:
cf-cache-status | 의미 | 조치 |
|---|---|---|
| HIT | 엣지에서 직접 제공됨 | 의도대로 작동 중 |
| MISS | 아직 캐싱되지 않음, 오리진에서 가져와 이제 저장됨 | 다시 요청하여 HIT가 되는지 확인 |
| DYNAMIC | Cloudflare가 캐싱 불가로 판단함 | 규칙이 일치하지 않거나 오리진이 캐싱을 금지함 |
| BYPASS | 규칙 또는 쿠키 우회가 캐시를 건너뜀 | 로그인 요청에서 예상됨 |
| EXPIRED | TTL 경과, 오리진과 재검증됨 | 정상, 너무 자주 발생하면 Edge TTL을 높이세요 |
| REVALIDATED | 오래됨, ETag를 통해 여전히 최신임이 확인됨 | 정상 |
DYNAMIC만 계속 보인다면 적격성 규칙이 실행되지 않는 것입니다. 표현식의 호스트 이름을 확인한 다음, 오리진이 HTML 문서에 Cache-Control: private 또는 Set-Cookie를 전송하지 않는지 확인하세요.
흔한 함정과 문제 해결
- 모든 응답의
Set-Cookie. Cloudflare는 쿠키를 설정하는 응답을 캐싱하지 않습니다. 분석 플러그인, CSRF 토큰, A/B 테스트 도구는 종종 HTML 문서에 이를 첨부합니다. 해당 로직을 비동기 요청으로 이동하거나 캐싱 가능한 경로에서 헤더를 제거하세요. - 익명 방문자의
BYPASS. 거의 항상 너무 광범위한 쿠키 우회 규칙 때문입니다 — 표현식과 일치하는_ga와 같은 일반 쿠키. 우회를 실제 세션 쿠키로만 제한하세요. - 배포 후 오래된 페이지. Edge TTL이 제 역할을 하고 있는 것입니다. 단지 퍼지를 잊었을 뿐입니다. TTL을 몇 초로 단축하는 대신 게시 시 대상 퍼지를 트리거하세요.
- 무시되는 Vary 헤더. Cloudflare는
Accept-Encoding에 대해서만 캐시를 분기합니다. 임의의Vary: User-Agent또는Vary: Cookie에 대해 별도의 복사본을 유지하지 않습니다. Vary에 의존하는 대신 반응형 CSS 또는 Worker를 통해 기기별 마크업을 제공하세요. - 켜진 채로 남겨진 Development Mode. 이는 세 시간 동안 캐시를 우회하고 모든 응답이 조용히 캐싱 불가로 보이게 만듭니다. 테스트하기 전에 꺼져 있는지 확인하세요.
프로덕션 고려 사항 및 자동 퍼지
단일 경로가 올바르게 작동하면 트래픽이 적은 시간대에 규칙을 전체 사이트로 확장하고 Caching → Overview에서 히트율을 확인하세요 — 건강한 정적 사이트는 90%를 여유롭게 상회합니다.
전체 존이 아니라 변경된 것만 퍼지하도록 CMS를 연결하세요. URL별 대상 퍼지는 인접 페이지를 캐시에 따뜻하게 유지합니다:
1curl -X POST \
2 "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/purge_cache" \
3 -H "Authorization: Bearer ${CF_API_TOKEN}" \
4 -H "Content-Type: application/json" \
5 --data '{"files":["https://example.com/pricing"]}'
게시 훅에서 이를 호출하여 편집자의 업데이트가 몇 초 안에 게시되는 동시에 나머지는 모두 캐싱된 상태로 유지되도록 하세요. 대규모 카탈로그의 경우 관련 URL을 Cache Tag(Enterprise) 뒤에 그룹화하거나 접두사로 퍼지하고, Tiered Cache를 활성화하여 미스가 오리진에 도달하기 전에 지역 부모를 통해 라우팅되도록 함으로써 전역 히트율을 높이세요.
검증된 UK Cloudflare 컨설팅과 협력하세요
이러한 캐싱 결정을 올바르게 내리면 오리진 서버를 보호하고 모든 방문자에 대한 페이지 전송 속도를 높일 수 있습니다. Mecanik은 전문적인 기술 SEO 감사 서비스와 웹사이트 개발 페이지를 통한 인프라 확장을 제공합니다. 저희는 Symfony 엣지 통합, 사용자 지정 Cloudflare Cache Rules, 엣지 네이티브 배포를 전문으로 합니다. 기술 스코핑 워크숍을 예약하려면 오늘 저희에게 연락하세요.
자주 묻는 질문 (FAQ)
Cloudflare CDN 캐싱이란 무엇인가요? Cloudflare CDN 캐싱은 웹사이트의 페이지, 이미지, 스크립트 파일의 정적 복사본을 전 세계에 위치한 엣지 서버에 저장하는 과정입니다. 이 구성을 통해 사용자 요청이 가장 가까운 물리적 서버에서 제공되어 웹사이트 로딩 시간을 줄입니다.
사용자 데이터를 유출하지 않고 HTML 페이지를 캐싱하려면 어떻게 하나요? HTML을 안전하게 캐싱하려면 세션 또는 관리자 쿠키가 요청 헤더에 있을 때 트리거되는 “Bypass Cache” 작업이 있는 Cache Rule을 구성하세요. 이 설정은 로그인한 포털 사용자가 항상 오리진 데이터베이스에서 동적 콘텐츠를 가져오도록 보장합니다.
Edge TTL과 Browser TTL의 차이점은 무엇인가요? Edge TTL(Time-To-Live)은 Cloudflare CDN 서버가 오리진 서버에서 새 복사본을 요청하기 전에 콘텐츠를 얼마나 오래 저장하는지를 결정합니다. 반대로 Browser TTL은 방문자의 로컬 브라우저 캐시가 파일을 얼마나 오래 유지하는지를 결정합니다.
쿼리 문자열 캐싱이 웹사이트 성능에 영향을 미치는 이유는 무엇인가요? 쿼리 문자열(예: UTM 추적 태그)이 정규화되지 않으면 CDN은 각 변형을 고유한 URL로 취급하여 오리진 서버에 중복 요청을 생성합니다. 캐시 키 정규화를 구성하면 이러한 크롤 중복이 방지됩니다.
엣지 캐싱이 제 Core Web Vitals 점수를 개선할 수 있나요? 예, HTML 및 미디어 자산을 엣지 서버에서 직접 제공하면 Time-to-First-Byte(TTFB)와 Largest Contentful Paint(LCP) 시간을 최소화합니다. 따라서 이 캐싱 전략은 모바일 페이지 속도 순위를 직접적으로 개선합니다.
댓글