단일 에이전트(single agent) — 하나의 모델, 시스템 프롬프트 (system prompt), 몇 가지 도구 (tools), 그리고 루프 (loop) — 만으로도 놀라울 정도로 멀리 갈 수 있습니다. 하지만 대부분의 사람들은 여기서 멈추곤 합니다. 데모용으로는 작동하지만, 작업이 동시에 한 가지 이상의 추론 (reasoning)을 필요로 하는 순간 무너져 버리기 때문입니다.

멀티 에이전트 오케스트레이션 (Multi-agent orchestration)은 단일 에이전트보다 단순히 유행을 따르는 업그레이드가 아닙니다. 이는 작업이 서로 다른 컨텍스트 (context), 서로 다른 도구 (tools), 또는 진정으로 다른 역할 (roles)로부터 이득을 얻을 수 있는 하위 작업 (sub-tasks)들로 자연스럽게 분해될 때 선택하게 되는 방식입니다. 이 포스트에서는 이러한 전환이 정당화되는 시점, 실제 프로덕션 (production)에서 사용되는 오케스트레이션 패턴 (orchestration patterns), 그리고 코디네이터 (coordinator)가 워커 에이전트 (worker agents)에게 작업을 위임하는 작은 작동 예제를 다룹니다.

단일 에이전트가 충분하지 않게 되는 이유

단일 에이전트의 컨텍스트 윈도우 (context window)와 도구 목록은 추가되는 기능이 늘어날 때마다 함께 커집니다. 이 과정에서 세 가지 실패 모드 (failure modes)가 나타납니다:

• 컨텍스트 오염 (Context pollution) — 연구 작업의 중간 메모 (scratch work)가 관련 없는 코딩 하위 작업의 추론 (reasoning) 과정에 스며들어, 두 작업 모두의 성능을 저하시킵니다.
• 도구 과부하 (Tool overload) — 하나의 시스템 프롬프트 (system prompt)에 포함된 도구의 수가 일정 수준을 넘어서면 선택 정확도가 떨어집니다. 모델은 도구를 실제로 잘 사용하는 것보다 어떤 도구를 선택할지 결정하는 데 더 많은 추론 (reasoning)을 소비하게 됩니다.
• 관심사의 분리 부재 (No separation of concerns) — 단일 에이전트는 "신중한 계획가 (careful planner)"가 되는 것과 "빠르고 좁은 범위의 실행가 (fast, narrow executor)"가 되는 것을 동시에 두 가지 서로 다른 행동 모드 (behavioral modes)로 유지하기 어렵습니다.

오케스트레이션 (Orchestration)은 하나의 크고 모호한 작업을 코디네이터 (coordinator)와 전문화된 워커 (specialized workers)로 나눔으로써 이 문제를 해결합니다. 각 워커는 좁은 역할, 고유한 컨텍스트, 그리고 실제로 필요한 도구만을 가집니다.

실제 사례에서 나타나는 패턴들

단 하나의 "멀티 에이전트 아키텍처 (multi-agent architecture)"는 존재하지 않습니다. 몇 가지 구체적인 패턴들이 대부분의 실제 시스템을 포괄합니다:

• 순차적 (Sequential, 파이프라인) — 에이전트 A의 출력이 에이전트 B로 전달되고, 다시 에이전트 C로 전달됩니다. 조사(research) → 초안 작성(draft) → 검토(review)와 같은 선형적인 워크플로우(workflow)에 적합합니다.
• 병렬적 (Concurrent, fan-out/fan-in) — 코디네이터(coordinator)가 동일하거나 관련된 하위 작업(sub-tasks)을 여러 에이전트에게 병렬로 배정(dispatch)한 다음, 결과를 병합(merge)합니다. 다섯 개의 문서를 한 번에 요약하는 것과 같이 독립적인 하위 작업에 적합합니다.
• 핸드오프 (Handoff) — 작업 도중 한 에이전트가 다른 에이전트가 더 적합하다고 판단하면 제어권(및 컨텍스트(context))을 해당 에이전트에게 넘깁니다. 지원 봇이 전문 에이전트에게 업무를 넘기는 것과 같은 분류(triage) 스타일의 시스템에 적합합니다.
• 계층적 (Hierarchical, 코디네이터/워커) — 중앙 플래너(central planner)가 작업을 분해하여 전문화된 워커(worker)들에게 위임한 다음, 그들의 출력을 최종 답변으로 조립합니다. 이는 가장 일반적인 프로덕션(production) 패턴이며, 아래 예시에서 사용하는 방식입니다.

LangGraph와 같은 프레임워크는 이를 명시적인 상태 그래프(state graph)로 모델링하고, CrewAI는 역할 기반의 "크루(crews)"로 모델링하며, OpenAI Agents SDK와 같은 최소한의 SDK는 하위 에이전트를 부모 에이전트로부터 호출 가능한 도구(tools)로 취급합니다. 프레임워크와 관계없이 근본적인 패턴은 동일하며, 차이점은 기본적으로 제공되는 구조(structure)와 관찰 가능성(observability)의 정도입니다.

