이 기사는 여러 bot을 Hermes Agent의 프로필(profile) 단위로 독립 운용하는 구성(Hermes Agent에서 bot마다 LLM 프로바이더를 전환 — Ollama × OpenRouter 혼용 운용)의 파생 토픽입니다. bot을 Teams에 내보내는 단계에서 빠졌던 함정을 독립시킨 것이지만, Teams 부분은 Hermes에 의존하지 않으므로 Hermes를 사용하지 않는 분들도 그대로 읽으실 수 있습니다.

manifest 설정은 모두 올바른 것 같은데, Microsoft Teams의 프라이빗 채널(private channel)에서만 bot이 "없는 상태가 된다". 반나절을 허비하며 조사한 결과 알아낸 것은, 이것은 나의 실수가 아니라, Teams 측이 이 영역에서 마침 사양 이행(specification migration) 중이었다는 사실이다.

게다가 이 영역은 2025년 후반~2026년에 걸쳐 급격히 움직이고 있어서, "private channel에서는 bot을 절대 사용할 수 없다"라는 오래된 이해도, "이미 public developer preview이므로 사용할 수 있다"라는 새로운 이해도, 둘 다 한쪽 면만 보고 있는 것이다. 실태는 **"preview로서 제공되고는 있으나, 본방 롤아웃(rollout)은 중지 중"**이라는 불확실한 상태에 있다.

같은 함정에 빠진 사람들을 위해, 2026년 시점의 정확한 상황과 본방에서 확실하게 운용하기 위한 현실적인 해답을 정리해 둔다.

Microsoft Teams의 private channel에서 bot을 구동하는 이야기는, 2026년 시점에서 사양 이행 중이다. 공식 문서상으로는 private channel 대응이 public developer preview로서 제공되며, bot / tab apps도 대상에 포함되어 있다. 다만 tenant / manifest / rollout 상황에 따라서는, sideload bot이 표시되지 않거나 메시지 이벤트가 전달되지 않을 수 있다. 게다가 private channel 앱 대응의 본방 롤아웃은 2026년 3월 시점에서 일시 중지되어 있다 (Message Center MC1197145).

본방에서 확실하게 운용하려면, "프라이빗 팀"의 "표준 채널(standard channel)"을 사용하는 것이 현실적인 해답이다. 이것은 Hermes 고유의 이야기가 아니라 Teams 측의 사정이다.

여기서 중요한 사양 변경이 하나 있다. standard channel에서는 host team에 install한 app이 channel에서 그대로 사용할 수 있는 반면, shared / private channel에서는 "app을 각 채널에 명시적으로 추가"해야 한다. 팀 레벨의 install은 shared / private에는 적용되지 않는다는 모델로 바뀌었다. 기사를 쓰거나 운용할 때, 이 차이점을 파악해 두면 함정에 빠지기 어렵다.

@mention에 대해 보충. 통상적인 group / channel bot은 @mention 되었을 때만 메시지를 받지만, RSC (ChannelMessage.Read.Group / ChatMessage.Read.Chat)를 사용하면...

