우리는 멀티 에이전트 리서치 시스템을 어떻게 구축했는가

How we built our multi-agent research system

우리의 Research 기능은 여러 Claude 에이전트를 활용하여 복잡한 주제를 보다 효과적으로 탐구합니다. 이 시스템을 구축하면서 겪은 엔지니어링 과제와 얻은 교훈을 공유합니다.

Claude는 이제 웹, Google Workspace, 그리고 다양한 통합 도구를 가로질러 복잡한 작업을 수행할 수 있는 Research(연구) 기능을 갖추고 있습니다.

이 멀티 에이전트 시스템이 프로토타입에서 프로덕션까지 발전하는 과정에서 우리는 시스템 아키텍처, 도구 설계, 프롬프트 엔지니어링에 관한 중요한 교훈을 얻었습니다. 멀티 에이전트 시스템이란 여러 에이전트(도구를 자율적으로 사용하는 LLM들이 루프를 이루며 함께 작동하는 구조)로 구성되어 있습니다. 우리의 Research 기능은 사용자의 쿼리에 따라 연구 과정을 계획하는 에이전트가 있고, 이 에이전트가 도구를 사용해 정보를 동시에 검색하는 병렬 에이전트들을 생성합니다. 여러 에이전트가 함께 작동하는 시스템은 에이전트 간의 조정, 평가, 신뢰성 등 새로운 과제를 동반합니다.

이 글에서는 우리가 실제로 적용해 효과를 본 원칙들을 소개합니다. 여러분이 직접 멀티 에이전트 시스템을 구축할 때에도 도움이 되길 바랍니다.

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

Research(연구) 작업은 사전에 필요한 단계를 예측하기 매우 어려운 개방형 문제를 포함합니다. 복잡한 주제를 탐구하는 데 있어 고정된 경로를 하드코딩할 수 없습니다. 과정 자체가 본질적으로 동적이고 경로에 따라 달라지기 때문입니다. 사람들이 연구를 할 때는 조사 과정에서 발견되는 새로운 단서를 따라가며 접근 방식을 계속해서 업데이트합니다.

이러한 예측 불가능성 때문에 AI 에이전트는 연구 작업에 특히 적합합니다. 연구는 조사 과정에서 방향을 전환하거나 주변 연결고리를 탐색할 수 있는 유연성이 필요합니다. 모델은 여러 차례에 걸쳐 자율적으로 작동하며, 중간 결과를 바탕으로 어떤 방향을 추구할지 결정해야 합니다. 선형적이고 일회성 파이프라인으로는 이러한 작업을 처리할 수 없습니다.

검색의 본질은 압축입니다. 방대한 자료에서 통찰을 추출하는 것이죠. 서브에이전트들은 각자의 컨텍스트 윈도우에서 병렬로 작동하며, 질문의 다양한 측면을 동시에 탐색한 뒤, 가장 중요한 토큰을 리드 연구 에이전트에게 압축해 전달합니다. 각 서브에이전트는 또한 관심사의 분리를 제공합니다. 즉, 각기 다른 도구, 프롬프트, 탐색 경로를 사용함으로써 경로 의존성을 줄이고 철저하고 독립적인 조사가 가능해집니다.

지능이 일정 수준에 도달하면, 멀티 에이전트 시스템은 성능을 확장하는 데 필수적인 방법이 됩니다. 예를 들어, 지난 10만 년 동안 개별 인간의 지능은 조금씩 향상되었지만, 인간 사회는 집단 지능과 협업 능력 덕분에 정보화 시대에 기하급수적으로 더 강력해졌습니다. 일반적으로 지능이 높은 에이전트라도 혼자 작동할 때는 한계가 있지만, 여러 에이전트가 함께하면 훨씬 더 많은 일을 해낼 수 있습니다.

