이 질문에 답하기 전에는 AI 프레임워크를 선택하지 마세요

Azure에서 AI 에이전트를 구축하고 있다면, 이런 상황을 겪어보셨을 것입니다. 킥오프 미팅에서 누군가 "어떤 프레임워크를 사용해야 할까요?"라고 질문하고, 에이전트가 실제로 무엇을 해야 하는지에 대해 아무도 합의를 보기도 전에 Semantic Kernel, AutoGen, Copilot Studio, Foundry, 그리고 Logic Apps 사이에서 향후 90분 동안 토론이 이어지는 상황 말입니다.

그것은 잘못된 순서입니다. 그리고 수많은 Azure AI 프로젝트가 가장 정교하게 들리는 옵션으로 시작하여, 이후 3개월 동안 잘못된 추상화 (Abstraction)와 싸우게 되는 이유이기도 합니다.

Microsoft 생태계는 다른 어떤 클라우드 제공업체보다 더 많은 에이전트 아키텍처 유연성을 제공합니다. 대화형 (Conversational) 또는 헤드리스 (Headless). 로우코드 (Low-code) 또는 프로코드 (Pro-code). M365 네이티브 (M365-native) 또는 Azure 네이티브 (Azure-native). 이러한 유연성은 진정한 장점이지만, 의사결정 트리 (Decision tree)를 올바른 순서로 읽었을 때만 유효합니다.

이 포스트는 그 트리를 따라가 봅니다. 글을 마칠 때쯤이면 여러분은 처음부터 올바른 아키텍처를 선택할 수 있는 반복 가능한 프레임워크와 함께, 확정하기 전에 반드시 알아야 할 SDK 은퇴 날짜 목록을 갖게 될 것입니다.

플랫폼 환경을 먼저 파악하세요

의사결정 트리에 앞서, Microsoft가 제공하는 세 가지 계층 (Tiers)을 이해하는 것이 도움이 됩니다:

┌─────────────────────────────────────────────────────────────────┐
│               Microsoft Agent Platform Tiers                     │
│                                                                   │
...

이것들은 서로 경쟁하는 제품이 아닙니다. 하나의 스펙트럼입니다. 질문은 어떤 것이 "최고"인가가 아니라, 어떤 계층이 여러분 팀의 제약 조건에 부합하는가입니다.

모든 것을 결정짓는 단 하나의 질문

프레임워크를 정하기 전에, 데이터 레이어 (Data layers)를 정하기 전에, 배포 (Deployment)를 하기 전에 — 가장 중요한 단 하나의 결정은 다음과 같습니다:

상호작용 패턴 (Interaction pattern)은 무엇인가?

정확히 세 가지 답변이 있습니다:

                    ┌─────────────────────┐
                    │  What is the        │
                    │ interaction pattern? │
...

이 분기점(fork)은 거의 모든 하위 의사결정을 결정합니다. 이 단계를 건너뛰고 바로 프레임워크 선택으로 넘어가는 팀은 잘못된 추상화(abstraction)와 싸우며 수개월을 허비하게 됩니다. 여기서부터 시작하는 팀은 단 몇 분 만에 더 나은 선택을 내립니다.

경로 1: 채팅 / UI 기반 에이전트 (Chat / UI-Based Agents)

사람이 에이전트와 직접 대화할 예정이라면, 이 분기를 따르십시오.

1단계: 사용자가 어디에 머무는가?

경험이 완전히 Microsoft 365 내에서 이루어지는가?
│
├── 예(YES) → M365 Copilot
...

2단계: 프로코드(pro-code) 분기

완전한 엔지니어링 제어가 가능한 대화형 UI(conversational UI)가 필요한 경우, 한 가지 결정이 올바른 SDK를 결정합니다:

이것이 M365 중심인가?
│
├── 예(YES) → M365 Agents SDK
...

UI 기반 에이전트에 대한 요약은 네 가지 질문으로 압축됩니다:

1. 이것이 대화형인가? (예 — 현재 이 경로를 따르고 있음)
2. 사용자가 어디에서 상호작용하는가? (M365, Teams, 또는 커스텀?)
3. 로우코드(low-code)인가, 프로코드(pro-code)인가?

