멀티 에이전트 리서치 시스템 구축기

발행일: 2025년 6월 13일

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

이제 Claude는 웹, Google Workspace, 그리고 각종 연동 서비스를 두루 검색해 복잡한 작업을 수행하는 Research 기능을 갖추고 있습니다.

이 멀티 에이전트 시스템이 프로토타입에서 프로덕션에 이르기까지 거쳐 온 과정은 시스템 아키텍처, 도구 설계, 프롬프트 엔지니어링에 관한 중요한 교훈을 안겨 주었습니다. 멀티 에이전트 시스템이란 여러 에이전트(루프 안에서 자율적으로 도구를 사용하는 LLM)가 함께 협력하는 시스템을 말합니다. 저희 Research 기능에서는 한 에이전트가 사용자 질의를 바탕으로 리서치 과정을 계획하고, 도구를 사용해 병렬 에이전트들을 생성해 동시에 정보를 검색합니다. 에이전트가 여러 개 있는 시스템에서는 에이전트 간 조율, 평가, 신뢰성이라는 새로운 과제가 등장합니다.

이 글에서는 저희에게 효과가 있었던 원칙들을 정리했습니다. 여러분이 직접 멀티 에이전트 시스템을 구축할 때 유용하게 적용하실 수 있기를 바랍니다.

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

리서치 작업은 필요한 단계를 미리 예측하기가 매우 어려운, 열린 문제를 다룹니다. 복잡한 주제를 탐구하는 경로를 고정된 형태로 하드코딩할 수는 없습니다. 그 과정은 본질적으로 동적이며 경로 의존적이기 때문입니다. 사람이 리서치를 할 때도 발견한 내용에 따라 접근 방식을 끊임없이 갱신하고, 조사 과정에서 떠오른 단서를 따라가는 경향이 있습니다.

이러한 예측 불가능성 때문에 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 에이전트는 아직 실시간으로 다른 에이전트와 조율하고 작업을 위임하는 데 능숙하지 않습니다. 저희가 확인한 바로는 멀티 에이전트 시스템은 병렬화 비중이 큰 작업, 단일 컨텍스트 윈도를 넘어서는 정보를 다루는 작업, 그리고 수많은 복잡한 도구를 다뤄야 하는 가치 높은 작업에서 빛을 발합니다.

Research 아키텍처 개요

저희 Research 시스템은 오케스트레이터-워커(orchestrator-worker) 패턴을 적용한 멀티 에이전트 아키텍처를 사용합니다. 리드 에이전트가 전체 과정을 조율하면서, 병렬로 작동하는 전문화된 서브에이전트에게 작업을 위임하는 구조입니다.

작동 중인 멀티 에이전트 아키텍처에서는 사용자 질의가 리드 에이전트를 거치고, 리드 에이전트는 서로 다른 측면을 병렬로 검색할 전문 서브에이전트들을 생성합니다.

사용자가 질의를 제출하면 리드 에이전트는 이를 분석하고 전략을 세운 뒤, 서로 다른 측면을 동시에 탐색할 서브에이전트들을 생성합니다. 위 다이어그램에서 보듯 서브에이전트는 검색 도구를 반복적으로 사용해 정보를 모으는 지능형 필터 역할을 합니다. 이 사례에서 서브에이전트는 2025년 AI 에이전트 기업에 관한 정보를 모으고, 그 기업 목록을 리드 에이전트에게 돌려주어 리드 에이전트가 최종 답변을 정리하도록 합니다.

검색 증강 생성(RAG)을 활용하는 전통적인 접근 방식은 정적 검색에 의존합니다. 즉, 입력 질의와 가장 유사한 청크 묶음을 가져와 이를 바탕으로 응답을 생성합니다. 반면 저희 아키텍처는 다단계 검색으로 관련 정보를 동적으로 찾아내고, 새로운 발견에 맞춰 적응하며, 결과를 분석해 고품질 답변을 만들어 냅니다.

