스탠드업 채팅에서 @GitHub 치기 전에 — Teams 공유 에이전트와 신뢰 경계

스탠드업이 채팅으로 열린 날, 액션 아이템이 채팅에 떨어집니다. 그다음 누군가 @GitHub 를 멘션합니다. 회의가 끝나기 전에 조사가 시작되고, PR 링크가 스레드에 붙습니다.

핵심 한 줄: Microsoft Teams의 Copilot 공유 에이전트 세션은 “회의 맥락을 코드 작업으로 바로 넘기는” 기능이지만, 쓰기 권한이 있는 사람만 변경을 트리거하고, Teams 연동 신원으로 만든 PR에는 추가 승인을 걸 수 있는지가 진짜 운영 질문입니다.

2026-08-21 GitHub 변경 로그에 Microsoft Teams에서 공유 에이전트 작업 이 public preview로 올라왔습니다. 같은 날 Slack 경험 도 나왔습니다. 표면은 비슷해 보이지만, 협업 UX와 거버넌스 체크리스트는 다릅니다.

왜 중요한가

에이전트는 이미 IDE·CLI·클라우드에 있습니다. 문제는 결정이 나는 장소입니다. 버그 재현, 범위 합의, “누가 고칠지”는 여전히 Teams(또는 Slack) 스레드에서 끝납니다. 그 스레드에서 바로 클라우드 에이전트를 깨우면 컨텍스트 복붙 비용은 줄지만, 채팅 참가자 ≠ 저장소 권한자 라는 오래된 사실이 한꺼번에 드러납니다.

GitHub 문서와 변경 로그가 강조하는 패턴은 이렇습니다.

• 대화의 누구나 질문·맥락·방향 제시를 할 수 있다.
• 대상 저장소에 write 권한이 있는 참가자만 Copilot이 코드를 바꾸도록 트리거할 수 있다.
• 작업은 secure cloud sandbox 에서 비동기로 이어지고, 스레드에서 진행을 따라간 뒤 터미널·Copilot 앱·IDE로 이어갈 수 있다.
• org/enterprise에서는 cloud agent + cloud sandboxes 정책이 켜져 있어야 한다(정책 구성이 공유된다는 설명).
• 클라우드 에이전트 세션은 AI credits 를 소비하고, cloud sandbox 사용량은 별도 과금·예산 으로 제어할 수 있다.

회의 채팅에서 바로 넘기는 UX는 매력적입니다. 다만 “회의실에 있던 사람”과 “머지 권한을 가진 사람”이 같다고 가정하면, preview 첫 주에 이미 거버넌스 사고가 납니다.

어떻게 다른가 (Slack Code vs Teams 스레드)

같은 날 나온 Slack 쪽은 Slack Code 라는 전용 코드 채널을 만들고, 세션 조향을 그 채널로 모읍니다. Teams 쪽 변경 로그·문서는 기존 채널/스레드/DM 위에서 공유 세션을 돌리는 쪽에 가깝습니다.

둘 다 “채팅에서 에이전트를 깨운다”는 제품 문장을 공유합니다. 운영자 관점의 차이는 세션 공간이 분리되는지(Slack Code) 와 미팅 채팅까지 기본 표면인지(Teams) 입니다. Teams를 쓰는 조직일수록 “스탠드업 중에 조사 시작”이 기본 시나리오가 되므로, 기본 저장소(default repository) 와 채널 권한을 먼저 정리해야 합니다.

코드 / 설정 예시

문서에 나온 멘션 패턴(요지)은 단순합니다.

@GitHub 스탠드업에서 나온 타임아웃 이슈 재현 경로 조사하고,
repo=acme/api branch=main 기준으로 재현 테스트 PR을 열어줘

채널 기본 저장소를 쓰는 경우 repo= / branch= 를 생략할 수 있습니다. DM에는 기본 저장소가 없다는 점도 로그 설명이 있습니다.

운영 체크리스트를 레포 규칙으로 고정하는 편이 낫습니다.

# teams-copilot-gate.md (team runbook excerpt)

## Before enabling @GitHub in a production channel
- [ ] Org/enterprise: Copilot cloud agent **and** cloud sandboxes enabled
- [ ] Teams client: Public Developer Preview as required by docs
- [ ] GitHub app for Microsoft Teams installed; accounts linked
- [ ] Public channels: default repository set deliberately (not “first mention wins” by accident)
- [ ] Channel membership ≠ repo write access — document who can trigger changes
- [ ] Repo rules: require **additional approval** for Teams Copilot integration identity PRs
- [ ] Budgets: AI credits + sandbox SKU budgets reviewed (sandbox is billed separately)
- [ ] Meeting-chat policy: which meetings may summon the agent (standup vs all-hands)

처음엔 채널 default repo를 “일단 아무거나”로 두고 넘어가려다, 공개 채널에서 첫 세션이 그 값을 박아 버리는 흐름을 문서에서 다시 읽고 멈춘 적이 있습니다. 설정 UI보다 어느 채널이 어느 레포의 기본 붙는지 표가 먼저입니다.

실무에서 쓰는 법

