Agentic AI 플랫폼 엔지니어링

Appearance

단일 에이전트 vs 멀티 에이전트 ​

이 장에서 얻는 것

  • "멀티 에이전트가 더 좋다/나쁘다"라는 이분법 대신, 어떤 작업 구조에서 어느 쪽이 이기는지를 판별하는 기준
  • Anthropic의 멀티 에이전트 리서치 시스템 실증 데이터(90.2% 성능 개선, 약 15배 토큰 비용)와 그 반대편에 있는 Cognition·arXiv 반론의 정확한 논점
  • 멀티 에이전트를 도입할 때 반드시 함께 배포해야 하는 비용 가드레일(서킷 브레이커, per-run 예산 캡)
  • 아키텍처 선택을 사후에 검증할 수 있는 SLI 세트

왜 문제가 되는가 ​

에이전트 플랫폼 설계에서 가장 먼저 마주치는 아키텍처 분기점이 이것이다: 하나의 에이전트에 모든 도구와 컨텍스트를 주고 순차적으로 일하게 할 것인가, 아니면 리드(orchestrator) 에이전트가 서브에이전트(worker)들을 스폰해 병렬로 일하게 할 것인가.

이 선택이 어려운 이유는 업계의 대표적인 두 진영이 정반대의 결론을 공개적으로 주장하고 있기 때문이다. Anthropic은 자사 Research 기능을 멀티 에이전트로 구축해 큰 폭의 성능 개선을 보고했고[^multi-agent], Cognition(Devin 개발사)은 같은 시기에 "Don't Build Multi-Agents"라는 제목의 글로 멀티 에이전트 아키텍처 자체를 반박했다[^cognition]. 둘 다 프로덕션 에이전트를 대규모로 운영하는 조직이다. 어느 한쪽이 틀렸다기보다, 서로 다른 작업 구조에 대해 이야기하고 있다는 것이 이 장의 핵심 논지다.

플랫폼 엔지니어에게 이 선택은 추상적 설계 취향의 문제가 아니다. 멀티 에이전트는 토큰 소비를 한 자릿수 배수로 증폭시키므로, 비용 구조·레이트 리밋 소진·지연 시간 프로파일이 아키텍처 결정 시점에 사실상 고정된다. 잘못 고르면 나중에 프롬프트 튜닝으로 만회할 수 없다.

핵심 개념 ​

두 아키텍처의 정의 ​

  • 단일 에이전트(single-agent): 하나의 컨텍스트 윈도우, 하나의 결정 주체. 모든 도구 호출과 중간 결과가 같은 컨텍스트에 축적된다. 컨텍스트가 차면 compaction/요약으로 버틴다.
  • 멀티 에이전트(multi-agent): 리드 에이전트가 작업을 분해해 서브에이전트들에게 위임하고, 각 서브에이전트는 자기만의 컨텍스트 윈도우에서 탐색한 뒤 압축된 결과만 리드에게 반환한다. Anthropic의 Research 시스템이 채택한 orchestrator-worker 패턴이 대표적이다[^multi-agent]. 패턴의 변형(sequential, debate, ensemble 등)은 오케스트레이션 패턴에서 다룬다.

멀티 에이전트의 본질적 이득은 두 가지다. 첫째, 컨텍스트 격리 — 서브에이전트의 탐색 노이즈가 리드의 컨텍스트를 오염시키지 않는다(이 관점의 상세는 컨텍스트 격리와 오프로딩에서 다룬다). 둘째, 병렬성 — 독립적인 탐색 경로를 동시에 진행할 수 있다.

토큰 경제학: 성능의 대리 변수이자 비용의 원천 ​

Anthropic이 공개한 데이터에서 가장 중요한 발견은 성능 수치 자체보다 그 원인 분해다. BrowseComp 유사 평가에서 성능 분산을 분석한 결과, 토큰 사용량 하나가 성능 분산의 80%를 설명했다[^multi-agent]. 도구 호출 횟수와 모델 선택이 나머지 대부분을 설명한다. 즉 멀티 에이전트 아키텍처의 성능 이득은 상당 부분 "더 많은 토큰을 병렬 컨텍스트 윈도우들에 나눠 태울 수 있다"는 데서 온다.

