How we built our multi-agent research system 읽기 — 병렬 서브에이전트로 만든 리서치 시스템

Anthropic은 2025년 6월 13일 How we built our multi-agent research system을 냈다. Claude의 Research 기능을 프로토타입에서 서비스까지 끌고 가며 얻은 멀티에이전트 시스템의 구조, 프롬프트, 평가, 운영 교훈을 적은 글이다.

별도 표기가 없으면 아래 내용은 원문 기준이다. 성능과 토큰 수치는 Anthropic이 자체로 잰 값이고 측정 방법은 대부분 원문에 없다. 프롬프트 지침에 든 숫자와 예시의 숫자는 측정값이 아니다. 원문에 없는 내용은 "원문에 없다"고 적었다.

들어가며: 에이전트와 서브에이전트

에이전트는 LLM이 "검색 → 결과 확인 → 다음 행동 결정"을 스스로 반복하며 도구를 호출하는 프로그램이다. 원문은 멀티에이전트 시스템을 이런 에이전트 여럿이 함께 일하는 시스템으로 정의한다. Research 기능에서는 한 에이전트가 사용자 질의를 보고 조사 계획을 세운다. 그다음 병렬로 움직이는 에이전트를 만들어 정보를 동시에 찾게 한다.

서브에이전트(subagent)는 다른 에이전트가 맡긴 일을 하는 하위 에이전트다. 일을 나눠 맡기는 쪽을 리드(lead) 에이전트라 부른다. 서브에이전트를 만든다는 말은 에이전트를 하나 더 실행해 일을 넘긴다는 뜻이다. 에이전트가 여럿이 되면 조율, 평가, 신뢰성에서 새로운 문제가 생긴다.

멀티에이전트는 토큰을 많이 쓴다, 그래서 고를 일이 정해진다

맞는 일과 맞지 않는 일

리서치는 필요한 단계를 미리 알기 어렵다. 조사하다 발견한 것에 따라 방향을 바꿔야 하므로 고정된 경로를 코드로 박아 둘 수 없다.

컨텍스트 윈도우(context window)는 모델이 한 번에 볼 수 있는 텍스트의 범위다. 긴 조사는 이 범위를 금방 채운다. 서브에이전트는 각자 자기 컨텍스트 윈도우에서 질문의 다른 면을 동시에 파고들고, 핵심만 추려 리드 에이전트에게 돌려준다. 원문은 이를 "검색의 본질은 압축"이라고 표현한다.

원문 곳곳에서 멀티에이전트에 맞는 일의 조건이 나온다. 아래 다섯 줄은 흩어진 문장을 이 글이 묶은 것이다.

• 독립된 방향 여러 개를 동시에 쫓는 너비 우선(breadth-first) 질의
• 늘어나는 토큰 비용을 치를 만큼 가치가 큰 일
• 병렬화를 많이 할 수 있는 일
• 한 컨텍스트 윈도우에 들어가지 않는 정보
• 복잡한 도구를 여럿 다루는 일

반대로 모든 에이전트가 같은 컨텍스트를 공유해야 하거나 에이전트 사이 의존이 많은 영역은 지금은 맞지 않는다. 코딩 작업 대부분은 리서치보다 병렬화할 일이 적고, LLM 에이전트는 다른 에이전트에게 실시간으로 조율하고 위임하는 데 아직 능숙하지 않다는 것이 이유다. '지금'은 글이 나온 2025년 6월이다.

수치마다 잰 범위가 다르다

• 90.2%. Claude Opus 4 리드와 Claude Sonnet 4 서브에이전트로 짠 멀티에이전트가, 단일 에이전트 Claude Opus 4보다 Anthropic의 "내부 리서치 평가"에서 90.2% 앞섰다. 표본 수와 점수 정의는 원문에 없고, 아래 평가 절의 "약 20개 질의"와 같은 세트인지도 알 수 없다. 예로 든 질의는 S&P 500 정보기술 기업의 이사진을 모두 찾는 것이다. 멀티에이전트는 일을 쪼개 답을 찾았고, 단일 에이전트는 느린 순차 검색 끝에 찾지 못했다.
• BrowseComp. 찾기 어려운 정보를 브라우징 에이전트가 얼마나 잘 찾는지 재는 평가다. 이 평가에서는 토큰 사용량이 점수 차이를 가장 많이 설명했다. 점수가 벌어지는 정도(분산)의 80%는 토큰 사용량 하나로 짚이고, 도구 호출 횟수와 모델 선택을 더한 세 요인으로는 95%가 짚인다. 통계적 설명이지 원인을 증명한 것이 아니다. "멀티에이전트는 주로 충분한 토큰을 쓰게 해 주기 때문에 잘 된다"는 풀이는 Anthropic의 해석이고, 분석 방법은 적혀 있지 않다.
• 모델 vs 토큰 예산. 모델을 Sonnet 3.7에서 Sonnet 4로 바꾸는 쪽이 Sonnet 3.7의 토큰 예산을 두 배로 늘리는 것보다 성능이 더 올랐다. 벤치마크나 수치 없이 한 문장으로만 나온다.
• 토큰 배수. Anthropic의 데이터에서 에이전트는 채팅보다 보통 약 4배, 멀티에이전트는 약 15배의 토큰을 쓴다. 작업 종류, 토큰 구성, 비용 금액은 원문에 없다.

구조: 오케스트레이터-워커

Research 시스템은 오케스트레이터-워커(orchestrator-worker) 패턴이다. 한 에이전트(리드)가 전체를 조율하고, 서브에이전트가 맡은 조사를 병렬로 수행한다. 흐름은 이렇다.

1. 사용자가 질의를 내면 LeadResearcher 에이전트가 만들어지고 조사 반복에 들어간다. LeadResearcher가 오케스트레이터 역할이다.
2. LeadResearcher는 접근 방식을 생각하고 계획을 Memory에 저장한다. Memory는 계획을 적어 두는 별도 저장소다. 컨텍스트 윈도우가 200,000토큰(LeadResearcher 기준으로 원문이 적은 값)을 넘으면 잘려 나가는데, 그때 Memory에서 계획을 다시 읽어 온다.
3. 서브에이전트에게 조사 과제를 준다. 원문 그림에는 둘이 나오지만 개수는 정해져 있지 않다.
4. 서브에이전트는 각자 웹 검색을 한다. 도구 결과를 볼 때마다 중간에 생각해 결과를 평가하는 인터리브드 씽킹(interleaved thinking)을 쓴다. 결과는 LeadResearcher에게 돌려준다.
5. LeadResearcher는 결과를 종합하고 조사가 더 필요한지 판단한다. 필요하면 서브에이전트를 더 만들거나 전략을 고친다.
6. 조사 반복을 끝내면 시스템이 모든 결과를 CitationAgent에 넘긴다. CitationAgent는 문서와 보고서를 읽고 각 주장 옆에 출처를 달 자리를 찾는 에이전트다. 원문은 모든 주장에 출처가 붙게 하는 단계라고 설명하지만 누락 비율은 원문에 없다.
7. 인용이 붙은 최종 결과가 사용자에게 간다.

RAG(Retrieval Augmented Generation, 검색 증강 생성)는 질의와 비슷한 조각을 정해진 방식으로 가져와 답을 만드는 정적 검색이다. Research 시스템은 이와 다르다. 여러 단계로 검색하면서 관련 정보를 동적으로 찾고, 새로 나온 내용에 맞춰 방향을 바꾸고, 결과를 분석해 답을 만든다.

서브에이전트에게 일을 맡기는 법: 지시에 네 가지를 담는다

초기 에이전트는 단순한 질의에 서브에이전트를 50개 만들거나, 없는 출처를 웹에서 끝없이 뒤지거나, 과도한 업데이트로 서로 방해했다. 에이전트는 프롬프트로 움직이므로 Anthropic은 프롬프트 엔지니어링을 이런 행동을 고치는 주된 수단으로 삼았다. 원문이 정리한 원칙 가운데 하나가 위임하는 법을 가르치는 일이다.

리드 에이전트는 질의를 하위 과제로 쪼개 서브에이전트에게 설명한다. 서브에이전트마다 목표, 출력 형식, 쓸 도구와 출처에 대한 안내, 분명한 작업 경계가 필요하다. 과제 설명이 구체적이지 않으면 에이전트들이 일을 겹치게 하거나, 빈틈을 남기거나, 필요한 정보를 못 찾는다.

원문이 소개하는 실패 사례는 이렇다. 처음에는 리드가 "research the semiconductor shortage" 같은 짧은 지시를 내렸다. 서브에이전트들은 과제를 잘못 이해하거나 서로 같은 검색을 했다. 한 서브에이전트는 2021년 자동차 칩 위기를 조사했고, 다른 둘은 현재 2025년 공급망을 겹쳐 조사했다. 역할 분담이 없었다.

그림 오른쪽의 예시는 원문에 없는 이 글의 예시다. 원문은 시스템의 예시 프롬프트를 Cookbook에 오픈소스로 공개했다고 안내한다.

도구 설계는 별도 원칙이다

원문은 에이전트와 도구의 인터페이스가 사람과 컴퓨터의 인터페이스만큼 중요하다고 본다. Slack에만 있는 맥락을 웹에서 찾는 에이전트는 처음부터 실패한다. 도구마다 목적이 겹치지 않고 설명이 분명해야 한다. 도구 설계는 Writing effective tools for agents 읽기에서 따로 정리했다.

도구 테스트 에이전트는 원문에서 "에이전트가 스스로 고치게 한다"는 원칙 아래 나오는 사례다. 결함 있는 MCP 도구를 받아 직접 써 보고 도구 설명을 다시 쓴다. 도구를 수십 번 시험해 미묘한 점과 버그를 찾았다. 새 설명을 쓰자 이후 에이전트의 과제 완료 시간이 40% 줄었다. 원문은 에이전트가 실수를 대부분 피했기 때문이라고 설명한다. 기준 시간, 도구 수, 실행 횟수는 원문에 없다.

투입량 조절과 병렬 호출

질의가 복잡할수록 에이전트를 더 투입한다

에이전트는 과제마다 얼마나 힘을 들일지 가늠하는 데 서툴렀다. 초기 버전은 단순한 질의에도 자원을 과하게 썼다. 그래서 Anthropic은 규칙을 프롬프트에 넣었다. 예를 들어 단순한 사실 확인은 에이전트 1개면 된다. 아래 값은 프롬프트에 넣은 지침의 예시 규모다(직접 비교와 복잡한 조사는 원문이 "might"로 썼다). 측정값이 아니다.

질의	예시 규모	도구 호출
단순한 사실 확인	에이전트 1개	3~10회
직접 비교	서브에이전트 2~4개	각각 10~15회
복잡한 조사	서브에이전트 10개 넘게(역할을 분명히 나눔)	원문에 횟수 없음

병렬 호출

초기 에이전트는 검색을 순차로 해서 매우 느렸다. Anthropic은 병렬화를 두 가지 넣었다. 하나는 리드가 서브에이전트 3~5개를 직렬이 아니라 병렬로 띄우는 것이다. 다른 하나는 서브에이전트가 도구를 3개 이상 병렬로 쓰는 것이다.

이 두 변경이 함께 복잡한 질의의 조사 시간을 최대 90% 줄였다. 앞의 90.2%는 품질 수치이고, 이 90%는 시간 수치다. 서로 다른 지표다. "최대"는 상한이다. 두 변경 중 어느 쪽 몫인지와 측정 조건은 원문에 없다. 원문은 이 덕에 몇 시간이 아닌 몇 분 만에 더 많은 일을 처리한다고 설명한다.

서브에이전트 10개 넘게 쓰는 질의와 한 번에 3~5개씩 띄우는 병렬 호출이 어떻게 이어지는지는 원문에 없다. 10개를 3~5개씩 나눠 돌린다고 읽을 수 있지만 이는 이 글의 추측이다.

그 밖의 프롬프트 원칙

