[한영자막] Claude Managed Agents로 리서치 에이전트를 만들어봅니다 (2/4)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Claude Managed Agents로 SEC 공시 리서치 에이전트를 만들려면 관리형 실행 환경 위에 세션 조정, 전문 에이전트 위임, 결과 검증과 공유 메모리를 연결해야 한다.

📌 핵심 요점

1. 실행 인프라는 서비스가 관리하고, 제품 흐름은 개발자가 구성한다. Managed Agents는 호스팅·샌드박스·확장·이벤트 로그 저장을 맡는다. 개발자는 세션과 이벤트를 연결하며, 저장 계층을 분리해 새로운 이벤트를 수용할 수 있도록 설계한다.
2. 기본 채팅은 이벤트 스트림에서 출발한다. 사용자 입력을 user.message로 보내고 API의 SSE 스트림을 브라우저로 중계한다. 여기에 SEC 조회 스킬과 전문 하위 에이전트를 추가해 장시간 비동기 리서치로 확장한다.
3. 여러 종목의 분석에는 세션을 조정하는 하네스가 필요하다. 종목마다 별도 세션을 실행하고 재무 분석·위험 평가를 위임한 뒤 결과를 집계한다. 자기 참조로 만든 하위 에이전트에는 같은 프롬프트·도구 설명·스키마를 제공하지만 기존 대화 기록은 복사하지 않는다.
4. Outcomes와 메모리로 완료 조건과 지식 재사용을 연결한다. 작업·평가 기준·최대 반복 횟수를 전달하고, 별도 에이전트가 산출물을 검증한다. Nvidia 사례에서는 기존 메모리를 먼저 확인하고, 분석 결과를 JSON과 스코어카드로 생성한 뒤 메모리를 갱신한다.
5. 운영 통제에는 개발자의 설계가 남는다. 네트워크 접근 범위와 하위 에이전트 권한을 제한하고, Vaults로 허용된 도메인에만 실제 자격 증명을 전달한다. 에이전트 간 반복과 토큰 소비도 통제해야 하며, 시연 당시 엄격한 세션별 예산 상한과 세션 되감기는 제공되지 않았다.

🧩 배경과 문제 정의

• 세션 저장 구조는 향후 새로운 이벤트를 수용하면서도 세션 동작과 강하게 결합되지 않도록 확장필요가 있다.
• Claude Managed Agents는 인프라·실행 환경·이벤트 저장 등을 관리하고, 개발자는 세션과 이벤트를 이용해 제품 기능을 구성한다.
• 리서치 애플리케이션에는 채팅을 넘어 SEC 공시 조회, 전문 에이전트 위임, 장시간 비동기 실행, 결과 검증과 세션 간 지식 공유가 필요하다.
• 여러 에이전트를 운영할 때는 자격 증명 보호, 반복 실행과 비용 통제, 실행 방향 수정의 지원 범위도 고려해야 한다.

🕒 시간순 섹션별 상세정리

1. 세션 저장 구조를 분리해 이벤트 확장성을 확보한다

• 첫 번째 구현에서 두 번째 구현으로 바뀐 핵심은 저장 기능을 여러 구성 요소로 추상화하고 분리한 것이다. 새로운 이벤트를 저장할 때 세션 동작과의 강한 결합을 줄이는 목적이다 [00:20]
• 인터페이스를 구성하고 가상화하는 원칙을 서비스 경계뿐 아니라 이벤트 계층에도 적용한다 [00:40]

2. 프롬프트로 에이전트를 만들고 실행 환경을 연결한다

• 주제에 맞는 농담을 만드는 에이전트를 요청하면 시스템 프롬프트, 이름, 설명과 모델 구성이 생성된다. 모델과 도구 접근을 조정한 뒤 생성하면 V1 agents 엔드포인트를 호출한다 [01:26]
• 환경은 샌드박스의 템플릿이며 설치할 패키지와 네트워크 접근 범위를 설정한다. 시연에서는 무제한 접근을 허용하지만, 운영 환경에서는 접근 도메인이나 MCP 서버를 제한해야 한다 [02:06]

3. 리서치 데스크를 채팅에서 다중 세션 분석으로 확장한다

• 실습 저장소를 복제한 뒤 research desk 디렉터리에서 npm install 또는 bun i로 의존성을 설치한다 [03:46]
• 구현 대상은 채팅 인터페이스, 하위 에이전트 위임, SEC 공시 조회와 특정 양식 분석 스킬이다. 이를 바탕으로 오래 걸리는 비동기 작업을 수행한다 [04:28]

