Microsoft Teams 개발자들은 모든 확장 기능을 '봇(bot)'이라고 부르는 것이 이제 운영 환경의 장애를 유발할 수 있다는 경고를 받고 있습니다. 2026년에는 플랫폼 자체의 제한 사항인 '메시지 응답 시간 10~15초'로 인해, 잘못 설계된 봇이 타임아웃 폭풍(timeout storms)을 일으켜 팀들이 파이프라인을 재설계해야 하는 상황에 직면하게 될 것입니다.

왜 이 구분이 중요한가

Teams는 서로 다른 상호작용 패턴을 위해 구축된 세 가지 유형의 확장 기능을 제공합니다. 이들을 혼용하면 잘못된 런타임, 잘못된 SDK, 그리고 잘못된 확장 모델을 사용하게 됩니다.

Teams 앱, 봇, 에이전트 – 각각 무엇인가

  • Teams apps – Teams 클라이언트 내부의 표면 탭(surface tabs), 정적 페이지 또는 단순 UI 구성 요소입니다. 본질적으로 상태가 없는(stateless) 웹 앱이며, 요청 시 렌더링되고 다른 HTTP 서비스와 마찬가지로 호스팅됩니다. 대화형 흐름은 기대되지 않습니다.
  • Bots – Bot Framework SDK로 구축되며, 스크립트된 대화 흐름을 따릅니다. 이들의 로직은 들어오는 활동(activity)에만 기반하여 다음 응답을 결정하는 결정론적(deterministic) if/else 트리입니다. 결정 경로를 미리 알 수 있기 때문에 응답이 플랫폼의 짧은 타임아웃 시간 내에 완료됩니다.
  • Agents – 상위 수준의 목표, 도구 세트, 그리고 LLM(대규모 언어 모델)을 전달받는 목표 지향적 엔티티입니다. Agents SDK 또는 Semantic Kernel을 사용하여, LLM은 어떤 도구를 어떤 순서로 호출할지, 그리고 언제 사용자에게 확인을 요청할지를 결정합니다. 흐름은 동적이며, 종종 여러 번의 외부 호출과 복잡한 추론을 필요로 합니다.

이 차이는 극명합니다. 봇은 결정론적(deterministic)인 반면, 에이전트는 확률론적(probabilistic)이며 런타임에 도구 호출을 오케스트레이션합니다.

타임아웃의 함정

개발자가 LLM 프롬프트, 데이터베이스 조회 또는 외부 API 호출과 같은 무거운 추론 과정을 봇의 메시지 핸들러 내에 직접 포함시키면, Teams는 요청이 10~15초의 제한 시간을 초과하는 것으로 간주합니다. 플랫폼은 응답을 중단하고 재시도하며, 이는 중복 작업과 스로틀링(throttling)으로 이어질 수 있습니다. 증상은 간헐적인 '봇이 응답하지 않음' 오류처럼 보이지만, 근본 원인은 아키텍처에 있습니다.

운영 환경에 적합한 비동기 파이프라인 구축하기

  1. Webhook entry point – 봇의 HTTP 엔드포인트가 Teams activity를 수락하고 즉시 수신 확인을 보냅니다.
  2. Queue the event – 핸들러가 페이로드를 Azure Service Bus와 같은 내구성이 있는 큐(durable queue)로 보냅니다.
  3. Background worker – Azure Durable Function, Service Bus 트리거 또는 기타 장시간 실행되는 워커가 메시지를 가져와 LLM 추론 또는 도구 오케스트레이션을 수행한 후, Bot Framework의 proactive messaging API를 통해 최종 응답을 Teams로 다시 게시합니다.

초기 웹훅이 즉시 반환되기 때문에 Teams는 타임아웃에 걸리지 않으며, 무거운 작업은 자체 속도에 맞춰 진행됩니다. 큐는 급증하는 트래픽을 완충하고, 워커는 백로그 길이에 따라 자동으로 확장(auto-scale)됩니다.

빠른 의사결정 가이드 (화이트보드 테스트)

  • 코드를 작성하기 전에 전체 결정 트리를 그릴 수 있습니까? 예 → 봇을 구축하십시오. 결정론적 흐름은 Bot Framework 모델에 적합하며 응답 시간 내에 유지됩니다.
  • 문제가 상위 수준의 목표와 가능한 도구 목록으로 정의됩니까? 예 → 에이전트를 구축하십시오. LLM이 계획을 세우고 도구를 호출하도록 하고, 계획 수립 작업은 백그라운드 워커로 넘기십시오.

다음 단계

이 가이드는 Azure에서 지능형 Teams 솔루션을 구축하는 .NET 9 개발자를 위한 시리즈의 첫 번째 편입니다.

이미 Teams 로그에서 “Bot timed out” 오류가 발생하고 있다면 해결 방법은 간단합니다. 웹훅을 무거운 작업으로부터 분리하고, 큐 기반의 워커를 채택하며, 처음부터 올바른 확장 유형을 선택하십시오. 플랫폼에는 타임아웃 제한이 있지만, 아키텍처를 통해 이를 피할 수 있습니다.

핵심 요약: Teams 확장 기능을 봇으로 잘못 분류하면 Teams가 감당할 수 없는 동기식 설계를 강제하게 됩니다. 요청과 추론을 분리하고, 적절한 SDK를 선택하십시오. 그러면 그 이면의 두뇌가 LLM 기반 에이전트라 할지라도 귀하의 Teams 솔루션은 응답성을 유지할 것입니다.