Claude Managed Agents로 리서치 에이전트 만들기 (2/4)

URL: https://www.youtube.com/watch?v=U0ZCwwG8sac
날짜: 2026-10-18
채널: Tech Bridge

---

📌 핵심 질문 / 핵심 논점

==Claude Managed Agents(CMA)의 관리형 실행 환경 위에 이벤트 기반 채팅, SEC 리서치 스킬, 전문 서브에이전트, 결과 검증 루프와 공유 메모리를 어떻게 조립해 장시간 비동기 리서치 제품을 만들 것인가?==

• 에이전트 생성·호스팅·샌드박스·이벤트 로그 저장·스케일링을 관리형 플랫폼에 맡기고 제품 인터페이스와 오케스트레이션을 직접 구성한다.
• 에이전트는 SEC 자료를 읽는 스킬과 전문 서브에이전트를 활용하고, outcome의 평가 기준을 만족할 때까지 작업을 보완한다.
• 세션 간 메모리와 반복 실행을 결합하면 여러 기업·사용자에 걸친 장기 분석 체계를 구성할 수 있지만, 세부 비용 제한과 서브에이전트별 평가 등은 아직 직접 설계해야 한다.

1. 세션 저장 구조와 관리형 에이전트의 기본 단위

1.1. 이벤트 저장소를 세션 동작과 분리하기

1. 저장 구성요소의 추상화
   1. 첫 번째에서 두 번째 구현으로 바뀐 점: 세션 작업의 메커니즘과 저장 방식을 단단히 결합하지 않고, 저장 기능을 여러 구성요소로 나눴다.
   2. 확장성: 앞으로 저장해야 할 이벤트 종류와 저장 메커니즘을 늘려도 세션 실행 로직을 함께 바꾸지 않도록 경계를 만들었다.
2. 계층 전반의 인터페이스 가상화
   1. 서비스 경계: 서비스 간 연결에서 인터페이스를 가상화해 구현 교체와 확장을 쉽게 한다.
   2. 이벤트 계층: 같은 원칙을 이벤트 레이어까지 적용해 세션 이벤트 저장소도 교체 가능한 구성으로 둔다.

1.2. 가장 작은 관리형 에이전트 생성

1. 자연어 요청을 에이전트 정의로 변환하기
   1. 요청 예시: “주제가 주어질 때마다 농담을 해주는 에이전트를 만들어줘”라고 입력한다.
   2. 초기 자동 생성: 화면이 시스템 프롬프트, 이름, 설명, 모델을 제안하고, 모델은 필요하면 바꿀 수 있다.
2. 에이전트와 환경을 별도로 구성하기
   1. Agent API: 생성 버튼은 V1 agents endpoint를 호출해 에이전트를 만든다.
   2. Environment 템플릿: 샌드박스의 기반이 될 환경 템플릿을 선택하고 필요한 패키지를 설치한 다음 세션을 시작한다.
3. 작동 확인과 관리형 책임 범위
   1. 짧은 실험: 생성한 에이전트에 “고양이에 관한 농담을 해줘”라고 보내면 세션이 실행되고 응답이 돌아온다.
   2. 플랫폼이 맡는 운영: 인프라, 호스팅, 실행 하네스(harness), 샌드박스 관리, 확장, 이벤트 로그 저장을 CMA가 담당하고 제품 개발자는 그 위의 제품에 집중한다.
   3. 권한 분리: 시연에서는 unrestricted access를 썼지만, 프로덕션에서는 허용 도메인과 MCP 서버를 제한해야 한다.

2. Research Desk 워크숍과 채팅 인터페이스

2.1. 실습 환경과 순서

1. 저장소 준비
   1. 프로젝트: QR 코드의 저장소를 복제하고 research-desk 디렉터리로 이동한다.
   2. 의존성 설치: npm install 또는 bun i를 실행한 뒤 bun run dev로 개발 서버를 시작한다.
