Claude Managed Agents 를 알아보자.

요즘 AI 에이전트를 만들겠다고 하면 많은 팀이 비슷한 고민에서 출발한다.

“모델은 Claude를 쓰면 될 것 같은데,
에이전트 루프는 직접 짜야 하나?”
“샌드박스는 어떻게 띄우지?”
“도구 실행은 어디서 관리하지?”
“파일시스템 상태는 어떻게 유지하지?”
“장시간 작업이 끊기면 어떻게 복구하지?”
“실행 중간에 사용자가 끼어들 수 있게 하려면 또 SSE를 직접 붙여야 하나?”

예전에는 이 질문들이 전부 개발자의 몫이었다.

모델 API는 말 그대로 모델에게 메시지를 보내고 응답을 받는 인터페이스에 가까웠다. 그래서 “에이전트”를 만들려면 모델 바깥에 별도의 실행 구조를 직접 설계해야 했다.

예를 들면 이런 것들이다.

모델이 다음 행동을 결정한다.
필요하면 도구를 호출한다.
도구 실행 결과를 다시 모델에게 넣는다.
모델이 또 다음 행동을 결정한다.
중간 산출물을 파일로 저장한다.
작업이 길어지면 컨텍스트를 압축한다.
세션을 다시 열었을 때 이전 상태를 복원한다.
사용자가 중간에 “그 방향 말고 이렇게 해줘”라고 하면 실행 흐름을 바꾼다.

이 전체 구조가 흔히 말하는 에이전트 루프다.

문제는 이 루프를 직접 짜기 시작하면 금방 일이 커진다는 것이다. 처음에는 단순한 tool calling처럼 보이지만, 실제 제품으로 만들려면 런타임, 파일시스템, 샌드박스, 권한, 로그, 스트리밍, 세션 상태, 재시도, 중단, 복구, 보안까지 다뤄야 한다.

Claude Managed Agents는 이 지저분한 영역을 상당 부분 “관리형 실행 골격”으로 묶어버린 시도에 가깝다.

쉽게 말하면 Claude에게 단순히 한 번 답변을 받는 것이 아니라, Claude가 특정 환경 안에서 파일을 읽고, 명령을 실행하고, 웹을 참고하고, 도구를 쓰면서 긴 작업을 수행할 수 있도록 Anthropic이 미리 구성해둔 에이전트 실행 시스템이다.

Messages API와 Claude Managed Agents는 다르다

Claude를 쓴다고 해서 모두 같은 방식으로 쓰는 것은 아니다.

가장 기본적인 방식은 Messages API다.

Messages API는 개발자가 Claude에게 메시지를 보내고 응답을 받는 방식이다. 챗봇, 문서 요약, 코드 설명, 간단한 tool calling, 커스텀 워크플로우를 만들 때 적합하다.

이 방식의 장점은 통제권이다.
개발자가 루프를 직접 설계할 수 있고, 어떤 도구를 언제 호출할지, 상태를 어디에 저장할지, 어떤 런타임을 쓸지 직접 결정할 수 있다.

반대로 Claude Managed Agents는 조금 다르다.

여기서는 개발자가 에이전트가 사용할 모델, 시스템 프롬프트, 도구, MCP 서버, 스킬 등을 설정하고, 그 에이전트를 실행할 환경과 세션을 만든다. 그러면 Anthropic이 제공하는 하네스 안에서 에이전트가 작업을 수행한다.

즉 Messages API가 “모델을 직접 호출하는 방식”이라면, Claude Managed Agents는 “에이전트 실행 환경을 호출하는 방식”에 가깝다.

비유하자면 이렇다.

Messages API는 엔진을 직접 받아 차를 조립하는 방식에 가깝다.
Claude Managed Agents는 엔진, 차체, 운전석, 기본 제어장치가 들어간 차량을 받아 목적지와 운전 규칙을 설정하는 방식에 가깝다.