같은 글이 비용도 명시한다: 에이전트는 일반 챗 대비 약 4배, 멀티 에이전트 시스템은 약 15배의 토큰을 사용한다[^multi-agent]. 성능 실증치는 이렇다: Claude Opus 4를 리드로, Claude Sonnet 4를 서브에이전트로 쓴 멀티 에이전트 구성이 단일 Claude Opus 4 에이전트를 내부 리서치 평가에서 90.2% 능가했다[^multi-agent]. Anthropic 스스로 이 조합의 경제성 조건을 단서로 단다 — "결과의 가치가 성능 향상 비용을 정당화할 만큼 큰 작업"에서만 성립하며, 모든 에이전트가 같은 컨텍스트를 공유해야 하거나 에이전트 간 상호 의존성이 큰 도메인은 현재 멀티 에이전트에 적합하지 않다. 그 예로 든 것이 바로 코딩이다(리서치보다 병렬화 가능한 작업이 적다는 이유)[^multi-agent].

반대편 논거: 컨텍스트 공유와 동일 예산 비교 ​

Cognition의 반론은 신뢰성 논거다[^cognition]. 두 원칙 — (1) 컨텍스트를 공유하되 개별 메시지가 아니라 전체 에이전트 트레이스를 공유하라, (2) 행동에는 암묵적 결정이 담기며, 상충하는 결정은 나쁜 결과를 낳는다 — 을 제시하고, 병렬 서브에이전트는 이 둘을 구조적으로 위반한다고 주장한다. 서로의 작업을 볼 수 없는 서브에이전트들이 상충하는 가정을 내리고(예: Flappy Bird 클론을 나눠 만들 때 한쪽은 Mario풍 배경, 다른 쪽은 이질적인 새 에셋을 만드는 예시), 리드가 이를 봉합하는 비용이 병렬화 이득을 잠식한다는 것이다. Cognition의 처방은 단일 스레드 선형 에이전트 + 컨텍스트 압축 전용 모델이다.

학술 쪽 반론은 비교 방법론을 겨냥한다. Tran & Kiela의 arXiv 논문(arXiv:2604.02460)은 동일한 thinking token 예산으로 정규화하면 FRAMES·MuSiQue 멀티홉 추론 벤치마크에서, 3개 모델 패밀리(Qwen3, DeepSeek-R1-Distill-Llama, Gemini 2.5)와 5개 MAS 아키텍처(sequential, debate, ensemble, parallel-roles, subtask-parallel) 전반에 걸쳐 단일 에이전트가 멀티 에이전트와 대등하거나 우세함을 보였다[^equal-budget]. Data Processing Inequality에 기반한 정보이론적 논거와 함께, 기존 벤치마크에서 보고된 MAS 이득의 상당수가 아키텍처의 우월성이 아니라 미통제된 추가 연산(토큰)의 효과라고 주장한다. 이는 Anthropic의 "토큰이 분산의 80%를 설명한다"는 관찰과 사실상 같은 현상을 반대 방향에서 읽은 것이다.

미정착 영역

멀티 에이전트의 가치는 업계에서 아직 결론이 나지 않은 논쟁이며, 이 책에서 가장 명시적으로 양쪽을 병기해야 하는 주제다.

멀티 에이전트 옹호 (Anthropic)[^multi-agent]: breadth-first 리서치처럼 병렬화 가능한 작업에서 90.2% 성능 개선을 실증. 단, 약 15배 토큰 비용과 "고부가가치 작업 한정"이라는 단서, 그리고 코딩처럼 상호 의존성이 큰 도메인 부적합이라는 자체 단서를 함께 공개.

단일 에이전트 옹호 (Cognition, Tran & Kiela): Cognition은 병렬 서브에이전트의 상충 결정 문제를 들어 단일 스레드 + 컨텍스트 압축을 처방[^cognition]. Tran & Kiela는 토큰 예산을 통제하면 단일이 대등하거나 우세하며, 기존 MAS 이득 보고는 연산량 미통제의 산물일 수 있음을 실험으로 제시[^equal-budget].