2. 코딩 에이전트와 워크숍 진행
   1. 도구 선택: 시연자는 Claude Code를 사용했지만, 참가자는 원하는 코딩 에이전트를 선택할 수 있다.
   2. 재현 가능한 안내: 저장소에 단계별 워크숍 Skill을 넣어 두었고, workshop start 및 workshop next로 여섯 개 Act를 순서대로 진행한다.
   3. 학습 방식: 자동 진행 모드에서도 변경 사항을 손잡고 안내하듯 설명하도록 요청해 각 구현을 따라가며 이해한다.
3. 초기 설정과 현장 상황
   1. 필수 값: .env.example을 .env.local로 복사하고 Anthropic API 키, SEC 요청에 쓸 이름과 이메일을 채운다.
   2. SEC 식별: SEC가 호출 주체를 알 수 있도록 이름과 이메일을 User-Agent 성격의 식별 정보로 전달한다.
   3. Wi-Fi 문제: 현장 연결이 불안정해 저장소 접근이 막힌 참가자가 많았고, 진행팀은 질문을 중간에 끊고 요청해 개념을 같이 풀어가도록 했다.

2.2. 이벤트 스트림으로 채팅 만들기

1. 세션 통신의 양방향 흐름
   1. 사용자 입력: 채팅 입력 후 Enter를 누르면 애플리케이션이 user.message 이벤트에 텍스트를 담아 세션으로 보낸다.
   2. 에이전트 출력: 백엔드는 CMA의 Server-Sent Events(SSE) 스트림을 구독하고, 수신 이벤트를 브라우저로 다시 중계해 UI에 렌더링한다.
2. 채팅에서 비동기 제품으로 확장하기
   1. 최소 제품: 이벤트를 주고받는 이 경로만 구현하면 에이전트와 대화하는 기본 채팅 앱이 된다.
   2. 관리형 세션의 더 큰 범위: CMA는 분 단위 대화를 넘어 몇 시간, 며칠, 몇 주, 몇 달 이어지는 장기 비동기 작업을 목표로 한다.

3. SEC 스킬과 전문 서브에이전트

3.1. 단일 에이전트에서 역할 분담형 에이전트로

1. 기본 에이전트의 한계 보완
   1. 초기 상태: 처음 생성한 Research Desk 에이전트는 기본 프롬프트와 기본 도구만 있고 SEC 스킬이나 서브에이전트 조정 기능은 없다.
   2. 확장 목표: SEC 공시를 찾는 Skill과 서로 다른 분석을 맡는 서브에이전트를 붙여 에이전트의 분석 능력을 단계적으로 높인다.
2. Skill과 custom tool 구성
   1. SEC Skill: Python 패키지 사용 방법과 EDGAR 식별 정보를 포함해 특정 티커의 공시와 지정 양식을 분석하는 방법을 기술한다.
   2. dispatch_analysis 도구: 나중에 여러 세션을 시작하고 결과를 조정할 자체 오케스트레이션 하네스가 호출할 사용자 정의 도구와 입력 스키마를 준비한다.
   3. 버전 갱신: 에이전트 정의와 스킬을 업데이트하면 새 버전이 만들어지고, 이후 그 버전을 참조하는 새 세션은 갱신된 내용을 받는다.
3. 서브에이전트 정의와 문맥 경계
   1. 전문 역할: 메인 에이전트는 여러 전문 서브에이전트와 자기 자신을 복제할 수 있는 자기 참조(self-reference)를 갖는다.
   2. 자기 참조의 용도: 실행 시점에 작업 종류를 미리 알기 어려워도 같은 프롬프트와 도구를 가진 에이전트를 필요에 따라 추가로 띄울 수 있다.
   3. 전달되는 정보: 서브에이전트에는 프롬프트, 도구 설명, 스키마가 복사되지만 기존 세션의 대화 기록(transcript)은 복사되지 않는다.
   4. 권한 분리: 각 서브에이전트는 자체 프롬프트·도구·권한을 갖도록 구성할 수 있다.
