🔥 Cloudflare Mesh, 에이전트가 사설망을 쓰는 방식이 바뀌었다

출처: Cloudflare Blog

어젯밤에 Claude Code에게 스테이징 DB에 있는 로그 한 덩어리를 조회하게 하려고 30분을 날렸다. VPN을 켜면 내 노트북 전체 트래픽이 사내망으로 들어가버리고, 켜지 않으면 에이전트가 사설 IP에 닿을 수가 없다. 포트를 뚫자니 찝찝하고, 터널을 파자니 에이전트가 쓰기엔 너무 번거롭다. 결국 로그를 직접 scp로 내려받아서 에이전트한테 파일로 넘겨줬다. 이게 2026년의 개발 경험이라는 게 조금 웃겼다.

그래서 오늘 아침, Cloudflare가 Agents Week 2026 둘째 날에 내놓은 Cloudflare Mesh 발표를 읽으면서 제일 먼저 든 생각은 "이거 딱 내 어제 문제잖아"였다.

무슨 일이 있었나

2026년 4월 14일, Cloudflare가 Cloudflare Mesh를 공식 발표했다(verified 2026-04-15). 표면적으로는 기존 WARP Connector의 리브랜딩이다. WARP Connector는 이제 "Cloudflare Mesh node"가 됐고, WARP Client는 "Cloudflare One Client"가 됐다. 이름만 바뀐 것처럼 들리는데, Cloudflare의 제품명 업데이트 공지를 읽어보면 계정당 노드 상한이 기존 10개에서 50개로 뛰었고, Networking > Mesh 대시보드에 인터랙티브 네트워크 맵과 셋업 위저드가 생겼다.

즉, 기능적으론 멀쩡히 돌아가던 사이트-투-사이트 VPN 대안에, 에이전트라는 새로운 사용자를 정면으로 얹은 리패키징이다.

왜 이 얘기가 지금 나왔나

Agents Week 자체가 Cloudflare의 2026년 메가 베팅이다. Sandboxes GA, Artifacts, Durable Object Facets, Workers VPC 확장, Mesh까지 전부 같은 주에 쏟아졌다. 공통 주제는 하나다. "에이전트한테 사람 개발자가 쓰던 인프라를 그대로 주자."

문제는 사람 개발자한테 만들어진 사설망 도구가 에이전트한테 잘 안 맞는다는 점이다. VPN은 사람이 클릭해서 로그인하는 걸 가정하고, SSH 터널은 수동 설정을 가정한다. 반대로 퍼블릭으로 노출하는 건 보안 리스크고, 감사 추적도 빈약하다. Cloudflare는 발표 글에서 세 가지 시나리오를 꼽았다.

• 집 맥미니에서 돌아가는 개인 에이전트를 휴대폰으로 접속
• 노트북의 Claude Code, Cursor, Codex가 스테이징 DB·API를 조회
• Workers 위에 배포된 에이전트가 내부 API와 MCP 서버를 호출

세 케이스 전부 한 가지 공통점이 있다. 사람 대신 자율 소프트웨어가 사설망에 들어가려 한다.

구조: 한 줄기로 정리

핵심 구성은 세 덩어리다.

Mesh 노드. 서버, VM, 컨테이너에 헤드리스 Cloudflare One Client를 깔면 Mesh IP를 하나 받는다. 노드끼리는 서로 사설 IP로 쌍방향 통신한다.

디바이스. 노트북·폰에 Cloudflare One Client를 깔면 Mesh에 합류한다. 로컬 에이전트가 이걸 타고 사설 자원에 닿는다.

Workers 위 에이전트. Workers VPC 네트워크 바인딩으로 Mesh 전체에 접근한다. 범위는 바인딩 단위로 좁혀지고, MCP 서버가 실제 도구 권한을 한 번 더 게이팅한다.

출처: Cloudflare Blog

모든 트래픽은 Cloudflare의 330+ 도시 엣지를 경유한다. 이게 다른 메시 VPN과 가장 크게 갈리는 지점이다. Tailscale은 원칙적으로 피어-투-피어 직접 연결을 선호한다. NAT 뒤에 있으면 DERP 릴레이로 폴백하는데, 릴레이 숫자가 한정적이면 전체 트래픽의 일정 비율이 그쪽을 타게 된다. Cloudflare는 아예 엣지 자체를 릴레이로 쓰는 쪽을 택했다. 레이턴시 관점에선 살짝 손해 볼 수 있지만, NAT 트래버설 실패로 인한 "간헐적 느림"을 구조적으로 없앤다.