우리의 내부 평가에 따르면, 멀티 에이전트 연구 시스템은 여러 독립적인 방향을 동시에 추구해야 하는 폭넓은(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(오케스트레이터-워커) 패턴의 멀티 에이전트 아키텍처를 사용합니다. 리드 에이전트가 전체 과정을 조율하며, 병렬로 작동하는 특화된 서브에이전트들에게 작업을 위임합니다.

사용자가 쿼리를 제출하면, 리드 에이전트는 이를 분석하고 전략을 개발한 뒤, 여러 서브에이전트를 생성해 다양한 측면을 동시에 탐색하게 합니다. 위의 다이어그램에서 볼 수 있듯, 서브에이전트들은 반복적으로 검색 도구를 사용해 정보를 수집하고(이 예시에서는 2025년 AI 에이전트 기업에 대한 정보), 그 결과를 리드 에이전트에게 반환하여 최종 답변을 만듭니다.

기존의 Retrieval Augmented Generation(RAG) 방식은 정적 검색을 사용합니다. 즉, 입력 쿼리와 가장 유사한 일부 청크를 가져와 이를 바탕으로 응답을 생성합니다. 반면, 우리의 아키텍처는 여러 단계의 검색을 통해 동적으로 관련 정보를 찾고, 새로운 발견에 따라 적응하며, 결과를 분석해 고품질의 답변을 만듭니다.

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

멀티 에이전트 시스템은 단일 에이전트 시스템과 달리 조정 복잡도가 급격히 증가합니다. 초기 에이전트들은 단순 쿼리에 50개의 서브에이전트를 생성하거나, 존재하지 않는 소스를 끝없이 찾거나, 과도한 업데이트로 서로를 방해하는 등의 오류를 범했습니다. 각 에이전트는 프롬프트에 의해 조정되므로, 프롬프트 엔지니어링이 이러한 행동을 개선하는 주요 수단이었습니다. 아래는 우리가 에이전트 프롬프트를 설계하며 얻은 원칙들입니다.

1. 에이전트의 입장에서 생각하라. 프롬프트를 반복적으로 개선하려면, 그 효과를 이해해야 합니다. 이를 위해 우리는 시스템에서 사용하는 프롬프트와 도구를 그대로 사용해 Console에서 시뮬레이션을 만들고, 에이전트가 한 단계씩 작업하는 모습을 관찰했습니다. 이를 통해 즉시 실패 원인을 파악할 수 있었습니다. 예를 들어, 이미 충분한 결과가 있는데도 계속 작업을 이어가거나, 지나치게 장황한 검색 쿼리를 사용하거나, 잘못된 도구를 선택하는 경우 등입니다. 효과적인 프롬프트 설계는 에이전트의 정확한 정신 모델을 개발하는 데 달려 있으며, 이는 가장 영향력 있는 변화를 명확히 해줍니다.
2. 오케스트레이터에게 위임 방법을 가르쳐라. 우리 시스템에서 리드 에이전트는 쿼리를 하위 작업으로 분해해 서브에이전트에게 설명합니다. 각 서브에이전트는 목표, 출력 형식, 사용할 도구와 소스에 대한 안내, 명확한 작업 경계가 필요합니다. 작업 설명이 부족하면, 에이전트들이 작업을 중복하거나, 누락하거나, 필요한 정보를 찾지 못합니다. 처음에는 리드 에이전트가 ‘반도체 부족 사태를 조사하라’와 같이 간단하고 짧은 지시만 내렸지만, 이런 지시는 서브에이전트가 작업을 오해하거나, 다른 에이전트와 동일한 검색을 반복하는 경우가 많았습니다. 예를 들어, 한 서브에이전트는 2021년 자동차 칩 위기를 조사하고, 두 명은 2025년 공급망을 중복 조사하는 등 효과적인 역할 분담이 이루어지지 않았습니다.
3. 노력의 크기를 쿼리 복잡도에 맞춰라. 에이전트는 작업별로 적절한 노력을 판단하는 데 어려움을 겪으므로, 프롬프트에 스케일링 규칙을 내장했습니다. 단순 사실 확인은 1명의 에이전트와 310회의 도구 호출만 필요하고, 직접 비교는 24명의 서브에이전트와 각 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-판사 평가 방식은 잘만 하면 확장성이 있다. 연구 결과는 자유 형식의 텍스트로, 단일 정답이 없는 경우가 많아 프로그램적으로 평가하기 어렵습니다. LLM은 결과를 평가하는 데 자연스럽게 적합합니다. 우리는 LLM 판사가 각 결과를 루브릭의 기준에 따라 평가하도록 했습니다. 기준은 사실 정확성(주장이 소스와 일치하는가?), 인용 정확성(인용된 소스가 주장과 일치하는가?), 완전성(요청한 모든 측면이 다뤄졌는가?), 소스 품질(1차 소스를 사용했는가?), 도구 효율성(적절한 도구를 적정 횟수 사용했는가?) 등입니다. 각 요소를 여러 판사가 평가하는 방식도 실험했지만, 단일 LLM 호출로 0.0~1.0 점수와 합격/불합격 판정을 내리는 방식이 가장 일관되고 인간 평가와 잘 맞았습니다. 특히 테스트 케이스에 명확한 정답이 있는 경우, LLM 판사가 답이 정확한지(예: R&D 예산이 가장 큰 제약회사 3곳을 정확히 나열했는가?) 단순히 확인하는 데 매우 효과적이었습니다. LLM을 판사로 활용하면 수백 개의 결과를 확장성 있게 평가할 수 있습니다.

사람의 평가는 자동화가 놓치는 부분을 잡아낸다. 사람이 에이전트를 테스트하면 평가가 놓치는 엣지 케이스를 발견할 수 있습니다. 예를 들어, 특이한 쿼리에서 잘못된 답을 환각(hallucination)하거나, 시스템이 실패하거나, 미묘한 소스 선택 편향이 발생하는 경우입니다. 실제로 우리의 초기 에이전트는 권위 있는 학술 PDF나 개인 블로그보다 SEO 최적화된 콘텐츠 팜을 더 자주 선택하는 경향이 있었습니다. 프롬프트에 소스 품질 휴리스틱을 추가해 이 문제를 해결했습니다. 자동 평가가 보편화된 시대에도, 수동 테스트는 여전히 필수적입니다.

멀티 에이전트 시스템에는 특정 프로그래밍 없이도 발생하는 창발적 행동(emergent behavior)이 있습니다. 예를 들어, 리드 에이전트에 작은 변화를 주면, 서브에이전트의 행동이 예측 불가능하게 바뀔 수 있습니다. 성공하려면 개별 에이전트의 행동뿐 아니라 상호작용 패턴을 이해해야 합니다. 따라서 이 에이전트들을 위한 최적의 프롬프트는 엄격한 지시가 아니라, 협업의 틀, 역할 분담, 문제 해결 방식, 노력 예산을 정의하는 프레임워크입니다. 이를 잘 설계하려면 프롬프트와 도구 설계, 견고한 휴리스틱, 관찰성, 빠른 피드백 루프가 필수입니다. 시스템에서 사용한 예시 프롬프트는 Cookbook의 오픈소스 프롬프트를 참고하세요.

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

전통적인 소프트웨어에서는 버그가 기능을 망가뜨리거나, 성능 저하, 장애를 일으킬 수 있습니다. 에이전트 시스템에서는 작은 변화가 대규모 행동 변화를 유발해, 복잡한 에이전트의 상태를 장기간 유지하는 코드를 작성하는 것이 매우 어렵습니다.

에이전트는 상태를 가지며, 오류가 누적된다. 에이전트는 오랜 시간 동안 작동하며, 여러 도구 호출에 걸쳐 상태를 유지합니다. 따라서 코드를 안정적으로 실행하고, 중간에 오류가 발생해도 이를 처리할 수 있어야 합니다. 효과적인 완화책이 없으면, 작은 시스템 장애도 에이전트에게 치명적일 수 있습니다. 오류가 발생하면 처음부터 다시 시작할 수 없으므로, 에이전트가 오류가 발생한 시점에서 다시 이어서 작업할 수 있도록 시스템을 구축했습니다. 또한, 모델의 지능을 활용해 문제를 유연하게 처리합니다. 예를 들어, 도구가 실패하면 에이전트에게 이를 알리고, 적응하게 하는 방식이 의외로 잘 작동했습니다. Claude 기반 AI 에이전트의 적응력과, 재시도 로직 및 정기 체크포인트와 같은 결정론적 안전장치를 결합했습니다.

디버깅에는 새로운 접근이 필요하다. 에이전트는 동적으로 의사결정을 내리며, 동일한 프롬프트로도 실행마다 결과가 달라집니다. 이 때문에 디버깅이 더 어렵습니다. 예를 들어, 사용자가 “에이전트가 명백한 정보를 찾지 못한다”고 보고해도, 그 이유를 알 수 없었습니다. 에이전트가 잘못된 검색 쿼리를 썼는지, 나쁜 소스를 선택했는지, 도구 오류가 있었는지 알 수 없었습니다. 전체 프로덕션 트레이싱을 추가해 에이전트가 왜 실패했는지 진단하고, 체계적으로 문제를 해결할 수 있었습니다. 표준 관찰성 외에도, 에이전트의 의사결정 패턴과 상호작용 구조를 모니터링합니다(개별 대화 내용은 모니터링하지 않아 사용자 프라이버시는 보장). 이런 고수준 관찰성 덕분에 근본 원인을 진단하고, 예기치 않은 행동을 발견하며, 일반적인 실패를 고칠 수 있었습니다.

배포에는 신중한 조정이 필요하다. 에이전트 시스템은 프롬프트, 도구, 실행 로직이 거의 지속적으로 작동하는 고도로 상태적인 구조입니다. 따라서 업데이트를 배포할 때, 에이전트가 어디까지 진행 중이든 영향을 받지 않도록 해야 합니다. 모든 에이전트를 동시에 새 버전으로 업데이트할 수 없으므로, 무지개 배포(rainbow deployment) 방식을 사용해, 구버전과 신버전을 동시에 운영하며 점진적으로 트래픽을 전환합니다.

동기 실행은 병목을 만든다. 현재 리드 에이전트는 서브에이전트가 모두 끝날 때까지 기다리는 동기 방식으로 실행됩니다. 이는 조정을 단순화하지만, 에이전트 간 정보 흐름에 병목을 만듭니다. 예를 들어, 리드 에이전트가 서브에이전트를 조정할 수 없고, 서브에이전트끼리 협업할 수 없으며, 한 서브에이전트가 검색을 마칠 때까지 전체 시스템이 대기해야 할 수 있습니다. 비동기 실행은 추가 병렬성을 가능하게 합니다. 즉, 에이전트가 동시에 작업하고, 필요할 때 새 서브에이전트를 생성할 수 있습니다. 하지만 비동기화는 결과 조정, 상태 일관성, 오류 전파 등에서 추가적인 도전과제를 동반합니다. 모델이 더 길고 복잡한 연구 작업을 처리할 수 있게 되면, 성능 향상이 복잡성을 상쇄할 것으로 기대합니다.

결론

AI 에이전트를 구축할 때, 마지막 단계가 전체 여정의 대부분이 되는 경우가 많습니다. 개발자 환경에서 잘 작동하는 코드베이스도, 신뢰할 수 있는 프로덕션 시스템이 되려면 상당한 엔지니어링이 필요합니다. 에이전트 시스템에서는 오류가 누적되기 때문에, 전통적 소프트웨어에서 사소한 문제가 에이전트에게는 치명적일 수 있습니다. 한 단계가 실패하면, 에이전트가 완전히 다른 경로로 탐색을 시작해 예측 불가능한 결과로 이어질 수 있습니다. 이런 이유로, 프로토타입과 프로덕션 사이의 간극은 예상보다 훨씬 큽니다.

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

부록

아래는 멀티 에이전트 시스템을 위한 추가 팁입니다.

여러 턴에 걸쳐 상태를 변경하는 에이전트의 최종 상태 평가. 여러 턴에 걸쳐 지속적으로 상태를 변경하는 에이전트를 평가하는 것은 고유한 과제를 동반합니다. 읽기 전용 연구 작업과 달리, 각 행동이 이후 단계의 환경을 바꿔 전통적 평가 방식이 어려워집니다. 우리는 턴별 분석 대신 최종 상태 평가에 집중해 성공을 거두었습니다. 즉, 에이전트가 특정 과정을 따랐는지보다, 올바른 최종 상태에 도달했는지 평가합니다. 이 방식은 에이전트가 다양한 경로로 동일한 목표에 도달할 수 있음을 인정하면서도, 의도한 결과를 보장합니다. 복잡한 워크플로우의 경우, 중간 단계마다 특정 상태 변화가 일어났는지 체크포인트로 나눠 평가하는 것이 좋습니다.

장기 대화 관리. 프로덕션 에이전트는 수백 턴에 걸친 대화를 수행하므로, 컨텍스트 관리 전략이 필요합니다. 대화가 길어지면 표준 컨텍스트 윈도우로는 부족해, 지능적 압축 및 메모리 메커니즘이 필요합니다. 우리는 에이전트가 완료된 작업 단계를 요약해 외부 메모리에 저장한 뒤, 새로운 작업을 진행하는 패턴을 구현했습니다. 컨텍스트 한계에 다다르면, 에이전트는 깨끗한 컨텍스트로 새 서브에이전트를 생성하고, 연구 계획 등 저장된 컨텍스트를 메모리에서 불러와 연속성을 유지할 수 있습니다. 이런 분산 접근법은 컨텍스트 오버플로우를 방지하면서, 장기 대화의 일관성을 보장합니다.

서브에이전트의 출력물을 파일시스템에 저장해 ‘전달 게임’을 최소화. 특정 유형의 결과에 대해, 서브에이전트의 출력을 메인 코디네이터를 거치지 않고 직접 저장하면, 정확성과 성능이 모두 향상됩니다. 서브에이전트가 도구를 호출해 외부 시스템에 작업 결과를 저장하고, 경량 참조만 코디네이터에 전달하는 방식입니다. 이는 다단계 처리 과정에서 정보 손실을 방지하고, 대화 기록을 통해 대용량 출력을 복사하는 데 드는 토큰 오버헤드를 줄여줍니다. 이 패턴은 코드, 보고서, 데이터 시각화 등 서브에이전트의 특화 프롬프트가 일반 코디네이터를 거치는 것보다 더 나은 결과를 내는 구조화된 출력에 특히 효과적입니다.