Claude Managed Agents: 모델 회사가 직접 그은 로컬과 호스팅의 경계

TL;DR. Claude Managed Agents는 모델 회사 자신이 로컬 평면과 호스팅 평면을 다른 거버넌스 평면으로 쪼갠 자리다. 2026-04-08 public beta, managed-agents-2026-04-01 베타 헤더로 모든 API 계정에 기본 활성, 표준 토큰 요금 + $0.08/session-hour. 로컬 Claude 스택과 동시 운영하면 즉시 7가지 충돌이 등장한다 — agent 정의·권한·메모리·감사·신뢰 경계·키 blast radius·Claude Platform on AWS 3중 교차. AWS Agent Registry가 서로 다른 벤더 사이의 마찰이라면, 여기서는 한 벤더가 자기 손으로 호스팅 평면과 로컬 평면의 경계를 그었다. 단일 정본·인증/권한 정합성·라이프사이클, 세 군데가 호스팅 평면에서 똑같이 깨진다. 가장 정합적이어야 할 같은 벤더 자리에서 단일 정본 결정이 가장 먼저 깨진다.

왜 지금 다뤄야 하는가

이번 분기에 로컬 Claude 스택을 쓰던 모든 팀이 로컬 vs 호스팅 거버넌스 결정을 강요받는다 — 선택지가 아니라 이미 켜져 있기 때문이다. Claude Managed Agents는 2026-04-08 public beta로 출시됐고, managed-agents-2026-04-01 베타 헤더가 전 엔드포인트에 필수이지만 SDK가 이를 자동 설정하므로 모든 API 계정에 기본 활성이다. 가격도 진입 장벽이 아니다 — 표준 Claude API 토큰 요금에 세션당 $0.08/session-hour만 더해진다. 거버넌스 인덱스가 정리한 "2026년 4월 양대 클라우드·양대 모델사 동시 진입" 중, 이 글은 모델 회사 자신이 내놓은 답을 다룬다.

Claude Managed Agents는 무엇인가

Claude Managed Agents는 에이전트 루프·샌드박스·툴 실행·세션 영속을 Anthropic 인프라에 위탁하는 호스팅 에이전트 런타임이다. 네 개의 핵심 개념으로 구성된다.

핵심 운영 모델은 단순하다 — agent를 한 번 만들어 ID를 받고, 세션마다 그 ID로 참조한다. agent 정의는 봉인되고 세션은 그 봉인을 가리킬 뿐이다. 모델은 Sonnet 4.6 / Opus 4.6 / Haiku 4.5 중 선택한다.

이 자리는 에이전트 실행과 영속을 누가 호스팅하느냐의 문제다 — 에이전트를 누가 등록·발견·승인하느냐(AWS Agent Registry가 다룬 면)와는 다른 질문이다. 같은 거버넌스 지형의 서로 다른 면이다.

핵심 5개 기능

1. 호스팅 하네스. 에이전트 루프·sandbox·tool 실행·세션 영속을 전부 Anthropic이 위탁받아 돌린다. 직접 오케스트레이션 인프라를 운영할 필요가 없다. 샌드박스는 gVisor userspace syscall 인터셉션 + process manager + 네트워크 방화벽의 3중 격리로 봉인된다.
2. vault 크리덴셜 프록시. 시크릿이 샌드박스 안으로 들어오지 않는다 — tool 호출 시점에 server-side에서 주입된다. 그래서 prompt injection으로 크리덴셜을 빼내는 경로가 구조적으로 차단된다. 단, env var·system prompt·mounted file에 하드코딩된 토큰은 이 프록시를 우회한다.
3. append-only event log. 앱↔에이전트 메시지가 컨테이너 밖에 append-only로 쌓여, harness가 재시작돼도 살아남는다. 감사 레코드가 실행 환경의 수명과 분리된다.
4. 권한 비대칭. 빌트인 8툴(agent_toolset_20260401: bash·read·write·edit·glob·grep·web_search·web_fetch)은 디폴트 always_allow로 자동 실행되는 반면, MCP 툴은 디폴트 always_ask로 호출마다 승인을 받는다. 신뢰가 둘로 갈린다.
5. Claude Platform on AWS 동시 제공. 같은 기능이 Claude Platform on AWS에서도 제공된다. 단, feature·session 동작에 차이가 있다.

로컬 Claude 스택과 동시 운영 시 충돌 7가지

광고용 장점은 Anthropic 공식 문서가 잘 정리해 두었으므로, 여기서는 로컬 Claude 스택과 같이 굴릴 때 구조적으로 필연인 마찰에 집중한다 — 동시 설치를 직접 돌려 본 관찰이 아니라, 양쪽 문서·정의·권한 모델을 읽고 설계상 부딪치는 지점만 짚는다.

