🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

클라우드플레어는 공개 인터넷 트래픽을 사설 애플리케이션으로 안전하게 라우팅하면서, 원본을 공개 IP로 노출하지 않고도 WAF·봇 관리·속도 제한·캐싱·Workers 같은 애플리케이션 서비스를 적용하는 기능을 엔터프라이즈 고객 대상 비공개 베타로 공개했다.

📌 핵심 요약

• 글은 공개 애플리케이션과 사설 애플리케이션을 별도 인프라로 운영하던 기존 구분이 점점 낡아지고 있다고 설명한다. 내부 API, AI 에이전트 백엔드, MCP 서버, 운영 도구처럼 원래 공개 인터넷에 노출되도록 설계되지 않은 서비스도 동일한 보안·성능·프로그래밍 가능성 계층이 필요하다는 문제의식에서 출발한다.
• 새로 공개된 Application Services for Private Origins는 적격 엔터프라이즈 고객 대상 비공개 베타 기능으로, 사설 원본을 공개 인터넷에 노출하지 않고도 공개 호스트명 뒤에 둘 수 있게 한다. 이를 통해 WAF, 봇 관리, 속도 제한, 캐싱, 변환 규칙, Workers 등을 사설 네트워크의 애플리케이션 앞단에도 적용할 수 있다.
• 이 기능은 기존 클라우드플레어 터널, 클라우드플레어 원, 클라우드플레어 WAN, 클라우드플레어 메시 연결 모델 위에 구축된다. 특히 이미 IPsec, GRE, CNI 링크, 메시 같은 사설 연결을 운영하는 고객이 별도의 원본 커넥터나 공개 로드밸런서를 추가하지 않고 같은 연결을 공개-사설 트래픽 라우팅에 사용할 수 있게 하는 점이 핵심이다.
• 사용 방식은 프록시된 A 또는 AAAA DNS 레코드에서 사설 네트워크 라우팅을 켜는 형태이며, RFC 1918 사설 IPv4, RFC 6598 CGNAT, RFC 4193 고유 로컬 IPv6 범위는 자동으로 적용된다. API에서는 표준 DNS 레코드에 use_private_routing 속성을 추가하는 방식으로 자동화할 수 있고, 클라우드플레어 프록시는 이 신호를 보고 최종 연결을 공용 인터넷이 아니라 사설 네트워킹 계층으로 넘긴다.
• 글은 이 모델이 HTTP뿐 아니라 Spectrum과 Workers VPC까지 확장된다고 설명한다. Spectrum은 사설 IP의 TCP·UDP 서비스 앞에 설 수 있고, Workers VPC 바인딩은 Workers 런타임이 같은 사설 경로로 원본에 접근하게 하며, 향후에는 공개-사설을 넘어 사설-사설 트래픽에도 같은 애플리케이션 서비스 계층을 적용하는 방향을 제시한다.

🧩 주요 포인트

