한 팀장이 기획 회의에서 질문을 던지자 회의실의 의견이 세 갈래로 나뉩니다. 이 에이전트를 Copilot Studio에서 만들 것인가, 오케스트레이션 (orchestration)을 직접 작성하여 호스팅할 것인가, 아니면 우리의 컨테이너를 Foundry에 전달하여 코드를 실행하게 할 것인가? 이 세 가지 모두 2026년 기준 Microsoft의 공식 빌드 경로이며, 세 가지 모두 결국 동일한 테넌트 전역 에이전트 인벤토리에 포함됩니다. 하지만 잘못된 선택을 하면 프로젝트가 확장되었을 때 재구축 비용이 발생합니다.

정답은 "가장 강력한 것"이 아닙니다. 정답은 서비스 모델이 에이전트를 누가 만드는지, 런타임 (runtime)을 누가 소유하는지, 그리고 오케스트레이션과 프로토콜 (protocols)에 대해 실제로 어느 정도의 프로코드 (pro-code) 제어가 필요한지와 일치하는 것입니다. 이 글은 Microsoft Learn에 근거하여 2026년 중반 기준 최신 정보를 바탕으로 작성된 해당 선택을 위한 의사결정 프레임워크입니다.

이 세 가지 경로 중 두 가지는 퍼블릭 프리뷰 (public preview) 상태이므로, 이 가이드는 운영 안정성 점수표가 아닌 아키텍처 적합성과 방향성에 대한 안내서입니다.

요약 (TL;DR)

세 가지 빌드 경로는 성능이 아닌 서비스 모델에 따라 선택됩니다.

• Copilot Studio: 메이커 (maker)를 위한 로우코드 (low-code) 관리형 SaaS. GA (General Availability).
• Foundry Hosted 에이전트: 자체 컨테이너를 위한 관리형 PaaS 런타임. 퍼블릭 프리뷰 (public preview).
• Microsoft 365 Agents SDK: 프로코드 (pro-code), 셀프 호스팅 (self-hosted), 가장 넓은 채널 도달 범위. 에이전트 프레임워크 (Agent Framework) 오케스트레이터는 퍼블릭 프리뷰 (public preview) 상태.

월요일의 실행 과제 (Monday move): 플랫폼을 선택하기 전에 이 에이전트에 대해 네 가지 사항을 적어보세요. 누가 만드는가 (메이커 또는 프로 개발자), 누가 컴퓨팅 자원을 소유해야 하는가, 도달해야 하는 채널은 무엇인가, 그리고 커스텀 프로토콜이나 백그라운드/비동기 (async) 동작이 필요한가. 이 네 가지 답변이 기능 체크리스트보다 더 확실하게 경로를 결정해 줄 것입니다.

각 경로를 한 단락씩 설명

Microsoft의 자체 Cloud Adoption Framework (CAF)는 구축 옵션을 세 가지 서비스 계층으로 정의하며, 이는 시작하기에 가장 깔끔한 사고 모델(mental model)을 제공합니다. CAF는 이를 Copilot Studio (SaaS, no/low-code), Microsoft Foundry (PaaS, pro-code 또는 low-code), 그리고 GPU 및 컨테이너 (IaaS, 최대 유연성을 위한 code-first 프레임워크)로 분류합니다. 처음 두 가지는 Microsoft가 관리합니다. 세 번째는 컴퓨팅을 엔드 투 엔드(end to end)로 직접 소유하는 self-hosted SDK 경로가 위치하는 곳입니다.

Copilot Studio는 Power Platform 세트에 포함된 에이전트 및 에이전트 흐름(agent flows) 구축을 위한 그래픽 기반의 low-code 도구입니다. Microsoft는 이를 제작자가 인프라, 호스팅 또는 거버넌스에 대해 걱정할 필요 없이 에이전트 경험에 집중할 수 있는 완전 관리형 SaaS 플랫폼으로 설명합니다. 이는 사전 구축된 커넥터 또는 사용자 정의 커넥터를 통해 데이터에 연결되며, 단독으로 실행될 수 있고, 엔터프라이즈 데이터를 통해 Microsoft 365 Copilot을 확장할 수 있습니다.

