https://www.anthropic.com/engineering/built-multi-agent-research-system

이제 Claude는 웹, Google Workspace, 그리고 다양한 통합 기능을 활용해 복잡한 작업을 수행할 수 있는 연구 기능을 갖추었다.

이 멀티 에이전트 시스템을 프로토타입에서 실제 서비스로 발전시킨 과정에서 우리는 시스템 아키텍처, 도구 설계, 그리고 프롬프트 엔지니어링에 대한 중요한 교훈을 얻었다. 멀티 에이전트 시스템은 여러 에이전트(루프 안에서 도구를 자율적으로 사용하는 대형 언어 모델)가 함께 작업하는 시스템이다. 우리의 연구 기능은 사용자 질의를 기반으로 연구 프로세스를 계획하는 에이전트와, 동시에 정보를 검색하는 병렬 에이전트를 생성하는 도구를 포함한다. 여러 에이전트가 함께 작동하는 시스템은 에이전트 간 조정, 평가, 그리고 신뢰성 측면에서 새로운 도전 과제를 제시한다.

이 글에서는 우리가 경험한 원칙들을 정리했다. 여러분이 자신만의 멀티 에이전트 시스템을 구축할 때 유용한 참고 자료가 되길 바란다.

멀티 에이전트 시스템의 장점

연구 작업은 예측하기 어려운 개방형 문제를 다룬다. 복잡한 주제를 탐구할 때 고정된 경로를 미리 정해둘 수 없다. 연구 과정은 본질적으로 동적이며 경로에 의존하기 때문이다. 사람들이 연구를 진행할 때는 발견한 내용을 바탕으로 접근 방식을 지속적으로 업데이트하며, 조사 중에 나타나는 단서를 따라간다.

이런 예측 불가능성 때문에 AI 에이전트는 연구 작업에 특히 적합하다. 연구는 조사가 진행되면서 방향을 전환하거나 관련 없는 연결점을 탐구할 수 있는 유연성을 요구한다. 모델은 여러 단계에 걸쳐 자율적으로 작동하며 중간 결과를 바탕으로 어떤 방향으로 나아갈지 결정해야 한다. 단순한 일회성 파이프라인은 이런 작업을 처리할 수 없다.

탐구의 핵심은 압축이다. 방대한 자료에서 통찰을 추출하는 것이다. 하위 에이전트는 각자의 컨텍스트 윈도우를 사용해 병렬로 작업하며, 문제의 다양한 측면을 동시에 탐구한 후 주요 연구 에이전트에게 중요한 토큰을 압축해 전달한다. 각 하위 에이전트는 관심사를 분리해 독립적인 도구, 프롬프트, 탐구 경로를 제공함으로써 경로 의존성을 줄이고 철저한 독립 조사를 가능하게 한다.

지능이 일정 수준에 도달하면, 멀티 에이전트 시스템은 성능을 확장하는 중요한 방법이 된다. 예를 들어, 개별 인간의 지능은 지난 10만 년 동안 점점 발전했지만, 정보화 시대에 들어서면서 인간 사회는 집단 지능과 협업 능력 덕분에 기하급수적으로 더 많은 것을 이뤄냈다. 일반적으로 지능이 높은 에이전트라도 개별적으로 작동할 때는 한계에 부딪힌다. 에이전트 그룹은 훨씬 더 많은 것을 달성할 수 있다.

내부 평가 결과, 멀티 에이전트 연구 시스템은 특히 여러 독립적인 방향을 동시에 추구하는 너비 우선 탐색(breadth-first) 쿼리에서 뛰어난 성능을 보인다. Claude Opus 4를 주 에이전트로, Claude Sonnet 4를 하위 에이전트로 구성한 멀티 에이전트 시스템은 단일 에이전트 Claude Opus 4보다 내부 연구 평가에서 90.2% 더 높은 성능을 보였다. 예를 들어, 정보 기술 S&P 500 기업의 이사진을 모두 찾아내는 작업에서 멀티 에이전트 시스템은 이를 하위 에이전트의 작업으로 분해해 정답을 찾았지만, 단일 에이전트 시스템은 느린 순차적 탐색으로 답을 찾지 못했다.

