원문: https://www.anthropic.com/engineering/multi-agent-research-system
Published Jun 13, 2025
Claude는 이제 웹, Google Workspace, 그리고 모든 통합 서비스를 검색하여 복잡한 작업을 수행할 수 있는 Research 기능을 제공합니다.
이 멀티 에이전트 시스템을 프로토타입에서 프로덕션까지 구축하는 여정을 통해 시스템 아키텍처, 도구 설계, 그리고 프롬프트 엔지니어링에 대한 중요한 교훈을 얻었습니다. 멀티 에이전트 시스템은 여러 에이전트(루프 내에서 자율적으로 도구를 사용하는 LLM)들이 함께 작동하는 구조입니다. 우리의 Research 기능은 사용자 쿼리를 기반으로 연구 프로세스를 계획하는 에이전트와, 동시에 정보를 검색하는 병렬 에이전트를 생성하는 도구를 사용합니다. 여러 에이전트가 있는 시스템은 에이전트 조정(coordination), 평가(evaluation), 그리고 신뢰성(reliability)에 있어 새로운 과제를 제시합니다.
이 글에서는 우리에게 효과적이었던 원칙들을 소개합니다. 여러분이 멀티 에이전트 시스템을 구축할 때 유용하게 활용하시길 바랍니다.
멀티 에이전트 시스템의 이점
연구 작업은 필요한 단계를 미리 예측하기 매우 어려운 개방형(open-ended) 문제를 수반합니다. 복잡한 주제를 탐색하기 위한 고정된 경로를 하드코딩할 수 없습니다. 왜냐하면 프로세스 자체가 본질적으로 동적이고 경로 의존적(path-dependent)이기 때문입니다. 사람들이 연구를 수행할 때는 발견한 내용을 바탕으로 접근 방식을 지속적으로 업데이트하며, 조사 중에 나타나는 단서를 따라갑니다.
이러한 예측 불가능성 때문에 AI 에이전트는 연구 작업에 특히 적합합니다. 연구는 조사가 진행되면서 방향을 전환하거나 관련된 연결고리를 탐색할 수 있는 유연성을 요구합니다. 모델은 중간 발견 사항을 바탕으로 어떤 방향을 추구할지 결정하면서 여러 턴 동안 자율적으로 작동해야 합니다. 선형적이고 일회성인 파이프라인으로는 이러한 작업을 처리할 수 없습니다.
검색의 본질은 압축(compression)입니다. 즉, 방대한 코퍼스에서 인사이트를 추출하는 것입니다. 서브-에이전트들은 각자의 컨텍스트 윈도우(context window를 가지고 병렬로 작동하며, 질문의 다양한 측면을 동시에 탐색한 후 리드 연구 에이전트(lead research agent를 위해 가장 중요한 토큰들을 압축함으로써 압축을 촉진합니다. 각 서브에이전트는 또한 관심사의 분리(separation of concerns)를 제공합니다. 즉, 고유한 도구, 프롬프트, 탐색 궤적을 가지므로 경로 의존성을 줄이고 철저하고 독립적인 조사를 가능하게 합니다.
지능이 일정 임계값에 도달하면, 멀티 에이전트 시스템은 성능을 확장하는 핵심적인 방법이 됩니다. 예를 들어, 개별 인간은 지난 100,000년 동안 더 지능적으로 진화했지만, 인간 사회는 정보화 시대에 집단 지능과 조정 능력 덕분에 기하급수적으로 더 유능해졌습니다. 범용 지능을 가진 에이전트조차도 개인으로 작동할 때는 한계에 직면하지만, 에이전트 그룹은 훨씬 더 많은 것을 달성할 수 있습니다.
우리의 내부 평가에 따르면, 멀티 에이전트 연구 시스템은 특히 여러 독립적인 방향을 동시에 추구하는 breadth-first 쿼리(너비 우선 쿼리)에서 탁월합니다. Claude Opus 4를 리드 에이전트로, Claude Sonnet 4를 서브에이전트로 사용하는 멀티 에이전트 시스템이 단일 에이전트 Claude Opus 4보다 내부 연구 평가에서 90.2% 더 우수한 성능을 보였습니다. 예를 들어, Information Technology S&P 500 기업들의 모든 이사회 구성원을 식별하라는 요청을 받았을 때, 멀티 에이전트 시스템은 이를 서브에이전트용 작업으로 분해하여 정확한 답을 찾았지만, 단일 에이전트 시스템은 느리고 순차적인 검색으로 답을 찾지 못했습니다.
멀티 에이전트 시스템이 주로 작동하는 이유는 문제를 해결하기 위해 충분한 토큰을 사용하는 데 도움이 되기 때문입니다. 우리의 분석에 따르면, BrowseComp 평가(찾기 어려운 정보를 찾는 브라우징 에이전트의 능력을 테스트)에서 성능 분산의 95%를 세 가지 요인이 설명했습니다. 토큰 사용량 자체가 분산의 80%를 설명했으며, 도구 호출 횟수와 모델 선택이 나머지 두 설명 요인이었습니다. 이 발견은 병렬 추론을 위한 용량을 추가하기 위해 별도의 컨텍스트 윈도우를 가진 에이전트들에게 작업을 분산하는 우리의 아키텍처를 검증합니다. 최신 Claude 모델들은 토큰 사용에 대한 큰 효율성 승수로 작용합니다. Claude Sonnet 4로 업그레이드하는 것이 Claude Sonnet 3.7에서 토큰 예산을 두 배로 늘리는 것보다 더 큰 성능 향상을 가져옵니다. 멀티 에이전트 아키텍처는 단일 에이전트의 한계를 초과하는 작업에 대해 토큰 사용량을 효과적으로 확장합니다.
단점도 있습니다. 실제로 이러한 아키텍처는 토큰을 빠르게 소모합니다. 우리 데이터에 따르면, 에이전트는 일반적으로 채팅 상호작용보다 약 4배 더 많은 토큰을 사용하며, 멀티 에이전트 시스템은 채팅보다 약 15배 더 많은 토큰을 사용합니다. 경제적 타당성을 위해, 멀티 에이전트 시스템은 향상된 성능에 대한 비용을 지불할 만큼 작업의 가치가 충분히 높아야 합니다. 또한, 모든 에이전트가 동일한 컨텍스트를 공유해야 하거나 에이전트 간 많은 의존성이 있는 일부 도메인은 현재 멀티 에이전트 시스템에 적합하지 않습니다. 예를 들어, 대부분의 코딩 작업은 연구보다 진정으로 병렬화할 수 있는 작업이 적으며, LLM 에이전트는 아직 다른 에이전트와 실시간으로 조정하고 위임하는 데 뛰어나지 않습니다. 우리는 멀티 에이전트 시스템이 강력한 병렬화, 단일 컨텍스트 윈도우를 초과하는 정보, 그리고 수많은 복잡한 도구와의 인터페이싱을 수반하는 가치 있는 작업에서 탁월하다는 것을 발견했습니다.
Research 아키텍처 개요
우리의 Research 시스템은 orchestrator-worker pattern(오케스트레이터-워커 패턴)을 사용하는 멀티 에이전트 아키텍처를 사용합니다. 여기서 리드 에이전트는 프로세스를 조정하면서 병렬로 작동하는 전문화된 서브에이전트에게 작업을 위임합니다.
작동 중인 멀티 에이전트 아키텍처: 사용자 쿼리가 리드 에이전트를 통과하고, 리드 에이전트는 다양한 측면을 병렬로 검색하기 위해 전문화된 서브에이전트를 생성합니다.
사용자가 쿼리를 제출하면, 리드 에이전트가 이를 분석하고, 전략을 개발하며, 다양한 측면을 동시에 탐색할 서브에이전트를 생성합니다. 위 다이어그램에서 보듯이, 서브에이전트는 검색 도구를 반복적으로 사용하여 정보를 수집하는 지능형 필터 역할을 합니다. 이 경우 2025년 AI 에이전트 기업에 대한 정보를 수집한 후, 리드 에이전트가 최종 답변을 작성할 수 있도록 기업 목록을 반환합니다.
Retrieval Augmented Generation(RAG, 검색 증강 생성)을 사용하는 전통적인 접근 방식은 정적 검색(static retrieval)을 사용합니다. 즉, 입력 쿼리와 가장 유사한 청크 세트를 가져와서 이러한 청크를 사용하여 응답을 생성합니다. 반면, 우리의 아키텍처는 관련 정보를 동적으로 찾고, 새로운 발견에 적응하며, 결과를 분석하여 고품질 답변을 공식화하는 다단계 검색(multi-step search)을 사용합니다.
멀티 에이전트 Research 시스템의 전체 워크플로우를 보여주는 프로세스 다이어그램. 사용자가 쿼리를 제출하면, 시스템은 반복적인 연구 프로세스에 진입하는 LeadResearcher 에이전트를 생성합니다. LeadResearcher는 접근 방식을 생각하고 계획을 Memory에 저장하여 컨텍스트를 유지하는 것으로 시작합니다. 컨텍스트 윈도우가 200,000토큰을 초과하면 잘릴 수 있으므로 계획을 보존하는 것이 중요합니다. 그런 다음 특정 연구 작업을 가진 전문화된 Subagent들(여기서는 두 개가 표시되지만 개수는 제한이 없음)을 생성합니다. 각 Subagent는 독립적으로 웹 검색을 수행하고, interleaved thinking(인터리브드 싱킹)을 사용하여 도구 결과를 평가하며, 발견 사항을 LeadResearcher에게 반환합니다. LeadResearcher는 이러한 결과를 종합하고 더 많은 연구가 필요한지 결정합니다. 필요한 경우 추가 서브에이전트를 생성하거나 전략을 수정할 수 있습니다. 충분한 정보가 수집되면, 시스템은 연구 루프를 종료하고 모든 발견 사항을 CitationAgent에 전달합니다. CitationAgent는 문서와 연구 보고서를 처리하여 citation(인용)을 위한 특정 위치를 식별합니다. 이를 통해 모든 주장이 출처에 적절히 귀속됩니다. 인용이 포함된 최종 연구 결과가 사용자에게 반환됩니다.
연구 에이전트를 위한 프롬프트 엔지니어링 및 평가
멀티 에이전트 시스템은 단일 에이전트 시스템과 주요 차이점이 있으며, 조정 복잡성이 급격히 증가합니다. 초기 에이전트들은 간단한 쿼리에 대해 50개의 서브에이전트를 생성하거나, 존재하지 않는 소스를 찾기 위해 웹을 끝없이 검색하거나, 과도한 업데이트로 서로를 방해하는 등의 오류를 만들었습니다. 각 에이전트는 프롬프트에 의해 조종되므로, 프롬프트 엔지니어링이 이러한 동작을 개선하는 우리의 주요 수단이었습니다. 다음은 에이전트 프롬프팅을 위해 배운 몇 가지 원칙입니다:
- 에이전트처럼 생각하세요. 프롬프트를 반복하려면, 그 효과를 이해해야 합니다. 이를 돕기 위해, 우리는 시스템의 정확한 프롬프트와 도구를 사용하여 Console에서 시뮬레이션을 구축하고, 에이전트가 단계별로 작동하는 것을 관찰했습니다. 이를 통해 실패 모드가 즉시 드러났습니다. 에이전트가 이미 충분한 결과를 얻었음에도 계속하거나, 지나치게 장황한 검색 쿼리를 사용하거나, 잘못된 도구를 선택하는 경우였습니다. 효과적인 프롬프팅은 에이전트에 대한 정확한 멘탈 모델을 개발하는 데 의존하며, 이를 통해 가장 영향력 있는 변경 사항이 명확해집니다.
- 오케스트레이터에게 위임 방법을 가르치세요. 우리 시스템에서, 리드 에이전트는 쿼리를 하위 작업으로 분해하고 이를 서브에이전트에게 설명합니다. 각 서브에이전트는 목표, 출력 형식, 사용할 도구와 소스에 대한 지침, 그리고 명확한 작업 경계가 필요합니다. 상세한 작업 설명이 없으면, 에이전트들은 작업을 중복하거나, 공백을 남기거나, 필요한 정보를 찾지 못합니다. 우리는 처음에 리드 에이전트가 ‘반도체 부족 연구’와 같은 간단하고 짧은 지침을 제공하도록 허용했지만, 이러한 지침은 종종 서브에이전트가 작업을 잘못 해석하거나 다른 에이전트와 정확히 동일한 검색을 수행할 만큼 모호했습니다. 예를 들어, 한 서브에이전트는 2021년 자동차 칩 위기를 탐색했고, 다른 두 서브에이전트는 현재 2025년 공급망을 조사하면서 작업을 중복했으며, 효과적인 업무 분담이 없었습니다.
- 쿼리 복잡성에 맞게 노력을 조정하세요. 에이전트는 다양한 작업에 적절한 노력을 판단하는 데 어려움을 겪으므로, 우리는 프롬프트에 스케일링 규칙을 포함했습니다. 간단한 사실 찾기는 3-10개의 도구 호출을 사용하는 1개의 에이전트만 필요하고, 직접 비교는 각각 10-15개의 호출을 사용하는 2-4개의 서브에이전트가 필요할 수 있으며, 복잡한 연구는 명확하게 나뉜 책임을 가진 10개 이상의 서브에이전트를 사용할 수 있습니다. 이러한 명시적인 지침은 리드 에이전트가 리소스를 효율적으로 할당하고 초기 버전에서 흔한 실패 모드였던 간단한 쿼리에 대한 과잉 투자를 방지하는 데 도움이 됩니다.
- 도구 설계와 선택이 중요합니다. 에이전트-도구 인터페이스는 인간-컴퓨터 인터페이스만큼 중요합니다. 올바른 도구를 사용하는 것은 효율적이며, 종종 엄격히 필요합니다. 예를 들어, Slack에만 존재하는 컨텍스트를 웹에서 검색하는 에이전트는 처음부터 실패할 운명입니다. 모델에게 외부 도구에 대한 액세스를 제공하는 MCP server를 사용하면, 에이전트가 품질이 매우 다양한 설명을 가진 본 적 없는 도구를 마주치기 때문에 이 문제가 복합됩니다. 우리는 에이전트에게 명시적인 휴리스틱을 제공했습니다. 예를 들어, 먼저 사용 가능한 모든 도구를 검토하고, 도구 사용을 사용자 의도에 맞추며, 광범위한 외부 탐색을 위해 웹을 검색하거나, 일반 도구보다 전문 도구를 선호하는 것입니다. 잘못된 도구 설명은 에이전트를 완전히 잘못된 경로로 보낼 수 있으므로, 각 도구는 명확한 목적과 명확한 설명이 필요합니다.
- 에이전트가 스스로 개선하도록 하세요. 우리는 Claude 4 모델이 훌륭한 프롬프트 엔지니어가 될 수 있다는 것을 발견했습니다. 프롬프트와 실패 모드가 주어지면, 에이전트가 왜 실패하는지 진단하고 개선 사항을 제안할 수 있습니다. 우리는 심지어 tool-testing agent(도구 테스팅 에이전트)를 만들었습니다. 결함이 있는 MCP 도구가 주어지면, 도구를 사용하려고 시도한 다음 실패를 피하기 위해 도구 설명을 다시 작성합니다. 도구를 수십 번 테스트함으로써, 이 에이전트는 주요 뉘앙스와 버그를 발견했습니다. 도구 ergonomics(사용성)을 개선하는 이 프로세스는 새로운 설명을 사용하는 향후 에이전트의 작업 완료 시간을 40% 감소시켰습니다. 대부분의 실수를 피할 수 있었기 때문입니다.
- 넓게 시작한 다음 좁혀가세요. 검색 전략은 전문가의 인간 연구를 반영해야 합니다. 구체적인 내용으로 들어가기 전에 전체적인 그림을 탐색하세요. 에이전트는 종종 결과가 거의 반환되지 않는 지나치게 길고 구체적인 쿼리를 기본적으로 사용합니다. 우리는 에이전트가 짧고 광범위한 쿼리로 시작하고, 사용 가능한 것을 평가한 다음, 점진적으로 초점을 좁히도록 프롬프팅하여 이러한 경향에 대응했습니다.
- 사고 과정을 안내하세요. Extended thinking mode(확장된 사고 모드)는 Claude가 보이는 사고 과정에서 추가 토큰을 출력하도록 하며, 제어 가능한 스크래치패드 역할을 할 수 있습니다. 리드 에이전트는 사고를 사용하여 접근 방식을 계획하고, 작업에 맞는 도구를 평가하며, 쿼리 복잡성과 서브에이전트 수를 결정하고, 각 서브에이전트의 역할을 정의합니다. 우리의 테스트 결과 확장된 사고가 지시 준수, 추론, 효율성을 개선했습니다. 서브에이전트도 계획을 수립한 다음, 도구 결과 이후 interleaved thinking을 사용하여 품질을 평가하고, 공백을 식별하며, 다음 쿼리를 개선합니다. 이를 통해 서브에이전트가 모든 작업에 더 효과적으로 적응할 수 있습니다.
- 병렬 도구 호출이 속도와 성능을 변화시킵니다. 복잡한 연구 작업은 당연히 많은 소스 탐색을 수반합니다. 우리의 초기 에이전트는 순차적 검색을 실행했으며, 이는 고통스러울 정도로 느렸습니다. 속도를 위해, 우리는 두 종류의 병렬화를 도입했습니다: (1) 리드 에이전트가 서브에이전트를 순차적이 아닌 병렬로 3-5개 생성합니다; (2) 서브에이전트가 병렬로 3개 이상의 도구를 사용합니다. 이러한 변경으로 복잡한 쿼리의 연구 시간이 최대 90% 단축되어, Research가 다른 시스템보다 더 많은 정보를 다루면서 시간이 아닌 몇 분 안에 더 많은 작업을 수행할 수 있게 되었습니다.
우리의 프롬프팅 전략은 엄격한 규칙보다는 좋은 휴리스틱을 주입하는 데 중점을 둡니다. 우리는 숙련된 인간이 연구 작업에 접근하는 방식을 연구하고 이러한 전략을 프롬프트에 인코딩했습니다. 어려운 질문을 더 작은 작업으로 분해하고, 출처의 품질을 신중하게 평가하며, 새로운 정보를 바탕으로 검색 접근 방식을 조정하고, 깊이(한 주제를 자세히 조사)와 넓이(여러 주제를 병렬로 탐색) 중 언제 집중할지 인식하는 전략입니다. 또한 에이전트가 통제 불능 상태가 되는 것을 방지하기 위해 명시적인 guardrail(가드레일)을 설정하여 의도하지 않은 부작용을 사전에 완화했습니다. 마지막으로, 우리는 관찰 가능성(observability)과 테스트 케이스를 갖춘 빠른 반복 루프에 집중했습니다.
에이전트의 효과적인 평가
좋은 평가는 신뢰할 수 있는 AI 애플리케이션을 구축하는 데 필수적이며, 에이전트도 다르지 않습니다. 그러나 멀티 에이전트 시스템을 평가하는 것은 고유한 과제를 제시합니다. 전통적인 평가는 종종 AI가 매번 동일한 단계를 따른다고 가정합니다. 입력 X가 주어지면, 시스템은 경로 Y를 따라 출력 Z를 생성해야 합니다. 그러나 멀티 에이전트 시스템은 이런 식으로 작동하지 않습니다. 동일한 시작점에서도, 에이전트는 목표에 도달하기 위해 완전히 다른 유효한 경로를 택할 수 있습니다. 한 에이전트는 세 개의 소스를 검색할 수 있고 다른 에이전트는 열 개를 검색할 수 있으며, 동일한 답을 찾기 위해 다른 도구를 사용할 수도 있습니다. 우리는 항상 올바른 단계가 무엇인지 알지 못하기 때문에, 에이전트가 미리 규정한 “올바른” 단계를 따랐는지 확인할 수 없는 경우가 많습니다. 대신, 합리적인 프로세스를 따르면서 에이전트가 올바른 결과를 달성했는지 판단하는 유연한 평가 방법이 필요합니다.
소규모 샘플로 즉시 평가를 시작하세요. 초기 에이전트 개발에서는 변경 사항이 극적인 영향을 미치는 경향이 있습니다. 쉽게 얻을 수 있는 성과가 풍부하기 때문입니다. 프롬프트 조정으로 성공률이 30%에서 80%로 상승할 수 있습니다. 이렇게 효과 크기가 큰 경우, 몇 가지 테스트 케이스만으로도 변경 사항을 발견할 수 있습니다. 우리는 실제 사용 패턴을 나타내는 약 20개의 쿼리 세트로 시작했습니다. 이러한 쿼리를 테스트하면 종종 변경 사항의 영향을 명확하게 볼 수 있었습니다. 우리는 AI 개발자 팀이 수백 개의 테스트 케이스가 있는 대규모 평가만 유용하다고 믿기 때문에 평가 생성을 지연한다는 말을 자주 듣습니다. 그러나 더 철저한 평가를 구축할 수 있을 때까지 기다리기보다는, 몇 가지 예제로 즉시 소규모 테스트를 시작하는 것이 가장 좋습니다.
LLM-as-judge 평가는 잘 수행하면 확장 가능합니다. 연구 출력은 자유 형식 텍스트이고 단일 정답이 거의 없기 때문에 프로그래밍 방식으로 평가하기 어렵습니다. LLM은 출력을 채점하는 데 자연스럽게 적합합니다. 우리는 루브릭의 기준에 따라 각 출력을 평가하는 LLM judge(저지)를 사용했습니다: factual accuracy(사실적 정확성)(주장이 출처와 일치하는가?), citation accuracy(인용 정확성)(인용된 출처가 주장과 일치하는가?), completeness(완전성)(요청된 모든 측면이 다루어졌는가?), source quality(출처 품질)(낮은 품질의 2차 출처보다 1차 출처를 사용했는가?), 그리고 tool efficiency(도구 효율성)(올바른 도구를 합리적인 횟수만큼 사용했는가?). 우리는 각 구성 요소를 평가하기 위해 여러 저지를 실험했지만, 0.0-1.0의 점수와 합격-불합격 등급을 출력하는 단일 프롬프트를 사용하는 단일 LLM 호출이 가장 일관되고 인간 판단과 일치한다는 것을 발견했습니다. 이 방법은 평가 테스트 케이스에 명확한 답이 있을 때 특히 효과적이었으며, LLM 저지를 사용하여 답이 정확한지 확인할 수 있었습니다(즉, R&D 예산이 상위 3위인 제약 회사를 정확하게 나열했는가?). LLM을 저지로 사용하면 수백 개의 출력을 확장 가능하게 평가할 수 있었습니다.
인간 평가는 자동화가 놓친 것을 포착합니다. 에이전트를 테스트하는 사람들은 평가가 놓친 엣지 케이스를 찾습니다. 여기에는 이상한 쿼리에 대한 hallucinated answer(환각된 답변), 시스템 실패, 또는 미묘한 출처 선택 편향이 포함됩니다. 우리의 경우, 인간 테스터는 초기 에이전트가 학술 PDF나 개인 블로그와 같은 권위 있지만 순위가 낮은 출처보다 SEO 최적화된 콘텐츠 팜을 일관되게 선택한다는 것을 발견했습니다. 프롬프트에 출처 품질 휴리스틱을 추가하여 이 문제를 해결하는 데 도움이 되었습니다. 자동화된 평가의 세계에서도 수동 테스트는 여전히 필수적입니다.
멀티 에이전트 시스템은 emergent behavior(창발적 행동)를 가지며, 이는 특정 프로그래밍 없이 발생합니다. 예를 들어, 리드 에이전트에 대한 작은 변경이 서브에이전트의 동작을 예측할 수 없게 변경할 수 있습니다. 성공하려면 개별 에이전트 동작뿐만 아니라 상호 작용 패턴을 이해해야 합니다. 따라서 이러한 에이전트를 위한 최선의 프롬프트는 엄격한 지시가 아니라 업무 분담, 문제 해결 접근 방식, 노력 예산을 정의하는 협업 프레임워크입니다. 이를 올바르게 수행하려면 신중한 프롬프팅과 도구 설계, 견고한 휴리스틱, 관찰 가능성, 그리고 긴밀한 피드백 루프가 필요합니다. 시스템의 프롬프트 예제는 Cookbook의 오픈 소스 프롬프트를 참조하세요.
프로덕션 신뢰성 및 엔지니어링 과제
전통적인 소프트웨어에서는 버그가 기능을 손상시키거나, 성능을 저하시키거나, 중단을 유발할 수 있습니다. agentic system(에이전트 시스템)에서는 사소한 변경이 큰 행동 변화로 연쇄적으로 확대되며, 이는 장기 실행 프로세스에서 상태를 유지해야 하는 복잡한 에이전트를 위한 코드를 작성하는 것을 매우 어렵게 만듭니다.
에이전트는 상태를 가지며 오류가 복합됩니다. 에이전트는 많은 도구 호출에 걸쳐 상태를 유지하면서 오랜 시간 동안 실행될 수 있습니다. 이는 코드를 안정적으로 실행하고 도중에 오류를 처리해야 함을 의미합니다. 효과적인 완화 조치가 없으면, 사소한 시스템 실패가 에이전트에게 치명적일 수 있습니다. 오류가 발생하면, 처음부터 다시 시작할 수 없습니다. 재시작은 비용이 많이 들고 사용자에게 불편을 줍니다. 대신, 우리는 오류가 발생했을 때 에이전트가 있던 지점부터 재개할 수 있는 시스템을 구축했습니다. 또한 모델의 지능을 사용하여 문제를 우아하게 처리합니다. 예를 들어, 도구가 실패할 때 에이전트에게 알리고 적응하도록 하는 것이 놀랍도록 잘 작동합니다. 우리는 Claude를 기반으로 구축된 AI 에이전트의 적응성을 재시도 로직 및 정기적인 checkpoint(체크포인트)와 같은 결정론적 보호 장치와 결합합니다.
디버깅은 새로운 접근 방식의 혜택을 받습니다. 에이전트는 동적 결정을 내리며 동일한 프롬프트를 사용하더라도 실행 간에 비결정적입니다. 이로 인해 디버깅이 더 어려워집니다. 예를 들어, 사용자는 에이전트가 “명백한 정보를 찾지 못한다”고 보고했지만, 우리는 그 이유를 볼 수 없었습니다. 에이전트가 잘못된 검색 쿼리를 사용하고 있었나요? 좋지 않은 출처를 선택하고 있었나요? 도구 실패를 겪고 있었나요? 전체 프로덕션 tracing(추적)을 추가하여 에이전트가 왜 실패했는지 진단하고 문제를 체계적으로 수정할 수 있었습니다. 표준 관찰 가능성을 넘어서, 우리는 사용자 개인정보를 유지하기 위해 개별 대화의 내용을 모니터링하지 않으면서 에이전트 결정 패턴과 상호 작용 구조를 모니터링합니다. 이러한 높은 수준의 관찰 가능성은 근본 원인을 진단하고, 예상치 못한 동작을 발견하며, 일반적인 실패를 수정하는 데 도움이 되었습니다.
배포에는 신중한 조정이 필요합니다. 에이전트 시스템은 거의 지속적으로 실행되는 프롬프트, 도구, 실행 로직의 고도로 상태를 가진 웹입니다. 즉, 업데이트를 배포할 때마다 에이전트가 프로세스의 어디에든 있을 수 있습니다. 따라서 선의의 코드 변경이 기존 에이전트를 손상시키는 것을 방지해야 합니다. 모든 에이전트를 동시에 새 버전으로 업데이트할 수 없습니다. 대신, 우리는 rainbow deployment를 사용하여 실행 중인 에이전트를 방해하지 않고, 두 버전을 동시에 실행하면서 트래픽을 이전 버전에서 새 버전으로 점진적으로 이동합니다.
동기 실행은 병목 현상을 만듭니다. 현재, 우리의 리드 에이전트는 서브에이전트를 동기적으로(synchronously) 실행하며, 진행하기 전에 각 서브에이전트 세트가 완료될 때까지 기다립니다. 이는 조정을 단순화하지만 에이전트 간의 정보 흐름에서 병목 현상을 만듭니다. 예를 들어, 리드 에이전트는 서브에이전트를 조종할 수 없고, 서브에이전트는 조정할 수 없으며, 단일 서브에이전트가 검색을 완료할 때까지 기다리는 동안 전체 시스템이 차단될 수 있습니다. 비동기 실행(asynchronous execution)은 추가적인 병렬성을 가능하게 합니다. 에이전트가 동시에 작동하고 필요할 때 새로운 서브에이전트를 생성합니다. 그러나 이러한 비동기성은 결과 조정, 상태 일관성, 서브에이전트 간 오류 전파에서 과제를 추가합니다. 모델이 더 길고 복잡한 연구 작업을 처리할 수 있게 되면서, 성능 향상이 복잡성을 정당화할 것으로 예상합니다.
결론
AI 에이전트를 구축할 때, 마지막 마일이 종종 대부분의 여정이 됩니다. 개발자 머신에서 작동하는 코드베이스는 신뢰할 수 있는 프로덕션 시스템이 되기 위해 상당한 엔지니어링이 필요합니다. 에이전트 시스템에서 오류의 복합적 특성은 전통적인 소프트웨어에 대한 사소한 문제가 에이전트를 완전히 탈선시킬 수 있음을 의미합니다. 한 단계가 실패하면 에이전트가 완전히 다른 궤적을 탐색하게 되어 예측할 수 없는 결과를 초래할 수 있습니다. 이 글에서 설명한 모든 이유로, 프로토타입과 프로덕션 사이의 격차는 종종 예상보다 넓습니다.
이러한 과제에도 불구하고, 멀티 에이전트 시스템은 개방형 연구 작업에서 가치 있는 것으로 입증되었습니다. 사용자들은 Claude가 고려하지 못했던 비즈니스 기회를 찾고, 복잡한 의료 옵션을 탐색하며, 까다로운 기술적 버그를 해결하고, 혼자서는 찾지 못했을 연구 연결을 발견하여 최대 며칠의 작업을 절약하는 데 도움을 주었다고 말했습니다. 멀티 에이전트 연구 시스템은 신중한 엔지니어링, 포괄적인 테스트, 세심한 프롬프트 및 도구 설계, 견고한 운영 관행, 그리고 현재 에이전트 능력에 대한 강한 이해를 가진 연구, 제품, 엔지니어링 팀 간의 긴밀한 협업을 통해 규모에 맞게 안정적으로 작동할 수 있습니다. 우리는 이미 이러한 시스템이 사람들이 복잡한 문제를 해결하는 방식을 변화시키는 것을 보고 있습니다.
assets/e991beab78cb96779636f407e289408a_MD5.webp]]
오늘날 사람들이 Research 기능을 사용하는 가장 일반적인 방법을 보여주는 Clio 임베딩 플롯. 상위 사용 사례 범주는 전문 도메인에 걸쳐 소프트웨어 시스템 개발(10%), 전문 및 기술 콘텐츠 개발 및 최적화(8%), 비즈니스 성장 및 수익 창출 전략 개발(8%), 학술 연구 및 교육 자료 개발 지원(7%), 그리고 사람, 장소 또는 조직에 대한 정보 연구 및 검증(5%)입니다.
다음은 멀티 에이전트 시스템을 위한 몇 가지 추가 팁입니다.
여러 턴에 걸쳐 상태를 변경하는 에이전트의 최종 상태 평가. 다중 턴 대화에서 지속적인 상태를 수정하는 에이전트를 평가하는 것은 고유한 과제를 제시합니다. 읽기 전용 연구 작업과 달리, 각 행동은 후속 단계를 위한 환경을 변경할 수 있으며, 전통적인 평가 방법이 처리하기 어려운 의존성을 만듭니다. 우리는 턴별 분석보다는 end-state evaluation(최종 상태 평가)에 집중하는 데 성공했습니다. 에이전트가 특정 프로세스를 따랐는지 판단하는 대신, 올바른 최종 상태를 달성했는지 평가하세요. 이 접근 방식은 에이전트가 동일한 목표에 대한 대안 경로를 찾을 수 있음을 인정하면서도 의도된 결과를 제공하도록 보장합니다. 복잡한 워크플로우의 경우, 모든 중간 단계를 검증하려고 시도하는 대신 특정 상태 변경이 발생해야 하는 discrete checkpoint(개별 체크포인트)로 평가를 나누세요.
장기 대화 관리. 프로덕션 에이전트는 종종 수백 턴에 걸친 대화에 참여하므로 신중한 컨텍스트 관리 전략이 필요합니다. 대화가 확장됨에 따라 표준 컨텍스트 윈도우가 불충분해지므로 지능형 압축 및 메모리 메커니즘이 필요합니다. 우리는 에이전트가 완료된 작업 단계를 요약하고 새로운 작업을 진행하기 전에 필수 정보를 외부 메모리에 저장하는 패턴을 구현했습니다. 컨텍스트 제한이 다가오면, 에이전트는 신중한 handoff(핸드오프)를 통해 연속성을 유지하면서 깨끗한 컨텍스트를 가진 새로운 서브에이전트를 생성할 수 있습니다. 또한, 컨텍스트 제한에 도달했을 때 이전 작업을 잃지 않고 메모리에서 연구 계획과 같은 저장된 컨텍스트를 검색할 수 있습니다. 이러한 분산 접근 방식은 확장된 상호 작용에서 대화 일관성을 유지하면서 컨텍스트 오버플로우를 방지합니다.
‘전화 게임’을 최소화하기 위한 파일 시스템으로의 서브에이전트 출력. 직접 서브에이전트 출력은 특정 유형의 결과에 대해 주요 조정자를 우회하여 충실도와 성능을 모두 향상시킬 수 있습니다. 서브에이전트가 리드 에이전트를 통해 모든 것을 전달하도록 요구하는 대신, 전문 에이전트가 독립적으로 지속되는 출력을 생성할 수 있는 artifact system(아티팩트 시스템)을 구현하세요. 서브에이전트는 도구를 호출하여 외부 시스템에 작업을 저장한 다음 조정자에게 경량 참조를 전달합니다. 이는 다단계 처리 중 정보 손실을 방지하고 대화 기록을 통해 대용량 출력을 복사하는 데 따른 토큰 오버헤드를 줄입니다. 이 패턴은 서브에이전트의 전문화된 프롬프트가 일반 조정자를 통해 필터링하는 것보다 더 나은 결과를 생성하는 코드, 보고서 또는 데이터 시각화와 같은 구조화된 출력에 특히 잘 작동합니다.
assets/0d8240802aaa5c0e1b73b75901d3b78f_MD5.svg]]