Claude 에이전트 사설망 진입, 손은 안쪽에 두는 설계

AI 요약

• 무슨 일: Anthropic이 Claude Managed Agents에 사설 샌드박스와 MCP 터널을 추가했습니다.
  • 샌드박스는 public beta, MCP 터널은 research preview입니다.
• 핵심 구조: 에이전트 루프는 Anthropic에 남고, 파일시스템과 셸 실행은 고객 인프라로 이동합니다.
• 실무 영향: 내부 API와 저장소를 붙이기 쉬워졌지만, 감사 로그와 권한 경계는 양쪽 시스템에 걸쳐 설계해야 합니다.
  • 특히 MCP 서버 호출의 schema, 승인 상태, trace ID를 로컬 경계에서 남기는 일이 중요해집니다.

Anthropic이 2026년 5월 19일 Claude Managed Agents에 두 가지 인프라 기능을 붙였습니다. 하나는 self-hosted sandboxes입니다. Claude 에이전트가 파일을 읽고, 명령을 실행하고, 네트워크로 나가는 “손”을 Anthropic 관리 컨테이너가 아니라 기업이 통제하는 환경에서 움직이게 합니다. 다른 하나는 MCP tunnels입니다. 사설망 안에 있는 Model Context Protocol 서버를 공개 엔드포인트로 열지 않고 Claude가 도구처럼 호출하게 하는 통로입니다.

겉으로 보면 보안 기능 업데이트입니다. 하지만 이번 발표의 더 중요한 지점은 에이전트 플랫폼의 책임 경계를 새로 그었다는 데 있습니다. Anthropic은 agent loop, orchestration, context management, error recovery를 계속 가져갑니다. 반대로 tool execution, filesystem, runtime image, network egress, 내부 서비스 접근은 고객 인프라 또는 고객이 선택한 샌드박스 공급자 쪽으로 이동합니다. 기업 입장에서는 “완전 셀프호스팅”도 아니고 “모든 것을 Anthropic 컨테이너에 맡기는 managed 서비스”도 아닌 중간 모델이 생긴 셈입니다.

공식 발표는 이 구조를 꽤 직설적으로 설명합니다. Claude Managed Agents는 이제 기업이 통제하는 샌드박스에서 작동하고, 비공개 MCP 서버에 연결할 수 있습니다. 샌드박스와 연결되는 서비스가 기업의 기존 보안 경계, 런타임 제어, 네트워크 정책 안에 들어온다는 메시지입니다. self-hosted sandboxes는 Claude Platform의 public beta이고, MCP tunnels는 접근 신청이 필요한 research preview입니다.

Managed Agents가 먼저 나눈 두뇌와 손

이 업데이트를 이해하려면 4월에 Anthropic이 Managed Agents를 설명한 방식부터 봐야 합니다. Anthropic Engineering은 Managed Agents를 장기 실행 에이전트를 위한 hosted service로 소개하면서, harness가 모델의 능력 변화에 맞춰 계속 바뀐다고 설명했습니다. 예로 든 것이 “context anxiety”입니다. 이전 모델에서는 context limit이 가까워질 때 일을 너무 일찍 마무리하려는 행동을 줄이기 위해 context reset을 harness에 넣었지만, Claude Opus 4.5에서는 그 문제가 사라져 해당 장치가 오히려 불필요한 무게가 됐다는 설명입니다.

여기서 Anthropic이 얻은 결론은 명확합니다. 에이전트 harness를 각 개발팀이 직접 고정된 방식으로 짜면 모델이 바뀔 때마다 낡습니다. 그래서 agent loop와 recovery를 Anthropic이 운영하고, 개발자는 session, tool, outcome 같은 안정적인 인터페이스에 맞춰 장기 작업을 보내는 구조가 Managed Agents의 핵심이었습니다.