4. M365 우선인가, Azure 우선인가?

경로 2: 자율형 / 이벤트 기반 에이전트 (Autonomous / Event-Driven Agents)

이 에이전트들은 백그라운드에서 실행됩니다. 이들은 트리거(trigger)에 반응합니다. 직접적인 사용자 상호작용을 최소화하거나 아예 없이 정보를 처리하고 조치를 취합니다. 여기서의 아키텍처는 채팅 UI가 아닌 워크플로(workflow)를 따릅니다.

자율형 에이전트 의사결정 트리 (Autonomous Agent Decision Tree):
│
├── 로우코드(low-code)를 원하는가? → 이벤트 트리거를 사용하는 Copilot Studio
...

이 경로를 위한 핵심 통찰: 자율형 에이전트는 채팅 기능만 제거된 챗봇이 아닙니다. 이들은 워크플로 시스템입니다. 아키텍처 선택은 실행하려는 모델의 정교함이 아니라, 워크플로의 형태, 트리거 소스, 그리고 통합 접점(integration surface)을 따라야 합니다.

이는 에이전트의 역할이 SAP를 호출하고, ServiceNow에서 읽고, Salesforce에 다시 쓰는 엔터프라이즈 워크플로에서 특히 중요합니다. 통합 계층(integration layer)과 비교했을 때 에이전트 프레임워크는 거의 무의미합니다.

경로 3: 헤드리스 / API 서비스 (Headless / API Services)

채팅창이 없습니다. 코파일럿(copilot) 인터페이스도 없습니다. 에이전트는 다른 시스템이 호출할 수 있는 백엔드 서비스를 노출합니다. 여기서 주요 변수는 **호스팅 요구사항(hosting requirements)**입니다:

Headless Agent Hosting (헤드리스 에이전트 호스팅):
│
├── Managed platform service (관리형 플랫폼 서비스) → Azure Container Apps
...

이 분기(branch)는 사용자 경험보다는 **런타임 형태 (runtime shape)**에 더 가깝습니다. 에이전트가 사용자가 아닌 다른 서비스에 의해 호출되는 인프라(infrastructure) 역할을 할 때는, 배포 대상(deployment target)과 SLA(서비스 수준 계약) 요구사항이 의사결정을 주도합니다.

데이터 계층 (The Data Layer): 구현 세부 사항으로 취급하지 마십시오

이 부분은 대부분의 Azure AI 프로젝트가 투자를 소홀히 하는 지점입니다. 에이전트 응답의 품질은 선택한 모델보다 검색 계층 (retrieval layer)에 훨씬 더 크게 좌우됩니다.

Does the agent need custom data? (에이전트에 커스텀 데이터가 필요한가?)
│
├── Microsoft 365 data (emails, docs, SharePoint)
...

실질적인 규칙: 만약 에이전트가 정보를 검색하여 (retrieving information) 질문에 답한다면, 검색 아키텍처 (retrieval architecture)는 여러분이 내릴 가장 중요한 설계 결정입니다. 모델은 범용 제품 (commodity)이지만, 모델에 데이터를 어떻게 공급하느냐는 그렇지 않습니다.

배포 (Deployment): 에이전트는 어디에 존재해야 하는가?

상호작용 모델 (interaction model), 구축 방식 (build approach), 데이터 계층을 결정한 후, 마지막 결정 사항은 사용자나 시스템이 에이전트에 도달하는 지점입니다:

대상 사용자 (Target Audience)	배포 경로 (Deployment Path)
Copilot 내 M365 사용자	M365 Copilot 채널
...

결정을 내렸다면: 모니터링을 생략하지 마십시오. 관찰 가능성 (Observability), 거버넌스 (governance), 그리고 비용 가시성 (cost visibility)은 첫 번째 운영 사고(production incident)가 발생한 후 사후에 적용하는 것이 아니라, 설계 첫날부터 포함되어야 합니다.

확정하기 전에 반드시 알아야 할 은퇴 날짜 (Retirement Dates)

