두뇌와 손을 분리한 Claude Managed Agents 설계

원문 제목: [한영자막] Anthropic Claude Managed Agents: 두뇌와 손을 분리한 설계 (1부) URL: https://www.youtube.com/watch?v=3iOP4cXChAc 날짜: 2026-10-18 채널: Tech Bridge

📌 핵심 질문 / 이 발표가 다루는 핵심 논점

Claude 기반 에이전트를 실제 서비스 규모로 운영할 때, 모델의 추론과 도구 실행 환경을 어떻게 나누어야 장애 복구·보안·응답 속도·확장성을 함께 얻을 수 있는가? 핵심은 ==지속성을 세션 이벤트 로그에 두고, 두뇌(harness)와 손(sandbox·도구)을 교체 가능한 구성요소로 분리하는 것==이다.

• 에이전트는 도구를 호출하며 작업을 완수하는 모델 루프이고, harness는 루프·도구 호출·컨텍스트 관리 등 모델 바깥의 책임을 맡는다.
• 모든 기능을 하나의 컨테이너에 넣은 초기 구조는 단순했지만, 컨테이너 자체가 오래 살려 관리해야 하는 ‘반려동물(pet)’이 되어 장애 진단과 고객 네트워크 연결이 어려웠다.
• 세션 로그를 보존하고 harness와 실행 샌드박스를 분리하면 각 구성요소를 가축(cattle)처럼 다시 띄울 수 있으며, 자격 증명 격리와 더 빠른 첫 응답도 가능해진다.

모델과 그 주변 실행환경은 계속 바뀌므로 특정 harness의 가정을 아키텍처의 영구 조건으로 만들면 안 된다. 세션은 append-only 기록으로 보존하고, 추론 루프와 여러 실행 도구를 명확한 인터페이스로 연결하면 각 계층을 독립적으로 복구·교체·확장할 수 있다. 발표 후반부에는 이 개념을 Claude Platform의 Environment·Agent·Session API와 이벤트 흐름을 이용해 간단한 농담 에이전트로 구성하는 순서를 소개한다.

1. 에이전트의 기본 구성과 harness의 역할

에이전트의 핵심은 모델 혼자 답을 생성하는 것이 아니라, 모델이 다음 행동을 고르고 도구를 호출하는 루프를 통해 일을 끝내는 데 있다.

1.1. 모델 루프와 도구 호출

1. 에이전트는 도구를 사용하는 반복 루프다
   1. 행동 선택: 모델이 현재 상태를 보고 다음에 취할 행동을 결정한다.
   2. 도구 실행과 반복: 모델이 도구를 호출하고 결과를 받은 뒤 다시 판단하며, 작업이 완료될 때까지 이 과정을 반복한다.
2. 도구가 실제 작업 능력을 보탠다
   1. 실행 공간: 모델이 작성한 코드를 실행하고 파일을 편집할 샌드박스나 컴퓨터가 필요하다.
   2. 외부 기능 연결: 파일 조작뿐 아니라 MCP 서버, 고객 VPC 안의 서비스 같은 외부 도구도 에이전트가 사용할 수 있다.

1.2. harness가 모델 바깥에서 맡는 일

1. 루프와 상태를 운영한다
   1. 반복 제어: harness는 모델 호출, 도구 실행, 결과 전달을 묶어 작업이 끝날 때까지 루프를 관리한다.
   2. 컨텍스트 관리: 모델이 다음 판단에 필요한 정보를 구성하고, 모델 자체가 처리하지 못하는 실행 책임을 캡슐화한다.
2. 모델별 한계를 보완하되 가정의 변화를 흡수한다
   1. Sonnet 4.5 사례: 발표자는 Sonnet 4.5가 컨텍스트 한도에 가까워졌다고 느끼면 일을 서둘러 마무리하려는 ‘context anxiety’를 보였다고 설명했다. 이를 보완하려고 당시 harness에 컨텍스트 리셋을 넣을 수 있었다.
   2. Opus 4.5와 대비: 다음 모델인 Opus 4.5에는 같은 제한이 없어서 컨텍스트 리셋이 필요하지 않았다. 특정 모델의 행동을 전제로 한 harness 규칙은 새 모델이 나오면 낡을 수 있다.