멀티 에이전트 시스템이 효과를 발휘하는 주된 이유는 문제를 해결하기에 충분한 토큰을 사용할 수 있기 때문이다. 분석 결과, BrowseComp 평가(탐색 에이전트가 찾기 어려운 정보를 찾는 능력을 테스트)에서 성능 차이의 95%를 세 가지 요인이 설명했다. 토큰 사용량 자체가 차이의 80%를 설명했으며, 도구 호출 횟수와 모델 선택이 나머지 두 가지 요인이었다. 이 결과는 작업을 별도의 컨텍스트 윈도우를 가진 에이전트에 분배해 병렬 추론 용량을 늘린 구조의 타당성을 입증한다. 최신 Claude 모델은 토큰 사용에 대해 큰 효율 승수를 제공하며, Claude Sonnet 3.7에서 Claude Sonnet 4로 업그레이드하면 토큰 예산을 두 배로 늘리는 것보다 더 큰 성능 향상을 가져온다. 멀티 에이전트 아키텍처는 단일 에이전트의 한계를 넘어서는 작업에 토큰 사용을 효과적으로 확장한다.

단점도 있다. 실제로 이런 아키텍처는 토큰을 빠르게 소모한다. 데이터에 따르면, 에이전트는 일반적으로 채팅 상호작용보다 약 4배 더 많은 토큰을 사용하며, 멀티 에이전트 시스템은 채팅보다 약 15배 더 많은 토큰을 사용한다. 경제적 타당성을 위해 멀티 에이전트 시스템은 작업의 가치가 성능 향상을 위한 비용을 충당할 수 있을 만큼 높아야 한다. 또한, 모든 에이전트가 동일한 컨텍스트를 공유해야 하거나 에이전트 간에 많은 의존성이 있는 도메인은 현재 멀티 에이전트 시스템에 적합하지 않다. 예를 들어, 대부분의 코딩 작업은 연구보다 병렬화 가능한 작업이 적으며, LLM 에이전트는 아직 실시간으로 다른 에이전트와 협업하고 작업을 위임하는 데 능숙하지 않다. 우리는 멀티 에이전트 시스템이 높은 병렬화, 단일 컨텍스트 윈도우를 초과하는 정보, 그리고 수많은 복잡한 도구와의 인터페이스가 필요한 가치 있는 작업에서 탁월한 성능을 발휘한다는 사실을 발견했다.

리서치 시스템 아키텍처 개요

리서치 시스템은 오케스트레이터-워커 패턴을 기반으로 한 멀티 에이전트 아키텍처를 사용한다. 여기서 리드 에이전트가 전체 프로세스를 조율하고, 특화된 서브 에이전트들이 병렬로 작업을 수행한다.

멀티 에이전트 아키텍처가 동작하는 방식: 사용자 쿼리는 리드 에이전트를 거쳐 특화된 서브 에이전트들이 다양한 측면을 병렬로 탐색한다.

사용자가 쿼리를 제출하면, 리드 에이전트가 이를 분석하고 전략을 수립한 후 여러 서브 에이전트를 생성해 동시에 다양한 측면을 탐색한다. 위 다이어그램에서 볼 수 있듯, 서브 에이전트들은 지능형 필터 역할을 하며 검색 도구를 반복적으로 사용해 정보를 수집한다. 이 예시에서는 2025년 AI 에이전트 기업에 대한 정보를 모아 리드 에이전트에게 반환하고, 리드 에이전트는 최종 답변을 작성한다.

기존의 Retrieval Augmented Generation(RAG) 접근 방식은 정적 검색을 사용한다. 즉, 입력 쿼리와 가장 유사한 청크를 가져와 이를 기반으로 응답을 생성한다. 반면, 이 아키텍처는 동적 검색을 사용해 관련 정보를 찾고, 새로운 발견에 적응하며, 결과를 분석해 고품질의 답변을 도출한다.