물론 후자가 항상 더 낫다는 뜻은 아니다.
직접 만든 루프가 경쟁력인 팀이라면 Messages API가 더 적합할 수 있다. 반대로 긴 작업, 상태 유지, 샌드박스 실행, 도구 사용, 비동기 작업이 중요하다면 Claude Managed Agents가 훨씬 빠른 출발점이 될 수 있다.

핵심 개념은 네 가지다

Claude Managed Agents를 이해하려면 네 가지 개념만 먼저 잡으면 된다.

Agent.
Environment.
Session.
Events.

이 네 가지를 이해하면 문서의 절반은 읽은 셈이다.

1. Agent: 재사용 가능한 에이전트 설정

Agent는 에이전트의 정체성을 정의하는 설정이다.

여기에는 모델, 시스템 프롬프트, 도구, MCP 서버, 스킬 등이 포함된다.

예를 들어 “리서치 에이전트”를 만든다고 해보자.

이 에이전트는 다음과 같은 설정을 가질 수 있다.

모델은 Claude Sonnet 계열을 사용한다.
시스템 프롬프트에는 “너는 시장 조사 전문 리서처다”라고 적는다.
웹 검색 도구를 사용할 수 있다.
파일 읽기와 쓰기 도구를 사용할 수 있다.
리포트 작성 스킬을 붙인다.
필요하면 특정 MCP 서버와 연결한다.

이렇게 한 번 Agent를 만들어두면 매번 같은 설정을 다시 보낼 필요가 없다. Agent ID로 재사용할 수 있다.

이 점이 중요하다.

일반적인 모델 호출에서는 매번 시스템 프롬프트와 도구 설정을 요청에 포함시키는 경우가 많다. 하지만 Managed Agents에서는 “이런 성격과 도구를 가진 에이전트” 자체를 하나의 재사용 단위로 만든다.

예를 들어 회사 내부에서 다음과 같은 에이전트를 각각 만들 수 있다.

시장 조사 에이전트
고객 응대 에이전트
코드 리뷰 에이전트
문서 정리 에이전트
데이터 분석 에이전트
경쟁사 모니터링 에이전트

각 Agent는 독립적인 역할, 도구, 시스템 프롬프트를 가진다. 그리고 실제 작업을 할 때는 해당 Agent를 호출해 세션을 만든다.

Agent는 “누가 일할 것인가”를 정의하는 개념이다.

2. Environment: 에이전트가 실제로 도는 장소

Agent가 “누가 일할 것인가”라면, Environment는 “어디서 일할 것인가”에 해당한다.

Claude Managed Agents에서 에이전트는 어떤 환경 안에서 실행된다. 이 환경은 Anthropic이 관리하는 클라우드 샌드박스일 수도 있고, 자체 인프라에 올린 셀프호스팅 샌드박스일 수도 있다.

이 개념이 중요한 이유는 에이전트가 단순히 텍스트만 생성하는 존재가 아니기 때문이다.

에이전트가 파일을 읽고, 명령을 실행하고, 웹을 참고하고, 코드를 실행하려면 실제 실행 공간이 필요하다. 이 공간이 샌드박스다.

샌드박스가 있다는 것은 에이전트가 “생각만 하는 모델”에서 “실행할 수 있는 작업자”에 가까워진다는 뜻이다.

예를 들어 이런 일이 가능해진다.

파일을 업로드한다.
에이전트가 파일을 읽는다.
필요한 데이터를 추출한다.
파이썬 스크립트를 실행한다.
결과 파일을 생성한다.
보고서를 작성한다.
사용자가 중간에 방향을 바꾸면 그에 맞게 작업을 수정한다.

이 모든 작업은 어딘가에서 실행되어야 한다. 그 실행 공간을 관리하는 것이 Environment다.

