에이전트의 컨텍스트 윈도우 (context window)가 더 이상 필요하지 않은 검색 결과로 세 번째쯤 가득 찼을 때, 모든 에이전트 빌더들이 결국 하게 되는 생각을 한 번쯤 해보셨을 것입니다: 이것을 여러 개의 에이전트로 나누면 어떨까? 하나는 조사하고, 하나는 쓰고, 하나는 검토하게 하는 것이죠. 아마 그 위에 "매니저 (manager)" 에이전트를 둘 수도 있을 것입니다. 이는 조직도 (org chart)처럼 들리며, 조직도는 마치 아키텍처 (architecture)처럼 느껴집니다.

때로는 그 직감이 정확할 때가 있습니다. 병렬 서브 에이전트 (subagents)를 갖춘 오케스트레이터 (orchestrator)로 구축된 Anthropic의 연구 시스템은 내부 평가 (evals)에서 기존의 가장 뛰어난 단일 에이전트 설정을 큰 차이로 능가했습니다. 반대로 때로는 그 직감이 완전히 틀릴 때도 있습니다. Cognition (Devin의 개발 팀)은 "Don't Build Multi-Agents"라는 직설적인 제목의 글을 게시하며, 자신들의 도메인에서는 작업을 나누는 것이 오히려 불일치 (inconsistency)를 제조하는 방식이라고 주장했습니다. 두 팀 모두 옳습니다. 왜냐하면 그들은 서로 다른 문제를 해결하고 있기 때문입니다.

이 글은 이 두 입장 사이의 의사결정 프레임워크 (decision framework)입니다. 멀티 에이전트 아키텍처 (multi-agent architectures)가 실제로 무엇을 제공하는지, 그 비용은 무엇인지, 프로덕션 (production)에서 작동하는 오케스트레이션 패턴 (orchestration pattern)은 무엇인지, 그리고 출시 게시물에는 포함되지 않는 실패 모드 (failure modes)는 무엇인지 다룹니다.

멀티 에이전트 시스템이란 실제로 무엇인가

유행어를 걷어내고 보면 간단합니다. **멀티 에이전트 시스템 (multi-agent system)**이란 LLM 기반 에이전트가 다른 LLM 기반 에이전트에게 작업을 위임할 수 있고, 각 에이전트가 **자신만의 컨텍스트 윈도우 (own context window)**에서 실행되며 그 결과를 사용할 수 있는 시스템을 말합니다. 일반적인 프로덕션 형태는 오케스트레이터-워커 (orchestrator–worker) 구조입니다. 리드 에이전트가 목표를 소유하고, 이를 하위 작업 (subtasks)으로 분해하며, 이를 실행하기 위해 서브 에이전트들을 생성하고 (종종 병렬로), 돌아온 결과물들을 합성 (synthesizes)합니다.

그 "자신만의 컨텍스트 윈도우"라는 조항이 핵심입니다. 이것은 의인화된 조직도에 관한 것이 아니라, **컨텍스트 격리 (context isolation)**에 관한 것입니다. 그 외의 모든 것은 여기서 파생됩니다.

이것이 무엇이 아닌지 주목하십시오. 여러분의 코드에서 순차적으로 호출하는 프롬프트 파이프라인 (pipeline of prompts)은 멀티 에이전트 시스템 (multi-agent system)이 아닙니다. 그것은 단지 하나의 프로그램일 뿐이며 (그리고 종종, 그것이 여러분이 대신 구축해야 할 정확한 방식이기도 합니다). 멀티 에이전트라는 라벨은 분해 (decomposition) 자체가 동적일 때 비로소 그 가치를 증명합니다. 즉, 에이전트가 런타임 (runtime)에 무엇을, 누구에게, 어떤 지침과 함께 위임할지를 스스로 결정할 때 말입니다.

팬아웃 (fan-out)이 실제로 제공하는 세 가지 이점

