서론

Microsoft Agent Framework의 오케스트레이션 패턴이 1.0에 도달했다고 발표되었습니다.

이 시리즈에서는 5가지 오케스트레이션 패턴을 하나씩 Microsoft.Agents.AI.Workflows 1.13.0에서 실제로 구동하며 확인하고 있습니다.

이번에는 가장 복잡한 Magentic orchestration 패턴입니다.

Magentic은 전용 관리자(manager)가 계획 수립, 진척 확인, 다음 담당자 선택, 필요에 따른 재계획까지 담당하는 패턴입니다.

다른 4가지 패턴과 달리, "누가", "어떤 순서로" 움직일지를 사전에 고정하지 않고 manager가 그 자리에서 판단합니다.

이 기사에서 알 수 있는 내용:

• Magentic의 관리자(manager)가 계획 작성부터 최종 답변까지 어떻게 행동하는가
• 진척 장부(progress ledger)의 JSON 포맷과 결정론적(deterministic) manager에서의 재현 방법
• 계획 검토(RequirePlanSignoff)를 포함한 다중 에이전트 실행 흐름
• LM Studio의 실제 LLM(google/gemma-4-12b)을 manager로 사용했을 때, 진척 장부를 정말로 반환할 수 있는가

관련 기사

시리즈 목록

환경

검증 코드 전문은 MAF_OrchestrationPatterns_Samples에서 공개하고 있습니다.

이 기사에서 테스트할 내용

이번에 준비한 것은 아래의 2가지 케이스입니다.

Magentic의 흐름은 다음과 같습니다.

스텁(Stub)을 통한 확인

Magentic은 manager의 응답 형식에 강하게 의존하는 패턴입니다.

특히 태스크의 진척 장부에서는 is_request_satisfied, next_speaker, instruction_or_question 등을 기대한 형태로 반환해야 합니다.