클라우드 샌드박스를 쓰면 인프라 부담이 줄어든다.
셀프호스팅 샌드박스를 쓰면 데이터 위치, 보안, 컴플라이언스 통제를 더 강하게 가져갈 수 있다.

즉 Environment는 단순 설정값이 아니라, 에이전트 제품의 운영 방식과 보안 구조를 결정하는 핵심 요소다.

3. Session: 상태가 유지되는 실행 인스턴스

Session은 실제 작업 단위다.

Agent가 역할이고, Environment가 장소라면, Session은 “이번에 실제로 돌아가는 작업 인스턴스”다.

예를 들어 “경쟁사 A, B, C의 최근 제품 업데이트를 조사해서 표로 정리해줘”라는 작업을 실행한다고 해보자.

이때 하나의 Session이 생성된다.

이 Session 안에서 에이전트는 웹을 검색하고, 중간 메모를 남기고, 파일을 만들고, 결과를 정리한다. 중요한 점은 Session이 상태를 가진다는 것이다.

즉 한 번 요청하고 끝나는 stateless 호출이 아니라, 파일시스템과 대화 기록, 실행 결과가 일정한 세션 안에서 유지된다.

이 구조는 장시간 작업에 특히 중요하다.

예를 들어 30분짜리 리서치 작업을 한다고 해보자. 중간에 사용자가 이렇게 말할 수 있다.

“미국 시장 말고 한국 시장 중심으로 다시 봐줘.”
“가격 비교는 빼고 기능 차이만 정리해줘.”
“방금 찾은 자료 중 공식 문서만 남겨줘.”
“최종 결과를 표와 요약문 두 가지 버전으로 만들어줘.”

상태가 없는 구조라면 매번 지금까지의 흐름과 파일, 중간 결과를 다시 설명해야 한다. 하지만 Session이 유지되면 에이전트는 같은 작업 맥락 안에서 이어서 움직일 수 있다.

Session은 “지금 진행 중인 작업의 살아있는 작업실”에 가깝다.

4. Events: 앱과 에이전트가 주고받는 실시간 흐름

Events는 애플리케이션과 에이전트 사이에서 오가는 메시지 흐름이다.

사용자의 메시지도 Event다.
에이전트의 상태 업데이트도 Event다.
도구 실행 결과도 Event다.
중간 진행 상황도 Event다.
사용자가 실행 중간에 끼어드는 것도 Event다.

Claude Managed Agents에서는 이 이벤트 흐름을 통해 앱과 에이전트가 상호작용한다. 특히 SSE, 즉 Server-Sent Events 기반 스트리밍을 통해 실행 중인 결과를 실시간으로 받아볼 수 있다.

이게 왜 중요할까?

에이전트 작업은 일반 챗봇 응답보다 오래 걸릴 수 있다. 몇 초 안에 끝나는 답변도 있지만, 실제 리서치, 코드 수정, 파일 분석, 데이터 처리 같은 작업은 몇 분 이상 걸릴 수 있다.

그런데 사용자가 아무 피드백 없이 빈 화면만 보고 있으면 제품 경험이 나빠진다.

그래서 실행 중간에 이런 상태를 보여줘야 한다.

“자료를 찾는 중입니다.”
“파일을 분석하는 중입니다.”
“코드를 실행했습니다.”
“결과를 정리하고 있습니다.”
“사용자 입력을 기다리고 있습니다.”

또 사용자가 중간에 방향을 바꿀 수도 있어야 한다.

예를 들어 에이전트가 리서치 중인데 사용자가 이렇게 보낸다.

“잠깐, 스타트업 사례 말고 대기업 사례만 봐줘.”
“그 자료는 제외해줘.”
“최종 결과는 블로그 글 말고 표로 정리해줘.”

이런 개입이 Events를 통해 가능해진다.

Events는 “에이전트가 지금 무엇을 하고 있고, 앱이 어떻게 개입할 수 있는가”를 다루는 통신 계층이다.

실제 동작 흐름