1. 글은 공개 애플리케이션과 사설 애플리케이션을 별도 인프라로 운영하던 기존 구분이 점점 낡아지고 있다고 설명한다. 내부 API, AI 에이전트 백엔드, MCP 서버, 운영 도구처럼 원래 공개 인터넷에 노출되도록 설계되지 않은 서비스도 동일한 보안·성능·프로그래밍 가능성 계층이 필요하다는 문제의식에서 출발한다.
2. 새로 공개된 Application Services for Private Origins는 적격 엔터프라이즈 고객 대상 비공개 베타 기능으로, 사설 원본을 공개 인터넷에 노출하지 않고도 공개 호스트명 뒤에 둘 수 있게 한다. 이를 통해 WAF, 봇 관리, 속도 제한, 캐싱, 변환 규칙, Workers 등을 사설 네트워크의 애플리케이션 앞단에도 적용할 수 있다.
3. 이 기능은 기존 클라우드플레어 터널, 클라우드플레어 원, 클라우드플레어 WAN, 클라우드플레어 메시 연결 모델 위에 구축된다. 특히 이미 IPsec, GRE, CNI 링크, 메시 같은 사설 연결을 운영하는 고객이 별도의 원본 커넥터나 공개 로드밸런서를 추가하지 않고 같은 연결을 공개-사설 트래픽 라우팅에 사용할 수 있게 하는 점이 핵심이다.
4. 사용 방식은 프록시된 A 또는 AAAA DNS 레코드에서 사설 네트워크 라우팅을 켜는 형태이며, RFC 1918 사설 IPv4, RFC 6598 CGNAT, RFC 4193 고유 로컬 IPv6 범위는 자동으로 적용된다. API에서는 표준 DNS 레코드에 use_private_routing 속성을 추가하는 방식으로 자동화할 수 있고, 클라우드플레어 프록시는 이 신호를 보고 최종 연결을 공용 인터넷이 아니라 사설 네트워킹 계층으로 넘긴다.
5. 글은 이 모델이 HTTP뿐 아니라 Spectrum과 Workers VPC까지 확장된다고 설명한다. Spectrum은 사설 IP의 TCP·UDP 서비스 앞에 설 수 있고, Workers VPC 바인딩은 Workers 런타임이 같은 사설 경로로 원본에 접근하게 하며, 향후에는 공개-사설을 넘어 사설-사설 트래픽에도 같은 애플리케이션 서비스 계층을 적용하는 방향을 제시한다.

🧠 상세 정리

1. 공개 인프라와 사설 인프라의 경계가 약해지는 배경

글은 인터넷의 오랜 운영 방식이 공개 애플리케이션과 사설 애플리케이션을 서로 다른 세계로 나누어 왔다고 설명한다. 공개 애플리케이션은 콘텐츠 전송 네트워크와 웹 애플리케이션 방화벽 뒤에 놓였고, 사설 애플리케이션은 VPN, 방화벽, 별도 운영 스택 뒤에서 관리되었다. 그러나 조직이 실제로 중요하게 여기는 애플리케이션 중 상당수는 공개 웹사이트가 아니라 내부 API, AI 에이전트 백엔드, MCP 서버, 운영 도구처럼 공개 인터넷 노출을 전제로 만들지 않은 서비스다. 저자들은 보안이 애플리케이션이 어디에 위치하는지의 우연한 결과가 아니라, 애플리케이션에 도달하는 트래픽의 속성이 되어야 한다고 주장한다.

2. 사설 애플리케이션에 애플리케이션 서비스를 적용하기 어려웠던 문제

기존에는 사설 애플리케이션에 공개 서비스 수준의 보안과 성능 기능을 적용하려면 여러 타협이 필요했다. 공개 IP를 부여하거나, 방화벽 예외를 만들거나, 원본 근처에 커넥터 소프트웨어를 실행하거나, 복잡한 네트워킹 구성을 추가해야 하는 경우가 많았다. 그 결과 사설 애플리케이션은 WAF, 봇 관리, 속도 제한, 캐싱, 트래픽 가속, URL 재작성, Workers 같은 기능이 필요함에도 이를 충분히 활용하지 못했다. 글은 이 간극을 줄이기 위해 사설 원본을 공개 인터넷에 직접 노출하지 않으면서도 클라우드플레어의 애플리케이션 서비스 계층을 앞단에 둘 수 있어야 한다고 설명한다.

3. Application Services for Private Origins의 출시 의미

클라우드플레어가 발표한 Application Services for Private Origins는 적격 엔터프라이즈 고객을 대상으로 한 비공개 베타 기능이다. 이 기능은 고객이 사설 원본을 공개 인터넷에 노출하지 않고도 공개 트래픽을 안전하게 라우팅할 수 있게 한다. 클라우드플레어의 보안, 성능, 프로그래밍 가능성 서비스가 공개 인터넷 애플리케이션과 같은 방식으로 사설 네트워크에서 실행되는 애플리케이션도 보호할 수 있게 되는 것이다. 원본에 공개 IP를 부여하거나 인바운드 방화벽 규칙을 열거나 cloudflared를 원본에서 실행하지 않아도 WAF, 봇 관리, 속도 제한, 캐싱, 재작성, Workers를 사설 원본 앞에 배치할 수 있다는 점이 핵심이다.

