CDN이란 무엇이며 Cloudflare는 어떻게 선두 제공업체가 되었나

CDN이란 무엇인가

콘텐츠 전송 네트워크(CDN)는 애플리케이션의 오리진 서버보다 사용자와 가까운 위치를 통해 콘텐츠를 제공하는 분산 서버 그룹입니다. 오리진은 권위 있는 원본으로 남고, 네트워크 엣지의 CDN 서버는 재사용 가능한 응답을 저장하며 연결을 종료하고 애플리케이션이 필요한 요청을 전달합니다.

이런 엣지 서버는 흔히 PoP라고 하는 접속 지점으로 구성됩니다. PoP에는 많은 장비가 있을 수 있으며, 지역 인터넷 제공업체, 이동통신사, 클라우드 네트워크, 기타 전송 네트워크에 직접 연결됩니다. CDN은 단순히 지리적으로 가장 가까운 PoP가 아니라 네트워크 상태에 따라 방문자를 적절한 PoP로 라우팅합니다.

CDN이 없으면 모든 요청이 오리진 또는 로드 밸런서에 도달합니다. 오리진 가까이에 있는 방문자는 빠르게 응답을 받을 수 있습니다. 다른 대륙의 사용자는 더 많은 네트워크를 거쳐야 하고, 연결 설정과 애플리케이션 왕복이 거듭될수록 지연이 늘어납니다. 서버가 아무리 빨라도 신호가 먼 거리를 이동하는 시간까지 없앨 수는 없습니다.

애플리케이션이 유용한 콘텐츠를 표시하기 전에 순차적인 교환을 세 번 해야 한다고 가정해 보겠습니다. 왕복 시간이 90밀리초라면 전송과 처리 시간 전에도 약 270밀리초가 듭니다. 연결 종단을 왕복 20밀리초인 엣지 위치로 옮기면 이 과정에서 약 210밀리초를 줄일 수 있습니다. 정확한 결과는 라우팅, 혼잡, 프로토콜 재사용, 요청한 응답의 캐시 여부에 따라 달라집니다.

CDN은 완성된 미니 웹사이트를 모아 둔 곳이 아닙니다. 특정 엣지에는 인기 이미지 한 장이 있어도 다른 엣지에는 사본이 없을 수 있습니다. 공개 문서는 한 시간 동안 캐시하면서 인증이 필요한 API 요청은 모두 전달할 수도 있습니다. 캐시는 요청 속성, 응답 헤더, 설정된 규칙, 남은 용량에 따라 채워지고 갱신됩니다.

CDN은 웹 호스팅과도 다릅니다. 호스팅은 원본 애플리케이션을 실행하고, 권위 있는 데이터를 저장하며, 응답을 생성합니다. CDN은 그 인프라 앞에 놓이는 리버스 프록시입니다. 일부 제공업체는 이제 엣지 컴퓨팅과 스토리지를 제공하므로 애플리케이션 일부를 네트워크에서 실행할 수 있지만, 그렇다고 데이터베이스나 나머지 백엔드가 자동으로 옮겨지는 것은 아닙니다.

이 차이가 CDN의 핵심 약속을 설명합니다. CDN은 피할 수 있는 거리와 오리진의 반복 작업을 줄입니다. 캐시할 수 없는 요청이 발생할 때 비효율적인 애플리케이션 프로그램을 빠르게 만들거나, 느린 데이터베이스 쿼리를 고치거나, 과부하된 오리진을 대신할 수는 없습니다.

CDN이 각 요청을 처리하는 방식

CDN은 엣지 위치에서 사용자 연결을 받고, 그곳에서 유효한 응답을 만들 수 있는지 확인한 뒤 필요할 때만 오리진에 연락합니다. 캐시 결정 전에 DNS와 Anycast 라우팅이 보통 트래픽을 제공업체 네트워크로 보냅니다.

일반적인 요청은 다섯 단계를 따릅니다.

1. DNS는 오리진을 직접 노출하는 대신 CDN과 연결된 주소를 반환합니다.
2. 네트워크는 연결을 사용 가능한 엣지 위치로 보내고, CDN은 그곳에서 TLS와 HTTP 프로토콜을 협상합니다.
3. 엣지는 스킴, 호스트, 요청 대상, 쿼리 매개변수, 선택한 헤더 등의 속성으로 캐시 키를 계산합니다.
4. 최신 상태의 일치 항목이 있으면 캐시 적중입니다. 누락, 우회 또는 만료된 항목이면 엣지가 상위 캐시 계층이나 오리진에 연락합니다.
5. CDN은 사용자에게 응답을 보내고, 이후 요청을 위해 적합한 사본을 저장할 수 있습니다.

Anycast를 사용하면 여러 시설이 같은 주소 범위를 알릴 수 있습니다. 인터넷 라우팅은 연결을 도달 가능한 공고 쪽으로 보냅니다. 보통 사용자를 가까운 시설로 데려오지만, 라우팅 정책과 피어링 때문에 지리적으로 가장 가까운 시설보다 다른 시설의 성능이 나을 수 있습니다.

캐시의 최신 상태는 주로 HTTP 응답 헤더와 CDN 규칙으로 정해집니다. 오리진은 다음과 같이 반환할 수 있습니다.

Cache-Control: public, max-age=300, s-maxage=3600, stale-while-revalidate=60
ETag: "build-4821"

이 예에서 브라우저는 응답을 5분 동안 재사용할 수 있고, 공유 캐시는 한 시간 동안 최신으로 볼 수 있습니다. 지정된 재검증 기간에는 호환되는 캐시가 업데이트된 버전을 확인하는 동안 오래된 사본을 반환할 수 있습니다. ETag는 조건부 검증을 가능하게 하므로 콘텐츠가 바뀌지 않았을 때 전체 응답 전송을 피할 수 있습니다.