Claude Managed Agents의 기본 흐름은 단순하게 보면 다음과 같다.

먼저 Agent를 만든다.
그다음 Environment를 만든다.
이후 특정 작업을 위해 Session을 시작한다.
사용자 메시지를 Event로 보낸다.
에이전트가 도구를 쓰고 작업을 수행한다.
결과와 진행 상황이 Event 스트림으로 돌아온다.
필요하면 사용자가 중간에 추가 Event를 보내 방향을 수정한다.
작업이 끝나면 결과를 받는다.

이 흐름을 제품 관점으로 바꾸면 더 명확해진다.

사용자가 앱에서 “이번 주 AI 뉴스 요약해줘”라고 입력한다.
백엔드는 미리 만들어둔 뉴스 리서치 Agent ID를 사용한다.
해당 Agent를 실행할 Environment를 지정한다.
새 Session을 만든다.
사용자 요청을 Event로 보낸다.
에이전트는 웹 검색, 문서 읽기, 요약, 정리를 수행한다.
앱은 SSE로 중간 진행 상황을 보여준다.
사용자가 “한국 사용자에게 중요한 것만 남겨줘”라고 중간에 입력한다.
그 메시지도 Event로 들어간다.
에이전트는 방향을 수정해 최종 결과를 만든다.

이 구조를 직접 만들려면 꽤 많은 인프라가 필요하다.
Claude Managed Agents는 이 중 상당 부분을 플랫폼 레벨에서 제공하려는 방식이다.

예시 1: 시장 조사 에이전트

가장 이해하기 쉬운 예시는 시장 조사 에이전트다.

예를 들어 사용자가 이렇게 요청한다고 해보자.

“초등학생용 AI 학습관리 앱을 만들려고 합니다. 최근 시장 사례를 조사하고, 핵심 기능과 차별화 전략을 정리해 주세요.”

일반적인 모델 API만 사용하면 모델은 알고 있는 범위에서 답하거나, 개발자가 별도로 웹 검색 도구와 루프를 붙여야 한다.

Managed Agents 방식에서는 다음과 같이 설계할 수 있다.

Agent는 “교육 시장 리서치 에이전트”로 만든다.
시스템 프롬프트에는 교육 앱, 학습관리, 학부모 UX, 구독 모델 분석에 강한 리서처 역할을 부여한다.
도구로 웹 검색과 파일 작성 기능을 허용한다.
Environment는 클라우드 샌드박스를 사용한다.
Session을 만들어 사용자의 요청을 넣는다.

그러면 에이전트는 검색하고, 자료를 읽고, 중간 메모를 만들고, 최종 보고서를 작성한다.

중간에 사용자가 이렇게 개입할 수도 있다.

“한국 앱 위주로 봐줘.”
“초등학생보다는 학부모 결제 관점으로 다시 정리해줘.”
“최종 결과를 PRD에 바로 넣을 수 있는 형식으로 바꿔줘.”

이런 요청이 같은 Session 안에서 이어진다.

결과적으로 사용자는 단순 답변이 아니라, 작업을 이어가는 리서치 에이전트를 경험하게 된다.

예시 2: 코드 수정 에이전트

두 번째 예시는 코드 수정이다.

사용자가 GitHub 저장소나 압축 파일을 올리고 이렇게 요청한다고 해보자.

“이 Next.js 앱을 배포 전 기준으로 점검하고, 치명적인 문제부터 수정해 주세요.”

에이전트는 파일시스템을 읽어야 한다.
코드를 검색해야 한다.
필요하면 테스트를 실행해야 한다.
문제를 발견하면 파일을 수정해야 한다.
수정 내역을 요약해야 한다.

이 작업은 단순한 챗봇 응답보다 훨씬 복잡하다.

Managed Agents의 장점은 여기서 분명해진다.

