Claude Managed Agents — 기존 에이전트 시스템을 대체할 수 있을까?#

2026-04-12

들어가며#

2026년 4월 8일, Anthropic이 Claude Managed Agents를 퍼블릭 베타로 출시했습니다. 에이전트 루프, 샌드박싱, 도구 실행 인프라를 직접 구축하지 않아도, 에이전트를 선언만 하면 Anthropic이 오케스트레이션을 처리해주는 호스팅형 실행 환경입니다.

필자는 현재 두 가지 에이전트 시스템을 운영하고 있습니다. 하나는 Claude Code + 하네스 기반의 로컬 작업 환경(이하 “로컬 에이전트”)으로, 운영자가 실시간으로 AI와 대화하며 업무를 처리합니다. 다른 하나는 Strands + AWS Bedrock AgentCore 기반의 멀티에이전트 시스템(이하 “시스템 에이전트”)으로, 사람 없이 자동으로 모니터링, 진단, 리포트를 수행합니다.

Managed Agents가 등장하면서 자연스럽게 의문이 생겼습니다. 기존 시스템 에이전트를 Managed Agents로 대체할 수 있을까? 그리고 그것이 올바른 선택일까?

이 글에서는 Managed Agents의 핵심 개념을 정리하고, 기존 시스템과의 비교, 실제 도입 시 마주치는 아키텍처 문제들을 실무 관점에서 다룹니다.

Managed Agents란 무엇인가#

핵심 개념#

Managed Agents는 네 가지 개념으로 구성됩니다.

비유하자면, Agent는 Docker 이미지이고 Session은 Docker 컨테이너입니다. 이미지를 만든다고 컨테이너가 뜨는 게 아니듯, agents.create()로 Agent를 정의한다고 바로 실행되는 것은 아닙니다. sessions.create()를 호출해야 실제 실행 인스턴스가 생성됩니다.

Brain / Hands / Session 분리#

Anthropic 엔지니어링 블로그에서 강조하는 핵심 설계 철학은 “Brain(두뇌)과 Hands(손)의 분리” 입니다.

• Brain: Claude 모델 + 하네스 (추론, 판단)
• Hands: 샌드박스 / 도구 (Bash, 파일 조작, 웹 검색 등 실제 작업 수행)
• Session: 이벤트 로그 (컨텍스트 윈도우 외부에 영속 저장)

이 세 컴포넌트가 독립적으로 실패하거나 교체될 수 있습니다. 컨테이너가 죽어도 세션 상태는 유지되고, 하네스가 크래시해도 새로운 하네스가 세션 로그를 읽어서 재개할 수 있습니다. OS가 하드웨어를 추상화한 것처럼, Managed Agents는 에이전트 컴포넌트를 추상화한 “메타 하네스” 입니다.

가격#

30분짜리 작업의 런타임 비용은 약 $0.04입니다.

현재 상태#

기본 기능은 API 키만 있으면 즉시 사용할 수 있습니다. Memory Store 등 고급 기능은 별도 신청이 필요합니다.

기존 시스템 에이전트와의 비교#

구조적 대응 관계#

필자의 시스템 에이전트와 Managed Agents의 대응 관계를 정리하면 다음과 같습니다.

Managed Agents가 내장하는 것#

Bedrock AgentCore와 Managed Agents 모두 에이전트 실행 환경을 제공하지만, 제공 범위가 다릅니다.

그렇다면 기존 시스템을 대체할 수 있는가?#

기능적으로는 대체 가능하지만, 구조적 트레이드오프가 있습니다.

대체 시 주의할 점:

1. 도구 호출이 네트워크 왕복으로 바뀔 수 있습니다. 기존에는 @tool 함수가 같은 프로세스 안에서 DB를 직접 호출합니다. Managed Agents에서 Custom Tool(정의형)을 사용하면 매 호출이 HTTP 왕복이 됩니다. 다만, sandbox 내에서 빌트인 Bash 도구로 스크립트를 직접 실행하면 이 문제를 우회할 수 있습니다.

2. 파이프라인 오케스트레이션의 제어력이 달라집니다. 기존에는 Python 코드로 “severity가 normal이 아닌 브랜드만 다음 단계로” 같은 조건 분기를 결정론적으로 처리합니다. Managed Agents의 Multi-agent는 에이전트가 자연어로 판단하는 구조이므로, 이런 분기를 프롬프트로 제어해야 합니다. 미들웨어에서 step별 Session을 순차 생성하는 방식으로 보완할 수 있습니다.

3. Research Preview 기능에 의존합니다. Multi-agent 오케스트레이션이 아직 GA(정식 출시)가 아닙니다. 이것 없이 파이프라인을 구현하려면 하나의 Agent 안에서 모든 것을 처리하거나, 미들웨어가 직접 오케스트레이션해야 합니다.