1. agent 정의의 정본이 두 곳으로 갈린다. 로컬 평면은 AGENTS.md·.claude/skills·로컬 MCP·Memory tool에 정의가 흩어져 있고 즉시 편집을 전제한다. 호스팅 평면은 model·system prompt·tools·MCP 서버·skills를 한 번 묶어 agent ID로 봉인하고, 세션은 그 봉인을 가리킬 뿐이다. 같은 에이전트를 양쪽에 두면 어느 정의가 정본인가에 답이 없다 — 한쪽을 고치면 다른 쪽이 모른다. 이게 추측이 아님은 같은 회사가 직접 그은 경계가 증명한다. Anthropic 브랜딩 가이드는 "Claude Agent"는 허용하되 "Claude Code"·"Claude Cowork" 명칭·ASCII·시각 요소 모방을 금지한다 — 같은 벤더가 제품 경계를 명시적으로 그었다는 것은 두 평면을 하나로 통합할 의도가 없다는 신호다. 정합적이어야 할 같은 벤더 자리에서 단일 정본이 가장 먼저 깨진다.
2. 권한 게이트가 평면마다 다른 모델로 작동한다. 호스팅 빌트인 8툴(agent_toolset_20260401)은 디폴트 permission_policy: always_allow로 확인 없이 자동 실행되고, MCP 툴은 디폴트 always_ask다. 로컬 Claude Code는 settings.json의 allow/deny 목록 + 사용자 확인으로 게이트를 건다. 같은 MCP 서버를 양쪽에 물리면 권한 결정이 두 개의 분리된 모델을 통과한다 — 로컬에서 deny한 동작이 호스팅에서는 always_allow일 수 있고, 그 차이는 호출 시점까지 보이지 않는다. 한 호출 경로에 두 권한 모델이 겹치면 누락이 생긴다.
3. 세션 간 학습의 정본도 두 곳에 누적된다. 로컬 평면은 Memory tool과 세션 학습으로 상태를 쌓는다. 호스팅 평면은 server-side에 영속되는 session filesystem과 append-only events에 상태를 쌓는다. 같은 에이전트를 양쪽에서 굴리면 학습이 두 저장소에 따로 누적되고, 어느 쪽이 현재 정본인가가 다시 미정이 된다. 이건 새 문제가 아니다 — 에이전트 메모리 카테고리가 분해한 "메모리 단일 정본" 깨짐이, 같은 벤더의 호스팅 평면에서 한 번 더 그대로 재현된 것이다.
4. 감사는 너무 영속하고 정의는 너무 휘발한다. append-only event log는 컨테이너 밖에 쌓여 harness 재시작 후에도 살아남으므로 감사 레코드가 기본 제공된다. 그러나 delete는 이벤트 히스토리를 영구 삭제한다 — 탈출구가 삭제뿐이고, 그 삭제가 컴플라이언스 레코드 자체를 파괴한다. 동시에 agent-by-ID 정의를 바꾸면 그 ID를 참조하는 세션 동작이 통째로 바뀌는데, 로컬은 정반대로 즉시 편집을 전제한다. AWS Agent Registry의 "수정 → DRAFT 환원 → 재승인"이 라이프사이클을 너무 무겁게 묶었다면, 여기는 그 반대 극이다 — 호스팅은 너무 영속(삭제만이 탈출구)이고 로컬은 너무 휘발이라, 둘을 같이 굴리면 일관된 변경 라이프사이클이 성립하지 않는다.
5. 신뢰 경계가 어디 그어졌는지가 평면마다 다르다. 호스팅의 vault 크리덴셜 프록시는 시크릿을 샌드박스 안으로 들이지 않고 tool 호출 시점에 server-side 주입한다 — prompt injection 절도 경로를 구조적으로 닫는 강점이다. 그런데 같은 평면에서 MCP는 Anthropic 보안 perimeter 밖이라 "네 애플리케이션이 신뢰 경계"이고, egress는 JWT 인증 프록시 + TLS inspection을 거치며 limited 모드에서도 Anthropic 인프라 호스트(sentry.io·staging 등 6개)가 egress JWT에 조용히 주입된다 — 컴플라이언스 팀은 JWT를 리버스하지 않으면 실제 egress 범위를 문서화할 수 없다. 로컬 스택은 egress를 직접 통제하므로 경계가 한곳에 있다. 신뢰 경계의 위치와 가시성이 평면마다 다르다 — 같은 호출이 평면을 옮길 때 신뢰 경계가 보이지 않게 이동한다.
6. "누가 무엇을 끌·볼 권한을 갖는가"의 단위가 평면마다 다르게 그어진다. 로컬 스택은 키를 프로젝트·사용자 단위로 쪼갤 수 있어 누가 어느 범위의 세션을 보고 끌 수 있는가를 잘게 나눈다. 호스팅 평면은 정반대다 — org 단위 API 키 하나가 전 세션·전 이벤트 히스토리에 접근하고 fine-grained role 분리가 없으므로, 감사·관측의 권한 경계가 org 전체 한 덩어리로만 그어진다. 누가 어떤 세션을 들여다보고 어디서 끄는가 — 감사·관측 권한의 입자 — 가 평면마다 다르게 그어진다. 그 경계를 같은 벤더가 자기 손으로, 로컬은 키를 쪼갤 수 있게·호스팅은 쪼갤 수 없게 그었다는 것이 핵심이다. 키 유출 시 blast radius가 org 전체로 번지는 것은 이 비대칭의 부산물이지 그 자체가 본질이 아니다 — 본질은 감사·관측 권한의 입자가 평면별로 다르다는 것이다.
7. Claude Platform on AWS 교차로 평면이 3중이 된다. Managed Agents는 Claude Platform on AWS에서도 제공된다(feature·session 동작 차이 있음). AWS에서 굴리는 순간 거버넌스 평면은 셋이 된다 — AWS Agent Registry + Anthropic Managed Agents + 로컬 Claude 스택. 이 자리에서 AWS Agent Registry의 마찰 — 인증 모델 단일 선택, 네이밍 충돌, 라이프사이클 환원 등 — 과 이 호스팅 평면의 충돌이 정면으로 만난다. 등록·발견 쪽 마찰과 호스팅 쪽 분열이 같은 자원 위에서 교차하며, 서로 다른 벤더 사이의 마찰과 한 벤더가 자기 손으로 그은 분열이 한 호출 경로에 동시에 얹힌다.