저희 멀티 에이전트 Research 시스템의 전체 워크플로를 보여 주는 프로세스 다이어그램은 다음과 같이 진행됩니다. 사용자가 질의를 제출하면 시스템은 LeadResearcher 에이전트를 생성하고, 이 에이전트가 반복적인 리서치 과정에 들어갑니다. LeadResearcher는 먼저 접근 방식을 숙고한 뒤, 컨텍스트를 보존하기 위해 자신의 계획을 Memory에 저장합니다. 컨텍스트 윈도가 200,000 토큰을 넘어서면 내용이 잘려 나가므로, 계획을 잃지 않고 유지하는 것이 중요하기 때문입니다. 그런 다음 구체적인 리서치 작업을 부여한 전문 Subagent들을 생성합니다(여기서는 두 개를 표시했지만 개수는 얼마든지 가능합니다). 각 Subagent는 독립적으로 웹 검색을 수행하고, interleaved thinking을 통해 도구 결과를 평가한 뒤, 발견한 내용을 LeadResearcher에게 돌려줍니다. LeadResearcher는 이 결과들을 종합하고 추가 리서치가 필요한지 판단합니다. 필요하다면 서브에이전트를 더 생성하거나 전략을 다듬을 수 있습니다. 충분한 정보가 모이면 시스템은 리서치 루프를 빠져나와 모든 발견 내용을 CitationAgent에게 넘깁니다. CitationAgent는 문서와 리서치 보고서를 처리해 인용을 달아야 할 구체적인 위치를 찾아냅니다. 이를 통해 모든 주장이 출처에 제대로 귀속되도록 보장합니다. 마지막으로 인용까지 완비된 최종 리서치 결과가 사용자에게 전달됩니다.

리서치 에이전트를 위한 프롬프트 엔지니어링과 평가

멀티 에이전트 시스템은 단일 에이전트 시스템과 근본적으로 다른 점이 있는데, 그중 하나가 조율 복잡도의 급격한 증가입니다. 초기 에이전트들은 단순한 질의에 서브에이전트 50개를 생성하거나, 존재하지도 않는 출처를 끝없이 웹에서 뒤지거나, 과도한 업데이트로 서로의 주의를 흐트러뜨리는 식의 오류를 범했습니다. 각 에이전트는 프롬프트로 조종되기 때문에, 이러한 행동을 개선하는 핵심 지렛대는 프롬프트 엔지니어링이었습니다. 아래는 에이전트 프롬프팅에 관해 저희가 배운 원칙들입니다.