두 진영의 주장은 실제로는 양립 가능하다. "토큰을 더 태울 수 있는 구조가 이긴다"(Anthropic)와 "같은 토큰이면 단일이 이긴다"(Tran & Kiela)는 서로를 반박하지 않는다. 실무 질문은 "멀티가 좋은가?"가 아니라 **"이 작업은 토큰을 병렬로 더 태우면 실제로 좋아지는 구조인가, 그리고 그 비용을 감당할 가치가 있는가"**다. 다만 어떤 작업이 정확히 어느 쪽에 속하는지의 경계선, 그리고 모델 능력 향상이 이 경계를 어느 쪽으로 이동시킬지는 미정착 상태다. Cognition조차 단일 에이전트 처방을 "2025년 현재"의 판단으로 한정한다[^cognition].

결정의 실제 축: 작업의 의존성 구조 ​

양쪽 실증을 종합하면 결정 축은 모델이나 프레임워크가 아니라 작업의 의존성 그래프다.

  • 독립 병렬 분해가 자연스러운 작업(breadth-first 리서치, 다수 소스 교차 검증, 서로 겹치지 않는 파일 트리 탐색): 서브에이전트 간 공유해야 할 상태가 거의 없으므로 Cognition이 지적한 상충-결정 문제가 발생할 표면적이 작다. 병렬 컨텍스트 윈도우의 토큰 증분이 실제 성능으로 전환된다. → 멀티가 유리.
  • 상호 의존적 작업(코딩, 하나의 일관된 산출물을 만드는 작업, 이전 결정이 다음 행동을 제약하는 작업): 서브에이전트마다 암묵적 결정이 갈라지고, 봉합 비용이 병렬화 이득을 초과한다. Anthropic도 이 범주를 멀티 에이전트 부적합으로 명시한다[^multi-agent]. → 단일이 유리.

멀티를 선택했다면: 비용 가드레일은 선택이 아니다 ​

약 15배 토큰이라는 비용 구조[^multi-agent]는 평균의 이야기이고, 꼬리(tail)는 훨씬 나쁘다. 리드가 작업을 과도하게 분해하거나 서브에이전트가 루프에 빠지면 단일 런의 비용이 통제 없이 발산한다. 따라서 멀티 에이전트 패턴은 비용 서킷 브레이커와 per-run 예산 캡을 함께 배포할 때만 도입한다 — 이는 이 책의 실행 로드맵 3단계가 멀티에이전트 도입의 전제 조건으로 못박은 것과 같은 원칙이다. 구체적으로:

  • per-run 예산 캡: 런 단위 토큰(또는 환산 비용) 상한. 초과 시 graceful termination — 지금까지의 부분 결과를 요약해 반환하고 종료한다.
  • 비용 서킷 브레이커: 시간창 단위(예: 시간당/일당) 누적 비용이 임계치를 넘으면 신규 멀티 에이전트 런의 스폰을 차단하고 단일 에이전트 폴백으로 강등한다.
  • 스폰 깊이/폭 제한: 서브에이전트가 다시 서브에이전트를 스폰하는 깊이, 리드가 동시에 유지하는 서브에이전트 수의 하드 리밋.

결정 표 ​

상황선택이유트레이드오프
breadth-first 리서치 — 여러 독립 소스를 병렬 탐색 후 종합멀티 (orchestrator-worker)병렬 컨텍스트 윈도우가 토큰 증분을 성능으로 전환; Anthropic 실증 90.2% 개선[^multi-agent]챗 대비 약 15배 토큰[^multi-agent]; 서킷 브레이커 + 예산 캡 필수
코딩 등 하나의 일관된 산출물 — 이전 결정이 다음 행동을 제약단일서브에이전트 간 암묵적 결정이 상충[^cognition]; Anthropic도 부적합 도메인으로 명시[^multi-agent]긴 작업에서 컨텍스트 압박 → compaction으로 대응
모든 참여자가 동일한 전체 컨텍스트를 공유해야 하는 작업단일격리가 이득이 아니라 손실이 되는 구조[^multi-agent][^cognition]컨텍스트 윈도우 한계가 작업 길이의 상한
토큰 예산이 고정되어 있고 늘릴 수 없음 (레이트 리밋, 비용 상한)단일동일 예산에서는 단일이 대등하거나 우세[^equal-budget]병렬화로 얻을 수 있던 지연 시간 단축 포기
탐색 노이즈가 큰 대용량 조회를 수행하되 결과 요약만 필요멀티 (또는 단일 + 서브태스크 격리)리드 컨텍스트 오염 방지 — 컨텍스트 격리 관점반환 계약 없으면 격리 무의미; 토큰 배수 비용
결과 가치가 낮은 대량 반복 작업 (분류, 단순 추출)단일 (또는 워크플로우)15배 비용을 정당화할 가치가 없음[^multi-agent]; 애초에 에이전트가 필요한지부터 재검토—
지연 시간이 최우선이고 작업이 병렬 분해 가능멀티병렬 실행으로 wall-clock 단축비용 증가와 부분 실패 처리 복잡도