`)를 부여하면 @mention 없이도 대화 메시지를 받을 수 있다. 따라서 그룹 채팅(group chat)도 "반드시 @mention 필수"가 아니라 "통상적으로는 필수, RSC를 통해 불필요하게 설정 가능"이 정확한 표현이다.

여기서 기술하는 내용은 프라이빗 채널(private channel) 앱 지원(app support)이 프리뷰(preview)로 제공되기 전, 혹은 프리뷰가 테넌트(tenant)에 도달하지 않은 환경에서의 동작이다.

• 팀에 bot 설치 → 해당 팀의 모든 채널(프라이빗 채널 포함)에서 @bot 후보가 나타남

• 일반 채널(예: "일반")에서 @ 입력 → bot 이름이 나타남 ✅

• 프라이빗 채널에서 @ 입력 → bot 이름이 나타나지 않음 ❌

• 프라이빗 채널의 "+"(앱 추가) → bot이 검색 결과에 나오지 않음 ❌

• 채널 설정 → 앱 → 앱 추가 → bot 후보 없음 ❌

즉, "같은 팀에 있는데 프라이빗 채널에서만 존재하지 않게 되는 상황"이 발생한다.

실제로 설치를 강행하려고 하면 다음과 같은 에러 문구가 발생하는 사례도 보고되고 있다:

App isn't supported in the private channel. Select another channel.

bot 매니페스트(manifest) 측에는 프라이빗 채널 대응 선언을 넣어두었다.

{
"supportedChannelTypes": ["sharedChannels", "privateChannels"],
"bots": [{
...

그럼에도 UI 상에는 나타나지 않았다.

여기서 오해하기 쉬운 부분이 supportedChannelTypes의 역할이다.

⚠️

supportedChannelTypes만으로는 bot이 프라이빗 채널에 나타나지 않는다.

2025년 시점의 Microsoft Q&A에서는 프라이빗/공유 채널(private / shared channel)에서 supportedChannelTypes가 적용되는 것은 탭(tab)뿐이며, bot이나 메시징 확장(messaging extension)은 아직 기능하지 않는다고 답변되어 있었다. 즉, 당시 이 필드에 privateChannels를 작성하더라도 bot을 프라이빗 채널에 나타나게 하는 데는 기여하지 못했다. "올바르게 작성했다고 생각했지만, 사실 bot에는 애초에 적용되지 않는 필드였다"는 점이 함정의 시작이었다.

Microsoft의 공식 Q&A에서는 앱이 팀이나 일반 채팅에는 문제없이 설치되는데 프라이빗 채널에서 나타나지 않는 건에 대해, "정책의 문제가 아니라 당시에는 단순히 bot이 프라이빗 채널을 지원하지 않았기 때문"이라고 설명했다. 매니페스트를 올바르게 작성해도 동작은 변하지 않는 상태였다.

이 영역은 이후 급격히 움직였다. 시계열로 정리하면 다음과 같다:

• 2025년 10월 ~ 2026년 1월: 공유 채널(shared channel)의 앱 대응이 GA(General Availability, 일반 배포)됨. bot / tab / 메시징 확장(message extension)을 공유 채널에서 사용할 수 있게 됨 (Message Center: MC1168294).
• 2026년 1월 중순 ~: 프라이빗 채널의 앱 대응도 동일한 모델로 롤아웃(rollout) 시작이 발표되었으며, public developer preview로 제공됨 (Message Center: MC1197145).
• 2026년 3월: Microsoft가 프라이빗 채널 앱 대응 롤아웃을 일시 중단함 (MC1197145의 2026/3/17 업데이트). GA 전의 롤백(rollback)이며, 재개 시기는 미정 (Message Center를 통해 후속 소식을 알리겠다고 공지).

즉, 2026년 시점의 정확한 상태는 다음과 같다:

• 프라이빗 채널 (private channel)에서의 봇 (bot) 이용은 "설계상 절대 불가"한 것은 아니다. 퍼블릭 개발자 프리뷰 (public developer preview)로서의 길은 열려 있다.
• 단,
  본격적인 롤아웃 (rollout)은 중단된 상태이며, 테넌트 (tenant) / 롤아웃 (rollout) / 매니페스트 (manifest) / RSC / Graph notification 조건에 따라 사이드로딩 (sideload)된 봇이 표시되지 않거나 메시지 이벤트 (message event)가 전달되지 않을 수 있다.
• 프리뷰 (preview)를 운영 환경에 의존하는 것은 위험하다. 확실하게 작동시키려면 다음의 회피책이 현실적인 해답이다.

프리뷰 (preview) 환경에서 프라이빗 / 공유 채널 (private / shared channel) 앱을 테스트할 경우, 현재 문서에서는 매니페스트 (manifest)를 v1.25로 설정하고 supportsChannelFeatures: "tier1"을 추가하여 각 채널 타입별로 테스트하도록 안내하고 있다.

{
"$schema": "https://developer.microsoft.com/json-schemas/teams/v1.25/MicrosoftTeams.schema.json",
"manifestVersion": "1.25",
...
}

⚠️ 주의:

supportsChannelFeatures는 2025년 11월 시점의 Q&A에서는 "공개 스키마 (public schema)에 미반영되었으므로 허용된 확장 (allowed extension)으로 취급해 달라"는 단계였으나, 현재는 매니페스트 스키마 (manifest schema) v1.25 (2026년 1월분)에 정식으로 추가되었으며, 공유 / 프라이빗 채널 (shared / private channel)을 포함한 다음 레벨의 채널 기능에 옵트인 (opt-in)하기 위한 프로퍼티 (property)로 정의되어 있다. team 스코프 (scope)를 사용하는 앱에서는 자동 앱 검증 (Automatic App Validation)이 이 프로퍼티를 요구하는 경우도 있다. 다만, 프로퍼티가 정의되어 있는 것과 프라이빗 채널 (private channel)에서 실제로 봇 (bot)이 작동하는 것은 별개의 문제이며, 후자는 앞서 언급한 바와 같이 프리뷰 (preview) / 롤아웃 (rollout) 중단 영향의 영향을 받는다.

Teams 관리 센터 (admin.teams.microsoft.com)에서:

• Teams 앱 → 앱 관리 → 업로드에서 ZIP (manifest.json + 아이콘 2개)을 업로드
• 앱 상세 화면에서 "게시됨" / "허용" 상태로 설정
• 테넌트 (tenant) 내 사용자에게 배포 및 허용

ZIP 내용물:

my-bot.zip
├── manifest.json
├── color.png (192×192)
...

위치 설정 시 주의사항: 게시 (publish)는 테넌트 (tenant) 내에서 커스텀 앱 (custom app)을 배포하고 허용하기 위한 정석적인 방법이지만, 이것만으로 프라이빗 채널 (private channel)에 반드시 표시되거나 작동함을 보장하지는 않는다. 앞서 언급했듯이 프라이빗 채널 지원 (private channel support)은 프리뷰 (preview) 상태이며 롤아웃 (rollout)이 중단된 상태이므로, 게시 (publish)는 "필요조건이 될 수는 있지만" "충분조건은 아니다". 실제로 작동시키려면 매니페스트 (manifest) v1.25 · supportsChannelFeatures: "tier1" · 각 채널에 대한 추가 · RSC 동의 (RSC consent) · 테넌트 정책 (tenant policy)을 종합적으로 검증해야 한다.

기타 문제점:

• Teams 서비스 관리자 (Teams Service Administrator) 권한이 필요함 (개인의 경우 관리자가 없거나 승인 대기 중일 수 있음)
• 반영까지 캐시 타임 (cache time)이 소요됨 (5분 ~ 30분)
• 대기업의 경우 신청 워크플로우 (workflow)가 필수적임

여기서 중요한 것은 "프라이빗 팀 (private team)"과 "프라이빗 채널 (private channel)"은 별개의 개념이라는 점이다. 혼동하기 쉬우므로 정리한다.

즉 "프라이빗 팀의 표준 채널 (standard channel)"이라면:

• ✅ 팀 자체가 "멤버 전용"이므로, 대화는 초대된 사람에게만 보인다 (즉, 프라이버시 확보)
• ✅ 채널 자체는 "표준 (standard)" 취급이므로, 봇 설치 (bot install) / @멘션 (@mention) / RSC 권한 (RSC permission)을 모두 사용할 수 있다 (프리뷰에 의존하지 않음)
• ✅ 조직 정책이 "내부적으로만 대화하라"는 의미라면, 이것으로 충족 가능하다

private channel의 preview / rollout 상황에 휘둘리지 않고, 현재 있는 안정적인 기능만으로 요구사항을 충족할 수 있다는 점이 가장 큰 이점이다.

이 부분이 까다롭다. 말 그대로 "private channel이 아니면 위반"이라는 운영 규칙이 있다면, preview 진행을 기다리거나 admin publish + preview 활성화를 실제 tenant에서 검증할 수밖에 없다. 운영 환경(production)에서 안정적으로 운영하고 싶다면, 정책(policy) 측면을 재검토할 수 있는지 확인하는 것이 우선이다.

많은 조직에서는 "멤버십을 제한한 곳에서 대화하라" 정도의 의미로 "프라이빗(private)"이라고 말한다. 그 경우에는 프라이빗 팀(private team)의 표준 채널(standard channel)로 충족할 수 있다. admin과 한 번 확인해 두면 안심할 수 있다:

"대화를 멤버 외부에 노출하지 않는 것"이 요구사항이지, "프라이빗 채널(private channel) 기능을 사용하는 것" 자체가 요구사항은 아니라는 뜻이 맞습니까?

bot이 반응하지 않을 때의 진단:

[Teams에서 @를 입력했을 때 bot 이름이 후보에 뜨는가?]
│
┌────┴────┐
...

private channel에서 preview를 사용하여 운영 환경에서 사용하고 싶다면, 실제 tenant에서 "install", "conversationUpdate", "message activity", "Graph read / subscription"을 개별적으로 검증할 것. standard channel과 동일한 실시간 전송(real-time delivery)을 기대하면 함정에 빠질 수 있다.

이 부분은 Hermes Agent에서 Teams adapter를 사용하고 있는 경우의 이야기다.

Hermes의 TEAMS_HOME_CHANNEL

(cron / proactive message delivery용 송신처 ID)에 스레드 답장용 ;messageid=...가 포함된 conversation reference를 넣으면, Hermes 측의 입력 검증에서 거부된다 (;가 허용되지 않음). clean한 channel / chat conversation ID를 사용할 것.

# NG: 스레드 답장(thread reply)용 messageid가 포함된 ID를 proactive delivery의 목적지로 사용함
TEAMS_HOME_CHANNEL=19:<thread-id>@thread.tacv2;messageid=<message-id>
# OK: channel/chat의 clean한 conversation ID
...

보충: Teams / Bot Framework 일반에서는 conversation.id에 ;messageid=...가 포함되는 상황은 흔히 있다 (스레드 답장 대상 표현 등). 따라서 ;messageid= 자체가 Bot Framework 전체에서 잘못된 것은 아니다. 어디까지나 Hermes의 기저(base) conversation ID를 사용하라는 이야기다. TEAMS_HOME_CHANNEL의 입력값으로는

프라이빗 채널(private channel)과 프라이빗 팀(private team)은 별개의 개념이다. 혼동이 자주 발생하는 용어이므로, 우선 이를 구분할 것.
private channel의 bot 대응은 2026년 시점에서 사양(specification) 이전 중이다. "설계상 절대 불가"는 아니며 public developer preview로서 길은 열려 있지만, 운영 환경 롤아웃(production rollout)은 2026년 3월에 일시 중단 중이다. supportedChannelTypes는 (적어도 2025년 시점에서는) 탭(tab)용이며 bot에는 적용되지 않는다. supportsChannelFeatures: "tier1"은 manifest schema v1.25에 정식 추가되었으나, 프로퍼티가 정의되어 있는 것과 private channel에서 bot이 동작하는 것은 별개의 문제다. preview를 운영 환경에 의존시키지 말 것.
shared channel의 앱 대응은 GA(General Availability, 2026년 1월 중순 예정)이다. 단, shared / private는 앱을 각 채널에 개별적으로 추가해야 하며, 팀 레벨의 install은 적용되지 않는다.
운영 환경의 현실적인 해답은 안 B(프라이빗 팀의 표준 채널)이다. preview에 의존하지 않고, 현재 있는 안정적인 기능으로 요구사항을 충족할 수 있다. 많은 경우 이것으로 충분하다.
부차적 주제: Hermes의 TEAMS_HOME_CHANNEL에는 clean한 conversation ID를 사용할 것 (;messageid=가 포함된 것은 거부됨).

이 기사는 여러 개의 bot을 Hermes Agent의 profile 단위로 독립적으로 운영하고, 각각 다른 LLM 프로바이더 (Ollama / OpenRouter)로 라우팅하는 구성의 파생 주제였습니다. bot의 identity(정체성)·기억·제약·provider(프로바이더)를 묶어서 profile 단위로 나누는 설계에 대해서는, 「Hermes Agent에서 bot마다 LLM 프로바이더를 전환하기 — Ollama × OpenRouter 혼합 운영」에 정리해 두었습니다.

MicrosoftTeams

Bot

BotFramework

Teams개발

엔터프라이즈

AI에이전트 (AI Agent)

HermesAgent