1. 파일럿 채널 하나만 고릅니다. 프로덕션 all-hands가 아니라, 이미 write 멤버가 정리된 팀 채널이 안전합니다.
2. Admin이 cloud agent / sandboxes를 켠 뒤, Teams에 GitHub 앱을 설치하고 계정 연결을 확인합니다.
3. 공개 채널이면 default repository를 의도적으로 지정합니다. DM 실험은 기본 저장소가 없으므로 repo= 를 명시합니다.
4. 스탠드업 미팅 채팅에서 @GitHub 로 “조사만” 시키는 플레이북과, write 보유자가 “PR까지” 여는 플레이북을 나눕니다.
5. 레포 설정에서 Teams 연동 신원 PR에 추가 승인을 켭니다. 이미 승인 2명이 필요하면 Copilot PR은 3명이 됩니다.
6. AI credit / sandbox 예산을 주간으로 보고, 미팅 채팅 호출이 예산을 태우는지 봅니다.

Public preview이므로 UX·정책 문구는 바뀔 수 있습니다. 지금 고정할 것은 UI 단축키가 아니라 권한·신원·예산 세 축입니다.

시니어 엔지니어 관점

채팅 에이전트의 실패 모드는 “틀린 코드”보다 틀린 트리거인 경우가 많습니다. 스탠드업에 초대된 게스트, 외부 파트너, 읽기 전용 이해관계자가 스레드에 맥락을 보태는 것은 유익합니다. 그 사람이 write 없이 변경을 못 열게 한 설계는 맞습니다. 그런데 write 보유자가 “회의 분위기”에 떠밀려 Autopilot에 가깝게 PR을 열면, 앱 신원 + 추가 승인이 없으면 리뷰 문화가 하루 만에 무너집니다.

추가 승인 옵션은 “느려지라고” 있는 게 아닙니다. 에이전트 작성 PR을 사람 PR과 다른 클래스로 취급하라는 신호입니다. Slack 초안과 같은 결론이 Teams에서도 반복됩니다. 표면만 바꾸면 거버넌스가 자동으로 따라오지 않습니다.

Cursor에서 쓰기

Cursor로 이 정책을 팀에 이식할 때는 기능 데모보다 런북 파일을 먼저 만듭니다.

1. 위 체크리스트를 docs/runbooks/teams-copilot.md 로 두고, Cloud Agent / 서브에이전트에게 “이 파일만 근거로 onboarding PR을 초안”하라고 시킵니다.
2. Cursor Subscriptions나 /goal 로 “파일럿 채널 설정 이슈 티켓 3장 작성”처럼 정지 조건이 있는 목표만 줍니다. Teams 멘션을 Cursor가 대신 누르게 하지 마세요 — 채팅 트리거는 사람 손에 둡니다.
3. 리뷰 기준을 AGENTS.md에 한 줄 넣습니다: PRs from chat-agent identities require the extra approval ruleset; do not ask to bypass.

Cursor는 IDE 쪽 에이전트 루프를 돌리고, Teams는 결정이 나는 방입니다. 둘을 한 프롬프트에 섞으면 책임 소재가 사라집니다.

FAQ

Q. Business/Enterprise만 되나요?
A. Teams 변경 로그는 유료 Copilot 플랜 public preview로 설명합니다. org/enterprise 사용자는 cloud agent·sandbox 정책 활성화가 필요할 수 있습니다. 최신 자격은 GitHub 문서·정책 UI를 확인하세요.

Q. Slack Code처럼 전용 채널이 생기나요?
A. 2026-08-21 기준 Teams 쪽 공식 설명은 기존 채널/스레드에서 진행을 따르는 형태입니다. Slack Code와 1:1 대응 표면은 명시되어 있지 않습니다.

Q. 미팅 채팅에서 호출하면 바로 머지되나요?
A. 아니요. 클라우드 샌드박스에서 비동기 작업 후 산출물(이슈/PR 등)이 생기고, 머지는 기존 브랜치 보호·(설정 시) 추가 승인 규칙을 따릅니다.

Q. default repository를 안 정하면?
A. 채널에 기본값이 없으면 첫 세션에 쓴 저장소가 채널 기본값으로 잡힐 수 있다는 문서 설명이 있습니다. 공개 채널에서는 미리 지정하는 편이 안전합니다.

Q. sandbox 요금은 Copilot 구독에 포함인가요?
A. 변경 로그는 클라우드 에이전트 AI credits와 sandbox 별도 과금·예산을 구분합니다. 조직 예산 설정에서 둘 다 확인하세요.

소스

• Shared agentic work with GitHub Copilot in Microsoft Teams (2026-08-21)
• Integrate Copilot cloud agent with Microsoft Teams
• The new GitHub Copilot experience in Slack (2026-08-21)
• Integrate Copilot cloud agent with Slack
• Neowin coverage (secondary paraphrase; deploy 표현은 1차 소스 표현을 우선)

마무리

채팅에서 에이전트를 깨우는 시대는 이미 왔습니다. Teams public preview가 묻는 것은 “할 수 있느냐”가 아니라 누가 트리거하고, 어떤 신원으로 PR이 열리며, 예산을 누가 보느냐 입니다.

앞으로 미팅 채팅이 기본 핸드오프가 되면, “회의록 → 티켓 → 사람” 파이프라인은 “회의록 → @GitHub → 앱 신원 PR”로 압축됩니다. 그 압축을 환영하려면, 추가 승인과 채널-레포 표를 먼저 깔아 두세요. 속도는 그다음입니다.