• 에이전트 입장에서 생각한다. Console에서 시스템과 같은 프롬프트와 도구로 에이전트를 돌려 보며 한 단계씩 지켜봤다. 결과가 충분한데도 계속하거나, 검색어가 너무 장황하거나, 도구를 잘못 고르는 실패가 바로 보였다.
• 에이전트가 스스로 고치게 한다. Claude 4 모델은 프롬프트와 실패 양상을 주면 원인을 진단하고 개선안을 낼 수 있었다.
• 넓게 시작해서 좁힌다. 에이전트는 길고 구체적인 검색어로 시작해 결과를 거의 못 얻는 경향이 있었다. 짧고 넓은 검색어로 시작해 상황을 보고 점점 좁히라고 프롬프트에 적었다.
• 생각 과정을 이끈다. 확장된 사고(extended thinking)는 Claude가 눈에 보이는 사고 과정으로 추가 토큰을 내놓는 모드다. 리드는 이것으로 접근 방식, 쓸 도구, 질의 복잡도, 서브에이전트 수와 역할을 정한다. 시험에서 지시 따르기, 추론, 효율이 좋아졌다고 하지만 수치는 없다.

원문은 엄격한 규칙 대신 경험칙(휴리스틱)을 프롬프트에 넣는 쪽을 택했다. 숙련된 사람의 조사 방식에서 다음을 프롬프트에 옮겼다.

• 어려운 질문을 작은 과제로 나눈다
• 출처의 질을 꼼꼼히 따진다
• 새 정보에 따라 검색 방식을 바꾼다
• 깊이(한 주제를 자세히)와 너비(여러 주제를 병렬로) 가운데 어디에 집중할지 알아본다

에이전트가 통제를 벗어나지 않도록 명시적인 가드레일도 두었지만 내용은 적지 않았다.

평가: 약 20개 질의로 시작하고, 사람이 보완한다

같은 출발점에서도 에이전트가 전혀 다른 경로로 목표에 갈 수 있다. 출처 세 곳을 찾는 에이전트가 있고 열 곳을 찾는 에이전트가 있다. 그래서 미리 정한 경로를 따랐는지만으로는 평가하기 어렵다. 결과가 맞는지와 과정이 합리적인지를 함께 보는 유연한 평가가 필요하다.

작은 표본으로 바로 시작한다

개발 초기에는 변경의 효과가 커서 적은 사례로도 차이가 보인다. 원문은 프롬프트를 조금 고치면 성공률이 30%에서 80%로 오를 수도 있다고 쓴다. 설명용 예시이고, 실제로 잰 값인지는 원문에 없다. Anthropic은 실제 사용 패턴을 반영한 약 20개 질의로 시작했다. 수백 개 규모의 평가를 갖출 때까지 미루지 말고 몇 개 사례로 곧장 시작하라는 조언이다.

LLM이 채점한다

리서치 결과는 자유 형식 텍스트이고 정답이 하나인 경우가 드물어서 프로그램으로 채점하기 어렵다. 그래서 LLM-as-judge, 곧 LLM이 채점자 역할을 맡는 방식을 썼다. 채점 기준표(루브릭)는 다섯 항목이다.

기준마다 채점자를 따로 두는 방식도 써 봤다. 그러나 LLM 호출 한 번에 프롬프트 하나로 0.0~1.0 점수와 통과·실패 판정을 내게 하는 쪽이 가장 일관되고 사람의 판단과 잘 맞았다. 평가 케이스에 명확한 정답이 있을 때 특히 효과적이었다. 예컨대 연구개발비 상위 3개 제약사를 정확히 나열했는지 확인하는 경우다. 채점 프롬프트 전문, 통과 기준 점수, 출력 형식, 사람과의 일치율은 원문에 없다.

사람이 잡는 것

사람이 에이전트를 직접 써 보면 평가가 놓친 경우가 나온다. 낯선 질의에 대한 환각 답변, 시스템 장애, 미묘한 출처 선택 편향이 그렇다. 원문의 사례에서는 사람 테스터가 초기 에이전트가 학술 PDF나 개인 블로그 같은 권위 있는 출처 대신 SEO에 맞춘 콘텐츠 농장을 계속 고른다는 것을 알아챘다. 프롬프트에 출처 품질 휴리스틱을 넣자 이 문제가 줄었다고 한다.

