Anthropic기술 블로그
멀티 에이전트 리서치 시스템 구축기
Claude Research 시스템을 구축하면서 겪은 엔지니어링 과제와 교훈
Claude에 리서치 기능이 추가되었습니다. 이제 웹, Google Workspace, 그리고 연동된 다양한 통합 서비스를 검색하여 복잡한 작업을 수행할 수 있습니다.
이 멀티 에이전트 시스템을 프로토타입에서 프로덕션까지 끌어올리는 과정에서, 시스템 아키텍처와 도구 설계, 프롬프트 엔지니어링에 관한 핵심적인 교훈을 얻었습니다. 멀티 에이전트 시스템이란 여러 에이전트(도구를 자율적으로 반복 사용하는 LLM)가 협력하여 작업을 수행하는 구조입니다. 리서치 기능에서는 사용자 쿼리를 바탕으로 조사 과정을 계획하는 에이전트가, 도구를 활용해 병렬로 정보를 검색하는 하위 에이전트들을 생성합니다. 이처럼 복수의 에이전트가 함께 작동하는 시스템에서는 에이전트 간 조율, 평가, 안정성 확보라는 새로운 과제가 생깁니다.
이 글에서는 저희에게 효과적이었던 원칙들을 하나씩 풀어보겠습니다. 여러분이 직접 멀티 에이전트 시스템을 구축할 때 참고할 수 있기를 바랍니다.
멀티 에이전트 시스템의 장점
리서치는 본질적으로 개방형 문제를 다루기 때문에, 필요한 단계를 미리 예측하기가 매우 어렵습니다. 복잡한 주제를 탐색하는 과정은 본질적으로 동적이고, 이전 단계의 결과에 따라 경로가 달라지므로 고정된 경로를 하드코딩할 수 없습니다. 실제로 사람이 리서치를 할 때도 조사 과정에서 새로운 단서를 발견하면서 접근 방식을 계속 수정해 나갑니다.
이런 예측 불가능성 때문에 AI 에이전트가 리서치 작업에 특히 적합합니다. 리서치에는 조사 과정에서 방향을 전환하거나 파생된 연결 고리를 탐색할 수 있는 유연성이 필요합니다. 모델이 여러 턴에 걸쳐 자율적으로 작동하면서, 중간 결과를 바탕으로 어떤 방향을 탐색할지 스스로 판단해야 합니다. 선형적인 단일 파이프라인으로는 이런 작업을 처리할 수 없습니다.
검색의 본질은 압축, 즉 방대한 자료에서 핵심 인사이트를 추출하는 것입니다. 서브에이전트는 각자의 컨텍스트 윈도우를 가지고 병렬로 작동하면서, 질문의 서로 다른 측면을 동시에 탐색한 뒤 가장 중요한 토큰만 리드 리서치 에이전트에게 압축하여 전달합니다. 또한 각 서브에이전트는 고유한 도구, 프롬프트, 탐색 경로를 가지므로 관심사가 분리되어, 경로 의존성이 줄고 독립적이면서도 심층적인 조사가 가능해집니다.
지능이 일정 수준에 도달하면, 멀티 에이전트 시스템은 성능을 확장하는 핵심 수단이 됩니다. 예를 들어, 지난 10만 년간 개개인의 지능도 발전했지만, 인류 사회가 정보화 시대에 기하급수적으로 더 강력해진 것은 집단 지성과 협업 능력 덕분입니다. 아무리 범용적인 지능을 가진 에이전트라도 단독으로는 한계가 있습니다. 에이전트가 모이면 훨씬 더 많은 것을 해낼 수 있습니다.
내부 평가 결과, 멀티 에이전트 리서치 시스템은 여러 독립적인 방향을 동시에 탐색해야 하는 너비 우선(breadth-first) 쿼리에서 특히 뛰어난 성능을 보였습니다. Claude Opus 4를 리드 에이전트로, Claude Sonnet 4를 서브에이전트로 구성한 멀티 에이전트 시스템은 내부 리서치 평가에서 단일 에이전트 Claude Opus 4 대비 90.2% 높은 성능을 기록했습니다. 예를 들어, S&P 500 정보기술 섹터에 속한 모든 기업의 이사회 구성원을 찾으라는 질문에서, 멀티 에이전트 시스템은 작업을 서브에이전트별로 분해하여 정확한 답을 찾아낸 반면, 단일 에이전트 시스템은 느리고 순차적인 검색으로 답을 찾지 못했습니다.
멀티 에이전트 시스템이 효과적인 근본적인 이유는, 문제 해결에 충분한 토큰을 투입할 수 있게 해주기 때문입니다. BrowseComp 평가(브라우징 에이전트가 찾기 어려운 정보를 얼마나 잘 찾는지 테스트)를 분석한 결과, 성능 분산의 95%를 세 가지 요인으로 설명할 수 있었습니다. 토큰 사용량만으로 분산의 80%가 설명되었고, 도구 호출 횟수와 모델 선택이 나머지를 차지했습니다. 이 결과는 별도의 컨텍스트 윈도우를 가진 에이전트들에게 작업을 분산시켜 병렬 추론 용량을 확보하는 저희 아키텍처의 타당성을 뒷받침합니다. 최신 Claude 모델은 토큰 활용 효율을 크게 높여주는데, Claude Sonnet 4로 업그레이드하는 것이 Claude Sonnet 3.7의 토큰 예산을 두 배로 늘리는 것보다 더 큰 성능 향상을 가져옵니다. 멀티 에이전트 아키텍처는 단일 에이전트의 한계를 초과하는 작업에서 토큰 사용량을 효과적으로 확장합니다.
물론 단점도 있습니다. 실제로 이러한 아키텍처는 토큰을 빠르게 소모합니다. 저희 데이터에 따르면, 에이전트는 일반 채팅 대비 약 4배, 멀티 에이전트 시스템은 약 15배 더 많은 토큰을 사용합니다. 경제적으로 성립하려면, 증가된 비용을 감당할 만큼 작업의 가치가 충분히 높아야 합니다. 또한 모든 에이전트가 동일한 컨텍스트를 공유해야 하거나 에이전트 간 의존성이 많은 영역은 현재의 멀티 에이전트 시스템에 적합하지 않습니다. 예를 들어, 대부분의 코딩 작업은 리서치에 비해 진정한 병렬 처리가 가능한 부분이 적고, LLM 에이전트는 아직 실시간으로 다른 에이전트에게 작업을 조율하고 위임하는 데 능숙하지 않습니다. 저희 경험상, 멀티 에이전트 시스템은 높은 수준의 병렬 처리가 필요하고, 단일 컨텍스트 윈도우를 초과하는 정보를 다루며, 다수의 복잡한 도구와 상호작용해야 하는 고부가가치 작업에서 가장 빛을 발합니다.
리서치 아키텍처 개요
리서치 시스템은 오케스트레이터-워커 패턴 기반의 멀티 에이전트 아키텍처를 사용합니다. 리드 에이전트가 전체 프로세스를 조율하면서, 병렬로 작동하는 전문 서브에이전트들에게 작업을 위임합니다.
사용자가 쿼리를 제출하면, 리드 에이전트가 이를 분석하고 전략을 수립한 뒤, 다양한 측면을 동시에 탐색할 서브에이전트들을 생성합니다. 위 다이어그램에서 볼 수 있듯이, 서브에이전트는 지능형 필터 역할을 합니다. 검색 도구를 반복 사용하여 정보를 수집하고(이 예시에서는 2025년 AI 에이전트 기업에 대한 정보), 기업 목록을 리드 에이전트에게 반환하면 리드 에이전트가 최종 답변을 종합합니다.
기존의 RAG(Retrieval Augmented Generation, 검색 증강 생성) 접근 방식은 정적 검색을 사용합니다. 입력 쿼리와 가장 유사한 청크 몇 개를 가져와서 응답을 생성하는 식입니다. 반면 저희 아키텍처는 다단계 검색을 통해 관련 정보를 동적으로 찾아내고, 새로운 발견에 적응하며, 결과를 분석하여 높은 품질의 답변을 도출합니다.
리서치 에이전트를 위한 프롬프트 엔지니어링과 평가
멀티 에이전트 시스템은 단일 에이전트 시스템과 핵심적인 차이가 있으며, 그중 하나가 조율 복잡성의 급격한 증가입니다. 초기 에이전트들은 간단한 쿼리에도 서브에이전트를 50개씩 생성하거나, 존재하지 않는 출처를 찾아 웹을 끝없이 탐색하거나, 과도한 상태 업데이트로 서로를 방해하는 등의 오류를 보였습니다. 각 에이전트는 프롬프트로 제어되므로, 프롬프트 엔지니어링이 이러한 동작을 개선하는 가장 핵심적인 수단이었습니다. 다음은 에이전트 프롬프팅에서 얻은 원칙들입니다:
- 에이전트의 시각으로 생각하라. 프롬프트를 반복 개선하려면, 프롬프트가 에이전트에 미치는 영향을 정확히 이해해야 합니다. 이를 위해 저희는 실제 시스템의 프롬프트와 도구를 그대로 적용한 시뮬레이션을 Console에서 구축하고, 에이전트가 단계별로 작업하는 과정을 관찰했습니다. 이를 통해 실패 패턴이 즉시 드러났습니다. 이미 충분한 결과를 확보했는데도 검색을 계속하거나, 지나치게 장황한 검색 쿼리를 사용하거나, 잘못된 도구를 선택하는 경우 등이었습니다. 효과적인 프롬프팅의 핵심은 에이전트에 대한 정확한 멘탈 모델을 구축하는 것이며, 이를 통해 가장 영향력 있는 개선점이 자연스럽게 보이게 됩니다.
- 오케스트레이터에게 위임 방법을 가르쳐라. 저희 시스템에서 리드 에이전트는 쿼리를 하위 작업으로 분해하여 서브에이전트에게 설명합니다. 각 서브에이전트에는 목표, 출력 형식, 사용할 도구와 소스에 대한 안내, 명확한 작업 경계가 필요합니다. 상세한 작업 설명이 없으면, 에이전트들이 작업을 중복 수행하거나, 빈틈을 남기거나, 필요한 정보를 찾지 못합니다. 처음에는 리드 에이전트가 '반도체 부족 현상을 조사하라'처럼 간단하고 짧은 지시만 내리도록 했는데, 이런 모호한 지시는 서브에이전트가 작업을 잘못 해석하거나 다른 에이전트와 똑같은 검색을 수행하는 결과를 초래했습니다. 실제로 한 서브에이전트는 2021년 자동차 칩 위기를 탐색하는 동안, 나머지 2개 에이전트가 2025년 현재의 공급망을 중복 조사하는 식으로 효과적인 분업이 이루어지지 않았습니다.
- 쿼리 복잡도에 맞춰 노력을 조절하라. 에이전트는 작업별로 적절한 노력 수준을 스스로 판단하기 어렵기 때문에, 프롬프트에 리소스 배분 규칙을 직접 포함시켰습니다. 단순한 사실 확인은 에이전트 1개에 도구 호출 3~10회, 직접적인 비교 작업은 서브에이전트 2~4개에 각 10~15회, 복잡한 리서치는 명확히 분업된 서브에이전트 10개 이상을 사용하는 식입니다. 이러한 명시적 가이드라인을 통해 리드 에이전트가 리소스를 효율적으로 배분하고, 초기 버전에서 흔히 발생했던 단순 쿼리에 대한 과잉 투자를 방지할 수 있었습니다.
- 도구 설계와 선택이 핵심이다. 에이전트-도구 인터페이스는 사람-컴퓨터 인터페이스만큼이나 중요합니다. 올바른 도구를 사용하는 것은 효율적일 뿐 아니라, 대부분의 경우 필수입니다. 예를 들어, Slack에만 존재하는 정보를 웹에서 검색하는 에이전트는 처음부터 실패가 정해져 있습니다. MCP 서버⟧/T42⟧를 통해 모델이 외부 도구에 접근할 수 있게 되면 이 문제가 더 심화됩니다. 에이전트가 품질이 천차만별인 설명과 함께 처음 보는 도구를 마주하게 되기 때문입니다. 저희는 에이전트에게 명시적인 휴리스틱을 제공했습니다. 예를 들어, 먼저 사용 가능한 모든 도구를 살펴보고, 사용자 의도에 맞게 도구를 선택하고, 넓은 범위의 외부 탐색에는 웹 검색을 사용하고, 범용 도구보다 전문 도구를 우선하라는 식입니다. 잘못된 도구 설명은 에이전트를 완전히 엉뚱한 방향으로 이끌 수 있으므로, 각 도구에는 명확한 용도와 설명이 필요합니다.
- 에이전트가 스스로를 개선하게 하라. Claude 4 모델이 뛰어난 프롬프트 엔지니어가 될 수 있다는 사실을 확인했습니다. 프롬프트와 실패 사례를 함께 제공하면, 에이전트가 왜 실패하는지 진단하고 개선안을 제안할 수 있습니다. 더 나아가 도구 테스트 에이전트도 만들었는데, 결함이 있는 MCP 도구가 주어지면 직접 사용해 본 뒤 실패를 방지할 수 있도록 도구 설명을 다시 작성합니다. 도구를 수십 차례 테스트하는 과정에서 이 에이전트는 핵심적인 뉘앙스와 버그를 발견했습니다. 이러한 도구 사용성 개선 프로세스를 통해, 새로운 설명을 사용하는 후속 에이전트의 작업 완료 시간이 40% 단축되었습니다. 대부분의 실수를 사전에 피할 수 있게 되었기 때문입니다.
- 넓게 시작해서 점차 좁혀라. 검색 전략은 숙련된 사람의 리서치 방식을 따라야 합니다. 세부 사항에 파고들기 전에 먼저 전체 지형을 파악하는 것입니다. 에이전트는 지나치게 길고 구체적인 쿼리를 사용하여 결과가 거의 나오지 않는 경향이 있습니다. 이를 방지하기 위해, 짧고 넓은 쿼리로 시작하여 어떤 정보가 있는지 파악한 뒤 점진적으로 범위를 좁혀가도록 프롬프트를 설계했습니다.
- 사고 과정을 안내하라. 확장 사고 모드(Extended thinking)는 Claude가 가시적인 사고 과정에서 추가 토큰을 출력하게 하는 기능으로, 제어 가능한 메모장 역할을 합니다. 리드 에이전트는 사고 과정에서 접근 방식을 계획하며, 어떤 도구가 작업에 적합한지 평가하고, 쿼리 복잡도와 서브에이전트 수를 결정하고, 각 서브에이전트의 역할을 정의합니다. 테스트 결과, 확장 사고가 지시 이행 능력, 추론 능력, 효율성을 모두 향상시키는 것으로 나타났습니다. 서브에이전트 역시 먼저 계획을 세운 다음, 도구 결과가 반환되면 인터리브드 씽킹을 통해 결과의 품질을 평가하고, 빈틈을 파악하고, 다음 쿼리를 개선합니다. 이를 통해 서브에이전트가 어떤 작업이든 유연하게 대응할 수 있게 됩니다.
- 병렬 도구 호출이 속도와 성능을 혁신적으로 바꾼다. 복잡한 리서치 작업에는 본질적으로 다수의 출처를 탐색해야 합니다. 초기 에이전트는 순차적으로 검색을 수행했는데, 매우 느렸습니다. 속도를 높이기 위해 두 가지 병렬화를 도입했습니다. (1) 리드 에이전트가 서브에이전트 3~5개를 순차가 아닌 병렬로 생성하고, (2) 서브에이전트가 도구 3개 이상을 동시에 사용합니다. 이러한 변경으로 복잡한 쿼리의 리서치 시간이 최대 90%까지 단축되었고, 리서치 기능이 기존에 몇 시간이 걸리던 작업을 몇 분 만에 수행하면서도 다른 시스템보다 더 많은 정보를 처리할 수 있게 되었습니다.
저희의 프롬프팅 전략은 엄격한 규칙이 아닌, 좋은 휴리스틱을 체화시키는 데 중점을 둡니다. 숙련된 사람이 리서치에 접근하는 방식을 연구하고, 이 전략들을 프롬프트에 반영했습니다. 어려운 질문을 작은 작업으로 분해하기, 출처의 품질을 꼼꼼히 평가하기, 새로운 정보에 따라 검색 방식을 조정하기, 깊이(하나의 주제를 상세히 파고들기)와 너비(여러 주제를 병렬로 탐색하기) 중 언제 무엇에 집중할지 판단하기 등의 전략입니다. 또한 에이전트가 통제를 벗어나지 않도록 명시적 가드레일을 사전에 설정하여 의도하지 않은 부작용을 선제적으로 방지했습니다. 마지막으로, 관찰 가능성과 테스트 케이스를 갖춘 빠른 반복 루프에 집중했습니다.
에이전트의 효과적인 평가
좋은 평가 체계는 신뢰할 수 있는 AI 애플리케이션 구축에 필수적이며, 에이전트도 예외가 아닙니다. 다만, 멀티 에이전트 시스템의 평가에는 고유한 난제가 있습니다. 기존 평가는 AI가 매번 동일한 단계를 따른다고 가정하는 경우가 많습니다. 입력 X가 주어지면 경로 Y를 거쳐 출력 Z를 생성해야 한다는 식입니다. 하지만 멀티 에이전트 시스템은 이렇게 작동하지 않습니다. 동일한 출발점에서도 에이전트는 목표에 도달하기 위해 완전히 다른, 그러나 모두 유효한 경로를 택할 수 있습니다. 어떤 에이전트는 3개의 출처를 검색하고, 다른 에이전트는 10개를 검색하거나, 서로 다른 도구를 사용해 같은 답에 도달할 수도 있습니다. 올바른 단계가 무엇인지 항상 알 수 없기 때문에, 사전에 정해둔 "정답 경로"를 따랐는지만 확인하는 것으로는 충분하지 않습니다. 대신, 에이전트가 합리적인 과정을 거쳐 올바른 결과에 도달했는지를 판단하는 유연한 평가 방법이 필요합니다.
소규모 샘플로 즉시 평가를 시작하라. 에이전트 개발 초기에는 쉽게 개선할 수 있는 부분이 많아 변경의 효과가 극적으로 나타나는 경향이 있습니다. 프롬프트 하나를 수정하는 것만으로 성공률이 30%에서 80%로 뛰어오를 수 있습니다. 효과가 이 정도로 크면, 소수의 테스트 케이스만으로도 변화를 충분히 감지할 수 있습니다. 저희는 실제 사용 패턴을 대표하는 약 20개의 쿼리 세트로 시작했습니다. 이 쿼리들을 테스트하는 것만으로도 변경의 영향을 명확하게 파악할 수 있는 경우가 많았습니다. 수백 개의 테스트 케이스를 갖춘 대규모 평가만 의미 있다고 생각하여 평가 구축을 미루는 AI 개발팀을 자주 접합니다. 하지만 철저한 평가를 만들 때까지 기다리기보다, 몇 개의 예시라도 즉시 소규모 테스트를 시작하는 것이 훨씬 낫습니다.
LLM-as-judge 평가는 제대로 설계하면 확장 가능합니다. 리서치 결과물은 자유 형식의 텍스트이고 단 하나의 정답이 존재하는 경우가 드물기 때문에, 프로그래밍 방식으로 평가하기가 어렵습니다. 이런 결과물을 채점하는 데 LLM은 자연스러운 선택지입니다. 저희는 LLM 심사관(judge)을 활용하여 각 결과물을 루브릭 기준에 따라 평가했습니다. 평가 기준은 사실 정확성(주장이 출처와 일치하는가?), 인용 정확성(인용된 출처가 주장과 부합하는가?), 완전성(요청된 모든 측면이 다뤄졌는가?), 출처 품질(품질이 낮은 2차 출처 대신 1차 출처를 사용했는가?), 도구 효율성(적절한 도구를 합리적인 횟수로 사용했는가?)입니다. 각 항목을 여러 심사관으로 평가하는 방식도 실험해 봤지만, 하나의 LLM 호출에 하나의 프롬프트로 0.0~1.0 점수와 합격/불합격 등급을 출력하는 방식이 가장 일관되고 사람의 판단과도 잘 부합했습니다. 이 방법은 평가 테스트 케이스에 명확한 정답이 있는 경우 특히 효과적이었으며, LLM 심사관에게 단순히 답이 맞는지 확인하게 할 수 있었습니다(예: R&D 예산 상위 3위 제약사를 정확히 나열했는가?). LLM을 심사관으로 활용함으로써 수백 건의 결과물을 확장 가능한 방식으로 평가할 수 있었습니다.
사람의 평가는 자동화가 놓치는 부분을 잡아냅니다. 에이전트를 직접 테스트하는 사람은 자동 평가가 놓치는 엣지 케이스를 발견합니다. 여기에는 특이한 질의에 대한 환각(hallucination) 응답, 시스템 장애, 미묘한 출처 선택 편향 등이 포함됩니다. 실제로 저희 인간 테스터들은 초기 에이전트가 학술 PDF나 개인 블로그 같은 권위 있는 출처보다 SEO에 최적화된 저품질 콘텐츠 팜을 일관되게 선택하는 현상을 발견했습니다. 프롬프트에 출처 품질 휴리스틱을 추가하여 이 문제를 해결할 수 있었습니다. 자동 평가 시대에도 수동 테스트는 여전히 필수적입니다.
멀티 에이전트 시스템에는 별도로 프로그래밍하지 않아도 나타나는 창발적 행동(emergent behavior)이 존재합니다. 예를 들어, 리드 에이전트에 사소한 변경을 가하면 서브 에이전트의 동작이 예측할 수 없는 방식으로 달라질 수 있습니다. 성공의 열쇠는 개별 에이전트의 동작이 아니라 에이전트 간 상호작용 패턴을 이해하는 데 있습니다. 따라서 이런 에이전트를 위한 최적의 프롬프트는 단순히 엄격한 지시문이 아니라, 역할 분담·문제 해결 접근법·노력 배분을 정의하는 협업 프레임워크입니다. 이를 제대로 구현하려면 정교한 프롬프트 및 도구 설계, 견고한 휴리스틱, 관측 가능성(observability), 그리고 빠른 피드백 루프가 필요합니다. 저희 시스템에서 사용한 프롬프트 예시는 Cookbook의 오픈소스 프롬프트에서 확인할 수 있습니다.
프로덕션 안정성과 엔지니어링 과제
기존 소프트웨어에서는 버그가 특정 기능을 고장 내거나, 성능을 저하시키거나, 장애를 일으키는 정도입니다. 그러나 에이전트 시스템에서는 사소한 변경이 연쇄적으로 큰 동작 변화를 유발합니다. 이 때문에 장시간 실행되면서 상태를 유지해야 하는 복잡한 에이전트의 코드를 작성하기가 매우 까다롭습니다.
에이전트는 상태를 유지하며, 오류는 누적됩니다. 에이전트는 오랜 시간 동안 실행되면서 다수의 도구 호출에 걸쳐 상태를 유지합니다. 따라서 코드를 안정적으로 실행하고, 중간에 발생하는 오류를 적절히 처리해야 합니다. 효과적인 대응 없이는 사소한 시스템 장애도 에이전트에게 치명적일 수 있습니다. 오류가 발생했을 때 처음부터 다시 시작할 수도 없습니다. 재시작은 비용이 크고 사용자에게 불편을 초래하기 때문입니다. 대신, 오류 발생 시점부터 재개할 수 있는 시스템을 구축했습니다. 모델의 지능을 활용해 문제를 유연하게 처리하는 방법도 씁니다. 예를 들어, 특정 도구에 장애가 발생했음을 에이전트에게 알려 주고 스스로 적응하게 하면 놀랍도록 잘 작동합니다. Claude 기반 AI 에이전트의 적응력과 재시도 로직, 정기적인 체크포인트 같은 결정론적 안전장치를 결합해 활용하고 있습니다.
디버깅에는 새로운 접근법이 필요합니다. 에이전트는 동적으로 의사결정을 내리며, 동일한 프롬프트로 실행해도 결과가 매번 달라지는 비결정적 특성을 지닙니다. 이 때문에 디버깅이 더 어렵습니다. 예를 들어, 사용자들이 "뻔한 정보를 에이전트가 찾지 못한다"고 보고하는데 원인을 파악할 수가 없었습니다. 검색 쿼리가 잘못된 건지, 출처 선택이 부적절한 건지, 도구 장애가 발생한 건지 알 수 없었기 때문입니다. 프로덕션 환경에 전체 트레이싱을 도입하면서 에이전트 실패 원인을 진단하고 체계적으로 문제를 수정할 수 있게 되었습니다. 일반적인 관측 가능성을 넘어, 사용자 프라이버시를 보호하기 위해 개별 대화 내용은 모니터링하지 않으면서도 에이전트의 의사결정 패턴과 상호작용 구조를 추적합니다. 이러한 고수준 관측 가능성 덕분에 근본 원인을 진단하고, 예상치 못한 동작을 발견하며, 빈번한 장애를 수정할 수 있었습니다.
배포에는 세심한 조율이 필요합니다. 에이전트 시스템은 프롬프트, 도구, 실행 로직이 복잡하게 얽혀 있는 상태 기반 시스템으로, 거의 끊임없이 실행됩니다. 따라서 업데이트를 배포할 때 에이전트가 프로세스의 어느 지점에서든 실행 중일 수 있습니다. 선의로 작성한 코드 변경이 기존 실행 중인 에이전트를 망가뜨리지 않도록 해야 합니다. 모든 에이전트를 동시에 새 버전으로 업데이트할 수는 없습니다. 대신 레인보우 배포(rainbow deployment)를 사용하여 기존 버전과 새 버전을 동시에 운영하면서 트래픽을 점진적으로 전환함으로써 실행 중인 에이전트의 중단을 방지합니다.
동기 실행은 병목을 만듭니다. 현재 리드 에이전트는 서브 에이전트를 동기적으로 실행하며, 각 서브 에이전트 그룹이 완료될 때까지 대기한 후 다음 단계로 진행합니다. 이 방식은 조율을 단순화하지만, 에이전트 간 정보 흐름에 병목을 만듭니다. 예를 들어, 리드 에이전트가 서브 에이전트를 중간에 조정할 수 없고, 서브 에이전트끼리 서로 조율할 수 없으며, 하나의 서브 에이전트가 검색을 완료할 때까지 전체 시스템이 차단됩니다. 비동기 실행을 도입하면 추가적인 병렬성을 확보할 수 있습니다. 에이전트가 동시에 작업하고 필요할 때 새로운 서브 에이전트를 생성하는 방식입니다. 하지만 이 비동기성은 서브 에이전트 간 결과 조율, 상태 일관성, 오류 전파 등의 새로운 과제를 수반합니다. 모델이 더 길고 복잡한 리서치 작업을 처리할 수 있게 됨에 따라, 이러한 복잡성을 감수할 만큼 성능 향상이 충분할 것으로 기대하고 있습니다.
결론
AI 에이전트를 구축할 때, 라스트 마일이 전체 여정의 대부분을 차지하는 경우가 많습니다. 개발자 로컬 환경에서 잘 동작하는 코드를 안정적인 프로덕션 시스템으로 만들려면 상당한 엔지니어링이 필요합니다. 에이전트 시스템에서 오류는 복합적으로 작용하기 때문에, 기존 소프트웨어에서는 사소한 문제가 에이전트에서는 전체 흐름을 완전히 이탈시킬 수 있습니다. 하나의 단계가 실패하면 에이전트가 전혀 다른 경로를 탐색하게 되어 예측 불가능한 결과로 이어질 수 있습니다. 이 글에서 설명한 여러 이유로, 프로토타입과 프로덕션 사이의 간극은 예상보다 훨씬 크기 마련입니다.
이러한 과제에도 불구하고, 멀티 에이전트 시스템은 개방형 리서치 작업에서 그 가치를 입증해 왔습니다. 사용자들은 Claude가 미처 생각하지 못했던 비즈니스 기회를 발견하고, 복잡한 의료 옵션을 탐색하며, 까다로운 기술 버그를 해결하고, 혼자서는 찾지 못했을 리서치 연결고리를 발굴해 최대 며칠치 작업을 절약하는 데 도움이 되었다고 이야기합니다. 멀티 에이전트 리서치 시스템은 세심한 엔지니어링, 포괄적인 테스트, 꼼꼼한 프롬프트·도구 설계, 견고한 운영 체계, 그리고 현재 에이전트 역량을 깊이 이해하는 리서치·프로덕트·엔지니어링 팀 간의 긴밀한 협업을 통해 대규모로 안정적으로 운영될 수 있습니다. 이미 이러한 시스템이 사람들의 복잡한 문제 해결 방식을 바꿔 놓고 있습니다.
감사의 말
본 글은 Jeremy Hadfield, Barry Zhang, Kenneth Lien, Florian Scholz, Jeremy Fox, Daniel Ford가 작성했습니다. 이 작업은 리서치 기능을 실현하기 위해 힘쓴 Anthropic 내 여러 팀의 공동 노력의 결과입니다. 이 복잡한 멀티 에이전트 시스템을 프로덕션에 올리기까지 헌신한 Anthropic 앱 엔지니어링 팀에 특별히 감사드리며, 훌륭한 피드백을 보내 주신 얼리 어답터 분들께도 감사를 전합니다.
부록
아래는 멀티 에이전트 시스템에 대한 추가 실용 팁입니다.
여러 턴에 걸쳐 상태를 변경하는 에이전트의 최종 상태 평가. 다중 턴 대화에서 영속적 상태를 변경하는 에이전트를 평가하는 것은 고유한 어려움을 수반합니다. 읽기 전용 리서치 작업과 달리, 각 행동이 후속 단계의 환경을 바꾸기 때문에 기존 평가 방법으로는 다루기 어려운 의존성이 생깁니다. 저희는 턴별 분석보다 최종 상태 평가에 집중하는 것이 효과적이었습니다. 에이전트가 특정 프로세스를 따랐는지 판단하는 대신, 올바른 최종 상태에 도달했는지를 평가하는 방식입니다. 이 접근법은 에이전트가 같은 목표에 도달하는 다양한 경로를 허용하면서도 의도한 결과가 달성되었는지를 확인할 수 있습니다. 복잡한 워크플로의 경우, 모든 중간 단계를 검증하려 하기보다는 특정 상태 변경이 발생했어야 하는 이산적인 체크포인트 단위로 평가를 분할하는 것이 좋습니다.
장기 대화 관리. 프로덕션 에이전트는 수백 턴에 걸친 대화를 수행하는 경우가 많아, 세심한 컨텍스트 관리 전략이 필요합니다. 대화가 길어질수록 표준 컨텍스트 윈도우만으로는 부족해지며, 지능적인 압축 및 메모리 메커니즘이 요구됩니다. 저희는 에이전트가 완료된 작업 단계를 요약하고 핵심 정보를 외부 메모리에 저장한 후 새로운 작업으로 넘어가는 패턴을 구현했습니다. 컨텍스트 한도에 가까워지면 에이전트가 클린 컨텍스트를 가진 새로운 서브 에이전트를 생성하고, 신중한 핸드오프를 통해 연속성을 유지합니다. 더불어, 컨텍스트 한도에 도달하더라도 이전 작업을 잃지 않도록 리서치 계획 등 저장된 컨텍스트를 메모리에서 가져올 수 있습니다. 이 분산 접근법은 장기 상호작용에서 대화의 일관성을 유지하면서도 컨텍스트 오버플로를 방지합니다.
'전화 게임' 효과를 최소화하기 위한 서브 에이전트의 파일시스템 출력. 특정 유형의 결과물에 대해 서브 에이전트 출력을 메인 코디네이터를 거치지 않고 직접 전달하면, 정확도와 성능 모두 향상됩니다. 서브 에이전트가 모든 것을 리드 에이전트를 통해 전달하도록 하는 대신, 전문화된 에이전트가 독립적으로 유지되는 아티팩트를 생성할 수 있는 시스템을 구현하는 것이 좋습니다. 서브 에이전트는 도구를 호출해 작업 결과를 외부 시스템에 저장한 후, 가벼운 참조만 코디네이터에 전달합니다. 이렇게 하면 다단계 처리 과정에서 정보 손실을 방지하고, 대화 히스토리에 대용량 출력을 복사하는 데 드는 토큰 오버헤드도 줄일 수 있습니다. 이 패턴은 코드, 보고서, 데이터 시각화 등 구조화된 출력물에 특히 효과적인데, 전문화된 프롬프트를 가진 서브 에이전트가 범용 코디네이터를 거치는 것보다 더 나은 결과를 만들어 내기 때문입니다.