에이전트처럼 생각하라. 프롬프트를 반복 개선하려면 그 효과를 이해해야 합니다. 이를 위해 저희는 실제 시스템과 똑같은 프롬프트와 도구를 사용해 Console에서 시뮬레이션을 구축하고, 에이전트가 한 단계씩 작동하는 모습을 지켜봤습니다. 그러자 곧바로 실패 양상이 드러났습니다. 이미 충분한 결과를 얻고도 작업을 계속하거나, 지나치게 장황한 검색 질의를 쓰거나, 잘못된 도구를 고르는 식이었죠. 효과적인 프롬프팅은 에이전트에 대한 정확한 멘탈 모델을 갖추는 데서 출발하며, 그 모델이 갖춰지면 가장 큰 영향을 미칠 변경 사항이 무엇인지 분명해집니다.
오케스트레이터에게 위임하는 법을 가르쳐라. 저희 시스템에서 리드 에이전트는 질의를 하위 작업으로 분해해 서브에이전트에게 설명합니다. 각 서브에이전트에는 목표, 출력 형식, 사용할 도구와 출처에 대한 안내, 그리고 명확한 작업 경계가 필요합니다. 작업 설명이 충분히 구체적이지 않으면 에이전트들은 작업을 중복 수행하거나, 빈틈을 남기거나, 필요한 정보를 찾지 못합니다. 처음에는 리드 에이전트가 "반도체 부족 사태를 조사하라" 같은 짧고 단순한 지시를 내리도록 허용했는데, 이런 지시는 너무 모호해서 서브에이전트가 작업을 잘못 해석하거나 다른 에이전트와 똑같은 검색을 반복하는 경우가 잦았습니다. 한 예로, 한 서브에이전트는 2021년 자동차 칩 위기를 탐색하는 동안 다른 두 에이전트가 효과적인 분업 없이 2025년 현재의 공급망을 조사하며 작업을 중복했습니다.
질의 복잡도에 맞춰 노력을 조절하라. 에이전트는 작업마다 적절한 노력 수준을 판단하기 어려워하므로, 저희는 프롬프트에 규모 조절 규칙을 심어 두었습니다. 단순한 사실 확인에는 도구 호출 3~~10회의 에이전트 1개면 충분하고, 직접 비교에는 각각 10~~15회를 호출하는 서브에이전트 2~4개가 필요할 수 있으며, 복잡한 리서치에는 책임이 명확히 나뉜 서브에이전트 10개 이상을 쓸 수도 있습니다. 이런 명시적 지침은 리드 에이전트가 자원을 효율적으로 배분하도록 돕고, 초기 버전에서 흔히 나타난 실패 양상이었던 단순 질의에 대한 과잉 투자를 막아 줍니다.
도구 설계와 선택이 결정적이다. 에이전트-도구 인터페이스는 인간-컴퓨터 인터페이스만큼이나 중요합니다. 올바른 도구를 쓰면 효율적이며, 때로는 반드시 그래야만 합니다. 예를 들어 Slack에만 존재하는 맥락을 웹에서 검색하는 에이전트는 시작부터 실패가 예정되어 있습니다. 모델에 외부 도구 접근 권한을 부여하는 MCP 서버까지 더해지면 이 문제는 한층 복잡해집니다. 에이전트가 설명의 품질이 천차만별이고 처음 보는 도구들과 마주하기 때문입니다. 그래서 저희는 에이전트에게 명시적인 휴리스틱을 제공했습니다. 예컨대 우선 사용 가능한 모든 도구를 살펴볼 것, 도구 사용을 사용자 의도에 맞출 것, 폭넓은 외부 탐색에는 웹을 검색할 것, 범용 도구보다 전문 도구를 우선할 것 등입니다. 나쁜 도구 설명은 에이전트를 완전히 엉뚱한 길로 보낼 수 있으므로, 각 도구에는 뚜렷한 목적과 명확한 설명이 있어야 합니다.
에이전트가 스스로 개선하게 하라. 저희는 Claude 4 모델이 훌륭한 프롬프트 엔지니어가 될 수 있다는 점을 발견했습니다. 프롬프트와 실패 양상을 함께 주면, 에이전트가 왜 실패하는지 진단하고 개선안을 제안할 수 있습니다. 저희는 도구 테스트 에이전트까지 만들었습니다. 결함이 있는 MCP 도구를 주면 이 에이전트가 직접 도구를 사용해 본 뒤, 실패를 피하도록 도구 설명을 다시 작성합니다. 이 에이전트는 도구를 수십 번 테스트하며 핵심적인 미묘함과 버그를 찾아냈습니다. 이렇게 도구 사용성을 개선한 결과, 새 설명을 사용하는 이후 에이전트들의 작업 완료 시간이 40% 줄었습니다. 대부분의 실수를 미리 피할 수 있게 되었기 때문입니다.
넓게 시작해서 좁혀 가라. 검색 전략은 숙련된 사람의 리서치 방식을 본떠야 합니다. 즉, 세부로 파고들기 전에 먼저 전체 지형을 살피는 것이죠. 에이전트는 지나치게 길고 구체적인 질의를 기본값으로 삼는 경향이 있는데, 이런 질의는 결과를 거의 반환하지 못합니다. 저희는 에이전트가 짧고 폭넓은 질의로 시작해 어떤 자료가 있는지 평가한 뒤 점차 초점을 좁히도록 프롬프트로 유도해 이 경향을 바로잡았습니다.
사고 과정을 안내하라. Claude가 눈에 보이는 사고 과정으로 추가 토큰을 출력하게 하는 확장 사고(extended thinking) 모드는 통제 가능한 메모장처럼 활용할 수 있습니다. 리드 에이전트는 사고를 통해 접근 방식을 계획하고, 어떤 도구가 작업에 맞는지 평가하며, 질의 복잡도와 서브에이전트 수를 정하고, 각 서브에이전트의 역할을 규정합니다. 저희 테스트에서 확장 사고는 지시 따르기, 추론, 효율을 모두 향상시켰습니다. 서브에이전트도 먼저 계획을 세운 뒤, 도구 결과가 나온 후 interleaved thinking을 사용해 품질을 평가하고 빈틈을 찾아 다음 질의를 다듬습니다. 이를 통해 서브에이전트는 어떤 작업에도 더 잘 적응하게 됩니다.
병렬 도구 호출은 속도와 성능을 완전히 바꾼다. 복잡한 리서치 작업은 본질적으로 수많은 출처를 탐색하게 됩니다. 초기 에이전트들은 검색을 순차적으로 실행했는데, 견디기 힘들 만큼 느렸습니다. 속도를 위해 저희는 두 가지 병렬화를 도입했습니다. (1) 리드 에이전트가 서브에이전트를 순차적으로가 아니라 한 번에 3~5개씩 병렬로 띄우고, (2) 각 서브에이전트가 도구를 3개 이상 병렬로 사용하는 것입니다. 이 변화로 복잡한 질의의 리서치 시간이 최대 90%까지 단축되어, Research가 다른 시스템보다 더 많은 정보를 다루면서도 몇 시간이 아니라 몇 분 만에 더 많은 일을 해낼 수 있게 되었습니다.