4. 데스크 구성 및 장기 메모리
   1. 자원 프로비저닝: staff the desk 설정으로 에이전트·서브에이전트·Skill·Memory Store를 구성한다.
   2. Memory Store: 서로 다른 세션이 금융 상품에 관해 축적한 지식을 공유해, 이후 작업이 이미 조사한 내용을 재사용하게 한다.
   3. 시연 중 수정: Skill이 이미 존재한 상태라 재현을 위해 삭제 후 다시 프로비저닝하는 과정이 발생했다.

4. Outcome 기반 장시간 리서치와 결과 검증

4.1. 과업과 채점 기준을 함께 주기

1. Outcome 정의
   1. 작업 명세: 특정 티커에 대해 무엇을 조사할지, 어떤 결과물을 만들지, 어떤 루브릭(rubric)으로 완료 여부를 판단할지 세션에 전달한다.
   2. 자가 감독(self-supervision): 메인 에이전트가 완료를 선언하면 평가 서브에이전트가 루브릭·작업 흔적·산출물을 확인한다.
   3. 반복 실행: 기준을 충족하지 못하면 다시 시도하고, 통과하면 작업을 완료한다. 사용자 정의 outcome 이벤트에는 과업 설명, 평가 기준, 최대 반복 횟수가 포함된다.
2. Nvidia 분석 시연
   1. 입력: Nvidia의 최신 SEC 분기 공시를 찾고, EDGAR 식별 정보를 사용하며, Memory Store에서 이전 분석이 있는지 먼저 확인한다.
   2. 기억 재사용: 이미 존재하는 조사 결과가 있으면 불필요하게 다시 수집하지 않고 그 지식을 활용한다.
   3. 두 가지 산출물: 회사별 메모를 공유 메모리에 기록하고, 지정 경로에 정형화된 Scorecard JSON 파일을 저장한다.
   4. 분석 범위: 가장 최근에 관심을 두는 공시 양식을 찾아 분석하고, 결과 수치와 근거를 보고서 형식에 맞춘다.

4.2. 서브에이전트 실행과 검증의 관찰성

1. 전문가에게 나눠 맡기기
   1. 재무 추출: Financial Expert/Analysis Extractor가 공시에서 재무 정보를 추출한다.
   2. 위험 평가: Risk Evaluator가 분석과 위험 검토를 맡는다.
   3. 스레드 가시성: 콘솔에서 각 스레드는 서브에이전트가 수행한 작업을 나타내며, 각 에이전트의 진행과 결과를 확인할 수 있다.
2. 결과 취합과 루브릭 검사
   1. 메인 에이전트 재개: 서브에이전트가 결과를 돌려주면 메인 에이전트가 정보를 통합해 JSON 산출물과 메모리를 갱신한다.
   2. 검증 단계: 평가 서브에이전트가 정의한 루브릭을 대조해 Scorecard 완성도, 수치의 정의, 메모리 업데이트의 정확성을 검사한다.
   3. 실행 시간과 결과 표시: 당시 분석은 약 10분 걸리는 작업으로 소개됐고, 데모 앱은 세션에서 Scorecard를 꺼내 로컬 DB에 저장해 티커별 표를 만들도록 구성됐다.

5. 여러 종목으로의 확장과 제품 운영

5.1. 사용자 정의 오케스트레이션 하네스

1. 한 번의 분석에서 배치 처리로
   1. 확장 규모: 단일 분석을 넘어 10개 또는 100개 티커를 동시에 조사하려면 종목별 별도 세션을 실행한다.
   2. 집계 목표: 여러 세션이 끝난 뒤 결과를 모아 각 종목의 Scorecard를 한꺼번에 반환한다.
