Microsoft Agent와 Flow 사이에서 고민하는 대부분의 팀은 잘못된 질문을 던집니다. 그들은 "Flow가 이것을 할 수 있는가?"라고 묻습니다. 충분한 조건과 중첩된 범위(nested scopes)가 주어진다면, 그 대답은 거의 항상 "예"입니다. 실제로 중요한 질문은 이것입니다: "작업이 실행되는 동안 경로가 변하는가?"

이 한 문장이 모든 차이를 설명합니다. Flow는 사전에 그려둔 그래프(graph)를 실행합니다. Agent는 런타임(runtime)에 그래프를 결정합니다.

지금 이 문제를 정리해야 하는 이유는 Agent Framework DevBlogs 공지에 따르면, Microsoft Agent Framework의 오케스트레이션(orchestration) 패턴이 Python에서 1.0 버전에 도달하여 .NET과 동일한 수준이 되었기 때문입니다. 이제 오케스트레이션은 매 분기마다 다시 작성해야 하는 프리뷰(preview) 단계가 아니라, 안정적인 의존성(dependency)이 되었습니다. 무언가를 고정(pin)하기 전에 PyPI와 NuGet에서 정확한 패키지 버전을 직접 확인하십시오. 해당 공지는 오케스트레이션 패턴을 다루는 것이지, 프레임워크 전체를 다루는 것이 아닙니다.

만약 화이트보드에 전체 경로를 그릴 수 있다면, 당신에게 필요한 것은 Agent가 아니라 Flow입니다.

"1.0"이 Microsoft에 실제로 약속하는 것

오케스트레이션 패턴의 1.0 버전은 계약(contract)이 더 이상 요동치지 않음을 의미합니다. Semantic Kernel과 AutoGen의 프리뷰 기간을 겪어본 팀들은 그 비용을 잘 알고 있습니다. SDK가 업데이트될 때마다 오케스트레이션 코드가 깨졌고, 그래서 아무도 강력한 의존성을 구축하지 않았으며, 결국 어떤 것도 프로덕션(production) 단계에 도달하지 못했습니다. 1.0은 바로 그 비용을 제거합니다. 이제 Microsoft Agent Framework 문서는 재작성 예산을 책정할 필요 없이 구축할 수 있는 인터페이스를 설명합니다.

여기 공지사항에서 알려주지 않는 주의사항이 있습니다. 안정화된 인터페이스는 API입니다. 당신의 프롬프트(prompts), 평가(evals), 가드레일(guardrails), 비용 제어(cost controls)는 여전히 당신의 몫이며, 1.0은 이것들을 안정화하는 데 아무런 역할도 하지 않습니다. 문서는 이를 프로덕션 준비 완료(production-ready)라고 표현하며, 오케스트레이션 계약 측면에서는 공정한 설명입니다. 하지만 에이전트 전체 관점에서는 그렇지 않습니다.

솔직한 프레임링(framing)은 다음과 같습니다: 1.0 버전은 지배적인 리스크를 "SDK가 내 밑에서 깨지는 것"에서 "나의 설계가 잘못된 것"으로 전환합니다. 그것이 바로 당신이 원하는 리스크입니다. 왜냐하면 그것은 당신이 통제할 수 있는 것이기 때문입니다.

Microsoft Agent Framework 1.0을 강력한 의존성(hard dependencies)을 구축해도 좋다는 허가로 간주하십시오. 하지만 이를 가드레일(guardrails)을 건너뛰어도 좋다는 허가로 간주해서는 안 됩니다.

Microsoft agent vs flow: 결정 테이블

표를 보기 전에 한 가지 명확히 할 점이 있습니다. Power Automate와 Logic Apps는 둘 다 결정론적 흐름(deterministic flows)을 실행하지만 동일한 것은 아닙니다. Power Automate는 Power Platform 내에 존재하며, 메이커(maker)가 소유하고, 환경(environments) 및 DLP 정책을 통해 관리됩니다. Logic Apps는 Azure 리소스이며, 엔지니어가 소유하고, ARM 및 표준 Azure RBAC을 통해 관리됩니다. 결정론(determinism)에 대한 논거는 양쪽 모두에 적용되지만, 거버넌스(governance) 이야기는 다르며, 이는 로직을 누가 소유할지 결정할 때 중요합니다.