문제는 이 구조가 기업 보안팀에게 곧바로 통과되기 어렵다는 점입니다. 장기 실행 에이전트가 실제 업무를 하려면 저장소, 내부 문서, 비공개 API, 데이터베이스, 티켓 시스템, 빌드 시스템에 접근해야 합니다. 하지만 이런 자원은 대개 사설망 안에 있고, 파일과 로그는 규제나 고객 계약 때문에 외부 실행 환경으로 나가기 어렵습니다. 모델은 cloud service로 쓸 수 있어도, 에이전트가 손대는 runtime까지 밖으로 보내는 것은 별개의 이야기입니다.

이번 self-hosted sandboxes는 그 긴장을 줄이려는 시도입니다. Claude가 무엇을 할지 결정하는 orchestration은 Anthropic 쪽에 남습니다. 그러나 명령 실행, 파일 접근, 패키지 설치, 빌드, 네트워크 egress는 고객이 제어하는 sandbox worker 안에서 일어납니다. 공식 문서는 이를 “orchestration은 Anthropic에 남지만 agent code, filesystem, network egress는 고객 환경을 떠나지 않는다”는 구조로 정리합니다.

샌드박스는 단순한 컨테이너 선택지가 아닙니다

Anthropic은 self-hosted sandboxes를 고객이 직접 운영하는 환경뿐 아니라 Cloudflare, Daytona, Modal, Vercel 같은 공급자와 연결했습니다. 이것은 단순한 파트너 로고 나열이 아닙니다. 에이전트 런타임 시장이 어떤 단위로 쪼개지는지를 보여줍니다.

Cloudflare는 Sandboxes, Agents SDK, Browser Run, Dynamic Workers를 묶어 에이전트 실행 인프라를 강조합니다. Cloudflare 공식 글은 Claude Managed Agents와의 통합으로 샌드박스 제어, 사설 서비스 연결, observability를 강화한다고 설명합니다. 특히 full stateful Linux microVM뿐 아니라 더 가볍고 빠른 V8 isolate 기반 backend를 선택할 수 있다고 말합니다. 개발자처럼 전체 애플리케이션을 빌드하고 Linux 도구를 돌려야 하면 microVM이 맞지만, 수만 개 concurrent agent burst를 처리하려면 isolate가 유리하다는 주장입니다.

Daytona는 long-running composable computer에 가까운 모델을 내세웁니다. Anthropic 발표는 Clay의 GTM engineering agent가 Daytona 샌드박스에서 파일 스토어를 mount하고 패키지를 즉석 설치하는 사례를 언급합니다. Modal은 AI workload platform답게 CPU와 GPU 자원을 온디맨드로 붙이는 쪽에 초점이 있습니다. Vercel은 VM security, VPC peering, bring your own cloud, millisecond startup, network boundary에서의 credential injection을 강조합니다.

이 차이는 에이전트 제품을 만드는 팀에게 중요합니다. “Claude가 우리 코드를 실행한다”는 문장은 실제로는 여러 질문으로 나뉩니다. 세션마다 깨끗한 filesystem이 필요한가, 장기 작업 상태를 보존해야 하는가, 빌드 캐시를 재사용해야 하는가, 내부 네트워크에 붙어야 하는가, 브라우저 자동화가 필요한가, GPU가 필요한가, 고객별 runtime image를 격리해야 하는가. self-hosted sandboxes는 Anthropic이 이 모든 조합을 직접 책임지는 대신, 실행면을 샌드박스 공급자와 고객 운영체계 쪽에 열어 놓은 것입니다.

공식 문서도 cloud environment와 self-hosted sandbox를 네 가지 기준으로 비교합니다. cloud environment에서는 도구가 Anthropic-managed containers에서 실행되고, 네트워크 reach와 파일 mount, lifecycle도 Anthropic이 관리합니다. self-hosted sandbox에서는 도구가 고객 인프라에서 실행되고, 네트워크 정책, repo mount, lifecycle은 고객이 관리합니다. 이 표가 이번 발표의 핵심입니다. 에이전트의 지능을 어느 회사 모델에 맡길지와, 에이전트의 실행 권한을 어느 경계에 둘지는 분리 가능한 결정이 됐습니다.