TTL만으로 결정되지는 않습니다. private 또는 no-store로 표시한 응답은 공유 캐시에 들어가면 안 됩니다. 인증 정보를 담은 요청과 세션 쿠키를 설정하는 응답도 신중히 다뤄야 합니다. 개인화된 HTML을 공유 식별자로 캐시하면 한 사용자의 콘텐츠가 다른 사용자에게 노출될 수 있습니다.

캐시 키는 어떤 요청이 같은 저장 응답을 재사용할 수 있는지 제어합니다. 모든 추적 매개변수를 포함하면 같은 콘텐츠 사본이 많이 생겨 적중률이 낮아집니다. 응답을 바꾸는 매개변수를 무시하면 잘못된 콘텐츠를 보낼 수 있습니다. 언어, 기기 유형, 테넌트 식별자, 선택한 쿠키, 압축 지원은 서버가 보내는 내용이 달라질 때만 식별자에 포함해야 합니다.

퍼지는 정상 만료 전에 저장된 사본을 제거합니다. 긴급 수정에는 유용하지만, 전 세계 캐시를 자주 비우면 데워진 캐시 항목을 버리고 오리진 부하를 높입니다. 배포에는 버전이 붙은 리소스 이름이 더 안전합니다. 새 HTML은 새 리소스 이름을 참조하고, 이전의 변경 불가 파일은 더 이상 요청되지 않을 때까지 캐시에 남겨둘 수 있습니다.

캐시 누락은 실패가 아닙니다. 새 콘텐츠, 만료된 콘텐츠, 드문 콘텐츠, 의도적으로 캐시하지 않는 콘텐츠에서는 정상입니다. 좋은 CDN 설정은 모든 요청을 저장하는 것이 아니라 안전하고 가치 있는 응답을 캐시하는 데 목적을 둡니다.

CDN이 개선하는 것과 해결하지 못하는 것

CDN은 설정이 애플리케이션에 맞을 때 전송 시간, 오리진 효율, 복원력, 경계 보안을 개선합니다. 개선 폭은 사용자 위치, 콘텐츠 재사용, 캐시 정책, 백엔드까지 도달하는 작업량에 따라 달라집니다.

가장 분명한 개선은 연결 지연 시간 감소입니다. 방문자 가까이에서 TLS 협상이 이뤄지고, 재사용 가능한 콘텐츠는 오리진 왕복을 피하며, 지속 연결은 반복 설정 작업을 줄입니다. 최신 프로토콜은 손실이 있거나 연결 상태가 바뀌는 모바일 네트워크에서도 더 잘 작동할 수 있습니다. 이런 이점은 첫 바이트까지의 시간과 페이지 경험 지표를 개선하지만, 렌더링을 막는 스크립트, 과도하게 큰 클라이언트 번들, 레이아웃 이동, 느린 브라우저 실행을 없애지는 못합니다.

오리진 부하 경감은 인프라와 데이터 전송 비용을 낮출 수 있습니다. 한 서비스가 매월 캐시 가능한 파일 8TB를 오리진에서 전송한다고 가정해 보겠습니다. CDN이 그 바이트의 92%를 엣지 스토리지에서 제공하면, 재검증 트래픽과 운영 오버헤드 전의 일반적인 누락분은 오리진 전송 약 640GB입니다. 실제 비용은 호스팅 제공업체의 송신 요금, CDN 플랜, 요청 요금, 변환 수수료, 유료 라우팅 기능에 따라 달라집니다.

분산 네트워크는 반복되는 파일 요청을 한 서버로 모두 보내지 않고도 갑작스러운 트래픽 증가를 흡수할 수 있습니다. 상태가 좋지 않은 엣지 시설에서 사용자를 다른 곳으로 보낼 수도 있습니다. 설정했다면 오리진 장애 조치는 적합한 트래픽을 백업 백엔드로 보냅니다. 데이터베이스가 장애를 일으키거나, 두 오리진이 같은 의존성을 공유하거나, 모든 요청에 실시간 애플리케이션 작업이 필요하면 가용성이 보장되지는 않습니다.

리버스 프록시는 보안 경계를 만듭니다. 대용량 공격 트래픽을 버리고, 방화벽과 속도 제한 규칙을 적용하며, 일반 DNS 응답에서 오리진 주소를 숨길 수 있습니다. 오래된 DNS 레코드, 이메일 헤더, 직접 호스트 이름, 타사 서비스가 오리진을 드러내고 오리진 방화벽이 임의의 인터넷 트래픽을 계속 허용한다면 그 경계는 무력해집니다.

애플리케이션 보안은 계속 소유자의 책임입니다. CDN만으로 잘못된 권한 부여, 안전하지 않은 데이터 접근, 노출된 비밀 정보, 취약한 의존성, 비즈니스 로직 악용을 고칠 수는 없습니다. 관리형 방화벽 규칙은 일반적인 공격 트래픽을 줄이지만, 오탐과 애플리케이션별 위협 누락을 피하려면 모니터링과 조정이 필요합니다.

혜택이 적은 워크로드도 있습니다. 오리진과 같은 시설에서 사용하는 비공개 애플리케이션은 이미 네트워크 지연 시간이 낮습니다. 요청마다 고유한 응답은 공유 캐싱의 이점이 작습니다. 대용량 업로드는 여전히 오리진 용량을 소모하고, 엣지 프록시는 타임아웃, 본문 크기, 헤더 제한을 이해해야 하는 지점을 하나 더 늘릴 수 있습니다.