강력한 입장은 다음과 같습니다: 예측 가능하고, 감사 가능하며, 대량의 단계가 필요한 작업에서는 flow가 승리합니다. Flow 실행 기록은 어떤 분기(branch)가 왜 실행되었는지 정확히 보여주며, 감사관(auditors)들은 이를 매우 선호합니다. 에이전트(Agents)는 다음 단계가 사전에 열거할 수 없는 중간 결과에 의존할 때 승리하며, 이는 바로 flow의 조건 트리(condition tree)가 유지 관리 불가능한 덤불로 변하는 지점입니다. 저는 에이전트를 아예 구축하지 말아야 할 때에 절제를 위한 더 긴 논거를 제시한 바 있으며, 그 논거는 여전히 유효합니다.

기본값은 flow로 설정하십시오. 분기(branching)가 진정으로 경계가 없을 때에만 에이전트를 고려하십시오.

Magentic은 에이전트가 단순한 화려한 flow가 아닌 이유입니다

Magentic 오케스트레이션 (orchestration) 패턴은 에이전트 측면의 논의를 단순한 열망이 아닌 실질적인 현실로 만드는 요소입니다. Microsoft의 Magentic-One 연구로 거슬러 올라가는 이 패턴은 다음과 같이 작동합니다: 리드 오케스트레이터 (lead orchestrator)가 목표를 받아 이를 계획으로 분해하고, 각 단계를 전문 에이전트 (specialist agents)에게 위임하며, 매 턴마다 돌아오는 결과를 검사하고, 실제로 진전이 이루어지고 있는지 추적합니다. 진전이 정체되면 멈추지 않고, 계획을 다시 세웁니다 (replans).

하나의 실패 시나리오를 살펴보겠습니다. 전문 에이전트가 차단된 도구 호출 (tool call)에 직면하는 경우입니다: API가 403 오류를 반환하거나, 문서가 누락되거나, 쿼리 결과가 비어 있는 상황입니다. 이를 위한 별도의 예외 경로 (exception path)는 없습니다. 실패는 진전의 부재로 나타나고, 오케스트레이터의 정체 감지 (stall detection) 기능이 작동하며, 오케스트레이터는 막힌 길을 우회하는 수정된 계획을 생성합니다. 인간의 개입은 전혀 없었습니다. 반면 동일한 상황에서 플로우 (flow)는 예외를 발생시키고, 정책에 따라 재시도(retry)를 하다가, 다시 예외를 발생시키고 멈춰버립니다. 누군가는 내일 실패한 실행에 대한 이메일을 읽게 될 것입니다.

이것이 바로 역량의 격차입니다. 또한 비용의 격차이기도 합니다.

자율적 재계획 (Autonomous replanning)에는 비용이 따릅니다

모든 오케스트레이션 라운드는 최소 한 번의 오케스트레이터 모델 호출과 전문 에이전트의 호출 비용이 발생하며, 매 턴마다 컨텍스트 (context)가 커지고, 재계획 시 업데이트된 상태에서 계획 수립을 다시 실행합니다. 제한을 두지 않으면, Magentic 오케스트레이션 패턴은 어려운 문제에서 루프를 돌며 토큰을 소모할 것입니다. 첫 프로덕션 실행 전에 최대 라운드 횟수와 정체 임계값 (stall threshold)을 설정하십시오. 선택하는 구체적인 수치는 직접 조정해야 합니다. 공개된 벤치마크 (benchmarks)는 없으므로, 온라인에서 보는 모든 수치는 예시로만 간주하십시오.

