YouTubeTech Bridge·2026년 10월 18일·0

[한영자막] Anthropic Claude Managed Agents: 두뇌와 손을 분리한 설계 (1부)

Quick Summary

Anthropic Claude Managed Agents는 세션 기록·두뇌·손을 분리해 실행 환경과 하네스를 교체하면서 작업을 이어갈 수 있도록 설계됐다.

영상 보기

클릭 전까지는 가벼운 미리보기만 먼저 불러옵니다.

원본 열기

🖼️ 인포그래픽

[한영자막] Anthropic Claude Managed Agents: 두뇌와 손을 분리한 설계 (1부) 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

[한영자막] Anthropic Claude Managed Agents: 두뇌와 손을 분리한 설계 (1부)의 핵심 내용을 4단계로 요약한 인포그래픽
[한영자막] Anthropic Claude Managed Agents: 두뇌와 손을 분리한 설계 (1부) 핵심 내용을 4단계로 압축한 4컷 인포그래픽

💡 한 줄 결론

Anthropic Claude Managed Agents는 세션 기록·두뇌·손을 분리해 실행 환경과 하네스를 교체하면서 작업을 이어갈 수 있도록 설계됐다.

📌 핵심 요점

  1. 에이전트는 모델이 도구를 반복 호출하며 작업하는 구조다. 하네스는 도구 호출과 문맥 관리를 담당하며, 모델별 한계를 보완하는 가정도 포함한다.
  2. 초기 구조는 세션 로그·하네스·코드 실행을 한 컨테이너에 담았다. 구현은 단순했지만 장애 원인 구분, 고객 데이터가 있는 환경의 조사, 고객 VPC 연결이 어려웠다.
  3. 새 구조는 추가 전용 세션 로그, Claude와 하네스로 구성된 두뇌, 샌드박스·MCP 도구 같은 손을 분리한다. 샌드박스는 필요할 때 생성하고, 하네스는 세션 로그를 읽어 작업을 재개한다.
  4. 인증정보는 샌드박스에 넣지 않고 외부 호출 시 프록시가 주입한다. 원본 이벤트를 보존하므로 문맥 압축 전략도 바꿀 수 있으며, 발표자는 샌드박스 시작을 기다리지 않아 첫 토큰 도달 시간을 약 90% 줄였다고 설명한다.
  5. 실습의 기본 순서는 환경 생성 → 에이전트 정의 → 세션 생성 → 이벤트 전송이다. 영상 마지막은 콘솔의 빠른 시작 안내로 넘어가며, 실제 에이전트 실행 결과는 이 구간에 나오지 않는다.

🧩 배경과 문제 정의

이 영상은 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% 감소의 측정 환경, 비교 기준, 표본 수와 절대 지연시간은 제시되지 않는다.
  • 모델이 토큰을 직접 보지 못하게 하는 설계는 설명되지만, 프롬프트 인젝션 전반이나 권한이 있는 도구의 오용까지 방지한다는 근거는 없다.
  • 세션 로그를 통한 재개는 소개되지만, 외부 작업의 중복 실행 방지, 샌드박스 파일 복원, 로그 저장소 장애 대응은 설명되지 않는다.
  • 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
  • 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
  • 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

  • 현재 에이전트 구조에서 세션 기록, 하네스, 코드 실행 환경이 어디에 저장되고 실행되는지 구분해 그린다.
  • 샌드박스 종료와 하네스 종료를 각각 가정하고, 어떤 기록으로 어디서부터 재개할지 점검한다.
  • 인증정보가 모델 입력·샌드박스 환경·파일에 노출되는지 확인하고, 영상의 프록시 주입 방식과 비교한다.
  • 간단한 실습을 환경 → 에이전트 → 세션 → 사용자 이벤트 순서로 구성하고, 오류·유휴·중단 이벤트의 처리 방식을 정한다.

❓ 열린 질문

  • 세션 로그에서 작업을 재개할 때 이미 실행된 외부 도구 호출의 중복과 부작용은 어떻게 처리하는가?
  • 교체된 샌드박스에는 이전 파일과 설치된 의존성을 어떤 방식으로 복원하는가?
  • 인증 프록시는 호출 대상과 권한 범위를 어떻게 제한하며, 허용된 자격증명을 악용하는 요청에는 어떻게 대응하는가?

관련 문서

공통 태그와 주제 흐름을 기준으로 같이 보면 좋은 문서를 이어서 제안합니다.