멀티에이전트에는 의도해서 넣지 않은 창발적 행동(emergent behavior)이 있다. 리드 에이전트를 조금 고쳐도 서브에이전트의 행동이 예측하기 어렵게 바뀐다. 개별 에이전트가 아니라 에이전트 사이의 상호작용 패턴을 이해해야 한다. 좋은 프롬프트는 엄격한 지시보다 역할 분담, 문제 해결 방식, 투입량 기준을 정하는 협업의 틀에 가깝다.

프로덕션: 에이전트는 상태를 갖고 에러는 쌓인다

에이전트는 오래 돌면서 도구 호출을 거칠 때마다 상태를 쌓는다. 여기서 상태는 지금까지 한 일과 받은 결과다. 작은 오류도 누적되어 크게 번진다. 에러가 나도 처음부터 다시 시작할 수는 없다. 비용이 크고 사용자도 불편하기 때문이다. 그래서 Anthropic은 에러가 난 지점에서 이어서 실행하는 시스템을 만들었다. 도구가 실패하고 있다고 에이전트에게 알려 주면 에이전트가 알아서 적응했고, 원문은 이것이 놀랄 만큼 잘 된다고 쓴다. 여기에 재시도 로직과 주기적인 체크포인트(checkpoint, 진행 상태를 저장해 둔 지점) 같은 코드로 정해진 대로 동작하는(결정론적) 안전장치를 더한다.

체크포인트에 무엇을 저장하는지, 얼마나 자주 저장하는지, 재시도를 몇 번까지 하는지, 이어서 실행할 때 이미 한 도구 호출이 두 번 실행되지 않게 어떻게 막는지는 원문에 없다.

디버깅은 에이전트가 같은 프롬프트에도 실행마다 다르게 움직여서 어렵다. 사용자가 "뻔한 정보를 못 찾는다"고 신고해도 이유를 볼 수 없었다. 검색어가 나빴는지, 출처를 잘못 골랐는지, 도구가 실패했는지 알 수 없었다. 전체 프로덕션 트레이싱(tracing, 에이전트가 거친 단계를 기록해 따라가는 일)을 넣고서야 실패 원인을 체계적으로 진단할 수 있었다. 일반 모니터링에 더해 의사결정 패턴과 상호작용 구조를 보고, 개인정보 때문에 개별 대화의 내용은 보지 않는다.

배포도 조율이 필요하다. 에이전트 시스템은 프롬프트, 도구, 실행 로직이 얽혀 이전 단계의 결과를 쥔 채 계속 도는 시스템이고 거의 쉬지 않고 돈다. 배포하는 순간 에이전트는 어느 단계에나 있을 수 있다. 모든 에이전트를 한꺼번에 새 버전으로 바꿀 수 없으므로 무지개 배포(rainbow deployment)를 쓴다. 이전 버전과 새 버전을 함께 돌리면서 트래픽을 점진적으로 옮기는 방식이다.

원문은 두 버전이 동시에 실행된다고만 적는다. 이전 버전을 언제 내리는지, 버전 사이에 체크포인트가 호환되는지는 원문에 없다.

동기 실행이라는 병목

2025년 6월 현재 리드는 서브에이전트를 동기로 실행한다. 서브에이전트 묶음이 모두 끝나기를 기다린 뒤에 다음으로 간다. 조율은 단순해지지만 에이전트 사이 정보 흐름에 병목이 생긴다. 리드는 서브에이전트를 조종할 수 없고, 서브에이전트끼리 조율할 수 없다. 서브에이전트 하나가 검색을 끝내기를 기다리며 시스템 전체가 막히기도 한다. 한 라운드의 시간이 가장 느린 서브에이전트에 묶인다는 읽기는 이 글의 해석이다. 시간 제한이나 부분 결과 정책은 원문에 없다.