1. 컨텍스트 격리 (Context isolation). 코드베이스를 검색(grep)하거나 20개의 웹 페이지를 읽는 서브 에이전트 (subagent)는 중간 단계의 노이즈 — 원본 파일 내용, 검색 결과, 막다른 길 등 — 에 수천 개의 토큰을 소모합니다. 단일 에이전트 (single-agent) 설계에서는 이 모든 것이 여러분이 가진 하나의 컨텍스트 윈도우 (context window)에 쌓이게 되며, 이는 이후의 모든 단계에 대한 주의력 (attention)을 희석시킵니다. 오케스트레이터-워커 (orchestrator–worker) 설계에서는 이러한 노이즈가 서브 에이전트의 윈도우 내에서 생성되고 소멸합니다. 오케스트레이터는 압축된 결론만을 전달받습니다. 여러분은 결과적으로 사용 가능한 컨텍스트를 워커 (worker)의 수만큼 효과적으로 배가시킨 것입니다.

2. 병렬성 (Parallelism).

Anthropic의 멀티 에이전트 연구 시스템 (multi-agent research system)에 대한 엔지니어링 기술 보고서(engineering write-up)는 이를 수치로 증명했습니다. 오케스트레이터와 병렬 서브 에이전트 (orchestrator-with-parallel-subagents) 아키텍처는 내부 연구 평가 (research eval)에서 단일 에이전트 베이스라인 (single-agent baseline)보다 90.2% 더 높은 성능을 보였으며, 시스템이 수행할 수 있는 관련된 사고 및 읽기 (thinking-and-reading)의 양인 토큰 사용량 (token usage)이 성능 차이의 대부분을 설명한다는 것을 발견했습니다. 팬아웃 (Fan-out)은 근본적으로 단일 컨텍스트 윈도우 (context window)가 물리적으로 허용하는 것보다 하나의 문제에 더 많은 토큰을 생산적으로 소비하는 방법입니다.

비용 측면

동일한 기술 보고서는 비용에 대해 매우 솔직합니다. 데이터에 따르면, 단일 에이전트는 채팅 상호작용 (chat interaction)보다 대략 4배 더 많은 토큰을 사용했으며, 멀티 에이전트 시스템 (multi-agent systems)은 대략 15배를 사용했습니다. 이것이 진입 비용입니다. 멀티 에이전트 아키텍처는 작업의 가치가 이 비용을 상회할 때에만 경제적 타당성을 갖습니다.

더 미묘한 비용은 **조정 (coordination)**입니다. 오케스트레이터는 _작업 설명 (task descriptions)_을 통해 서브 에이전트 (subagents)와 통신하며, 이 설명에 포함된 모든 모호함은 사용자가 볼 수 없는 컨텍스트 내에서 서브 에이전트가 확신을 가지고 잘못된 일을 수행하게 만드는 원인이 됩니다. Anthropic 시스템의 초기 버전에서는 서브 에이전트들이 서로의 작업을 중복하거나, 범위를 벗어나 방황하거나, 다른 서브 에이전트가 이미 찾아낸 것을 다시 찾는 현상이 발생했습니다. 이는 모델이 약해서가 아니라 위임 지침 (delegation instructions)이 모호했기 때문입니다. 해결책은 화려하지 않은 프롬프트 엔지니어링 (prompt engineering)이었습니다. 각 위임에는 명시적인 목표, 출력 형식, 도구 가이드라인, 그리고 서브 태스크 (subtask)가 종료되는 _경계 (boundaries)_가 필요합니다.

반대 의견 — 그리고 이는 강력한 논거입니다

Cognition의 반론은 진지하게 받아들일 가치가 있습니다. 왜냐하면 멀티 에이전트 설계가 실패하는 정확한 조건을 지목하고 있기 때문입니다: 서브 태스크 (subtasks)가 실제로 독립적이지 않을 때입니다.

