멀티 에이전트 오케스트레이션(Multi-Agent Orchestration) 뜻과 설계

🤔 에이전트 하나에 다 맡겼더니 대화가 넘칠 때

경쟁사 다섯 곳의 요금제를 조사해 비교표를 만들어 달라고 에이전트 하나에 맡기면, 첫 회사의 요금 페이지를 읽고 두 번째 회사의 도움말을 읽는 동안 대화가 빠르게 길어집니다. 다섯 번째 회사에 이를 즈음에는 앞에서 읽은 페이지 내용이 대화 대부분을 차지하고, 정작 비교에 필요한 숫자는 그 사이에 흩어져 있습니다.

일을 나눠 여러 에이전트에게 맡기면 이 문제가 줄어듭니다. 회사마다 작업자 에이전트를 하나씩 붙이고, 각자 조사한 결과를 요약해 돌려받아 메인 에이전트가 표로 합치는 방식입니다. 이 구조를 멀티 에이전트 오케스트레이션이라고 부릅니다. 이 편에서는 일을 나눠 맡기고 결과를 거둬들이는 원리를 도구와 상관없이 정리합니다.

🔑 멀티 에이전트 오케스트레이션의 정의

멀티 에이전트 오케스트레이션은 메인 에이전트가 일을 나눠 작업자 에이전트에게 맡기고 돌아온 결과를 모아 합치는 구조입니다.

오케스트레이션(orchestration)은 여러 연주자를 지휘해 하나의 곡을 만드는 일에서 온 말입니다. 앤트로픽은 이 구조를 오케스트레이터-워커(orchestrator-workers) 패턴이라 부르며, 가운데의 모델이 일을 쪼개 작업자에게 맡기고 결과를 합친다고 설명합니다. 여기서 중요한 조건이 하나 붙습니다. 작은 일의 목록이 미리 정해져 있지 않고, 메인 에이전트가 들어온 요청을 보고 그때그때 정한다는 점입니다. 쪼개는 방법까지 코드로 고정해 두면 AI 에이전트 뜻에서 본 워크플로에 가깝습니다.

공사 현장으로 보면 이해가 빠릅니다. 반장은 도면을 보고 오늘 할 일을 구역별로 나눠 작업자에게 맡기고, 작업자는 자기 구역만 끝내고 무엇을 했는지 보고합니다. 반장은 보고를 모아 전체가 맞게 끝났는지 확인합니다. 작업자는 다른 구역의 사정을 몰라도 되고, 반장은 작업자가 무슨 공구를 몇 번 꺼냈는지까지 들을 필요가 없습니다.

🧩 일을 맡기는 방식 세 가지

작업자에게 일을 넘기는 방식은 도구와 프레임워크마다 이름이 다르지만 크게 세 가지로 나뉩니다. 2026년 9월 28일 공식 문서 기준입니다.

실무에서 가장 흔한 것은 첫 번째입니다. 클로드 코드 문서는 서브에이전트가 자기 컨텍스트에서 일하고 요약만 돌려준다고 설명하면서, 다시 볼 일 없는 검색 결과나 로그가 메인 대화를 채울 때 쓰라고 권합니다. 에이전트 팀은 팀원끼리 발견한 것을 나누고 서로 반박해야 하는 일에 맞지만, 팀원 하나하나가 별도 인스턴스라 토큰을 더 씁니다. 2026년 9월 28일 기준으로 에이전트 팀은 기본으로 꺼져 있는 실험 기능입니다.

📨 작업자에게 넘기는 지시에 적을 네 가지

작업자는 메인이 나눈 대화를 보지 못하고 지시문 한 장만 받습니다. 앤트로픽은 2025년 6월 공개한 멀티 에이전트 리서치 시스템 글에서 초기 버전의 실패를 소개했습니다. "반도체 부족 현상을 조사하라"처럼 짧은 지시를 받은 작업자들이 같은 내용을 겹쳐 조사하거나 엉뚱한 범위를 조사했다는 것입니다. 그래서 작업자마다 네 가지를 적어 주도록 메인을 가르쳤다고 합니다.