2. CMA와 애플리케이션 코드의 역할
   1. 분업: 메인 에이전트가 작업 수와 유형을 결정하고, dispatch_analysis 같은 도구를 통해 애플리케이션 서버의 custom harness가 세션 실행을 조율한다.
   2. Skill의 지속 개선: 이전 세션의 성능을 살펴보고 Skill을 갱신할 수 있으며, 갱신된 Skill은 이후 이를 참조하는 새 세션에 반영된다.
3. 반복 실행
   1. Deployments API: 정해진 주기에 따라 세션을 반복 실행해 장기 분석을 계속 갱신하는 자동화 경로를 제공한다.

5.2. 보안, 비용 및 세션 제어

1. Vault를 통한 자격 증명 주입
   1. 데모와 프로덕션의 차이: 데모에서는 SEC 이름·이메일을 프롬프트에 넣었지만, 운영 환경에서는 Vault에 자격 증명을 묶어 전달한다.
   2. 도메인 제한 Egress: 에이전트 환경 변수에는 실제 비밀값 대신 placeholder를 주입하고, 네트워크 Egress 계층이 허용한 호스트로 요청할 때만 실제 값으로 바꾼다.
   3. 오용 차단: SEC 도메인만 허용된 비밀값은 SEC 요청에만 교체되며, 다른 도메인으로 보낼 때는 실제 값이 주입되지 않는다.
   4. 다양한 인증 방식: Vault ID를 세션에 연결하면 MCP나 CLI의 자격 증명을 사용할 수 있고, 사전 구성된 OAuth(예: Notion) 인증도 함께 묶을 수 있다.
2. Agent SDK와 CMA의 관계
   1. Agent SDK: 어디서나 실행할 수 있는 headless Claude Code 계열의 바이너리로 소개된다.
   2. CMA 하네스: Agent SDK의 교훈을 바탕으로 만들었지만 코딩에 한정되지 않는 자체 관리형 하네스이며, Anthropic 클라우드에서 실행된다.
3. 비용·반복 제한
   1. 현재 책임: 서브에이전트 루프와 토큰 사용을 제어하는 세부 오케스트레이션은 사용자 정의 하네스에서 설계해야 한다.
   2. 향후 검토: 세션당 비용이나 토큰 상한 기능은 검토 중이지만 당시에는 제공되지 않았다.
   3. 다중 제공자: 직접 하네스를 만들 때 다른 모델 제공자를 섞는 구조도 선택할 수 있다.
4. 세션을 조정하고 되돌리기
   1. 추가 지시: 실행 중 새 user.message 이벤트를 보내면 에이전트에 방향을 전달할 수 있고, 여러 메시지를 큐에 넣을 수 있다.
   2. 기록 되감기: 실행 기록을 rewind/roll forward하는 기능은 당시 제공되지 않았다.
   3. 세션 포킹: 기존 지점에서 갈라져 재실행하는 session forking은 요청이 있어 로드맵에 올라 있었다.

6. 공유 메모리와 외부 데이터 연결

6.1. 사용자·조직 간 지식 축적

1. 공유 메모리 저장소
   1. 세션 간 학습: 여러 에이전트가 수행한 작업 정보를 메모리에 쌓아 다음 세션이 다른 세션의 결과를 참조하게 한다.
   2. Dreaming: 여러 세션의 transcript와 생성된 메모리를 분석해, 미래 에이전트가 무엇을 가져와야 하는지 메모리 구성을 정리하고 개선한다.
   3. 현재 범위: Dreaming은 당시 Memory Store에만 적용되며, Skill·프롬프트·에이전트 정의까지 자동 개선하는 기능은 확장 아이디어로 언급됐다.
2. 조직 데이터와 사용자 데이터의 분리
   1. 다중 Memory Store: 한 세션에 여러 저장소를 붙여 사용자별 메모리와 조직 전체 메모리를 함께 쓸 수 있다.
   2. 이식성: 메모리는 API로 가져갈 수 있어 특정 인프라에 잠기지 않는다.
   3. 외부 저장소 연결: 기본 지원되는 외부 메모리 제공자는 없지만 MCP 또는 custom tool을 만들어 연결할 수 있다.