Memory Store — Anthropic이 호스팅하는 영속 메모리#

Memory Store는 Managed Agents의 Research Preview 기능 중 가장 주목할 만한 것입니다.

무엇인가#

Workspace 단위의 텍스트 문서 컬렉션으로, Anthropic 서버에 저장됩니다. 파일 경로 체계(/brands/A/strategy.md)로 구조화되어 있고, 세션에 연결하면 에이전트가 자동으로 메모리를 확인하고 기록합니다.

핵심 특성#

• Anthropic 호스팅: 데이터가 Anthropic 서버에 저장됩니다 (client-side가 아닙니다)
• API로 외부 접근 가능: 에이전트 세션 밖에서도 REST API로 읽기 / 쓰기 / 검색 가능
• 자동 관리: 에이전트에게 memory_list, memory_search, memory_read, memory_write, memory_edit, memory_delete 도구가 자동 부여
• 버전 관리: 모든 변경이 불변 버전으로 기록 (감사 / 롤백 가능)
• 세션당 최대 8개 Memory Store 연결 가능
• 개별 메모리 100KB 제한 (~25K 토큰)

write()는 append가 아니라 upsert#

# 같은 path → replace (이전 내용 교체, 버전 기록에는 남음)
client.beta.memory_stores.memories.write(
    memory_store_id=store.id,
    path="/config/strategy.md",
    content="새로운 전략 내용",
)

# 다른 path → 별도 문서 생성
client.beta.memory_stores.memories.write(
    memory_store_id=store.id,
    path="/config/kpi.md",
    content="KPI 목표",
)

하나의 Memory Store 안에 여러 개의 memory(문서)가 경로별로 존재하는 파일 시스템과 유사한 구조입니다.

에이전트가 메모리를 자율 관리한다#

Memory Store를 세션에 연결할 때 prompt를 통해 관리 지침을 줄 수 있습니다.

resources=[{
    "type": "memory_store",
    "memory_store_id": store.id,
    "access": "read_write",
    "prompt": "새 정보를 기록할 때 기존 파일에 병합하세요. "
              "outdated된 정보는 삭제하거나 갱신하세요.",
}]

Anthropic이 자동으로 중복 제거나 요약을 해주는 것은 아닙니다. Claude 에이전트가 도구를 사용해서 스스로 판단하고 관리하는 방식이며, 지침을 통해 관리 품질을 높일 수 있습니다.

로컬 에이전트와의 공유 계층#

Memory Store가 가장 빛나는 지점은 로컬 에이전트(Claude Code)와 시스템 에이전트(Managed Agents) 사이의 공유 지식 계층이 된다는 것입니다.

운영자가 로컬에서 전략 수립 → Memory Store에 기록 (API 호출)
    ↓
시스템 에이전트가 Memory Store에서 검색 → 최신 전략을 반영하여 동작

기존에는 로컬 에이전트의 지식 저장소를 시스템 에이전트가 참조할 수 없었습니다. Memory Store가 이 단절을 해소합니다. 다만, Research Preview 상태이므로 GA 전까지는 Custom Tool로 자체 DB를 조회하는 폴백이 필요합니다.

로컬 에이전트의 스킬을 Managed Agents로 옮길 수 있는가#

로컬 에이전트에는 운영자가 정의한 다양한 스킬(워크플로우 지침 파일) 이 있습니다. 예를 들어 “데일리 리뷰” 스킬은 GTD 기반으로 모든 소스를 스캔하고, 작업을 분류하고, 오늘의 할 일을 확정하는 워크플로우입니다.

이 스킬을 Managed Agents로 옮긴다면?

핵심 구분: 인간 참여형 vs 자율 실행형#

스킬의 지침 파일(수백 줄)을 통째로 Managed Agent 프롬프트에 넣는 것은 비현실적입니다. 로컬 스킬은 운영자와 함께 동작하도록 설계된 것이고, Managed Agents는 사람 없이 돌아가는 에이전트를 위한 것이므로, 같은 워크플로우라도 자율 실행 버전은 다른 프롬프트 설계가 필요합니다.

실제 패턴#

• 인간 참여형 스킬 (전략 수립, 최적화 사이클): 로컬 에이전트에 유지
• 완전 자율 실행형 (일일 모니터링, 자동 리포트): Managed Agents로 이관. 시스템 프롬프트 + Environment 파일 + Custom Tool로 분리
• 하이브리드: 로컬 에이전트가 Managed Agent 세션을 트리거. 자율 실행 구간만 위임하고 결과를 받아서 계속 진행

프롬프트 분산 문제는 해결되는가#