작동 예시: Rust에서의 코디네이터 + 워커 에이전트

다음은 최소한의 계층적 설정입니다. 코디네이터 에이전트가 조사 요청을 받고, 이를 하위 작업으로 분해하며, 이를 워커 에이전트들에게 병렬로 배정하고, 결과를 병합합니다.

use futures::future::join_all;
use serde::{Deserialize, Serialize};

...

이 구조에서 주목할 만한 몇 가지 사항은 다음과 같습니다:

• 각 워커(worker)는 코디네이터(coordinator)의 전체 컨텍스트를 공유하는 대신 자신만의 좁은 시스템 프롬프트 (role_prompt)를 가집니다 — 이것이 컨텍스트 오염(context pollution)을 해결하는 실제 메커니즘입니다.
• join_all은 워커들을 순차적(sequentially)이 아닌 병렬적(concurrently)으로 실행합니다 — 독립적인 하위 작업(sub-tasks)의 경우, 이는 단일 에이전트 루프(single-agent loop)에서는 얻을 수 없는 직접적인 지연 시간(latency) 이점입니다.
• 병합(merge) 단계 자체가 문자열 연결(string concatenation)이 아닌 LLM 호출입니다 — 워커의 출력은 종종 중복되거나 조정(reconciling)이 필요하며, 이 단계를 건너뛰는 것은 일관성 없는 최종 답변이 발생하는 흔한 원인이 됩니다.

이 패턴이 한계에 부딪히는 지점

멀티 에이전트 오케스트레이션 (Multi-agent orchestration)은 공짜가 아닙니다. 많은 글들이 이 부분을 생략하곤 하므로, 비용을 명시적으로 언급할 가치가 있습니다:

• 전체적인 토큰 소모 증가 — 계획(planning), 배정(dispatch), 병합(merge) 단계는 모두 실제 작업 위에 추가되는 추가적인 LLM 호출입니다.
• 디버깅의 어려움 — 잘못된 최종 답변은 계획 단계, 특정 워커, 또는 병합 단계 중 어디에서든 발생할 수 있습니다. 이것이 바로 오케스트레이션을 추가했을 때 이 시리즈의 관찰 가능성(observability) 포스트에서 다룬 트레이싱(tracing) 패턴이 더 중요해지는 이유입니다.
• 진정으로 단순하고 선형적인 작업의 경우 조정 오버헤드(coordination overhead)가 이점을 초과할 수 있습니다 — 위에서 언급한 실패 모드(failure modes)에 직면하기 전까지는 좋은 도구를 갖춘 적절한 범위의 단일 에이전트가 여전히 올바른 기본값입니다.

Gartner가 인용한, 진지하게 받아들일 만한 패턴은 다음과 같습니다: 에이전틱 프로젝트의 상당수가 에이전트가 작동하지 않아서가 아니라, 작업에 실제로 필요하기 전에 팀이 오케스트레이션을 시도했고, 조정 오버헤드가 이득보다 컸기 때문에 취소됩니다.

합리적인 의사결정 규칙

기본적으로 단일 에이전트를 사용하십시오. 다음 중 하나라도 해당될 때 오케스트레이션으로 전환하십시오:

• 작업에 진정으로 독립적인 하위 부분들이 있어, 그렇지 않으면 하나의 컨텍스트 창(context window)을 공유하고 오염시킬 경우
• 서로 다른 하위 작업들이 의미 있게 다른 도구 세트(tool sets)나 행동 지침(behavioral instructions)을 필요로 할 경우
• 단순히 조직적인 깔끔함 때문이 아니라, 지연 시간(latency) 문제로 인해 병렬성(parallelism)이 필요한 경우

만약 위의 어떤 경우에도 해당하지 않는다면, 도구 선택 (tool selection) 능력이 뛰어난 잘 설계된 단일 에이전트가 비용과 신뢰성 측면 모두에서 일반적으로 멀티 에이전트 시스템 (multi-agent system)보다 더 나은 성능을 보여줄 것입니다.

다음 단계

이 시리즈의 다음 포스트에서는 비용/제어 (cost/control) 프레임워크로 돌아가서, 폐쇄형 API (closed API)를 호출하는 대신 오픈 웨이트 모델 (open-weight models)을 직접 실행하는 것이 언제 합리적인지, 그리고 단순히 유행을 따르는 대신 어떻게 그 트레이드오프 (tradeoff)를 논리적으로 판단할 수 있는지에 대해 다룹니다.

이 글은 Rust를 사용하여 멀티 프로바이더 AI 게이트웨이 (multi-provider AI gateways)를 구축한 실무 경험을 바탕으로 작성된 AI 인프라 패턴 (AI infrastructure patterns) 시리즈의 일부입니다. 시리즈의 나머지 내용도 계속해서 확인해 보세요.