저희 프롬프팅 전략은 경직된 규칙을 부과하기보다 좋은 휴리스틱을 심는 데 초점을 둡니다. 숙련된 사람이 리서치 작업에 어떻게 접근하는지 연구하고, 그 전략을 프롬프트에 담았습니다. 어려운 질문을 더 작은 작업으로 분해하기, 출처의 품질을 신중히 평가하기, 새 정보에 맞춰 검색 방식을 조정하기, 그리고 언제 깊이(한 주제를 상세히 파고들기)에 집중하고 언제 폭(여러 주제를 병렬로 탐색하기)에 집중할지 분별하기 같은 전략들입니다. 또한 에이전트가 통제 불능으로 치닫지 않도록 명시적인 가드레일을 두어 의도치 않은 부작용을 선제적으로 완화했습니다. 끝으로, 관측 가능성과 테스트 케이스를 갖춘 빠른 반복 루프에 집중했습니다.

효과적인 에이전트 평가

신뢰할 수 있는 AI 애플리케이션을 구축하려면 좋은 평가가 필수이며, 에이전트도 예외가 아닙니다. 다만 멀티 에이전트 시스템을 평가하는 데는 고유한 어려움이 있습니다. 전통적인 평가는 AI가 매번 같은 단계를 밟는다고 가정합니다. 즉, 입력 X가 주어지면 시스템이 경로 Y를 따라 출력 Z를 내야 한다는 식입니다. 하지만 멀티 에이전트 시스템은 그렇게 작동하지 않습니다. 출발점이 동일하더라도 에이전트들은 목표에 이르기까지 완전히 다른, 그러나 모두 타당한 경로를 택할 수 있습니다. 한 에이전트는 세 개의 출처를 검색하고 다른 에이전트는 열 개를 검색할 수도 있고, 같은 답을 찾는 데 서로 다른 도구를 쓸 수도 있습니다. 무엇이 올바른 단계인지 늘 알 수는 없으므로, 미리 정해 둔 "올바른" 단계를 에이전트가 따랐는지만 확인할 수는 없습니다. 대신 에이전트가 합리적인 과정을 거치면서도 올바른 결과를 달성했는지를 판단하는 유연한 평가 방법이 필요합니다.

