Magentic 오케스트레이션 설명: Microsoft의 패턴이 단순 감독자 아키텍처보다 우수한 이유

저는 자신이 실패하고 있음을 알고 있는 감독자(supervisor) 아키텍처를 방어하는 데 한 달을 보냈습니다.

증상은 처음에는 미묘했습니다. 제 감독자 에이전트는 작업을 올바르게 분해하고, 적절한 전문가에게 라우팅하며, 깨끗한 결과를 받고, 그런 다음 합성 과정 중 어딘가에서 그 전문가가 표시했던 제약 조건을 조용히 누락시켰습니다. 환각(hallucination)이 아니었습니다. 압축(compression)이었습니다. 전문가는 '소스 A를 기반으로 검증되었으나, 소스 B는 오래되었습니다'라고 말했습니다. 감독자는 이를 '검증됨'이라고 요약했습니다. 결과물이 사용자에게 도달할 때쯤이면, 주의사항은 사실이 되어버렸습니다.

저는 계속 프롬프트를 조정했습니다. 감독자가 더 많은 세부 사항을 보존해야 했습니다. 전문가는 더 구조화된 출력을 반환해야 했습니다. 저는 감독자를 더 강력한 모델로 업그레이드했습니다. 아무것도 도움이 되지 않았는데, 왜냐하면 저는 메모리 문제를 추론 문제로 진단하고 있었기 때문입니다.

연구에서는 이미 제가 부딪히는 것을 이름 붙였습니다. 2026년 논문에서 발견했듯이, 계획(planning)을 실행(execution)과 분리할 때, 정교한 계획 전략은 그들이 의존하는 실행자들(executors)이 그것들을 받을 수 있도록 적응되지 않았기 때문에 구현에 실패합니다. 핸드오프(handoff)가 손실 채널입니다. 감독자의 컨텍스트 윈도우가 병목 지점입니다. 그리고 제가 구축했던 아키텍처는 모든 메시지가 자신의 축적된 컨텍스트 속에서 서서히 익사하는 하나의 에이전트를 통과하는 허브-앤-스포크(hub-and-spoke) 토폴로지였습니다.

그때 저는 Magentic-One을 발견했습니다.

감독자 패턴의 구조적 약점

감독자 패턴은 그 자체로 기본값이기 때문에 존재합니다. 하나의 에이전트가 워크플로우를 소유하고, 작업을 분해하며, 하위 작업을 할당하고, 출력을 수집하며, 다음에 무슨 일이 일어날지 결정합니다. 이는 추론하기 쉽고, 디버깅하기 쉬우며, 읽었던 모든 프레임워크에 깔끔하게 매핑됩니다. LangGraph의 create_supervisor, CrewAI의 계층적 프로세스, 그리고 AutoGen의 그룹 채팅 모두 이 버전 중 일부를 구현하고 있습니다.

이는 3개에서 7개의 에이전트까지 작동합니다. 2026년 설문 문헌은 이를 중앙 집중식 패턴으로 공식화했습니다. 이 구조에서는 모든 메시지가 감독자(supervisor)를 거쳐 전달되는 허브 앤 스포크 토폴로지(hub-and-spoke topology)를 따르며, 감독자는 작업 진행 상황에 대한 전역적인 시야(global view)를 유지합니다. 해당 설문조사는 이 패턴의 한계점에 대해 명확하게 평가했습니다. 즉, 감독자가 단일 실패 지점(single point of failure)이자 처리량 병목 현상(throughput bottleneck)이며, 에이전트 수와 대화 길이가 증가함에 따라 컨텍스트 윈도우가 가득 차고, AutoGen의 자동 스피커 선택 모드(auto speaker-selection mode)는 매 턴마다 전체 대화 기록을 중첩된 채팅(nested chat)을 통해 처리합니다. 이 패턴은 토큰 비용이 대화 길이에 선형적으로 비례하여 증가하는 문제가 있습니다.

저는 그 비용을 측정하지 않은 채 지불하고 있었습니다. 감독자는 매번 돌아올 때마다 축적된 전체 대화를 재처리했습니다. 감독자가 작업에 대해 추론(reasoning)하는 것이 아니었습니다. 그것은 자신의 기록을 다시 흡수하며 신호가 살아남기를 바랄 뿐이었습니다.

더 깊은 실패는 감독자 패턴이 '우리가 무엇을 하려고 하는지'와 '무엇을 했는지'를 구별할 메커니즘이 없다는 것입니다. 계획(plan)은 감독자의 컨텍스트 윈도우 안에 존재하며, 모든 도구 출력(tool output), 모든 전문 답변(specialist response), 모든 중간 아티팩트(intermediate artifact)와 뒤섞여 있습니다. 컨텍스트가 포화되면, 가장 최근에 작성된 것이 아니기 때문에 계획이 먼저 저하됩니다.