Foundry Hosted 에이전트는 중간 경로입니다. Foundry Agent Service는 에이전트를 구축, 배포 및 확장하기 위한 관리형 플랫폼이며, 두 가지 에이전트 유형을 제공합니다: Prompt 에이전트 (완전 관리형, 코드 또는 컴퓨팅 유지 관리 필요 없음) 및 Hosted 에이전트 (사용자 정의 컨테이너화된 코드, Foundry가 관리형 엔드포인트, 확장성, ID 및 관측성(observability)과 함께 실행). Hosted 에이전트는 오케스트레이션(orchestration) 코드는 유지하고 싶지만 서버는 직접 운영하고 싶지 않은 전문 개발(pro-dev) 팀이 관심을 가질 만한 옵션입니다.

Microsoft 365 Agents SDK는 셀프 호스팅(self-hosted) 방식의 프로 코드(pro-code) 경로입니다. 개발자가 원하는 AI 스택을 사용하여 커스텀 엔진 에이전트를 구축하고 이를 Microsoft 365 Copilot에 배포할 수 있게 해줍니다. 이는 모델 및 오케스트레이터(orchestrator)에 구애받지 않으며, Microsoft 365 Copilot, Teams, 제3자 플랫폼, 커스텀 애플리케이션 및 웹사이트 전반에 걸쳐 에이전트를 노출할 수 있습니다. 다만, 오케스트레이션(orchestration) 프로세스를 직접 호스팅해야 한다는 점이 트레이드오프(trade-off)입니다.

비교에 앞서, 요약본에서 미결 사항으로 언급되었기에 한 가지 참고 사항을 말씀드립니다. Foundry는 동일한 에이전트 서비스(Agent Service) 내에서 완전 관리형 노코드 런타임(no-code-runtime) 옵션인 프롬프트 에이전트(Prompt agents)도 제공합니다. 본 기사는 제목에서 언급한 세 가지 구축 경로를 다룹니다. 프롬프트 에이전트는 Foundry 에이전트 서비스 내의 별도 관리형 옵션이며, 커스텀 코드가 전혀 필요하지 않다면 이는 호스팅(Hosted) 경로와 경쟁하는 것이 아니라 Copilot Studio와 함께 낮은 노력(low-effort)의 선택지로 나란히 존재합니다.

여기서 "인 프로세스(in-process)"가 실제로 의미하는 것

"인 프로세스(In-process)"는 이번 비교에서 사람들이 혼동하기 쉬운 부분이므로 명확히 짚고 넘어갈 가치가 있습니다. 여기서 인 프로세스란 Microsoft 365 Agents SDK를 사용하는 셀프 호스팅 경로를 의미합니다. 이는 컨테이너를 Foundry에 넘기거나 Copilot Studio에서 선언적(declaratively)으로 구축하는 대신, 사용자가 소유하고 호스팅하는 프로세스 내부에서 에이전트의 오케스트레이션을 실행하는 것을 뜻합니다. 두 가지 요소가 중요합니다.

