Claude Managed Agents vs Claude Agent SDK

지난주 나는 탭 세 개를 열어놨다: Managed Agents 문서, Agent SDK 퀵스타트, 그리고 Messages API 레퍼런스. 비동기 문서 처리 파이프라인에 어떤 경로를 써야 할지 파악하려는 중이었다. 40분이 지나서야 혼란의 원인이 기능의 차이가 아니라는 걸 깨달았다. 문제는 런타임을 누가 소유하느냐였다.

그게 이 결정의 핵심이다. 어느 쪽이 “더 낫다”가 아니라. 지금 만들고 있는 것에 어떤 인프라 경계가 맞는지의 문제다. 이 글은 두 경로를 어떻게 비교할지 — 그리고 대부분의 비교 글이 빠뜨리는 세 번째 옵션이 왜 존재하는지를 정리한다.

Claude 기반 에이전트로 가는 두 가지 경로

Agent SDK: 루프는 당신이 소유하고, 런타임은 당신이 관리한다

Claude Agent SDK — 올해 초 Claude Code SDK에서 이름이 바뀐 — 는 Claude Code를 구동하는 도구, 에이전트 루프, 컨텍스트 관리를 Python 또는 TypeScript 라이브러리로 패키징해 제공한다. 직접 설치하고, 자체 인프라에서 실행하며, 스케일링·샌드박싱·오케스트레이션을 모두 직접 처리해야 한다.

SDK는 Claude Code CLI를 자동으로 번들링한다. 에이전트는 파일 작업, bash 명령, 웹 브라우징, 코드 실행 — 전체 Claude Code 툴셋 — 을 기본으로 사용할 수 있다. 허용할 도구를 정의하고, 권한 모드를 설정하며, 커스텀 도구를 인프로세스 MCP 서버로 구현할 수 있다.

얻는 것: 실행 환경에 대한 완전한 제어권. 함께 얻는 것: 그 환경을 운영하고, 보안을 유지하고, 관찰 가능하게 만들 책임.

Managed Agents: Anthropic이 하네스를 소유하고, 당신이 태스크를 정의한다

2026년 4월 8일 공개 베타로 출시된 Claude Managed Agents는 소유 모델을 뒤집는다. 에이전트를 명세하면 — 모델, 시스템 프롬프트, 도구, MCP 서버, 가드레일 — Anthropic이 실행한다. 하네스가 도구 실행, 샌드박싱, 세션 유지, 컨텍스트 압축, 프롬프트 캐싱, 충돌 복구를 처리한다.

Anthropic 엔지니어링 팀은 이를 “메타 하네스”라고 설명한다 — Claude가 할 수 있거나 없는 것에 대한 고정된 가정을 인코딩하기보다 모델이 발전함에 따라 미래의 하네스를 수용할 수 있도록 설계됐다. 컨테이너가 충돌해도 세션은 살아남는다. 새 컨테이너가 세션 로그에서 이어받는다.

당신은 설정하고, Anthropic이 운영한다.

어느 쪽이 일방적으로 더 낫지 않다

기능 겹침이 크다. 두 쪽 모두 Claude에게 코드 실행, 파일 조작, bash, 웹 브라우징, MCP 통합에 대한 접근을 준다. 차이는 운영 측면이다: 누가 환경을 프로비저닝하고, 누가 장애를 처리하고, 누가 컨테이너를 스케일링하는지. 이것은 인프라 결정이지, 기능 결정이 아니다.

핵심 비교

청구 관련해 한 가지 짚고 넘어갈 점: Agent SDK는 세션 런타임 요금을 추가하지 않는다. 그렇다고 단순히 “더 저렴하다”고 말하면 오해를 부른다. 자체 호스팅 런타임은 실질적인 비용이 있다 — 서버, 컨테이너 오케스트레이션, 모니터링, 인시던트 대응, 이 모든 것을 유지하는 엔지니어 시간. 비용 구조가 다른 것이지, 단순히 순서가 있는 게 아니다.

Managed Agents를 선택해야 할 때

세션 지속성이 중요한 장시간 또는 비동기 태스크

에이전트가 30분에서 몇 시간 동안 실행될 때 — 문서 처리, 리서치, 멀티스텝 워크플로우 실행 — 연결 끊김이나 컨테이너 장애에서 살아남는 세션 상태가 필요하다. Managed Agents는 전체 이벤트 히스토리를 서버 측에 저장하고 API로 조회할 수 있게 한다. 이에 상응하는 내구성을 직접 구축하는 것도 가능하다. 그런데 그건 핵심 제품이 아닌 곳에 쏟아붓는 몇 주 치 엔지니어링이기도 하다.

보안 샌드박스를 구축할 인프라 역량이 없는 팀

프로덕션 수준의 샌드박싱 — 격리, 자격증명 관리, 범위가 지정된 권한, 실행 추적 — 은 진짜 어렵다. 대부분의 팀이 이를 과소평가한다. 팀에 안전한 에이전트 실행 환경을 구축하고 유지할 DevOps 역량이 없다면, Managed Agents는 그 전체 영역을 로드맵에서 제거해 준다.

