이 문서는 확정 분석이 아니라 자료 정리다. Anthropic의 Managed Agents 글은 AI agent를 더 오래 돌리는 기능 소개처럼 보이지만, 실제로는 더 중요한 설계 질문을 던진다. 장기 실행 agent에서 모델, 실행 환경, 작업 기록, 권한을 한 덩어리로 묶어 두면 어디가 먼저 깨지는가?
한 줄로 말하면, Managed Agents는 agent의 “두뇌”와 “손”과 “작업 기록”을 분리해, 긴 작업을 더 안정적으로 복구하고 더 안전한 권한 경계 안에서 실행하려는 runtime 설계다.
왜 지금 읽을 만한가
AI agent가 짧은 답변을 만드는 단계에서는 하나의 대화창과 몇 개의 도구 호출만으로도 충분해 보인다. 하지만 실제 업무로 들어가면 문제가 달라진다. agent는 저장소를 수정하고, 여러 실행 환경을 연결하고, 외부 도구를 호출하며, 몇 시간 또는 며칠짜리 작업을 이어가야 한다.
이때 병목은 모델 지능만이 아니다. 컨테이너가 죽었을 때 작업을 복구할 수 있는가, 실행 환경 안에 credential이 노출되는가, 긴 context를 요약하다가 중요한 사건을 잃는가, sandbox를 준비하느라 첫 응답이 늦어지는가가 제품 경험을 결정한다.
Managed Agents 글은 managed agents라는 개념을 실제 제품 설계 언어로 풀어낸다. 특히 “brain”과 “hands”를 분리한다는 표현은 앞으로 기업용 agent runtime을 볼 때 반복해서 나올 구조적 렌즈가 될 수 있다.
확인된 것
Anthropic은 Managed Agents를 만들면서 agent를 세 부분으로 나눠 설명한다.
- Brain은 Claude와 harness가 다음 행동을 결정하는 층이다.
- Hands는 sandbox, 도구, 코드 실행 환경처럼 실제 행동이 일어나는 층이다.
- Session은 agent가 무엇을 봤고 무엇을 했는지를 남기는 event log다.
초기 구조에서는 이 요소들이 하나의 컨테이너 안에 붙어 있었다. 이 방식은 단순하지만, 컨테이너가 멈추면 session이 사라지고, 디버깅도 어려우며, 사용자의 데이터와 credential이 같은 공간에 놓일 수 있다. Anthropic은 이를 “pet” 서버처럼 다뤄야 하는 문제로 설명한다. 하나의 귀중한 개체를 살려야 하는 구조는 장기 실행 agent와 잘 맞지 않는다.
개선된 구조에서는 harness가 컨테이너 밖으로 나가고, sandbox는 필요할 때 호출되는 “손”이 된다. session log도 harness 밖에 있으므로 harness가 실패해도 새 harness가 event log를 읽고 이어받을 수 있다. Anthropic은 이 분리로 time-to-first-token이 p50에서 약 60%, p95에서 90% 이상 줄었다고 설명한다.
또 하나의 핵심은 credential 분리다. Git token이나 OAuth token을 sandbox 안에서 agent가 직접 읽게 두지 않고, clone 과정이나 MCP proxy, vault 같은 경로로 감싼다. 즉 agent가 실행하는 untrusted code와 비밀값을 같은 공간에 놓지 않는 것이 구조의 핵심이다.
Wansook.World에서 볼 포인트
첫 번째 포인트는 agent runtime이 점점 운영체제와 닮아간다는 점이다. Anthropic은 “아직 생각하지 못한 프로그램을 위한 시스템”이라는 오래된 컴퓨팅 문제를 언급한다. operating system이 process와 file abstraction으로 하드웨어를 감쌌듯이, agent runtime도 session, harness, sandbox라는 안정된 인터페이스가 필요해진다.
두 번째 포인트는 agent containment와의 연결이다. agent가 똑똑해질수록 사용자는 더 많은 권한을 주고 싶어진다. 하지만 권한이 커질수록 피해 범위도 커진다. Managed Agents는 모델을 더 잘 감독하는 것만이 아니라, 실행 환경과 권한 경계를 분리해 위험을 줄이려는 설계다.
세 번째 포인트는 agent memory consolidation의 위험을 runtime 차원에서 다룬다는 점이다. session log가 context window와 분리되어 있으면, 요약이나 trimming이 실패해도 원래 event stream으로 돌아갈 가능성이 생긴다. 긴 작업에서 “기억”은 모델 안에 넣는 텍스트만이 아니라, 복구 가능한 사건 기록이어야 한다.
아직 모르는 것
이 글은 Anthropic의 공식 엔지니어링 설명이므로, 구조의 방향은 중요하지만 실제 시장 성과는 별도 확인이 필요하다. 특히 다른 모델 제공자나 cloud agent platform이 비슷한 abstraction을 어떻게 구현하는지, 고객이 self-hosted 환경이나 private VPC에서 얼마나 쉽게 연결할 수 있는지는 더 봐야 한다.
다음 질문이 남아 있다.
- Managed Agents가 실제 고객 장기 작업에서 실패율과 복구 시간을 얼마나 줄이는가.
- brain과 hands 분리가 비용과 latency를 어디까지 낮추는가.
- session log가 감사·재현·디버깅에 충분한 정보를 남기는가.
- MCP proxy와 vault 구조가 third-party tool ecosystem에서 얼마나 일관되게 동작하는가.
- AWS, Microsoft, Google의 agent runtime 설계와 비교했을 때 차별점이 무엇인가.
헷갈리지 말아야 할 점
- Managed Agents는 “agent가 스스로 모든 일을 안전하게 한다”는 뜻이 아니다. 오히려 agent가 실패할 수 있다는 전제에서 구조를 나누는 설계다.
- 긴 context window가 커진다고 session log가 필요 없어지는 것은 아니다. context는 모델이 지금 보는 작업대이고, session은 복구 가능한 사건 기록이다.
- Sandbox를 쓰는 것만으로 credential 문제가 해결되지는 않는다. 비밀값이 sandbox 안에 들어오지 않도록 proxy와 vault 경계를 함께 설계해야 한다.
- Anthropic의 성능 수치는 Anthropic의 제품 환경에서 나온 설명이다. 일반적인 agent platform 전체에 바로 적용하려면 독립 사례가 필요하다.