1.3. 실행 샌드박스와 격리

1. 모델이 만든 코드는 신뢰할 수 없는 실행물이다
   1. 작업 환경: 샌드박스나 컨테이너에서 코드를 실행하고 파일을 수정하며 필요한 의존성을 설치한다. Claude Code가 로컬 컴퓨터의 파일을 바꾸며 작업하는 방식이 익숙한 예다.
   2. 오류 가능성: 작성된 코드에는 버그가 있을 수 있으므로 프로덕션 에이전트에서는 실행 범위를 통제해야 한다.
2. 작업 간 영향 범위를 제한한다
   1. 컨테이너 격리: 각 작업을 별도 컨테이너에서 실행하면 한 작업의 문제나 데이터가 다른 작업으로 번지는 범위를 줄일 수 있다.
   2. blast radius 축소: 샌드박스는 격리되어야 하며, 컨테이너 단위로 작업을 분리하는 것이 장애의 영향 반경을 제한하는 기본 설계다.

2. 모든 것을 컨테이너에 넣은 초기 구조와 한계

초기 구조는 로컬에서 구현하기 쉬웠지만, 세션의 상태·harness·실행 환경을 한 컨테이너에 결합해 컨테이너를 반드시 살려야 하는 단일 단위로 만들었다.

2.1. 초기 아키텍처의 구성과 장점

1. 세션 하나가 작업 단위였다
   1. 세션 로그: 해당 세션에서 일어난 모든 일을 담은 로그가 컨테이너 안에 있었다.
   2. 실행과 조정의 결합: harness도 컨테이너 안에서 실행되고 샌드박스 코드 실행 역시 같은 컨테이너 안에서 이루어졌다.
2. 구현 경계가 단순했다
   1. 서비스 경계 불필요: 모든 것이 한곳에서 동작하므로 여러 서비스 사이의 인터페이스를 설계할 필요가 거의 없었다.
   2. 직접적인 파일 조작: 로컬 파일 수정은 사실상 시스템 호출(syscall)처럼 다룰 수 있어 편집하기 쉬웠다.

2.2. ‘pet’이 된 컨테이너와 운영 문제

1. 반려동물과 가축의 차이가 운영 모델을 설명한다
   1. pet: 이름을 붙이고 손으로 돌보는 개별 인스턴스다. 아프면 되살려야 하고, 잃어버릴 수 없다고 여긴다.
   2. cattle: 서로 교체 가능한 인스턴스다. 하나가 고장 나면 다른 것을 띄우고 계속 진행한다. 발표자는 단일 데이터베이스 샤드가 죽으면 제품 전체가 멈추는 경우를 pet에, 마스터가 내려가도 replica를 다시 올릴 수 있는 구조를 cattle에 비유했다.
2. 한 컨테이너가 상태와 실행을 모두 붙잡았다
   1. 장애 진단의 모호성: 컨테이너 안에서 모든 것이 돌아가므로 패킷 유실과 컨테이너 사망이 비슷한 현상으로 보였다. 문제를 조사하려면 컨테이너 안으로 WebSocket을 연결해야 했다.
   2. 고객 데이터 접근의 어려움: 고객 데이터가 컨테이너에 놓여 있어 운영팀이 내부에 들어가 조사하고 디버깅하기 어려웠다.
3. 고객 네트워크 연동이 비쌌다
   1. VPC의 MCP 연결: 고객이 자기 VPC 안의 MCP에 연결하려 하면 네트워크 피어링이 필요했다.
   2. 대안의 부담: harness 자체를 고객에게 전달해 고객 환경에서 실행하게 하는 방법도 고려해야 했고, 초기 구조만으로는 이 문제들을 깔끔하게 해결하기 어려웠다.

3. ‘두뇌’와 ‘손’을 분리한 새로운 구조

핵심 변경은 에이전트의 상태·판단·실행을 세 인터페이스로 나누고, 작업의 연속성은 세션 로그가 책임지게 한 것이다.