그들의 핵심 원칙은 다음과 같습니다: 전체 컨텍스트 (context)와 추적 이력 (trace history)을 공유할 것, 그리고 _행동 (actions)에는 암묵적인 결정이 포함되어 있음_을 기억할 것. 두 개의 서브 에이전트 (subagents)가 작업의 부분적인 관점 (partial views)을 가지고 병렬로 작업할 때, 각 에이전트는 명명 (naming), 구조 (structure), 모호한 요구사항의 해석 (interpretation)과 같은 작은 암묵적 결정들을 내립니다. 이들의 출력이 만날 때, 그러한 결정들은 충돌하게 됩니다. 파트 A와 파트 B가 컴파일되고, 링크되며, 컨벤션 (conventions)에 동의해야 하는 코딩 작업의 경우, 부분적인 컨텍스트를 가진 병렬 에이전트들은 서로 대화해 본 적 없는 두 명의 계약업체로부터 기대할 수 있는 바로 그 불일치 (inconsistency)를 만들어냅니다.

따라서 두 입장에 대한 솔직한 종합은 "Anthropic 대 Cognition"이 아니라, _작업 (task)_의 속성에 관한 것입니다:

• **읽기 중심적이고 (Read-heavy), 분해 가능하며 (decomposable), 너비 우선 방식 (breadth-first)**인 작업 (연구, 감사, 평가 스윕 (evaluation sweeps), 코드베이스 탐색)은 병렬화가 매우 훌륭하게 이루어집니다. 서브 에이전트의 출력은 오케스트레이터 (orchestrator)가 병합할 수 있는 _결과물 (findings)_이며, 이들 사이의 충돌을 해결하는 비용은 저렴합니다.
• 쓰기 중심적이고 (Write-heavy), 상호 의존적이며 (interdependent), 컨벤션이 많은 (convention-laden) 작업 (기능 구현, 리팩토링, 출력이 반드시 일관성을 유지해야 하는 모든 작업)은 팬아웃 (fan-out)에 의해 손해를 봅니다. 이 경우에는 압축 (compaction), 외부 메모리 (external memory), 적시 검색 (just-in-time retrieval) 등을 통해 잘 관리된 컨텍스트를 가진 단일 에이전트가 더 강력한 아키텍처 (architecture)입니다.

유용한 암기법: 읽을 때는 팬아웃(fan out)하고, 쓸 때는 단일 에이전트(stay single)를 유지하라. 이것이 절대적인 규칙은 아니지만 (별도의 워크트리 (worktrees)에서 수행되는 고립된 쓰기 작업은 병렬화가 잘 됩니다), 올바른 기본값이며, 이 규칙을 언제 깨야 하는지를 아는 것이 바로 AI 에이전트 아키텍처에 관한 본격적인 과정에서 실제로 시간을 들여 구축하고자 하는 판단력입니다.

프로덕션에서 살아남는 오케스트레이션 패턴 (orchestration patterns)

만약 당신의 작업이 위의 테스트를 통과한다면, 다음과 같은 형태들이 견고하게 유지될 것입니다:

Orchestrator–worker (기본값). 하나의 리드 에이전트가 작업을 분해(decompose), 위임(delegate), 합성(synthesize)합니다. 워커(worker)들은 서로 통신하지 않으며, 결과는 오케스트레이터(orchestrator)를 통해 흐릅니다. 이는 통신 토폴로지(communication topology)를 메시(mesh)가 아닌 스타(star) 형태로 유지하며, 이는 디버깅 가능 여부를 결정짓는 차이입니다. 에이전트끼리 서로 채팅하는 피어 투 피어(peer-to-peer) 방식의 환상에 저항하십시오. 프로덕션 환경에서 이러한 방식은 대부분 토큰 비용만 높이는 오해를 초래할 뿐입니다.