멀티 에이전트 리서치 시스템의 전체 워크플로우를 보여주는 프로세스 다이어그램. 사용자가 쿼리를 제출하면 시스템은 LeadResearcher 에이전트를 생성하고 반복적인 리서치 프로세스를 시작한다. LeadResearcher는 접근 방식을 고민하고 계획을 메모리에 저장해 컨텍스트를 유지한다. 컨텍스트 윈도우가 200,000 토큰을 초과하면 잘리기 때문에 계획을 유지하는 것이 중요하다. 그런 다음 특정 리서치 작업을 수행할 서브 에이전트를 생성한다(여기서는 두 개로 표시되었지만, 실제로는 여러 개가 될 수 있다). 각 서브 에이전트는 독립적으로 웹 검색을 수행하고, 인터리브드 사고를 사용해 도구 결과를 평가한 후 LeadResearcher에게 결과를 반환한다. LeadResearcher는 이러한 결과를 종합하고 추가 리서치가 필요한지 결정한다. 필요하다면 추가 서브 에이전트를 생성하거나 전략을 수정한다. 충분한 정보가 수집되면 시스템은 리서치 루프를 종료하고 모든 발견을 CitationAgent에게 전달한다. CitationAgent는 문서와 리서치 리포트를 처리해 인용이 필요한 구체적인 위치를 식별한다. 이를 통해 모든 주장이 출처에 정확히 귀속되도록 보장한다. 최종 리서치 결과는 인용과 함께 사용자에게 반환된다.

연구 에이전트를 위한 프롬프트 엔지니어링과 평가

멀티 에이전트 시스템은 단일 에이전트 시스템과 몇 가지 중요한 차이점이 있으며, 그 중 하나는 조정 복잡성이 빠르게 증가한다는 점이다. 초기 에이전트들은 간단한 쿼리에 대해 50개의 하위 에이전트를 생성하거나, 존재하지 않는 소스를 찾기 위해 웹을 끝없이 탐색하거나, 지나치게 많은 업데이트로 서로를 방해하는 등의 오류를 범했다. 각 에이전트는 프롬프트로 조종되기 때문에, 이러한 행동을 개선하기 위해 우리는 주로 프롬프트 엔지니어링에 초점을 맞췄다. 아래는 에이전트를 프롬프팅할 때 배운 몇 가지 원칙이다:

1. 에이전트의 입장에서 생각한다. 프롬프트를 반복적으로 개선하려면 그 효과를 이해해야 한다. 이를 위해 우리는 Console을 사용해 시스템의 정확한 프롬프트와 도구를 시뮬레이션하고, 에이전트가 단계별로 작업하는 과정을 관찰했다. 이 과정에서 에이전트가 충분한 결과를 얻었음에도 계속 작업하거나, 지나치게 장황한 검색 쿼리를 사용하거나, 잘못된 도구를 선택하는 등의 실패 모드를 즉시 확인할 수 있었다. 효과적인 프롬프팅은 에이전트의 정확한 정신적 모델을 개발하는 데 달려 있으며, 이는 가장 큰 변화를 명확히 만들어낼 수 있다.

2. 오케스트레이터에게 위임하는 방법을 가르친다. 우리 시스템에서 리드 에이전트는 쿼리를 하위 작업으로 분해하고 이를 하위 에이전트에게 설명한다. 각 하위 에이전트는 목표, 출력 형식, 사용할 도구와 소스에 대한 지침, 그리고 명확한 작업 경계가 필요하다. 상세한 작업 설명이 없으면 에이전트는 작업을 중복하거나, 공백을 남기거나, 필요한 정보를 찾지 못한다. 우리는 리드 에이전트가 ‘반도체 부족 현상을 조사하라’와 같은 간단하고 짧은 지시를 내리도록 허용했지만, 이러한 지시는 종종 너무 모호해서 하위 에이전트가 작업을 오해하거나 다른 에이전트와 동일한 검색을 수행하는 경우가 많았다. 예를 들어, 한 하위 에이전트는 2021년 자동차 칩 위기를 탐색하는 동안, 다른 두 에이전트는 2025년 공급망을 조사하는 작업을 중복으로 수행했고, 효과적인 분업이 이루어지지 않았다.

3. 쿼리 복잡성에 맞춰 노력을 조정한다. 에이전트는 다양한 작업에 적절한 노력을 판단하는 데 어려움을 겪기 때문에, 우리는 프롬프트에 규모 조정 규칙을 포함시켰다. 간단한 사실 확인은 1개의 에이전트와 3-10번의 도구 호출만 필요하며, 직접적인 비교는 2-4개의 하위 에이전트와 각각 10-15번의 호출이 필요할 수 있고, 복잡한 연구는 10개 이상의 하위 에이전트와 명확히 분할된 책임이 필요할 수 있다. 이러한 명시적인 지침은 리드 에이전트가 자원을 효율적으로 할당하고 간단한 쿼리에 과도하게 투자하는 것을 방지하는 데 도움이 되며, 이는 초기 버전에서 흔히 발생하던 실패 모드였다.