3. 서브에이전트 평가 범위
   1. 세션 수준 평가: outcome은 전체 세션이 달성할 결과를 정의하고, 메인 에이전트가 서브에이전트 협업을 통해 이를 완성한다.
   2. 미지원 기능: 개별 서브에이전트 작업마다 별도 outcome을 정의하는 기능은 아직 지원되지 않는다.

6.2. 사내 데이터·네트워크·환경 의존성

1. 비공개 데이터 접근 경로
   1. MCP와 Vault: 사내 API나 MCP에 인증을 붙여 에이전트가 직접 호출하게 한다.
   2. MCP Tunnels: MCP 서버를 인터넷에 공개하지 않으려면 사내 네트워크에서 Anthropic 쪽으로 터널을 만든다.
   3. 자체 호스팅 샌드박스: 자체 네트워크와 피어링된 샌드박스를 관리하면 에이전트가 내부 서비스에 접근할 수 있다.
2. 의존성의 설치 시점
   1. 환경 생성 시 설치: 패키지는 세션 실행 직전이 아니라 환경을 만들 때 설치되고 캐시된다.
   2. 재사용: 샌드박스를 다시 인스턴스화해도 캐시된 환경 구성을 활용한다.
   3. 사내 패키지: 의존성은 npm·Cargo·pip 등 패키지 레지스트리에서 접근 가능해야 하지만, 파일이나 GitHub 저장소를 세션에 올려 설치하는 방식도 가능하다.

주요 발언 모음

“세션의 동작과 저장을 그렇게 단단히 결합하지 않고, 가능한 많은 것을 추상화해 서로 다른 구성요소로 나누고 싶었다.”

“세션을 시작하고 이벤트를 보내고 이벤트를 받으면 된다. 나머지는 우리가 관리한다.”

“에이전트가 결과를 완성했다고 생각하면 서브에이전트가 루브릭을 보고 작업을 평가한다. 부족하면 다시 시도한다.”

“모든 것은 API 호출이다. 메모리 데이터를 가져가 다른 곳에서 사용할 수 있다.”

핵심 데이터 & 수치

• 워크숍: 6개 Act로 나뉘며 workshop start와 workshop next로 진행한다.
• 시연 분석: Nvidia의 최신 SEC 분기 보고서를 분석하며, 한 번의 장기 세션은 약 10분이 걸릴 수 있다고 제시한다.
• 배치 확장: 종목 10개 또는 100개를 각각 별도 세션으로 돌린 뒤 결과를 집계하는 구상을 제시한다.
• 세션 입력: 여러 사용자 메시지를 큐에 넣을 수 있으며, 예시로 10개 메시지를 한 번에 보내도 된다고 답했다.
• 예산 제어: 세션별 달러·토큰 상한은 검토 중이고 당시에는 제공하지 않았다.
• 환경 패키지: 생성 시 설치하고 이후 샌드박스 재생성에 재사용하도록 캐시한다.

결론 및 시사점

1. 제품 경계를 나눠라: CMA는 세션 런타임·샌드박스·로그 저장을 관리하고, 애플리케이션은 SSE 이벤트를 UI로 연결해 사용자 경험을 구현한다.
2. 작업을 구조화하라: 역할이 구분된 Skill·서브에이전트·Memory Store·custom harness로 조사와 집계를 나누되, 하위 작업의 실행 한도와 비용 제어는 직접 설계해야 한다.
3. 완료 기준을 명시하라: Outcome과 루브릭을 산출물·메모리 갱신에 함께 적용하면 장시간 작업의 완료 여부를 검증하고 미흡한 결과를 재시도할 수 있다.
4. 보안 경계를 설정하라: 프로덕션 자격 증명은 Vault와 허용 도메인으로 제한하고, 사내 자원은 MCP Tunnels 또는 네트워크 피어링 샌드박스로 연결한다.
5. 메모리를 계층화하라: 사용자별 지식과 조직 공통 지식을 분리된 저장소로 유지하면서, Dreaming으로 반복 세션에서 얻은 교훈을 장기 메모리에 반영한다.
6. 미지원 기능을 제품 설계에 반영하라: 하위 에이전트별 outcome, 비용·토큰 상한, 세션 기록 되감기 기능은 당시 제공 범위 밖이므로 별도 오케스트레이션이 필요하다.