Magentic-One의 변화점

Magentic-One은 Microsoft Research에서 개발하고 2024년 11월에 출시한 범용 멀티 에이전트 시스템입니다. 이 시스템은 단일 오케스트레이터(Orchestrator) 에이전트를 중심으로 구축되어 계획을 세우고, 진행 상황을 추적하며, 오류로부터 복구하기 위해 재계획합니다. 아키텍처는 속임수처럼 단순합니다. 하나의 선도 에이전트가 전문 에이전트들에게 작업을 수행하도록 지시합니다. 이들은 웹 브라우저 작동, 로컬 파일 탐색, Python 코드 작성 및 실행 등의 작업을 합니다. 그리고 오케스트레이터는 계획과 진행 상황 추적을 분리하는 두 개의 원장(ledger)을 유지합니다.

이러한 분리가 바로 전체 패턴입니다. 오케스트레이터는 계획을 자신의 컨텍스트 윈도우에 담지 않습니다. 대신, 재계획 주기 전반에 걸쳐 살아남는 구조화된 원장 안에 계획을 보관합니다.

태스크 원장(The Task Ledger): 우리가 하려는 일

task ledger는 오케스트레이터(Orchestrator)의 접근 계획입니다. Magentic-One 논문에서는 이를 주어진 사실, 찾아볼 사실, 도출할 사실, 추론된 가설, 그리고 자연어 형태의 단계별 계획을 포함하고 있다고 설명합니다. 오케스트레이터는 실행 시작 시점에 이 원장을 구축하며, 전문가(specialists)들로부터 새로운 정보가 도착함에 따라 이를 정교하게 다듬습니다.

원장의 구조가 내용보다 더 중요합니다. 사실들을 '주어진', '찾아볼', '도출할', '추론된 가설'로 분류함으로써, 오케스트레이터는 자신이 무엇을 알고 있는지, 무엇을 알아내야 하는지, 무엇을 계산할 수 있는지, 그리고 무엇을 추론하고 있는지를 구별하도록 강제됩니다. 감독자(supervisor)의 컨텍스트 윈도우(context window)는 그러한 구분을 만들어내지 못합니다. 모든 것이 단지 텍스트일 뿐이며, 대화가 진행됨에 따라 검증된 사실과 확신에 찬 추측 사이의 경계가 모호해집니다.

task ledger는 암묵적인 체인(chain)이라기보다는 명시적이고 수정 가능한 아티팩트입니다. 오케스트레이터가 재계획할 때, 이 원장을 업데이트합니다. 계획은 요약본으로부터 재구성되는 것이 아니라, 제자리에서 편집됩니다.

진행 원장(The Progress Ledger): 우리가 한 일

progress ledger는 매 반복마다 다섯 가지 질문에 답합니다: 요청이 충족되었는가? 팀이 순환하고 있는가? 진전이 이루어지고 있는가? 누가 다음에 말할 차례인가? 그들에게 어떤 지침이나 질문을 주어야 하는가?

오케스트레이터는 또한 정지 카운터(stall counter)를 유지합니다. 루프가 감지되거나 진행이 멈추면, 이 카운터가 증가합니다. 이것이 임계값(threshold)—Magentic-One 실험에서는 2—보다 낮은 한, 오케스트레이터는 다음 에이전트를 선택하고 내부 루프를 계속합니다. 만약 카운터가 임계값을 초과하면, 오케스트레이터는 내부 루프에서 벗어나 반성 단계(reflection step)를 시작합니다. 이 단계에서 무엇이 잘못되었을 수 있는지, 그리고 무엇을 배웠는지 파악하고, task ledger를 업데이트하며, 계획을 수정하고, 다음 사이클을 시작합니다.

이것은 감독자(supervisor)들이 갖지 못하는 메커니즘입니다. 감독자는 명시적인 정지 카운터(stall counter)를 가지고 있지 않습니다. 구조화된 반성 단계(structured reflection step)도 없습니다. 대화 자체와 분리되어 '계획이 실패하고 있다'는 것을 나타내는 표현이 없기 때문에, 실패하는 계획에서 벗어날 수 없습니다. 정지는 단지 컨텍스트 창에 추가되는 텍스트일 뿐입니다.

두 개의 루프 (The Two Loops)

이 아키텍처는 중첩된 루프 시스템입니다. **외부 루프(outer loop)**는 작업 원장(task ledger)을 관리합니다: 이를 초기화하고, 계획이 변경될 때 업데이트하며, 오케스트레이터(Orchestrator)가 재계획할 때 에이전트 컨텍스트를 리셋합니다. **내부 루프(inner loop)**는 다섯 가지 진행 질문에 답하고, 다음 전문가를 할당하며, 진전이 감지되지 않을 때 정지 카운터를 증가시킵니다.