4. 도구 설계와 선택이 중요하다. 에이전트-도구 인터페이스는 인간-컴퓨터 인터페이스만큼 중요하다. 적절한 도구를 사용하는 것은 효율적이며, 종종 필수적이다. 예를 들어, Slack에만 존재하는 컨텍스트를 웹에서 검색하는 에이전트는 처음부터 실패할 운명이다. MCP 서버를 사용해 모델이 외부 도구에 접근할 수 있게 되면서, 이 문제는 더욱 복잡해졌다. 에이전트는 품질이 천차만별인 설명을 가진 미지의 도구를 마주하게 된다. 우리는 에이전트에게 명시적인 휴리스틱을 제공했다: 예를 들어, 모든 사용 가능한 도구를 먼저 검토하고, 도구 사용을 사용자 의도에 맞추고, 웹을 검색해 넓은 외부 탐색을 수행하거나, 일반적인 도구보다 특수한 도구를 선호하도록 했다. 나쁜 도구 설명은 에이전트를 완전히 잘못된 길로 이끌 수 있으므로, 각 도구는 명확한 목적과 설명이 필요하다.

5. 에이전트가 스스로 개선하도록 한다. 우리는 Claude 4 모델이 훌륭한 프롬프트 엔지니어가 될 수 있다는 사실을 발견했다. 프롬프트와 실패 모드가 주어지면, 에이전트가 왜 실패하는지 진단하고 개선 사항을 제안할 수 있다. 우리는 도구 테스트 에이전트도 만들었다. 이 에이전트는 결함이 있는 MCP 도구를 사용해보고, 실패를 방지하기 위해 도구 설명을 다시 작성한다. 이 에이전트는 도구를 수십 번 테스트하면서 중요한 뉘앙스와 버그를 발견했다. 이 도구 인체공학 개선 과정은 새로운 설명을 사용하는 미래의 에이전트들이 대부분의 실수를 피할 수 있게 해주어 작업 완료 시간을 40% 단축시켰다.

6. 넓게 시작한 후 좁혀간다. 검색 전략은 전문가의 연구 방식을 반영해야 한다: 구체적인 내용을 파고들기 전에 전체적인 상황을 탐색한다. 에이전트는 종종 지나치게 길고 구체적인 쿼리를 기본값으로 사용해 적은 결과를 반환한다. 우리는 에이전트가 짧고 넓은 쿼리로 시작해, 사용 가능한 것을 평가한 후 점차 초점을 좁히도록 프롬프팅해 이 경향을 상쇄했다.

7. 사고 과정을 안내한다. 확장 사고 모드는 Claude가 추가 토큰을 출력해 보이는 사고 과정을 제공하며, 조절 가능한 스크래치패드 역할을 할 수 있다. 리드 에이전트는 이 사고를 사용해 접근 방식을 계획하고, 작업에 적합한 도구를 평가하며, 쿼리 복잡성과 하위 에이전트 수를 결정하고, 각 하위 에이전트의 역할을 정의한다. 우리의 테스트는 확장 사고가 지시 따르기, 추론, 그리고 효율성을 개선한다는 것을 보여주었다. 하위 에이전트도 계획을 세운 후, 도구 결과를 평가하고, 공백을 식별하며, 다음 쿼리를 개선하기 위해 교차 사고를 사용한다. 이는 하위 에이전트가 어떤 작업에도 더 효과적으로 적응할 수 있게 해준다.

8. 병렬 도구 호출이 속도와 성능을 변화시킨다. 복잡한 연구 작업은 자연스럽게 많은 소스를 탐색하는 과정을 포함한다. 우리의 초기 에이전트는 순차적 검색을 실행했는데, 이는 매우 느렸다. 속도를 위해 우리는 두 가지 병렬화를 도입했다: (1) 리드 에이전트가 순차적으로가 아니라 병렬로 3-5개의 하위 에이전트를 생성한다; (2) 하위 에이전트가 3개 이상의 도구를 병렬로 사용한다. 이러한 변경으로 복잡한 쿼리의 연구 시간이 최대 90% 단축되었고, 다른 시스템보다 더 많은 정보를 다루며 몇 분 안에 더 많은 작업을 수행할 수 있게 되었다.

