[한영자막] Anthropic Claude Managed Agents: 두뇌와 손을 분리한 설계 (1부)
Quick Summary
Anthropic Claude Managed Agents는 세션 기록·두뇌·손을 분리해 실행 환경과 하네스를 교체하면서 작업을 이어갈 수 있도록 설계됐다.
영상 보기
클릭 전까지는 가벼운 미리보기만 먼저 불러옵니다.
🖼️ 인포그래픽
![[한영자막] Anthropic Claude Managed Agents: 두뇌와 손을 분리한 설계 (1부) 내용을 설명하는 본문 이미지](/_next/image?url=%2Fpage-asset%2Fyoutube%2Fmanaged-agents-brain-hands-separation%2F5201.poster.png%3Fv%3Df0b8c3a2a50389e9&w=1536&q=75)
🖼️ 4컷 인포그래픽
![[한영자막] Anthropic Claude Managed Agents: 두뇌와 손을 분리한 설계 (1부)의 핵심 내용을 4단계로 요약한 인포그래픽](/_next/image?url=%2Fpage-asset%2Fyoutube%2Fmanaged-agents-brain-hands-separation%2F5201.4cut.png%3Fv%3D7c5edbed2d925ca3&w=1536&q=75)
💡 한 줄 결론
Anthropic Claude Managed Agents는 세션 기록·두뇌·손을 분리해 실행 환경과 하네스를 교체하면서 작업을 이어갈 수 있도록 설계됐다.
📌 핵심 요점
- 에이전트는 모델이 도구를 반복 호출하며 작업하는 구조다. 하네스는 도구 호출과 문맥 관리를 담당하며, 모델별 한계를 보완하는 가정도 포함한다.
- 초기 구조는 세션 로그·하네스·코드 실행을 한 컨테이너에 담았다. 구현은 단순했지만 장애 원인 구분, 고객 데이터가 있는 환경의 조사, 고객 VPC 연결이 어려웠다.
- 새 구조는 추가 전용 세션 로그, Claude와 하네스로 구성된 두뇌, 샌드박스·MCP 도구 같은 손을 분리한다. 샌드박스는 필요할 때 생성하고, 하네스는 세션 로그를 읽어 작업을 재개한다.
- 인증정보는 샌드박스에 넣지 않고 외부 호출 시 프록시가 주입한다. 원본 이벤트를 보존하므로 문맥 압축 전략도 바꿀 수 있으며, 발표자는 샌드박스 시작을 기다리지 않아 첫 토큰 도달 시간을 약 90% 줄였다고 설명한다.
- 실습의 기본 순서는 환경 생성 → 에이전트 정의 → 세션 생성 → 이벤트 전송이다. 영상 마지막은 콘솔의 빠른 시작 안내로 넘어가며, 실제 에이전트 실행 결과는 이 구간에 나오지 않는다.
🧩 배경과 문제 정의
이 영상은 Claude Managed Agents를 만든 엔지니어들이 개발 과정과 기본 API 개념을 설명하는 워크숍의 첫 부분이다. 전체 행사에서는 콘솔로 간단한 에이전트를 만들고 이후 코드로 금융 에이전트를 구성할 예정이라고 안내하지만, 제공된 영상은 아키텍처 설명과 첫 콘솔 실습 진입까지를 담는다.
핵심 문제는 에이전트를 이루는 세션 기록, 하네스, 코드 실행 환경을 한 컨테이너에 묶었을 때 생기는 운영 부담이다. 발표자는 이를 장애가 나면 개별적으로 돌봐야 하는 ‘펫’에 비유한다. 새 설계는 작업 이력을 별도로 보존하고 두뇌와 손을 분리해, 실행 구성요소를 교체하면서 작업을 이어가도록 한다.
🕒 시간순 섹션별 상세정리
1. 발표자 소개와 워크숍의 범위
- Anthropic의 Priyanka는 Claude Managed Agents를 만든 엔지니어링 팀을 이끌며, 최근 12개월 동안 에이전트 인프라 구축에 집중했다고 보여준다. Gabe Semach도 같은 팀의 개발자로 참여한다. [00:41]
- 진행 순서는 아키텍처의 발전 과정, 콘솔을 이용한 간단한 에이전트, 코딩 도구를 활용한 금융 에이전트, 질의응답이다. 참석자의 질문과 실습 참여를 독려한다. [01:48]
2. 에이전트·하네스·샌드박스의 역할
- 에이전트는 모델이 다음 행동을 결정하고 작업이 끝날 때까지 도구를 반복 호출하는 구조다. 하네스는 이 반복 실행과 문맥 관리 등을 맡아 모델의 부족한 부분을 보완한다. [02:44]
- 발표자는 Sonnet 4.5가 문맥 한도에 가까워지면 작업을 서둘러 마무리하는 현상을 예로 든다. 이를 위한 문맥 초기화 장치가 Opus 4.5에는 필요하지 않았다며, 하네스의 가정도 모델에 맞춰 갱신해야 한다고 보여준다. [03:29]
- 에이전트가 만든 코드는 오류가 있을 수 있으므로 실행 환경을 격리해야 한다. 작업마다 별도 컨테이너를 두어 파일 변경과 의존성 설치 등의 영향 범위를 제한하는 방식을 제시한다. [04:25]
3. 초기 단일 컨테이너 구조의 한계
- 초기 고객에게 제공한 구조는 세션 로그, 하네스, 샌드박스 실행을 모두 한 컨테이너에 넣었다. 서비스 경계를 설계할 필요가 없고 파일 조작이 로컬 호출로 끝나는 장점이 있었다. [05:17]
- 그러나 이 컨테이너는 쉽게 버리고 대체하기 어려운 ‘펫’이 됐다. 발표자는 이를 장애 시 다른 인스턴스로 대체할 수 있는 ‘캐틀’과 대비한다. [06:06]
- 패킷 손실과 컨테이너 장애를 구분하기 어려웠고, 고객 데이터가 들어 있는 컨테이너를 조사하는 데도 제약이 있었다. 고객 VPC 안의 MCP에 연결하려면 네트워크 피어링이나 고객 측 하네스 실행 등이 필요했다. [06:57]
4. 세션 기록·두뇌·손을 분리한 복구 구조
- 새 구조는 세 인터페이스로 나뉜다. 세션은 발생한 일을 쌓는 추가 전용 로그이고, 두뇌는 Claude와 하네스이며, 손은 샌드박스와 MCP 도구 호출 등이다. [07:26]
- 손에 해당하는 자원은 필요할 때 생성하고 작업이 끝나면 없앤다. 샌드박스 장애도 도구 호출 실패처럼 다루며, Claude나 하네스가 재생성하거나 다른 방식으로 진행할 수 있다. [07:56]
- 하네스가 죽으면 새 인스턴스가 세션 이벤트 로그를 읽어 작업을 이어간다. 발표자는 세션 로그를 보호하고 나머지 구성요소는 교체할 수 있게 만든 것이 핵심이라고 보여준다. [08:19]
5. 인증정보 보호·문맥 관리·응답 속도의 변화
- 인증정보를 샌드박스에 두지 않고, 인증이 필요한 외부 호출은 프록시를 거쳐 토큰을 주입한다. 모델이 토큰을 직접 보지 않으므로 토큰을 출력하거나 파일에 쓰라는 지시로 노출시키는 경로를 차단한다는 설명이다. [09:01]
- 원본 이벤트는 유지하고 모델 문맥에 넣을 정보만 별도로 선택한다. 전체 기록을 요약하거나 최근 이벤트를 사용하는 등 압축 전략을 바꿀 수 있으며, 추론을 먼저 시작하고 샌드박스를 필요할 때 생성해 첫 토큰 도달 시간을 약 90% 줄였다고 한다. [09:59]
- 하나의 하네스가 샌드박스, 고객 VPC, MCP 서버 등 여러 실행 대상을 사용할 수 있다. 발표자는 하네스의 가정이 낡더라도 인터페이스는 오래 유지되도록 설계해야 한다고 정리한다. [10:54]
6. 환경·에이전트·세션을 만드는 기본 절차
- 농담을 들려주는 간단한 에이전트를 예제로 실습을 시작한다. 첫 단계인 환경 API는 샌드박스 템플릿을 만들며, 네트워크 제한과 설치할 패키지 등을 정의한다. [11:47]
- 두 번째 단계에서는 에이전트 이름, 모델, 시스템 프롬프트, 도구를 정한다. 예제는 코미디언 역할과 함께 bash, 읽기·쓰기·검색 등의 기본 도구 모음을 사용한다. [12:31]
- 세 번째 단계에서는 에이전트 ID와 환경 ID로 세션을 만든다. 세션은 작업 단위이며, 생성 직후에는 유휴 상태이고 이벤트를 보내야 작업이 시작된다. [12:48]
7. 이벤트 처리 개념과 콘솔 실습 진입
- 세션에는 사용자가 보내는 메시지와 에이전트가 돌려주는 이벤트가 흐른다. 사용자 정의 도구는 도구 사용 이벤트를 수신해 외부에서 처리한 뒤 결과를 Claude에 반환하는 방식이다. [13:25]
- 오류, 유휴 상태, 작업 중단을 위한 이벤트도 보여준다. 멀티에이전트와 메모리는 뒤 워크숍에서 더 깊게 다룰 기능으로 나온다. [14:02]
- 마지막에는 콘솔의 Managed Agents 영역으로 이동해 첫 에이전트 생성을 안내하는 빠른 시작 기능을 보여준다. 제공된 영상은 이 안내에서 끝난다. [14:35]
🧾 결론
- 이 설계의 중심은 보존해야 할 세션 기록과 교체 가능한 실행 구성요소를 분리하는 데 있다.
- 하네스가 담고 있는 모델별 가정은 낡을 수 있으므로, 하네스와 문맥 관리 전략을 바꿔도 유지되는 인터페이스가 중요하다.
- 장애 복구, 인증정보 보호, 응답 시작 속도, 다양한 도구 연결은 같은 분리 설계에서 나온 이점으로 제시된다.
📈 투자·시사 포인트
- 에이전트 플랫폼의 도입 가치를 평가할 때 모델 성능과 함께 장애 복구 방식, 실행 격리, 고객 네트워크 연결성을 살펴볼 필요가 있다.
- 필요할 때만 샌드박스를 생성하는 구조는 자원 운용을 검토할 지점이다. 다만 영상에는 비용이나 이용률 수치가 없어 비용 절감 규모를 계산할 수 없다.
- 인증정보를 실행 환경에서 분리하고 세션 이벤트를 보존하는 방식은 기업용 에이전트의 운영 적합성을 판단하는 기준이 될 수 있다.
- 약 90%라는 개선치는 첫 토큰 도달 시간에 관한 발표자의 설명이다. 전체 작업 처리 속도나 투자수익률의 개선치로 확대 해석해서는 안 된다.
⚠️ 불확실하거나 확인이 필요한 부분
- 첫 토큰 도달 시간 약 90% 감소의 측정 환경, 비교 기준, 표본 수와 절대 지연시간은 제시되지 않는다.
- 모델이 토큰을 직접 보지 못하게 하는 설계는 설명되지만, 프롬프트 인젝션 전반이나 권한이 있는 도구의 오용까지 방지한다는 근거는 없다.
- 세션 로그를 통한 재개는 소개되지만, 외부 작업의 중복 실행 방지, 샌드박스 파일 복원, 로그 저장소 장애 대응은 설명되지 않는다.
- 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
- 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
- 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.
✅ 액션 아이템
- 현재 에이전트 구조에서 세션 기록, 하네스, 코드 실행 환경이 어디에 저장되고 실행되는지 구분해 그린다.
- 샌드박스 종료와 하네스 종료를 각각 가정하고, 어떤 기록으로 어디서부터 재개할지 점검한다.
- 인증정보가 모델 입력·샌드박스 환경·파일에 노출되는지 확인하고, 영상의 프록시 주입 방식과 비교한다.
- 간단한 실습을 환경 → 에이전트 → 세션 → 사용자 이벤트 순서로 구성하고, 오류·유휴·중단 이벤트의 처리 방식을 정한다.
❓ 열린 질문
- 세션 로그에서 작업을 재개할 때 이미 실행된 외부 도구 호출의 중복과 부작용은 어떻게 처리하는가?
- 교체된 샌드박스에는 이전 파일과 설치된 의존성을 어떤 방식으로 복원하는가?
- 인증 프록시는 호출 대상과 권한 범위를 어떻게 제한하며, 허용된 자격증명을 악용하는 요청에는 어떻게 대응하는가?