MCP 터널은 “도구 공개”가 아니라 “통로 위임”입니다

두 번째 기능인 MCP tunnels는 더 민감한 문제를 다룹니다. MCP는 모델과 외부 도구를 연결하는 표준으로 빠르게 퍼졌지만, 기업 환경에서 가장 어려운 부분은 “도구 서버를 어디에 둘 것인가”입니다. 내부 티켓 시스템, billing API, 고객 데이터베이스, 보안 스캐너를 MCP 서버로 감싸도, 그 서버를 인터넷에 공개하면 다른 문제가 생깁니다. VPN, allowlist, reverse proxy, OAuth, secret rotation, audit log를 모두 엮어야 합니다.

Anthropic의 MCP tunnels는 이 문제를 outbound-only connection으로 풀려 합니다. 고객 네트워크 안에 작은 tunnel stack을 배포하고, 이 stack이 Anthropic-operated tunnel edge와 바깥 방향 연결을 맺습니다. Anthropic 문서는 이 구조 덕분에 인바운드 방화벽 포트를 열거나, MCP 서버를 공개 인터넷에 노출하거나, origin에서 Anthropic IP range를 allowlist하지 않아도 된다고 설명합니다.

보안 계층도 흥미롭습니다. 공식 문서는 outer mTLS, inner TLS, MCP 서버별 OAuth를 독립 계층으로 둡니다. transport는 Cloudflare 네트워크를 쓰지만, inner TLS는 고객이 보유한 인증서로 proxy에서 종료됩니다. 따라서 Cloudflare는 request와 response payload를 읽을 수 없고, 대신 cloudflared host의 egress IP, host fingerprint, 연결 시점, byte volume, 할당된 tunnel subdomain 같은 metadata는 볼 수 있다고 설명합니다. 이 지점은 “완전히 안 보인다”가 아니라 “payload와 metadata의 경계가 다르다”로 읽어야 합니다.

MCP tunnels는 Managed Agents뿐 아니라 Messages API에서도 지원됩니다. 즉 Anthropic이 보는 MCP의 위치는 단지 에이전트 플랫폼 내부 기능이 아니라, Claude API 전체의 사설 도구 연결 계층입니다. self-hosted sandboxes와도 독립적입니다. Anthropic 문서는 Anthropic cloud container에서 실행되는 session도 tunnel을 통해 private MCP server에 접근할 수 있고, self-hosted session도 tunneled MCP server나 public MCP server를 사용할 수 있다고 말합니다. 둘을 함께 쓰면 실행과 도구 접근을 모두 기업 경계 안에 더 가깝게 둘 수 있습니다.

좋은 소식은 보안팀이 볼 표면이 생겼다는 것

개발팀 입장에서 이번 업데이트의 장점은 분명합니다. 내부 저장소를 clone하고, 비공개 패키지를 설치하고, 사내 API를 호출하고, 장기 빌드를 돌리는 에이전트를 만들 때 “모든 데이터를 Anthropic container로 보내도 되는가”라는 질문을 줄일 수 있습니다. 네트워크 egress를 기존 프록시로 통제하고, sandbox image를 사내 표준에 맞추고, runtime log를 내부 SIEM으로 보내고, 고객별 환경을 격리하는 설계가 가능해집니다.

특히 AI 에이전트는 전통적인 API 클라이언트보다 더 넓은 실행면을 가집니다. 단일 요청과 응답으로 끝나지 않고, repository를 읽고, 테스트를 돌리고, 실패를 해석하고, 다른 도구를 호출하고, 결과물을 저장합니다. 이런 시스템에서 “모델이 무슨 결정을 내렸는가”와 “그 결정이 어떤 권한으로 실제 실행됐는가”는 다른 감사 질문입니다. self-hosted sandbox는 후자의 표면을 고객 쪽에 돌려줍니다.