작은 표본으로 즉시 평가를 시작하라. 에이전트 개발 초기에는 손쉽게 따낼 성과가 풍부하기 때문에, 변경이 극적인 영향을 미치는 경향이 있습니다. 프롬프트를 살짝 손보는 것만으로 성공률이 30%에서 80%로 뛰어오를 수 있습니다. 효과 크기가 이 정도면 테스트 케이스 몇 개만으로도 변화를 포착할 수 있습니다. 저희는 실제 사용 패턴을 대표하는 질의 약 20개로 시작했습니다. 이 질의들로 테스트하면 변경의 영향이 또렷하게 보이는 경우가 많았습니다. AI 개발팀이 수백 개의 테스트 케이스를 갖춘 대규모 평가만 쓸모 있다고 여겨 평가 작성을 미룬다는 이야기를 자주 듣습니다. 하지만 더 철저한 평가를 갖출 때까지 미루기보다, 몇 가지 예시로 곧장 소규모 테스트를 시작하는 편이 가장 좋습니다.

LLM 심판(LLM-as-judge) 평가는 잘 설계하면 확장된다. 리서치 결과물은 자유 형식의 텍스트이고 정답이 하나로 정해진 경우가 드물어 프로그램으로 평가하기 어렵습니다. 이런 결과물을 채점하는 데는 LLM이 자연스럽게 잘 맞습니다. 저희는 각 결과물을 루브릭의 기준에 따라 평가하는 LLM 심판을 사용했습니다. 기준은 사실 정확성(주장이 출처와 일치하는가?), 인용 정확성(인용된 출처가 주장과 일치하는가?), 완전성(요청된 모든 측면이 다뤄졌는가?), 출처 품질(저품질 2차 출처보다 1차 출처를 사용했는가?), 그리고 도구 효율성(적절한 도구를 적당한 횟수만큼 사용했는가?)입니다. 구성 요소별로 여러 심판을 두는 방식도 실험해 봤지만, 0.0~1.0 점수와 합격/불합격 등급을 출력하는 단일 프롬프트의 단일 LLM 호출이 가장 일관적이고 사람의 판단과도 가장 잘 부합했습니다. 이 방법은 평가 테스트 케이스에 명확한 답이 있을 때, 즉 LLM 심판으로 답이 맞는지만 확인하면 되는 경우(예: R&D 예산 상위 3개 제약사를 정확히 나열했는가?)에 특히 효과적이었습니다. LLM을 심판으로 활용한 덕분에 수백 개의 결과물을 확장성 있게 평가할 수 있었습니다.

사람의 평가는 자동화가 놓치는 것을 잡아낸다. 에이전트를 테스트하는 사람은 평가가 놓치는 엣지 케이스를 찾아냅니다. 비정상적인 질의에서의 환각 답변, 시스템 장애, 또는 미묘한 출처 선택 편향 같은 것들이죠. 저희의 경우, 초기 에이전트가 학술 PDF나 개인 블로그처럼 권위 있지만 검색 순위는 낮은 출처 대신, SEO에 최적화된 콘텐츠 팜을 일관되게 선택한다는 점을 사람 테스터들이 발견했습니다. 프롬프트에 출처 품질 휴리스틱을 추가하자 이 문제가 해결되었습니다. 자동화된 평가의 시대에도 수동 테스트는 여전히 필수입니다.