4. 워크숍 스킬로 실행 준비와 단계 진행을 관리한다

• 저장소에 포함된 워크숍 스킬은 실습을 단계별로 안내하며, 로컬 서버는 bun run dev로 시작한다. 실행한 웹사이트의 설정 페이지에서 준비를 이어간다 [06:11]
• workshop start로 여섯 단계의 실습을 시작하고, workshop next로 다음 단계로 진행한다. Claude가 단계별 진행 상태를 추적한다 [07:25]

5. 관리형 실행 인프라와 외부 샌드박스를 선택할 수 있다

• 기본 실행은 서비스 제공자의 자체 인프라에서 이루어진다. AWS 크레딧으로 이용할 수 있는 AWS상의 플랫폼 선택지도 있다 [10:16]
• 자체 샌드박스를 가져오는 방식도 지원한다. Vercel·Modal·Daytona 등의 제공자나 Google Cloud·AWS 환경에서 샌드박스를 실행할 수 있다 [10:31]

6. 기본 에이전트에 이벤트 스트림 기반 채팅을 연결한다

• 설정 버튼은 환경과 기본 에이전트를 생성한다. 환경에는 SEC 중심의 웹 접근과 Python 패키지를 설정하고, 에이전트에는 기본 도구와 프롬프트를 제공하되 스킬이나 하위 에이전트 조정은 아직 추가하지 않는다 [10:54]
• 세션과의 통신은 이벤트 스트림을 중심으로 이루어진다. 클라이언트는 에이전트가 보내는 이벤트를 구독하고 별도 엔드포인트로 이벤트를 전송한다 [11:52]

7. Outcomes로 작업 목표와 자체 검증 기준을 지정한다

• 비동기 분석은 특정 금융 상품을 조사하고 사용자가 정한 형식의 보고서를 만드는 작업이다. Outcomes는 작업과 평가 기준을 함께 지정하는 자체 감독 방식이다 [17:33]
• 에이전트가 작업을 마쳤다고 판단하면 하위 에이전트가 평가 기준과 결과물을 비교해 정확성과 완료 여부를 검증한다. 기준을 충족하지 못하면 작업을 다시 시도한다 [17:50]

8. Nvidia 공시 분석에 메모리 재사용과 출력 형식을 요구한다

• Nvidia 분석 세션을 시작하며, 실행에는 약 10분 정도가 걸릴 것으로 예상한다. 실제 처리 과정을 확인하기 위해 이전에 실행한 세션을 사용한다 [18:53]
• 분석 과제는 Nvidia의 최신 SEC 분기 공시를 조사하는 것이다. 먼저 메모리를 확인하고 기존 분석이 있으면 재사용해 이미 아는 내용을 다시 조사하는 일을 줄인다 [19:09]

9. 전문 에이전트의 분석을 모아 결과물과 메모리를 갱신한다

• 이전 실행에서는 메모리 저장소에서 기존 노트를 찾지 못해 재무 정보 추출·분석과 위험 평가를 담당하는 하위 에이전트에 작업을 위임했다 [20:00]
• 콘솔의 각 스레드는 하위 에이전트가 수행하는 작업을 나타낸다. 하위 에이전트는 작업을 마치면 요청받은 결과를 주 에이전트에 반환한다 [20:22]

10. 별도 검증 에이전트가 산출물과 완료 조건을 확인한다

• 결과물 생성 후 자체 감독용 하위 에이전트가 실행되어 outcome의 평가 기준, 세션에서 수행한 작업과 생성된 산출물을 검토한다 [20:55]
• 이전 실행에서는 스코어카드 제출, 수치의 명확성, 메모리 갱신이 기준을 충족한다고 판정했다 [21:03]

11. 종목별 세션을 분리하고 결과를 집계하는 하네스를 구성한다

• 10개나 100개 종목을 분석하려면 종목마다 별도 세션에 작업을 맡기고, 완료 후 결과와 점수를 집계하는 방식으로 확장할 수 있다 [21:42]
• 서버의 사용자 정의 조정 하네스는 앞서 만든 도구를 이용한다. 주 에이전트가 여러 세션을 시작하기로 결정하면 애플리케이션이 그 요청을 받아 처리하는 구조다 [22:05]

12. 스킬 갱신으로 이후 세션의 분석 범위를 넓힌다