빠른 프로토타입에서 프로덕션까지: 몇 달 대신 며칠

Anthropic의 헤드라인은 “10배 빠르게 프로덕션 도달”이다. 충분한 시나리오에서 그 수치를 검증하지 못해 보증할 수는 없다. 하지만 방향은 맞다: “에이전트가 로컬 테스트에서 동작한다”와 “에이전트가 프로덕션에서 안정적으로 실행된다” 사이의 간극은 크고, Managed Agents가 그 간극을 좁힌다. Rakuten은 전문 에이전트를 각각 일주일 이내에 배포했다고 전해진다.

내장된 압축과 캐싱이 커스텀 제어보다 더 중요할 때

Managed Agents는 프롬프트 캐싱과 컨텍스트 압축을 자동으로 처리한다. 장시간 실행 에이전트를 위해 자체 컨텍스트 관리를 구축해본 사람이라면 여기에 얼마나 많은 시행착오가 필요한지 안다. 내장 방식이 모든 워크로드에 최적이지는 않다. 대부분에게는 충분하고 — 첫날부터 작동한다.

Agent SDK를 선택해야 할 때

Managed Agents가 노출하지 않는 커스텀 오케스트레이션 로직

SDK는 훅, 인프로세스 MCP 서버로서의 커스텀 도구, 세분화된 권한 콜백, 에이전트 루프에 대한 완전한 제어를 제공한다. 에이전트에게 커스텀 재시도 전략, 조건부 도구 라우팅, 세션 중간의 동적 프롬프트 수정 — Managed Agents의 설정 인터페이스가 노출하지 않는 로직 — 이 필요하다면 SDK가 필요하다.

특수 도구 통합 또는 커스텀 실행 환경

에이전트가 특정 환경 안에서 실행되어야 한다면 — GPU 접근, 특정 데이터베이스 드라이버, 독점 라이브러리 — SDK로 실행 환경을 완전히 제어할 수 있다. Managed Agents는 사전 설치된 패키지가 있는 클라우드 컨테이너를 제공한다. 대부분의 경우엔 충분하다. 전부는 아니다.

온프레미스 또는 프라이빗 클라우드 요구사항

Managed Agents는 오직 Anthropic 인프라에서만 실행된다. 온프레미스 옵션도, 자체 클라우드 배포도 없다. 엄격한 데이터 주권 요구사항이나 서드파티 인프라로 데이터 전송을 금지하는 규제 제약이 있는 조직에게 SDK가 유일한 경로다. 이것은 선호의 문제가 아니라 하드 제약이다.

규모에서의 비용 구조

$0.08/세션시간은 대부분의 워크로드에서 무시할 만하다 — 24/7 에이전트는 토큰 전에 런타임 비용이 대략 월 $58 정도다. 하지만 동시에 실행되는 장시간 에이전트 대규모 플릿에서는 세션 요금이 쌓인다. 500개 에이전트 플릿이 동시에 실행되면 세션 오버헤드만 시간당 $40이 발생한다.

Agent SDK에는 이 세션당 추가 요금이 없다. 비용은 토큰 플러스 인프라 운영 비용이다. 대용량에서 런타임을 직접 소유하는 게 한계 비용 면에서 더 저렴할 수 있다 — 하지만 구축과 유지 비용이라는 고정 비용을 이미 흡수했을 때만.

세 번째 옵션: Messages API

SDK도 Managed Agents도 필요 없을 때

이것이 대부분의 비교 글이 빠뜨리는 옵션이고, 사람들이 생각하는 것보다 더 자주 올바른 답이다.

Messages API는 모델에 직접 접근을 제공한다. 프롬프트를 보내고 응답을 받는다. 하네스도, 에이전트 루프도, 관리형 런타임도 없다. 필요하다면 도구 실행 루프를 포함해 모든 것을 직접 구축한다.

전체 에이전트 프레임워크가 필요 없는 단순한 도구 사용 패턴

사용 사례가 이렇다면: Claude를 호출하고, 선택적으로 하나나 두 개의 도구를 사용하게 하고, 결과를 반환한다 — 에이전트 프레임워크가 전혀 필요 없다. 도구 사용이 있는 Messages API가 이것을 깔끔하게 처리한다. Agent SDK나 Managed Agents를 추가하면 단순한 요청-응답 패턴에서 그만한 값어치를 하지 못하는 복잡성이 생긴다.

Anthropic Python 및 TypeScript 클라이언트 SDK는 도구 사용을 기본으로 지원한다. 도구 루프를 직접 구현한다 — stop_reason을 확인하고, 도구를 실행하고, 결과를 다시 보내는 while 루프. 많은 프로덕션 워크로드에서 그것으로 충분하다.

20줄짜리 도구 루프로 해결됐을 일에 에이전트 프레임워크에 손 뻗는 팀을 봤다. 더 무거운 추상화를 선택하기 전에 태스크가 실제로 자율성이나 세션 지속성을 필요로 하는지 확인해라.

