어나티픽, 클라우드 매니지드 에이전트에 자가호스팅 샌드박스 및 MCP 터널 추가

Anthropic이 Claude Managed Agents에 자체 호스팅 샌드박스(self-hosted sandboxes)와 MCP 터널(MCP tunnels)을 도입한 것은 엔터프라이즈 환경에서 AI 에이전트 도입을 가로막던 데이터 주권 및 보안 경계 문제를 정면으로 다룬 변화다. 기존 Managed Agents는 Anthropic 인프라 내부의 격리된 컨테이너에서 도구 실행(코드 실행, 파일 처리, 셸 명령 등)을 수행했기 때문에, 사내 데이터베이스나 내부 API에 접근하려면 외부로 트래픽을 노출해야 하는 부담이 있었다. 이번 업데이트로 기업은 Kubernetes나 자체 VM 위에 샌드박스 런타임을 직접 배포하고, MCP(Model Context Protocol) 서버를 자사 네트워크 안에 둔 채 Anthropic 측 에이전트 오케스트레이터와 안전한 터널로 연결할 수 있다. 다만 에이전트의 추론·계획·툴 호출 결정 자체는 여전히 Anthropic 측 컨트롤 플레인이 담당하는 하이브리드 구조이며, 실행 페이로드만 고객 인프라로 위임된다는 점이 핵심이다.

개발자 관점에서 가장 직접적인 영향은 "민감 데이터를 외부로 내보낼 수 없어 Claude 도입을 보류했던" 금융·공공·헬스케어·대기업 사내 시스템에 에이전트를 붙일 수 있는 길이 열렸다는 것이다. 예컨대 사내 GitLab, 온프레미스 Jira, VPN 내부 데이터 웨어하우스에 MCP 서버를 두고 코드 리뷰·티켓 처리·로그 분석 에이전트를 운용할 때, 자격 증명과 원본 데이터가 사내 경계를 벗어나지 않게 된다. 한국 SI/금융권에서 통상 요구하는 망분리·내부 감사 로깅·VPC 격리 요건을 만족시키기 쉬워졌고, 도구 호출 시 발생하는 네트워크 지연(latency)도 데이터가 사내 네트워크 안에서 처리되므로 줄어들 가능성이 있다. 반대로 에이전트의 핵심 의사결정 로직은 여전히 Anthropic이 쥐고 있어 완전한 self-hosting을 원했던 조직에는 절충안에 그친다는 한계도 분명하다.

엔지니어가 실무에서 점검해야 할 포인트는 크게 세 가지다. 첫째, 자체 샌드박스를 운영하려면 컨테이너 격리(gVisor·Firecracker급), 시크릿 관리, 네트워크 정책(egress 화이트리스트)을 직접 책임져야 하므로, 단순히 컨테이너만 띄우는 게 아니라 "신뢰할 수 없는 코드가 도는 실행 환경"으로 설계해야 한다. 둘째, MCP 터널은 본질적으로 Anthropic 컨트롤 플레인에서 사내로 들어오는 inbound 채널이므로 인증·인가·요청 감사 로그를 어떻게 남길지, 어떤 MCP 도구에 어떤 권한을 부여할지(least privilege) 사전에 정책으로 정의해야 한다. 셋째, 컨트롤 플레인이 외부에 있다는 사실은 그대로이므로 프롬프트·툴 호출 메타데이터·툴 출력 요약 등이 여전히 외부로 흐를 수 있어, 보안 검토 시 "어떤 데이터가 어디까지 나가는가"를 데이터 분류 기준에 맞춰 다시 매핑하는 작업이 필요하다. 도입을 검토 중이라면 PoC 단계에서 네트워크 다이어그램과 데이터 흐름도를 먼저 확정하고, 사내 보안팀과 함께 위협 모델을 점검하는 것이 안전하다.