• 스킬은 갱신할 수 있는 리소스다. 새로운 공시 양식을 분석하는 기능을 추가하면, 이후 해당 스킬을 참조하는 새 세션에 변경 내용이 적용된다 [22:27]
• 이전 세션의 수행 결과를 바탕으로 스킬을 계속 개선할 수 있다. 세션 경험을 활용하는 dreaming은 후속 시연 대상으로 예고된다 [22:48]

13. Vaults는 허용된 도메인으로 나가는 요청에만 실제 자격 증명을 넣는다

• SEC 접근에는 이름과 이메일이 필요하며, 시연에서는 프롬프트에 직접 넣는다. 운영 애플리케이션의 자격 증명 처리를 위해서는 Vaults를 사용한다 [23:55]
• 환경 변수에는 실제 비밀값 대신 대체값을 제공하고, 외부로 나가는 요청에서 허용된 호스트 도메인에 대해서만 실제 값으로 교체한다. 허용하지 않은 도메인으로 보내는 요청에는 교체를 수행하지 않는다 [24:05]

14. Managed Agents는 범용 작업을 위한 별도 관리형 하네스를 사용한다

• Agent SDK는 헤드리스 Claude Code에 가까운 패키지이며, 실행 파일을 원하는 환경에서 구동할 수 있다. Managed Agents는 SDK의 경험과 장점을 참고하면서 코딩 외 작업에도 사용할 수 있도록 하네스를 재구성했다 [26:15]
• Managed Agents는 제공자의 클라우드에서 실행되는 완전 관리형 서비스이며 자체 하네스를 사용한다. Claude Code 하네스의 개선 사항과도 지속적으로 정보를 교환한다 [26:37]

15. 반복 실행 방지와 세션별 예산 통제에는 개발자 책임이 남는다

• 사용자 정의 하네스에서 에이전트 간 반복과 과도한 토큰 소비를 통제하는 일은 일부 개발자가 설계해야 한다. 다른 제공자를 함께 사용하는 조정 구조도 가능하다 [27:17]
• 세션별 금액이나 토큰 사용량에 상한을 두는 더 엄격한 예산 통제는 검토 중이지만, 당시에는 제공하지 않는다 [27:34]

16. 실행 중 지침을 추가할 수 있지만 과거 시점으로 되돌릴 수는 없다

• 새 user.message 이벤트를 보내 실행 중인 에이전트의 방향을 수정할 수 있다. 여러 메시지를 보내면 대기열에 들어간다 [28:17]
• 과거 시점으로 되감아 다시 진행하는 기능은 현재 없다. 세션 포킹은 고객 요청을 받은 로드맵 항목이며, 제공 시점은 확정되지 않았다 [28:31]

17. 여러 세션의 지식을 메모리 저장소로 공유한다

• 여러 사용자가 금융 리서치를 수행할 때 세션 간 지식을 공유하는 메모리 저장소는 이미 지원되며, 이 시연에서도 사용한다 [29:39]
• 에이전트들은 각자 수행한 작업에 관한 정보를 메모리에 축적한다. 시간에 따라 이 지식을 통합하는 방법은 후속 시연에서 다룰 예정이다 [29:48]

18. 메모리의 공동 학습과 외부 이전

• dreaming은 서로 다른 에이전트가 경험한 예외 사례를 바탕으로 메모리 저장소를 지속적으로 개선하고, 에이전트들이 서로의 경험을 학습하도록 한다. [30:01]
• 메모리는 API로 추출해 다른 시스템으로 옮길 수 있다. 다만 세션에서 다른 메모리 제공자를 바로 연결하는 기능은 현재 지원하지 않으며, MCP나 사용자 정의 도구를 구현하는 방식이 제안된다. [30:32]

19. 세션 단위의 성과 평가와 dreaming의 현재 범위

• 하위 에이전트는 협업을 통해 세션의 문맥과 작업 능력을 확장한다. 달성할 결과는 전체 세션 수준에서 정의하며, 주 에이전트가 하위 에이전트를 활용해 작업을 마친다. 현재 하위 에이전트별 결과 정의는 지원하지 않는다. [31:32]
• dreaming은 여러 세션의 대화 기록과 생성된 메모리를 분석해 이후 에이전트가 참고할 메모리를 갱신한다. 현재 적용 대상은 메모리 저장소이며, 스킬·프롬프트·에이전트 정의로의 확장은 가능한 향후 방향으로 드러난다. [32:21]

20. 기업 내부 데이터에 접근하는 연결 방식