가변 비용과 지연 시간 (latency)을 감당할 수 있고, 반드시 중단 조건 (hard stop)이 설정된 경우에만 Magentic을 사용하십시오. 만약 귀하의 예산 모델이 실행당 고정 비용을 가정한다면, 플로우 (flow)를 원했던 것입니다. 워크로드가 스스로 재계획을 수행할 때, 지출 한도 거버넌스 문제는 완화되는 것이 아니라 더욱 날카로워집니다.

.NET과 Python 간의 동등성으로 스택 비용 제거

지금까지 멀티 에이전트 오케스트레이션 (multi-agent orchestration)을 수행하는 Azure 팀들은 불합리한 선택을 해야 했습니다. 플랫폼 팀이 다른 언어를 사용하더라도, 오케스트레이션 SDK (orchestration SDK)가 더 앞서 있는 언어를 선택해야만 했습니다. DevBlogs 포스트는 Python과 .NET 모두에서 오케스트레이션 패턴이 1.0 단계에 도달했음을 확인해주며, 이는 발표된 패턴들에 대해 더 이상 그러한 선택을 할 필요가 없음을 의미합니다.

실질적인 가이드는 지루하지만 정확합니다. 플랫폼 팀이 이미 운영하고, 배포하며, 새벽 3시에 디버깅(debug)할 수 있는 언어를 선택하십시오. 더 화려한 샘플 저장소(sample repository)를 가진 언어를 선택하지 마십시오. 샘플은 호출기(pager)를 들고 뛰어다니지 않습니다.

이제 언어 선택은 오케스트레이션 성숙도(orchestration-maturity)의 결정이 아니라, 팀의 결정 사항입니다.

현재 에이전트가 플로우(flow)를 압도하는 지점

1.0 단계에서 진정으로 실행 가능한 세 가지 패턴이 있으며, 각 패턴에는 실제 복잡성(complexity)이 발생할 때 무너지는 플로우(flow) 형태의 대안이 존재합니다.

다단계 조사 및 합성 (Multi-step research and synthesis). 소스를 수집하고, 관련성을 평가하며, 자료가 부족한 부분을 더 깊이 파고들고, 합성합니다. 플로우(flow) 버전은 어떤 소스에 접속할지를 하드코딩(hardcode)하며, "이 소스가 쓸모없는 것으로 밝혀졌다"와 같은 상황에 반응할 수 없습니다. 에이전트(agent) 버전은 경로를 재설정(reroute)합니다.

재경로 설정을 포함한 자율적 장애 분류 (Autonomous incident triage with reroute). 이것은 제대로 설계해 볼 가치가 있는 패턴입니다. 왜냐하면 재계획(replanning)이 그 비용만큼의 가치를 창출하는 지점이기 때문입니다:

1. 오케스트레이터(Orchestrator)가 경고 수신: 분류 작업을 계획으로 분해합니다: 로그 추출, 최근 배포 확인, 서비스 상태 API(service health API) 쿼리, 상관관계 분석.
2. 전문가 에이전트(Specialist agents)의 병렬 실행: 로그 에이전트, 변경 에이전트, 상태 에이전트가 각각 도구 호출(tool calls)을 실행하고 결과를 보고합니다.
3. 경로 차단: 서비스 상태 API가 타임아웃(timeout)됩니다. 오케스트레이터는 재시도 후에도 해당 브랜치에서 진전이 없음을 기록합니다.
4. 실패가 아닌 재계획: 오케스트레이터는 경로를 재설정합니다: 대신 로그 에이전트의 에러율(error-rate) 데이터를 통해 서비스 상태를 추론하고 계속 진행합니다.
5. 제한된 종료 (Bounded finish): 신뢰도 노트와 함께 분류 요약이 게시되거나, 라운드 제한(round cap)에 걸려 인간이 전체 추적(traces)이 포함된 부분적인 결과를 받게 됩니다.

Flow의 대안은 당신이 예측한 모든 실패 모드(failure mode)에 대해 '실행 후 처리(run-after)' 핸들러를 갖춘 40개의 액션으로 구성된 Logic App입니다. 이는 당신이 예측하지 못한 실패 모드에서는 실패합니다.