마이그레이션 고려사항

Managed Agents에서 시작해 SDK로 이동: 무엇이 바뀌나

에이전트 로직 — 시스템 프롬프트, 도구 정의, 태스크 구조 — 은 그대로 옮겨진다. 그렇지 않은 것: 세션 지속성, 샌드박싱, 컨텍스트 관리, 충돌 복구. 이것들은 모두 직접 구축해야 한다.

Managed Agents에서 SDK로 이동한다는 것은 “Anthropic이 운영”에서 “당신이 운영”으로 넘어가는 것을 의미한다. 기능은 동등하다. 운영 부담이 전적으로 팀으로 이동한다.

SDK에서 시작해 Managed Agents로 이동: 무엇이 바뀌나

어떤 면에서는 더 쉽고, 다른 면에서는 더 어렵다. 에이전트의 핵심 로직은 이식된다. 인프로세스 MCP 서버로 구현된 커스텀 도구는 원격 MCP 서버로 다시 노출해야 할 수 있다. 커스텀 훅과 권한 콜백은 Managed Agents의 설정 모델로 매핑해야 한다.

얻는 것: 런타임 유지를 그만해도 된다. 잃는 것: 실행 환경에 대한 세밀한 제어권. 그 트레이드오프가 맞는지는 커스텀 인프라 중 얼마나 실제로 필요했는지 대 초기 프로토타이핑 결정에서 물려받은 것인지에 달려있다.

2026년 4월 기준으로 두 사이 공식 마이그레이션 가이드는 없다. 단순한 코드 이식이 아닌 통합 테스트를 계획해라.

FAQ

같은 제품에서 둘 다 사용할 수 있나?

그렇다. SDK와 Managed Agents는 서로 다른 운영 필요를 충족한다. 흔한 패턴: 완전한 제어가 필요한 사용자 대면, 지연 민감 인터랙션에는 Agent SDK; 세션 지속성과 무인 운영이 더 중요한 백그라운드, 비동기 태스크에는 Managed Agents. 두 가지 모두 동일한 기반 Claude 모델과 토큰 비용에 대한 가격 구조를 공유한다.

Managed Agents가 Anthropic 인프라에 종속시키나?

그렇다. 런타임은 Claude용으로 특별히 설계됐다. GPT, Gemini, 오픈소스 모델을 실행하지 않는다. 에이전트 로직 — 프롬프트, 도구 정의, 태스크 구조 — 은 이식 가능하다. 런타임과 세션 형식은 그렇지 않다. SDK는 모델 레이어를 추상화하는 더 많은 유연성을 제공하지만, 그것도 Claude에 특화되어 있다.

어느 쪽이 오류와 재시도를 더 잘 처리하나?

Managed Agents에는 내장 충돌 복구가 있다 — 세션 로그가 유지되고, 새 컨테이너가 이전 것이 실패한 지점에서 이어받는다. SDK를 쓰면 자체 오류 처리를 구축한다. 이전에 해본 적이 있고 좋은 패턴이 있다면, SDK 오류 처리를 필요에 맞게 더 정밀하게 조율할 수 있다. 그렇지 않다면, Managed Agents의 기본값이 강력한 출발점이다.

기존 SDK 에이전트를 Managed Agents로 마이그레이션할 수 있나?

핵심 에이전트 로직은 이전된다. 시스템 프롬프트, 도구 정의, 태스크 구조는 호환된다. 재작업이 필요한 것: 커스텀 훅, 인프로세스 MCP 서버 (원격 등가물이 필요할 수 있음), 커스텀 권한 로직, 특정 실행 환경에 의존하는 모든 것. 공식 마이그레이션 툴링은 아직 없다.

대용량에서 어느 쪽이 비용 효율적인가?

무엇을 계산에 넣느냐에 달려있다. Managed Agents는 토큰에 더해 $0.08/세션시간을 추가한다. SDK는 세션당 추가 요금이 없다 — 하지만 자체 호스팅 런타임에는 자체 비용이 있다: 서버, 오케스트레이션, 모니터링, 엔지니어링 유지. 낮음에서 중간 수준의 볼륨에서는, Managed Agents가 총 소유 비용 면에서 일반적으로 더 저렴하다. 동시에 실행되는 장시간 세션이 많은 매우 높은 볼륨에서는 수학이 뒤집힐 수 있다 — 하지만 인프라에 이미 투자했을 때만.

이것이 비교다. 결정 트리: 인프라 제어가 필요하거나 데이터를 외부로 보낼 수 없다 → SDK. 인프라를 건너뛰고 싶다 → Managed Agents. 에이전트 루프가 전혀 필요 없다 → Messages API.

확신이 없다면 둘 다 파일럿을 돌려봐라. 배포 아키텍처를 확정한 이후보다 프로토타입 단계의 전환 비용이 훨씬 낮다.

다음 주에 계속 — Managed Agents에서 멀티에이전트 패턴을 아직 테스트 중이다.

이전 글: