지난 2년 동안 왜 그렇게 많은 멀티 에이전트 개념 증명(PoC)들이 보류되었는지에 대한 저의 견해는 다음과 같습니다. 에이전트가 미성숙했기 때문이 아니라, 문제가 동적인 조정(dynamic coordination)을 필요로 했음에도 불구하고 팀들이 모든 것을 고정된 순차적 파이프라인(fixed sequential pipeline)으로 설계했기 때문입니다. 이는 측정된 수치가 아닌 의견이지만, 아래에서 제가 옹호할 내용입니다.

이 질문을 다시 불러일으킨 뉴스는 agent-framework-orchestrations가 Python에서 1.0.0 버전에 도달했다는 것입니다. 이는 Microsoft Agent Framework의 오케스트레이션 레이어(orchestration layer)가 이제 Python과 .NET 모두에서 1.0에 도달했음을 의미합니다. PyPI에서 직접 버전을 확인할 수 있습니다.

이제 실제로 중요한 질문은 Microsoft Agent와 Flow의 차이입니다. Flow는 사전에 그려놓은 그래프(graph)입니다. 반면 에이전트 오케스트레이션(agent orchestration)은 런타임(runtime)에 그래프를 결정할 수 있습니다. 이 글의 모든 내용은 이 차이점에 기반합니다.

진짜 헤드라인은 버전 번호가 아니라 Microsoft Agent Framework 1.0의 동등성(parity)입니다

다섯 가지 오케스트레이션 패턴(orchestration patterns)이 이제 두 SDK 모두에서 동시에 안정화되었습니다: Sequential(순차적), Concurrent(병렬적), Group Chat(그룹 채팅), Handoff(전달), 그리고 Magentic입니다. 발표 포스트는 언어 간의 동등성(cross-language parity)에 대해 명시적으로 언급하고 있으며, 이것이 바로 기업들이 관심을 가져야 할 부분입니다.

다른 무엇보다 먼저 한 가지 명확히 할 점이 있습니다. 여전히 팀들을 혼란스럽게 만드는 부분인데, Microsoft Agent Framework는 Semantic Kernel과 AutoGen을 하나의 SDK로 통합하는 후속 제품입니다. Microsoft는 프레임워크를 소개할 때 이를 직접적으로 밝혔습니다. 만약 귀하의 아키텍처 검토(architecture review)에서 여전히 이들을 세 가지 경쟁 옵션으로 취급하고 있다면, 그 슬라이드부터 먼저 수정하십시오.

버전 번호보다 기능적 동등성(parity)이 더 중요한 이유: Microsoft 환경에서 Python과 .NET이 혼합된 자산(estates)은 예외가 아닌 표준입니다. 지금까지는 언어를 선택하면 패턴을 포기해야 했거나, 패턴을 선택하면 프리뷰(preview) 패키지에 프로덕션 코드를 맡겨야 하는 상황이었습니다. 이제 두 가지 변명은 모두 사라졌습니다.

여기서 명확히 짚고 넘어가고 싶은 주의 사항이 있습니다. 마지막에 숨겨두지 않고 말씀드리자면, 오케스트레이션(orchestration) API의 1.0 버전이 그 주변의 모든 요소가 1.0임을 의미하지는 않습니다. 오케스트레이션된 에이전트(orchestrated agents) 전반에 걸친 관측성(observability), 비용 할당(cost attribution), 실패 의미론(failure semantics)은 조정 계층(coordination layer)보다 미흡하며, 아래에서 이러한 격차를 자세히 설명하겠습니다. 따라서 SDK 성숙도는 조정 로직 자체에 대한 결정 테이블에서는 대부분 제외되었습니다. 남은 질문은 패턴 적합성(pattern fit)이며, 이것이 더 어려운 문제입니다.

에이전트 오케스트레이션 패턴: 의사결정 프레임워크

아래의 모든 패턴에는 판결이 내려집니다. 중립적인 조사 방식은 팀들이 결국 문서의 첫 번째 예시인 순차적(Sequential) 패턴을 기본값으로 선택하게 만드는데, 공교롭게도 그것이 바로 Sequential입니다.

