AI 에이전트는 팀이 프라이빗 네트워크 액세스를 생각하는 방식을 바꿔놓았습니다. 코딩 에이전트는 스테이징 데이터베이스를 쿼리해야 합니다. 프로덕션 에이전트는 내부 API를 호출해야 합니다. 개인 AI 어시스턴트는 홈 네트워크에서 실행되는 서비스에 도달해야 합니다. 이제 클라이언트는 더 이상 사람이나 서비스만이 아닙니다. 클라이언트는 에이전트입니다. 자율적으로 실행되며, 사용자가 명시적으로 승인하지 않은 요청을 보내고, 보안을 유지해야 하는 인프라를 대상으로 작동합니다.
이러한 각 워크플로에는 동일한 근본적인 문제가 있습니다. 에이전트는 프라이빗 리소스에 접근해야 하지만, 이를 위한 도구는 자율 소프트웨어가 아니라 사람을 위해 만들어졌습니다. VPN은 대화형 로그인이 필요합니다. SSH 터널은 수동 설정이 필요합니다. 서비스를 공개로 노출하는 것은 보안 위험입니다. 그리고 이러한 어떤 방식도, 에이전트가 연결된 이후 실제로 무엇을 하고 있는지에 대한 가시성을 제공하지 않습니다.
오늘 Cloudflare Mesh를 소개합니다. 이를 통해 프라이빗 네트워크를 서로 연결하고, 에이전트에 안전한 액세스를 제공할 수 있습니다. 또한 Mesh를 Cloudflare 개발자 플랫폼과 통합하여 Workers, Durable Objects, 그리고 Agents SDK로 구축된 에이전트가 프라이빗 인프라에 직접 접근할 수 있도록 할 것입니다.
Cloudflare One의 SASE 및 Zero Trust 제품군을 사용하고 계신다면 바로 Mesh에 액세스할 수 있습니다. 에이전틱 워크로드를 보호하는 데 새로운 기술 패러다임이 필요한 것은 아닙니다. 에이전틱 시대에 맞게 구축된 SASE가 필요할 뿐이며, 그것이 바로 Cloudflare One입니다. Cloudflare Mesh는 이미 익숙한 온램프(on-ramp)인 WARP Connector(현재는 Cloudflare Mesh 노드) 및 WARP Client (현재는 Cloudflare One Client)를 활용하여 더 간단한 설정으로 누리는 새로운 경험입니다. 이들을 함께 사용하면 사람, 개발자, 그리고 에이전트 트래픽을 위한 프라이빗 네트워크를 구축할 수 있습니다. Mesh는 기존 Cloudflare One 배포에 직접 통합됩니다. 기존 게이트웨이 정책, 액세스 규칙, 장치 상태 확인이 Mesh 트래픽에 자동으로 적용됩니다.
단지 에이전트, 서비스, 팀을 위한 프라이빗 네트워킹이 필요한 개발자라면 Mesh에서 시작하면 됩니다. 몇 분 만에 설정하고, 네트워크를 연결하고, 트래픽을 보호할 수 있습니다. 또한 Mesh는 Cloudflare One 플랫폼에서 실행되므로, 시간이 지나면서 더 고급 기능으로 확장하여, Gateway 네트워크, DNS 및 HTTP 정책을 통해 세밀한 트래픽 제어를 수행하고, Access for Infrastructure를 통해 SSH 및 RDP 세션을 관리하며, 브라우저 격리로 안전한 웹 액세스를 제공하고, DLP로 민감한 데이터의 네트워크 외부 유출을 방지하며, CASB를 통해 SaaS 보안을 강화할 수 있습니다. 이 모든 것을 처음부터 계획할 필요는 없습니다. 필요해질 때 별도의 마이그레이션 없이 바로 확장하면 됩니다.
프라이빗 네트워킹은 서버에 SSH로 접속하고, 데이터베이스를 쿼리하고, 내부 API에 액세스하는 것처럼 항상 클라이언트를 리소스에 연결하는 것이 핵심이었습니다. 달라진 것은 클라이언트가 누구냐는 점입니다. 1년 전만 해도 그 대상은 개발자와 서비스였습니다. 이제는 점점 에이전트가 그 중심이 되고 있습니다.
이건 이론적인 이야기가 아닙니다. 생태계를 보면 분명합니다. 도구 액세스를 제공하는 MCP(Model Context Protocol) 서버가 폭발적으로 증가하고 있고, 프라이빗 리포지토리와 데이터베이스를 읽어야 하는 코딩 에이전트, 그리고 홈 하드웨어에서 실행되는 개인 어시스턴트까지 등장하고 있습니다. 이러한 모든 패턴은 에이전트가 필요한 리소스에 접근할 수 있다는 전제를 깔고 있습니다. 그런데 그 리소스가 프라이빗 네트워크에 격리되어 있다면, 에이전트는 아무것도 할 수 없게 됩니다.
이로 인해 현재 보호하기 어려운 세 가지 워크플로우가 생성됩니다.
모바일 장치에서 개인 에이전트에 액세스. 집에 있는 Mac mini에서 OpenClaw를 실행 중이고, 이를 휴대폰이나 카페에 있는 노트북, 또는 회사 PC에서 접속하고 싶습니다. 하지만 이를 퍼블릭 인터넷에 노출하는 것은(비밀번호로 보호하더라도) 일부 취약점을 그대로 드러낼 수 있습니다. 해당 에이전트는 셸 액세스, 파일 시스템 액세스, 그리고 홈 네트워크에 대한 네트워크 액세스까지 가지고 있습니다. 설정을 한 번만 잘못해도 누구나 접근할 수 있는 상태가 될 수 있습니다.
코딩 에이전트가 스테이징 환경에 액세스하도록 허용. 노트북에서 Claude Code, Cursor, 또는 Codex를 사용하고 있습니다. 배포 상태를 확인하거나, 스테이징 데이터베이스에서 분석 데이터를 쿼리하거나, 내부 개체 스토리지에서 데이터를 읽도록 에이전트에 요청합니다. 하지만 이러한 서비스는 프라이빗 클라우드 VPC 안에 있기 때문에, 서비스를 인터넷에 노출하거나 노트북 전체를 VPC에 터널링하지 않는 한 에이전트가 해당 서비스에 접근할 수 없습니다.
배포된 에이전트를 프라이빗 서비스에 연결. Cloudflare Workers에서 Agents SDK를 사용해 제품에 에이전트를 구축하고 있습니다. 이러한 에이전트는 내부 API를 호출하고, 데이터베이스를 쿼리하며, 퍼블릭 인터넷에 노출되지 않은 서비스에 접근해야 합니다. 이때 필요한 것은 프라이빗 액세스이지만, 동시에 범위가 제한된 권한, 감사 로그, 그리고 자격 증명 유출이 없는 환경이어야 합니다.
Cloudflare Mesh: 사용자, 노드, 에이전트를 위한 하나의 프라이빗 네트워크
Cloudflare Mesh는 개발자 친화적인 프라이빗 네트워킹입니다. 하나의 경량 커넥터, 하나의 바이너리로 개인 장치, 원격 서버, 사용자 엔드포인트까지 모든 것을 연결합니다. 각 패턴마다 별도의 도구를 설치할 필요가 없습니다. 네트워크에 커넥터 하나만 두면, 모든 액세스 패턴이 동작합니다.
일단 연결되면 프라이빗 네트워크의 장치들이 Cloudflare의 330개 이상 도시에 걸쳐 있는 글로벌 네트워크를 통해 라우팅되는 프라이빗 IP를 통해 서로 통신할 수 있으므로 네트워크의 안정성과 제어 능력이 향상됩니다.
이제 Mesh를 사용하면 하나의 솔루션으로 위에서 언급한 모든 에이전트 시나리오를 해결할 수 있습니다.
휴대폰에 Cloudflare One Client for iOS를 설치하면, 모바일 장치에서 Mesh 프라이빗 네트워크를 통해 로컬 Mac mini에서 실행 중인 OpenClaw에 안전하게 연결할 수 있습니다.
노트북에 Cloudflare One Client for macOS를 설치하면, 노트북을 프라이빗 네트워크에 연결하여 코딩 에이전트가 스테이징 데이터베이스나 API에 접근하고 쿼리할 수 있습니다.
Linux 서버에 Mesh 노드를 배치하면, 외부 클라우드의 VPC들을 서로 연결할 수 있어 에이전트가 외부 프라이빗 네트워크에 있는 리소스와 MCP에 접근할 수 있습니다.
Mesh는 Cloudflare One Client를 기반으로 동작하기 때문에, 모든 연결은 Cloudflare One 플랫폼의 보안 제어를 그대로 상속받습니다. 게이트웨이 정책은 Mesh 트래픽에도 적용됩니다. 장치 상태 점검을 통해 연결되는 장치를 검증하고, DNS 필터링으로 의심스러운 조회를 탐지합니다. 이 모든 것은 추가 설정 없이 제공되기 때문에 사람의 트래픽을 보호하던 동일한 정책이 에이전트 트래픽에도 그대로 적용됩니다.
Mesh가 도입되면서 이런 질문이 생길 수 있습니다. 언제 Tunnel 대신 Mesh를 사용해야 할까? 두 솔루션 모두 외부 네트워크를 프라이빗하게 Cloudflare에 연결하지만, 목적은 서로 다릅니다. Cloudflare Tunnel은 단방향 트래픽에 적합한 솔루션으로, Cloudflare가 에지에서 특정 프라이빗 서비스(예: 웹 서버나 데이터베이스)로 트래픽을 프록시하는 방식입니다.
반면 Cloudflare Mesh는 완전한 양방향, 다대다 네트워크를 제공합니다. Mesh에 연결된 모든 장치와 노드는 서로의 프라이빗 IP를 사용해 상호 접근할 수 있습니다. 네트워크에서 실행되는 애플리케이션이나 에이전트는 각 리소스마다 별도의 Tunnel을 구성할 필요 없이, Mesh에 있는 다른 모든 리소스를 탐색하고 접근할 수 있습니다.
Cloudflare Mesh는 메시 네트워크의 장점(복원력, 높은 확장성, 낮은 대기 시간, 높은 성능)을 제공하면서도, 모든 트래픽을 Cloudflare를 통해 라우팅함으로써 메시 네트워크의 핵심 과제 중 하나인 NAT 트래버설 문제를 해결합니다.
인터넷의 대부분은 NAT(Network Address Translation) 뒤에 있습니다. 이 메커니즘은 퍼블릭 헤더와 내부 프라이빗 주소 간의 트래픽을 매핑함으로써, 하나의 퍼블릭 IP 주소를 여러 장치가 공유할 수 있게 합니다. 두 장치가 모두 NAT 뒤에 있을 경우, 직접 연결이 실패할 수 있고 트래픽은 릴레이 서버를 거쳐야 합니다. 만약 릴레이 인프라의 PoP가 제한적이라면, 상당한 비율의 트래픽이 해당 릴레이를 거치게 되어 대기 시간이 증가하고 안정성은 떨어집니다. 이를 보완하기 위해 자체 릴레이 서버를 구축하는 것도 가능하지만, 이는 기존 네트워크를 연결하기 위해 추가 인프라를 직접 운영해야 하는 부담을 의미합니다.
Cloudflare Mesh는 다른 접근 방식을 취합니다. 모든 Mesh 트래픽은 Cloudflare의 글로벌 네트워크를 통해 라우팅되며, 이는 인터넷의 대규모 웹사이트 트래픽을 처리하는 동일한 인프라입니다. 크로스 리전 또는 멀티 클라우드 트래픽의 경우, 이 방식은 퍼블릭 인터넷 라우팅보다 일관되게 더 나은 성능을 제공합니다. 별도의 성능 저하가 있는 우회 경로가 존재하지 않습니다. Cloudflare 에지가 곧 경로이기 때문입니다.
Cloudflare를 통해 라우팅된다는 것은 모든 패킷이 Cloudflare의 보안 스택을 통과한다는 의미이기도 합니다. 이것이 Cloudflare One 플랫폼 위에 Mesh를 구축하는 핵심 장점입니다. 보안은 나중에 덧붙이는 별도의 제품이 아닙니다. 또한 동일한 글로벌 백본을 활용함으로써, 모든 팀에 다음과 같은 핵심 요소를 첫날부터 제공할 수 있습니다.
50개 노드 및 사용자 50명 무료. 전체 팀과 전체 스테이징 환경을 하나의 프라이빗 네트워크로 구성할 수 있으며, 이는 모든 Cloudflare 계정에 기본으로 포함됩니다.
글로벌 에지 라우팅. 전 세계 330개 이상의 도시에서 최적화된 백본 라우팅을 제공합니다. 제한된 PoP를 가진 릴레이 서버도 없고, 성능이 저하되는 우회 경로도 없습니다.
첫날부터 보안 제어. Mesh는 Cloudflare One에서 실행됩니다. 게이트웨이 정책, DNS 필터링, DLP, 트래픽 검사, 장치 상태 점검을 모두 동일한 플랫폼에서 사용할 수 있습니다. 간단한 프라이빗 연결부터 시작하면 됩니다. 트래픽 필터링이 필요할 때는 게이트웨이 정책을 활성화하고, SSH 및 RDP에 대한 세션 단위 제어가 필요할 때는 Access for Infrastructure를 적용하면 됩니다. 민감한 데이터가 네트워크를 벗어나지 않도록 해야 할 때는 DLP를 추가하면 됩니다. 모든 기능은 하나의 토글로 활성화할 수 있습니다.
높은 가용성. 높은 가용성을 구현한 상태로 Mesh 노드를 생성하고, 동일한 토큰을 사용해 여러 커넥터를 active-passive 모드로 실행하세요. 이들은 동일한 IP 경로를 광고하므로, 하나에 장애가 발생하면 트래픽이 자동으로 페일오버됩니다.
Mesh는 외부 클라우드 전반에 걸쳐 에이전트와 리소스를 연결해 주지만, 동시에 Workers에서 Agents SDK로 구축한 에이전트에서도 연결할 수 있어야 합니다. 이를 위해 Workers VPC를 확장하여, 전체 Mesh 네트워크를 Workers와 Durable Objects에서 접근할 수 있도록 했습니다.
즉, Workers에서 Cloudflare Mesh 네트워크에 연결할 수 있으며, 하나의 바인딩에서 fetch() 호출만으로 전체 네트워크에 접근할 수 있습니다. 이는 Workers VPC가 기존에 제공하던 Cloudflare Tunnel 지원을 보완하여, 네트워크를 보호하는 방식에 대해 더 많은 선택지를 제공합니다. 이제 wrangler.jsonc 파일에서 연결하려는 전체 네트워크를 지정할 수 있습니다. Mesh 네트워크에 바인딩하려면, 계정의 Mesh 네트워크에 바인딩되는 cf1:network 예약 키워드를 사용하세요.
"vpc_networks": [
{ "binding": "MESH", "network_id": "cf1:network", "remote": true },
{ "binding": "AWS_VPC", "tunnel_id": "350fd307-...", "remote": true }
]
그런 다음 Worker 또는 에이전트 코드 내에서 이를 사용할 수 있습니다.
export default {
async fetch(request: Request, env: Env, ctx: ExecutionContext) {
// Reach any internal host on your Mesh, no pre-registration required
const apiResponse = await env.MESH.fetch("http://10.0.1.50/api/data");
// Internal hostname resolved via tunnel's private DNS resolver
const dbResponse = await env.AWS_VPC.fetch("http://internal-db.corp.local:5432");
return new Response(await apiResponse.text());
},
};
개발자 플랫폼을 Mesh 네트워크에 연결하면, 프라이빗 데이터베이스, 내부 API, MCP에 안전하게 접근할 수 있는 Workers를 구축할 수 있습니다. 이를 통해 애플리케이션에 에이전트 기능을 제공하는 크로스 클라우드 에이전트와 MCP를 구현할 수 있습니다. 또한 이는 에이전트가 전체 스택을 엔드투엔드로 자율적으로 관찰하고, 로그를 교차 분석하며, 실시간으로 최적화를 제안할 수 있는 환경을 열어줍니다.
Cloudflare Mesh, Workers VPC, 그리고 Agents SDK를 함께 사용하면 Cloudflare와 외부 클라우드를 아우르는 통합 프라이빗 네트워크를 구축할 수 있습니다. 연결성과 컴퓨팅을 하나로 결합하여, 에이전트가 전 세계 어디에 있든 필요한 리소스에 안전하게 접근할 수 있게 되었습니다.
Mesh 노드는 서버이자, VM이자, 컨테이너입니다. 이 노드는 헤드리스 버전의 Cloudflare One Client를 실행하고 Mesh IP를 확보합니다. 서비스는 Cloudflare 에지를 통해 라우팅되는 프라이빗 IP를 통해 양방향으로 통신합니다.
장치는 노트북과 휴대폰입니다. 이들은 Cloudflare One Client를 실행하고, 프라이빗 IP를 통해 SSH, 데이터베이스 쿼리, API 호출 등의 Mesh 노드에 직접 연결됩니다. 로컬에서 실행되는 코딩 에이전트는 이 연결을 활용해 프라이빗 리소스에 접근합니다.
Workers에서 실행되는 에이전트는 Workers VPC 네트워크 바인딩을 통해 프라이빗 서비스에 접근합니다. 이들은 MCP를 통해 제어되는 전체 네트워크에 대해 범위가 제한된 액세스를 부여받습니다. 네트워크는 에이전트가 어디에 접근할 수 있는지를 제한하고, MCP 서버는 에이전트가 무엇을 할 수 있는지를 제한합니다.
현재 버전의 Mesh는 안전하고 통합된 연결을 위한 기반을 제공합니다. 하지만 에이전트 중심 워크플로가 점점 더 복잡해짐에 따라, 우리는 단순한 연결을 넘어 더 직관적으로 관리할 수 있고, 누가 또는 무엇이 서비스와 통신하고 있는지 더 세밀하게 인지할 수 있는 네트워크로 발전시키는 데 집중하고 있습니다. 올해 남은 기간 동안에는 다음과 같은 기능을 구축해 나갈 예정입니다.
우리는 이번 여름에 Cloudflare Tunnel의 호스트 이름 라우팅을 Mesh로 확장할 예정입니다. Mesh 노드는 wiki.local이나 api.staging.internal과 같은 프라이빗 호스트 이름에 대한 트래픽을 수신할 수 있으며, IP 목록을 관리하거나 해당 호스트 이름이 Cloudflare 에지에서 어떻게 해석되는지 신경 쓸 필요가 없습니다. 트래픽을 IP가 아니라 서비스 이름으로 라우팅하세요. 인프라에서 동적 IP, 오토스케일링 그룹, 또는 일시적으로 생성되고 사라지는 컨테이너를 사용하는 경우, 이렇게 하면 라우팅 관련 문제의 상당 부분을 근본적으로 제거할 수 있습니다.
지금은 Mesh IP(예: ssh 100.64.0.5)를 통해 Mesh 노드에 도달할 수 있습니다. 그 방식도 안 되는 건 아니지만 인프라를 바라보는 일반적인 방식과는 맞지 않습니다. 보통은 postgres-staging, api-prod, nikitas-openclaw 등의 이름으로 인프라를 인식합니다.
우리는 올해 하반기에는 Mesh DNS를 구축할 예정이며, 이를 통해 Mesh에 참여하는 모든 노드와 장치는 자동으로 라우팅 가능한 내부 호스트 이름을 부여받게 됩니다. DNS 설정이나 수동 레코드 등록이 필요 없습니다. 예를 들어 postgres-staging이라는 이름의 노드를 추가하면, postgres-staging.mesh가 Mesh에 연결된 어떤 장치에서든 올바른 Mesh IP로 자동 해석됩니다.
호스트 이름 기반 라우팅과 결합하면, ssh postgres-staging.mesh 또는 curl http://api-prod.mesh:3000/health와 같이 IP 주소를 알거나 관리할 필요 없이 바로 접근할 수 있습니다.
현재 Mesh 노드는 Cloudflare 에지에 인증되지만, 네트워크 계층에서는 동일한 아이덴티티를 공유합니다. 장치는 Cloudflare One Client를 통해 사용자 아이덴티티로 인증되지만, 노드는 아직 게이트웨이 정책에서 구분할 수 있는 고유하고 라우팅 가능한 아이덴티티를 가지지 않습니다.
우리는 이를 바꾸고자 합니다. 목표는 Mesh를 위한 아이덴티티 인식 라우팅입니다. 각 노드, 각 장치, 그리고 궁극적으로는 각 에이전트가 정책에서 평가할 수 있는 고유한 아이덴티티를 갖도록 하는 것입니다. 이렇게 하면 IP 대역을 기준으로 규칙을 작성하는 대신, 무엇이 또는 누가 연결하고 있는지를 기준으로 규칙을 작성하게 됩니다.
이 점은 특히 에이전트에서 가장 중요합니다. 현재 Workers에서 실행되는 에이전트가 VPC 바인딩을 통해 도구를 호출하면, 대상 서비스는 단순히 요청을 보내는 Worker만 보게 됩니다. 어떤 에이전트가 호출했는지, 누가 이를 승인했는지, 어떤 범위의 권한이 부여되었는지는 알 수 없습니다. Mesh 측에서도 마찬가지입니다. 노트북에서 실행되는 로컬 코딩 에이전트가 스테이징 서비스에 접근할 때, 게이트웨이는 사용자의 장치 아이덴티티는 확인할 수 있지만 그 에이전트 자체의 아이덴티티는 확인하지 못합니다.
우리는 에이전트가 네트워크를 통해 자체 아이덴티티를 보유하는 모델을 개발 중입니다.
책임자/후원자: 작업을 승인한 사람(플랫폼 팀의 Nikita)
에이전트: 작업을 수행하는 AI 시스템(배포 어시스턴트, 세션 #abc123)
범위: 에이전트가 수행할 수 있는 작업(배포 읽기, 롤백 트리거, 그 외에는 불허)
이를 통해 'Nikita의 에이전트에서 발생하는 읽기 작업은 허용하되, 쓰기 작업은 Nikita 본인이 직접 수행해야 한다'는 정책을 작성할 수 있습니다. 에이전트 트래픽은 사람의 트래픽과 분리하여 독립적으로 필터링할 수 있습니다. 또한 에이전트의 네트워크 액세스는 Nikita의 액세스에는 영향을 주지 않으면서 개별적으로 철회할 수 있습니다.
이를 위한 인프라는 이미 갖춰져 있습니다. Mesh 노드는 노드별 토큰으로 프로비저닝되고, 장치는 사용자별 아이덴티티로 인증되며, Workers VPC 바인딩은 서비스별로 범위가 지정된 액세스를 제공합니다. 남아 있는 마지막 조각은 이러한 아이덴티티를 정책 계층에서 볼 수 있게 만들어, 게이트웨이가 이를 바탕으로 라우팅 및 액세스 결정을 내릴 수 있도록 하는 것입니다. 그것이 바로 우리가 구축하고 있는 기능입니다.
현재 Mesh 노드는 VM과 베어메탈 Linux 서버에서 실행됩니다. 하지만 현대 인프라는 점점 Kubernetes 파드, Docker Compose 스택, 일시적으로 생성되는 CI/CD 러너 등의 컨테이너 기반으로 이동하고 있습니다. 이를 위해 우리는 어떤 컨테이너 환경에도 Mesh 노드를 추가할 수 있도록, Mesh Docker 이미지를 구축하고 있습니다.
이는 Docker Compose 스택에 Mesh 사이드카를 포함시켜, 해당 스택의 모든 서비스에 프라이빗 네트워크 액세스를 부여할 수 있음을 의미합니다. 예를 들어 스테이징 클러스터의 컨테이너에서 실행되는 마이크로서비스가 퍼블릭 엔드포인트를 노출하지 않고도 Mesh를 통해 프로덕션 VPC의 데이터베이스에 접근할 수 있습니다.
또한 빌드와 테스트 중에 프라이빗 인프라에 접근해야 하는 CI/CD 파이프라인에도 유용합니다. GitHub Actions 러너가 Mesh 컨테이너 이미지를 가져와 네트워크에 참여한 뒤, 스테이징 환경을 대상으로 통합 테스트를 실행하고 종료할 수 있습니다. VPN 자격 증명을 관리하거나 지속적인 터널을 유지할 필요가 없습니다. 컨테이너가 종료되면 해당 노드도 함께 사라집니다.
Mesh Docker 이미지는 올해 말에 제공할 수 있을 것으로 기대하고 있습니다.
이러한 아이덴티티 및 라우팅 기능은 계속 발전시키고 있지만, 안전하고 통합된 네트워킹을 위한 기반은 이미 지금 바로 사용할 수 있습니다. 몇 분 만에 클라우드 간 연결을 구축하고 에이전트를 안전하게 보호할 수 있습니다.
Cloudflare Mesh 시작하기: Cloudflare 대시보드에서 Networking > Mesh로 이동합니다. 최대 50개 노드에 사용자 50명까지 무료입니다.
Agents SDK와 Workers VPC로 에이전트 구축: Agents SDK(npm i agents)를 설치하고, Workers VPC 빠른 시작 가이드를 따라 진행한 뒤, 프라이빗 백엔드에 접근할 수 있는 원격 MCP 서버를 구축하세요.
이미 Cloudflare One을 사용하고 계신가요? Mesh는 기존 설정과 연동되어 게이트웨이 정책, 장치 상태 확인, 액세스 규칙이 Mesh 트래픽에 자동으로 적용됩니다. 첫 번째 노드를 추가하려면 Mesh 설명서를 참조하세요.