우리의 프롬프팅 전략은 엄격한 규칙보다는 좋은 휴리스틱을 심어주는 데 초점을 맞춘다. 우리는 숙련된 인간이 연구 작업에 접근하는 방식을 연구하고, 이를 우리의 프롬프트에 인코딩했다. 이 전략에는 어려운 질문을 더 작은 작업으로 분해하고, 소스의 품질을 신중하게 평가하며, 새로운 정보를 바탕으로 검색 접근 방식을 조정하고, 깊이(한 주제를 상세히 조사)와 폭(많은 주제를 병렬로 탐색) 중 어디에 초점을 맞출지 인식하는 것이 포함된다. 또한, 에이전트가 통제를 벗어나지 않도록 명시적인 가드레일을 설정해 의도하지 않은 부작용을 사전에 방지했다. 마지막으로, 관찰 가능성과 테스트 케이스를 통해 빠른 반복 루프에 집중했다.

에이전트 효과적인 평가 방법

신뢰할 수 있는 AI 애플리케이션을 구축하려면 철저한 평가가 필수적이며, 에이전트도 예외는 아니다. 하지만 멀티 에이전트 시스템을 평가할 때는 특별한 어려움이 따른다. 전통적인 평가 방식은 주로 AI가 매번 동일한 단계를 거칠 것이라는 전제를 깔고 진행된다. 즉, 입력 X가 주어지면 시스템은 Y 경로를 따라 출력 Z를 생성해야 한다는 것이다. 하지만 멀티 에이전트 시스템은 이와 다르게 동작한다. 동일한 출발점에서도 에이전트들은 목표를 달성하기 위해 완전히 다른 유효한 경로를 선택할 수 있다. 한 에이전트는 세 개의 소스를 검토하고, 다른 에이전트는 열 개의 소스를 검토할 수도 있으며, 동일한 답을 찾기 위해 다른 도구를 사용할 수도 있다. 우리가 항상 올바른 단계를 알 수 없기 때문에, 에이전트가 미리 정해둔 “올바른” 단계를 따랐는지 확인하는 방식은 적합하지 않다. 대신, 에이전트가 합리적인 과정을 거쳐 올바른 결과를 달성했는지 판단할 수 있는 유연한 평가 방법이 필요하다.

소규모 샘플로 즉각적인 평가 시작하기. 에이전트 개발 초기에는 작은 변화도 큰 영향을 미칠 수 있다. 프롬프트를 약간 수정하는 것만으로도 성공률이 30%에서 80%로 급상승할 수 있다. 이런 큰 효과를 감안할 때, 몇 가지 테스트 케이스만으로도 변화를 명확하게 확인할 수 있다. 우리는 실제 사용 패턴을 반영한 약 20개의 쿼리 세트로 시작했다. 이 쿼리를 자주 테스트하면서 변화의 영향을 명확하게 확인할 수 있었다. 많은 AI 개발 팀이 수백 개의 테스트 케이스가 포함된 대규모 평가만이 유용하다고 생각해 평가 구축을 미루는 경우가 많다. 하지만 가능한 한 빨리 소규모 테스트를 시작하는 것이 더 효과적이다.

LLM-as-judge 평가는 잘 활용하면 확장성이 뛰어나다. 연구 결과물은 자유 형식의 텍스트이며, 단일 정답이 거의 없기 때문에 프로그램적으로 평가하기 어렵다. LLM은 이런 출력물을 평가하는 데 적합하다. 우리는 각 출력물을 기준에 따라 평가하는 LLM 판단 시스템을 사용했다. 평가 기준은 사실 정확성(주장이 출처와 일치하는가?), 인용 정확성(인용된 출처가 주장과 일치하는가?), 완전성(요청된 모든 측면을 다뤘는가?), 출처 품질(저품질의 2차 출처보다 1차 출처를 사용했는가?), 도구 효율성(적절한 도구를 적절한 횟수로 사용했는가?) 등이었다. 여러 판단자를 통해 각 요소를 평가하는 실험도 했지만, 0.0-1.0 점수와 합격/불합격 판정을 출력하는 단일 프롬프트로 구성된 단일 LLM 호출이 가장 일관적이고 인간의 판단과 일치했다. 이 방법은 특히 평가 테스트 케이스에 명확한 답이 있을 때 효과적이었다(예: R&D 예산 상위 3개 제약회사를 정확히 나열했는가?). LLM을 판단자로 사용함으로써 수백 개의 출력물을 확장 가능하게 평가할 수 있었다.