Sequential은 추출(extract), 변환(transform), 요약(summarize)과 같이 진정한 단계 경계가 있는 파이프라인에 적합합니다. 이는 Agent Framework 문서의 첫 번째 패턴이며, 바로 그 때문에 과도하게 사용되곤 합니다. 만약 당신의 "파이프라인"에 "다음에 무엇을 할지 결정하기"라는 단계가 있다면, 그것은 파이프라인이 아닙니다.

Concurrent는 하위 작업(subtasks)이 진정으로 독립적이고 팬인(fan-in) 단계가 필요할 때, 즉 병렬 문서 분석이나 다각도 검토와 같은 경우에 적합합니다. 비용 구조를 조기에 확인하십시오. 한 분기(branch)의 비용이 X 토큰이라면, 다섯 분기는 집계 비용을 더해 대략 5X가 됩니다. 이는 예시를 위한 계산일 뿐이며, 실제 워크로드에 맞춰 조정하십시오.

**Group Chat (그룹 채팅)**은 심의 루프 (deliberation loops)에 적합합니다. 예를 들어, 작가 에이전트, 비평가 에이전트, 컴플라이언스 (compliance) 에이전트가 출력이 세 가지 조건을 모두 통과할 때까지 논쟁하는 방식입니다. 하지만 엄격한 턴 제한 (turn limit) 없이 이를 배포하는 순간 잘못된 선택이 됩니다. 프로덕션 환경에서 제한 없는 심의는 트리거가 발생하기만을 기다리는 비용 사고 (cost incident)와 같습니다.

**Handoff (핸드오프)**는 라우팅 (routing) 및 에스컬레이션 (escalation)에 적합합니다. 이는 단순히 단계가 추가된 순차적 (Sequential) 방식이 아니며, 이 차이는 매우 중요합니다. 제어권이 고정된 순서가 아닌 런타임 판단 (runtime judgment)에 따라 전달되기 때문입니다. 하지만 가능한 전이 (transitions) 세트가 사전에 열거되어 있으므로, 거버넌스 (governance) 목적으로 볼 때 Handoff는 여전히 그려낼 수 있는 그래프 (drawable graph)로 간주됩니다. 시스템이 어떤 경로를 택할지는 알 수 없더라도, 시스템이 취할 수 있는 모든 경로는 알고 있기 때문입니다.

**Magentic (마젠틱)**은 계획 자체가 런타임에 생성되어야 할 때 적합합니다. 이는 별도의 섹션으로 다룰 가치가 있습니다.

지배 원칙: 문제를 해결하는 데 있어 가장 덜 동적인 (least dynamic) 패턴을 사용하십시오. 필요하지 않은 동적 특성은 결국 비용과 예측 불가능성이라는 대가로 돌아옵니다.

Magentic 오케스트레이션: Agent vs Flow가 실제로 갈라지는 지점

Magentic은 Microsoft Agent vs Flow의 구분이 철학을 넘어 아키텍처 (architecture)가 되는 지점입니다. 다른 모든 패턴은 사용자가 정의한 구조를 실행하지만, Magentic은 구조 자체를 생성합니다.

이 설계는 Magentic-One, Microsoft Research의 범용 멀티 에이전트 시스템으로 거슬러 올라갑니다. 메커니즘을 살펴보면 다음과 같습니다. 리드 오케스트레이터 (lead orchestrator) 에이전트가 수집된 사실과 현재 계획을 담은 태스크 원장 (task ledger), 그리고 각 턴을 평가하여 작업 완료 여부, 진행 상황, 시스템 정체 여부를 확인하는 진행 원장 (progress ledger)을 유지합니다. 오케스트레이터는 해당 상태를 기반으로 다음 에이전트를 선택하며, 정체(stall)가 감지되면 계획을 재수립(replans)합니다. Agent Framework 문서는 이 패턴을 Magentic 오케스트레이션으로 계승합니다. 실행 그래프 (execution graph)는 사전에 정의되는 것이 아니라 LLM에 의해 생성됩니다.