Session 안에 파일 상태가 유지된다.
Bash 같은 도구로 명령을 실행할 수 있다.
파일 읽기, 쓰기, 편집을 수행할 수 있다.
실행 결과를 바탕으로 다음 행동을 이어갈 수 있다.
사용자는 중간에 방향을 수정할 수 있다.

예를 들어 에이전트가 보안 이슈를 고치고 있는데 사용자가 이렇게 말할 수 있다.

“지금은 보안보다 모바일 UI 깨지는 문제부터 먼저 봐줘.”
“수정은 하지 말고 리포트만 만들어줘.”
“테스트 실패 원인만 따로 정리해줘.”

이것이 가능한 이유는 Session과 Events가 있기 때문이다.

예시 3: 콘텐츠 제작 에이전트

세 번째 예시는 콘텐츠 제작이다.

예를 들어 매일 아침 AI 뉴스를 수집해 카드뉴스 원고를 만드는 에이전트를 생각해보자.

Agent는 “AI 뉴스 큐레이터”로 설정한다.
도구로 웹 검색과 파일 작성 기능을 붙인다.
시스템 프롬프트에는 한국 사용자에게 실용적인 뉴스만 고르라는 기준을 넣는다.
Session마다 “오늘 날짜의 AI 뉴스 8개를 골라 카드뉴스용 원고로 정리하라”는 작업을 실행한다.

에이전트는 뉴스를 검색하고, 출처를 확인하고, 헤드라인을 만들고, 카드별 문안을 구성한다.

사용자가 중간에 이렇게 말할 수도 있다.

“개발자 도구 뉴스만 남겨줘.”
“너무 딱딱하니 X 타래 톤으로 바꿔줘.”
“카드뉴스 10장 구성으로 다시 나눠줘.”

이런 콘텐츠 워크플로우는 상태 유지와 중간 개입이 중요하다. Managed Agents 구조는 이런 장시간, 다단계 작업에 잘 맞는다.

왜 중요한가

Claude Managed Agents가 중요한 이유는 “에이전트 개발의 기본 단위”가 바뀌고 있기 때문이다.

이전에는 개발자가 모델 호출 위에 직접 에이전트 루프를 얹어야 했다.

프롬프트 관리.
도구 호출.
실행 결과 파싱.
컨텍스트 압축.
파일 저장.
샌드박스 관리.
스트리밍.
중간 개입.
세션 복구.
권한 관리.

이 모든 것을 직접 설계해야 했다.

하지만 Managed Agents는 이 중 상당 부분을 플랫폼이 제공한다. 개발자는 “어떤 에이전트를 만들 것인가”, “어떤 환경에서 실행할 것인가”, “어떤 세션을 만들 것인가”, “어떤 이벤트를 주고받을 것인가”에 집중할 수 있다.

즉 개발자의 관심사가 인프라에서 제품 설계로 이동한다.

물론 이것이 모든 문제를 해결한다는 뜻은 아니다.
하지만 에이전트 앱을 만들 때 매번 반복해서 짜던 기본 실행 골격을 줄여준다는 점에서 의미가 크다.

그래도 직접 만드는 게 나은 경우

Claude Managed Agents가 무조건 정답은 아니다.

다음과 같은 경우에는 직접 루프를 짜는 편이 나을 수 있다.

첫째, 멀티벤더 전략이 중요한 경우다.

Claude뿐 아니라 OpenAI, Gemini, 로컬 모델, 오픈소스 모델을 상황에 따라 라우팅해야 한다면 특정 플랫폼의 관리형 하네스에 강하게 묶이는 것이 부담이 될 수 있다.

둘째, 세밀한 제어가 필요한 경우다.

모델이 언제 어떤 도구를 호출하는지, 루프를 몇 번 돌릴지, 실패 시 어떤 전략을 쓸지, 비용을 어떻게 제한할지 아주 세밀하게 통제해야 한다면 직접 구현이 더 적합할 수 있다.

셋째, 데이터 보존이나 규제 요건이 엄격한 경우다.