개발자 입장에서 진짜 재밌는 부분: Workers VPC 바인딩

Mesh 발표의 실질적인 뉴스는 Workers VPC가 Mesh 전체를 하나의 바인딩으로 받을 수 있게 됐다는 점이다. wrangler.jsonc에 이렇게 적는다.

"vpc_networks": [
  { "binding": "MESH", "network_id": "cf1:network", "remote": true },
  { "binding": "AWS_VPC", "tunnel_id": "350fd307-...", "remote": true }
]

"vpc_networks": [
  { "binding": "MESH", "network_id": "cf1:network", "remote": true },
  { "binding": "AWS_VPC", "tunnel_id": "350fd307-...", "remote": true }
]

cf1:network이라는 예약 키워드가 "너희 계정의 Mesh 네트워크 전부"를 가리킨다. 그다음 Worker 코드에서 이렇게 쓴다.

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    const apiResponse = await env.MESH.fetch("http://10.0.1.50/api/data");
    const dbResponse = await env.AWS_VPC.fetch(
      "http://internal-db.corp.local:5432"
    );
    return new Response(await apiResponse.text());
  },
};

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    const apiResponse = await env.MESH.fetch("http://10.0.1.50/api/data");
    const dbResponse = await env.AWS_VPC.fetch(
      "http://internal-db.corp.local:5432"
    );
    return new Response(await apiResponse.text());
  },
};

기존 Workers VPC는 Cloudflare Tunnel 단위로 바인딩을 걸었다. 하나의 터널 = 하나의 사설 자원 앞단이라 에이전트가 여러 서비스를 돌아가며 호출하려면 바인딩을 여러 개 정의해야 했다. cf1:network은 그걸 네트워크 단위로 한 번에 끌어안는다. 사내에 호스트가 추가돼도 wrangler 설정을 다시 밀 필요가 없다. Agents SDK 기반 에이전트한테 이 바인딩을 넘기면, 그 에이전트는 사실상 사내망 안에 앉아 있는 셈이 된다.

Agents SDK는 v0.6.0에서 MCP용 RPC 트랜스포트와 OAuth 옵션화까지 들어갔다. Mesh 바인딩과 합치면 "에이전트 ↔ MCP 서버 ↔ 사설 DB"라는 전형적인 체인이 HTTP 노출 없이 Cloudflare 안쪽에서만 돈다.

Tunnel하고는 뭐가 다른가

Cloudflare 자신이 구분점을 명확히 해뒀다.

• Tunnel: 엣지 → 사설 서비스로 향하는 단방향 프록시. 웹 서버, HTTP API 한두 개 노출할 때.
• Mesh: 모든 노드·디바이스가 서로 사설 IP로 접속하는 쌍방향, N:N 네트워크.

에이전트 워크로드는 거의 대부분 쌍방향이다. 에이전트가 서비스를 부르고, 서비스가 이벤트를 발행하고, 다른 에이전트가 그걸 구독하는 식. 그래서 이 발표가 에이전트 얘기로 포장될 수밖에 없다.

남은 숙제: 정체성과 DNS

읽다 보면 Cloudflare 스스로도 지금 단계가 완성이 아니라고 인정한다. 올해 안에 들어올 예정인 것들이 세 가지다.

호스트네임 라우팅. 지금은 ssh 100.64.0.5처럼 Mesh IP로 쳐야 한다. 올여름 중 Tunnel의 호스트네임 라우팅이 Mesh에도 확장돼, wiki.local 같은 이름을 노드가 직접 흡수할 수 있게 된다.

Mesh DNS. 노드가 합류하면 자동으로 postgres-staging.mesh 같은 내부 호스트네임이 붙는다. DNS 수동 관리 없이 curl http://api-prod.mesh:3000/health가 된다.

