아키텍처 측면에서 중요한 차이점은 간단합니다. 봇(bot)은 고정된 로직을 사용하여 대화를 턴 단위(turn-by-turn)로 해결하는 반면, 에이전트(agent)는 런타임(runtime)에 어떤 도구를 어떤 순서로 호출할지 결정함으로써 목표를 해결합니다. 만약 귀하의 Teams 확장 기능이 다음에 무엇을 말할지 결정하는 if/else 트리나 결정론적 대화 상태 머신(deterministic dialog state machine)을 가지고 있다면, 그것은 봇입니다. 만약 LLM에 도구 레지스트리(tool registry)를 전달하고, LLM이 Graph 호출, 데이터베이스 쓰기 또는 승인 트리거의 순서를 동적으로 선택하게 한다면, 그것은 에이전트입니다. 이러한 차이는 재시도 제한(retry limits), 도구 검증(tool validation), 루프 가드(loop guards), 그리고 인간 참여(human-in-the-loop) 체크포인트를 포함하여 주변 아키텍처를 극적으로 변화시킵니다.

요청 경로와 운영 환경의 오류 (The Request Path and the Production Fallacy)

모든 Teams 확장 기능은 카테고리에 관계없이 비즈니스 로직에 닿기 전 궁극적으로 동일한 계층적 경로를 통해 해결됩니다:

1. Teams 클라이언트 (Teams Client): 사용자가 UI 구성 요소와 상호작용합니다.
2. Microsoft Graph 및 Teams 플랫폼 (Microsoft Graph and the Teams Platform): 들어오는 활동 웹후크(activity webhook)가 등록된 엔드포인트로 라우팅됩니다.
3. 인그레스 및 오케스트레이션 계층 (Ingress and Orchestration Layer - Azure App Service / Azure Functions): 요청이 수락되고 애플리케이션 로직이 시작됩니다.
4. AI 계층 (AI Layer - Azure AI Foundry / Azure OpenAI): LLM 추론(inference), 의도 계획(intent planning), 도구 선택이 여기서 처리됩니다.
5. 다운스트림 종속성 (Downstream Dependencies): 워크플로가 귀하의 업무용(line-of-business) API, SQL 데이터베이스, SharePoint 또는 내부 서비스에 도달합니다.

대부분의 팀이 빠지는 안티 패턴(anti-pattern)은 추론 로직을 봇이나 에이전트의 메시지 핸들러 내부에 직접 넣는 것입니다. 이는 로컬 개발 터널(dev tunnel) 데모에서는 작동합니다. 하지만 운영 환경(production)에서는 무너집니다. Teams는 타임아웃 재시도를 피하기 위해 약 10~15초 이내에 HTTP 200 OK 응답을 기대하므로, 무거운 추론 루프는 원시 엔드포인트(raw endpoints)를 중단시킬 수 있습니다. 또한 작업 중간에 호스팅 인스턴스가 재시작될 경우 내구성(durability)이 보장되지 않으며, 모델이 계획한 것과 실제로 실행된 것 사이의 깔끔한 분리가 없고, 승인 게이트(approval gate)를 삽입할 자연스러운 위치도 없습니다.

운영 환경(production)에서 살아남으려면, 미들 레이어(middle layer)는 설계 단계부터 비동기적(asynchronous)이어야 합니다. 메시지 핸들러(message handler)는 웹훅(webhook)을 수락하고, Azure Service Bus와 같은 신뢰할 수 있는 큐(queue)에 이벤트를 발행한 다음, 백그라운드 워커(background worker)나 Azure Durable Function이 실제 추론 루프(reasoning loop)를 수행하도록 해야 합니다.

Bot Framework vs. Microsoft 365 Agents SDK

이것은 대부분의 팀이 가장 먼저 맞닥뜨리는 결정 지점이며, 작년에 팀이 사용했던 SDK를 기본값으로 선택하기보다는 신중하게 결정할 가치가 있습니다.

Bot Framework는 레거시(legacy)가 아닙니다. 예측 가능하고 감사 가능한(auditable) 대화 흐름이 필요하며, 규제 대상 프로세스에 대해 LLM이 단계 순서를 즉흥적으로 결정하는 것을 원하지 않을 때는 여전히 올바른 선택입니다. Agents SDK는 작업이 동적 계획(dynamic planning)으로부터 진정으로 이득을 얻을 때, 즉 적절한 경로가 첫 번째 도구 호출(tool call)의 반환 값이나 라이브 엔터프라이즈 컨텍스트에서 사용 가능한 데이터에 따라 달라질 때 그 복잡성을 정당화합니다.

Adaptive Cards와 이벤트 기반 앱(Event-Driven Apps)의 위치

1. 프레젠테이션 디커플링 (Presentation Decoupling)

Adaptive Cards는 경쟁 관계에 있는 아키텍처 결정 사항이 아닙니다. 이는 봇(bot)이 상호작용을 주도하든 에이전트(agent)가 주도하든 상관없이 교차 플랫폼 프레젠테이션 레이어(presentation layer) 역할을 합니다. 차이점은 카드가 어떻게 채워지는가에 있습니다. 스크립트 기반 봇은 이미 보유하고 있는 값을 사용하여 고정된 템플릿으로부터 카드를 렌더링합니다. 에이전트는 어떤 데이터가 관련 있는지 결정하고 도구 호출(tool call)로부터 데이터를 가져온 후, 추론 루프(reasoning loop)의 최종 단계로서 카드를 렌더링합니다. 카드 스키마 생성은 핵심 계획 로직(core planning logic)으로부터 분리하여 유지하십시오.

2. 이벤트 기반 Teams 앱 (Event-Driven Teams Apps)

모든 Teams 상호작용이 사용자가 메시지를 입력하는 것에서 시작되는 것은 아닙니다. 현대 클라우드 아키텍처에서 Teams는 종종 운영 코크핏(operational cockpit) 역할을 합니다. Azure DevOps에서 열린 풀 리퀘스트, 모니터링 파이프라인에 의해 플래그 지정된 보안 이상 징후, 또는 마감된 CRM 거래와 같은 외부 이벤트가 Azure Event Grid, Service Bus, 또는 Event Hub를 통해 Azure Function으로 흘러 들어가 채널이나 채팅에 선제적인 업데이트를 게시할 수 있습니다. 이러한 패턴은 Teams가 단순한 대화 공간을 넘어 행동의 전면 문(front door to action)인 엔터프라이즈 시나리오에서 점점 더 중요해지고 있습니다.

.NET 9 구현 로드맵

이 시리즈는 아키텍처부터 프로덕션 등급 구현까지 의도적인 순서로 진행됩니다:

1. 2026년의 현대적 Teams 아키텍처 (본문)
2. .NET 9와 Teams AI 라이브러리를 사용한 Teams 봇 구축
3. Microsoft 365 에이전트 대 Bot Framework — 심층적인 코드 레벨 비교
4. 상태 관리: Redis를 사용한 분산 캐싱 대 Cosmos DB 봇 상태
5. Teams + Azure AI Foundry: Semantic Kernel 채팅 완료 구현
6. 채널 보안 강화: Entra ID, 관리 ID, 그리고 On-Behalf-Of (OBO) 흐름
7. Azure Service Bus와 .NET 워커를 사용한 이벤트 기반 선제적 메시징
8. 지속 가능한 에이전트(Durable Agents): Teams 시간 초과 없이 장기 실행 LLM 작업 관리

다음 Teams 프로젝트가 봇을 필요로 하는지 에이전트를 필요로 하는지 결정하는 경우, 화이트보드 테스트를 사용하십시오. 코드를 작성하기 전에 전체적이고 절대적인 의사결정 트리(decision tree)를 그릴 수 있습니까? 그렇다면 봇을 구축하십시오. 만약 의사결정 트리가 단지 높은 수준의 목표 진술과 도구 상자일 뿐이라면, 에이전트가 필요하며, 이를 둘러싼 훨씬 더 신중하고 비동기적인 하네스(harness)가 필요합니다.

_본문은