이것이 상태 머신 (state machine)을 명시적으로 선언하는 LangGraph와 같은 정적 그래프 (static-graph) 프레임워크와의 솔직한 비교 지점입니다. 저는 Agent Framework가 LangGraph를 이긴다고 말하지 않을 것입니다. 왜냐하면 그것은 방어 가능한 주장이 아니기 때문입니다. 방어 가능한 주장은 아키텍처 측면에서의 것입니다. 즉, 단계를 사전에 열거할 수 없는 개방형 작업 (open-ended tasks)에서는 동적 계획 (dynamic planning)이 승리합니다. 반면, 단계를 반드시 열거해야 하는 감사 가능하고 재현 가능한 파이프라인 (auditable, reproducible pipelines)에서는 정적 그래프가 승리합니다. Magentic은 재현성을 적응성 (adaptability)과 맞바꾸며, 그 거래의 양면은 모두 실재합니다.

실무자 주의사항: 문서는 Magentic이 예시 작업에 깔끔하게 수렴하는 모습을 보여줍니다. 하지만 프로덕션 환경에서는 매니저가 루프를 돌거나, 공격적으로 재계획 (replanning)을 하거나, 막힌 워커 (worker)를 재평가하느라 턴 (turn)을 낭비할 상황을 대비해야 합니다. 첫 번째 비용 검토를 마친 후가 아니라, 첫날부터 턴 및 반복 제한 (turn and iteration limits)을 설정하십시오. 이것은 버그 보고가 아니라, 모델이 계획을 관리하도록 허용했을 때 발생하는 예측 가능한 결과입니다.

결론은 대칭적입니다. 그래프를 사전에 그릴 수 없을 때는 Magentic을 사용하십시오. 만약 그래프를 그릴 수 있다면, 플로우 (flow)를 원한다는 뜻이며, 그것은 열등한 선택이 아닙니다. 그것은 올바른 선택입니다.

1.0이 여러분의 백로그 (backlog)에 가져올 변화

만약 여러분의 팀이 안정성을 기다리며 멀티 에이전트 (multi-agent) 작업을 보류해 왔다면, 이제 시작해도 좋다는 신호가 떨어졌습니다. 더 정확히 말하면, 단일 에이전트 루프에 덧붙여진 커스텀 오케스트레이션 (custom orchestration)을 위한 변명은 이제 사라졌습니다.

다음은 구체적인 감사 프롬프트 (audit prompt)입니다. 분류 호출 (classification call)을 기반으로 서로 다른 에이전트에게 작업을 할당하는 수동 제작된 라우터 (hand-rolled router), 또는 특정 조건이 충족될 때까지 에이전트 호출 간에 누적된 컨텍스트를 전달하는 while-loop가 코드베이스에 있는지 검색해 보십시오. 만약 둘 중 하나라도 발견한다면, 여러분은 테스트된 종료 처리 (termination handling)와 유지 관리되는 API가 빠진 Handoff 또는 Group Chat을 직접 재구현한 것입니다. 해당 코드가 더 많은 촉수를 뻗기 전에 마이그레이션하십시오.

1.0이 변경하지 않는 또 다른 점은 다음과 같습니다: 애초에 여러 개의 에이전트가 필요한지 여부입니다. 안정적인 오케스트레이션 (Orchestration) API가 존재한다고 해서 반드시 오케스트레이션이 필요한 것은 아닙니다. 다섯 가지 패턴 중 어느 하나라도 채택하기 전에, 에이전트 구축이 완전히 잘못된 경우에 대한 우리의 분석을 통해 문제를 검토하십시오. 훌륭한 도구를 갖춘 단일 에이전트가 근거가 빈약한 군집 (Swarm)보다 언제나 더 낫습니다.