실질적인 기준은 CDN이 수수료와 운영 복잡성보다 더 많은 지연, 전송, 위험을 줄이는지입니다. 모든 분산 네트워크가 모든 애플리케이션을 개선한다고 가정하지 말고 실제 트래픽으로 결과를 측정하세요.

현대 애플리케이션에서 CDN의 역할

CDN은 많은 사용자가 재사용 가능한 콘텐츠를 요청하거나 가까운 연결 종단의 혜택을 받는 곳에 적합합니다. 정적 웹사이트가 가장 단순한 사례이지만, 소프트웨어 다운로드, API, 미디어 전송, SaaS 애플리케이션, 모바일 클라이언트, 연결 기기도 각기 다른 방식으로 엣지 네트워크를 사용합니다.

일반적인 배포 패턴은 다음과 같습니다.

• 정적 사이트 리소스: 이미지, 글꼴, 스타일시트, 스크립트, 문서 등 공개 파일을 긴 최신 상태 기간과 버전이 붙은 이름으로 캐시합니다.
• 웹 애플리케이션 셸: 초기 HTML과 프런트엔드 번들을 엣지에서 제공하고, 계정 데이터는 인증된 서비스에서 가져옵니다.
• API: 클라이언트 가까이에서 TLS를 종료하고 업스트림 연결을 재사용하며, 악성 호출자의 속도를 제한하고, 명시적으로 공개되었거나 안전하게 분리된 응답만 캐시합니다.
• 동영상과 대용량 파일: 인기 세그먼트나 다운로드를 시청자 가까이에 저장해 출시나 라이브 이벤트가 소스를 포화시키지 않게 합니다.
• 모바일 및 기기 배포: 서명된 애플리케이션 패키지, 펌웨어, 지도, 미디어를 업데이트 검증을 유지하며 효율적으로 전송합니다.

동적 트래픽은 정적 파일보다 더 신중히 다뤄야 합니다. GET과 HEAD 응답은 공개 데이터를 담고 명확한 최신 상태 규칙을 정의했다면 캐시할 수 있습니다. 상태를 변경하는 요청은 보통 애플리케이션에 도달해야 합니다. 인증된 응답은 설계상 항목을 분리하고 식별자가 충돌할 수 없음을 증명하지 않는 한 공유 스토리지를 우회해야 합니다.

GraphQL과 유사한 API 방식은 하나의 엔드포인트가 매우 다양한 응답을 만들기 때문에 일괄 캐싱이 어렵습니다. 영속 작업, 정규화된 요청 본문, 애플리케이션이 생성한 대리 식별자, 목적에 맞는 API 캐시가 도움이 될 수 있지만, 권한 부여와 무효화 동작을 명확히 한 뒤에만 적용해야 합니다.

스트리밍은 하나의 거대한 동영상 전송보다 작은 미디어 세그먼트와 적응형 비트레이트 변형에 의존합니다. 이벤트 중 인기 세그먼트는 재사용률이 높습니다. 드문 녹화본은 소스에서 반복해 가져오지 않도록 상위 캐시 계층이나 영구 CDN 스토리지가 필요할 수 있습니다. 권한 관리, 서명된 액세스, 지역 제한, 플레이어 동작은 별도의 설계 과제입니다.

다중 리전 SaaS 제품은 애플리케이션 셸과 공개 리소스에 CDN을 쓰고, 트래픽 관리자가 실시간 데이터용 애플리케이션 리전을 선택하는 경우가 많습니다. 엣지는 연결 비용을 줄일 수 있지만, 한 리전의 사용자가 다른 곳에 있는 데이터를 조회해야 할 때 데이터베이스 거리를 없앨 수는 없습니다. 데이터 배치와 일관성이 여전히 대화형 지연 시간의 큰 부분을 결정합니다.

Koder.ai 프로젝트에서는 공개 React 번들, 글꼴, 미디어를 캐시하고 Go 서비스가 계속 요청을 인증하며 PostgreSQL은 애플리케이션 계층 뒤에 두는 구성이 실용적입니다. 릴리스 서명과 업데이트 제어를 유지한다면 Flutter 애플리케이션 패키지에도 CDN 전송을 쓸 수 있습니다. Koder.ai 맞춤 도메인 앞에 Cloudflare를 배치한다면 호스팅 설정에서 필요한 DNS 구성을 확인하고, 프로덕션 트래픽을 옮기기 전에 테스트하세요. 소스 코드 내보내기를 이용하면 팀이 직접 관리하는 인프라에 배포한 뒤에도 같은 패턴을 적용할 수 있습니다.

캐싱은 애플리케이션 개발자가 응답의 의미를 정의할 때 가장 효과적입니다. CDN 운영자가 응답이 공개인지, 언제까지 유효한지, 어떤 요청 속성이 응답을 바꾸는지 추측해서는 안 됩니다.

CDN 제공업체 평가 방법

CDN 제공업체는 애플리케이션의 위치, 트래픽 유형, 안정성 목표, 보안 요구 사항, 운영 모델에 맞춰 평가해야 합니다. 지역, 통신사, 프로토콜, 캐시 상태, 기능 설정에 따라 제공업체가 다르므로 단일 벤치마크만으로 보편적인 선두 업체를 정할 수는 없습니다.

유용한 비교는 다섯 가지 차원을 다룹니다.