4. 기존 연결 모델 위에 확장되는 하나의 애플리케이션 계층

이 라우팅 모델은 클라우드플레어가 이미 지원하던 클라우드플레어 터널, 클라우드플레어 원 클라이언트, 사설 네트워크 통합 같은 연결 패턴 위에 구축된다. 과거에는 클라우드플레어 터널이 cloudflared를 통해 공개 트래픽을 사설 애플리케이션으로 보낼 수 있게 해주었지만, 이번 기능은 기존 클라우드플레어 WAN이나 클라우드플레어 메시 연결에도 같은 모델을 확장한다. 고객은 각 제품별로 별도 네트워크 스택을 관리하는 대신 API와 대시보드에서 라우팅 동작을 정의할 수 있다. 클라우드플레어는 사설 네트워킹 계층을 애플리케이션 서비스 스택에 직접 확장해, 보안·성능 프록시 인프라가 사설 IP를 공개 호스트명의 유효한 원본 대상으로 취급할 수 있게 했다고 설명한다.

5. 공개-사설 트래픽 흐름과 제품 간 통합 모델

글은 애플리케이션 트래픽을 사용자가 어디에서 오고 애플리케이션이 어디에 있는지에 따라 네 가지 조합으로 나눈다. 공개 인터넷의 사용자가 공개 인터넷의 애플리케이션에 접근하는 방식은 클라우드플레어가 기존부터 제공해 온 전통적인 모델이다. 사설 네트워크 사용자가 공개 서비스에 안전하게 접근하는 모델은 클라우드플레어 원이 담당해 왔다. 이번에 제공되는 것은 공개 인터넷 사용자가 사설 네트워크의 애플리케이션에 접근하는 흐름이며, 클라우드플레어는 다음 단계로 사설 네트워크의 사용자·서비스·에이전트가 다른 사설 네트워크의 애플리케이션에 접근하는 private-to-private 흐름을 구축하겠다고 밝힌다.

6. DNS 레코드와 API에서의 동작 방식

실제 사용은 프록시된 A 또는 AAAA 레코드에서 사설 네트워크 라우팅을 켜는 방식으로 설명된다. 이 설정을 켜면 클라우드플레어 네트워크에서는 WAF, 속도 제한, 캐싱, 봇 관리, 변환 규칙이 평소처럼 실행되며, 달라지는 것은 마지막 홉뿐이다. 원본에 공용 인터넷으로 직접 연결하는 대신 고객이 이미 보유한 사설 네트워크 연결을 통해 연결이 라우팅된다. API 자동화에서는 표준 DNS 레코드에 use_private_routing 속성을 추가하면 되고, 클라우드플레어 프록시 플랫폼은 Origin API 응답의 이 플래그를 보고 요청을 사설 네트워킹 계층으로 넘긴다.

7. 자동 적용되는 주소 범위와 수동 설정이 필요한 경우

사설 주소 범위에 대해서는 설정 동작도 구체적으로 제시된다. 10.x.x.x, 172.16.x.x부터 172.31.x.x, 192.168.x.x 같은 RFC 1918 사설 IPv4 범위와 100.64.x.x부터 100.127.x.x까지의 RFC 6598 CGNAT 범위, FC00::/7의 RFC 4193 고유 로컬 IPv6 주소는 사설 네트워크 안에서만 도달 가능한 주소이므로 토글이 자동으로 활성화된다. 반면 주소 자체는 공용 IP이지만 고객의 사설 네트워크나 터널을 통해서만 도달 가능한 경우에는 사용자가 직접 토글을 켤 수 있다. 이 구분은 원본의 노출 여부가 주소 형식만이 아니라 실제 도달 경로와도 관련된다는 점을 보여준다.