고립된 스테이지를 가진 파이프라인 (Pipeline with isolated stages). 각 항목은 고정된 스테이지(찾기 → 검증 → 요약)를 거치며, 각 스테이지는 고유하고 깨끗한 컨텍스트(context)를 가진 개별적인 에이전트 호출(agent call)로 이루어집니다. 항목 간의 장벽은 없습니다. 즉, 항목 A가 스테이지 3에 있는 동안 항목 B는 스테이지 1에 있을 수 있습니다. 구조는 당신의 코드 내에서 결정론적 제어 흐름(deterministic control flow)을 따르고, 각 스테이지 내부에서만 LLM의 판단이 이루어집니다. 코드가 구조를 결정하고 에이전트가 그 빈자리를 채우는 이 하이브리드 방식은 이 분야에서 가장 과소평가된 패턴이며, "프레임워크가 정말 필요한가?"라는 대부분의 의문이 해소되는 지점입니다.

적대적 검증 (Adversarial verification). 결과를 확인하기보다는 오히려 *반박(refute)*하도록 N개의 독립적인 에이전트를 생성하고, 살아남은 결과만을 유지합니다. 이는 속도가 아닌 **신뢰도(confidence)**를 위해 사용되는 팬아웃(fan-out) 방식입니다. 독립적인 컨텍스트는 독립적인 실수를 의미하며, 이는 다수결 투표(majority voting)가 작동하는 데 정확히 필요한 요소입니다. 이는 단일 에이전트가 기꺼이 확신하며 내뱉을 수 있는, 그럴듯하지만 틀린 출력(plausible-but-wrong output)에 맞서는 가장 저렴한 방어책입니다.

패턴에 관계없이 그 가치를 스스로 증명하는 세 가지 구현 규칙:

1. 외주 업체에 티켓을 작성하듯 위임하세요. 객관적이고, 출력 형식을 지정하며, 사용할 도구와 범위의 경계를 명확히 하세요. 유능한 사람이라도 명확한 설명을 위해 질문을 던져야 할 상황이라면, 당신의 서브에이전트(subagent)는 대신 조용히 추측해 버릴 것입니다.
2. 산문(prose)이 아닌 데이터를 반환하세요. 서브에이전트는 구조화된 결과(스택이 허용한다면 스키마 검증(schema-validated)된 결과)를 보고해야 합니다. 오케스트레이터(orchestrator)는 결과를 즐기는 독자가 아니라 출력을 소비하는 프로그램이기 때문입니다.
3. 노력과 가치를 일치시키세요. 단순한 조회(lookup) 작업에는 적은 예산을 가진 한 명의 작업자면 충분하지만, 개방형 연구(open-ended research)에는 함대(fleet)가 필요합니다. 단 한 번의 검색으로 답할 수 있는 질문에 대해 10개의 서브에이전트를 생성하는 오케스트레이터는, 사용자가 3명뿐인 마이크로서비스 모노레포(microservices monorepo)의 멀티 에이전트 버전과 같습니다.

아무도 데모에서 보여주지 않는 실패 모드

다음은 모두 데모가 성공한 '이후'에 실제로 발생하는 일들입니다:

• 중복 작업. 오케스트레이터의 작업 설명이 공간을 제대로 분할(partition)하지 못했다면, 두 명의 서브에이전트가 전체 토큰 비용을 지불하며 독립적으로 동일한 사실을 발견하게 됩니다. 명시적으로 분할하세요.
• 오류의 누적. 파이프라인(pipeline)에서 1단계의 환각(hallucination)은 2단계의 신뢰할 수 있는 입력값이 됩니다. 멀티 에이전트 시스템은 단순히 오류를 전파하는 것이 아니라, 오류를 '세탁(launder)'합니다. 최종 합성 단계에 이르면, 잘못된 사실이 세 번이나 "처리"되었다는 자신감을 가지고 전달됩니다. 이것이 검증(verification) 단계가 마지막뿐만 아니라 '초기' 단계에도 포함되어야 하는 이유입니다.
• 전화기 게임(The telephone game). 오케스트레이터를 거치는 모든 단계는 정보를 압축합니다. 세 단계를 거치면 "CI 부하 상황에서 테스트가 간헐적으로 실패함"이라는 정보는 "테스트가 고장 남"으로 변질됩니다. 계층 구조를 얕게 유지하세요. 한 단계의 위임만으로도 거의 모든 실제 사용 사례를 커버할 수 있습니다.
• 부분적 작업의 손실. 10개의 병렬 서브에이전트 중 하나가 8분 만에 충돌합니다. 만약 당신의 하네스(harness)가 나머지 9개를 다시 실행하지 않고 작업을 재개할 수 없다면, 15배의 토큰 비용을 한 번 이상 지불하게 될 것입니다. 체크포인팅(checkpointing)과 재개 가능성(resumability)은 지루한 작업이지만, 이것이 바로 단순한 데모와 실제 시스템을 가르는 차이점입니다.