기존에 두 시스템(로컬 에이전트 + 시스템 에이전트)에 프롬프트, 컨텍스트, 실행 로직이 분산되는 것이 문제였다면, Managed Agents로 바꿔도 이 문제는 근본적으로 동일합니다. Managed Agents용 시스템 프롬프트와 로컬 스킬 파일은 여전히 별개의 문서로 관리해야 하고, 하나를 바꾸면 다른 쪽도 동기화해야 합니다.

다만, 개선되는 부분이 있습니다:

1. 코드 동거: Managed Agents 관련 코드(Agent 정의, 프롬프트)를 로컬 에이전트 프로젝트 안에 둘 수 있으므로, 별도 레포 / 별도 기술 스택의 부담이 줄어듭니다
2. Memory Store 공유 계층: 양쪽에서 같은 저장소를 읽고 쓸 수 있으므로, 지식 단절이 해소됩니다
3. 모델 동시성: 양쪽 모두 같은 Claude 모델을 사용하므로, 모델 버전 지연 문제가 없습니다

결론적으로, “동기화 문제를 근본적으로 해결하는 것"이 아니라 “동기화 비용을 줄이는 것” 입니다.

거버넌스 문제 — 누가 에이전트를 관리하는가#

로컬 에이전트 환경에 Managed Agents 코드를 두면 생기는 문제#

로컬 에이전트 환경은 운영자 각자의 작업 환경입니다. 여기에 agents.create() 같은 실행 코드를 두면:

• 운영자 A가 에이전트를 생성하고, 운영자 B도 같은 에이전트를 생성
• 누가 만든 게 실제 운영에 쓰이는 건지 파악 불가
• 마지막에 agents.update()를 호출한 사람의 설정이 반영

로컬 에이전트는 “각자의 작업 환경"이고, Managed Agents는 “공유 인프라"입니다. 이 성격이 충돌합니다.

해결 방향#

설정은 로컬에, 실행은 중앙에서.

로컬 에이전트 환경 (운영자)
  ├── 프롬프트, 도구 스펙 편집 가능 (yaml/md 파일)
  ├── 변경 사항 미리보기 가능 (diff 스크립트)
  └── 실제 Agent 변경은 불가 (API 키 없음)

중앙 관리 서비스 (개발자)
  ├── PR 머지 후 CI/CD가 Agent 업데이트
  ├── Agent 생성/수정/삭제 권한 보유
  └── B2C 서비스의 게이트키핑 역할

운영자가 프롬프트를 수정하면 Git PR을 올리고, 리뷰 후 머지되면 CI/CD가 agents.update()를 실행합니다. Agent를 직접 변경하는 권한은 파이프라인에만 있으므로, 충돌이나 중복 생성 문제가 구조적으로 방지됩니다.

B2C 서비스와의 분리#

내부 운영용(로컬 에이전트)과 고객 대면 서비스(B2C)의 거버넌스 요구사항은 다릅니다.

기존 시스템 에이전트 서비스는 “에이전트 실행"에서 “에이전트 관리 / 통제"로 역할이 전환됩니다. 에이전트 실행은 Managed Agents에 맡기고, 인증 / 인가, 비용 한도 체크, 프로덕션 Agent 버전 관리, 로그 / 모니터링 등의 게이트키핑 레이어로 남게 됩니다.

실무 판단 기준#

Managed Agents가 적합한 경우#

• 신규 에이전트를 빠르게 만들어야 할 때 (에이전트 루프를 직접 구축할 시간이 없을 때)
• 에이전트 인프라(상태 관리, 체크포인팅, 장애 복구) 유지보수 부담을 줄이고 싶을 때
• Claude 최신 모델을 즉시 사용하고 싶을 때 (Bedrock 리전 배포 대기 없이)
• 프로토타이핑 단계에서 빠르게 PoC를 만들어야 할 때

기존 시스템을 유지하는 게 나은 경우#

• 이미 잘 동작하는 시스템이 있고, 이관 비용 대비 이점이 불분명할 때
• 파이프라인의 결정론적 조건 분기가 중요할 때
• 데이터 주권 등의 이유로 데이터가 외부로 나가면 안 될 때
• Research Preview 기능(Multi-agent, Memory Store)이 GA되지 않아 프로덕션에 쓰기 불안할 때

결론#

Managed Agents의 진짜 가치는 “기존 시스템을 대체하는 것"이 아니라, “인프라를 직접 만드는 대신 플랫폼에 맡기고, 도메인 설계에 집중할 수 있다” 는 것입니다. 기존에 잘 동작하는 시스템을 굳이 이관하는 것보다, 신규 에이전트를 빠르게 만들어야 하는 상황에서 Managed Agents를 선택하는 것이 가장 현실적인 전략입니다.

참고 링크#

• Claude Managed Agents 공식 문서
• Scaling Managed Agents: Decoupling the brain from the hands
• Memory Store 문서