Cloudflare Private Origins 정식 출시, 기존 사설 연결로 내부 서비스에 프록시 요청 전달

2026년 10월 30일 Cloudflare는 프라이빗 오리진(private origins) 서비스가 정식 출시(GA)되었다고 발표했다. 사이트 소유자가 프록시되는 DNS 레코드를 프라이빗 IP 주소로 지정하면, Cloudflare는 고객이 이미 가진 Cloudflare One 연결을 통해 그 오리진에 도달한다. 오리진은 비공개로 유지되며, 웹 애플리케이션 방화벽(WAF), 캐싱, 봇 관리, Workers가 공개 오리진과 같은 방식으로 작동한다고 Cloudflare는 말한다.

Cloudflare는 이 기능을 6월에 비공개 베타로 출시했다고 한다. 내부 API, AI 에이전트 백엔드, MCP 서버, 운영 도구가 인터넷을 마주하도록 만들어지지 않았는데도 파트너, 고객, 에이전트의 요청을 받아야 한다는 고객의 이야기가 계기였다. 베타 전에는 이런 서비스 앞에 Cloudflare를 두려면 공용 IP를 노출하거나, 방화벽 포트를 열거나, 오리진 옆에서 cloudflared를 실행해야 했다. 이런 방식 때문에 프라이빗 애플리케이션은 공개 애플리케이션이 누리는 보호를 받지 못하는 경우가 많았다. 베타 기간에는 계정 팀을 통해 접근했고, 게시물은 오늘 그 그룹 밖으로 접근을 넓힌다고 말한다. 정식 출시 후에도 계정에 Private Origins 권한(entitlement)이 있어야 하며, 게시물은 고객에게 계정 팀에 활성화를 요청하라고 안내한다.

설정은 프록시되는 A 또는 AAAA 레코드로 한다. ‘Use private network routing’ 설정은 RFC 1918 사설 IPv4 주소, RFC 6598 CGNAT 주소(100.64.0.0/10), RFC 4193 고유 로컬 IPv6 주소(fc00::/7)에서는 자동으로 켜지며, 이 범위에서는 끌 수 없다. API로 끄려고 하면 오류가 반환된다. 오리진이 고객의 사설망을 통해서만 닿는 공용 IP를 쓴다면 수동으로 켤 수 있다. API에서는 표준 DNS 레코드에 private_routing을 true로 하는 속성이 하나 더해질 뿐이다. Cloudflare의 프록시는 Origin API에서 이 플래그를 받으면 그 주소에 공용 인터넷으로 직접 연결하지 않고, 요청을 사설 네트워킹 계층에 넘긴다. 이 계층은 고객의 기존 연결인 IPsec, GRE, Cloudflare Tunnel, CNI, Cloudflare Mesh를 쓴다. TLS 종료, WAF, 규칙, 캐싱은 계속 Cloudflare 네트워크에서 실행된다. 오리진에는 인바운드 방화벽 예외가 필요 없다. Cloudflare WAN을 쓰면 오리진에 커넥터 소프트웨어가 필요 없고, Cloudflare Mesh를 쓰면 사설망 안의 커넥터 하나가 여러 오리진을 담당할 수 있다.

시작하기 전에 고객에게는 Private Origins 권한, IPsec, GRE, CNI, Cloudflare Tunnel, Cloudflare Mesh 중 하나의 Cloudflare One 연결, 그리고 계정에서 활성화된 Unified Routing이 필요하다. 다만 Cloudflare Tunnel을 쓰면 Unified Routing은 필요 없다. Cloudflare WAN이나 Cloudflare Mesh를 쓰는 경우에는 Cloudflare의 출발지 대역(IPv4는 100.64.0.0/12, IPv6는 2606:4700:cf1:5000::/64)에 대한 반환 경로도 설정해야 한다. Cloudflare는 베타 경험에서 얻은 조언으로, 요청이 시간 초과되고 오리진에 아무것도 도착하지 않으면 먼저 반환 경로를 확인하라고 한다. 이 경로가 빠진 것이 가장 흔한 설정 실패였기 때문이다. 지원하지 않는 기능도 있다. Argo Smart Routing과 Dedicated CDN Egress IPs는 프라이빗 오리진에서 쓸 수 없고, 오리진 상태 점검에는 Load Balancing이 필요하다. 게시물은 전체 제한 목록을 개발자 문서에서 보라고 안내한다. 우리가 그 문서 페이지를 읽었을 때는 업데이트 날짜가 5월 7일이었고 비공개 베타와 Enterprise 전용 표시가 그대로여서, 블로그 글과 문서 페이지는 아직 일치하지 않았다.

주소 유형에 따라 사설 경로 설정도 달라진다. RFC 1918 사설 IPv4, RFC 6598 공유 주소 및 RFC 4193 로컬 IPv6에 대한 프록시 레코드에는 설정이 자동 적용되고 끌 수 없다. 겉으로는 공인 주소라도 고객의 사설 연결을 통해서만 닿는 원본이라면 수동으로 켤 수 있다. Cloudflare의 프록시는 DNS 레코드의 표시를 읽고 공용 인터넷 대신 사설 네트워크 계층으로 요청을 넘긴다. WAN을 쓸 때 원본마다 연결 프로그램을 설치할 필요가 없고 Mesh에서는 사설망 안의 연결 지점 하나가 여러 원본을 맡을 수 있다. 하지만 이 경로가 내부 서비스의 사용자 인증을 없애 주는 것은 아니다. 업체가 예고한 사설망 간 연결은 2027년 초 비공개 시험 목표인 별도 후속 작업이다.

Cloudflare는 다음 단계가 프라이빗에서 프라이빗으로 가는 트래픽이라고 말한다. 한 사설망의 사용자, 서비스, AI 에이전트가 Cloudflare의 애플리케이션 서비스를 거쳐 다른 사설망의 애플리케이션에 닿는 방식이다. 엔지니어링 작업이 진행 중이며 2027년 초 비공개 베타를 목표로 한다. 이미 IPsec, GRE, CNI, Tunnel, Mesh를 운영하는 팀에게 이번 출시는 내부 서비스를 인터넷에 노출하지 않고 그 앞에 WAF, 속도 제한, 캐싱을 둘 수 있는 방법이다. 단, 권한과 반환 경로가 갖춰져 있어야 한다.