첫 번째는 호스트(host)입니다. Microsoft 365 Agents SDK를 사용하면, 사용자의 Program.cs가 호스팅을 관리하고 (예: C#의 ASP.NET 호스트), 스토리지를 등록하며 (샘플은 메모리 스토리지(Memory Storage)를 사용하지만, 운영 환경에서는 Blob 또는 Cosmos DB로 전환 가능), api/messages 엔드포인트를 라우팅합니다. 사용자는 일반적으로 Azure에서 에이전트 자체와는 별개로 해당 컴퓨팅 자원을 프로비저닝하고 비용을 지불합니다.

두 번째는 해당 호스트 내부에서 실행되는 오케스트레이터 (orchestrator)입니다. Semantic Kernel 및 Microsoft Agent Framework 모두 Agents SDK 에이전트 내부의 오케스트레이터가 될 수 있습니다. Semantic Kernel은 SDK 내에서 오케스트레이션 패턴(Concurrent, Sequential, Handoff, Group Chat, Magentic)을 직접 구현하며, Microsoft.SemanticKernel.Agents.Runtime.InProcess 패키지를 통해 인프로세스 (in-process) 런타임을 제공합니다. 바로 이

아직 배포한 적이 없다면, 아래의 여러 의사결정을 주도하는 Hosted 에이전트 런타임 모델을 이해할 가치가 있습니다. Foundry Hosted 에이전트는 컨테이너화된 에이전트 애플리케이션 (agentic applications)입니다: 에이전트를 컨테이너 이미지로 패키징하여 Azure Container Registry에 푸시하면, 배포 시점에 Agent Service가 이미지를 가져오고, 컴퓨팅 리소스를 프로비저닝하며, 전용 Microsoft Entra ID 에이전트 ID를 할당하고, 전용 엔드포인트 (endpoint)를 노출합니다. 플랫폼은 스케일링 (scaling), 세션 상태 지속성 (session state persistence), 관측성 (observability) 및 라이프사이클 관리 (lifecycle management)를 처리합니다.

런타임은 세션별로 제공되며 샌드박스 (sandboxed) 환경에서 실행됩니다. Hosted 에이전트는 영구적인 파일 시스템 ($HOME 및 /files)을 갖춘 세션별 VM 격리 샌드박스에서 실행되므로, 상태 유지 재개 (stateful resume)가 가능한 스케일 투 제로 (scale-to-zero)를 지원합니다. 설계 의도는 저렴하게 일시 중단할 수 있는 수명이 짧은 유휴 세션이며, 엄격한 세션 수명 상한선이 존재합니다.

Hosted 런타임 사양 요약 (미리보기 기본값이며, 규모 산정 전 재확인 필요). Hosted 에이전트 개념 문서에서 발췌:

• 샌드박스 크기: 0.5 vCPU / 1 GiB, 1 vCPU / 2 GiB, 또는 2 vCPU / 4 GiB
• 세션 유휴 타임아웃 (Session idle timeout): 15분
• 세션 수명: 비활성 상태가 30일간 지속되면 영구 삭제
• 동시성 (Concurrency): 리전당 구독별 기본 최대 활성 동시 세션 50개 (Microsoft 지원을 통해 조정 가능)

핵심은 '자체 프레임워크 사용 (Bring-your-own framework)'입니다. 호스팅된 에이전트 (Hosted agents)를 사용하면 어떤 프레임워크로든 자체 코드를 가져올 수 있습니다 — Microsoft Agent Framework, LangGraph, Semantic Kernel, OpenAI Agents SDK, Anthropic Agent SDK, GitHub Copilot SDK 또는 커스텀 코드(마지막 세 가지는 Invocations 프로토콜 브릿지를 통해 가능)가 이에 해당합니다. 지원되는 언어는 Python과 C#이며, 프로토콜 라이브러리는 프레임워크에 구애받지 않습니다 (framework-agnostic). 만약 팀이 LangGraph를 표준으로 사용하고 있다면, 관리형 Microsoft 런타임을 사용하기 위해 이를 포기할 필요가 없습니다.

도구 (Tools)는 자동이 아니라 선택 사항 (opt-in)입니다. 호스팅된 에이전트는 프로젝트에 프로비저닝된 Toolbox MCP 엔드포인트를 통해 Foundry 관리형 도구 (Code Interpreter, Web Search, Azure AI Search, OpenAPI, 커스텀 MCP 연결, A2A)에 접근합니다. 에이전트 코드는 표준 MCP 클라이언트 라이브러리를 사용하여 이 엔드포인트에 연결하며, 플랫폼이 도구를 자동으로 주입하지는 않습니다. 이는 의도적인 설계 선택입니다. 즉, 고정된 세트를 상속받는 대신 원하는 도구를 직접 연결하게 함으로써, 코드 우선 (code-first) 개발자가 기대하는 작업 방식에 더 가깝게 구현되었습니다.

아키텍처 문서에 기재해야 할 몇 가지 제약 사항이 있습니다. 호스팅된 에이전트는 퍼블릭 프리뷰 (public preview) 상태이며, 활성 세션 중의 CPU 및 메모리 사용량과 호출당 추론 (inference) 및 도구 사용량에 따라 사용량 기반으로 과금됩니다. 이들은 네트워크가 격리된 Foundry 리소스 내에서의 배포를 지원하며, 아웃바운드 트래픽을 위해 고객이 제공한 Azure 가상 네트워크 (Virtual Network)를 사용할 수 있습니다. 하지만 이미지를 보유한 Azure 컨테이너 레지스트리 (Azure Container Registry)는 현재 퍼블릭 엔드포인트를 통해 접근 가능한 상태로 유지되어야 합니다. 만약 완전히 에어갭 (air-gapped)된 레지스트리가 현재 필수 요구 사항이라면, 도입을 결정하기 전에 현재 문서와 대조하여 이 격차를 확인해야 합니다.

나란히 비교하기 (The side-by-side comparison)

이것은 핵심이 되는 표입니다. 열(column) 단위가 아닌 차원(dimension) 단위로 읽으십시오. 이 행들에서 참조되는 교차 링크(cross-links)는 셀 내부가 아니라 본문 및 '다음 읽을거리(Read Next)' 섹션에 있습니다.

| 차원 (Dimension) | Copilot Studio | Foundry Hosted 에이전트 | M365 Agents SDK (in-process / self-hosted) |
| --- | --- | --- |
| 서비스 모델 (CAF) | SaaS, no/low-code | PaaS, 관리형 런타임 (preview) | Self-hosted; 컴퓨팅 자원(App Service, Container Apps 또는 자체 호스트)을 직접 소유 및 프로비저닝 |
| ... | |

일부 셀은 표의 셀 안에 담기에는 너무 긴 설명이 필요합니다.

거버넌스(governance) 측면에서 세 가지 경로 모두 한 곳에서 수렴합니다. Foundry, Copilot Studio 및 기타 Microsoft 에이전트는 단일 테넌트 전역 인벤토리(tenant-wide inventory)에 나타납니다. 관리자는 Microsoft Entra 관리 센터(admin center), Entra ID, Agent ID, All agent identities 아래에서 이들을 확인하고 관리할 수 있으며, 여기서 조건부 액세스(Conditional Access), ID 보호(Identity Protection), 네트워크 액세스 제어 및 라이프사이클 거버넌스(lifecycle governance)를 적용할 수 있습니다. 각 플랫폼이 자체적인 거버넌스 제어 평면(control plane)을 유지하더라도, 세 가지 모두 한 곳에서 확인할 수 있는 하나의 공유된 Entra ID 인벤토리에 등록됩니다. 공유된 가시성(Shared visibility)이 통합된 제어 평면(unified control plane)을 의미하는 것은 아닙니다.

채널 측면에서 실질적인 차이점은 도달 범위(reach) 대 네이티브의 단순성(native simplicity)입니다. Microsoft의 커스텀 엔진 에이전트 비교(In Microsoft's custom-engine-agent comparison)에 따르면, Agents SDK는 Microsoft 365 Copilot, Teams, 파트너 앱, 모바일 앱 및 커스텀 웹사이트에 도달할 수 있는 반면, Foundry는 Microsoft 365 Copilot와 Teams에 네이티브(natively)로 도달하며 다른 채널은 커스텀 통합(custom integration)이 필요합니다. Copilot Studio 에이전트는 웹사이트, 모바일 앱, Facebook, Microsoft Teams 또는 Azure Bot Service가 지원하는 모든 채널에서 실행될 수 있으며, Microsoft 365 Copilot로 게시될 수 있습니다. 만약 배포 요구 사항이 "우리 고객이 있는 모든 곳"이라면, SDK와 Copilot Studio가 Foundry의 네이티브 채널보다 더 넓은 범위에 도달합니다.

Foundry Hosted, in-process, 그리고 Copilot Studio 중 어떻게 선택해야 할까요?