2026년 6월 Foundry 릴리스는 에이전트(agents)를 배포하는 비용을 극적으로 낮춰줍니다. 바로 그 점이 문제입니다. Microsoft의 에이전트(agent) 대 플로우(flow) 문제는 플랫폼 팀이 내리는 가장 중대한 아키텍처 결정이었으며, 이번 릴리스는 잘못된 답을 선택했을 때의 위험을 그 어느 때보다 쉽게 배포할 수 있게 함으로써 판돈을 높였습니다.

저의 입장은 이렇습니다: 대부분의 팀은 결정론적 플로우(deterministic flow)가 더 잘 수행할 수 있는 작업에 대해 에이전트(agents)를 과하게 구축합니다. 이번 릴리스는 에이전트(agent)를 구축하는 비용은 낮춰줍니다. 하지만 에이전트(agent)를 운영하거나, 감사하거나, 거버넌스 위원회에 설명하는 비용을 낮춰주지는 않습니다. 이번 릴리스는 배포(shipping) 비용을 낮춥니다. 이는 잘못된 선택을 했을 때의 비용을 높입니다.

실제로 무엇이 출시되었는가, 그리고 왜 Claude가 헤드라인이 아닌가

Foundry 2026년 6월 릴리스는 많은 영역을 다룹니다: Foundry에서 Claude의

대부분의 보도는 Claude의 GA (General Availability, 일반 가용성)를 앞세웠습니다. 제 생각에 이는 핵심을 놓친 것입니다. 최상위 경쟁사의 플래그십 모델을 GA 단계에서 출시한다는 것은 Foundry가 특정 모델 하나가 승리하는 것에 베팅하지 않는다는 신호입니다. 저의 해석은—그리고 이것은 Microsoft가 주장하는 바가 아닌 저의 입장입니다—Foundry가 에이전트(agents)가 구동되는 기질(substrate)로서 스스로를 포지셔닝하고 있다는 것입니다. 여기서 배포(distribution)와 거버넌스(governance)가 해자(moat) 역할을 하며, 모델은 교체 가능한 테넌트(tenants)가 됩니다. 이것이 사실이라고 가정하고 계획을 세우십시오. 왜냐하면 기능 목록은 오직 이러한 관점을 통해서만 의미가 있기 때문입니다.

헤드라인은 Claude가 아닙니다. 헤드라인은 Microsoft가 모델 선택을 지루한 것으로 만들고, 배포를 결정적인 요소로 만들었다는 것입니다.

Microsoft agent vs flow: 솔직한 결정 규칙

Microsoft의 포지셔닝은 에이전트(agents)를 더 유능한 옵션으로, 플로우(flows)를 더 단순한 옵션으로 취급합니다. 하지만 실제 운영(production) 환경에서는 그 관계가 역전됩니다. 감사자(auditor)가 재생할 수 있는 실행별 이력(per-run history)과 함께 한 줄씩 읽을 수 있는 Power Automate flow가, 아무도 완전히 설명할 수 없는 에이전트보다 낫습니다. Foundry agent는 입력값이 비정형(unstructured)이고 다음 단계가 진정으로 추론(reasoning)에 의존할 때에만 그 복잡성을 정당화할 수 있습니다.

결정론(Determinism)이 첫 번째 테스트 기준이지만, 유일한 기준은 아닙니다. 인간의 승인 게이트(approval gates), 트랜잭션성(transactionality), 장애 허용 범위(failure tolerance), 처리량(volume), 커넥터 커버리지(connector coverage), 그리고 데이터 레지던시(data residency)에 대해 질문하십시오. 그리고 비용에 대해서도 질문하십시오. Power Automate는 사용자당 또는 플로우당 라이선스(per-user or per-flow licensing) 방식으로 비용을 청구하므로, 비용은 처리량에 관계없이 대체로 고정되어 있습니다. 반면 Foundry 에이전트는 사용량 기반(consumption)으로 비용을 청구하므로, 실행할 때마다 비용이 변동됩니다. 업계 표준 입력을 사용한 예시 계산을 통해 귀하의 테넌시(tenancy)와 요율에 맞춰 조정해 보십시오. 실제 수치는 다를 수 있습니다. 인보이스 라우팅(invoice-routing)을 10,000번 실행할 때, 플로우당 라이선스 비용은 1월이나 6월이나 동일합니다. 하지만 동일한 10,000번의 실행을 에이전트를 통해 수행하고, 실행당 수천 개의 토큰을 사용한다면 이는 한 달에 수천만 개의 토큰이 되며, 이는 귀하의 모델 요율에 따라 가격이 결정되고 프롬프트 길이, 재시도(retries), 모델 선택에 따라 요동칩니다. 두 수치 중 중요한 것은 금액 그 자체보다 그 형태입니다. 하나는 평면적(flat)이고, 다른 하나는 아무도 예측하지 못한 곡선(curve)입니다.

