Microsoft Agent Framework(MAF) 코어 1.0은 2026년 4월 3일 공식 발표됐고, Python orchestration 패턴도 7월 8일 1.0에 도달했다. 처음엔 AutoGen 패키지를 MAF 패키지로 바꾸는 업그레이드처럼 보인다. 그런데 공식 migration guide를 펼치면 반전이 있다. Agent와 tool의 표면은 닮았지만 multi-agent의 중심은 Team과 event-driven runtime에서 typed, graph-based Workflow로 이동한다.
AutoGen 공식 저장소는 현재 maintenance mode이며 신규 기능과 enhancement를 받지 않고, 새 프로젝트에는 MAF를 권한다. 그렇다고 금요일 오후에 패키지를 갈아끼우면 월요일에 운영이 맑아지는 건 아니다. 기존 Team의 종료 조건, 메시지 순서, 저장 상태, 사람 승인, 도구 부작용을 Workflow의 executor·edge·event·checkpoint로 다시 표현해야 한다.
나는 AutoGen에서 MAF로 프로덕션 시스템을 직접 이전한 경험은 없다. 대신 Codex/Obsidian Blog OS에서 direct write → preflight → dry-run → update-url 순서를 운영했고, 파일 읽기·쓰기·외부 발행 권한을 분리하며 로그와 중단 기준을 실제로 적용했다. 이 글은 그 운영 원칙을 공식 migration 문서에 대입한 체크리스트이며, MAF 프로덕션 이전 체험담으로 포장하지 않는다.
이 글은 MCP와 A2A 에이전트에게 회사 권한을 줘도 될까 2026 – 감사 로그 체크표 허브의 하위 글이다. 프레임워크 선택보다 이전 과정의 권한, 관측성, 비용 게이트에 초점을 맞춘다. 연결 표준을 정했다면 이제 “새 runtime이 같은 일을 같은 통제 아래 수행하는가”를 확인할 차례다.
지금 결론
MAF 코어와 orchestration 1.0은 새 프로젝트의 기본 후보로 볼 만하고, AutoGen maintenance mode는 장기 지원 관점에서 이전 계획을 만들 이유가 된다. 다만 multi-agent 이전은 package migration이 아니라 실행 의미의 재설계다. 공식 가이드도 AutoGen의 event-driven core와 high-level Team을 MAF의 typed graph Workflow에 대응시킨다.
따라서 첫 배포는 cutover가 아니라 shadow run이어야 한다. 같은 입력을 기존 AutoGen과 새 MAF에 동시에 넣되, MAF 쪽 write·send·delete·deploy 같은 부작용 도구는 막고 출력, tool call, 승인 요청, 상태 복원, 지연 시간, 비용만 비교한다. 결과가 비슷하다는 이유만으로 전환하지 말고 실패했을 때 같은 지점에서 멈추고 되돌릴 수 있는지까지 봐야 한다.
업계어로 typed Workflow는 타입이 있는 그래프 실행 모델이다. 사람말로 번역하면 “누가 다음 일을 받고, 어떤 형식으로 넘기며, 어디서 멈추는지 계약서에 적는 방식”이다. 현실에서는 AutoGen Team이 대화 흐름으로 넘기던 일을 executor와 edge가 명시적으로 전달한다. 이전 전에 메시지 타입, 종료 조건, 승인 지점, checkpoint 경계를 먼저 문서화해야 하는 이유다.
AutoGen에서 MAF로 바뀌는 운영 모델
단일 Agent 수준에서는 이전 난도가 비교적 낮다. 두 프레임워크 모두 모델 client, instructions, function-style tool, streaming, async I/O라는 익숙한 구성을 쓴다. 차이는 기본 tool iteration과 session 처리에서 시작되고, multi-agent·HITL·checkpoint로 갈수록 커진다.
| 비교 항목 | AutoGen | Microsoft Agent Framework | 이전 때 확인할 것 |
|---|---|---|---|
| Agent | AssistantAgent 중심 |
Agent 중심 |
system message, model client, output schema를 고정 입력으로 대조 |
| tool iteration | 기본 single-turn 성격, max_tool_iterations로 확대 |
final answer까지 여러 tool 호출을 이어가는 multi-turn 기본값 | 무한 반복 방지, 최대 호출 수, 종료 사유 기록 |
| session | model context와 Agent/Team state를 직접 저장·복원 | AgentSession, 외부 저장소 연계 |
대화 기록과 업무 상태를 같은 저장소로 뭉개지 않기 |
| multi-agent | event-driven core + high-level Team |
typed graph Workflow + orchestration builders |
Team 대화를 executor, edge, event, termination으로 재설계 |
| HITL | UserProxyAgent, termination 후 다음 run에서 피드백 |
function tool approval, workflow의 정보 요청·재개 | 승인자, tool arguments, 승인 만료, 거절 후 경로 기록 |
| checkpoint | Team save_state/load_state; 실행 중 저장은 일관성 주의 |
step·superstep 경계 checkpoint, 특정 checkpoint에서 재개 | 중간 부작용과 checkpoint 저장 순서 검증 |
| OTel | OpenTelemetry 기반 runtime·AgentChat tracing 지원 | OTel GenAI conventions 기반 traces·logs·metrics | 동일 run_id, agent, tool, error taxonomy로 이중 계측 |
| MCP | McpWorkbench로 MCP tools/resources 사용 |
MCP tool 연결, hosted MCP와 allowed tools·approval 구성 | 서버 신뢰, allowlist, 인자, 외부 전송 데이터 확인 |
| 권한 | 앱 레이어의 도구 노출과 HITL로 설계 | tool approval과 safety 지침, MCP approval 설정 제공 | read/write/external publish를 별도 정책으로 분리 |
| distributed runtime | standalone + experimental distributed runtime | 현재 single-process composition 중심, distributed execution은 planned | 분산 AutoGen 사용 중이면 MAF로 먼저 옮기지 말 것 |
이 표에서 가장 위험한 행은 multi-agent다. RoundRobinGroupChat을 SequentialBuilder로 바꿨다고 업무 의미가 자동 보존되지는 않는다. 누가 발언할지 정하던 selector, 최대 turn, termination condition, handoff 메시지, 공유 context가 새 edge와 executor 활성화 조건에서 같은 의미를 갖는지 replay해야 한다.
두 번째로 놓치기 쉬운 행은 tool iteration이다. AutoGen에서 한 번만 도구를 부르던 Agent가 MAF에서는 final answer를 만들 때까지 여러 번 호출할 수 있다. 기능이 더 똑똑해진 것처럼 보여도 검색 API를 반복 호출하거나 같은 쓰기 tool을 두 번 실행하면 비용과 부작용이 함께 커진다. SDK 고유 옵션을 가정하지 말고 애플리케이션 레이어의 업무별 tool call 상한, timeout, idempotency key, duplicate suppression을 migration acceptance criteria에 넣어야 한다.
1.0이라고 모든 주변 기능이 같은 안정성은 아니다
2026년 4월 3일 MAF 1.0 공식 발표는 코어 Agent API와 안정화된 Workflow 기반을 프로덕션 후보로 올린 사건이다. 7월 8일에는 Python의 agent-framework-orchestrations가 1.0.0이 되면서 sequential, concurrent, group chat, handoff, magentic orchestration이 Python과 .NET 양쪽에서 1.0 선에 맞춰졌다. AutoGen의 새 기능이 멈춘 상황과 비교하면 이동 방향은 분명하다.
하지만 “MAF 1.0”을 저장소의 모든 package, hosted integration, UI, harness까지 전부 GA라는 뜻으로 읽으면 안 된다. 4월 발표도 DevUI, Foundry hosted agent integration, 일부 Foundry tools·memory·observability·evaluation 연동, UI adapter와 harness 등을 preview 기능으로 따로 구분했다. 실제 도입 때는 사용하는 package와 API 문서의 stable·preview·experimental 표기를 각각 확인해야 한다.
분산 runtime은 더 선명한 예외다. 공식 migration guide는 AutoGen에 embedded runtime과 experimental distributed runtime이 있고, MAF는 현재 single-process composition에 집중하며 distributed execution은 planned라고 적는다. 여러 프로세스나 여러 언어 worker에 이미 의존한다면 maintenance mode만 보고 서둘러 옮기면 기능 회귀가 된다.
권한·관측성·비용을 먼저 고정하기
내 Blog OS에서는 파일을 읽는 권한, 초안을 쓰는 권한, 외부 URL을 갱신하는 권한을 같은 버튼으로 취급하지 않는다. 먼저 direct write로 로컬 산출물을 만들고 preflight와 dry-run을 통과한 뒤에만 update-url 단계로 간다. MAF migration에도 같은 원칙을 적용하면 read tool은 shadow에서 허용하되 write와 external publish는 승인 또는 완전 차단으로 시작할 수 있다.
MAF의 function tool approval은 tool 실행 전 사용자 입력 요청을 반환하고, 승인 또는 거절 메시지로 이어 실행하는 흐름을 제공한다. Hosted MCP 문서도 AllowedTools와 RequireApproval 설정을 보여준다. 다만 승인 기능이 있다는 사실과 올바른 권한 모델을 가졌다는 말은 다르다. 승인 화면에는 tool 이름뿐 아니라 arguments, 대상 resource, 데이터 반출 범위, 되돌리기 가능 여부가 보여야 한다.
관측성은 OpenTelemetry를 켜는 것으로 끝나지 않는다. MAF는 OTel GenAI semantic conventions에 맞춘 traces, logs, metrics를 내보낼 수 있지만, sensitive data 옵션을 프로덕션에서 켜면 prompt, response, function arguments와 result가 로그에 노출될 수 있다. run_id, workflow version, agent name, tool name, approval actor, checkpoint id, retry count, result status는 남기고 비밀키·개인정보·원문 payload는 기본 마스킹하는 편이 안전하다.
비용은 모델 token 단가 하나로 계산하면 migration이 싸게 보이는 착시가 생긴다. shadow run은 한동안 두 runtime을 같이 돌리고 사람이 차이를 검토하므로 reviewer 시간이 실제 비용으로 들어간다. 아래 식을 AutoGen baseline과 MAF shadow 양쪽에 같은 방식으로 적용해야 한다.
월 총비용 = 월 runs × [평균 모델비용/run + 평균 tool·infra비용/run + (reviewer minutes/run ÷ 60 × reviewer 시간당 비용)] + retries 비용 + rollbacks 비용
| 필수 metric | 무엇을 보는가 | migration에서 잡을 경고 신호 |
|---|---|---|
tokens/run |
입력·출력·tool 결과가 소비한 token | 같은 결과인데 baseline보다 지속 증가 |
tool_calls/run |
한 run의 tool 호출 횟수 | 반복 호출, 종료 실패, 중복 쓰기 시도 |
P95 |
end-to-end P95 latency | 평균은 비슷하지만 긴 꼬리가 커지는 현상 |
approvals |
승인 요청 수와 승인·거절 비율 | 사소한 read까지 승인하거나 위험한 write가 무승인 |
reviewer minutes |
사람이 비교·검수한 시간 | 자동화 절감 시간보다 검수 시간이 커짐 |
retries |
모델·tool·workflow 재시도 횟수 | 일시 오류와 논리 오류를 같은 정책으로 재시도 |
rollbacks |
cutover 후 복구 횟수와 성공 여부 | rollback 절차가 느리거나 상태를 복원하지 못함 |
절대 통과 수치를 남의 사례에서 가져오지는 말자. 먼저 현재 AutoGen의 2~4주 baseline을 만들고, 업무 위험도별 허용 폭을 정해야 한다. 고객 발송처럼 부작용이 큰 작업은 rollbacks=0보다 “shadow에서 외부 발송 자체가 0”이어야 하고, 내부 요약처럼 read-only인 작업은 품질과 P95 중심으로 볼 수 있다.
7단 shadow migration 순서
- baseline을 고정한다. 실제 업무에서 개인정보를 제거한 replay set을 만들고 AutoGen의 output schema,
tokens/run,tool_calls/run, P95, 실패 사유, reviewer minutes를 기록한다. - 현재 의미를 목록화한다. Agent instructions, Team 종류, selector, termination condition, state 저장, MCP server, tool 권한, retry와 외부 부작용을 한 표에 모은다.
- 단일 Agent부터 옮긴다. model client와 tool schema를 MAF
Agent로 매핑하고, tool iteration 상한과 session 분리를 먼저 검증한다. 이 단계에서는 multi-agent를 건드리지 않는다. - Team을 typed Workflow로 다시 그린다. executor input/output type, edge 조건, fan-out/fan-in, 종료 이벤트, HITL 위치, checkpoint 경계를 명시한다. 기존 대화 순서를 그대로 흉내 내는 것보다 업무 계약을 보존하는 데 집중한다.
- 권한과 OTel을 먼저 붙인다. read tool만 allowlist에 넣고 write·send·delete·deploy는 차단한다. 두 runtime에 같은
run_id와 metric 이름을 사용해 trace, log, metric을 나란히 비교한다. - shadow run을 돌린다. 동일 replay와 제한된 실제 traffic을 AutoGen과 MAF에 동시에 보내되 MAF 결과는 사용자나 외부 시스템에 반영하지 않는다. output diff, tool diff, approval diff, checkpoint resume, 비용식을 매 run 기록한다.
- canary 후 cutover한다. 사전에 정한 중단 기준을 통과한 read-only 업무부터 일부 traffic을 전환하고, write는 별도 승인 기간을 둔다. rollback 명령, 기존 AutoGen state 보존 기간, 책임자를 확인한 뒤에만 기본 runtime을 바꾼다.
shadow run의 목적은 새 프레임워크가 더 멋진 답을 내는지 겨루는 데 있지 않다. 같은 업무 계약을 지키고, 예상한 승인 지점에서 멈추며, 실패 후 checkpoint에서 복원되고, 비용 경계 안에 들어오는지 확인하는 과정이다. 결과 품질만 비교하면 운영 결함은 cutover 뒤에야 모습을 드러낸다.
중단 기준도 시작 전에 써둬야 한다. write tool 호출 또는 외부 발송 시도, 승인 우회, output schema 파손, checkpoint 재개 후 중복 부작용, 민감정보 로그 노출, P95·비용 허용 폭 초과, rollback 실패 중 하나라도 발생하면 해당 workflow의 전환을 멈춘다. “조금 더 지켜보자”는 문장은 관측 계획이 아니라 회의 연장 버튼이 되기 쉽다.
실수 TOP 7: 실패 포인트는 여기서 나온다
첫 번째 실수는 AutoGen Team 이름과 MAF orchestration builder 이름을 1:1로 치환하는 것이다. 이름이 비슷해도 selector, termination, 공유 state와 message ordering이 달라질 수 있다. 고정 replay에서 event 순서와 최종 output schema를 함께 비교해야 한다.
두 번째 실수는 MAF의 기본 tool iteration 차이를 놓치는 것이다. 호출 상한과 idempotency가 없으면 read API 비용이 튀고 write tool은 같은 작업을 반복할 수 있다. final answer만 맞았다고 통과시키면 중간 비용과 위험을 숨기게 된다.
세 번째 실수는 session, memory, workflow checkpoint를 모두 “기억”으로 묶는 것이다. 대화 context, 장기 지식, 업무 진행 상태, 복구 지점은 보존 기간과 접근 권한이 다르다. 저장소와 삭제 정책도 분리해야 한다.
네 번째 실수는 OTel sensitive data를 편의상 켜둔 채 운영하는 것이다. prompt와 tool arguments를 전부 남기면 디버깅은 편하지만 로그 저장소가 새로운 민감정보 창고가 된다. 개발 trace와 프로덕션 audit log의 payload 수준을 다르게 잡아야 한다.
다섯 번째 실수는 HITL이 있으면 권한 설계가 끝났다고 보는 것이다. 승인자가 arguments와 대상 resource를 못 보면 승인 버튼은 책임만 사람에게 넘긴다. 거절, timeout, 승인 취소, 재승인 경로까지 테스트해야 한다.
여섯 번째 실수는 checkpoint 직전이나 직후의 부작용 순서를 검증하지 않는 것이다. 메일은 발송됐는데 checkpoint 저장이 실패하면 resume 과정에서 같은 메일을 다시 보낼 수 있다. 외부 action에는 idempotency key와 실행 영수증을 남겨야 한다.
일곱 번째 실수는 AutoGen maintenance mode만 보고 distributed workload까지 한 번에 옮기는 것이다. MAF의 현재 single-process 중심 범위와 사용 중인 runtime 요구사항이 다르면 전환 자체가 회귀다. 이런 workload는 분산 실행 대안이 검증될 때까지 AutoGen을 격리 유지하는 편이 낫다.
언제 안 옮겨도 되는가
AutoGen 앱이 read-only 내부 도구이고, 변경 요구가 거의 없으며, 보안 패치와 버그 수정 범위 안에서 운영 수명이 짧다면 즉시 이전하지 않아도 된다. maintenance mode는 당장 실행이 멈춘다는 뜻이 아니다. 이전 비용이 남은 운영 기간보다 크면 dependency pinning, 취약점 모니터링, 종료 날짜를 정한 채 유지할 수 있다.
실험용 연구 코드나 재현성이 더 중요한 논문 prototype도 비슷하다. framework rewrite가 실험 조건을 바꾸거나 검증 시간을 잡아먹는다면 환경을 고정하는 편이 낫다. 다만 새 기능을 계속 붙일 계획이라면 유지가 아니라 기술 부채 연장인지 구분해야 한다.
AutoGen의 experimental distributed runtime에 실제로 의존하거나 여러 프로세스·언어 worker를 운영 중이라면 MAF로의 즉시 이전은 보류 대상이다. 공식 migration guide 기준 MAF distributed execution은 planned이므로, 필요한 기능이 stable로 제공되거나 별도 runtime 설계가 검증될 때까지 기다려야 한다.
반대로 새 multi-agent 프로젝트, 장기 지원이 필요한 사내 시스템, 승인·checkpoint·typed routing을 명시적으로 관리해야 하는 workflow라면 MAF 검토를 미루기 어렵다. 이 경우에도 답은 전면 재작성보다 단일 Agent, read-only Workflow, shadow run, canary 순서다. 이전 속도보다 rollback 가능한 상태를 오래 유지하는 쪽이 운영에는 유리하다.
FAQ
AutoGen이 maintenance mode면 지금 바로 MAF로 옮겨야 하나?
아니다. 신규 기능과 장기 지원이 필요하면 migration plan을 시작하되, 현재 시스템의 수명·변경 빈도·분산 runtime 의존성을 먼저 계산해야 한다. 기존 AutoGen을 pin한 채 shadow MAF를 병행하는 기간이 현실적인 출발점이다.
MAF 1.0이면 multi-agent도 모두 안정 버전인가?
2026년 7월 8일 기준 sequential, concurrent, group chat, handoff, magentic orchestration은 Python과 .NET에서 1.0에 도달했다. 다만 주변 package와 hosted integration, DevUI, harness까지 같은 안정성이라고 단정하면 안 되며 각 문서의 stable·preview·experimental 표기를 확인해야 한다.
Team을 같은 이름의 orchestration builder로 바꾸면 끝나나?
끝나지 않는다. selector, termination condition, 공유 context, message order, state 저장 의미를 executor, edge, event, checkpoint로 다시 표현해야 한다. 고정 replay와 event diff가 필요한 이유다.
shadow run에서는 무엇을 막아야 하나?
MAF 쪽의 write, send, delete, deploy, 결제, 외부 publish를 기본 차단해야 한다. read-only tool도 allowed tools를 최소화하고, 민감 데이터가 외부 MCP 서버나 trace로 나가는지 확인해야 한다.
비용 비교에서 token만 보면 안 되는 이유는 무엇인가?
multi-agent migration은 tool 호출, 긴 P95, 승인 대기, reviewer minutes, retries, rollbacks가 비용을 만든다. 특히 shadow 기간에는 두 runtime을 동시에 실행하므로 모델비용과 검수 인건비를 함께 계산해야 한다.
MAF의 OTel을 켜면 관측성 준비가 끝나나?
OTel은 신호를 내보내는 기반일 뿐 metric 이름, run_id, error taxonomy, 보관 기간, 마스킹 정책은 팀이 정해야 한다. sensitive data 설정은 prompt와 tool arguments를 노출할 수 있으므로 프로덕션 기본값으로 켜두면 안 된다.
checkpoint가 있으면 외부 작업도 안전하게 재개되나?
자동으로 안전해지지 않는다. 외부 작업이 성공한 뒤 checkpoint 저장이 실패하면 resume에서 중복 실행될 수 있다. write tool에는 idempotency key, 실행 결과 영수증, 중복 억제 로직이 함께 필요하다.
가장 먼저 옮길 workflow는 무엇이 좋은가?
내부 문서 조회, 분류, 요약처럼 read-only이며 output schema가 분명한 업무가 좋다. 승인과 checkpoint를 시험할 수 있으면서도 실패가 외부 고객이나 데이터 변경으로 이어지지 않는 workflow를 고르면 된다.
공식 출처
- Microsoft Agent Framework Blog, Microsoft Agent Framework Version 1.0
- Microsoft Agent Framework Blog, Agent Framework’s Orchestration Patterns Reach 1.0
- Microsoft Learn, Microsoft Agent Framework overview
- Microsoft GitHub, AutoGen repository and maintenance mode notice
- Microsoft Learn, AutoGen to Microsoft Agent Framework migration guide
- Microsoft Learn, Microsoft Agent Framework Workflows
- Microsoft Learn, Using function tools with human-in-the-loop approvals
- Microsoft Learn, Agent safety
- Microsoft Learn, MCP and Foundry Agents
- Microsoft Learn, Observability