8. HTTP를 넘어 Spectrum과 Workers VPC로 확장되는 라우팅

글은 이 사설 라우팅 모델이 HTTP 애플리케이션에만 머물지 않는다고 설명한다. 원본은 웹 서버가 아니라 TCP 데이터베이스, UDP 로깅 엔드포인트, Workers가 직접 호출하는 사설 API일 수도 있다. Spectrum은 클라우드플레어의 계층 4 프록시로서 사설 IP에서 실행되는 TCP 및 UDP 서비스 앞에 설 수 있으며, 이때 중간 로드밸런서 풀 대신 원본 구성에 virtual_network_id를 직접 지정할 수 있다. 초기 릴리스에서 Spectrum 사설 원본은 클라우드플레어 터널을 통해 지원되며, 추가 사설 네트워크 연결 옵션은 이후 릴리스에서 지원될 예정이다.

9. 비공개 베타, 향후 일반 제공, 그리고 시작 조건

Application Services for Private Origins는 현재 적격 엔터프라이즈 고객에게 비공개 베타로 제공되며, 클라우드플레어는 2026년 4분기 일반 제공을 목표로 한다고 밝힌다. 일반 제공 이후에는 공개-사설 라우팅을 넘어 사설 네트워크 안의 사용자, 서비스, AI 에이전트가 다른 사설 네트워크의 애플리케이션에 안전하게 접근하는 흐름을 구축하려는 방향이 제시된다. 시작하려면 고객은 클라우드플레어 계정 팀에 접근 권한을 요청해야 하며, 활성화 후 개발자 문서에 따라 설정을 진행한다. 또한 IPsec, GRE, CNI 또는 클라우드플레어 메시 형태의 클라우드플레어 원 연결과, 사설 네트워크에서 클라우드플레어 소스 IP 범위 100.64.0.0/12에 대한 반환 경로가 필요하다.

🧾 핵심 주장 / 시사점

• 핵심 변화는 사설 애플리케이션을 공개 인터넷에 노출하지 않으면서도 공개 애플리케이션과 동일한 애플리케이션 보안·성능 계층을 적용할 수 있게 만드는 데 있다.
• 이미 클라우드플레어 WAN, 메시, 터널, 클라우드플레어 원 연결을 운영하는 조직일수록 별도 공개 로드밸런서나 원본 커넥터를 줄이고 기존 사설 연결을 재사용할 수 있는 이점이 크다.
• 클라우드플레어가 제시하는 장기 방향은 사용자와 원본이 공개인지 사설인지와 관계없이 같은 프록시, 라우팅, 보안 정책 계층을 적용하는 통합 트래픽 모델이다.

✅ 액션 아이템

• 사설 인프라가 필요한 내부 API·AI 에이전트 백엔드·MCP·운영 도구를 공개 자산과 분리해 private origin 후보군으로 재정의한다.
• 프록시된 A/AAAA DNS 레코드에 use_private_routing을 적용해 RFC 1918·RFC 6598·RFC 4193 주소대역 기반 라우팅이 의도대로 동작하는지 점검한다.
• 기존 IPsec·GRE·CNI 링크·서비스 메시 운영 환경에서 원본 커넥터나 공개 로드밸런서 추가 없이 WAF·봇 관리·속도 제한·캐싱을 private origin 경로에 동일 적용한다.

❓ 열린 질문

• 적격 엔터프라이즈 고객 전용 비공개 베타 조건을 충족한 경우, 우리 대상 서비스에서 우선 적용 범위는 어디까지가 현실적인가?
• use_private_routing 자동화를 설계할 때 내부 API·AI 백엔드·MCP를 누락하지 않으려면 어떤 도메인과 서브도메인 기준이 필요한가?
• HTTP 외 Spectrum과 Workers VPC 확장 적용 시 공개-사설 경계 바깥의 사설-사설 트래픽으로까지 일관되게 확장 가능한 기준은 무엇인가?