Teams의 GitHub 앱 통합, 11월 16일 무엇이 끝나나?

11월 16일 종료되는 것은 구형 앱이다

GitHub가 10월 23일 Teams용 통합 앱을 소개했다. 저장소 알림을 받은 자리에서 @GitHub를 불러 문제 조사와 코드 수정을 요청하고 PR까지 만들 수 있다. 기존 사용자에게 먼저 필요한 일은 설치한 앱의 구별이다.

같은 GitHub 이름을 사용해도 전환 방법은 다르다. 종료 예정일을 Teams의 GitHub 알림 전체가 사라지는 날로 받아들일 필요는 없다.

앱 설치와 AI 작업 권한은 따로 충족해야 한다

GitHub의 설치 문서는 GitHub 계정, 앱 설치 권한이 있는 Teams 작업 공간, Teams 클라이언트의 Microsoft Public Developer Preview 활성화를 사전 조건으로 적고 있다. Teams의 프리뷰 참여는 관리자 정책의 영향을 받는다.

Copilot에 작업을 맡기려면 유료 GitHub Copilot 요금제와 활성화된 cloud sandboxes가 필요하다. 조직·기업 계정에서는 소유자가 Copilot cloud agent와 cloud sandboxes를 허용해야 할 수 있다. 앱을 설치했다고 이 조건들이 함께 충족되는 것은 아니다.

Copilot의 Teams 통합은 10월 26일 기준 공개 프리뷰다. 설치 뒤 @GitHub를 호출해 계정을 연결하고, 안내가 나오면 기본 저장소를 정한다. 작업 대상 저장소를 요청에 지정하지 않으면 기본 저장소가 이슈와 PR 생성의 기준이 된다.

알림을 받는 것과 수정을 요청하는 것은 두 단계다

채널에서 저장소 알림을 구독하는 공식 명령은 다음과 같다. OWNER/REPO는 실제 저장소 이름으로 바꾼다.

@GitHub subscribe OWNER/REPO
@GitHub subscribe list

첫 명령은 해당 저장소를 구독하고, 둘째는 채널의 구독 목록을 보여준다. 연결 과정에서 저장소나 조직에 앱 접근 권한을 부여하라는 안내가 나올 수 있다.

알림이 도착한 뒤에는 @GitHub와 함께 원하는 작업을 요청한다. GitHub가 제시한 흐름은 버그 알림, 조사·수정과 PR 생성, 팀의 검토·테스트·병합 순서다. 알림을 구독하는 명령 자체가 버그 수정이나 병합 요청은 아니다.

공유 채널에서 만든 PR은 앱 명의다

Copilot은 대화의 스레드 전체를 작업 문맥으로 사용한다. 권한 문서에 따르면 DM에서는 연결한 개인 GitHub 계정의 권한으로 작업하고, 채널이나 그룹 스레드에서는 앱의 신원으로 PR 같은 결과물을 만든다.

변경 작업을 시작할 수 있는 사람은 저장소 쓰기 권한자다. 다른 대화 참여자는 의견을 보탤 수 있지만, 작업 공간의 게스트와 저장소의 외부 협업자는 Teams에서 Copilot 세션을 시작하거나 지시할 수 없다.

채널·그룹 대화에서 만든 PR의 승인 규칙도 확인해야 한다. 저장소가 rulesets를 사용하고 이미 최소 한 개의 승인을 요구한다면, 앱 명의로 생성된 해당 PR에는 승인 하나가 더 필요하다. 이 동작은 기본 활성화돼 있다. 앱 전환 뒤에는 알림 수신뿐 아니라 실제 PR의 작성 주체와 요구 승인 수도 함께 확인하는 편이 좋다.

자주 묻는 질문