Managed Agents는 상태 저장을 전제로 한다. 세션 기록, 파일 상태, 산출물이 서버 측에 유지되는 구조이므로 Zero Data Retention 같은 요건이 중요한 조직은 별도 검토가 필요하다.

넷째, 자체 에이전트 런타임이 이미 경쟁력인 경우다.

어떤 팀은 이미 LangGraph, 자체 샌드박스, 큐 시스템, 권한 관리, 도구 실행기를 잘 구축해두었을 수 있다. 이런 팀에게 Managed Agents는 오히려 자유도를 줄이는 선택일 수 있다.

제품 기획 관점에서 봐야 할 포인트

기술적으로는 “에이전트 하네스”가 핵심이지만, 제품 기획자 입장에서는 조금 다르게 봐야 한다.

Claude Managed Agents는 사용자가 “AI에게 일을 맡긴다”는 경험을 만들기 위한 백엔드 구조에 가깝다.

단순 챗봇은 사용자가 질문하면 답한다.
에이전트 제품은 사용자가 일을 맡기면 진행하고, 중간에 보고하고, 결과물을 만든다.

이 차이가 크다.

예를 들어 사용자가 “이 문서 요약해줘”라고 하면 챗봇으로도 충분하다.
하지만 “이 문서를 읽고, 관련 자료를 조사하고, 경쟁사 사례와 비교해서, 내일 회의용 1페이지 보고서로 만들어줘”라고 하면 에이전트 실행 구조가 필요하다.

Claude Managed Agents는 바로 이런 종류의 작업에 맞춰져 있다.

기획자는 다음 질문을 먼저 해야 한다.

이 작업은 몇 초짜리 답변인가, 몇 분 이상 걸리는 작업인가?
도구 실행이 필요한가?
파일을 읽고 쓰는가?
중간 산출물이 있는가?
사용자가 실행 중간에 방향을 바꿀 가능성이 있는가?
작업 상태를 저장해야 하는가?
작업 결과를 나중에 다시 이어서 볼 필요가 있는가?

이 질문에 “예”가 많을수록 Managed Agents에 가까운 구조가 어울린다.

한 문장으로 정리하면

Claude Managed Agents는 Claude를 단순히 답변 생성 모델로 쓰는 것이 아니라, 상태를 가진 샌드박스 안에서 도구를 사용하며 장시간 작업을 수행하는 에이전트로 실행하기 위한 관리형 하네스다.

Agent는 일할 사람의 설정이다.
Environment는 일할 장소다.
Session은 실제 작업실이다.
Events는 작업 중 오가는 실시간 대화와 상태 흐름이다.

이 네 가지를 이해하면 Claude Managed Agents의 큰 그림은 잡힌다.

마지막으로

에이전트 시대의 개발은 “모델에게 무슨 프롬프트를 보낼까”에서 “어떤 실행 구조를 제품 안에 넣을까”로 넘어가고 있다.

예전에는 그 실행 구조를 직접 만들어야 했다.
이제는 플랫폼이 그 일부를 제공하기 시작했다.

Claude Managed Agents는 그 흐름을 보여주는 대표적인 사례다.

물론 아직 베타이고, 기능이나 제약은 바뀔 수 있다.
규제 요건, 데이터 보존 정책, 멀티벤더 전략, 비용 구조를 꼼꼼히 봐야 한다.

하지만 적어도 한 가지는 분명하다.

앞으로 에이전트 앱을 만들 때 매번 에이전트 루프, 샌드박스, 도구 실행기, 상태 저장 세션을 처음부터 직접 짜야 한다고 생각할 필요는 점점 줄어들고 있다.

이제 중요한 질문은 이것이다.

“에이전트 인프라를 직접 짤 것인가?”가 아니라,
“우리 제품에서 어떤 일을 에이전트에게 맡길 것인가?”다.

 

Claude Managed Agents overview