자동화된 평가가 놓친 부분은 인간 평가로 잡아낸다. 에이전트를 테스트하는 사람들은 평가에서 놓친 예외 사항을 발견한다. 이에는 특이한 쿼리에 대한 잘못된 답변, 시스템 오류, 미묘한 출처 선택 편향 등이 포함된다. 우리의 경우, 초기 에이전트가 학술 PDF나 개인 블로그 같은 권위 있는 출처보다 SEO 최적화된 콘텐츠 팜을 일관적으로 선택한다는 사실을 인간 테스터가 발견했다. 프롬프트에 출처 품질 휴리스틱을 추가해 이 문제를 해결했다. 자동화된 평가가 보편화된 상황에서도 수동 테스트는 여전히 필수적이다.

멀티 에이전트 시스템은 특정 프로그래밍 없이도 새로운 동작이 나타나는 특성을 보인다. 예를 들어, 주 에이전트에 작은 변화를 가하면 하위 에이전트의 동작이 예측할 수 없게 바뀔 수 있다. 성공을 위해서는 개별 에이전트의 동작뿐만 아니라 상호작용 패턴을 이해해야 한다. 따라서 이들 에이전트를 위한 최적의 프롬프트는 엄격한 지시사항이 아니라, 업무 분담, 문제 해결 접근 방식, 노력 예산 등을 정의하는 협업 프레임워크여야 한다. 이를 올바르게 구현하려면 신중한 프롬프트와 도구 설계, 견고한 휴리스틱, 관찰 가능성, 빠른 피드백 루프가 필요하다. 우리 시스템의 예시 프롬프트는 쿡북의 오픈소스 프롬프트에서 확인할 수 있다.

프로덕션 신뢰성과 엔지니어링 과제

기존 소프트웨어에서는 버그가 기능을 중단시키거나 성능을 저하시키는 정도로 그쳤다. 하지만 에이전트 시스템에서는 사소한 변경이 큰 행동 변화로 이어질 수 있다. 이는 장기 실행 프로세스에서 상태를 유지해야 하는 복잡한 에이전트를 위한 코드를 작성하기 어렵게 만든다.

에이전트는 상태를 유지하며 에러가 누적된다. 에이전트는 오랜 시간 동안 실행되며 여러 도구 호출을 거쳐 상태를 유지한다. 따라서 코드를 안정적으로 실행하고 중간에 발생하는 에러를 처리해야 한다. 효과적인 대응책이 없다면 사소한 시스템 장애도 에이전트에게 치명적일 수 있다. 에러가 발생했을 때 처음부터 재시작할 수는 없다. 재시작은 사용자에게 비용이 크고 불편을 초래한다. 대신 에러가 발생한 시점부터 에이전트를 재개할 수 있는 시스템을 구축했다. 또한 모델의 지능을 활용해 문제를 우아하게 처리한다. 예를 들어, 도구가 실패할 때 에이전트에게 알려주고 적응하도록 하는 방식은 놀라울 정도로 잘 작동한다. Claude 기반 AI 에이전트의 적응성과 재시도 로직, 정기적인 체크포인트 같은 결정론적 안전장치를 결합한다.

디버깅은 새로운 접근 방식이 필요하다. 에이전트는 동적 결정을 내리며, 동일한 프롬프트라도 실행마다 비결정론적이다. 이는 디버깅을 더 어렵게 만든다. 예를 들어 사용자는 에이전트가 “명백한 정보를 찾지 못한다”고 보고했지만, 그 이유를 알 수 없었다. 에이전트가 잘못된 검색 쿼리를 사용했을까? 나쁜 소스를 선택했을까? 도구 실패를 겪었을까? 전체 프로덕션 추적을 추가해 에이전트가 실패한 이유를 진단하고 문제를 체계적으로 수정할 수 있었다. 표준 관찰 가능성 외에도 에이전트의 결정 패턴과 상호작용 구조를 모니터링한다. 개별 대화 내용을 모니터링하지 않으면서 사용자 프라이버시를 유지한다. 이러한 높은 수준의 관찰 가능성은 근본 원인을 진단하고 예상치 못한 동작을 발견하며 일반적인 실패를 수정하는 데 도움을 준다.