그러나 이것이 모든 보안 문제의 해답이라는 뜻은 아닙니다. 오히려 운영자가 설계해야 할 로그 상관관계가 늘어납니다. agent loop는 Anthropic에 있고, tool execution은 고객 sandbox에 있고, MCP server는 사설망 안에 있으며, tunnel transport는 Cloudflare 네트워크를 경유할 수 있습니다. 사고가 났을 때 “어떤 prompt와 tool schema가 어떤 MCP 호출로 이어졌고, 어떤 사용자 또는 policy가 그것을 승인했는가”를 복원하려면 여러 시스템의 trace를 맞춰야 합니다.

Reddit의 MCP 커뮤니티에서도 이 지점이 나왔습니다. agent loop가 Anthropic에 남으면 의사결정 context, 모델 revision, prompt template, retrieval hit 같은 흔적은 Anthropic trace에 있고, credential use와 tool execution은 로컬 시스템에 남습니다. 나중에 특정 refund, access change, code push가 왜 발생했는지 감사하려면 두 쪽 로그를 이어야 합니다. 실무적으로는 로컬 MCP 서버 경계에서 resolved tool schema, parent span ID, 승인 정책, redacted arguments를 남기는 설계가 필요합니다.

“사설망 진입”보다 중요한 것은 종속성의 모양입니다

이번 발표는 Anthropic이 enterprise agent stack에서 더 깊은 층으로 내려오고 있음을 보여줍니다. 최근 Stainless 인수는 SDK와 MCP server generation, 즉 API 연결 배관을 강화하는 움직임이었습니다. Managed Agents는 장기 실행 에이전트의 orchestration을 Anthropic이 잡는 제품입니다. self-hosted sandboxes와 MCP tunnels는 그 orchestration이 기업 내부 데이터와 런타임을 만나는 경계입니다.

이 조합은 강력하지만, 공급자 종속성 질문도 같이 불러옵니다. 완전히 자체 호스팅하는 LangGraph나 사내 agent runner를 쓰면 agent loop, trace, execution, tool gateway를 모두 직접 운영할 수 있습니다. 대신 session recovery, long-horizon orchestration, prompt caching, 모델 변화에 맞춘 harness 개선, managed event stream을 직접 책임져야 합니다. Anthropic Managed Agents를 쓰면 이 부분을 서비스로 가져오지만, agent loop와 일부 decision trace는 Anthropic 쪽에 남습니다.

따라서 선택지는 “보안이 좋다, 나쁘다”로 단순화하기 어렵습니다. 더 정확한 질문은 “어떤 경계를 누구에게 맡길 것인가”입니다. 모델 호출과 agent loop를 Anthropic에 맡기고 싶은가. filesystem과 shell은 사내 runner에서만 돌리고 싶은가. MCP 서버는 공개 endpoint가 아니라 outbound tunnel로만 열 것인가. Cloudflare, Daytona, Modal, Vercel 같은 sandbox provider가 운영 경계 안에 들어와도 되는가. Claude Platform on AWS를 쓰는 조직이라면 self-hosted sandboxes가 아직 지원되지 않는 제한을 어떻게 볼 것인가.

기업 AI 팀에게는 이 질문이 곧 아키텍처 검토 항목이 됩니다. 에이전트가 내부 API를 호출할 수 있다면, API gateway는 agent identity를 사람 계정과 분리해야 합니다. 에이전트가 repository에 접근한다면, branch protection과 commit signing, secret scanning이 같이 움직여야 합니다. 에이전트가 사내 데이터베이스를 읽는다면, row-level policy와 query audit가 MCP tool 단위로 보존돼야 합니다. 에이전트가 장기 작업을 수행한다면, session timeout과 human approval checkpoint도 별도 설계해야 합니다.

개발자가 지금 확인할 체크포인트