• CLI·API 또는 MCP로 접근할 수 있는 데이터는 MCP에 인증 볼트를 연결해 호출할 수 있다. MCP를 인터넷에 노출하고 싶지 않다면 MCP tunnels로 사내 네트워크와 제공자 측 네트워크 사이에 터널을 만들 수 있다. [33:20]
• 터널 연결의 도입 장벽이 크다면 자체 호스팅 샌드박스를 사용할 수 있다. 사내 네트워크와 연결되고 내부 애플리케이션·서비스에 접근할 수 있는 샌드박스를 직접 운영하면, 에이전트가 이를 호출해 내부 자원에 접근한다. [33:53]

21. 환경 의존성의 설치 시점과 반입 방법

• 의존성은 환경 생성 시점에 설치하며, 생성된 환경을 캐시해 샌드박스를 다시 인스턴스화할 때 재사용한다. [34:27]
• 현재 의존성은 NPM·Cargo·pip 등의 패키지 관리 도구로 접근할 수 있어야 한다. 파일을 세션에 직접 업로드하거나 GitHub 저장소를 가져와 설치하는 방법도 사용할 수 있다. [34:42]

🧾 결론

• 리서치 에이전트의 구현 단위는 프롬프트뿐 아니라 세션·이벤트·도구·스킬·산출물·검증 기준까지 포함한다.
• 관리형 서비스가 실행 기반을 제공해도 종목별 작업 분배, 결과 집계와 반복 통제는 애플리케이션 설계에 달려 있다.
• 공유 메모리는 세션 간 분석을 재사용하게 하고, 갱신한 스킬은 이후 새 세션의 분석 범위를 넓힌다. dreaming의 현재 적용 대상은 메모리 저장소다.

📈 투자·시사 포인트

• 금융 리서치는 공시 수집, 재무 분석, 위험 평가와 정형 보고서 생성을 나눠 에이전트에 맡길 수 있는 적용 사례다. 시연은 이 작업들을 연결하는 구조를 보여준다.
• 다수 종목으로 확장할 때는 분석 결과뿐 아니라 종목별 완료 여부, 검증 결과와 실행 비용을 함께 관리하는 체계가 중요해진다.
• 기존 분석을 메모리에서 재사용하도록 설계하면 중복 조사를 줄일 수 있다. 다만 영상에는 비용 절감이나 정확도 개선을 정량적으로 입증하는 비교 결과가 없다.
• Nvidia는 공시 분석의 시연 대상이다. 제시된 내용은 리서치 시스템 구축에 관한 것으로, Nvidia의 투자 매력이나 매매 판단을 뒷받침하는 분석 결과는 제공하지 않는다.

⚠️ 불확실하거나 확인이 필요한 부분

• 약 10분이라는 실행 시간은 예상치이며, 처리 과정 설명에는 이전 실행 세션을 사용했다. 현재 실행의 최종 소요 시간과 반복 실행 시 성능은 확인되지 않는다.
• 자체 검증 에이전트가 기준 충족을 판정한 사례는 있지만, 공시 원문과 대조한 독립적인 정확도 평가나 오류율은 제시되지 않는다.
• 엄격한 세션별 예산 상한, 세션 포킹과 되감기, 외부 메모리 제공자 직접 연결의 지원 여부는 시연 당시 설명에 해당한다. 실제 도입 전 현재 지원 범위를 확인해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 기본 세션에서 user.message 전송과 SSE 수신을 연결해 채팅 흐름을 먼저 확인한다.
• SEC 요청용 식별 정보와 분석 스킬을 설정하고, 운영 환경의 접근 도메인·MCP 서버·에이전트 권한을 제한한다.
• 종목별 작업 설명, 보고서 형식, 평가 기준과 최대 반복 횟수를 정의하고 검증 결과를 확인한다.
• 기존 메모리 조회부터 분석 위임, JSON·스코어카드 생성, 메모리 갱신까지 한 종목으로 검증한 뒤 여러 세션으로 확장한다.

❓ 열린 질문

• 자체 검증을 통과한 보고서가 공시 원문과 다른 수치를 포함할 경우, 이를 발견하고 재작업시키는 기준은 어떻게 마련할 것인가?
• 여러 세션이 공유하는 메모리에서 오래된 분석이나 상충하는 내용을 어떻게 정리할 것인가?
• 종목 수가 늘어날 때 분석 완료율과 품질을 유지하면서 반복 횟수와 실행 비용을 어느 수준으로 제한할 것인가?