• 범위와 상호 연결: 실제 사용자 근처의 시설, 사용자 네트워크와의 피어링, 오리진 연결성, 필요한 국가 지원을 살펴봅니다.
• 성능: 여러 백분위에서 첫 바이트까지의 시간, 다운로드 시간, 캐시 동작, 연결 오류, 페이지 경험을 측정합니다.
• 안정성: 서비스 약정, 장애 이력, 트래픽 조정, 오리진 장애 조치, 제어 플레인 동작, 지원 응답을 검토합니다.
• 보안과 규정 준수: DDoS 적용 범위, 방화벽 제어, 봇 및 속도 제한 도구, 로깅, 인증서 관리, 데이터 위치, 감사 요구 사항을 비교합니다.
• 운영과 비용: 설정, 자동화, 관측성, 지원, 마이그레이션 작업, 부가 기능, 요청 요금, 오리진 송신 비용을 고려합니다.

시설 수만으로는 성능을 판단하기 어렵습니다. 한 제공업체가 도시에 시설을 운영해도 고객이 쓰는 통신사와 피어링이 좋지 않을 수 있습니다. 다른 제공업체는 시설 수가 적어도 중요한 네트워크로 가는 경로가 더 나을 수 있습니다. 혼잡이나 유지보수 중에는 요청을 처리하는 위치도 바뀔 수 있습니다.

합성 테스트와 실제 사용자 모니터링을 함께 사용하세요. Catchpoint, ThousandEyes, WebPageTest 같은 합성 시스템은 통제된 위치에서 반복 가능한 테스트를 제공합니다. 브라우저 측정은 실제 방문자가 겪는 기기, 통신사, 무선 상태, 페이지 동작을 보여 줍니다. SpeedCurve와 자체 브라우저 텔레메트리로 이런 정보를 수집할 수 있습니다. W3Techs나 BuiltWith의 도입 보고서는 제공업체 사용 빈도를 보여 주지만 속도 테스트는 아닙니다.

평가는 통제된 시험으로 진행하세요.

1. 리전, 기기 종류, 콘텐츠 유형, 트래픽 기간별로 오리진 단독 기준선을 기록합니다.
2. 후보마다 비교 가능한 캐시, TLS, 압축, 보안 정책을 구성합니다.
3. 콜드 누락, 웜 적중, 재검증, 동적 응답, 대형 객체, 업로드를 별도로 테스트합니다.
4. 프로덕션 데이터를 위험에 빠뜨리지 않고 비정상 오리진과 급격한 트래픽 증가를 시뮬레이션합니다.
5. 측정된 개선 효과를 각 옵션의 전체 월 청구액 및 운영에 필요한 엔지니어링 시간과 비교합니다.

중앙값 지연 시간은 가장 나쁜 경험을 하는 사용자를 숨깁니다. 표본 수가 충분하다면 p50, p75, p95, p99를 추적하세요. 느린 백엔드를 CDN 탓으로 돌리지 않도록 엣지 시간과 오리진 시간을 분리합니다. 첫 방문과 재방문을 비교하고, 캐시 가능한 바이트와 요청 수를 구분하세요.

캐시 적중률도 두 관점이 필요합니다. 요청 적중률은 오리진 없이 엣지가 응답하는 빈도를 보여 줍니다. 바이트 적중률은 엣지가 흡수하는 전송량을 보여 줍니다. 대용량 동영상 몇 개가 높은 바이트 비율을 만들 수 있지만, 작은 API 요청 수천 건은 계속 백엔드에 도달할 수 있습니다.

안정성 측정에는 엣지 오류, 오리진 오류, DNS 실패, TLS 실패, 타임아웃, 성공적인 장애 조치를 포함해야 합니다. 장애 중 대시보드를 쓸 수 없거나 설정 변경 전파에 너무 오래 걸린다면 명목상의 가동 시간 비율은 큰 의미가 없습니다.

보안 비교에는 워크로드별 테스트가 필요합니다. 정상 클라이언트가 속도 제한을 통과하는지, 관리형 규칙이 실제 구매나 API 호출을 막지 않는지, 로그가 조사에 충분한 증거를 제공하는지, 오리진 직접 접근이 막혔는지 확인하세요. 규정 준수 인증은 계약한 서비스와 설정된 데이터 흐름이 그 범위에 들어갈 때만 의미가 있습니다.

이 과정은 «선두»라는 말에 실용적인 의미를 부여합니다. 특정 애플리케이션에 가장 적합한 선두 제공업체는 측정된 목표를 감당할 수 있는 비용과 운영 위험으로 충족하는 업체입니다.

Cloudflare가 선두 제공업체로 평가받는 이유

Cloudflare는 광범위한 네트워크 범위, 높은 도입률, 접근하기 쉬운 시작 플랜, 보안 서비스, 프로그래밍 가능한 애플리케이션 전송을 하나의 네트워크에서 결합하기 때문에 선두 CDN 제공업체로 평가받습니다. 모든 워크로드에서 입증 가능한 1위이기보다는 이 조합이 입지를 만듭니다.

Cloudflare는 2010년에 원치 않는 트래픽을 걸러 내고 웹사이트 전송을 개선하는 서비스로 시작했습니다. 캐싱과 DDoS 방어가 같은 리버스 프록시 구조를 공유했기에, 고객은 오리진에 장비를 설치하지 않고 성능과 보호 기능을 얻을 수 있었습니다. 이후 회사는 이 네트워크를 DNS, 애플리케이션 보안, 비공개 액세스, 개발자 컴퓨팅, 스토리지, 미디어 서비스로 확장했습니다.