이 섹션은 현재 모든 Azure AI 아키텍처 논의에서 반드시 다뤄져야 하는 내용입니다. 세 가지 SDK가 현재의 계획 범위 내에서 은퇴 날짜를 발표하거나 확정했습니다:

SDK / 서비스	은퇴 날짜 (Retirement Date)	후속 제품 (Successor)
Bot Framework	2025년 12월 31일	M365 Agents SDK
...

만약 이 중 하나라도 현재 여러분의 스택에 포함되어 있거나 평가 후보 목록에 있다면, 지금 즉시 마이그레이션 (migration)을 시작하십시오.

프로젝트 중간에 — 팀원들에게 SDK (Software Development Kit) 교육을 마치고, 문서를 작성하고, 통합 (integration)을 구축한 뒤에 — 서비스 종료 날짜를 발견하게 되는 비용은 항상 올바른 플랫폼에서 시작하는 것보다 더 높습니다. 이는 특히 여러 분기(multi-quarter)에 걸친 계획 주기를 가진 팀에게 더욱 그러합니다.

이 글을 쓰는 시점을 기준으로 Bot Framework의 서비스 종료는 이미 지나갔습니다. 만약 여전히 이를 사용 중이라면, M365 Agents SDK로의 마이그레이션 (migration)은 선택이 아닌 필수입니다.

요약 버전 (화이트보드에 적어두세요)

STEP 1: 상호작용 패턴 (interaction pattern)은 무엇인가?
        Chat UI → 2단계로 이동
        자율형 (Autonomous) → 3단계로 이동
...

핵심 요약 (Key Takeaways)

• Azure AI 에이전트 아키텍처에서 가장 중요한 단 하나의 결정은 상호작용 패턴 (interaction pattern) (Chat/UI, Autonomous, Headless)입니다. 다른 모든 선택은 이 결정으로부터 파생됩니다. 이 질문에 대한 답이 나오기 전의 프레임워크 논쟁은 시기상조입니다.
• 로우코드 (Low-code, Copilot Studio)는 타협이 아닌 전략적 선택입니다. 사용자가 이미 Teams와 M365를 사용 중이라면, 로우코드는 동일한 결과를 내는 커스텀 프로코드 (pro-code) 솔루션보다 종종 더 빠르게 프로덕션 (production) 단계에 도달하게 해줍니다.
• 데이터 레이어 (data layer)는 모델 티어 (model tier)보다 에이전트의 품질을 더 크게 결정합니다. Azure AI Search, pgvector, Cosmos DB 또는 Fabric 중 무엇을 선택할지는 데이터의 형태에 달려 있으므로, 이를 조기에 결정하십시오.
• 세 가지 SDK가 2026년 계획 범위 내에서 확정된 서비스 종료 날짜를 가지고 있습니다: Bot Framework (2025년 12월 종료), azure-ai-inference SDK (2026년 5월 종료), 그리고 Assistants API (2026년 8월 종료). 지금 즉시 여러분의 스택을 감사(audit)하십시오.
• 핵심 문제가 모델 선택이 아닌 통합 (integration)에 있다면, 1,400개 이상의 엔터프라이즈 커넥터를 보유한 Logic Apps AI 에이전트 워크플로 (workflows)가 올바른 경로입니다. 그러한 시나리오에서는 모델의 이야기보다 커넥터의 이야기가 더 중요합니다.

깊이 고민해 볼 가치가 있는 질문

제가 본 모든 팀이 Azure AI 프레임워크에 대해 논쟁할 때, 시작은 항상 "어떤 것이 가장 강력한가?"였습니다. 올바른 질문은 "어떤 것이 우리가 실제로 구축하려는 것의 형태에 적합한가?"입니다.

최근 Azure AI 아키텍처 의사결정 과정을 거치셨다면 — 프레임워크 선택을 강제한 요인은 무엇이었나요? 상호작용 모델 (interaction model), 데이터 계층 (data layer), 팀의 기술 수준, 시간적 압박, 아니면 완전히 다른 무엇이었나요?

댓글로 남겨주세요. 실제 의사결정을 이끈 동인이 무엇인지 듣는 것은 그 어떤 의사결정 트리 (decision tree)보다 유용합니다.