백로그 (Backlog) 작업은 구체적입니다: 이번 스프린트 내에 수동으로 작성된 조정 (Coordination) 코드를 인벤토리화하고, 각 사례를 다섯 가지 패턴 중 하나에 매핑하십시오. 매핑할 수 없는 사례는 설계 결함 (Design smells)으로 간주하십시오.

1.0에서 여전히 부족한 점

조정 (Coordination) API는 안정적입니다. 하지만 그 주변의 운영성 (Operability) 이야기는 그렇지 않으며, 그렇지 않은 척하는 것이 1.0 발표가 새벽 3시의 (장애 대응) 페이지로 변질되는 방식입니다.

에이전트 간 트레이싱 (Cross-agent tracing). 본 문서 작성 시점을 기준으로, 공개 문서는 에이전트별 텔레메트리 (Telemetry)를 다루고 있지만, 핸드오프 (Handoff) 경계, 프로세스 경계, 그리고 비동기 팬아웃 (Async fan-out)을 관통하며 유지되는 퍼스트 클래스 트레이스 (First-class trace)는 Agent Framework 문서가 프로덕션 디버깅에 필요한 수준으로 즉시 제공하지는 않습니다. Magentic 실행이 14번째 턴에서 오작동할 때, 여러분은 해당 실행이 접촉한 모든 에이전트에 걸친 인과 관계 체인을 원할 것입니다. 이러한 상관 관계를 직접 구축하기 위한 엔지니어링 시간을 예산에 반영하십시오.

에이전트별 비용 귀속 (Per-agent cost attribution). 모델 호출당 토큰 (Token) 수는 존재합니다. 하지만 에이전트, 워크플로 (Workflow), 또는 테넌트 (Tenant)별로 합산하는 작업은 자동으로 이루어지지 않으며, 커스텀 태깅 (Custom tagging)과 텔레메트리 차원 (Telemetry dimensions)이 필요합니다. 에이전트의 도구 호출 (Tool calls)에 의해 트리거되는 검색 쿼리나 코드 인터프리터 (Code-interpreter) 샌드박스 시간과 같은 비토큰 (Non-token) 비용은 직접 연결하지 않는 한 보이지 않는 상태로 남습니다. 조직 내에서 비용 배분 (Chargeback)이 중요하다면, 이는 실제적인 작업이 될 것입니다.

실패 및 재시도 의미론 (Failure and retry semantics). SDK 수준의 일시적 재시도 (transient retries) 기능은 존재합니다. 하지만 Magentic 플랜의 에이전트 중 하나가 오류를 발생시키는 대신 의미론적으로 정체(stalls)될 경우, 발행 시점 기준으로 공개 문서에는 이 운영상의 문제에 대해 완전히 명시되어 있지 않습니다. 저는 여기서 동작 방식을 임의로 만들어내지 않겠습니다. 직접 테스트하십시오. 그리고 부수 효과(side-effecting)를 일으키는 도구들에 대한 멱등성 (idempotency) 확보는 여러분의 책임이라고 가정하십시오. 실제로 그러하기 때문입니다.

핵심 요약: 1.0은 조정 (coordination) 측면에서는 1.0이지만, 운영성 (operability) 측면에서는 1.0이 아닙니다. 여러분의 추정치에 이 차이를 반영하십시오.

Azure 배포의 현실

다섯 가지 패턴 모두 SDK가 실행되는 곳이라면 어디에서나 작동하지만, 대부분의 Microsoft 기업 환경에서는 관리형 스레드 (managed threads)와 실행 환경, 그리고 Application Insights로의 OpenTelemetry 트레이스 (traces)를 제공하는 Azure AI Foundry의 Agent Service에 이를 구축하게 될 것입니다. 통합의 깊이를 과장하지 마십시오. 에이전트 간 트레이스 상관관계 (cross-agent trace correlation)가 어디까지 확장되는지는 버전에 따라 다르며, 올바른 방법은 도입을 결정하기 전에 여러분의 관측 가능성 (observability) 요구 사항에 맞춰 일주일간의 스파이크 (spike, 기술 검증)를 통해 이를 검증하는 것입니다.