3.1. 세 인터페이스: session, brain, hands

1. session은 작업의 지속 기록이다
   1. append-only 이벤트 로그: 세션에서 일어난 모든 사건을 순서대로 추가하는 기록이며, 작업의 단위이자 복구 기준이다.
   2. 다른 구성요소와 분리: 세션 기록을 컨테이너 내부 프로세스와 동일시하지 않으므로 실행 인스턴스와 별도로 보존할 수 있다.
2. brain은 Claude와 harness다
   1. 판단과 루프: 가운데의 brain은 Claude와 에이전트 루프 또는 harness를 합친 역할을 한다.
   2. 인터페이스 기반 교체: 모델을 둘러싼 가정이 바뀌어 harness를 교체해도 세션 및 실행 도구와의 경계는 유지할 수 있다.
3. hands는 실제 행동을 실행한다
   1. 다양한 실행 수단: 샌드박스 컨테이너, 고객 VPC, MCP 도구 호출 등이 손의 역할을 한다.
   2. 필요할 때 생기고 작업 후 사라짐: hands는 필요할 때 프로비저닝하고 일이 끝나면 제거할 수 있으며, 한 brain이 여러 종류의 hands를 호출할 수 있다.

3.2. 장애 복구를 전제로 한 cattle 모델

1. 샌드박스는 실패 가능한 도구 호출로 취급한다
   1. 실패 뒤 선택: 샌드박스가 죽으면 호출 결과가 실패로 돌아오고, Claude/harness는 이를 보고 샌드박스를 다시 띄울지 다른 방식으로 계속할지 결정한다.
   2. 교체 가능성: 샌드박스는 세션을 독점하는 필수 생명선이 아니라 다른 도구처럼 호출하고 대체할 수 있는 구성요소다.
2. harness도 다시 시작해 이어갈 수 있다
   1. 새 인스턴스 기동: harness가 죽으면 새 harness 인스턴스를 띄운다.
   2. 이벤트 로그에서 재개: 새 인스턴스가 세션 이벤트 로그를 읽고 마지막 이벤트 이후부터 계속하므로, 실행 중이던 프로세스가 사라져도 작업을 복원할 수 있다.
3. 보존할 것은 세션 로그다
   1. 지속성의 기준: 나머지 구성요소는 내려갔다 다시 올라올 수 있으며, 작업 연속성을 지키는 핵심은 세션 로그다.
   2. 장애를 정상 경로로 흡수: 일시적 구성요소 장애를 복구 불가능한 세션 손실로 만들지 않는다.

4. 보안·컨텍스트·속도에서 얻는 효과

분리된 경계는 실행 장애의 복구만 돕는 것이 아니다. 자격 증명을 모델과 샌드박스 밖에 두고, 원본 이벤트를 보존하며, 느린 샌드박스 준비와 추론을 분리한다.

4.1. 자격 증명을 sandbox에 넣지 않는다

1. 이전 구조는 prompt injection에 취약했다
   1. 토큰 노출: 과거 구성에서는 고객 자격 증명이 샌드박스 안에 들어갔다.
   2. 유출 경로: 악의적인 지시가 모델을 속여 토큰을 보여 주거나 출력하고 파일에 기록하게 만들 수 있었다.
2. 인증 프록시가 비밀을 대신 주입한다
   1. 요청 경로: 샌드박스가 토큰이나 접근 제어가 필요한 외부 endpoint 또는 MCP를 호출하면 프록시를 거친다.
   2. 모델에 비밀을 감춘다: 프록시가 외부 호출 직전에 토큰을 주입하므로 Claude와 샌드박스는 실제 자격 증명을 보지 않는다. 따라서 프롬프트로 토큰을 출력시키거나 파일에 쓰게 하는 경로를 차단한다.

4.2. append-only 로그와 유연한 compaction

