Microsoft Agent vs Flow: What Foundry's June 2026 Release Really Decides for You

개요

Microsoft의 Foundry 2026년 6월 릴리스는 에이전트 개발 비용을 낮추지만, 잘못된 아키텍처 선택의 위험성을 증가시킨다.

주요 내용

* Foundry 2026년 6월 릴리스의 주요 특징:
* Claude 모델의 일반 가용성(GA) 달성
* 에이전트의 Teams 및 Microsoft 365 Copilot 직접 게시 기능
* Toolboxes 및 Routines 확장
* Memory 업데이트
* Agent Optimizer (프라이빗 미리보기)
* Foundry Agent Service, Copilot Studio, Microsoft 365 Copilot, Power Automate Flow의 구분: 각 서비스는 고유한 목적과 거버넌스 경계를 가지므로, 혼동 시 잘못된 아키텍처 설계로 이어질 수 있다.
* Microsoft의 포지셔닝: Foundry는 모델에 관계없이 에이전트가 실행될 수 있는 기반(substrate)을 제공하며, 유통(distribution)과 거버넌스가 핵심 경쟁력임을 시사한다.
* 에이전트 vs. Flow 아키텍처 결정 규칙:
* 결정성(Determinism): 실행 경로가 고정되고 알려진 경우 Power Automate Flow가 더 적합하다.
* 복잡성: 비정형 데이터에 대한 추론이 필요한 경우 에이전트가 유리하나, human review로 대체 가능한 경우 Flow가 더 안전할 수 있다.
* 가청성(Auditability): Flow는 라인별 추적이 가능하며 감사자가 검토하기 용이한 반면, 에이전트는 설명하기 어렵다.
* 비용 모델: Flow는 사용자/플로우 라이선스 기반으로 비용이 고정적인 반면, 에이전트는 사용량 기반으로 비용 변동성이 크다.
* 실패 모드: Flow는 오류 발생 시 중단되지만, 에이전트는 그럴듯하지만 잘못된 답변을 내놓고 계속 실행될 수 있다.
* Teams 게시의 영향: 에이전트가 Teams에 직접 게시되는 기능은 유통의 장벽을 낮췄지만, 여전히 관리자 승인 및 테넌트 정책 준수가 필요하다.
* 거버넌스: 에이전트가 Teams에 노출되더라도 거버넌스는 별도로 관리해야 하며, Power Platform DLP, Microsoft Purview, M365 관리 센터에서의 관리가 중요하다.
* Toolboxes 및 Routines: 에이전트의 예측 불가능성을 완화하는 기능으로, 정책 적용 및 작업 실행 정의에 도움을 줄 수 있다.
* Memory: 세션 간 지속적인 컨텍스트를 제공하지만, 데이터 보존, 개인정보보호, 재현성, 범위 격리 등의 문제를 야기할 수 있다.
* Agent Optimizer: 에이전트의 테스트 및 튜닝을 위한 도구로, 향후 발전 가능성이 있으나 현재는 프라이빗 미리보기 상태이다.
* 에이전트 구축 전 결정 게이트:
1. 실행 경로가 고정/인지 가능한가? (아니면 Flow)
2. 비정형 콘텐츠에 대한 추론이 필요한가? (아니면 Flow with more branches, 복잡하면 에이전트 고려)
3. 그럴듯한 잘못된 답변을 허용하거나 human review를 적용할 수 있는가? (아니면 에이전트 부적합)
4. 레이턴시, 데이터 플레인, 오케스트레이션 요구사항이 플랫폼을 초과하는가? (예: Custom Azure build)
5. 에이전트 배포 전 DLP, 수명 주기 소유자 지정, 메모리 보존 검증, 삭제 경로 증명, 평가 도구 실행 등의 절차를 거쳤는가?

시사점

Foundry 2026년 6월 릴리스는 에이전트 개발을 용이하게 했으나, 아키텍처 결정 시에는 기능뿐만 아니라 운영, 감사, 거버넌스, 비용 효율성을 종합적으로 고려해야 하며, 결정적인 상황에서는 Power Automate Flow나 Custom Azure build가 더 나은 선택일 수 있다.