콘텐츠 의존적 승인 라우팅 (Content-dependent approval routing). 라우팅 결정이 메타데이터가 아닌 문서의 실제 내용에 따라 달라질 때, Flow의 조건 트리(condition tree)는 정책당, 문서 유형당 하나의 브랜치를 추가하며 확장됩니다. 에이전트는 이를 읽고 라우팅합니다.

그 차이는 당신의 테넌트(tenant) 내에서도 명확히 보입니다. 만약 당신의 "Flow"에 이미 15개의 조건부 브랜치와 3단계 깊이의 중첩된 범위(nested scopes)가 있다면, 그것은 Flow의 탈을 쓴 에이전트입니다.

아무도 광고하지 않는 격차: 도구가 아닌 운영 성숙도

여기 불편한 의견이 하나 있습니다. 프레임워크의 발전 속도가 대부분의 조직이 이를 운영할 수 있는 능력보다 더 빨랐다는 점입니다. 평가 하네스(eval harness)가 뒷받침되지 않은 1.0 SDK는 여전히 통제되지 않는 에이전트를 배포합니다. 안정적(Stable)이라는 것이 안전(Safe)함을 의미하지는 않습니다.

운영 환경에서 자율적인 재계획(autonomous replanning)을 신뢰하기 위한 최소 기준은 다음과 같습니다: OpenTelemetry를 통해 Application Insights로 이어지는 단계별 추적(per-step tracing), 테스트가 머지(merge)를 제어하는 방식처럼 배포를 제어하는 평가 하네스(eval harness), 시스템 기록(system of record)에 닿는 모든 출력에 대한 스키마 검증(schema validation), 그리고 실제로 테스트를 거친 킬 스위치(kill switch)입니다. 이 중 하나라도 놓친다면, 정직한 구성은 실행 시 인간의 승인을 거치는 '제안 전용 모드(suggest-only mode)'여야 합니다. 저는 AgentOps decode에서 에이전트 관찰 가능성 및 평가(agent observability and evals)가 파이프라인으로서 어떻게 구성되는지 살펴보았습니다. 요약하자면, 하네스는 있으면 좋은 기능이 아니라 인프라 그 자체입니다.

사고가 발생한 후가 아니라, 에이전트를 만들기 전에 평가 하네스(eval harness)를 구축하십시오.

1.0이 보통 예고하는 것

로드맵에 대한 주장이라기보다 패턴 기반의 기대치입니다. Microsoft가 오케스트레이션 계약(orchestration contract)을 안정화하면, 더 깊은 플랫폼 통합이 뒤따르는 경향이 있습니다. 향후 몇 번의 릴리스를 거치면서 Azure AI Foundry 통합 스토리와 에이전트 관련 거버넌스 도구(governance tooling)가 더욱 강화될 것으로 예상됩니다. 안정적인 계약이야말로 호스팅된 런타임(hosted runtimes)과 정책 계층(policy layers)이 구축을 위해 필요로 하는 바로 그것이기 때문입니다.

Microsoft의 에이전트(agent) 대 플로우(flow) 선택은 이제 기능 비교가 아닌 성숙도 테스트입니다. 플로우(Flows)는 당신이 직접 그릴 수 있는 경로를 위한 것이고, 에이전트(Agents)는 스스로 결정하는 경로를 위한 것입니다. 먼저 구축한 관측성(observability) 없이는 어느 쪽도 안전하지 않습니다. 완전히 추적 가능하고 완전히 중단할 수 있는 하나의 제한된 에이전트 유스케이스(agent use case)로 시작하여, 하네스(harness)가 작동함을 증명한 후에 확장하십시오. 후속 글에서는 Magentic으로 무엇을 먼저 구축해야 하는지를 다룰 예정이며, 그 답은 생각보다 작을 것입니다.

이 기사는 원래 az365.ai에 게시되었습니다. 저는 Alex Pechenizkiy이며, Microsoft AI 스택에 대해 정직하고 벤더 중립적인 분석을 작성하는 Azure 및 Power Platform 솔루션 아키텍트입니다. 더 자세한 내용은 az365.ai에서 확인하세요.