아이덴티티 기반 라우팅. 이건 솔직히 제일 흥미로운 부분이다. 지금은 Mesh 노드가 네트워크 계층에서 "우리 편"이라는 한 덩어리로 인증된다. Cloudflare가 목표로 하는 건 Principal(사람) / Agent(에이전트) / Scope(권한) 세 축을 노드·디바이스·요청마다 붙이는 것. "Nikita의 에이전트가 보낸 읽기 요청은 허용하되, 쓰기 요청은 Nikita 본인만"이라는 식의 정책이 Gateway에서 평가된다.

AI 에이전트를 프로덕션에 꽂아본 사람은 알겠지만, "이 요청이 누가 시킨 건지"를 네트워크 레이어까지 관통시키는 게 실제로 가장 귀찮다. 지금은 대부분 앱 레이어에서 토큰에 사용자 정보를 밀어넣고, 서비스가 그걸 풀어서 확인하는 식으로 돌린다. Cloudflare가 네트워크 레이어에서 이걸 처리해준다면 MCP 서버가 "누가 부르는지 모르는 상태"로 사는 시간을 줄여준다. 다만 "working toward"라고 써놨으니 당장 기대할 건 아니다.

한계와 현실적 경계

공짜 층위(50노드/50유저)는 개인 홈랩과 스몰 팀한테 충분히 쓸 만하다. 하지만 팀이 커지고 정책이 섬세해질수록 Cloudflare One의 상위 플랜을 타게 된다. "나는 그냥 Mesh만 쓰면 된다"라고 생각하다가 Gateway 정책, DLP, Access for Infrastructure가 엮여오는 경로는 꽤 자연스럽게 깔려 있다. 이건 Cloudflare의 설계 의도이기도 하고, 소비자 입장에선 락인 리스크이기도 하다.

또 하나. Mesh는 Cloudflare 엣지 경유가 기본이라 엣지가 없는 지역에선 퍼포먼스가 떨어질 수 있다. The New Stack의 분석도 같은 지적을 한다. 국내 단일 리전 내 서비스라면 Tailscale의 직접 P2P가 여전히 더 빠를 수 있다. 제품 선택은 내 팀이 어디에 있는지, 크로스 리전 트래픽 비중이 얼마나 되는지에 달렸다.

내가 실제로 해볼 것

이번 주말에 집에 굴리고 있는 미니 PC에 Cloudflare Mesh node를 깔아볼 생각이다. 맥미니 쪽 Claude Code가 거기를 사설 IP로 바라보게 만들고, 주말 사이드 프로젝트의 스테이징 DB를 거기 얹어서 에이전트가 직접 쿼리하는 경험이 얼마나 덜 번거로운지 보려고 한다. VPN 토글을 켜고 끄던 어제의 경험이 싫었으니까.

아직 프로덕션 스케일에서 얼마나 견디는지는 나도 확신이 없다. Tailscale을 2년 넘게 쓰고 있는 입장에서, 라우팅 일관성을 Cloudflare의 엣지에 맡기는 게 장기적으로 어떤 트레이드오프인지 좀 더 지켜봐야 한다. 다만 에이전트가 사설 자원에 닿는 경로가 "VPN, 터널, 포트 포워딩 중 하나 고르기"에서 "한 줄짜리 바인딩"으로 바뀌는 방향 자체는 이미 바꿀 수 없는 흐름 같다.

참고 자료

• Secure private networking for everyone — introducing Cloudflare Mesh (Cloudflare Blog) — 원문 발표 글, 아키텍처와 cf1:network 바인딩 예제 포함
• Cloudflare Mesh 공식 문서 — 셋업 가이드와 노드 관리 레퍼런스
• Cloudflare One in 2026: Product Name Updates — WARP Connector/Client 리네이밍 공식 공지
• Workers VPC Get Started — vpc_networks 바인딩 설정 공식 레퍼런스
• Beyond the VPN: Cloudflare Mesh builds a private network for the age of AI agents (The New Stack) — 제3자 분석, 타 메시 VPN과의 비교 관점
• Agents SDK v0.6.0 Changelog — MCP RPC 트랜스포트, OAuth 옵션화 변경점
• Agents Week 2026 Updates — 같은 주에 발표된 Sandboxes GA, Artifacts 등 전체 맥락