1. 기록과 모델 컨텍스트를 분리한다
   1. 원본 이벤트 보존: 이벤트 스트림 자체를 압축하거나 변경하지 않고 각 사건을 모두 저장한다.
   2. 요약은 별도 선택: 컨텍스트를 만들 때 전체 이벤트 로그를 읽어 요약해 넣을지, 마지막 N개 이벤트만 넣을지 compaction 전략이 결정한다.
2. 전략을 바꾸어도 과거 기록은 남는다
   1. 정책 변경 가능: 원본 로그를 유지하므로 모델이나 제품 요구에 따라 컨텍스트 구성 방식을 바꿀 수 있다.
   2. 경계의 장기 수명: harness나 compaction 전략을 통째로 교체해도 세션 로그와 hands 사이의 인터페이스는 그대로 유지할 수 있다.

4.3. 첫 토큰과 실행 확장성

1. 첫 토큰까지 걸리는 시간이 약 90% 줄었다
   1. 기존 대기 제거: 이전처럼 컨테이너 샌드박스가 올라올 때까지 첫 추론을 기다리지 않는다.
   2. 필요 시점에 sandbox 기동: 추론 호출을 즉시 시작하고 sandbox는 필요해졌을 때만 띄워 time to first token을 약 90% 낮췄다.
2. 하나의 brain에 여러 hands를 연결한다
   1. 실행 환경 선택: harness는 자체 샌드박스뿐 아니라 고객 VPC나 MCP 서버도 호출할 수 있다.
   2. 구성의 유연성: 각 hand를 플러그인처럼 더하거나 바꿀 수 있어, 모든 실행 기능을 단일 컨테이너에 넣지 않아도 된다.

5. Claude Managed Agents를 구성하는 API와 이벤트 흐름

실습은 코드 없이 콘솔에서 간단한 에이전트를 만든 뒤, API가 표현하는 environment·agent·session 구조와 세션 이벤트를 살펴보는 순서로 진행된다.

5.1. 먼저 Environment와 Agent를 만든다

1. Environment API v1은 실행 환경의 템플릿이다
   1. 네트워크 정책: 네트워크를 제한 없이 열지, 특정 도메인이나 MCP에만 허용할지 설정한다.
   2. 컨테이너 구성: 샌드박스에 미리 설치할 패키지와 환경 설정을 정한다.
2. Agent에는 모델과 행동 지침을 설정한다
   1. 이름과 모델: 예제 에이전트 이름은 Joke Teller다. 사용할 모델은 Opus 4 계열, Haiku, Sonnet 등에서 선택한다고 안내했다.
   2. 시스템 프롬프트와 도구: “코미디언처럼 행동하고, 주제에 맞는 신선한 농담을 찾아 잘 전달하라”는 지침을 넣고, bash·read·write·grep 등을 포함하는 기본 Agent tool set을 제공한다. 발표자는 대부분의 에이전트에 이 기본 도구 집합이 필요하다고 말했다.

5.2. Session을 열고 event stream으로 작업한다

1. Session은 실제 작업 단위다
   1. 생성 인자: Session 생성에는 agent ID와 environment ID가 들어간다.
   2. 초기 상태: 세션이 프로비저닝되어도 곧바로 작업하지 않고, 이벤트가 전송될 때까지 idle 상태로 남는다.
2. 사용자와 에이전트가 이벤트를 주고받는다
   1. 입력과 응답: user.message 이벤트로 “분산 시스템에 관한 농담을 해 달라”고 요청하고, 에이전트의 응답 이벤트에서 농담을 받는다.
   2. custom tool 왕복: 개발자는 custom tool을 정의하고 이벤트 스트림의 tool-use 이벤트를 구독해 직접 처리한 뒤, 결과를 custom_tool_result로 Claude에 돌려준다.
3. 운영 상태와 중단 이벤트도 다룬다
   1. 오류와 대기: session.error는 세션에 오류가 발생했음을 나타내며, status가 idle이면 세션이 작업하지 않는 상태다. 이때 보통 사용 중인 샌드박스가 없다.
   2. interrupt: 더 이상 작업하지 않도록 세션을 중지하거나 종료할 때 interrupt를 사용한다.

5.3. 워크숍의 범위와 다음 주제

