멀티 에이전트, 언제 나누고 어떻게 맡길까

에이전트 하나로 버거운 일이 생기면 가장 먼저 떠오르는 방법은 에이전트를 더 붙이는 것입니다. 조사하는 에이전트, 쓰는 에이전트, 검토하는 에이전트. 그럴듯해 보이지만, 지난 1년 동안 이 방식을 실제로 운영한 팀들의 기록을 읽어 보면 결론이 꽤 조심스럽습니다.

이 글에서는 Anthropic, Cognition, LangChain 이 공개한 경험과 멀티 에이전트의 실패를 분석한 연구를 바탕으로 원칙 여섯 가지를 정리했습니다. 뒤에서는 endue 가 이 원칙에 맞춰 에이전트를 어떻게 구성하는지 설명합니다.

1. 먼저 한 에이전트로 해 본다

Anthropic 은 올해 1월 글에서 멀티 에이전트 구성이 단일 에이전트보다 보통 토큰을 3~10배 더 쓴다고 밝혔습니다. 여러 달에 걸쳐 복잡한 멀티 에이전트 구조를 만든 팀이 결국 단일 에이전트의 프롬프트만 다듬어 같은 결과를 얻은 사례도 여러 번 봤다고 적었습니다. 권고는 단순합니다. 가장 단순한 방법으로 시작하고, 근거가 생길 때만 복잡도를 더하라는 것입니다.

반대쪽 사례도 있습니다. Anthropic 의 리서치 기능은 리드 에이전트 하나가 계획을 세우고 하위 에이전트들이 나란히 조사하는 구조입니다. 내부 리서치 평가에서 단일 에이전트보다 90.2% 높은 점수를 냈지만, 일반 채팅보다 토큰을 15배가량 썼습니다. 성능 차이의 80%가 사용한 토큰 양으로 설명됐다는 분석도 함께 나왔습니다. 멀티 에이전트의 이득은 상당 부분 더 많은 계산을 나란히 쓸 수 있다는 데서 옵니다. 그만한 값을 치를 일인지 먼저 따져야 하는 이유입니다.

2. 나눌 이유는 세 가지다

Anthropic 이 정리한, 여러 에이전트가 하나보다 꾸준히 나았던 경우는 셋입니다.

• 맥락 보호. 한 하위 작업에서 쌓인 정보가 다음 작업을 방해할 때. 긴 검색 결과나 로그를 다른 에이전트가 걸러 핵심만 넘기면 본 작업의 맥락이 깨끗하게 유지됩니다.
• 병렬화. 서로 독립된 갈래로 나눠 동시에 돌릴 수 있을 때. 넓은 정보를 훑는 조사가 대표적입니다.
• 전문화. 필요한 도구나 지침이 서로 부딪칠 때. 한 에이전트에 모두 넣으면 도구 선택이 흐려집니다.

셋 중 어디에도 해당하지 않는다면 에이전트를 늘릴 근거가 약합니다.

3. 읽기는 나누고, 쓰기는 한 곳에서

Cognition 은 작년 6월 Don’t Build Multi-Agents 에서 Flappy Bird 예시를 들었습니다. 게임 클론을 두 하위 에이전트에게 나눠 맡겼더니 한쪽은 슈퍼 마리오풍 배경을, 다른 쪽은 게임과 어울리지 않는 새를 만들었습니다. 행동에는 말하지 않은 결정이 담기고, 서로 다른 가정에서 나온 결정은 부딪힌다는 것이 요지였습니다.

LangChain 은 두 회사의 입장이 어디서 맞물리는지 짚었습니다. 읽기는 쓰기보다 훨씬 쉽게 나뉩니다. Anthropic 의 리서치 시스템도 조사는 여럿이 나눠 하지만 최종 보고서는 에이전트 하나가 씁니다.

올해 4월 Cognition 은 입장을 한 단계 조정했습니다. 실제로 잘 돌아가는 구성은 여러 에이전트가 판단과 정보를 보태되 쓰기는 한 줄기로 유지하는 형태라는 것입니다. 코드 리뷰를 맡는 Devin Review 는 PR 하나당 평균 2개의 버그를 찾고, 그중 58%가량이 심각한 문제라고 합니다. 여러 작성자가 동시에 쓰는 구조는 여전히 잘 안 된다고 덧붙였습니다.