일곱이 모두 같은 패턴의 변주다 — 모델 회사 자신이 로컬은 다중 소스를, 호스팅은 단일 소스를 가정하고, 둘을 다른 API 평면으로 쪼갰다. AWS Agent Registry의 마찰이 서로 다른 벤더의 가정 충돌이었다면, 여기서는 같은 벤더가 자기 손으로 그은 경계가 충돌의 원인이다 — 그래서 가장 정합적이어야 할 같은 벤더 자리에서 단일 정본 결정이 가장 먼저, 가장 깊게 깨진다.

종합

거버넌스 인덱스는 다음 분기 운영 화두를 어느 평면을 단일 정본으로 둘 것인가로 좁혔다. AWS Agent Registry는 그 화두의 cross-vendor 버전 — 클라우드 Registry와 로컬 스택 중 어느 쪽을 정본으로 — 이고, 여기서는 그 intra-vendor 버전이다. 그리고 intra-vendor 버전이 더 무겁다. cross-vendor 분열은 벤더가 다르니 가정이 다르다로 설명되지만, 여기서는 같은 회사가 같은 손으로 로컬 평면과 호스팅 평면의 경계를 그었다. 브랜딩 가이드가 "이것을 Claude Code라 부르지 마라"로 제품 경계를 명시한 것이 그 증거다 — 통합할 의도가 없다는 신호이고, 그래서 두 평면을 하나의 정본으로 봉합하는 일은 벤더가 해주지 않는다. 단일 소스 결정은 운영자에게로 통째로 떨어진다.

핵심은 이 결정이 연기 가능한 선택지가 아니라는 점이다. Managed Agents는 베타 헤더를 SDK가 자동 설정하므로 모든 API 계정에 이미 켜져 있다 — 로컬 스택을 굴리는 팀은 결정하지 않아도 두 평면을 동시에 굴리는 상태에 자동 진입한다. 결정을 미루면 다음 거버넌스 레이어가 그 결정을 강제한다 — AWS Agent Registry에서의 결론이 여기서 한 단계 더 날카로워진다: intra-vendor 자리에서는 그 레이어가 이미 도착해 기본 활성 상태로 켜져 있다. 결정을 미루는 선택 자체가 호스팅 평면을 묵시적 그림자 정본으로 승격시키는 결정이다 — 정의·권한·메모리·감사가 두 곳에 갈린 채, 어느 쪽이 정본인지 아무도 선언하지 않은 상태로 운영된다. 거버넌스 분열의 최악 형태는 분열 자체가 아니라 분열을 인지하지 못한 채 굴리는 것이고, 기본 활성은 정확히 그 상태를 디폴트로 만든다.

한 줄 추천. long-running·async 워크로드가 본질이고 오케스트레이션·샌드박스·세션 영속 인프라를 위탁하는 가치가 org 단위 키 blast radius를 감수할 값을 넘는 팀은 호스팅으로 옮기고 로컬 정의를 mirror로 강등하라. 키 blast radius를 프로젝트·사용자 단위로 통제해야 하거나, egress 범위를 직접 문서화·통제해야 하거나, 즉시 편집 반복이 워크플로의 본질인 팀은 로컬에 남고 호스팅을 쓰지 마라. 둘 다 두되 어느 쪽도 정본으로 선언하지 않는 상태가 유일하게 틀린 답이다.

참고

• Claude Managed Agents — Overview (Anthropic Platform Docs)
• Inside Claude Managed Agents (Pluto Security)
• What Is Anthropic Managed Agents (MindStudio)
• Claude Managed Agents: What It Actually Offers — The Honest Pros and Cons (Medium, unicodeveloper)
• Agent Governance 카테고리 인덱스 — 4축·3깨짐지점 프레임
• AWS Agent Registry — 같은 화두의 cross-vendor 버전
• Agent Memory 시리즈 — 메모리 단일 정본 깨짐이 호스팅 평면에서 재현되는 자리
• MCP 시리즈 — "남은 문제는 운영"의 출발점이자, 호스팅 평면이 그 운영 문제에 대한 모델사 자신의 답인 자리
• ECC — AgentShield 보안 스캔이라는 인접 운동(메타프레임 평면에서의 보안 하드닝)