1. 두 단계의 실습을 예고했다
   1. 콘솔 기반 시작: 첫 번째 실습은 코드를 쓰지 않고 Claude Platform Console에서 프롬프트를 작성해 단순한 농담 에이전트를 만들고 시험한다.
   2. 코드 기반 확장: 이어서 Claude Code 또는 선호하는 코딩 에이전트로 더 복잡한 금융 에이전트를 만든다.
2. 2시간짜리 상호작용형 세션으로 구성했다
   1. 진행 계획: 전체 워크숍은 네 부분으로 나뉘어 보이지만 사실상 하나의 긴 발표이며, 2시간 슬롯 안에서 진행할 예정이라고 소개했다.
   2. 질문과 지원: 참석자에게 질문이 있으면 손을 들라고 안내했고, 스태프가 마이크를 전달한다. 실습 지원을 위해 Travis가 돌아다니며 질문이나 도움 요청을 받는다.
3. 다중 에이전트와 메모리를 후속 개념으로 남겼다
   1. 기능 목록: 관리형 에이전트 API에는 다중 에이전트와 메모리도 제공된다고 언급했다.
   2. 실습의 다음 화면: 발표 끝부분에서 플랫폼 콘솔의 Managed Agents 섹션에 있는 Quick Start가 첫 에이전트를 만드는 guided tour라고 소개하며 콘솔로 넘어갔다.

주요 발언 모음

“에이전트는 기본적으로 도구를 갖춘 모델 루프다.”

“harness는 모델을 감싸 도구 호출 루프를 만들고, 모델이 할 수 없는 것에 대한 가정을 담는다.”

“harness는 가정을 인코딩하며, 그 가정은 낡을 수 있다.”

“우리가 가져가고 싶은 것은 두뇌와 손을 분리하는 설계다.”

“세션 로그만 지켜지면 나머지는 교체 가능하다.”

핵심 데이터 & 수치

• 2년 조금 넘게: Priyanka는 Anthropic에서 2년 조금 넘게 일했고, 최근 12개월은 에이전트 인프라 구축에 집중했다고 소개했다.
• 1년 조금 넘게: Gabe는 Anthropic에서 1년 조금 넘게 일했고, 재직 기간 대부분 Managed Agents 개발을 맡았다고 말했다.
• 지난해 12월: 초기 아키텍처를 early access 고객에게 내놓은 시점으로 제시했다.
• 약 90% 단축: sandbox 구동을 기다리지 않고 추론을 먼저 시작하도록 바꾸면서 time to first token을 약 90% 줄였다.
• 2시간 / 네 부분: 워크숍은 2시간 슬롯에 네 부분으로 안내됐지만 실제로는 하나의 긴 발표처럼 진행한다고 말했다.
• 879초: 영상 길이는 약 14분 39초다.

결론 및 시사점

1. 영속 상태와 실행 프로세스를 분리하라: 장애가 나도 이벤트 로그를 바탕으로 새 harness나 샌드박스를 띄워 이어갈 수 있게 해야 한다.
2. 모델별 우회책을 아키텍처의 불변 조건으로 두지 말라: 모델 행동은 바뀔 수 있으므로 가정을 인터페이스 뒤에 두고 필요할 때 교체할 수 있게 설계해야 한다.
3. 자격 증명은 실행 도구와 모델에 노출하지 말라: 인증 프록시가 외부 요청 직전에 토큰을 넣고, 모델에는 비밀이 전달되지 않도록 경계를 둔다.
4. 원본 이벤트는 보존하고 컨텍스트만 조정하라: append-only 기록을 남기면 compaction·요약 정책을 바꿔도 원래 작업 흐름을 잃지 않는다.
5. 첫 응답을 실행 환경 준비와 분리하라: 모델 추론을 먼저 시작하고 필요한 손만 요청 시 프로비저닝하면 체감 응답 속도를 높일 수 있다.
6. 실행 수단을 플러그인 가능한 hands로 취급하라: 샌드박스, MCP, 고객 VPC를 같은 에이전트 루프에서 선택적으로 연결하면 통합과 확장이 쉬워진다.