4. 맡길 때는 제대로 넘긴다

Anthropic 은 초기에 “X 를 조사해” 같은 짧은 지시만 주었더니 하위 에이전트들이 같은 일을 중복하거나 엉뚱한 방향으로 갔다고 합니다. 그 뒤로는 하위 에이전트마다 목표, 결과 형식, 써야 할 도구와 출처, 맡은 범위의 경계를 적어 주었습니다. Cognition 은 한 걸음 더 나가 메시지 몇 줄 대신 작업 기록 전체를 공유하라고 권합니다.

넘기는 쪽이 한 번 더 수고하면 받는 쪽의 추측이 줄어듭니다.

5. 협업 방식을 고르고, 검증은 따로 둔다

Anthropic 은 올해 4월 협업 패턴 다섯 가지를 정리했습니다.

패턴	잘 맞는 일	주의할 점
생성자·검증자	기준이 분명하고 품질이 중요한 결과물	검증 기준을 정하지 않으면 루프가 헛돈다
오케스트레이터·하위 에이전트	경계가 분명한 하위 작업으로 나뉘는 일	오케스트레이터가 정보 병목이 된다
에이전트 팀	서로 독립적이고 오래 걸리는 병렬 작업	중간 발견을 나누기 어렵고 완료 판정이 까다롭다
메시지 버스	이벤트로 흐르는 파이프라인, 계속 늘어나는 에이전트	연쇄 이벤트를 추적하기 어렵다
공유 상태	서로의 발견을 이어받아 쌓는 협업	종료 조건이 없으면 끝없이 맴돈다

기본값으로는 오케스트레이터·하위 에이전트를 권합니다. 가장 넓은 범위의 문제를 가장 적은 조율 비용으로 다룰 수 있고, 한계가 보이는 지점에서 다른 패턴으로 옮겨 가면 됩니다.

검증은 별도 역할로 두는 편이 좋습니다. UC 버클리 연구진이 멀티 에이전트 실행 기록 1,642건을 분석한 MAST 연구를 보면 실패의 44.2%가 시스템 설계와 명세 문제, 32.3%가 에이전트 사이의 어긋남, 23.5%가 검증 실패였습니다. 흔한 실패는 같은 단계를 반복하기, 추론과 다른 행동 하기, 끝났는지 알아채지 못하기, 모호한데 묻지 않고 넘어가기였습니다. 역할 명세만 고쳐도 같은 모델과 같은 프롬프트에서 성공률이 9.4% 올랐습니다. 모델을 바꾸기 전에 구조부터 볼 일입니다.

6. 사람이 보고, 멈추고, 승인할 수 있어야 한다

에이전트는 여러 턴에 걸쳐 상태를 이어 가기 때문에 작은 오류가 뒤로 갈수록 커집니다. Anthropic 도 운영 단계에서는 실행 추적과 관찰이 필수라고 강조합니다. 에이전트가 무엇을 하고 있는지 보이고, 필요하면 멈추거나 방향을 틀 수 있어야 하며, 되돌리기 어려운 행동 앞에서는 사람이 확인해야 합니다.

endue 는 이렇게 구성합니다

endue 는 위 원칙을 제품 구조로 옮겼습니다.

에이전트마다 정체성이 따로 있습니다. 이름과 @핸들, 시스템 프롬프트와 리비전, 기본 모델, 스킬과 커넥터 연결, 메모리가 에이전트 단위로 나뉩니다. 연결과 메모리도 에이전트마다 따로 붙습니다. 그래서 전문화가 필요할 때 도구와 지침을 한 에이전트에 몰아넣지 않고 역할별 에이전트를 만들 수 있습니다. 조사에는 빠르고 저렴한 모델을, 최종 작성에는 가장 강한 모델을 고르는 식으로 역할마다 모델을 달리 둘 수도 있습니다.

일반 대화는 한 에이전트와 합니다. 에이전트는 서로의 대화를 읽지 않습니다. 두 번째 에이전트를 같은 문제에 붙이려면 그 에이전트와 새 대화를 열고, 맥락을 함께 써야 할 때는 두 대화를 같은 프로젝트에 넣습니다. 프로젝트가 공유 작업 기록 역할을 합니다. 맥락이 뒤섞이지 않도록 막는 기본값입니다.