장애 모드(failure-mode) 행을 두 번 읽어보십시오. 중단되는 플로우는 에러를 발생시키고 멈춥니다. 하지만 중단되는 에이전트는 확신에 차 있고 그럴듯해 보이지만 틀린 답을 내놓으며 계속 진행합니다. 이 단 하나의 차이점이 Build의 모든 기능 슬라이드를 합친 것보다 더 많은 아키텍처 결정의 근거가 되어야 합니다.

다음은 고객 사례가 아닌 세 가지 예시입니다. 인보이스 승인 라우팅: 고정된 경로, 필수 감사 추적(audit trail), 정의된 승인자가 필요합니다. 이 경우 플로우가 승리하며, 여기에 에이전트를 도입하는 것은 이득 없이 확률적 리스크(probabilistic risk)만 추가하는 것입니다. 비정형 지원 이메일을 분류된 티켓으로 분류하는 작업: 자유 형식의 텍스트가 입력되고 판단이 필요합니다. 이 경우 에이전트가 승리하며, 에이전트의 정확성에 대한 신뢰를 쌓는 동안 인간의 검토(human review) 과정을 결합하여 사용하면 됩니다. 기존 이벤트 파이프라인 내의 지연 시간(latency)에 민감한 사기 점수 산정(fraud-scoring) 단계: 밀리초(milliseconds) 단위가 중요하며 데이터 플레인(data plane)이 맞춤형(bespoke)입니다. 이 경우 커스텀 Azure 빌드가 승리하며, 어떤 관리형 에이전트 플랫폼도 이를 바꿀 수 없습니다.

플로우 (flow)를 기본값으로 설정하세요. 플로우의 분기 로직 (branching logic)이 유지 관리하기 어려워질 때만 에이전트 (agent)로 격상하십시오. 이는 더 많은 스위치 케이스 (switch cases)가 아닌 추론 (reasoning)이 필요하다는 정직한 신호입니다.

AI 코파일럿 (copilots) vs 커스텀 Azure 빌드: Teams 게시 방식의 변화

수년간 AI 코파일럿 (AI copilots) 대 커스텀 Azure 빌드 (custom Azure build) 논쟁에서 가장 강력한 논거는 배포 (distribution)였습니다. Teams 내부의 사용자에게 어시스턴트를 제공한다는 것은 봇 등록, 매니페스트 패키징 (manifest packaging), 그리고 관리자 협상 과정을 의미했으며, 이는 팀들이 대신 커스텀 프런트엔드 (custom front ends)로 향하게 만들었습니다. 에이전트 (Agents)가 Teams 및 Microsoft 365 Copilot에 직접 게시 (publishing directly to Teams and Microsoft 365 Copilot)됨에 따라 이러한 작업의 상당 부분이 제거되었지만, 관리자 승인 게이트와 테넌트 카탈로그 정책 (tenant catalog policies)은 여전히 "게시됨"과 "사용자 앞" 사이에 존재합니다.

그렇다면 커스텀 빌드가 여전히 승리하는 경우는 언제일까요? 세 가지 사례가 유효합니다: 플랫폼이 수용하지 않는 맞춤형 (bespoke) 데이터 플레인 (data-plane) 요구 사항, 관리형 인프라를 통한 모델 라운드트립 (model round-trip)이 허용되지 않는 지연 시간 민감 경로 (latency-sensitive paths), 그리고 플랫폼이 노출하지 않는 오케스트레이션 패턴 (orchestration patterns)입니다. 만약 당신의 커스텀 빌드 근거가 배포 (distribution)였다면, 이제 그 근거는 약해졌습니다. 만약 제어 (control)였다면, 그 근거는 여전히 완전히 유효합니다.

게시되었다고 해서 거버넌스(governed)가 되는 것은 아닙니다

