Claude Managed Agents란? 2026년에 언제 쓰고 언제 쓰지 말아야 하나

Claude Managed Agents는 Anthropic이 long-running agent work를 위해 제공하는 hosted runtime이다. Anthropic이 session과 loop infrastructure를 더 많이 맡아주길 원하면 이쪽이 맞고, 반대로 loop를 직접 소유하거나 runtime을 자기 프로세스 안에 남겨야 한다면 Messages API나 Claude Agent SDK가 더 자연스럽다.

2026년 4월 10일 기준으로 이 surface는 아직 beta이며, 일반 Claude token 비용에 session runtime 비용이 추가된다. 그리고 이것은 Claude Code가 아니다. 여기서 정말 답해야 하는 질문은 “Managed Agents가 더 최신처럼 들리느냐”가 아니라 “이 workload에서 runtime ownership을 Anthropic에 넘기는 편이 더 이익이냐”이다.

“

검증 메모: 이 글은 Anthropic의 Managed Agents overview, quickstart, migration, pricing, memory preview, 공식 cookbook, engineering 글을 2026년 4월 10일 기준으로 확인한 내용에 기반한다.

TL;DR

짧게 기억하면 이렇다.

• runtime을 Anthropic에 맡기고 싶으면 Managed Agents.
• loop를 직접 쥐고 싶으면 Messages API.
• runtime을 내 process 안에 남기고 싶으면 Claude Agent SDK.
• 실제 필요가 로컬 개발, 데스크톱 위임, repo 작업이라면 Claude Computer Use, Claude Code에서 먼저 써야 할 Skills, Claude Code용 추천 MCP Servers가 더 맞다.

Claude Managed Agents는 정확히 무엇인가

Claude Managed Agents는 막연한 “AI agents 기능”이 아니다. Anthropic의 현재 문서는 이것을 managed infrastructure 위에서 돌아가는 pre-built, configurable agent harness로 설명하고 있고, 특히 long-running task와 asynchronous work에 맞는다고 위치시킨다. 즉 helper가 조금 붙은 SDK라기보다, runtime surface로 이해하는 편이 정확하다.

공식 설명은 이 제품을 agent, environment, session, events 네 가지로 묶는다. agent는 동작과 tool 설정, environment는 hosted runtime의 접근 범위, session은 실제 실행 단위, events는 session이 바깥으로 내보내는 진행 및 상호작용 신호다. 이 네 요소를 먼저 잡고 보면 Managed Agents는 모호한 신제품 이름이 아니라 꽤 분명한 runtime contract처럼 읽힌다.

Messages API와 가장 큰 차이는 ownership이다. Messages API에서는 message history를 직접 들고, tool loop를 직접 굴리고, runtime이 실제로 어떻게 이어질지 스스로 책임져야 한다. Managed Agents에서는 Anthropic이 session runtime의 상당 부분을 맡기 때문에, 장시간 돌아가는 loop plumbing을 전부 직접 조립하지 않아도 된다.

Claude Agent SDK와의 차이도 단순히 “기능이 더 많다 / 적다”가 아니다. Anthropic의 migration 문서는 SDK는 당신의 process에서 실행되고, Managed Agents는 Anthropic-managed infrastructure에서 실행된다고 분명히 구분한다. runtime을 자기 쪽에 두고 싶으면 SDK, hosted runtime convenience를 얻고 싶으면 Managed Agents라는 식으로 보는 편이 실무적이다.

또 하나 초반에 바로 정리해야 할 오해가 있다. Claude Managed Agents는 Claude Code가 아니다. Anthropic은 Managed Agents를 Claude Code나 Claude Cowork처럼 브랜딩하지 말라고 적고 있다. 로컬 repo 작업, 브라우저 위임, 데스크톱 실행을 찾는 독자라면 이 페이지는 핵심 답이 아니다.

언제 Claude Managed Agents가 맞는 선택인가

Managed Agents가 진짜 설득력을 갖는 순간은 “새 제품이라서”가 아니다. 병목이 모델 자체보다도, tool-using workflow를 오래 돌리기 위한 runtime을 직접 유지해야 하는 데 있을 때다. Anthropic의 공개 자료도 일관되게 long-running, asynchronous, stateful 작업을 sweet spot으로 제시한다.

예를 들면 research agent, data analysis agent, 또는 첫 요청 이후에도 계속 진행되는 internal automation이 그렇다. 공통점은 한 번의 completion으로 끝나는 작업이 아니라 session 지속성과 hosted environment가 실제 의미를 가진다는 점이다.

공식 cookbook의 data analyst agent가 좋은 이유도 여기에 있다. environment를 재사용하고, 파일을 mount하고, events를 stream하고, outputs를 session 안에 쌓아간다. 여기서 보이는 가치는 “Claude가 tool을 부른다”가 아니라 “hosted runtime과 session lifecycle을 Anthropic이 가져간다”는 데 있다.