여럿이 함께 하는 일은 스페이스에서 합니다. 스페이스에 일을 맡기면 대화 담당 에이전트가 단계를 나누고, 각 단계는 맞는 에이전트가 이어받습니다. @ 로 특정 에이전트를 지목할 수도 있습니다. 업무는 접수됨, 진행 중, 완료로 흘러가고, 끝난 결과는 버전으로 남아 새 결과가 이전 버전을 덮지 않습니다. 한 에이전트가 판을 나누고 결과를 버전으로 쌓는 구조라서 앞에서 본 오케스트레이터·하위 에이전트 패턴, 그리고 쓰기를 한 곳에 모으는 원칙과 맞닿아 있습니다.

모든 에이전트의 일이 한 화면에 보입니다. 활동 보드는 모든 에이전트의 대화를 상태별(Waiting·Active·Failed·Done)로 묶어 보여 줍니다. 진행 중인 실행은 멈출 수 있고, 실패한 대화는 다시 시도할 수 있습니다. 실행 도중에 방향을 바꾸고 싶으면 스티어링으로 지시를 끼워 넣습니다.

모호하면 묻고, 위험하면 멈춥니다. 에이전트는 판단이 서지 않을 때 선택지나 자유 입력으로 질문하고 답을 기다립니다. 메시지 발송이나 삭제처럼 되돌리기 어려운 행동은 실행 전에 승인을 받습니다. 이 승인은 에이전트별로도 계정 전체로도 끌 수 없고, 사람이 지켜보지 않는 실행에서는 기다리는 대신 거절됩니다. MAST 연구가 짚은 “묻지 않고 넘어가는” 실패와 “확인 없이 끝나는” 실패를 제품 차원에서 막는 장치입니다.

일은 여러 입구로 들어옵니다. 정해진 시간에 도는 루틴, Slack·Discord·카카오톡·네이버 톡톡·WhatsApp 같은 채널, 우리 시스템에서 직접 부르는 에이전트 API 로 같은 에이전트에게 일을 줄 수 있습니다.

예시: 조사, 작성, 검토를 나누는 팀

주간 시장 동향 보고서를 만든다고 해 봅시다.

1. 조사 에이전트에게 웹 검색 스킬과 빠른 모델을 줍니다. 여러 출처를 넓게 훑는 읽기 작업이라 나누기 좋은 영역입니다.
2. 작성 에이전트에게는 가장 강한 모델을 주고, 보고서를 쓰는 역할은 이 에이전트 하나로 정합니다.
3. 검토 에이전트는 작성 에이전트와 다른 모델로 두고, 출처와 수치를 확인하는 기준을 시스템 프롬프트에 적어 둡니다.
4. 셋을 한 스페이스에 넣고 일을 맡깁니다. 결과는 버전으로 쌓이니, 검토 뒤 고친 원고도 이전 버전을 지우지 않습니다.
5. 완성본을 밖으로 보내는 일은 사람이 결과를 확인한 뒤 대화에서 맡깁니다. 발송은 승인을 거쳐야 실행됩니다.

정리하며

• 한 에이전트로 먼저 해 보고, 근거가 생기면 나눈다.
• 나눌 이유는 맥락 보호, 병렬화, 전문화 중 하나여야 한다.
• 읽기는 여럿이, 쓰기는 한 곳에서.
• 맡길 때는 목표, 형식, 도구, 경계를 적어 넘긴다.
• 검증은 따로 두고, 기준을 먼저 정한다.
• 사람이 보고, 멈추고, 승인할 수 있게 만든다.

참고 자료

• Anthropic, When to use multi-agent systems (and when not to) (2026년 1월)
• Anthropic, Multi-agent coordination patterns: Five approaches and when to use them (2026년 4월)
• Anthropic, How we built our multi-agent research system (2025년 6월)
• Cognition, Don’t Build Multi-Agents (2025년 6월), Multi-Agents: What’s Actually Working (2026년 4월)
• LangChain, How and when to build multi-agent systems (2025년 6월)
• Cemri 외, Why Do Multi-Agent LLM Systems Fail? (NeurIPS 2025)