외부 루프가 이 패턴을 적응적으로 만듭니다. 감독자의 계획은 분해 시점에 고정됩니다. 만약 계획이 잘못되었다면, 감독자는 이를 수정할 메커니즘이 없습니다 — 단지 결과를 내지 못하는 구조를 통해 작업을 계속 라우팅하는 것만 할 수 있습니다. Magentic Orchestrator는 계획 자체를 완전히 포기할 수 있습니다. Microsoft 문서에 있는 SRE 인시던트 대응 예시가 이를 정확하게 보여줍니다: 진단 에이전트(diagnostics agent)가 데이터베이스 연결 문제를 발견하면, 오케스트레이터는 전체 계획을 배포 롤백 전략에서 데이터베이스 연결 복구에 초점을 맞춘 전략으로 전환할 수 있습니다.

계획은 약속이 아닙니다. 그것은 작동 가설(working hypothesis)입니다.

왜 기존 감독자 아키텍처보다 우수한가 (Why It Outperforms Naive Supervisor Architectures)

성능 차이는 미미하지 않습니다. Magentic-One은 GAIA에서 38%, WebArena에서 32.8%, AssistantBench에서 **27.7%**의 작업 완료율을 달성했습니다 — 이는 세 가지 다양하고 도전적인 에이전트 벤치마크에서 최첨단(state-of-the-art)과 통계적으로 경쟁할 수 있는 수준입니다. 이 결과들은 핵심 에이전트 기능이나 협업 방식에 대한 수정 없이 달성되었으며, 그 모듈식 설계 덕분에 추가적인 프롬프트 튜닝이나 학습 없이도 에이전트를 추가하거나 제거할 수 있습니다.

하지만 벤치마크 수치보다 중요한 것은 그 수치가 나온 아키텍처적 이유입니다. Magentic-One 논문의 제거(ablation) 및 오류 분석 결과, 두 개의 원장 메커니즘(two-ledger mechanism), 정지 카운터(stall counter), 그리고 외부 루프 재계획(outer-loop replanning) 각각이 성능을 지탱하는 핵심 요소임이 밝혀졌습니다. 이 중 어느 하나를 제거해도 성능 저하가 발생했습니다. 이 패턴이 작동하는 이유는 감독자(supervisors)들이 혼합하는 세 가지 관심사, 즉 '우리가 하려고 하는 것', '우리가 한 것', 그리고 '다음에 무엇을 해야 할지'를 분리하기 때문입니다.

감독자는 이 세 가지를 단일한 컨텍스트 윈도우에 혼합합니다. 태스크 원장(task ledger)은 계획입니다. 진행 상황 원장(progress ledger)은 상태입니다. 오케스트레이터(Orchestrator)의 라우팅 결정(routing decision)이 다음 행동입니다. 각각은 고유한 구조, 고유한 업데이트 주기, 그리고 고유한 실패 모드를 가집니다. 이들이 혼합되면, 하나의 실패 모드가 다른 것들을 오염시킵니다.

프로덕션 팀에서 실행되는 방식

Microsoft의 Azure Architecture Center에 있는 SRE 인시던트 대응 예시가 가장 명확한 프로덕션 사례입니다. 서비스 장애가 발생하면, magentic 관리자 에이전트(manager agent)는 '서비스 가용성 복구', '근본 원인 식별'과 같은 고수준 목표를 담은 초기 태스크 원장(task ledger)을 생성합니다. 이는 로그와 메트릭을 분석하기 위해 진단 에이전트(diagnostics agent)에 문의하고, 특정 조사 단계를 태스크 원장에 업데이트하며, 복구 옵션을 이해하기 위해 인프라 에이전트(infrastructure agent)에 문의하고, 커뮤니케이션 에이전트를 통해 커뮤니케이션 체크포인트와 승인 게이트를 통합합니다. 만약 장애가 자동화의 범위를 초과하면, 인간 SRE 엔지니어에게 에스컬레이션됩니다. 관리자는 진화하는 계획과 구현 단계에 대한 완전한 감사 추적(audit trail)을 유지하며, 이는 인시던트 후 검토를 위한 투명성을 제공합니다.

해당 패턴 자체의 문서에서도 어떤 경우에 적합한지 솔직하게 설명하고 있습니다. AgentPatterns.ai는 다음 네 가지 조건이 모두 충족되어야 한다고 나열합니다: 계획(plan) 자체가 미지수여야 하며 (실행 전에 고정된 파이프라인을 그릴 수 없음), 검토 가능한 감사 추적(audit-trailed) 계획이 제품의 일부여야 하고, 팀이 '작업당 몇 달러와 수십 분'을 감당할 수 있어야 하며, 쓰기 접근 권한 전문가가 일시 정지 후 되돌릴 수 없는 행동 전 게이트(pause-before-irreversible-action gate)가 있는 샌드박스 내부에서 실행되어야 합니다. 이 조건 중 하나라도 실패하면 더 단순한 토폴로지가 우세합니다.

