목차
이 글은 Anthropic 엔지니어링 블로그에 2025년 6월 13일 게재된 “How we built our multi-agent research system” 을 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/multi-agent-research-system
한 줄로 말하면 #
리서치는 혼자보다 여럿이 동시에 시키는 게 낫다 — 정확도 +90%. 단, 토큰 비용은 15배.
어떤 문제를 해결하려 했나 #
이런 질문을 챗봇에 던졌다고 해봅시다.
“S&P 500 IT 기업의 이사회 멤버 전부 알려줘.”
한 명의 에이전트에게 시키면, 회사 하나씩 검색해가며 사이트를 뒤집니다. 도중에 컨텍스트 창이 가득 차고, 검색 키워드가 좁아지고, 누락이 생기고, 결국 답을 못 채웁니다.
사람이라면 어떻게 할까요? 팀에 풀어버립니다. 다섯 명이 100개씩 나눠 동시에 조사하고, 한 명이 모아 정리합니다.
Anthropic의 Claude Research 기능(웹·구글 워크스페이스를 뒤져서 답하는 기능)이 바로 이 구조입니다. 단순히 “더 큰 모델"을 쓰는 게 아니라, 여러 에이전트를 동시에 풀어 병렬로 조사시킨 거예요.
해결책: 오케스트레이터-워커 패턴 #
1. 구조: 리드 1명 + 서브에이전트 여럿 #
전체 흐름은 이렇습니다.
사용자 질문
↓
[리드 에이전트] (Claude Opus)
- 질문 분석, 조사 계획 수립
- 계획을 외부 메모리에 저장 (200K 토큰 한계 대비)
- 서브에이전트 3~10명 동시 호출
↓ ↓ ↓
[서브에이전트 1] [서브에이전트 2] [서브에이전트 3] …
(Claude Sonnet) (Claude Sonnet) (Claude Sonnet)
- 각자의 컨텍스트로 독립 조사
- 도구 3개 이상 병렬 호출
- 결과를 압축해 리드에 보고
↓ ↓ ↓
[리드 에이전트]
- 결과 통합, 부족하면 추가 조사 지시
↓
[인용 에이전트] (출처 붙이기)
↓
최종 답변핵심은 서브에이전트마다 컨텍스트 창이 따로 있다는 점입니다. 한 명이 모든 자료를 다 읽어 토큰을 다 태우는 대신, 여러 명이 각자 자기 영역만 읽어와 압축본만 리드에게 넘깁니다.
2. 작업 규모에 따라 인원을 바꾼다 #
모든 질문에 10명을 부르는 건 낭비입니다. 원문이 권장하는 인원 배분은 단순한데 효과적입니다.
| 질문 유형 | 서브에이전트 수 | 도구 호출 수 |
|---|---|---|
| 단순 사실 확인 | 1명 | 3~10번 |
| 비교·요약 | 2~4명 | 각 10~15번 |
| 복잡한 다축 조사 | 10명+ | 많이 |
이걸 프롬프트에 명시적으로 박아두지 않으면, 단순 질문에 50명을 동원하는 어이없는 일이 벌어집니다(실제 발생한 실패 모드입니다).
3. 실패 모드 — production이 어려운 이유 #
프로토타입은 금방 만들었지만, “마지막 한 발자국이 사실은 여행의 대부분” 이었다고 원문은 말합니다. 자주 만난 실패와 처방을 추리면:
| 실패 | 처방 |
|---|---|
| 단순 질문에 50명 호출 | 작업량 등급 규칙을 프롬프트에 명시 |
| 없는 자료를 무한 검색 | 충분 기준과 검색 예산 부여 |
| 서브에이전트끼리 같은 일 중복 | 분담을 명확히 지정 |
| 검색어가 너무 구체적이라 결과 0 | “넓게 시작해 좁혀라” 가이드 |
| SEO 농장 글을 신뢰 | 권위 있는 출처(논문·블로그) 우선 휴리스틱 |
원문이 강조하는 한 줄: “규칙(rules)이 아니라 휴리스틱(heuristics)을 심어줘라.” 이게 사람 시니어가 주니어에게 일을 가르치는 방식과 똑같습니다.
결과 / 효과 #
| 지표 | 결과 |
|---|---|
| 단일 Opus 4 대비 정확도 | +90.2% |
| 병렬 도구 호출로 단축된 시간 | 최대 90% |
| 토큰 사용량이 성능 변동에서 차지하는 비중 | 80% |
| 챗봇 대비 토큰 소비 (단일 에이전트) | 약 4배 |
| 챗봇 대비 토큰 소비 (멀티 에이전트) | 약 15배 |
핵심은 마지막 두 줄입니다. 멀티에이전트는 15배 토큰을 태우고 90% 더 잘하는 트레이드오프입니다. 가치 높은 작업에만 쓰라는 뜻이에요.
멀티에이전트가 잘 맞는 일 / 안 맞는 일 #
쓸수록 좋은 게 아닙니다. 원문이 직접 정리한 경계는 이렇습니다.
잘 맞는 경우:
- 여러 방향으로 펼쳐 조사하는 breadth-first 작업
- 정보량이 한 컨텍스트 창을 넘어서는 경우
- 도구를 많이·복잡하게 다뤄야 하는 경우
- 결과 가치가 높아 토큰 15배가 정당화될 때
안 맞는 경우:
- 모든 에이전트가 같은 컨텍스트를 공유해야 할 때
- 에이전트 간 의존성·실시간 조율이 필요할 때
- 가치가 낮은 작업
- 대부분의 코딩 작업 — 병렬화 가능한 부분이 적기 때문
핵심 결론 #
AI를 더 똑똑하게 쓰는 길은 항상 “더 큰 모델"이라고 생각하기 쉽습니다. 이 글이 보여주는 답은 다릅니다.
“모델 능력의 문제인 줄 알았는데, 사실은 한 명에게 다 시키는 구조가 문제였다.”
지능이 일정 수준을 넘으면, 여럿이 협업하는 구조 자체가 다음 단계의 성능 도약을 만들어냅니다. 인간 사회가 협력으로 폭발적으로 똑똑해진 것과 같은 원리입니다.
내 작업에 적용한다면 #
시나리오 1 — 일반적인 데이터 분석 과정 #
데이터 분석에서 멀티에이전트는 “흩어 조사하는 단계” 에 잘 맞습니다. 반대로 “의존성 강한 단계” 에는 오히려 비용만 올립니다.
[잘 맞는 영역]
EDA(탐색적 데이터 분석)
- 가설 A: 매출과 광고비 상관관계
- 가설 B: 지역별 매출 분포 차이
- 가설 C: 시즌성 패턴
→ 가설마다 서브에이전트 1명씩 병렬 탐색 → 리드가 통합
데이터 소스 조사
- 공공 데이터, 경쟁사 데이터, 학술 논문
→ 출처별 서브에이전트 병렬 수집
[안 맞는 영역]
정제 → 모델링 → 평가
→ 단계가 의존적, 한 명이 일관되게 끌어가는 게 효율적핵심: 분석 작업에서 “동시에 여러 방향을 봐도 되는 단계” 와 “순서가 깨지면 안 되는 단계” 를 구분하세요.
시나리오 2 — 웹 사이트를 자동으로 운영할 때 #
웹 자동운영에서도 비슷한 구분이 가능합니다.
[잘 맞는 영역]
콘텐츠 소스 수집
- 뉴스 사이트 모니터링
- 학술/기술 블로그 모니터링
- 커뮤니티 트렌드 모니터링
→ 채널별 서브에이전트 병렬 수집 → 리드가 중복 제거 후 우선순위 정리
발행 전 다축 검수
- 톤 가이드 검수자
- SEO·메타 검수자
- 사실관계·법적 리스크 검수자
→ 한 글에 검수자 3명을 동시에 붙이고 결과 합산
[안 맞는 영역]
실제 글 작성
→ 톤 일관성·논리 흐름 때문에 한 명이 끝까지 쓰는 게 낫다
배포·롤백
→ 단계 의존성이 강해 직렬 처리가 안전핵심: 콘텐츠 운영에서 “넓게 흩어지는 일은 여럿이, 일관성이 필요한 일은 혼자” 가 일반 원칙입니다. 그리고 이 모든 게 토큰 15배를 정당화할 만큼 가치 있는 작업인지 먼저 따져보세요.
Anthropic 엔지니어링 블로그를 오래된 순서대로 읽고 정리합니다.