실패 모드 ​

증상근본 원인확인 방법해결
멀티 도입 후 품질은 비슷한데 비용만 10배 이상 증가작업이 병렬 분해 가능한 구조가 아님 — 토큰 증분이 성능으로 전환되지 않음[^equal-budget]동일 작업을 단일 에이전트 + 동일 토큰 예산으로 A/B 평가단일로 회귀; 멀티는 breadth-first 작업에만 유지
서브에이전트 산출물이 서로 모순되어 리드가 봉합에 실패상호 의존 작업을 병렬 분해 — 암묵적 결정 상충[^cognition]서브에이전트 트레이스에서 같은 대상에 대한 상이한 가정 검출의존 구간을 단일 스레드로 직렬화; 공유 결정은 리드가 먼저 확정 후 위임
단일 런 비용이 간헐적으로 발산 (p99 비용 폭주)리드의 과잉 분해 또는 서브에이전트 루프; per-run 캡 부재런별 토큰 분포의 p50 대비 p99 배율 확인per-run 예산 캡 + 스폰 깊이/폭 하드 리밋 (로드맵 3단계)
서브에이전트가 대량 원본을 그대로 반환해 리드 컨텍스트 즉시 소진반환 계약(return contract) 부재 — 격리가 형식만 남음서브에이전트 반환 페이로드 크기 측정반환 스키마·토큰 상한을 프롬프트에 명시 (컨텍스트 격리 참고)
멀티 구성인데 지연 시간이 단일보다 오히려 김서브에이전트를 순차 스폰하거나, 분해·종합 오버헤드가 병렬 이득 초과트레이스에서 서브에이전트 실행 구간의 실제 병렬도 측정병렬 스폰으로 전환; 분해 단위가 너무 잘게 쪼개지지 않았는지 검토
레이트 리밋 소진으로 다른 워크로드까지 장애 전파멀티 에이전트의 토큰 배수를 용량 계획에 미반영프로바이더 사용량 대시보드에서 멀티 런 기여도 분리비용 서킷 브레이커 + 워크로드별 쿼터 분리

안티패턴 ​

  • ❌ "에이전트가 여러 개면 더 똑똑하다"는 직관으로 멀티를 기본값으로 삼는다 → ✅ 작업의 의존성 그래프를 먼저 그리고, 독립 병렬 분해가 자연스러울 때만 멀티를 검토한다.
  • ❌ 멀티 vs 단일 비교 평가에서 토큰 예산을 통제하지 않는다 → ✅ 동일 토큰 예산으로 정규화해 비교한다 — 미통제 비교는 아키텍처 효과와 연산량 효과를 구분하지 못한다[^equal-budget].
  • ❌ 코딩 파이프라인을 병렬 서브에이전트로 분해해 같은 코드베이스를 동시에 수정하게 한다 → ✅ 상호 의존 산출물은 단일 스레드로 유지하고, 병렬화는 읽기 전용 탐색(코드 검색, 문서 조사)에 한정한다[^cognition][^multi-agent].
  • ❌ 예산 캡 없이 멀티를 프로덕션에 배포하고 "평균 비용이 감당 가능하니 괜찮다"고 판단한다 → ✅ per-run 캡 + 서킷 브레이커를 아키텍처의 일부로 배포한다. 평균이 아니라 꼬리가 청구서를 결정한다.
  • ❌ 서브에이전트에 "조사해서 알려줘"라고만 지시한다 → ✅ 반환 형식과 토큰 상한을 계약으로 명시한다 (상세: 컨텍스트 격리와 오프로딩).
  • ❌ 한 번 정한 아키텍처를 고정 사실로 취급한다 → ✅ 이 논쟁은 미정착 영역이다. 모델 능력과 비용이 바뀌면 경계선도 움직이므로, 아래 SLI로 분기 결정을 주기적으로 재검증한다.