멀티 에이전트 시스템에는 특정하게 프로그래밍하지 않아도 나타나는 창발적(emergent) 행동이 있습니다. 예를 들어 리드 에이전트를 조금만 바꿔도 서브에이전트의 행동이 예측 불가능하게 달라질 수 있습니다. 성공하려면 개별 에이전트의 행동만이 아니라 상호작용 패턴을 이해해야 합니다. 그러므로 이런 에이전트를 위한 최선의 프롬프트는 엄격한 지시문이 아니라, 분업·문제 해결 방식·노력 예산을 규정하는 협업의 틀입니다. 이를 제대로 갖추려면 세심한 프롬프트와 도구 설계, 탄탄한 휴리스틱, 관측 가능성, 그리고 긴밀한 피드백 루프가 필요합니다. 저희 시스템의 예시 프롬프트는 Cookbook에 공개된 오픈소스 프롬프트에서 확인하실 수 있습니다.

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

전통적인 소프트웨어에서는 버그 하나가 기능을 망가뜨리거나, 성능을 떨어뜨리거나, 장애를 일으킬 수 있습니다. 에이전트형 시스템에서는 사소한 변경이 큰 행동 변화로 연쇄되므로, 오래 실행되는 프로세스에서 상태를 유지해야 하는 복잡한 에이전트의 코드를 작성하기가 유난히 어렵습니다.

에이전트는 상태를 가지며 오류가 누적된다. 에이전트는 오랫동안 실행되면서 수많은 도구 호출에 걸쳐 상태를 유지할 수 있습니다. 따라서 코드를 견고하게 실행하고 그 과정에서 오류를 처리해야 합니다. 효과적인 완화책이 없으면 사소한 시스템 장애가 에이전트에게는 치명적일 수 있습니다. 오류가 발생했을 때 처음부터 다시 시작할 수는 없습니다. 재시작은 비용이 크고 사용자에게도 답답한 일이기 때문입니다. 그래서 저희는 오류가 발생한 지점에서 에이전트를 이어서 재개할 수 있는 시스템을 구축했습니다. 또한 문제를 매끄럽게 처리하는 데 모델의 지능을 활용합니다. 예를 들어 도구가 실패하고 있음을 에이전트에게 알리고 스스로 적응하게 하는 방식이 의외로 잘 작동합니다. 저희는 Claude 기반 AI 에이전트의 적응력을, 재시도 로직과 정기적인 체크포인트 같은 결정론적 안전장치와 결합합니다.

디버깅에는 새로운 접근이 필요하다. 에이전트는 동적으로 결정을 내리며, 프롬프트가 동일해도 실행마다 비결정론적입니다. 이 때문에 디버깅이 더 어려워집니다. 예를 들어 사용자들이 에이전트가 "뻔한 정보를 못 찾는다"고 신고해도, 저희는 그 이유를 알 수 없었습니다. 에이전트가 나쁜 검색 질의를 썼던 걸까요? 출처를 잘못 골랐던 걸까요? 도구 실패에 부딪혔던 걸까요? 프로덕션 전체에 트레이싱을 추가하자 에이전트가 실패한 이유를 진단하고 문제를 체계적으로 고칠 수 있게 되었습니다. 표준적인 관측 가능성을 넘어, 저희는 사용자 프라이버시를 지키기 위해 개별 대화의 내용은 들여다보지 않으면서도 에이전트의 의사결정 패턴과 상호작용 구조를 모니터링합니다. 이런 상위 수준의 관측 가능성 덕분에 근본 원인을 진단하고, 예상치 못한 행동을 발견하고, 흔한 실패를 바로잡을 수 있었습니다.

배포에는 세심한 조율이 필요하다. 에이전트 시스템은 거의 끊임없이 실행되는, 프롬프트·도구·실행 로직이 촘촘히 얽힌 상태 집약적 그물망입니다. 따라서 업데이트를 배포하는 순간 에이전트들은 저마다 프로세스의 서로 다른 지점에 가 있을 수 있습니다. 그래서 저희는 선의로 적용한 코드 변경이 이미 실행 중인 에이전트를 망가뜨리지 않도록 막아야 합니다. 모든 에이전트를 동시에 새 버전으로 업데이트할 수는 없습니다. 대신 레인보우 배포(rainbow deployment)를 사용해, 이전 버전과 새 버전을 함께 돌리면서 트래픽을 점진적으로 옮겨 실행 중인 에이전트를 방해하지 않습니다.

