Cloudflare로 공개 트래픽을 사설 애플리케이션에 라우팅

출처: Cloudflare Blog

2026-06-10

6분 읽기

인터넷 역사의 대부분 동안, 퍼블릭 인프라와 프라이빗 인프라는 별개의 세계처럼 운영되었습니다. 퍼블릭 애플리케이션은 콘텐츠 전송 네트워크(CDN)와 웹 애플리케이션 방화벽(WAF) 뒤에 있었고, 프라이빗 애플리케이션은 가상 사설망(VPN), 방화벽, 별도의 운영 스택 뒤에 있었습니다. 우리는 이제 그 구분이 사라지고 있다고 생각합니다.

조직이 신경 쓰는 많은 애플리케이션은 퍼블릭 웹사이트가 아닙니다. 내부 API, AI 에이전트 백엔드, MCP 서버, 운영 도구, 그리고 처음부터 퍼블릭 인터넷에 노출될 설계가 아니었던 서비스들입니다. 하지만 이러한 애플리케이션도 최신 보안·성능·프로그래밍 가능 서비스가 필요합니다. 보안은 애플리케이션이 어디에 위치했는가에 따라 우연히 결정되는 것이 아니라, 애플리케이션에 도달하는 트래픽의 속성이어야 합니다.

지금까지 프라이빗 애플리케이션에 이러한 서비스를 적용하려면 퍼블릭 IP, 방화벽 예외, 커넥터 소프트웨어, 혹은 복잡한 네트워킹이 필요했습니다. 그 결과, 많은 프라이빗 애플리케이션이 WAF, 봇 관리, 속도 제한, 캐시, 트래픽 가속, 리라이트, Workers와 같은 기능을 놓치게 되었으며, 퍼블릭 애플리케이션과 동일한 보호와 제어가 필요함에도 불구하고 이를 활용하지 못했습니다.

오늘부터, 자격을 갖춘 엔터프라이즈 고객을 대상으로 클로즈드 베타 형태로 “프라이빗 오리진용 애플리케이션 서비스”를 출시합니다. 이제 고객은 프라이빗 오리진을 퍼블릭 인터넷에 노출하지 않고도 안전하게 트래픽을 라우팅할 수 있습니다. 이를 통해 Cloudflare의 보안·성능·프로그래밍 가능 서비스가 퍼블릭 인터넷 애플리케이션에 적용되는 것과 동일하게 프라이빗 네트워크에서 실행되는 애플리케이션을 보호합니다.

WAF 규칙, 봇 관리, 속도 제한, 캐시, 리라이트, Workers를 이제 퍼블릭 IP 노출, 인바운드 방화벽 규칙, 혹은 오리진에서 실행되는 cloudflared 없이도 프라이빗 오리진 앞에 배치할 수 있습니다.

네 가지 사용 사례, 하나의 애플리케이션 레이어

이 라우팅 모델은 현재 Cloudflare가 지원하는 Cloudflare Tunnel, Cloudflare One Client, 그리고 프라이빗 네트워크 통합 방식을 기반으로 합니다. 수년간 Cloudflare Tunnel은 고객이 cloudflared를 통해 퍼블릭 트래픽을 프라이빗 애플리케이션으로 라우팅하도록 해왔습니다. 이번 새로운 기능은 기존 Cloudflare WAN 또는 Cloudflare Mesh 연결에서도 동일한 모델을 적용할 수 있게 하며, 오리진에 커넥터 소프트웨어를 설치할 필요가 없습니다.

이러한 연결은 대부분 Cloudflare의 프라이빗 네트워킹 라우팅 레이어를 통해 오케스트레이션됩니다. 이 레이어는 Cloudflare Tunnel, Virtual Networks, Cloudflare Mesh 등 다양한 연결 모델을 가로질러 트래픽이 프라이빗 목적지에 도달하는 방식을 결정합니다. 고객은 별도의 네트워킹 스택을 관리하지 않고도 API와 대시보드만으로 라우팅 동작을 정의할 수 있습니다.

우리는 Cloudflare의 프라이빗 네트워킹 레이어를 직접 애플리케이션 서비스 스택에 확장했습니다. 이제 보안·성능 프록시 인프라가 프라이빗 IP를 퍼블릭 호스트네임에 대한 유효한 오리진 대상으로 취급합니다. 결과적으로 이전에 Cloudflare Tunnel, Cloudflare One, Cloudflare Mesh, 혹은 Cloudflare WAN을 통해서만 접근 가능했던 프라이빗 IP가 이제 퍼블릭 오리진과 동일하게 Cloudflare의 보안·성능·프로그래밍 가능 서비스 뒤에 위치할 수 있게 되었습니다.