배포는 신중한 조정이 필요하다. 에이전트 시스템은 프롬프트, 도구, 실행 로직으로 구성된 고도로 상태를 유지하는 웹이며 거의 지속적으로 실행된다. 이는 업데이트를 배포할 때 에이전트가 프로세스의 어느 단계에 있을지 모른다는 뜻이다. 따라서 기존 에이전트를 중단시키지 않으려면 코드 변경에 주의해야 한다. 모든 에이전트를 동시에 새 버전으로 업데이트할 수는 없다. 대신 레인보우 배포를 사용해 실행 중인 에이전트를 방해하지 않는다. 이 방식은 오래된 버전과 새로운 버전을 동시에 실행하면서 점진적으로 트래픽을 전환한다.

동기식 실행은 병목 현상을 만든다. 현재 리드 에이전트는 하위 에이전트를 동기식으로 실행하며, 각 하위 에이전트가 완료될 때까지 기다린다. 이는 조정을 단순화하지만 에이전트 간 정보 흐름에 병목 현상을 만든다. 예를 들어 리드 에이전트는 하위 에이전트를 조종할 수 없고, 하위 에이전트는 서로 조정할 수 없으며, 단일 하위 에이전트가 검색을 마칠 때까지 전체 시스템이 차단될 수 있다. 비동기식 실행은 추가적인 병렬성을 가능하게 한다. 에이전트가 동시에 작업하고 필요할 때 새로운 하위 에이전트를 생성할 수 있다. 하지만 이러한 비동기성은 결과 조정, 상태 일관성, 하위 에이전트 간 에러 전파에서 새로운 과제를 추가한다. 모델이 더 길고 복잡한 연구 작업을 처리할 수 있게 됨에 따라 성능 향상이 복잡성을 정당화할 것으로 기대한다.

결론

AI 에이전트를 구축할 때, 마지막 단계가 전체 과정의 대부분을 차지하는 경우가 많다. 개발자 머신에서 작동하는 코드베이스는 신뢰할 수 있는 프로덕션 시스템으로 전환하기 위해 상당한 엔지니어링 노력이 필요하다. 에이전트 시스템에서 발생하는 오류의 복합적인 특성은 전통적인 소프트웨어에서는 사소한 문제일 수 있지만, 에이전트 전체를 완전히 무너뜨릴 수 있다. 하나의 단계가 실패하면 에이전트가 전혀 다른 경로를 탐색하게 되어 예측 불가능한 결과를 초래할 수 있다. 이 글에서 설명한 모든 이유로 인해, 프로토타입과 프로덕션 사이의 격차는 종종 예상보다 더 크다.

이러한 어려움에도 불구하고, 멀티 에이전트 시스템은 개방형 연구 작업에서 그 가치를 입증했다. 사용자들은 Claude가 고려하지 못했던 비즈니스 기회를 찾고, 복잡한 의료 옵션을 탐색하며, 까다로운 기술적 버그를 해결하고, 혼자서는 발견하지 못했을 연구 연결을 찾아 며칠의 작업 시간을 절약하는 데 도움을 준다고 말했다. 멀티 에이전트 연구 시스템은 신중한 엔지니어링, 포괄적인 테스트, 세심한 프롬프트 및 도구 설계, 견고한 운영 관행, 그리고 현재 에이전트의 능력을 깊이 이해하는 연구, 제품, 엔지니어링 팀 간의 긴밀한 협력을 통해 대규모로 안정적으로 운영될 수 있다. 우리는 이미 이러한 시스템이 사람들이 복잡한 문제를 해결하는 방식을 변화시키는 것을 목격하고 있다.