이 네트워크는 125개국 이상, 330개 이상의 도시에 이르며 13,000개 이상의 다른 네트워크와 상호 연결됩니다. 이런 폭넓은 연결성 덕분에 Cloudflare는 액세스 제공업체 가까이에서 트래픽을 교환할 기회가 많습니다. Anycast를 쓰면 팀이 리전별로 별도의 공개 엔드포인트를 만들지 않아도 같은 고객용 서비스 주소를 여러 시설에서 운영할 수 있습니다.

접근성도 도입에 기여했습니다. 작은 사이트는 무료 플랜으로 시작할 수 있고, 큰 조직은 유료 제어 기능, 지원, 계약상 약정, 특화 네트워크 서비스를 구매할 수 있습니다. 대시보드와 API는 DNS, 프록싱, 인증서, 캐싱, 트래픽 규칙, 보안 정책을 하나의 운영 모델로 제공합니다.

공유 네트워크에서는 요청이 하나의 엣지에서 여러 기능을 거칠 수 있습니다. Cloudflare는 TLS를 종료하고, 보안 정책을 평가하며, 캐시를 확인하고, 각 단계마다 무관한 공급업체 네트워크를 거치지 않고 애플리케이션 로직을 호출할 수 있습니다. 통합은 연동 작업을 줄일 수 있지만, 한 제공업체의 설정과 가용성에 대한 의존도도 높입니다.

측정 기준을 정의하지 않고 Cloudflare를 세계 1위 CDN이라고 부르면 근거를 과장하게 됩니다. Akamai는 일부 대규모 미디어 및 엔터프라이즈 전송 프로그램에서 더 선호될 수 있습니다. AWS와 깊이 연결된 애플리케이션에는 CloudFront가 자연스러운 선택일 수 있습니다. Fastly는 경험 많은 팀에 세밀한 전송 제어를 제공합니다. 지역 제공업체는 집중된 현지 사용자층에서 글로벌 업체보다 나은 성능을 낼 수 있습니다.

Cloudflare는 다양한 평가 범주에서 경쟁력이 있고 규모가 매우 다른 조직도 사용할 수 있으므로 선두 그룹에 속합니다. 최종 결정에는 여전히 워크로드 테스트, 계약 검토, 제공업체 장애에 대비한 명확한 계획이 필요합니다.

현재 Cloudflare 캐싱 방식

Cloudflare 캐싱은 프록시된 DNS 레코드의 적격 정적 리소스에 자동으로 적용되지만, HTML, JSON, 개인화된 애플리케이션 응답에는 명시적인 정책이 필요합니다. 새 설정에는 Cache Rules를 사용하고, 오리진 헤더를 애플리케이션 계약의 일부로 다뤄야 합니다.

프록시로 표시한 DNS 레코드는 호환되는 웹 트래픽을 Cloudflare로 보냅니다. DNS 전용 레코드는 설정된 오리진으로 해석되며, 해당 레코드에서는 CDN 캐싱, HTTP DDoS 필터링, 엣지 방화벽 처리를 받지 않습니다. 일부 호스트 이름만 프록시 상태로 표시될 때 이 차이를 놓치기 쉽습니다.

Cloudflare의 기본 캐시 동작은 메서드, 파일 확장자, 상태 코드, 쿼리 문자열, 응답 헤더, 쿠키, 인증 등의 요소를 고려합니다. 정적 파일 형식은 보통 적격입니다. HTML과 JSON은 기본적으로 캐시하지 않습니다. 제한적인 캐시 지시문, Set-Cookie 헤더, 특정 인증 요청이 있는 응답은 흔히 저장을 우회합니다.

Cache Rules는 적격성, 엣지 최신 상태, 브라우저 최신 상태, 캐시 식별자, 쿼리 처리, 응답 상태별 동작을 바꿀 수 있습니다. 최신 규칙은 중첩 가능하므로 하나의 요청에 여러 규칙이 일치할 수 있고, 나중에 충돌하는 설정이 적용될 수 있습니다. 이는 이전 Page Rules와 다릅니다. 기존 Page Rules는 신중하게 마이그레이션해야 하지만, 새 설계에서는 캐싱, 리디렉션, 오리진 선택, 설정에 전용 규칙 제품을 사용해야 합니다.

Tiered Cache는 오리진에 연락하는 엣지 시설 수를 줄입니다. 하위 계층에서 누락되면 소스에 객체를 요청하기 전에 상위 계층을 확인합니다. Cloudflare는 표준 플랜에 Tiered Cache와 스마트 토폴로지를 포함하며, 글로벌, 지역, 맞춤형 토폴로지는 이용 가능 범위가 더 제한됩니다. 선택한 상위 계층에 누락을 모으면 재사용률을 높이고 동시에 열리는 오리진 연결을 줄일 수 있습니다.

Cache Reserve는 일반 캐시 계층 위에 영구 스토리지를 추가합니다. 긴 최신 상태 기간을 가진 캐시 가능 객체를 위한 유료 사용량 기반 옵션입니다. 저장된 객체도 캐시 정책에 따라 오래된 상태가 되며 오리진 재검증이 필요할 수 있습니다. 보존과 최신 상태는 다릅니다. 보존은 저장된 사본이 계속 남는지 결정하고, 최신 상태는 Cloudflare가 소스를 확인하지 않고 보낼 수 있는지 결정합니다.

Argo Smart Routing은 오리진을 향해 Cloudflare 네트워크를 지나야 하는 트래픽에 더 나은 경로를 고르기 위해 네트워크 관측 정보를 쓰는 별도 유료 기능입니다. 동적 요청과 누락에 도움이 될 수 있지만, 느린 애플리케이션 처리를 고치는 대체 수단은 아닙니다.

엣지 인증서가 활성화되면 표준 플랜에서 방문자의 Cloudflare 연결에 HTTP/3를 사용할 수 있습니다. 이 설정이 Cloudflare에서 오리진으로 가는 HTTP/3 연결을 만드는 것은 아닙니다. 토글을 켰다는 사실만으로 개선을 단정하지 말고 모바일 네트워크에서 프로토콜 결과를 테스트해야 합니다.

TLS 연결은 두 개입니다. 방문자에서 Cloudflare로 가는 연결과 Cloudflare에서 오리진으로 가는 연결입니다. Full strict 모드는 오리진이 요청한 호스트 이름과 일치하고 유효 기간이 지나지 않은 유효한 인증서를 제시하는지 검증합니다. Flexible 암호화는 엣지와 오리진 사이를 암호화하지 않으므로, 오리진에서 HTTPS를 지원할 수 있는 프로덕션 애플리케이션에 쓰면 안 됩니다.

안전한 캐시 정책은 다섯 가지 원칙을 따릅니다.

• 공개적이고 재사용 가능한 응답을 캐시하고, 계정별 콘텐츠는 기본적으로 우회합니다.
• 버전이 붙은 리소스에는 긴 최신 상태 기간을 주고, 문서에는 게시 요구에 맞는 더 짧은 기간을 줍니다.
• 응답을 바꾸지 않음을 확인한 뒤에만 관련 없는 추적 매개변수를 제거합니다.
• 캐시 키를 바꾸기 전에 쿠키, 인증, 언어, 기기, 테넌트 동작을 테스트합니다.
• 수정 시에는 범위를 좁혀 퍼지하고, 그에 따른 오리진 부하를 모니터링합니다.

높은 적중률만이 목표는 아닙니다. 정확성, 개인정보 보호, 최신성, 예측 가능한 무효화가 먼저입니다.

Cloudflare가 캐싱 외에 제공하는 기능

Cloudflare는 CDN에 애플리케이션 보안, 오리진 보호, 엣지 컴퓨팅, 미디어 처리, 비공개 액세스 서비스를 더합니다. 이 제품들은 인프라와 관리를 공유하지만 제한, 과금 방식, 플랜별 이용 가능 여부는 서로 다릅니다.

주요 서비스 그룹은 다음과 같습니다.

• 애플리케이션 보안: DDoS 완화, 관리형 및 맞춤 방화벽 규칙, 속도 제한, 봇 제어, API 보호, 인증서 서비스
• 오리진 보호: 프록시 주소 지정, 네트워크 허용 목록, 인증된 오리진 풀, 상태 점검, 로드 밸런싱, 아웃바운드 Cloudflare Tunnel 연결
• 개발자 플랫폼: Workers 컴퓨팅과 KV, D1, Durable Objects, R2, Queues 등의 스토리지 및 메시징 제품
• 미디어 서비스: 이미지 스토리지와 변환, 자동 형식 선택, 동영상 수집, 인코딩, 스토리지, 적응형 전송
• 비공개 연결: Zero Trust 액세스, 보안 웹 게이트웨이 기능, 직원, 사무실, 인프라용 네트워크 서비스

DDoS 보호는 표준 CDN 플랜 전반에 제공되지만, 방화벽 규칙 용량, 관리형 보호, 봇 기능, 분석 데이터 보존, 지원 수준은 다릅니다. 속도 제한은 애플리케이션 시작, 결제, 웹훅 전송, 모바일 클라이언트 재시도처럼 정상적인 급증과 악성 자동화를 구분해야 합니다.

레코드를 프록시하면 일반 방문자에게서 오리진 주소를 숨기지만, 이미 다른 곳에 공개된 정보를 지우지는 못합니다. 트래픽을 검증한 뒤에는 승인된 소스만 허용하도록 오리진 방화벽을 제한하세요. 인증된 오리진 풀은 요청이 Cloudflare를 거쳤다는 인증서 기반 검증을 추가합니다. Cloudflare Tunnel은 서비스의 운영 모델이 맞는다면 아웃바운드 연결을 만들어 공개 라우팅 가능한 오리진 주소의 필요성을 없앨 수 있습니다.

Workers는 경량 V8 isolate를 사용해 Cloudflare 네트워크 전반에서 요청 처리 프로그램을 실행합니다. 리디렉션, 인증 확인, 실험, 개인화, API 구성, 완전한 애플리케이션 기능을 처리할 수 있습니다. 변경 가능한 메모리가 요청 사이에 유지되거나 두 요청이 같은 isolate에 도달한다고 가정해서는 안 됩니다. 상태 조정은 적절한 스토리지 서비스에 맡겨야 합니다.

Cloudflare Images는 엣지에서 원격 이미지를 변환하거나 유료 플랜에서 원본 이미지를 저장할 수 있습니다. 무료 Images 계층에는 매월 고유 변환 허용량이 포함되며, 더 많은 변환과 호스팅 이미지 전송은 별도 기준으로 과금됩니다. 서로 다른 원본과 변환 조합마다 사용량에 영향을 주므로, 제어되지 않은 크기나 품질 값은 불필요한 변형을 만들 수 있습니다.

Cloudflare Stream은 라이브 및 주문형 동영상 수집, 스토리지, 인코딩, 적응형 전송을 처리합니다. CDN을 켠다고 무료로 따라오는 기능이 아니라 별도 서비스입니다. 기존 동영상 워크플로를 대체하기 전에는 액세스 제어, 재생 시간, 저장 기간, 소스 권리, 지원 인코딩 출력을 검토해야 합니다.

