1줄 정의

프롬프트 지능이 아니라 세션 시간 단위로 과금되는 호스트형 런타임으로서의 에이전트. Anthropic Managed Agents 가 대표.

전체 시스템에서 맡는 역할

매니지드 에이전트는 에이전트를 “프롬프트의 산물” 에서 “시간 단위로 빌리는 런타임” 으로 바꾸는 카테고리다. 단일 제품 이름이 아니라 운용 형태의 라벨로 보는 게 정확하다.

지금까지 에이전트 개발은 자기 환경에 Claude Code 나 harness 를 짜서 모델 API 를 두드리며 돌리는 게 기본이었다. 이게 “로컬 work surface” 에 가깝다. 매니지드 에이전트는 그 반대로, 제공자 측 (Anthropic 등) 이 session · harness · sandbox 를 포함한 런타임을 통째로 호스팅한다. 사용자는 API 로 “이 작업을, 이 도구 권한으로, session 으로 돌려달라” 고 넘기기만 한다.

대표 예인 Anthropic Managed Agents (2026-04 기준) 를 기점으로 특징을 늘어놓으면:

• session 이 1급 객체: 1 회의 질문 응답이 아니라 장시간 도는 작업 단위. 끊겨도 재개되는 전제로 설계됨
• brain 과 hands 분리: 모델 (생각하는 쪽) 과 도구 실행 환경 (움직이는 쪽) 을 다른 레이어로 끊는다. sandbox 는 이 hands 쪽에 속함
• credential boundary: API 키·자격 정보를 모델에 직접 노출하지 않고 실행 환경에 가둔다
• session-hour 과금: Anthropic 공식 pricing docs 는 $0.08 per session-hour (session 이 running 일 때만 누적, 2026-04 기준). token 과 별개의 과금 축이 생긴 게 새로움
• hosted service: 사용자는 뒷단 인프라를 안 본다. Claude API direct surface 에서 호출

이 설계에서 읽히는 본질은 에이전트 경쟁축이 프롬프트의 영리함에서 오래 안전하게 도는 바닥의 튼튼함으로 옮겨갔다는 것이다. autonomous loop 을 수 시간~수 일 단위로 돌리는 전제가 성립해야 비로소 A2A 같은 상위 프로토콜이나 meta-harness 같은 논의가 의미를 갖기 시작한다. 매니지드 에이전트는 그 바닥 쪽 선택지다.

한 줄로 정리하면: Claude Code 는 로컬 work surface, Managed Agents 는 호스트형 runtime surface. 같은 Anthropic 계열이어도 운용 철학이 갈린다.

흔한 오해

• 오해 1: 매니지드 에이전트 = 더 똑똑해진 AI 비서, 라고 받아들여지기 쉽다.

– 실제로는 답변 품질 자체를 극적으로 올리는 제품이 아니다. 바뀐 건 “오래 안 멈추고, credential 을 안 흘리고, 중간에 죽어도 재개되는” 구조 쪽이다. 모델은 같은 Claude 라도 올라가 있는 runtime 이 다른 물건이다, 라고 보는 게 가깝다.

• 오해 2: Managed Agents 는 Anthropic 고유 프로덕트 이름이다, 라고 좁게 잡히기 쉽다.

– 실제로는 Anthropic Managed Agents 가 대표 예시일 뿐, 카테고리로서의 “매니지드 에이전트” 는 다른 곳도 따라올 영역이다. 문맥에 따라 “Anthropic 특정 제품을 가리키는 건지”, “호스트형 런타임 일반을 가리키는 건지” 구분해서 읽어야 한다. 이 용어 페이지는 후자의 의미로 쓴다.

• 오해 3: session-hour 과금은 token 과금보다 무조건 이득 (또는 손해) 이다, 라고 단순화되기 쉽다.

– 실제로는 작업 성격에 따라 뒤집힌다. 대기 시간이 길고 token 생성이 적은 장시간 작업 (감시·폴링·사람 승인 대기 섞인 처리) 에서는 session 과금이 유리하지만, token 을 잔뜩 뱉는 단발 처리에서는 비싸진다. Anthropic 공식 pricing docs 는 session 이 running 일 때만 누적한다고 명시한다 ── 이 조건을 놓치면 견적이 빗나간다.

이 단어가 중요한 이유

매니지드 에이전트를 “제품 이름” 이 아니라 “운용 카테고리” 로 이해해 두면 실무 판단축이 늘어난다. 이게 가치다.

자사에서 에이전트를 돌리려 할 때 선택지는 대략 셋:

1. 로컬 harness (Claude Code 등) 를 자기 머신이나 CI 에서 돌린다

2. 매니지드 에이전트에 session 을 세워서 제공자 런타임에 맡긴다

3. 둘을 섞는다 (개발·검증은 로컬, 운영은 hosted)

이 구분을 안 가진 사람은 “에이전트 = 똑똑한 채팅” 의 연장선으로만 설계한다. 반면 이 3 지선다를 가진 사람은 예를 들어 다음 질문에 답할 수 있다:

• 24 시간 도는 감시형 에이전트를 어디에 둘까 (로컬 PC 는 멈춤)
• 고객 데이터를 건드리는 에이전트의 credential boundary 를 어디서 끊을까
• 실패한 session 을 누가 재기동할까 (우리인가, runtime 쪽인가)
• session-hour 와 token 합산 비용을 어떻게 견적할까

즉 매니지드 에이전트를 안다는 건 에이전트 운영의 “놓을 자리” 설계를 획득하는 것과 같다. 프롬프트 튜닝만으로는 닿을 수 없는 레이어의 판단축이 생긴다.

이 단어가 나오는 기사

• Anthropic Managed Agents, 장시간 에이전트 운용, Claude Code 와의 비교 관련 기사 (※ auto-link 로 자동 삽입)

다음에 읽을 용어 3개

• agent — 매니지드 에이전트가 속하는 상위 개념. “운용 형태의 하나” 로 두면 이해가 쉽다.
• A2A — 여러 매니지드 에이전트를 연계시키는 상위 프로토콜. 단독 운용의 다음 단계.
• autonomous loop — session 안에서 에이전트가 계속 도는 패턴. 매니지드 런타임이 떠받치는 실행 모델.