internal sealed class MagenticManagerAgent(string name, IReadOnlyList<string> speakerPlan) : ScriptedAgent(name, string.Empty)
{
private int _progressIndex;
...

진척 장부 프롬프트를 감지하면 다음 참여 에이전트 이름을 반환하도록 설정했습니다.

if (_progressIndex < speakerPlan.Count)
{
string speaker = speakerPlan[_progressIndex++];
...

모두가 응답한 후에는 is_request_satisfied를 true로 설정합니다.

이렇게 구성함으로써 Magentic의 진척 장부 이벤트와 참여 에이전트 호출을 안정적으로 관측할 수 있습니다.

구현 코드

simple 케이스에서는 FactAgent를 1회 호출합니다.

static Workflow CreateMagenticSimpleWorkflow(bool requirePlanSignoff)
{
AIAgent manager = new MagenticManagerAgent("MagenticManagerSimple", ["FactAgent"]);
...

complex 케이스에서는 Research, Calc, Writer 순으로 동작시킵니다.

RequirePlanSignoff(true)로 설정하여 계획 검토도 확인하고 있습니다.

static Workflow CreateMagenticComplexWorkflow(bool requirePlanSignoff)
{
AIAgent manager = new MagenticManagerAgent("MagenticManagerComplex", ["ResearchAgent", "CalcAgent", "WriterAgent"]);
...
}

계획 검토는 RequestInfoEvent로 도착합니다.

검증 코드에서는 자동 승인하도록 구현했습니다.

case RequestInfoEvent requestInfo
when requestInfo.Request.TryGetDataAs<MagenticPlanReviewRequest>(out MagenticPlanReviewRequest? reviewRequest)
&& reviewRequest is not null:
...

동작 흐름

simple 케이스입니다.

complex 케이스입니다.

실행 결과

simple 케이스에서는 계획 작성, 진행 상황 장부(progress ledger), FactAgent의 실행, 최종 출력까지 진행되었습니다.

=== magentic/simple ===
magentic-plan:We are working to address the following user request: ...
magentic-ledger:satisfied=False;next=FactAgent;instruction=Please complete your validation step and return a concise result.
...

complex 케이스에서는 계획 검토를 자동 승인한 후, 3개의 에이전트가 순차적으로 동작했습니다.

=== magentic/complex ===
magentic-plan:We are working to address the following user request: ...
plan-review:auto-approve:Plan: ResearchAgent -> CalcAgent -> WriterAgent -> final answer.
...

CalcAgent와 WriterAgent는 전 단계의 이력을 context=[...]로 반환하는 EchoingAgent이기 때문에, 직전까지의 응답이 입력으로 전달된 것도 로그에서 확인할 수 있습니다(긴 줄은 생략했습니다).

계획 검토 자동 승인, 진행 상황 장부를 통한 next_speaker 전환, 3개 에이전트 순차 실행, 최종 출력까지 모두 의도한 대로 진행되었습니다.

summary는 다음과 같습니다. 에이전트 ID에는 실행마다 바뀌는 GUID 접미사가 붙지만, 가독성을 위해 제거했습니다.

magentic/simple: status=ok; agents=FactAgent
magentic/complex: status=ok; agents=ResearchAgent>CalcAgent>WriterAgent

LM Studio에서 실행

여기까지는 결정론적인 manager를 사용하여 SDK 측의 흐름을 확인했습니다.

하지만 Magentic의 진정한 난관은 실제 모델이 진행 상황 장부 JSON을 기대 스키마로 반환할 수 있는지 여부입니다.

LM Studio 상의 LLM을 사용하여 manager와 참여 에이전트의 동작을 확인합니다.

AIAgent manager = CreateAgent(chatClient, "MagenticManager",
"분석과 문서화 팀을 통합하는 오케스트레이션 매니저.",
"You are an orchestration manager. Always follow the requested output format exactly.",
...

실행 결과는 다음과 같습니다(plan은 생략했습니다).

=== magentic ===
prompt: 지난주 매출은 100이었고, 이번 주는 112였습니다. 문의 건수는 15건에서 12건으로 줄었습니다. 증감률을 계산하여 3문장 이내의 일본어 주간 보고서를 작성해 주세요.
magentic-plan: We are working to address the following user request: ...
...

manager는 진행 상황 장부 (progress ledger) JSON을 3회 모두 기대 스키마 (expected schema)에 맞춰 반환하였으며, AnalystAgent

→ WriterAgent

순으로 지시를 내려 최종 답변에 도달했습니다.

2번째 지시 (instruction)에서는 AnalystAgent의 계산 결과(매출 +12%, 문의 -20%)를 반영한 지시가 내려졌으며, 진행 상황을 반영한 동적인 지휘 (dynamic orchestration)가 LLM에서도 작동하고 있음을 보여줍니다.

지시 (instruction)가 영어와 일본어로 혼용되는 것은 로컬 모델다운 동작이지만, 워크플로 (workflow) 진행에는 영향을 미치지 않았습니다.

실행 시간은 약 123초로, 다른 패턴(18~48초)보다 훨씬 길게 나타납니다.

계획 생성, 라운드별 진행 상황 장부, 최종 답변 등 manager 스스로가 여러 번 LLM 호출을 수행하기 때문이며, 이는 Magentic의 비용 구조로서 유념해 두어야 할 점입니다.

manager가 진행 상황 장부를 반환하지 못하면 어떻게 되는가

동작 확인 중에 에이전트의 MaxOutputTokens = 400으로 설정했기 때문에, manager가 진행 상황 장부 JSON을 끝까지 출력하지 못했고, 이는 바로 앞부분에서 경고했던 실패 모드 (failure mode)를 그대로 관찰한 사례입니다.

magentic-plan: We are working to address the following user request: ...
magentic-replan: ... **Root Cause Analysis** The previous ru...
output: [assistant] Task execution stopped due to hitting the maximum reset count limit.

진행 상황 장부를 반환하지 못함 → 정체 (stall) 처리 → 재계획 (replan) → 그럼에도 반환하지 못해 WithMaxResets 상한에서 정지, 라는 흐름입니다.

google/gemma-4-12b는 본문 전에 사고 (reasoning) 토큰을 출력하기 때문에, 400 토큰으로는 사고 과정만으로 상한에 도달했습니다.

manager를 포함한 모든 에이전트의 MaxOutputTokens를 100000으로 늘리면 이 문제가 해결됩니다.

알게 된 점

• Microsoft.Agents.AI.Workflows 1.13.0에서는 Magentic의 계획 생성, 계획 리뷰, 진행 상황 장부, 참여 에이전트 호출, 최종 출력까지 전 과정을 확인할 수 있었습니다. 과거 1.5.0 버전에서 확인했던 ChatMessage의 프로토콜 (protocol) 선언 부족으로 인한 정지 현상은 이번 검증에서는 재현되지 않았습니다.
• 반면, Magentic은 manager의 출력 형식에 강하게 의존합니다. 실제 LLM을 manager로 사용할 경우에는 진행 상황 장부 JSON을 기대 스키마에 맞춰 반환할 수 있는지, next_speaker가 참여 에이전트 이름과 일치하는지를 사전에 확인하는 것이 좋아 보입니다.
• LM Studio의 google/gemma-4-12b를 manager로 사용한 LLM 검증에서는 진행 상황 장부 JSON이 3회 모두 정상 작동하였으며, 계산 → 문장화 → 최종 답변까지 약 123초 만에 완주했습니다. 12B 클래스의 로컬 모델에서도 Magentic은 성립합니다.
• 단, MaxOutputTokens가 부족하면 manager가 진행 상황 장부를 다 출력하지 못해 stall → 재계획 → reset 상한에서 정지하게 됩니다. reasoning 계열 모델에서는 사고 토큰을 위한 여유분이 필수적입니다.

참고

Discussion