또 다른 적합 사례는 agent run의 결과가 중요하지, loop 내부 모든 orchestration을 직접 소유하는 것이 제품 차별점은 아닌 경우다. 팀의 진짜 목표가 “이 hosted workflow를 안정적으로 굴리는 것”이라면, Managed Agents는 상당한 runtime scaffolding을 덜어준다.

더 현실적으로 말하면, 많은 팀이 자체 agent runtime의 숨은 비용을 과소평가한다. state management, long-running execution, tool retries, event streaming, session continuity, environment lifecycle. 이 plumbing 자체가 여러분의 강점이 아니라면, Anthropic에 넘기는 선택은 꽤 합리적이다.

언제 Messages API나 Claude Agent SDK가 더 나은가

가장 흔한 오해는 “더 managed되었으니 상위호환”이라고 생각하는 것이다. 그렇지 않다. runtime ownership을 실제로 넘기고 싶을 때만 Managed Agents가 더 낫다. 제품이 bespoke loop, 독특한 state transitions, 세밀한 orchestration, 특수 fallback에 의존한다면 Messages API가 여전히 더 깔끔하다.

왜냐하면 Messages API는 지금도 가장 얇고 자유로운 경로이기 때문이다. message history를 어떻게 가질지, tool flow를 어떻게 전개할지, loop를 어디서 끝낼지, runtime을 다른 시스템과 어떻게 연결할지는 모두 직접 결정할 수 있다. 번거롭지만, 그 번거로움이 곧 제품 가치인 경우도 많다.

Claude Agent SDK가 더 맞는 경우는 핵심 요구가 “Anthropic이 host해주면 좋겠다”가 아니라 “runtime은 우리 process 안에 있어야 한다”일 때다. Anthropic도 migration 문서와 cookbook에서 이 경계를 여전히 남겨 두고 있으므로, SDK는 Managed Agents에 흡수된 옛 surface가 아니다.

custom tools도 과장해서 읽으면 안 된다. Managed Agents가 “이제 client logic이 완전히 사라진다”는 뜻은 아니다. 현재 문서에서도 custom tools는 events를 통해 이어진다. private service, 특별한 tool choreography, 복잡한 callback에 크게 의존하는 시스템이라면 hosted runtime의 이점이 처음 보이는 만큼 크지 않을 수도 있다.

결국 판단 규칙은 짧아도 충분하다.

• Anthropic에 runtime을 맡기고 싶으면 Managed Agents.
• loop를 직접 소유하고 싶으면 Messages API.
• runtime을 자기 process에 두고 싶으면 Claude Agent SDK.

이 세 가지를 분리해 생각하면 글이 흐릿한 feature compare로 무너지지 않는다.

현재 pricing, beta 상태, preview 경계

Managed Agents는 “이미 실제로 쓸 수 있지만, 아직 완전히 굳은 platform layer는 아닌 beta runtime surface”로 이해하는 편이 가장 안전하다. Anthropic의 현재 docs는 managed-agents-2026-04-01 beta header를 요구한다. 이 사실은 남겨야 하지만, 기사 전체를 지배할 주제는 아니다.

2026년 4월 10일 기준 pricing은 두 층으로 나뉜다. 첫째는 일반 Claude token billing이다. 둘째는 session이 running 상태일 때 붙는 session runtime 비용으로, Anthropic은 현재 session-hour당 0.08달러를 안내한다. 이것은 날짜가 붙은 사실로 읽어야 하지만, 동시에 route choice를 바꾸는 사실이기도 하다. 지금 고르는 것은 model만이 아니라 runtime contract이기 때문이다.

그래서 이 글은 setup보다 route choice를 먼저 둔다. workload가 hosted long-running session에서 실제 이익을 얻는다면 이 runtime fee는 충분히 정당화될 수 있다. 반대로 작업이 짧고 얇거나 이미 custom loop로 충분히 잘 돌아간다면, hosted runtime을 하나 더 올리는 것이 큰 가치를 주지 않을 수 있다.

기능 성숙도 경계도 솔직하게 적는 편이 낫다. Anthropic은 현재 Managed Agents 자체는 Claude API accounts에 default access로 설명하면서도, memory, multiagent, outcomes는 여전히 research preview로 따로 둔다. 즉 core runtime은 real하지만 주변 capability는 아직 fully settled contract로 읽으면 안 된다.

rate limits도 마찬가지다. Anthropic은 현재 create endpoints 60 RPM, read endpoints 600 RPM을 적고 있고 organization-level spend / tier limits도 적용된다. production planning에서는 중요하지만, surface를 고르는 첫 번째 이유가 되어서는 안 된다.