패턴별 비용 구조는 다음과 같습니다. 모든 수치는 예시일 뿐이므로 여러분의 워크로드에 맞춰 조정하십시오. 병렬 처리 (Concurrent)는 분기 수만큼 병렬 토큰 소비를 배수로 늘립니다. 그룹 채팅 (Group Chat)은 숙의 라운드 (deliberation rounds)가 진행됨에 따라 증가합니다. Magentic은 모든 워커 턴 (worker turn) 위에 플래너 턴 (planner-turn) 오버헤드를 추가하며, 재계획 (replanning)은 이를 더욱 배가시킵니다. 그리고 Foundry 비용은 결코 추론 (inference) 비용만이 아닙니다. AI Search, 그라운딩 (grounding), 스토리지와 같이 연결된 구성 요소들은 별도로 청구되므로, 처음부터 리소스 태깅 (resource tagging)과 사용자 정의 텔레메트리 차원 (custom telemetry dimensions)을 통한 비용 귀속 (attribution)이 필요합니다.

규제 대상 워크로드에서의 Azure 기반 Magentic 오케스트레이션 (Magentic orchestration)

런타임 계획 (Runtime planning)은 사전 승인된 실행 경로를 요구하는 컴플라이언스 체제 (compliance regimes)와 직접적으로 충돌합니다. 만약 감사관이 시스템이 실행되기 전에 취할 수 있는 모든 경로를 확인해야 한다면, LLM이 생성한 계획은 구조적으로 그 테스트를 통과할 수 없습니다. 저의 견해는 이렇습니다. 규제 대상 워크로드에서는 모든 전환이 열거 가능한 (enumerable) Sequential 또는 Handoff 방식으로 시작하십시오. 그리고 턴 제한 (turn limits), 모든 플래너 결정에 대한 감사 로그 (audit logging), 그리고 부수 효과 (side-effecting)를 일으키는 작업에 대한 인간의 체크포인트 (human checkpoints)를 통해 Magentic으로 나아갈 자격을 갖추어야 합니다.

규제 대상 자산의 경우, Bring-your-own storage and search, Private Link, 그리고 관리형 ID (managed identity)를 기본값으로 사용하고, 패턴 선택을 거버넌스 모델 (governance model) 옆에 두는 것이 아니라 모델 내부에 포함시키십시오. 실제 배포를 위한 위험 계층별 에이전트 거버넌스 (risk-tiered agent governance for real deployments)에 대한 당사의 주석 처리된 가이드라인은 이와 직접적으로 연결됩니다. Magentic은 작업의 형태와 관계없이 가장 엄격한 조사가 필요한 최상위 계층 (highest-scrutiny tier)에 속해야 합니다.

배포 시 핵심 요점: 스파이크 테스트 (spike)를 통해 트레이싱 깊이 (tracing depth)를 검증하고, 첫날부터 비용 귀속 (attribution)을 위해 리소스를 태깅하며, Magentic을 그 역동적인 시스템의 특성에 맞게 계층화하십시오.

데모와 프로덕션을 가르는 결정

안정성 문제는 해결되었습니다. 다섯 가지 에이전트 오케스트레이션 패턴, 두 언어 모두 지원, 1.0 버전. 이제 프로덕션 환경의 멀티 에이전트 시스템 (multi-agent systems)과 비용만 많이 드는 데모를 가르는 것은, 여러분이 문제에 맞는 패턴을 매칭했느냐 하는 것입니다.

규칙은 두 문장으로 요약됩니다. 실행 경로를 사전에 열거할 수 있다면, Sequential 또는 Handoff로 플로우 (flow)를 구축하여 감사 가능성 (auditability)을 누리십시오. 만약 열거할 수 없다면, Magentic은 이제 두 언어 모두에서 안정적인 옵션이며, Microsoft가 아직 여러분을 위해 완성하지 않은 관측성 (observability) 및 거버넌스 작업을 위한 예산을 책정해야 합니다.