Claude Managed Agents
에이전트를 만드는 건 어렵지 않습니다. 프로덕션에 올리는 게 어렵습니다.
프로토타입은 주말이면 됩니다. Claude API 호출하고, 도구 붙이고, 루프 돌리면 뭔가 돌아가는 건 금방이에요. 문제는 그 다음입니다. 코드 실행을 안전하게 샌드박싱해야 하고, 세션이 끊겨도 상태가 유지되어야 하고, 인증은 분리해야 하고, 장애가 나면 복구해야 하고, 이 모든 걸 모니터링해야 합니다.
프로토타입에서 프로덕션까지 수개월이 걸리는 이유는 모델 때문이 아니라 이 인프라 때문입니다.
2026년 4월 8일, Anthropic이 Claude Managed Agents 퍼블릭 베타를 발표했습니다. 이 인프라를 통째로 맡기는 서비스입니다.
제품 발표: Claude Managed Agents: get to production 10x faster 기술 배경: Scaling Managed Agents: Decoupling the brain from the hands 공식 문서: Managed Agents overview
에이전트를 실제로 운영해본 사람이라면 이런 상황을 겪어봤을 겁니다.
컨테이너가 죽으면 세션이 날아갑니다. 에이전트가 2시간 동안 작업하다가 컨테이너가 죽으면? 처음부터 다시. Anthropic 엔지니어링 블로그에서는 이걸 "펫 문제(Pet Problem)"라고 불렀습니다. 컨테이너가 잃을 수 없는 애완동물이 된 거죠. 인프라는 가축(cattle)이어야 하는데.
모델이 바뀌면 하네스를 다시 짜야 합니다. Claude Sonnet 4.5는 컨텍스트 한계에 가까워지면 작업을 조기 종료하는 "컨텍스트 불안"이 있었습니다. 그래서 하네스에 컨텍스트 리셋 로직을 넣었더니, Claude Opus 4.5에는 이 문제가 없어서 그 로직이 죽은 무게(dead weight)가 됐습니다. 모델이 발전할 때마다 하네스에 인코딩된 가정이 무효화되는 겁니다.
인증, 샌드박싱, 모니터링을 전부 직접 짜야 합니다. LangChain이든 CrewAI든 AutoGen이든, 프레임워크는 오케스트레이션을 도와주지만 인프라까지 해결해주진 않습니다.
Managed Agents
Managed Agents는 한 마디로 "에이전트 루프 + 실행 환경 + 상태 관리를 통째로 Anthropic이 운영해줍니다"입니다.
개발자가 하는 일은 4가지입니다:
- Agent 정의 — 모델, 시스템 프롬프트, 도구, MCP 서버를 선언합니다. 한 번 만들면 ID로 재사용합니다.
- Environment 정의 — 클라우드 컨테이너 환경을 설정합니다. Python, Node.js, Go 등 패키지와 네트워크 규칙을 지정합니다.
- Session 시작 — 에이전트 + 환경을 참조해서 세션을 런칭합니다.
- Event 전송 — 사용자 메시지를 보내면, Claude가 자율적으로 도구를 실행하고 SSE로 결과를 스트리밍합니다.
그 뒤로는 Anthropic이 합니다. 도구 호출 결정, 컨텍스트 관리, 에러 복구, 프롬프트 캐싱, 컴팩션. 실행 중에 방향을 바꾸고 싶으면 추가 이벤트를 보내면 되고, 중단하고 싶으면 인터럽트하면 됩니다.
Claude가 쓸 수 있는 빌트인 도구:
도구 |
설명 |
|---|---|
Bash |
컨테이너에서 셸 명령 |
File operations |
읽기, 쓰기, 수정, glob, grep |
Web search & fetch |
웹 검색 + URL 콘텐츠 |
MCP servers |
외부 도구 연결 |
여기에 커스텀 MCP 서버를 추가로 붙일 수 있습니다.
기존 Messages API와 뭐가 다른가
Messages API |
Managed Agents |
|
|---|---|---|
에이전트 루프 |
직접 짜야 함 |
Anthropic이 운영 |
코드 실행 |
직접 샌드박스 구축 |
매니지드 컨테이너 |
상태 관리 |
직접 구현 |
영속 세션 자동 |
장애 복구 |
직접 구현 |
컨테이너 죽어도 세션 유지, 자동 복구 |
적합한 경우 |
세밀한 제어, 커스텀 루프 |
장시간 실행, 비동기 작업 |
Messages API가 "엔진"이라면, Managed Agents는 "엔진 + 차체 + 도로"입니다. 세밀한 제어가 필요하면 여전히 Messages API가 맞지만, "돌아가는 에이전트를 빨리 프로덕션에 올리고 싶다"면 Managed Agents가 답입니다.
실제로 누가 쓰고 있나
퍼블릭 베타와 함께 공개된 얼리 어답터 5곳입니다.
Notion — Custom Agents를 통합해서 코딩, 웹사이트 제작, 프레젠테이션 같은 작업을 병렬로 위임합니다.
Rakuten — 제품, 영업, 마케팅, 재무, HR 부서별로 에이전트를 만들어 Slack과 Teams에 통합했습니다. 배포까지 1주일 걸렸다고 합니다.
Asana — AI Teammates라는 이름으로 프로젝트 관리 워크플로우 안에서 에이전트가 협업합니다.
Sentry — 디버깅 에이전트와 패치 작성 에이전트를 쌍으로 운영합니다. 기존에 수개월 걸리던 개발이 수주일로 줄었습니다.
Vibecode — AI 네이티브 앱 인프라. 기존 대비 10배 빠른 배포를 달성했다고 합니다.
Anthropic 내부 테스트에서는 구조화된 파일 생성 과제에서 표준 프롬프팅 루프 대비 최대 10포인트 성공률 향상이 관찰되었고, 어려운 문제에서 개선 폭이 가장 컸습니다.
접근 방법
현재 퍼블릭 베타이며, 모든 API 계정에서 기본 활성화되어 있습니다.
필요한 것:
- Claude API 키
- 모든 요청에 managed-agents-2026-04-01 베타 헤더 (SDK는 자동 설정)
레이트 리밋: 생성 엔드포인트 분당 60건, 읽기 엔드포인트 분당 600건.
아직 리서치 프리뷰인 기능 3가지가 있습니다: - Outcomes — 에이전트가 목표 달성 여부를 자체 평가 - Multi-agent — 여러 에이전트 간 조율 - Memory — 세션 간 기억 유지
이것들은 별도 신청이 필요합니다.
내부 아키텍처: 뇌와 손의 분리
기술적 배경이 궁금한 분을 위해 간단히 짚겠습니다.
Anthropic 엔지니어링 블로그의 제목이 핵심입니다: "Decoupling the brain from the hands." 추론(뇌)과 실행(손)을 분리한 겁니다.
3개의 독립 계층으로 가상화했습니다:
- Session: 모든 이벤트의 추가 전용 로그. 하네스와 샌드박스 바깥에 존재. 컨테이너가 죽어도 세션은 살아남음.
- Harness: 오케스트레이션. 상태가 없고 교체 가능(stateless, replaceable). 여러 개를 동시에 실행할 수 있음.
- Sandbox: 실행 환경. 온디맨드 프로비저닝. 인증 토큰으로부터 격리됨.
이 분리 덕분에 TTFT(첫 토큰까지의 시간) p50이 약 60%, p95가 90% 이상 줄었습니다. 뇌가 손이 준비될 때까지 기다리지 않고 먼저 추론을 시작하기 때문입니다.
OS의 read() 명령이 1970년대 디스크 팩부터 현대 SSD까지 바뀌지 않은 것처럼, 이 인터페이스 위에서 하네스 구현은 자유롭게 바뀔 수 있습니다. "아직 발명되지 않은 하네스"도 수용하는 설계입니다.
시사점
Managed Agents가 의미하는 건 에이전트 인프라의 상품화입니다.
AWS가 서버를 상품화해서 "서버를 직접 운영하지 마세요"라고 한 것처럼, Anthropic은 이제 "에이전트 인프라를 직접 구축하지 마세요"라고 말하고 있습니다.
프롬프트 엔지니어링 → 컨텍스트 엔지니어링 → 하네스 엔지니어링으로 진화해온 흐름에서, 이제 하네스 자체를 매니지드 서비스로 제공하는 단계입니다. 개발자의 관심사가 "인프라를 어떻게 짜느냐"에서 "에이전트에게 무엇을 시키느냐"로 이동합니다.
프로토타입에서 프로덕션까지 수개월이 수일로 줄어든다는 Anthropic의 주장이 어디까지 현실인지는, 직접 써봐야 알 수 있을 겁니다. 베타 헤더 하나면 시작할 수 있으니까요.