Teams에 에이전트가 나타난다고 해서 Teams 내에서 거버넌스 (governed)가 이루어지는 것은 아닙니다. 배포하기 전에, Power Platform DLP 정책 (Power Platform DLP policy)의 소유자가 누구인지, Microsoft Purview를 통해 에이전트의 데이터 처리를 누가 모니터링하는지, 그리고 M365 관리 센터에서 에이전트 수명 주기 (agent lifecycle in the M365 admin center)를 누가 관리하는지를 결정하십시오. 에이전트는 기존 권한이 이미 허용하는 것을 표면화할 뿐입니다. 검색 (search) 기능에서 용인했던 과도한 공유 (oversharing) 문제가 에이전트가 동일한 파일을 대화형으로 제시할 때는 보안 사고 (incident)가 됩니다.

저는 Power Platform governance guardrails에서 이에 필요한 가드레일 레이어 (guardrail layer)에 대해 작성한 바 있으며, 에이전트가 테넌트 (tenant)에 진입하게 되면 그곳의 모든 사항이 두 배로 적용됩니다. 배포는 쉬워졌습니다. 거버넌스 (governance)는 그렇지 않았으며, 이 둘 사이의 간극은 이제 Microsoft의 문제가 아니라 여러분의 문제입니다.

툴박스 (Toolboxes), 루틴 (Routines), 그리고 메모리 (Memory): 기능 속에 숨겨진 거버넌스 이야기

먼저 출처에 대한 주의 사항을 말씀드립니다: 이 글을 쓰는 시점 기준으로 툴박스 (Toolboxes)와 루틴 (Routines)에 대한 공개 문서 (public documentation)는 여전히 부족합니다. 다음 내용은 방향성을 제시하는 것으로 간주하고, 아키텍처 (architecture)를 확정하기 전에 현재의 Microsoft Learn 문서와 대조하여 세부 사항을 확인하십시오.

방향성 측면에서 볼 때, 툴박스 (Toolboxes)와 루틴 (Routines)은 생산성 기능처럼 읽히지만 실제로는 그렇지 않습니다. 툴박스 (Toolbox)는 에이전트가 접근할 수 있는 기능들의 큐레이션된 범위 제한적 컬렉션 (curated, scoped collection)이며, 이는 정책 (policy)이 에이전트마다 매번 재논의되는 대신 도구 부여 (tool-grant) 단계에서 적용될 수 있음을 의미합니다. 루틴 (Routine)은 에이전트가 작업을 수행하는 방식에 대한 선언적이고 검토 가능한 정의 (declarative, reviewable definition)로, 에이전트의 동작을 변경 자문 위원회 (change advisory board)가 실제로 추론할 수 있는 영역으로 이동시킵니다. 이 둘은 기업 IT가 에이전트에 대해 제기하는 가장 큰 반대 의견인 예측 불가능성 (unpredictability)에 대한 Microsoft의 해답입니다. 공개적으로 확인되지 않은 사항은 RBAC 모델 (RBAC model), 버전 관리 보장 (versioning guarantees), 그리고 승인 워크플로 (approval workflows)가 내장되어 있는지 여부입니다. 표준화하기 전에 이러한 질문들을 던지십시오.

에이전트를 확장한 후가 아니라, 확장하기 전에 루틴 (Routines)을 채택하십시오. 이미 배포된 50개의 에이전트에 예측 가능성을 사후 적용하는 것은 재작업 (rewrite)입니다. 처음 3개에 이를 구축하는 것은 템플릿 (template)입니다.

메모리 (Memory)는 가장 중요하지만 화려하지 않은 기능이며, 양날의 검과 같습니다. 세션 전반에 걸친 지속적인 컨텍스트 (context)는 챗봇과 어시스턴트 (assistant)를 구분 짓는 요소이며, 사용자는 이를 즉각적으로 체감합니다. 하지만 지속적인 메모리는 지속적인 데이터 보존 (data retention)을 의미하며, 이는 네 가지 구체적인 책임 (liabilities)을 발생시킵니다. 첫째, 보존 그 자체입니다. 릴리스 블로그가 아닌 Microsoft Learn의 데이터 및 개인정보 보호 문서를 바탕으로 메모리가 어디에 저장되는지, 기본 보존 기간은 얼마인지, 만료 설정이 가능한지 확인하십시오. 둘째, 정보 주체의 권리입니다. 에이전트 메모리에 영향을 미치는 GDPR 삭제 요청은 프로그래밍 방식의 감사 가능한 삭제 경로 (auditable purge path)가 필요하며, 서비스 출시 (go-live) 전에 해당 경로가 존재함을 증명해야 합니다. 셋째, 재현성 (reproducibility)입니다. 과거 에이전트의 결정을 설명하려면 추론 (inference) 시점에 어떤 메모리 상태가 존재했는지 알아야 하므로, 메모리 읽기 및 쓰기가 트레이스 (traces)에 기록되는지 확인하십시오. 넷째, 범위 격리 (scope isolation)입니다. 메모리 범위가 잘못 지정되면 사용자 간에 컨텍스트가 유출되며, 이는 가정이 아닌 테스트 케이스로 다뤄야 할 문제입니다.