Zero Trust 제품은 공개 콘텐츠 전송과 다른 문제를 해결합니다. 사용자와 기기가 비공개 애플리케이션 또는 인터넷에 접근하는 방식을 제어합니다. 서비스가 같은 네트워크에서 실행되더라도 CDN을 구매했다고 모든 비공개 액세스 기능이 포함되는 것은 아닙니다.

통합 분석은 엣지 트래픽, 캐시 결과, 보안 이벤트, Worker 실행을 연결해 볼 수 있습니다. 보존 기간과 세부 수준은 플랜과 제품에 따라 다릅니다. 장애 조사나 감사 정책에 더 긴 기록이 필요하다면 중요한 로그를 조직의 모니터링 시스템으로 내보내세요.

Cloudflare와 다른 CDN 제공업체 비교

Cloudflare는 하나의 네트워크로 이용하기 쉬운 도입 절차와 폭넓은 서비스를 제공한다는 점에서 눈에 띄지만, 특정 클라우드, 전송 방식, 미디어 워크플로, 엔터프라이즈 운영 모델에는 다른 제공업체가 더 잘 맞을 수 있습니다. 비교는 제공업체의 글로벌 평균보다 애플리케이션에 집중해야 합니다.

Cloudflare의 전체 영역 설정은 보통 권한 네임서버를 변경하므로, 한 제공업체가 DNS와 프록싱을 관리할 때 편리합니다. 다른 권한 DNS 서비스를 반드시 유지해야 하는 조직은 부분 설정의 이용 가능 여부와 플랜 요구 사항을 검토해야 합니다. 이 차이는 성능 테스트가 시작되기 전에 마이그레이션 설계를 결정할 수 있습니다.

콘텐츠가 이미 AWS 스토리지에 있고 애플리케이션 권한이 AWS ID를 쓴다면 CloudFront가 통합 작업을 줄일 수 있습니다. 요청 가까이에서 세밀한 전송 로직을 표현하려는 팀에는 Fastly가 적합할 수 있습니다. Akamai는 까다로운 엔터프라이즈와 미디어 프로그램에서 오랜 경험을 갖고 있습니다. 특정 국가에 집중한 서비스에는 지역 CDN이 더 나은 현지 지원, 결제 조건, 통신사 관계를 제공할 수 있습니다.

두 CDN을 쓰면 하나의 엣지 네트워크에 대한 의존도를 낮출 수 있지만, 설정 불일치, 일관되지 않은 캐시 무효화, 인증서 조정, 중복 보안 규칙, 분리된 로그, 더 어려운 장애 진단이 생깁니다. 다중 CDN 아키텍처는 가용성 또는 지역 성능 요구 사항이 그 운영 비용을 넘을 때 정당화됩니다. 관련 없는 공개 테스트에서 두 업체가 더 빨라 보인다는 이유만으로 추가하면 안 됩니다.

따라서 Cloudflare는 강력한 기본 후보이지 자동 승자는 아닙니다. 가장 관련 있는 대안과 짧은 평가를 하면 기능 수 비교보다 더 나은 결정을 내릴 수 있습니다.

Cloudflare 가격과 총비용

Cloudflare 가격은 고정형 표준 플랜으로 시작하고, 워크로드에 따라 사용량 기반 제품과 맞춤 계약을 추가합니다. 공개된 Network 및 CDN 계층 가격은 다음과 같습니다.

• Free는 월 $0이며, 비즈니스 핵심 서비스가 아닌 개인 또는 취미 프로젝트가 대상입니다.
• Pro는 연간 결제 시 월 $20, 월간 결제 시 $25입니다.
• Business는 연간 결제 시 월 $200, 월간 결제 시 $250입니다.
• Enterprise 서비스는 미션 크리티컬 애플리케이션용 맞춤형 연간 계약을 사용합니다.

기본 계층에는 CDN 전송, 권한 DNS, Universal SSL, DDoS 보호가 포함되지만, 모든 Cloudflare 제품이 무료가 되는 것은 아닙니다. Argo 라우팅, 로드 밸런싱, 고급 인증서 옵션, Workers 사용량, 이미지 처리, 동영상 전송, 영구 캐시 스토리지, 로그 액세스, 특화 보안 기능에는 별도 요금이나 계약 조건이 적용될 수 있습니다.

실제 트래픽 범주로 총비용을 추정하세요. 캐시 가능한 바이트, 동적 요청, 이미지 변형, 동영상 분, 컴퓨팅 호출, 로그 볼륨, DNS 쿼리, 소스 전송을 분리합니다. এরপর 낮은 트래픽, 일반 트래픽, 피크 트래픽 달을 모델링합니다. 설정, 모니터링, 장애 대응, 정책 유지에 드는 인력 시간도 포함하세요.

같은 계산에서 오리진 절감 효과도 중요합니다. 유료 CDN 기능이 더 큰 클라우드 송신 비용을 줄이거나 더 작은 소스 서버군을 가능하게 할 수 있습니다. 반대로 현지의 적은 트래픽을 가진 사이트는 무료 계층이 보안과 연결 처리를 개선하더라도 금전적 이점이 작을 수 있습니다.

가격은 아키텍처에도 영향을 줍니다. 팀은 인기 파일에는 일반 엣지 캐싱을, 비용이 큰 소스 객체 중 일부에는 영구 스토리지를, 드문 콘텐츠에는 직접 오리진 전송을 선택할 수 있습니다. 모든 옵션을 모든 트래픽에 적용하는 것보다 이 방식이 더 저렴한 경우가 많습니다.

Cloudflare를 결정하고 안전하게 도입하는 방법