동기 실행은 병목을 만든다. 현재 저희 리드 에이전트는 서브에이전트를 동기적으로 실행해, 각 서브에이전트 묶음이 완료될 때까지 기다린 후에야 다음으로 넘어갑니다. 이는 조율을 단순하게 해 주지만, 에이전트 간 정보 흐름에 병목을 만듭니다. 예를 들어 리드 에이전트가 서브에이전트를 도중에 조종할 수 없고, 서브에이전트끼리 조율할 수 없으며, 단 하나의 서브에이전트가 검색을 끝내기를 기다리는 동안 시스템 전체가 막힐 수 있습니다. 비동기 실행이라면 추가적인 병렬성이 가능해집니다. 에이전트들이 동시에 작업하고 필요할 때 새 서브에이전트를 만드는 식이죠. 다만 이런 비동기성은 결과 조율, 상태 일관성, 서브에이전트 전반의 오류 전파 측면에서 새로운 과제를 더합니다. 모델이 더 길고 복잡한 리서치 작업을 감당하게 됨에 따라, 그 성능 향상이 이러한 복잡성을 정당화하리라 기대합니다.

맺음말

AI 에이전트를 구축할 때, 마지막 한 걸음(last mile)이 여정의 대부분을 차지하는 경우가 많습니다. 개발자 컴퓨터에서는 잘 돌아가는 코드베이스도, 신뢰할 수 있는 프로덕션 시스템이 되려면 상당한 엔지니어링이 필요합니다. 에이전트형 시스템에서는 오류가 복합적으로 작용하므로, 전통적인 소프트웨어에서는 사소했을 문제가 에이전트를 완전히 탈선시킬 수 있습니다. 한 단계의 실패가 에이전트를 전혀 다른 경로로 이끌어 예측 불가능한 결과로 이어질 수 있습니다. 이 글에서 설명한 모든 이유로, 프로토타입과 프로덕션 사이의 간극은 흔히 예상보다 훨씬 넓습니다.

이런 어려움에도 멀티 에이전트 시스템은 열린 리서치 작업에서 가치를 입증해 왔습니다. 사용자들은 Claude 덕분에 미처 생각하지 못한 사업 기회를 발견하고, 복잡한 의료 선택지를 헤쳐 나가고, 까다로운 기술 버그를 해결하고, 혼자서는 결코 찾지 못했을 연구 간 연결고리를 밝혀내 며칠 분의 작업을 아꼈다고 말합니다. 멀티 에이전트 리서치 시스템은 세심한 엔지니어링, 포괄적인 테스트, 디테일에 충실한 프롬프트와 도구 설계, 견고한 운영 관행, 그리고 현재 에이전트 역량을 깊이 이해하는 리서치·제품·엔지니어링 팀 간의 긴밀한 협업이 갖춰질 때 대규모로 안정적으로 작동할 수 있습니다. 저희는 이미 이런 시스템이 사람들이 복잡한 문제를 푸는 방식을 바꿔 놓는 모습을 보고 있습니다.

오늘날 사람들이 Research 기능을 가장 흔히 사용하는 방식을 보여 주는 Clio 임베딩 플롯에서, 상위 사용 사례 범주는 특화된 분야에 걸친 소프트웨어 시스템 개발(10%), 전문적·기술적 콘텐츠의 개발과 최적화(8%), 사업 성장과 매출 창출 전략 개발(8%), 학술 연구와 교육 자료 개발 지원(7%), 그리고 사람·장소·조직에 관한 정보 조사 및 검증(5%)입니다.

감사의 말