별도의 증명이 없는 한, 에이전트가 기억하는 모든 것을 개인정보 (PII)로 취급하십시오. 마케팅 문구는 Purview 감사 (audit)를 통과하지 못하지만, 문서는 통과합니다.

Agent Optimizer: 로드맵이 아닌 관찰 목록 (watch list)

모두가 에이전트 빌더 (agent builders)를 출시합니다. 하지만 거의 아무도 에이전트 평가기 (agent evaluators)를 출시하지 않으며, 이것이 바로 수많은 에이전트가 데모와 프로덕션 (production) 사이에서 사장되는 이유입니다. 프라이빗 프리뷰 (private preview) 단계인 Agent Optimizer는 Microsoft가 이러한 격차를 인정하고 있음을 보여주는 듯합니다. 즉, 에이전트의 동작을 눈으로 대충 확인하는 것이 아니라, 테스트하고 튜닝하기 위한 하네스 (harness) 역할을 합니다.

프라이빗 프리뷰는 아직 확정되지 않았음을 의미합니다. 일반 가용성 (GA) 단계 이전에 변경되거나 사라질 수 있는 기능에 맞춰 3분기 계획을 세우지 마십시오. 오늘날의 컴플라이언스 (compliance) 증거를 위해서는, 제가 프로덕션 전 에이전트 평가하기에서 주장하는 바로 그 규율인, 이미 실행 가능한 GA 평가 도구 및 트레이싱 (tracing)에 기반을 두십시오. Optimizer는 관찰 목록 (watch list)에 넣어두고 GA 시점에 다시 검토하십시오.

구축 전 실행해야 할 결정 게이트 (decision gate)

다음 계획 회의를 "에이전트(agent)를 구축해 봅시다"라는 말로 끝내지 마십시오. 대신 다음의 결정 게이트(decision gate)를 순서대로 적용하고, 첫 번째 탈출 지점(exit)에서 멈추십시오.

1. 실행 경로(execution path)가 고정되어 있고 알려져 있는가? 그렇다면 플로우(flow)를 구축하십시오. 여기서 멈추십시오.
2. 입력값이 비정형 콘텐츠(unstructured content)에 대한 추론(reasoning)을 진정으로 필요로 하는가? 아니라면, 그것은 분기(branch)가 더 많은 플로우(flow)일 뿐입니다. 만약 분기들이 유지 관리하기 어려울 정도로 많아졌다면, 다음 단계로 진행하십시오.
3. 그럴듯하게 틀린 답변(plausible wrong answer)을 허용할 수 있거나, 틀린 답변을 찾을 수 없을 때까지 에이전트(agent)를 인간의 검토(human review)로 감쌀 수 있는가? 둘 다 해당되지 않는다면, 아직 에이전트(agent) 후보가 아닙니다.
4. 지연 시간(latency), 데이터 평면(data-plane), 또는 오케스트레이션(orchestration) 요구 사항이 플랫폼이 제공하는 범위를 초과하는가? 그렇다면 그것은 커스텀 Azure 구축(custom Azure build)이며, 그에 따른 모든 책임을 직접 지게 됩니다.
5. 에이전트(agent)를 출시하기 전에: DLP 소유자 지정, 라이프사이클(lifecycle) 소유자 지정, Learn 문서에 따른 메모리 보유(memory retention) 검증, 삭제 경로(erasure path) 증명, GA 툴링(GA tooling)에서 평가 하네스(evaluation harness) 실행 완료.

제가 알고 있는 가장 좋은 프로덕션 패턴은 확률적 핵심(probabilistic core)을 둘러싼 결정론적 래퍼(deterministic wrapper)입니다. 즉, 플로우(flow)가 트리거(trigger), 승인(approvals), 감사 추적(audit trail)을 담당하고, 에이전트(agent)는 중간의 판단(judgment call)만을 담당하는 것입니다. Microsoft는 방금 여러분에게 에이전트(agent)를 더 빠르게 출시할 수 있는 방법을 제공했습니다. 이 게이트(gate)를 실행하십시오. 여러분이 무엇을 구축하지 않기로 선택하느냐가 무엇을 구축하느냐보다 더 중요할 것입니다.

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