첫째, self-hosted sandbox가 필요한 작업과 cloud environment로 충분한 작업을 분리해야 합니다. 공개 패키지와 임시 파일만 다루는 분석 작업은 Anthropic-managed container가 더 단순할 수 있습니다. 반대로 사내 repository, private package registry, internal service, 규제 데이터, 고객별 credential을 다루면 self-hosted sandbox가 검토 대상입니다.

둘째, MCP tunnel을 “내부 API를 쉽게 여는 기능”으로만 보면 위험합니다. tunnel token, TLS private key, MCP server OAuth 설정은 모두 high-value secret입니다. 공식 문서도 token과 TLS private key가 함께 유출되면 proxy impersonation과 payload 노출 위험이 있다고 경고합니다. tunnel 도입은 네트워크팀과 보안팀의 인증서 관리, rotation, proxy access log 정책까지 포함해야 합니다.

셋째, trace 상관관계를 제품 요구사항으로 넣어야 합니다. 에이전트가 어떤 tool을 호출했는지 보는 것만으로는 부족합니다. 어떤 agent session, 어떤 model configuration, 어떤 tool schema version, 어떤 user request, 어떤 approval state에서 호출됐는지 로컬 시스템에서도 식별할 수 있어야 합니다. MCP server가 단순히 “요청을 처리했다”가 아니라 “어떤 에이전트 권한으로 무엇이 허가됐는지”를 남겨야 합니다.

넷째, sandbox provider 선택은 비용과 성능만의 문제가 아닙니다. microVM과 isolate의 격리 수준, startup time, long-running state, SSH 접근, preview URL, VPC peering, secret injection, egress proxy, log export, region control이 모두 다릅니다. 에이전트가 코딩 도우미인지, 내부 업무 자동화인지, 금융 분석 agent인지, 브라우저를 운전하는 QA agent인지에 따라 맞는 런타임이 달라집니다.

에이전트 플랫폼 경쟁은 모델 밖에서 벌어집니다

이번 뉴스의 의미는 Claude가 더 많은 도구를 호출하게 됐다는 수준을 넘습니다. 2026년의 에이전트 경쟁은 모델 성능만으로 설명하기 어렵습니다. 실제 제품에서 병목은 long-running session, sandbox, credential, private network, observability, audit, recovery, cost control로 옮겨가고 있습니다. Anthropic은 Managed Agents로 agent loop를 잡고, Stainless로 SDK와 MCP 배관을 품고, 이번 업데이트로 실행 경계와 사설 도구 연결까지 넓히고 있습니다.

다만 “기업 경계 안에서 실행된다”는 문장을 그대로 받아들이면 안 됩니다. 이번 설계는 분업입니다. 두뇌는 Anthropic에 남고, 손은 고객 인프라로 갈 수 있으며, 사설 도구는 outbound tunnel로 연결됩니다. 이 분업은 실용적입니다. 동시에 감사와 책임도 분업됩니다. Claude가 왜 그렇게 판단했는지, sandbox가 무엇을 실행했는지, MCP 서버가 어떤 권한으로 응답했는지, transport provider가 어떤 metadata를 보았는지를 각각 확인해야 합니다.

그래서 이번 발표를 도입 검토할 때 가장 먼저 볼 것은 기능 데모가 아닙니다. 내부 보안 경계도입니다. 어떤 데이터가 Anthropic으로 가고, 어떤 파일이 sandbox에 남고, 어떤 credential이 tunnel proxy와 MCP server에 있고, 어떤 로그가 어느 시스템에 저장되는지를 그려야 합니다. 그 그림이 명확하다면 Claude Managed Agents의 새 기능은 기업 에이전트를 훨씬 현실적인 배포 단계로 끌어올릴 수 있습니다. 그 그림이 없다면, 사설망 진입은 통제 강화가 아니라 복잡성 증가가 될 가능성이 큽니다.

출처: Anthropic 공식 발표, self-hosted sandboxes 문서, MCP tunnels 문서, Cloudflare 통합 발표, Managed Agents 엔지니어링 글.