실무적 요약은 단순하다. Managed Agents는 충분히 real하고 진지하게 평가할 가치가 있다. 다만 pricing, preview access, beta headers, limits 같은 freshness-sensitive 정보는 반드시 날짜와 함께 읽어야 한다.

한 가지 예로 이해하기: hosted data analyst workflow

공식 data analyst agent cookbook은 Managed Agents를 가장 구체적으로 보여주는 예시다. hosted environment 위에서 agent가 움직이고, environment를 재사용하고, files를 mount하고, events를 stream하고, outputs를 session 안에 쌓아간다. 여기서 “hosted runtime”이 실제로 무엇을 뜻하는지 감이 잡힌다.

이 예시가 좋은 이유는 “tool을 부를 수 있다”를 보여주기보다, “session-oriented hosted runtime이 왜 필요한가”를 보여주기 때문이다. data analysis 같은 작업은 한 번의 text completion으로 끝나지 않는다. 여러 단계를 거치고, 시간이 걸리고, 나중에 결과를 돌려준다. 바로 그런 shape의 일이라면 Managed Agents는 자연스럽다.

동시에 cookbook은 exit boundary도 분명히 보여준다. agent loop와 deployment를 완전히 제어해야 한다면 Claude Agent SDK가 더 낫다고 Anthropic 스스로 말한다. 이것은 작은 주석이 아니라 route decision 자체다.

현재 flow를 아주 짧게만 요약하면 이렇다. agent를 만들고, environment를 만들고, session을 시작하고, events를 보내고, 결과를 stream한다. 이 정도만 봐도 이런 hosted session runtime이 자기 workload에 필요한지 대략 판단할 수 있다.

bash
curl https://api.anthropic.com/v1/agents \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: managed-agents-2026-04-01"

이 snippet을 짧게 둔 이유도 같다. 중요한 것은 curl 문법이 아니라, 이런 종류의 hosted runtime이 실제로 필요한지 여부다.

FAQ

Claude Managed Agents는 Claude Code와 같은 것인가?

아니다. Managed Agents는 Anthropic API 안의 hosted runtime surface이고, Claude Code는 로컬 coding workflow product이다. Anthropic도 둘을 섞지 말라고 분명히 적고 있다.

언제 Messages API 대신 Managed Agents를 선택해야 하나?

Anthropic에게 long-running loop와 session runtime을 더 많이 맡기고 싶을 때다. loop, message history, 저수준 orchestration을 직접 쥐고 싶다면 Messages API에 남는 편이 맞다.

언제 Claude Agent SDK가 더 적합한가?

runtime을 자기 process나 deployment 안에 남겨야 할 때다. Anthropic의 migration 문서도 이 경계를 아직 분명하게 유지한다.

Managed Agents면 custom tools까지 Anthropic이 전부 관리해주나?

아니다. hosted runtime이 더 많은 것을 맡기는 것은 맞지만, custom tools는 여전히 client-side event handling이 필요할 수 있다. fully managed everything으로 읽으면 안 된다.

현재 pricing은 어떻게 이해하면 되나?

2026년 4월 10일 기준으로 Anthropic은 일반 Claude token 비용에 더해 session이 running 상태일 때 session-hour당 0.08달러의 runtime fee가 붙는다고 적고 있다. 이 숫자는 날짜와 함께 읽어야 한다.

memory, multiagent, outcomes는 이미 일반 공개인가?

아직은 아니다. Anthropic은 지금도 이를 research preview로 취급하고 별도 access를 요구한다.

rate limits를 초반부터 크게 봐야 하나?

production planning에서는 중요하지만, route choice보다 앞세울 문제는 아니다. Anthropic은 create 60 RPM, read 600 RPM을 적고 있지만, 그것이 surface 선택의 첫 이유는 아니다.

결국 판단해야 하는 것은 runtime을 누가 소유할 것인가이다

Claude Managed Agents가 중요한 이유는 단순히 새 이름이 붙어서가 아니다. Anthropic이 hosted runtime을 독립된 product route로 꺼내 놓았기 때문이다. 이때 풀어야 하는 질문은 아주 구체적이다. 오래 도는 agent work의 runtime을 계속 우리가 소유할 것인가, 아니면 Anthropic에 넘길 것인가.

물론 이것이 모두의 default answer는 아니다. custom loop가 강점이라면 Messages API에 남아야 한다. runtime이 자기 process에 있어야 한다면 Claude Agent SDK가 더 자연스럽다. Anthropic-managed session runtime이 실제 이익을 줄 때만 Managed Agents가 올바른 route가 된다.

이렇게 보면 주제가 훨씬 단순해진다. 물어야 할 것은 “Managed Agents가 무엇인가”만이 아니다. “이 runtime을 Anthropic이 소유해야 하나, 아니면 우리 시스템이 계속 소유해야 하나”가 더 중요하다. 이 페이지는 바로 그 판단을 빨리 끝내게 하려고 존재한다.