Microsoft의 가이드는 반대 시나리오를 추가합니다: 해결 경로가 결정론적(deterministic)이어야 할 때, 원장(ledger)을 생성할 필요가 없을 때, 작업의 복잡도가 낮을 때, 또는 작업이 시간 민감적일 때는 magentic 오케스트레이션을 피해야 합니다. 이 패턴은 속도 최적화보다는 실행 가능한 계획을 구축하고 토론하는 데 중점을 둡니다.

Magentic-One이 해결하지 못하는 것들

저는 이 패턴이 만능 해결책이라고 주장할 생각이 없습니다. 한계는 구조적인 것입니다.

이 패턴은 비용이 많이 듭니다. AgentPatterns.ai 가이드는 Magentic-One 논문의 자체 제한 사항 섹션을 인용합니다: '작업당 몇 달러와 수십 분'. 감독자(supervisor)는 센트 단위의 비용과 초 단위의 시간을 들일 수 있습니다. 원장 기반 접근 방식은 계획 품질과 감사 가능성(auditability)을 위해 비용과 지연 시간(latency)을 교환합니다.

이 패턴은 수렴하지 않고 정지할 수 있습니다. 정지 카운터와 외부 루프 재계획(outer-loop replanning)은 경계일 뿐, 보장은 아닙니다. 오케스트레이터(Orchestrator)의 재계획이 실행 가능한 접근 방식을 찾지 못하면, 시스템은 작업을 해결하지 못한 채 종료 조건에 도달합니다. Magentic 오케스트레이션 무한 루프에 대한 GitHub 이슈는 실제 환경에서 이러한 실패 모드를 문서화하고 있습니다: 오케스트레이터가 사용자의 작업을 해결할 때까지 끝나지 않는 루프에서 실행되어 과도한 토큰을 소비하고 수동 종료를 필요로 합니다.

이 패턴은 모든 다중 에이전트 시스템에 영향을 미치는 것과 같은 **핸드오프 압축 문제(handoff compression problems)**에 취약합니다. 오케스트레이터는 자연어를 통해 전문화된 에이전트와 통신합니다. 태스크 원장(task ledger)과 진행 상황 원장(progress ledger)은 구조화되어 있지만, 전문화된 에이전트에게 전달되는 *지침(instructions)*은 그렇지 않습니다. 전문화된 에이전트는 여전히 제약 조건을 오해하거나 바인딩 상태를 잃어버린 결과를 반환할 수 있습니다. 원장은 오케스트레이터의 결정을 명시적으로 만듭니다. 하지만 전문화된 에이전트의 추론 과정을 투명하게 만들지는 못합니다.

과거의 나에게 하고 싶은 말

감독자(supervisor) 패턴 자체가 틀린 것은 아닙니다. 잘못된 점은 감독자의 컨텍스트 윈도우를 시스템의 메모리라고 간주하는 것입니다.

Magentic-One이 제시하는 통찰은 계획과 진행 상태가 대화 그 자체라는 것이 아니라는 점입니다. 그것들은 우연히 대화를 통해 생성되는 구조화된 아티팩트(structured artifacts)입니다. 이 둘을 분리하면 계획은 수정 가능하고, 진행 상황은 측정 가능하며, 정체(stall)는 감지할 수 있게 됩니다. 세 가지를 모두 하나의 컨텍스트 윈도우에 담으려는 감독자는 결국 가장 중요했던 제약 조건을 놓치게 될 것입니다.

이것을 성공적으로 구현하는 팀들은 '감독자'와 '군집(swarm)' 중 하나를 선택하는 것이 아닙니다. 그들은 더 어려운 질문, 즉 '나의 오케스트레이션 레이어가 컨텍스트 포화 상태에서도 살아남는 계획에 대한 명시적인 표현을 가지고 있는가? 그리고 증거가 틀렸다고 말할 때 그 계획을 버릴 수 있는가?'를 던지고 있습니다.

감독자는 할 수 없습니다. Magentic 오케스트레이터만이 할 수 있습니다.

그래서 제 질문은 이겁니다: 당신의 감독자 에이전트의 컨텍스트 윈도우가 가득 찼을 때, 당신의 아키텍처는 여전히 무엇을 하려는지 알고 있습니까, 아니면 계획이 단지 요약되어 사라질 위험에 처한 또 다른 텍스트 블록일 뿐입니까?