분산된 사용자에게 공개 웹사이트, 애플리케이션, API를 제공하고 글로벌 프록시 네트워크를 직접 구축하지 않으면서 엣지 전송, 트래픽 보호, 인증서 관리를 원하는 팀이라면 Cloudflare가 잘 맞습니다. 도입은 많은 토글을 켜는 방식이 아니라 측정 가능한 목표와 되돌릴 수 있는 파일럿으로 시작해야 합니다.

프록시 장비를 완전히 직접 소유해야 하거나, 기존 공급업체 계약이 이미 요구를 충족하거나, 애플리케이션이 지원하지 않는 프로토콜을 쓰거나, 데이터 처리가 엄격히 제한된 관할권 안에 머물러야 한다면 적합성이 떨어질 수 있습니다. Cloudflare는 지역 및 엔터프라이즈 제어 기능을 제공하지만, 계약한 구성은 조직의 법적, 기술적 요구 사항에 맞는지 확인해야 합니다.

안전한 배포는 다섯 단계를 따를 수 있습니다.

1. 기준 지연 시간, 페이지 지표, 오류율, 오리진 부하, 전송량, 현재 DNS 값을 기록합니다.
2. 도메인을 추가하고 가져온 DNS 레코드를 모두 확인하며, DNS 전용으로 남아야 하는 메일 또는 검증 레코드를 식별합니다.
3. 위험이 낮은 호스트 이름이나 제한된 트래픽 비율로 파일럿을 진행한 뒤 인증서, 리디렉션, 요청 본문, 업로드, 애플리케이션 콜백을 확인합니다.
4. Full strict 암호화를 활성화하고 오리진 직접 접근을 제한하며, 가능하면 보안 정책을 모니터링 모드로 도입합니다.
5. 범위를 좁힌 Cache Rules를 추가하고 누락과 우회를 관찰한 뒤 인증 및 개인화 동작이 테스트를 통과할 때만 확장합니다.

네임서버 변경은 리졸버에 전파되는 데 시간이 걸릴 수 있습니다. 마이그레이션 전에 관련 DNS 최신 상태 기간을 낮추면 전환 시간을 줄일 수 있지만, 기존 캐시 응답이 만료될 만큼 일찍 해야 합니다. 새 서비스가 대표적인 트래픽 기간 동안 안정적으로 유지될 때까지 이전 제공업체 설정을 보존하세요.

트래픽이 Cloudflare에 도달한 뒤에는 CF-Cache-Status 응답 헤더를 확인하세요. HIT는 Cloudflare가 캐시된 응답을 반환했다는 뜻입니다. MISS는 사용할 수 있는 사본이 없어 업스트림에서 가져왔다는 뜻입니다. DYNAMIC은 요청 시점에 캐시 적격으로 보지 않았음을 나타냅니다. BYPASS는 보통 저장을 막는 규칙 또는 오리진 응답을 뜻합니다. 백그라운드 재검증 중 오래된 콘텐츠가 반환될 때는 UPDATING이 나타날 수 있습니다. Age 헤더는 최근 검증 또는 재충전 이후 제공된 캐시 항목이 저장된 시간을 보여 줍니다.

광범위한 도입 전에 다음 다섯 결과를 검증하세요.

• 로그인한 사용자가 다른 사용자의 콘텐츠를 받지 않고, 로그아웃이나 권한 변경이 올바르게 적용됩니다.
• 퍼지와 버전이 붙은 배포가 필요한 최신 상태 기간 안에 변경된 리소스를 교체합니다.
• 오리진은 의도한 Cloudflare 트래픽을 허용하면서 승인되지 않은 직접 연결은 거부합니다.
• 방화벽과 속도 정책이 실제 브라우저, API, 웹훅, 검색 크롤러, 접근성 도구를 허용합니다.
• 모니터링이 엣지 장애, 소스 장애, 애플리케이션 오류, 차단된 보안 이벤트를 구분합니다.

파일럿을 같은 백분위와 비슷한 트래픽 기간의 기준선과 비교하세요. 첫 바이트까지의 시간, 최대 콘텐츠 렌더링 시간, 오류율, 소스 CPU, 열린 연결, 전송 바이트의 변화를 살펴봅니다. 중앙값은 빨라졌지만 p95 지연 시간이 나빠졌다면 축하할 일이 아니라 조사할 일입니다.

캐시 최신 상태 기간은 점진적으로 늘리세요. 긴 값은 재사용률을 높이지만 무효화 실수의 영향도 키웁니다. 공개 버전 리소스는 긴 저장 기간을 견딜 수 있습니다. 자주 편집하는 HTML에는 제어된 재검증 또는 신뢰할 수 있는 퍼지 자동화가 필요합니다. 계정 페이지는 애플리케이션이 분리 캐싱을 위해 특별히 설계되고 테스트되지 않았다면 공유 스토리지 밖에 두어야 합니다.

정상 동작이 확인된 뒤에는 장애도 계획하세요. 오리진 인증서가 계속 갱신되게 하고, 프록싱을 중지하는 방법을 문서화하며, 인프라 설정을 버전 관리에 보관하고, 구매했다면 오리진 장애 조치를 테스트하세요. DNS, 캐시 정책, 보안 규칙, 청구 알림, 장애 커뮤니케이션의 책임자를 정합니다.

이 측정된 도입 과정이 감당할 수 있는 총비용으로 의미 있는 성능, 안정성, 보안 향상을 만든다면 Cloudflare는 적합한 선택입니다. 폭넓은 네트워크와 통합 제품은 Cloudflare를 선두 옵션으로 만들며, 실제로 애플리케이션을 개선하는지는 규율 있는 설정이 결정합니다.