• 목표: 무엇을 알아내거나 만들어야 하는지
• 결과 형식: 어떤 모양으로 돌려줘야 하는지
• 쓸 도구와 자료: 어디를 보고 무엇으로 확인하는지
• 작업 경계: 어디까지가 내 일이고 어디부터는 다른 작업자의 일인지

앞의 요금제 조사라면 작업자 하나에게 가는 지시는 이 정도가 됩니다. 가상의 예시입니다.

마지막 줄이 특히 쓸모가 있습니다. 경계를 적지 않으면 작업자가 친절하게 비교와 추천까지 붙여 오고, 메인은 다섯 작업자가 제각각 내린 결론을 다시 정리해야 합니다.

📥 결과를 회수하는 방법

작업자가 돌려주는 것은 과정 전체가 아니라 요약입니다. 메인의 컨텍스트가 가벼워지는 이유가 여기에 있고, 동시에 약점도 여기서 생깁니다. 요약을 거칠 때마다 세부가 빠지기 때문입니다.

앤트로픽은 이 문제를 말 전달 놀이(game of telephone)에 빗대며, 작업자가 결과물을 파일로 저장하고 메인에게는 파일 위치만 알리는 방식을 권합니다. 긴 표나 코드처럼 그대로 보존해야 하는 결과는 파일로, 판단에 필요한 핵심만 메시지로 돌려받는 식입니다.

회수한 결과는 메인이 그대로 합치지 말고 한 번 확인합니다. 작업자의 결과가 서로 어긋나면 어느 쪽이 맞는지 원본을 다시 보게 하고, 형식이 지시와 다르면 돌려보냅니다. 작업자가 만든 결과를 따로 검수하는 방법은 이 코스의 에이전트 검수와 평가 편에서 다룹니다.

💰 성과와 비용을 같이 봐야 하는 이유

앤트로픽이 공개한 수치를 보면 멀티 에이전트 구조의 장단점이 함께 드러납니다. 모두 앤트로픽 내부 리서치 평가 기준이고 다른 작업에 그대로 옮길 수는 없습니다.

성과가 오른 이유의 상당 부분이 토큰을 더 많이 썼기 때문이라는 뜻입니다. 클로드 코드 문서도 에이전트 팀이 팀원들이 계획 단계에 있을 때 일반 세션의 약 7배까지 토큰을 쓴다고 적고 있습니다. 결과의 가치가 그 비용을 넘는 일에만 나누는 것이 맞습니다.

⚖️ 나눌 일과 나누지 않을 일

앤트로픽은 멀티 에이전트 구조가 병렬로 나눌 수 있는 일, 한 컨텍스트에 다 담기 어려운 양의 정보를 다루는 일, 여러 복잡한 도구를 오가는 일에 강하다고 설명합니다. 반대로 모든 에이전트가 같은 맥락을 공유해야 하거나 에이전트끼리 의존이 많은 일에는 지금은 맞지 않다고 적고, 코딩 작업은 대부분 조사보다 병렬로 나눌 부분이 적다고 덧붙였습니다.

일의 크기에 맞춰 작업자 수를 정하라는 안내도 있습니다. 앤트로픽은 간단한 사실 확인은 에이전트 하나가 도구를 3번에서 10번 부르는 것으로 충분하고, 복잡한 조사에서만 작업자를 10개 넘게 쓴다고 설명합니다. 앤트로픽 프롬프트 안내서는 오퍼스 4.6이 더 단순한 방법으로 충분한 상황에서도 서브에이전트를 띄우는 경향이 있다고 적고 있어서, 나눌 조건을 지시에 적어 두는 편이 낫습니다. 나누고 모이는 순서를 그림으로 설계하는 방법은 AI 그래프 엔지니어링에 있습니다.

⚠️ 여러 에이전트를 돌릴 때 자주 하는 실수