그리고 위의 모든 문제를 야기하는 메타 실패(meta-failure)는 바로 측정하지 않는 것입니다. 멀티 에이전트 시스템은 LLM으로 구축하는 그 어떤 것보다 조절해야 할 노브(knob)가 많습니다. 분해 입도(decomposition granularity), 워커 수(worker count), 위임 프롬프트(delegation prompts), 합성 전략(synthesis strategy) 등 모든 노브는 조용히 성능이 퇴보할 수 있는 기회입니다. 이러한 시스템을 출시하는 팀들은 평가를 일급 인프라(first-class infrastructure)로 취급합니다. 즉, 대표적인 태스크 세트, 엔드 투 엔드(end-to-end) 결과 점수 산정(루브릭(rubric)이 허용하는 경우 LLM 판사 활용), 그리고 모든 아키텍처 변경 시 재실행을 수행합니다. "내가 시도한 세 개의 쿼리에서는 더 나아 보였다"라는 식의 판단은, 1배의 결과물을 얻기 위해 15배의 토큰 비용을 승인하게 만드는 방식입니다.

의사결정 체크리스트

하나의 에이전트를 여러 개로 나누기 전에, 태스크를 다음 항목에 대입해 보십시오:

정직한 답변이 지루한 쪽인 경우가 얼마나 빈번한지 주목하십시오. 절제된 컨텍스트 관리(압축(compaction), 외부 메모리(external memory), 컨텍스트가 요구할 때만 수행하는 하위 태스크화)를 갖춘 단일 에이전트가 오늘날 구축되는 대부분의 작업에 적합한 아키텍처입니다. 또한, 재시도(retries), 예산(budgets), 관측 가능성(observability)을 갖추어 어떤 변형이든 실제 제품에 연결하는 것은 아키텍처 선택과는 별개의 자체적인 프로덕션 규율(production discipline)입니다.

결론

멀티 에이전트 시스템은 단일 에이전트의 상위 단계가 아닙니다. 이는 컨텍스트 용량과 병렬성(parallelism)을 얻기 위해 토큰과 조정 복잡성(coordination complexity)을 맞바꾸는 특화된 도구입니다. 이러한 트레이드오프(trade-off)는 너비 우선(breadth-first), 읽기 중심(read-heavy), 분해 가능한 작업에는 매우 효과적이지만, 상호 의존적이고 관례(convention)가 중요한 결과물 생성 작업에는 적극적으로 해롭습니다. 읽기 작업에는 팬아웃(fan-out)을 사용하고, 쓰기 작업에는 단일 에이전트를 유지하십시오. 어떤 방식이든 제어 흐름(control flow)은 결정론적 코드(deterministic code)가 담당하게 하고, 모든 노브 뒤에는 반드시 평가(eval)를 배치하십시오.

이를 제대로 수행하는 팀은 가장 많은 에이전트를 보유한 팀이 아닙니다. 그들은 자신들의 특정 작업에 대해 두 번째 컨텍스트 윈도우 (context window)가 무엇을 '얻어다 주는지'를 명확히 설명할 수 있고, 그 답변이 요구하는 것보다 정확히 한 단계만 더 복잡하게 아키텍처 (architecture)를 유지하는 팀입니다.