이 글은 Jeremy Hadfield, Barry Zhang, Kenneth Lien, Florian Scholz, Jeremy Fox, Daniel Ford가 작성했습니다. 이 작업은 Research 기능을 가능하게 한 Anthropic 여러 팀의 공동 노력의 결과입니다. 이 복잡한 멀티 에이전트 시스템을 프로덕션까지 끌어올린 Anthropic apps 엔지니어링 팀의 헌신에 특별히 감사드립니다. 또한 훌륭한 피드백을 준 초기 사용자 여러분께도 감사드립니다.

부록

아래는 멀티 에이전트 시스템을 위한 몇 가지 추가적인 자잘한 팁입니다.

여러 턴에 걸쳐 상태를 변경하는 에이전트의 최종 상태(end-state) 평가. 여러 턴의 대화에 걸쳐 지속되는 상태를 수정하는 에이전트를 평가하는 데는 고유한 어려움이 있습니다. 읽기 전용 리서치 작업과 달리, 각 행동이 이후 단계의 환경을 바꿔 놓아 전통적인 평가 방법으로는 다루기 힘든 의존 관계를 만들기 때문입니다. 저희는 턴별 분석이 아니라 최종 상태 평가에 집중해 성과를 거두었습니다. 에이전트가 특정 과정을 따랐는지 판단하는 대신, 올바른 최종 상태에 도달했는지를 평가하는 것입니다. 이 접근은 에이전트가 같은 목표에 이르는 다른 경로를 찾을 수 있음을 인정하면서도, 의도한 결과를 확실히 내놓도록 보장합니다. 복잡한 워크플로의 경우, 중간 단계를 일일이 검증하려 들기보다 특정 상태 변화가 일어났어야 할 개별 체크포인트로 평가를 나눕니다.

장기 호흡(long-horizon) 대화 관리. 프로덕션 에이전트는 수백 턴에 걸친 대화에 참여하는 경우가 많아, 세심한 컨텍스트 관리 전략이 필요합니다. 대화가 길어지면 표준 컨텍스트 윈도로는 부족해지므로 지능적인 압축과 메모리 메커니즘이 요구됩니다. 저희는 에이전트가 완료된 작업 단계를 요약하고 핵심 정보를 외부 메모리에 저장한 뒤 새 작업으로 넘어가는 패턴을 구현했습니다. 컨텍스트 한계에 다가가면 에이전트는 깨끗한 컨텍스트를 가진 새 서브에이전트를 생성하되, 세심한 인계를 통해 연속성을 유지할 수 있습니다. 또한 컨텍스트 한계에 도달했을 때 이전 작업을 잃는 대신, 리서치 계획 같은 저장된 컨텍스트를 메모리에서 다시 가져올 수 있습니다. 이러한 분산 방식은 컨텍스트 오버플로를 막으면서도 긴 상호작용 전반에 걸쳐 대화의 일관성을 지켜 줍니다.

'전화 게임(game of telephone)'을 최소화하기 위한 서브에이전트의 파일시스템 출력. 특정 유형의 결과에 대해서는 서브에이전트의 출력이 메인 조율자를 거치지 않고 직접 전달되게 하면, 충실도와 성능을 모두 높일 수 있습니다. 서브에이전트가 모든 것을 리드 에이전트를 통해 전달하도록 요구하는 대신, 전문 에이전트가 독립적으로 지속되는 결과물을 만들 수 있는 아티팩트 시스템을 구현하는 것입니다. 서브에이전트는 도구를 호출해 자신의 작업물을 외부 시스템에 저장한 뒤, 가벼운 참조만 조율자에게 돌려줍니다. 이렇게 하면 다단계 처리 과정에서의 정보 손실을 막고, 대화 기록을 통해 큰 출력물을 복사하면서 생기는 토큰 부담을 줄일 수 있습니다. 이 패턴은 코드, 보고서, 데이터 시각화처럼 구조화된 출력물에 특히 잘 맞는데, 이런 경우 서브에이전트의 전문화된 프롬프트가 범용 조율자를 거쳐 걸러진 것보다 더 나은 결과를 내놓기 때문입니다.