비동기 실행이면 에이전트가 동시에 일하고 필요할 때 서브에이전트를 새로 만들 수 있어 병렬성이 더 늘어난다. 대신 결과 조율, 상태 일관성, 서브에이전트 사이의 에러 전파를 다루기 어려워진다. 모델이 더 길고 복잡한 조사를 다룰 수 있게 되면 성능 이득이 이 복잡성을 정당화할 것이라고 Anthropic은 예상한다.

부록: 최종 상태 평가, 긴 대화, 파일로 출력 넘기기

원문 부록에는 팁이 세 가지 있다.

• 최종 상태 평가. 여러 턴에 걸쳐 저장된 상태를 바꾸는 에이전트는 한 행동이 이후 환경을 바꾸기 때문에 턴별로 평가하기 까다롭다. Anthropic은 최종 상태를 평가했다. 특정 과정을 따랐는지가 아니라 올바른 최종 상태에 이르렀는지를 본다. 복잡한 워크플로는 특정 상태 변화가 있어야 할 체크포인트로 나눠 평가하고, 모든 중간 단계를 검증하려 하지 않는다.
• 긴 대화 관리. 프로덕션 에이전트는 수백 턴의 대화를 이어 가기도 한다. 에이전트가 끝낸 작업 단계를 요약해 핵심 정보를 외부 메모리에 저장한 뒤 새 작업으로 넘어간다. 컨텍스트 한계가 다가오면 깨끗한 컨텍스트의 새 서브에이전트를 만들고 인수인계로 연속성을 유지한다. 연구 계획 같은 저장된 맥락은 메모리에서 다시 읽는다.
• 파일 시스템으로 서브에이전트 출력 전달. 모든 결과가 리드를 거치면 "전화 게임(game of telephone)"처럼 정보가 변한다. 원문은 아티팩트 시스템(artifact system)을 제안한다. 서브에이전트가 결과를 외부 시스템에 저장하고 가벼운 참조만 코디네이터에게 돌려준다. 큰 출력이 리드의 대화 기록을 거치지 않는다. 원문은 충실도와 성능이 좋아지고 토큰 부담이 줄어든다고 하지만 수치는 없다. 코드, 보고서, 데이터 시각화처럼 구조가 있는 출력에 잘 맞는다. 참조 형식과 리드가 나중에 그것을 읽는 방법은 원문에 없다.

마치며: 만들기 전에 정할 것

원문을 바탕으로 멀티에이전트를 만들기 전에 정할 것을 추리면 이렇다.

• 일이 맞는가. 독립된 방향이 여럿이고, 병렬화가 되고, 한 컨텍스트에 안 들어가는 정보를 다루는 일인가. 공유 맥락이나 에이전트 사이 의존이 많은 일은 2025년 6월 기준으로 맞지 않는다.
• 토큰을 감당할 만큼 값어치가 있는가. Anthropic의 데이터에서 멀티에이전트는 채팅보다 보통 약 15배의 토큰을 쓴다.
• 서브에이전트 지시에 네 가지를 담는다. 목표, 출력 형식, 도구와 출처 안내, 작업 경계다.
• 투입량 규칙을 프롬프트에 넣는다. 단순한 질의에 서브에이전트를 과하게 만들지 않게 한다.
• 약 20개 질의로 평가를 시작하고, 사람이 직접 써 본다.
• 에러가 쌓이는 것을 전제로 한다. 이어서 실행, 트레이싱, 무지개 배포를 갖춘다.
• 동기 실행의 한계를 안고 간다. 병렬성은 늘지만 가장 느린 서브에이전트를 기다린다.

시리즈의 다른 글과도 이어진다. 워크플로와 에이전트를 가르는 기준은 Building effective agents 읽기에서, 서브에이전트가 컨텍스트 윈도우를 따로 갖는 이유와 맞닿은 컨텍스트 관리는 컨텍스트 엔지니어링 문서 읽기에서 다뤘다.

---

참고

• How we built our multi-agent research system — Anthropic (2025-06-13)
• Anthropic Cookbook — 원문이 예시 프롬프트가 있다고 안내하는 곳. 이 글에서는 열어 보지 않았다.