Anthropic이 리서치 기능에 도입한 멀티 에이전트 시스템의 설계 원칙, 프롬프트 엔지니어링, 아키텍처, 그리고 신뢰성 확보 및 운영 팁에 대한 엔지니어링 경험 공유.
Claude는 이제 리서치 기능으로 웹, 구글 워크스페이스, 그리고 다양한 통합 기능을 활용해 복잡한 작업을 완수할 수 있습니다.
이 멀티 에이전트 시스템이 프로토타입에서 실제 프로덕션 시스템으로 발전하는 여정은 시스템 아키텍처, 툴 설계, 프롬프트 엔지니어링에 관한 중요한 교훈을 남겼습니다. 멀티 에이전트 시스템이란 여러 에이전트(LLM이 자율적으로 반복적으로 툴을 사용하는 구조)들이 협력하여 작동하는 시스템입니다. Claude의 리서치 기능은 사용자의 질의에 기반해 리서치 계획을 세우는 주도 에이전트가 여러 하위 에이전트를 병렬로 생성해 동시에 정보를 탐색하도록 하는 구조를 취합니다. 이러한 시스템은 에이전트 간 조정, 평가, 신뢰성 관련 새로운 난관을 가져옵니다.
이 글에서는 우리가 사용했던 핵심 원칙들을 풀어서 설명합니다. 멀티 에이전트 시스템을 구축할 때 참고가 되길 바랍니다.
리서치 작업은 사전에 필요한 단계를 예측하기 어려운 열린 문제를 담고 있습니다. 복잡한 주제를 살펴보는 경로는 본질적으로 역동적이고 상황에 따라 달라지므로, 고정된 순서를 하드코딩하기 어렵습니다. 사람이 리서치를 할 때도 조사 중 발견되는 실마리를 따라 계속해서 접근법을 수정해 나갑니다.
이런 예측 불가능성 때문에 AI 에이전트가 리서치에 특히 적합합니다. 리서치는 새로운 정보가 나올 때마다 방향을 전환하거나 연관성을 탐색하는 유연성이 필요합니다. 모델은 여러 턴에 걸쳐 자율적으로 작동하며, 중간 결과에 따라 탐구 방향을 결정해야 합니다. 단순하고 일회성인 파이프라인 구조만으로는 이런 작업을 소화할 수 없습니다.
검색의 본질은 압축입니다. 방대한 자료에서 통찰을 추려내는 일이죠. 서브에이전트(하위 에이전트)는 각자의 컨텍스트 창에서 병렬로 질문의 다양한 측면을 살피고, 이렇게 발견한 중요한 토큰을 주도 에이전트에게 모아 핵심 정보만 압축해 전달합니다. 각 서브에이전트는 툴, 프롬프트, 탐구 경로가 분리되어 있어 작업 간섭이 줄고, 독립적·철저한 조사가 가능합니다.
지능이 임계값에 도달하면 멀티 에이전트 시스템은 성능 확장의 핵심 수단이 됩니다. 인간도 10만 년 동안 개인적 지능은 점진적으로 증가했지만, 정보화 시대에 사회적/집단적 지능과 협력 능력 덕분에 _기하급수적_으로 집합적 역량이 확대되었습니다. 단일 AI 에이전트만으론 한계가 있지만, 다수의 에이전트가 모이면 훨씬 많은 일을 해낼 수 있습니다.
내부 평가에 따르면, 멀티 에이전트 리서치 시스템은 여러 독립적 방향을 동시에 추구하는 폭넓은(breadth-first) 쿼리에서 특히 뛰어났습니다. Claude Opus 4를 리드 에이전트로, Claude Sonnet 4를 하위 에이전트로 둔 멀티 시스템이 단일 에이전트 Claude Opus 4보다 내부 리서치 평가에서 90.2% 더 높은 성능을 보였습니다. 예를 들어, IT S&P 500 기업 이사진을 모두 찾아내는 문제에서 멀티 에이전트는 하위 에이전트에게 세부 과제를 쪼개어 정답을 찾은 반면, 단일 에이전트 구조는 느리고 순차적인 검색 때문에 실패했습니다.
멀티 에이전트 시스템이 효과적인 주된 이유는 문제 해결에 충분한 토큰을 쓸 수 있기 때문입니다. BrowseComp 평가에서, 토큰 소모량 하나가 성능 변동의 80%를 설명했고, 툴 호출 횟수, 모델 선택이 나머지를 설명했습니다. 즉, 독립된 컨텍스트 창에 작업을 배분하는 우리의 아키텍처가 병렬 추론 능력을 확장하는 데 적합하다는 점이 입증되었습니다. 최신 Claude 모델은 토큰 효율을 폭발적으로 높이며, Sonnet 4로 업그레이드하면 Sonnet 3.7의 토큰을 두 배로 늘리는 것보다 성능 향상이 큽니다. 멀티 에이전트 아키텍처는 단일 에이전트 한계를 넘는 작업에서 토큰 활용도를 효과적으로 확장합니다.
단점도 있습니다. 실제로 이런 구조는 토큰을 매우 빨리 소모합니다. 데이터 상, 에이전트는 일반 채팅보다 약 4배, 멀티 시스템은 채팅보다 15배나 많은 토큰을 씁니다. 경제적 타당성을 위해서는, 그만큼 높은 가치가 나오는 작업에 한해 이런 시스템이 적합합니다. 또한, 모든 에이전트가 같은 컨텍스트를 공유해야 하거나 복잡하게 상호 참조가 많은 도메인에는 멀티 시스템이 아직 적합하지 않습니다. 예를 들어 대다수 코딩 작업은 리서치만큼 병렬처리 가능한 태스크가 적고, LLM이 실시간으로 다른 에이전트와 조율·위임에 아직 미흡합니다. 우리가 확인한 바로는, 멀티 에이전트는 강도 높은 병렬화, 단일 컨텍스트 창을 넘는 정보, 다양한 복잡한 툴 인터페이스를 필요로 하는 가치 높은 과제에서 빛을 발합니다.
Anthropic의 리서치 시스템은 리드(주도) 에이전트가 전체 과정을 조율하고, 병렬로 동작하는 특화 서브에이전트에 하위 작업을 맡기는 오케스트레이터-워커 패턴 멀티 에이전트 아키텍처를 사용합니다.
실행 중인 멀티 에이전트 아키텍처: 사용자 쿼리는 리드 에이전트를 거쳐, 병렬로 서로 다른 측면을 탐색하는 서브에이전트들이 생성됩니다.
사용자가 쿼리를 제출하면, 리드 에이전트는 이를 분석·전략을 세우고, 여러 하위 측면을 동시에 살피도록 병렬 서브에이전트를 만듭니다. 위 다이어그램에서처럼, 서브에이전트들은 반복적으로 검색툴을 활용해 정보를 수집(여기서는 2025년 AI 에이전트 기업 관련 정보)하고, 최종적으로 기업 리스트를 리드 에이전트에 돌려보내 통합 결과를 냅니다.
기존 RAG(Retrieval Augmented Generation)는 정적인 검색만 합니다. 즉 쿼리와 가장 유사한 데이터 일부만을 뽑아 응답을 생성합니다. 우리가 설계한 아키텍처는 여러 단계를 거치는 동적 검색으로, 새로운 정보를 찾고 결과를 분석해 품질 높은 답을 만들어 냅니다.
Anthropic 리서치 시스템의 전체 워크플로우 프로세스 다이어그램. 사용자가 쿼리를 제출하면 LeadResearcher 에이전트가 반복적인 리서치 과정을 시작합니다. LeadResearcher는 접근법을 고민하며, 컨텍스트가 200,000 토큰 한계를 넘을 경우 대화가 잘릴 수 있으므로 Memory에 계획을 저장하여 연속성을 확보합니다. 이어, 특정 리서치 태스크가 주어진 하위 서브에이전트들을 만듭니다(그 수에는 제한 없음). 각 서브에이전트는 독립적으로 웹 검색을 하고, interleaved thinking으로 툴 결과를 평가, 발견을 LeadResearcher에 반환합니다. LeadResearcher는 결과를 종합해 추가 연구가 필요한지 결정—필요하다면 서브에이전트를 추가하거나 전략을 수정합니다. 충분한 정보가 모이면, research loop를 종료하고 모든 결과를 CitationAgent에 전달해 인용 출처 업무를 처리합니다. 이렇게 하면 모든 주장이 정확하게 인용될 수 있습니다. 최종 결과(인용 포함)는 사용자에게 반환됩니다.
멀티 에이전트 시스템은 단일 에이전트와 달리, 조정 복잡도가 급증합니다. 초기 버전에서는 간단한 쿼리에 50개가 넘는 서브에이전트를 만들거나, 확인되지 않은 소스를 무한정 찾거나, 불필요한 경과 보고로 서로 방해하는 오류가 많았습니다. 각 에이전트는 프롬프트로 유도되므로, 프롬프트 튜닝이 주요 개선 수단이었습니다. 다음은 우리가 배운 주요 원칙입니다.
Anthropic의 프롬프트 전략은 엄격한 규칙이 아닌 좋은 인간 리서처들의 문제 해결 휴리스틱을 프롬프트로 코딩하는 데 중점을 뒀습니다: 큰 문제 쪼개기, 소스 품질 신중히 평가, 새로운 정보마다 검색 방법 조정, 깊이-넓이 우선 판단, 예상치 못한 부작용 방지(명확한 가드레일 설정), 관찰/테스트케이스 빠른 피드백 루프 구축 포함입니다.
우수한 평가는 신뢰할 수 있는 AI 구축에 필수이며, 에이전트 시스템도 예외가 아닙니다. 그러나 멀티 에이전트 평가는 독특한 도전이 있습니다. 전통적 평가는 AI가 매번 동일 경로를 따르면, 입력 X→경로 Y→출력 Z가 맞는지 검증하지만, 멀티 시스템은 같은 시작점이어도 완전히 다른, 여럿이 모두 타당한 경로를 밟습니다. 한 에이전트는 세 가지 소스를, 다른 에이전트는 열 가지 소스를 탐색하거나, 서로 다른 툴을 써 같은 답을 낼 수 있습니다. 언제나 “정답 경로”를 미리 알 수 없으니, 과정 따라갔는지만 체크할 수 없습니다. 따라서, 산출물의 적합성과 합리적 과정 모두를 탄력적으로 평가해야 합니다.
소규모 샘플로 신속 평가 시작하기. 초기엔 프롬프트만 건드려도 성공률이 30→80% 오르는 등 효과가 커서, 단 몇 케이스만으로도 개선을 확인할 수 있었습니다. 우리는 대략 20개의 실제 사용 패턴 쿼리로 시작했습니다. 대다수 AI팀이 수백 케이스 큰 평가만 의미 있다고 생각해 평가 작성에 주저하지만, 소규모 케이스부터 빠르게 시작하는 것이 훨씬 낫습니다.
LLM-판사 평가가 잘하면 수십~수백 배 이상 확장된다. 리서치 결과물은 자유 형태이거나 정답이 딱 떨어지지 않아, 전통적 방식으로는 평가가 어렵습니다. LLM은 채점에 아주 적합합니다. 우리는 실제로 루브릭으로 만든 평가 기준(사실성, 인용 정확, 완전성, 소스 품질, 툴 효율 등)에 따라 평가하고, 한 번의 LLM 호출에서 0.0~1.0 점수 및 합격/불합격을 내리도록 했습니다. 이렇게 하면 사람 평가와 가장 일치하며, 단일 답이 있는 케이스에서는 정답만 체크하면 됩니다. LLM 평가자로 수백 개 결과를 확장성 있게 평가했습니다.
사람 평가는 자동화가 놓치는 부분 보완. 직접 테스트한 경우, 자동화 평가로 잡지 못하는 변칙/엣지 케이스(잘못된 소스, 드문 시스템 오류, 은근한 소스 선택 편향 등)를 발견할 수 있었습니다. 예컨대, 우리 초기 에이전트는 학술 PDF, 개인 블로그 등 신뢰도 높은 자료보다 SEO에 최적화된 허접 콘텐츠를 더 자주 선택하는 문제를 사람이 발견해 소스 품질 휴리스틱을 강화했고, 즉시 해결됐습니다. 자동 평가가 있어도 수동 테스트는 반드시 필요합니다.
멀티 에이전트 시스템은 예측 불가한 상호작용이 많습니다. 예를 들어 리드 쪽 소폭 개선이 서브 전체에 큰 영향을 줍니다. 성공하려면 개별 동작만이 아니라, 상호작용 패턴 자체를 이해해야 합니다. 따라서, 최적의 프롬프트는 엄격한 지침이 아닌 협력적 프레임워크—작업 분업, 풀이 방식, 노력 분배 등—이 되어야 합니다. 이를 위해 세심한 프롬프트/툴 설계, 견고한 휴리스틱/관찰성, 빠른 피드백 루프가 핵심입니다. Anthropic Cookbook의 오픈소스 프롬프트에도 실제 시스템 예시가 담겨 있습니다.
기존 소프트웨어는 버그가 단일 기능이나 성능만 깎거나 다운타임을 유발하지만, 에이전트 시스템은 소규모 변경도 대규모 행동 변화를 일으켜, 오래 실행되어야 하는 복잡한 에이전트 코딩을 더 어렵게 만듭니다.
에이전트는 상태를 가지고, 오류가 누적된다. 에이전트는 수많은 툴 호출에 걸쳐 상태를 유지하며 장시간 동작합니다. 이때 내구성 있는 실행/오류 핸들링이 필수입니다. 효과적인 완화책이 없으면, 사소한 시스템 결함이 에이전트 전체를 파괴할 수 있습니다. 오류발생시 처음부터 재시작하면 비용 크고 사용자 불편도 큽니다. 우리는 에이전트의 중단 시점부터 복구 가능한 회복체계를 만들었고, AI의 적응력을 활용해 툴 실패 등을 알려주면 꽤 자연스럽게 적응합니다. 이를 Claude 기반 AI의 유연성과, 재시도 로직·정기 체크포인트 등 결정적(deterministic) 보호장치와 결합해 신뢰성을 높였습니다.
디버깅에는 새로운 방식이 필요하다. 에이전트는 실행마다 결정론적이지 않아, 동일 프롬프트여도 행동이 달라집니다. 때문에 디버깅이 어렵습니다. 예컨대 “당연한 정보 못 찾는다”며 제보가 왔을 때, 검색 쿼리가 문제인지, 잘못된 소스 선택인지, 툴 실패인지 알기 힘든데, 프로덕션 레벨 추적을 도입한 덕분에 에이전트 실패의 근본 원인을 체계적으로 분석할 수 있었습니다. 개별 대화 내용은 보지 않지만, 에이전트간 결정 패턴과 상호작용구조의 고수준 관찰로, 예상치 못한 행동패턴도 실시간 진단/개선 가능합니다.
배포에는 세심한 조정 필요. 에이전트 시스템은 프롬프트·툴·로직이 결합된 고도로 상태를 가진web입니다. 업데이트 시 실시간으로 어디에서나 실행 중일 수 있으므로, 새로운 버전이 기존 에이전트를 망가뜨리지 않도록, 모든 에이전트를 동시 교체하지 않습니다. 대신, "레인보우 배포" 기법으로 신/구 버전을 점진적으로 전환해 안정성을 확보합니다.
동기 실행은 병목을 만든다. 현재 리드 에이전트는 각 서브에이전트의 결과를 기다렸다가(동기식) 다음 스텝을 진행합니다. 조율은 쉽지만, 정보 흐름 병목 가능성이 있습니다. 예컨대 리드가 실시간으로 지시를 바꿀 수 없고, 서브들끼리 실시간으로 협업하는 것도 어렵습니다. 비동기식으로 바꾸면 병렬성이 더 늘고, 필요에 따라 신속히 서브 생성도 가능하지만, 결과 조정·상태 일관성·오류전파 등 도전 과제도 클 것입니다. 모델이 더 길고 복잡한 작업 처리에 강해질수록, 비동기 및 상태 관리의 부가적인 복잡성도 감수할 가치가 생깁니다.
AI 에이전트의 "마지막 1마일"이 실제로는 전체 여정의 대부분을 차지합니다. 개발환경에서는 잘 돌아가는 코드도, 프로덕션에서는 신뢰성 확보에 엄청난 추가 엔지니어링이 요구됩니다. 에이전트 시스템은 오류의 복합성 때문에 기존 방식의 사소한 결함이 전체 동작을 심각하게 엉뚱하게 만들 수 있습니다. 한 스텝이 망가지면 엉뚱한 루트를 타고 결과도 예측 불가해집니다. 앞서 설명한 이유들로, 프로토타입과 실제 서비스의 간극은 예상을 훨씬 넘게 벌어질 수 있습니다.
그럼에도 불구하고, 멀티 에이전트 시스템은 열린 리서치 과제에서 큰 가치를 인정받고 있습니다. 사용자들은 Claude가 혼자서는 찾기 어렵던 비즈니스 기회를 발견해주거나, 복잡한 헬스케어 옵션 내비게이팅, 까다로운 기술적 버그 해결, 연구 결과 연결성 발굴로 수일치까지 업무 시간을 절감해준 경험을 전했습니다. 멀티 에이전트 리서치 시스템은 세심한 엔지니어링, 꼼꼼한 테스트, 정교한 프롬프트·툴 디자인, 견고한 운영방식, 그리고 현재 에이전트 능력을 깊이 이해한 연구·제품·엔지니어링팀의 협업이 뒷받침될 때, 확장성 있게 신뢰성을 갖추고 운영 가능합니다. 이미 우리는 이 시스템들이 사람들이 복잡한 문제를 해결하는 방식을 변화시키는 모습을 직접 보고 있습니다.
Clio 임베딩으로 분석한 오늘날 리서치 기능 주요 사용 유형의 분포. 상위 5개 카테고리는 특화 도메인 소프트웨어 시스템 개발(10%), 전문가/기술 콘텐츠 개발·최적화(8%), 비즈니스 성장 및 수익 창출 전략 개발(8%), 학문·교육 자료 개발 지원(7%), 사람, 장소, 조직 등에 관한 정보 조사·검증(5%) 입니다.
Jeremy Hadfield, Barry Zhang, Kenneth Lien, Florian Scholz, Jeremy Fox, Daniel Ford 작성. 리서치 기능 구현에 참여한 Anthropic 여러 팀의 헌신이 담긴 결과입니다. 특히 복잡한 멀티 에이전트 시스템을 프로덕션에 올린 엔지니어링팀에 감사를 표합니다. 초기 사용자들의 탁월한 피드백에도 깊이 감사드립니다.
아래는 멀티 에이전트 시스템에 추가적으로 유용한 팁입니다.
여러 턴에 걸쳐 상태를 변경하는 에이전트의 종단 평가. 대화 중 상태를 꾸준히 바꾸는 에이전트 평가에는 고유한 어려움이 있습니다. 읽기 전용 리서치와 달리, 각 액션이 이후 경로에 영향을 미쳐, 기존 방법으론 처리가 어렵습니다. 우리는 과정별 평가보다는 종단 평가(최종 상태 달성여부 체크)에 집중하는 게 효과적임을 발견했습니다. 즉, 특정 과정을 반드시 따랐는가가 아니라, 올바른 최종 상태에 도달했는지를 평가하는 것이 더 현실적입니다. 복잡한 워크플로우라면, 중간 체크포인트별로 목표 상태 변화만 검증하는 단순화된 접근이 바람직합니다.
장기 대화 관리. 실제 운영 에이전트는 수백 턴에 달하는 대화와컨텍스트 관리가 핵심입니다. 대화가 길어질수록 컨텍스트 창이 부족하므로, 지능적인 압축·외부 메모리 연동 패턴이 필수입니다. 우리는 완료된 작업 단계를 요약해 외부 메모리에 저장, 새 작업 전에 불필요한 컨텍스트 누적을 방지합니다. 컨텍스트 한계에 다다를 때는, 새 에이전트(서브)에게 깔끔한 컨텍스트로 넘기고, 필요한 계획을 외부 메모리에서 불러오게 합니다. 이렇게 분산 설계를 하면, 긴 대화의 맥락 일관성을 유지하며 컨텍스트 과부하를 방지할 수 있습니다.
서브에이전트 출력 파일 시스템 직접 저장으로 정보 손실 최소화. 중간 산출물 일부는 총괄 매개 없이 파일 시스템 등에 바로 저장하고, 참조만 코디네이터에 전달하는 방식이 더 효율적이고, fidelity도↑입니다. 즉, 모든 서브아웃풋을 주도 에이전트를 거치지 않고, 외부 시스템에 직접 저장/경량 참조만 넘기는 구조가 좋습니다. 단계별 대규모 산출물 복사로 토큰 소모가 늘고 정보 누락되는 걸 줄일 수 있습니다. 코드·리포트·시각화 등 전문 프롬프트로 좋은 결과가 나올 때 특히 유용합니다.
