AI 적용 사례 – Anthropic의 멀티 에이전트 리서치 시스템
멀티 에이전트 시스템은 여러 에이전트가 함께 일하는 구조를 가리킵니다. Anthropic은 2025년 6월 13일 엔지니어링 블로그에 Claude의 리서치 기능을 이 구조로 만든 과정을 공개했는데, 구조와 수치뿐 아니라 프롬프트를 다듬은 방법, 평가, 운영까지 한 글에 담겨 있어요.
이 글은 그 원문을 구조와 설계 판단 중심으로 풀어 쓴 정리입니다. 수치는 원문의 숫자와 조건을 그대로 옮겼습니다.
단계를 미리 정할 수 없는 조사라는 일
원문 첫 줄에 따르면 Claude의 리서치 기능은 웹과 Google Workspace, 연결된 통합 도구들을 가로질러 검색하면서 복잡한 과제를 처리합니다. 사용자의 질의를 받아 조사 과정을 계획하는 에이전트가 있고, 이 에이전트가 동시에 정보를 찾는 에이전트들을 도구로 만들어 내는 방식이에요.
Anthropic이 이 일에 에이전트를 쓴 이유도 적혀 있습니다. 조사는 필요한 단계를 미리 내다보기 어려운 열린 문제이고, 사람도 조사하면서 찾은 내용에 따라 접근을 계속 바꿉니다. 그래서 중간 결과를 보고 어느 방향을 팔지 스스로 정하면서 여러 턴을 돌아야 하는데, 원문은 한 번에 죽 흘러가는 선형 파이프라인으로는 이런 과제를 처리할 수 없다고 봤어요.
기존 방식과의 차이도 한 문단으로 짚습니다. 질의와 가장 비슷한 조각을 가져와 답을 만드는 RAG의 정적 검색과 달리, 멀티 에이전트 리서치 시스템은 여러 단계에 걸쳐 검색하면서 새로 찾은 내용에 맞춰 방향을 고친다는 설명입니다.
사람들이 이 기능을 어디에 쓰는지 보여 주는 그림도 원문 끝에 실려 있습니다.
그림 설명에 적힌 상위 유형은 다섯 가지예요.
- 전문 분야에 걸친 소프트웨어 시스템 개발 (10%)
- 전문·기술 콘텐츠 작성과 다듬기 (8%)
- 사업 성장과 수익 창출 전략 수립 (8%)
- 학술 연구와 교육 자료 개발 지원 (7%)
- 사람, 장소, 조직에 대한 정보 조사와 확인 (5%)
리드 에이전트 하나가 서브에이전트 여럿을 조율한다
이 멀티 에이전트 구조를 원문은 오케스트레이터-워커 패턴이라고 부릅니다. 리드 에이전트가 전체 과정을 조율하고, 병렬로 도는 서브에이전트에게 일을 넘깁니다. 서브에이전트는 Claude Code 공식 문서의 정의로는 특정 유형의 작업을 맡는 전문 AI 어시스턴트이고, 자세한 내용은 서브에이전트 글에 정리해 뒀어요.
원문의 흐름도 설명을 따라가면 이렇습니다. 리드 에이전트는 먼저 접근 방법을 생각하고 그 계획을 메모리에 저장합니다. 컨텍스트 창이 200,000토큰을 넘으면 잘리기 때문에 계획을 따로 남겨 둔다고 해요. 그다음 조사 과제를 하나씩 맡긴 서브에이전트를 만드는데, 수는 정해져 있지 않습니다.
종합 단계에는 되돌아가는 길이 있습니다. 리드 에이전트가 결과를 모아 보고 조사가 더 필요하다고 판단하면 서브에이전트를 추가로 만들거나 전략을 고쳐요. 정보가 충분해지면 이 반복에서 빠져나와 모든 결과를 인용 에이전트에게 넘깁니다.
| 구성 (제 나름의 정리) | 맡은 일 |
|---|---|
| 리드 에이전트 | 질의를 분석해 전략을 세우고, 과제를 나눠 주고, 결과를 종합해 더 조사할지 정한다 |
| 서브에이전트 | 각자 웹을 검색하고 도구 결과를 평가한 뒤 찾은 내용을 리드에게 돌려준다 |
| 메모리 | 리드 에이전트의 계획을 보관한다 |
| 인용 에이전트 | 문서와 조사 보고서를 처리해 인용이 들어갈 위치를 찾는다 |
멀티 에이전트가 리서치에 맞는 이유와 수치
원문은 검색의 본질을 압축이라고 봅니다. 방대한 자료에서 필요한 것만 추려 내는 일이고, 서브에이전트는 각자 컨텍스트 창에서 질문의 서로 다른 측면을 동시에 탐색한 뒤 중요한 내용만 줄여서 리드 에이전트에게 넘겨요. 에이전트마다 도구와 프롬프트, 탐색 경로가 따로라서 조사가 서로 독립적으로 이뤄진다는 점도 이유로 들었습니다.
90.2%는 Anthropic 내부 평가에서 나온 숫자이고, 원문은 여러 독립된 방향을 동시에 좇는 넓은 질의에서 특히 강했다고 덧붙입니다. 예로 든 것은 S&P 500 정보기술 기업들의 이사회 구성원을 모두 찾는 질의였어요. 이 구성은 일을 서브에이전트 과제로 쪼개서 답을 찾았습니다.
성능이 어디서 나오는지에 대한 분석도 있습니다. 찾기 어려운 정보를 찾아내는 능력을 재는 BrowseComp 평가에서 세 요인이 성능 편차의 95%를 설명했고, 그중 토큰 사용량 하나가 80%를 설명했다고 해요. 나머지 둘은 도구 호출 횟수와 모델 선택입니다. 원문은 멀티 에이전트 구조가 통하는 주된 이유를, 문제를 풀 만큼 충분한 토큰을 쓰게 해 준다는 데서 찾습니다.
토큰 배수는 두 단계로 적혀 있습니다. Anthropic 데이터에서 에이전트는 보통 일반 채팅의 약 4배, 멀티 에이전트 시스템은 약 15배를 씁니다.
원문이 맞지 않는다고 밝힌 일
멀티 에이전트는 토큰을 빠르게 쓰는 구조라서 조건이 붙습니다. 원문은 늘어난 성능의 값을 치를 만큼 가치가 큰 작업이어야 경제성이 맞는다고 적었어요.
잘 맞는다고 한 일
- 병렬로 많이 쪼갤 수 있다
- 정보가 컨텍스트 창 하나를 넘는다
- 복잡한 도구를 여럿 다뤄야 한다
지금은 잘 맞지 않는다고 한 일
- 모든 에이전트가 같은 컨텍스트를 공유해야 한다
- 에이전트 사이의 의존이 많다
코딩에 대한 언급도 여기 있습니다. 대부분의 코딩 작업은 리서치보다 진짜로 병렬화할 수 있는 부분이 적고, LLM 에이전트가 다른 에이전트를 실시간으로 조율하고 일을 넘기는 데는 아직 능숙하지 않다는 내용이에요.
컨텍스트 엔지니어링 – AI가 읽는 양을 설계하는 방법리드 에이전트에게 일 넘기는 법을 가르친다
멀티 에이전트 시스템을 처음 돌렸을 때의 동작도 원문에 그대로 적혀 있습니다. 단순한 질의에 서브에이전트를 50개 만들거나, 있지도 않은 자료를 찾아 웹을 계속 뒤지는 식이었다고 해요. 에이전트는 프롬프트로 움직이니 프롬프트를 다듬는 일이 주된 수단이었고, 거기서 배운 원칙이 원문에 실려 있는데, 세어 보면 여덟 가지입니다.
그중 하나가 위임입니다. 리드 에이전트가 질의를 하위 과제로 나눠 서브에이전트에게 설명하는데, 각 서브에이전트에게는 목표, 출력 형식, 쓸 도구와 자료에 대한 안내, 분명한 작업 경계가 필요하다고 해요. 처음에는 짧은 지시를 허용했는데, 그러면 서브에이전트가 과제를 다르게 해석하거나 다른 에이전트와 똑같은 검색을 했다고 적혀 있습니다.
들이는 노력을 질의에 맞추는 기준도 프롬프트에 넣었습니다. 에이전트가 과제마다 적절한 노력의 크기를 판단하기 어려워한다는 것이 원문이 든 이유예요.
나머지 원칙을 줄여 옮기면 이렇습니다.
- 시스템과 똑같은 프롬프트와 도구로 시뮬레이션을 만들어 에이전트가 일하는 과정을 단계별로 지켜본다
- 도구마다 뚜렷한 목적과 분명한 설명을 둔다. 쓸 수 있는 도구를 먼저 다 살펴보고, 범용 도구보다 전용 도구를 고르라는 지침을 줬다
- 프롬프트와 실패 양상을 Claude 4 모델에게 주고 원인 진단과 개선안을 받는다
- 짧고 넓은 검색어로 시작해서 점점 좁힌다
- 확장 사고로 리드는 계획을 세우고, 서브에이전트는 도구 결과를 받은 뒤 품질과 빈틈을 따진다
- 리드는 서브에이전트 3~5개를 병렬로 띄우고, 서브에이전트는 도구를 3개 이상 병렬로 쓴다
도구 설명을 고치는 에이전트 얘기는 수치가 붙어 있습니다. 결함이 있는 MCP 도구를 주면 직접 써 보고 설명을 다시 쓰는 에이전트를 만들었는데, 새 설명을 쓴 이후의 에이전트들은 작업 완료 시간이 40% 줄었다고 해요. 앞에서 본 시간 단축 최대 90%는 마지막 항목의 두 가지 병렬화에서 나온 숫자입니다.
원문은 이 프롬프트 전략을 엄격한 규칙보다 좋은 휴리스틱을 심는 쪽이라고 정리합니다. 숙련된 사람이 조사하는 방식을 살펴서 프롬프트에 옮겼고, 에이전트가 통제를 벗어나지 않도록 명시적인 가드레일도 함께 뒀다고 해요.
정해진 경로가 없는 시스템을 평가하는 방법
기존 평가는 같은 입력이면 같은 단계를 밟는다고 가정하는 경우가 많습니다. 멀티 에이전트 시스템은 출발점이 같아도 서로 다른 경로로 목표에 닿을 수 있어서, 원문은 미리 정한 단계를 따랐는지보다 옳은 결과에 닿았는지와 과정이 합리적이었는지를 보는 평가가 필요하다고 봤어요.
- 실제 사용 패턴을 대표하는 질의 약 20개로 바로 시작했습니다. 개발 초기에는 변경 하나의 효과가 커서 적은 수로도 차이가 보인다는 설명이 붙어 있어요.
- 출력은 LLM이 채점했습니다. 기준은 사실 정확성, 인용 정확성, 완결성, 출처 품질, 도구 효율이고, 프롬프트 하나로 LLM을 한 번 불러 0.0~1.0 점수와 통과 여부를 내게 한 방식이 가장 일관됐다고 합니다.
- 사람이 직접 써 보는 평가를 같이 했습니다. 초기 에이전트가 권위 있는 자료보다 검색 최적화된 콘텐츠 팜을 고른다는 점을 사람이 찾아냈고, 프롬프트에 출처 품질 기준을 넣어 다뤘습니다.
오래 도는 에이전트를 운영하면서 다룬 것
운영 대목은 멀티 에이전트 시스템이 상태를 가진 채 오래 도는 프로그램이라는 점에서 출발합니다. 에이전트는 여러 도구 호출에 걸쳐 상태를 유지하고, 오류가 나면 처음부터 다시 돌리는 비용이 큽니다.
| 다룬 것 | 원문에 적힌 방법 |
|---|---|
| 오류 | 오류가 난 지점부터 이어서 재개한다. 재시도 로직과 주기적인 체크포인트를 두고, 도구가 실패하면 에이전트에게 알려 스스로 맞추게 한다 |
| 디버깅 | 프로덕션 트레이싱을 넣었다. 개별 대화 내용은 보지 않고 에이전트의 결정 패턴과 상호작용 구조를 본다 |
| 배포 | 옛 버전과 새 버전을 함께 띄워 두고 트래픽을 점진적으로 옮기는 레인보우 배포를 쓴다 |
| 실행 방식 | 리드가 서브에이전트 한 묶음이 끝나기를 기다렸다가 다음으로 넘어가는 동기 실행이다 |
동기 실행은 조율을 단순하게 해 주는 대신 병목이 생긴다고 원문이 직접 밝혔습니다. 리드 에이전트가 도는 중인 서브에이전트의 방향을 바꿀 수 없고, 서브에이전트 하나가 끝나기를 기다리는 동안 시스템이 멈춰 있을 수 있어요. 비동기 실행은 결과 조율, 상태 일관성, 오류 전파라는 과제가 따른다고 함께 적었습니다.
“the last mile often becomes most of the journey” (Anthropic, 원문 결론)
이 사례에서 가져갈 만한 것
여기부터는 원문의 분류가 아니고 제가 읽으면서 추린 것입니다.
- 일을 넘길 때 적을 네 가지. 목표, 출력 형식, 쓸 도구와 자료, 작업 경계입니다. 에이전트 하나를 부를 때도 그대로 쓸 수 있는 목록이에요.
- 일의 크기와 에이전트 수를 미리 짝지어 둔다. 판단을 에이전트에게만 맡겨 두지 않고 프롬프트에 기준을 적어 줬다는 점이 눈에 들어왔습니다.
- 평가는 작게 바로 시작한다. 질의 약 20개로 시작했다는 대목은 규모가 작은 프로젝트에도 옮길 수 있는 기준입니다.
- 나누기 전에 병렬로 쪼개지는 일인지 본다. 원문이 스스로 밝힌 조건이고, 토큰 배수가 그 옆에 적혀 있습니다.
제 미니앱 제작에서는 조사가 아닌 검증 역할을 나눠 씁니다. 기획 단계에 검증 에이전트 셋을 한 번에 병렬로 돌리고, 코드를 완성한 뒤 셋을 병렬로 한 번 돌리도록 규칙 파일에 정해 뒀어요. 정의 파일과 호출 시점은 서브에이전트 글에 있고, 판정을 기록으로 남기는 부분은 AI 하네스 글에서 다뤘습니다.
참고한 공식 자료
Anthropic 엔지니어링 블로그의 리서치 시스템 글과 Claude Code 서브에이전트 문서를 기준으로 썼습니다. 수치는 2025년 6월 13일 공개된 글에 적힌 것이고, 지금의 제품 동작과는 다를 수 있으니 원문을 확인하세요.
멀티 에이전트 자주 묻는 질문
멀티 에이전트 시스템이 뭔가요?
Anthropic의 글은 여러 에이전트가 함께 일하는 시스템이라고 설명합니다. 여기서 에이전트는 도구를 반복해서 스스로 쓰는 LLM을 가리킵니다. 리서치 시스템에서는 리드 에이전트 하나가 조사를 계획하고, 동시에 검색하는 서브에이전트를 만들어 일을 나눕니다.
멀티 에이전트는 단일 에이전트보다 얼마나 나은가요?
Anthropic 내부 리서치 평가에서 Claude Opus 4 리드와 Claude Sonnet 4 서브에이전트 구성이 단일 Claude Opus 4보다 90.2% 앞섰다고 합니다. 같은 글은 여러 방향을 동시에 좇는 넓은 질의에서 특히 강하다고 적었습니다.
멀티 에이전트가 맞지 않는 일도 있나요?
원문은 모든 에이전트가 같은 컨텍스트를 공유해야 하거나 에이전트 사이 의존이 많은 영역은 지금은 잘 맞지 않는다고 밝혔습니다. Anthropic 데이터에서 일반 채팅의 약 15배 토큰을 쓰기 때문에, 그 비용을 감당할 만큼 가치가 큰 작업이어야 한다는 조건도 붙어 있습니다.
글에 나온 규칙 파일과 에이전트는 Claude Code에서 쓰는 방식이고, 공식 안내는 Claude Code 공식 문서에 있습니다.
이 글은 직접 만들고 운영하며 남긴 기록입니다. 적힌 수치는 작성 시점의 제 계정 기준이며, 같은 결과나 수익을 보장하지 않습니다.
2 Comments