계측 (SLI) ​

아키텍처 선택은 배포로 끝나지 않는다. 다음 지표로 "그 선택이 여전히 옳은지"를 계속 측정한다.

  • 토큰 배수 (token multiplier): 동일 작업군에서 멀티 런의 토큰 사용량 ÷ 단일 베이스라인. Anthropic 공개치(챗 대비 에이전트 약 4배, 멀티 약 15배[^multi-agent])를 기준선으로, 이 배율이 기준을 크게 상회하면 과잉 분해를 의심한다.
  • 품질/비용 비 (quality per token): 평가 점수 ÷ 소비 토큰. 멀티가 단일 대비 이 비율에서도 이기는지가 진짜 판정 기준이다 — 절대 점수만 보면 토큰 증분 효과와 아키텍처 효과를 구분할 수 없다[^equal-budget].
  • per-run 비용 분포의 p99/p50 배율: 꼬리 발산의 조기 신호. 서킷 브레이커 임계치 설정의 근거 데이터.
  • 서브에이전트 반환 압축률: 서브에이전트 내부 소비 토큰 대비 리드로 반환된 토큰. 격리가 실제로 작동하는지의 지표 (컨텍스트 격리와 동일 지표).
  • 봉합 실패율: 리드가 서브에이전트 산출물 간 모순을 해소하지 못해 재시도/재스폰한 비율. 상승 추세면 작업이 멀티에 부적합하다는 신호[^cognition].
  • 서킷 브레이커 발동 횟수: 0이 목표가 아니다 — 한 번도 발동하지 않는 브레이커는 임계치가 무의미하게 높다는 뜻일 수 있다.

체크리스트 ​

  • [ ] 작업의 의존성 그래프를 그렸는가 — 독립 병렬 분해가 자연스러운가, 아니면 결정이 순차적으로 누적되는가?
  • [ ] 결과의 가치가 약 15배 토큰 비용[^multi-agent]을 정당화하는가? (아니라면 단일 또는 워크플로우)
  • [ ] 멀티 vs 단일 비교 평가를 동일 토큰 예산으로 수행했는가?[^equal-budget]
  • [ ] per-run 예산 캡과 비용 서킷 브레이커가 멀티 배포에 포함되어 있는가? (로드맵 3단계의 전제 조건)
  • [ ] 서브에이전트 스폰 깊이/폭에 하드 리밋이 있는가?
  • [ ] 모든 서브에이전트 프롬프트에 반환 형식·토큰 상한 계약이 명시되어 있는가?
  • [ ] 상호 의존 산출물(특히 코드)을 병렬 서브에이전트가 동시에 수정하지 않도록 경계를 설정했는가?
  • [ ] 토큰 배수·품질/비용 비·봉합 실패율을 대시보드에서 추적하고 있는가?
  • [ ] 분기 결정을 재검증할 주기(예: 주요 모델 업데이트 시점)를 정했는가?

참고 ​

[^multi-agent]: Anthropic, "How we built our multi-agent research system", Anthropic Engineering Blog (2025년 6월 13일 게시). 90.2% 성능 개선, 토큰 사용량의 성능 분산 80% 설명, 챗 대비 에이전트 약 4배/멀티 에이전트 약 15배 토큰, 코딩 도메인 부적합 단서의 출처. [^cognition]: Walden Yan, "Don't Build Multi-Agents", Cognition Blog (2025년 6월 12일 게시). [^equal-budget]: Dat Tran, Douwe Kiela, "Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets", arXiv:2604.02460 (2026).

관련 챕터 ​