이와 동시에 Cloudflare 제품 전반에 걸쳐 보다 통합된 모델이 형성됩니다. Workers VPC 바인딩과 Spectrum 프라이빗 오리진 라우팅이 동일한 프라이빗 연결 레이어를 사용하게 되면서, 고객은 프라이빗 트래픽이 Cloudflare 환경을 통해 이동하는 방식을 한 곳에서 관리할 수 있게 됩니다.

애플리케이션 트래픽은 사용자가 어디에서 오고 애플리케이션이 어디에 위치하느냐에 따라 네 가지 조합으로 구분됩니다.

오른쪽 위 조합은 Cloudflare가 기존에 제공해 온 방식입니다: 인터넷 사용자가 인터넷에 있는 애플리케이션에 접근하고, 그 사이에 Cloudflare가 위치합니다. 오른쪽 아래는 Cloudflare One으로, 프라이빗 네트워크에 있는 사용자가 퍼블릭 서비스를 안전하게 이용합니다.

왼쪽 위가 오늘 출시되는 기능이며, 왼쪽 아래인 프라이빗‑투‑프라이빗 조합은 앞으로 구축해 나갈 목표입니다.

오늘 출시되는 내용

지금까지 퍼블릭 트래픽을 프라이빗 오리진으로 전달하려면 트레이드오프가 불가피했습니다. 고객은 오리진 근처 혹은 오리진 자체에 Cloudflare Tunnel을 설치해 cloudflared(커넥터 소프트웨어)를 실행하거나, 프라이빗 오리진 풀을 활용한 Cloudflare Load Balancing을 사용해 헬스 체크와 장애 조치를 구현했습니다. 많은 경우 조직은 퍼블릭 로드 밸런서, 리버스 프록시, 홉 간 mTLS, 다중 레이어 TLS 종료 등 병렬 인프라를 별도로 유지했습니다. 이 때문에 Cloudflare 전체 애플리케이션 서비스 스택을 프라이빗 애플리케이션에 적용하려면 추가 복잡성·운영 부담·별도 제품이 필요했습니다. Application Services for Private Origins는 이러한 트레이드오프를 없앱니다.

부족했던 점은 이미 Cloudflare WAN(IPsec 터널, GRE 터널, CNI 링크)이나 Cloudflare Mesh를 운영하고 있는 고객을 위한 경로였습니다. 이들은 사이트‑투‑사이트 네트워킹과 Zero Trust를 위해 프라이빗 연결을 구축했으며, 그 동일한 연결을 퍼블릭 트래픽이 프라이빗 오리진에 도달하도록 사용하고 싶어했습니다. 바로 이것이 Application Services for Private Origins가 제공하는 기능입니다.

프록시된 A 또는 AAAA 레코드에서 Use private network routing을 토글하면, Cloudflare의 WAF, 속도 제한, 캐시, 봇 관리, 트랜스폼 규칙이 모두 기존과 동일하게 Cloudflare 네트워크 상에서 동작합니다. 차이점은 마지막 홉뿐입니다. 퍼블릭 인터넷을 통해 오리진에 도달하는 대신, Cloudflare가 기존 프라이빗 네트워크 연결을 통해 연결을 라우팅합니다.

이 토글은 RFC 1918 프라이빗 IPv4 대역(10.x.x.x, 172.16.x.x–172.31.x.x, 192.168.x.x), RFC 6598 CGNAT 대역(100.64.x.x–100.127.x.x), 그리고 RFC 4193 Unique Local IPv6 주소(FC00::/7)에 대해 자동으로 활성화됩니다. 이러한 주소는 프라이빗 네트워크 내에서만 도달 가능하기 때문입니다. 퍼블릭 IP이지만 오직 프라이빗 네트워크 또는 터널을 통해서만 도달 가능한 경우에는 토글을 수동으로 활성화할 수 있습니다.

API 예시

API를 통해 배포를 자동화하는 고객에게는 프라이빗 라우팅이 표준 DNS 레코드에 추가되는 속성일 뿐입니다.

POST /zones/{zone_id}/dns_records
{
 "type": "A",
 "name": "app.example.com",
 "content": "10.0.0.50",
 "ttl": 300,
 "proxied": true,
 "use_private_

(코드 블록은 그대로 유지됩니다)