• 경계를 적지 않습니다: 작업자 둘이 같은 자료를 겹쳐 조사하거나 둘 다 빠뜨립니다
• 같은 파일을 동시에 고치게 둡니다: 작업자가 서로의 변경을 덮어씁니다. 코드 작업이라면 작업자마다 git worktree(같은 저장소를 폴더별로 따로 꺼내 쓰는 기능)를 나눠 주는 방식이 쓰입니다
• 작업자의 보고를 그대로 믿습니다: 요약은 세부를 잃고, 작업자가 끝났다고 한 일이 실제로는 절반만 된 경우도 있습니다
• 작은 일까지 나눕니다: 지시를 쓰고 결과를 합치는 비용이 일 자체보다 커집니다

❓ 자주 묻는 질문

서브에이전트와 에이전트 팀은 무엇이 다른가요?

서브에이전트는 메인이 부르면 일하고 요약만 돌려주는 작업자이고, 에이전트 팀은 팀원들이 각자 일하면서 서로 직접 메시지를 주고받는 구조입니다. 클로드 코드 문서는 빨리 끝내고 보고하는 작업자가 필요하면 서브에이전트를, 팀원끼리 발견을 나누고 반박하며 조율해야 하면 에이전트 팀을 쓰라고 안내합니다. 비용은 에이전트 팀 쪽이 큽니다.

작업자 에이전트가 또 다른 작업자를 부를 수 있나요?

도구마다 다릅니다. 2026년 9월 28일 클로드 코드 문서 기준으로 서브에이전트는 기본값에서 메인 대화 아래 세 단계까지 서브에이전트를 더 띄울 수 있고, 에이전트 팀의 팀원은 자기 팀을 따로 만들 수 없습니다. 단계가 깊어질수록 요약이 여러 번 겹쳐 세부가 빠지므로 한두 단계에서 끝내는 편이 관리하기 쉽습니다.

메인과 작업자에 다른 모델을 써도 되나요?

됩니다. 앤트로픽 리서치 시스템도 리더는 오퍼스 4, 작업자는 소네트 4로 나눴습니다. 계획과 종합처럼 판단이 많은 일은 상위 모델에, 정해진 범위를 조사하는 일은 빠르고 싼 모델에 맡기는 구성이 흔합니다.

작업자는 몇 개로 시작하면 되나요?

서로 겹치지 않게 나눌 수 있는 만큼만 만듭니다. 클로드 코드 문서는 에이전트 팀을 대부분의 경우 팀원 3명에서 5명으로 시작하라고 권합니다. 작업자를 늘릴수록 지시와 합치는 비용도 함께 늘어납니다.

📋 3줄 요약

1. 멀티 에이전트 오케스트레이션은 메인 에이전트가 일을 나눠 작업자 에이전트에게 맡기고 각자 따로 된 컨텍스트에서 돌아온 결과를 모아 합치는 구조입니다.

2. 앤트로픽의 리서치 시스템에서 이 구조는 단일 에이전트보다 내부 평가 점수가 90.2% 높았지만 일반 채팅의 약 15배에 이르는 토큰을 썼습니다.

3. 회사별 조사처럼 서로의 결과 없이 병렬로 나눌 수 있는 일에 맞고 맥락을 공유해야 하거나 의존이 많은 일은 에이전트 하나가 맡는 편이 낫습니다.

📚 참고 자료

• 앤트로픽, How we built our multi-agent research system (2025-06-13): https://www.anthropic.com/engineering/multi-agent-research-system
• 앤트로픽, Building effective agents: https://www.anthropic.com/engineering/building-effective-agents
• 클로드 코드 문서, Subagents: https://code.claude.com/docs/en/sub-agents
• 클로드 코드 문서, Agent teams: https://code.claude.com/docs/en/agent-teams
• OpenAI Agents SDK 문서, Multi-agent orchestration: https://openai.github.io/openai-agents-python/multi_agent/