핵심 요약 (20줄)

Claude Managed Agents는 관리형 샌드박스와 이벤트 로그를 제공해 개발자가 제품 로직과 사용자 인터페이스에 집중하게 한다.

세션 저장을 작업 실행 방식과 분리하면 새 이벤트와 저장 메커니즘을 기존 세션 로직에 강하게 결합하지 않고 추가할 수 있다.

자연어로 에이전트를 만들면 시스템 프롬프트·이름·설명·모델이 생성되고, 환경 템플릿과 패키지를 정한 뒤 클라우드 세션을 실행한다.

프로덕션 환경은 시연의 unrestricted access 대신 허용 도메인과 MCP 서버를 제한해야 한다.

Research Desk 실습은 저장소를 복제하고 의존성을 설치한 뒤 개발 서버와 여섯 단계 워크숍 Skill을 실행하는 흐름으로 구성된다.

채팅 앱은 사용자 입력을 user.message 이벤트로 보내고 CMA의 SSE 이벤트를 서버에서 브라우저로 중계해 구현한다.

관리형 세션은 일반 채팅을 넘어 몇 시간에서 몇 달까지 이어지는 비동기 작업을 지원하도록 설계됐다.

SEC 공시 Skill에는 Python 패키지 사용법과 EDGAR 식별 정보를 넣어 특정 티커와 양식을 조사하게 한다.

전문 서브에이전트는 재무 추출과 위험 평가를 나눠 맡으며, 메인 에이전트의 도구·프롬프트 정의를 공유해 협업한다.

자기 참조 에이전트는 기존 대화 기록이 아니라 프롬프트·도구 설명·스키마를 복사해 추가 세션을 생성한다.

Outcome은 작업 설명과 평가 루브릭, 최대 반복 횟수를 지정해 완료 후 검증과 재시도를 가능하게 한다.

Nvidia 분석 과업은 최신 SEC 분기 공시를 확인하고 기존 메모리를 재사용해 회사별 지식과 정형 Scorecard JSON을 함께 만든다.

재무 분석기와 위험 평가기가 별도 스레드에서 조사한 뒤 메인 에이전트가 결과를 취합하고 평가 에이전트가 산출물을 루브릭으로 검사한다.

종목 10개나 100개를 처리하려면 각 종목의 세션을 시작하고 사용자 정의 하네스가 결과를 모으는 Map-Reduce 구성이 필요하다.

배포 API는 세션을 정해진 주기로 실행해 장기 분석을 반복 갱신하는 경로로 소개됐다.

Vault는 실제 비밀값 대신 placeholder를 세션에 주고 허용된 대상 도메인으로 나가는 요청에만 실제 자격 증명을 삽입한다.

Vault ID는 MCP·CLI 인증과 OAuth 자격 증명을 세션에 연결하며, Agent SDK와 달리 CMA는 코딩에 한정되지 않는 자체 호스팅 하네스다.

세션 중 새 메시지 이벤트로 작업을 조정할 수 있지만, 비용·토큰 상한과 기록 되감기·포킹은 당시 제공되지 않았다.

여러 Memory Store를 붙이면 사용자별 지식과 조직 지식을 함께 활용하고, Dreaming은 여러 세션의 기록을 분석해 메모리를 개선한다.

사내 데이터는 Vault가 적용된 MCP, MCP Tunnels 또는 네트워크에 연결된 자체 호스팅 샌드박스로 접근하고 환경 패키지는 생성 시 설치·캐시한다.