Clio 임베딩 플롯은 현재 사람들이 연구 기능을 사용하는 가장 일반적인 방법을 보여준다. 주요 사용 사례 카테고리는 전문 도메인 간 소프트웨어 시스템 개발(10%), 전문 및 기술 콘텐츠 개발 및 최적화(8%), 비즈니스 성장 및 수익 창출 전략 개발(8%), 학술 연구 및 교육 자료 개발 지원(7%), 사람, 장소 또는 조직에 대한 정보 연구 및 검증(5%)이다.

감사의 말

이 글은 Jeremy Hadfield, Barry Zhang, Kenneth Lien, Florian Scholz, Jeremy Fox, 그리고 Daniel Ford가 작성했다. 이 작업은 Anthropic의 여러 팀이 함께 노력한 결과물로, Research 기능을 가능하게 한 모든 분들의 공헌이 담겨 있다. 특히 Anthropic 앱 엔지니어링 팀에게 특별한 감사를 전한다. 그들의 헌신 덕분에 복잡한 멀티 에이전트 시스템을 실제 프로덕션 환경에 적용할 수 있었다. 또한 초기 사용자들의 소중한 피드백에 깊이 감사드린다.

부록

다음은 멀티 에이전트 시스템을 위한 추가적인 팁들이다.

상태를 여러 차례에 걸쳐 변경하는 에이전트의 최종 상태 평가. 지속적인 상태를 여러 차례의 대화를 통해 변경하는 에이전트를 평가하는 것은 독특한 도전 과제를 제시한다. 읽기 전용 연구 작업과 달리, 각 행동은 이후 단계의 환경을 바꿀 수 있으며, 이는 전통적인 평가 방법으로는 처리하기 어려운 의존성을 만든다. 우리는 턴별 분석보다는 최종 상태 평가에 초점을 맞추는 것이 효과적임을 발견했다. 에이전트가 특정 프로세스를 따랐는지 판단하는 대신, 올바른 최종 상태를 달성했는지 평가한다. 이 접근법은 에이전트가 동일한 목표에 도달하기 위해 다양한 경로를 찾을 수 있음을 인정하면서도 원하는 결과를 제공하는지 확인한다. 복잡한 워크플로우의 경우, 모든 중간 단계를 검증하려고 시도하기보다는 특정 상태 변화가 발생했어야 할 이산적인 체크포인트로 평가를 나눈다.

장기 대화 관리. 프로덕션 에이전트는 종종 수백 차례에 걸친 대화를 진행하므로, 신중한 컨텍스트 관리 전략이 필요하다. 대화가 길어질수록 표준 컨텍스트 윈도우는 부족해지며, 지능적인 압축과 메커니즘이 필요하다. 우리는 에이전트가 완료된 작업 단계를 요약하고 새로운 작업을 진행하기 전에 필수 정보를 외부 메모리에 저장하는 패턴을 구현했다. 컨텍스트 제한에 가까워지면, 에이전트는 깨끗한 컨텍스트를 가진 새로운 서브에이전트를 생성하면서도 신중한 인수인계를 통해 연속성을 유지할 수 있다. 또한, 컨텍스트 제한에 도달했을 때 이전 작업을 잃지 않도록 메모리에서 연구 계획과 같은 저장된 컨텍스트를 검색할 수 있다. 이 분산된 접근법은 컨텍스트 오버플로우를 방지하면서도 장기적인 상호작용에서 대화의 일관성을 유지한다.

‘전화 게임’을 최소화하기 위해 서브에이전트 출력을 파일 시스템에 저장. 특정 유형의 결과에 대해 서브에이전트 출력이 메인 코디네이터를 우회할 수 있도록 하면 충실도와 성능이 모두 향상된다. 서브에이전트가 모든 것을 리드 에이전트를 통해 전달하도록 요구하는 대신, 전문 에이전트가 독립적으로 지속할 수 있는 출력을 생성할 수 있는 아티팩트 시스템을 구현한다. 서브에이전트는 도구를 호출하여 자신의 작업을 외부 시스템에 저장한 다음, 코디네이터에게 경량 참조를 전달한다. 이는 다단계 처리 중 정보 손실을 방지하고 대화 기록을 통해 큰 출력을 복사하는 토큰 오버헤드를 줄인다. 이 패턴은 코드, 보고서, 데이터 시각화와 같은 구조화된 출력에서 특히 잘 작동하며, 서브에이전트의 전문 프롬프트가 일반 코디네이터를 통한 필터링보다 더 나은 결과를 생성한다.