Teams의 GitHub 이슈 알림에서 수정 PR까지, Copilot에 맡기는 법

세 줄 요약

Teams의 통합 GitHub 앱에서 이슈 알림을 받은 뒤 같은 대화에서 수정 작업을 요청할 수 있다.
코드 변경을 시작하려면 유료 Copilot 이용 권한, 활성화된 클라우드 샌드박스, 저장소 쓰기 권한이 필요하다.
Copilot이 PR을 만들더라도 팀의 코드 검토·테스트·병합 단계는 남는다.

버그를 논의한 대화에서 수정 PR을 요청한다

Teams로 GitHub 이슈 알림을 받는 팀이라면, 그 알림을 보고 별도의 작업 요청을 다시 적는 단계를 줄일 수 있다. GitHub의 10월 23일 업데이트는 알림과 Copilot을 하나의 Teams 앱에 연결했다. 이슈가 도착한 대화에서 @GitHub를 멘션해 조사와 코드 수정, 풀 리퀘스트 생성을 요청하는 흐름이다.

알림이 왔다는 이유만으로 버그가 자동 수정되는 기능은 아니다. 개발자가 작업을 요청하고, Copilot이 수정안을 제안하면 팀이 검토·테스트·병합한다. 결과물은 다음 리뷰 단계로 넘길 PR이다.

앱 연결과 코드 변경 권한을 함께 갖춰야 한다

Teams용 Copilot cloud agent는 공개 미리 보기로 제공된다. 유료 GitHub Copilot 플랜과 Teams 계정이 필요하며 클라우드 샌드박스도 활성화돼 있어야 한다. 회사 계정은 조직·기업 관리자의 허용이 필요할 수 있다. 저장소 코드를 바꾸는 작업을 시작하려면 해당 저장소에 쓰기 권한이 있어야 한다.

앱이 설치된 Teams에서 @GitHub를 입력하면 계정 연결과 저장소 선택 안내가 나온다. 기존 GitHub notifications 앱 사용자는 최신 버전으로 업데이트하면 된다. 구형 앱의 교체 대상과 종료 일정은 Teams GitHub 앱 통합 안내에서 구별할 수 있다.

어느 저장소의 무엇을 고칠지 적는다

채널의 기본 저장소와 다른 곳을 수정하거나 특정 브랜치를 기준으로 PR을 만들려면 요청에 대상을 명시한다. 다음은 입력 검증 버그를 맡기는 요청 예시다. OWNER/REPO와 main은 실제 저장소와 기존 기준 브랜치로 바꾼다.

@GitHub 이 이슈의 빈 입력 처리 오류를 수정하고 회귀 테스트를 추가한 PR을 만들어 줘. repo=OWNER/REPO branch=main

같은 스레드에서 다시 @GitHub를 멘션해 요구사항을 보탤 수 있다. 예를 들어 “빈 문자열뿐 아니라 공백만 입력한 경우도 처리해 줘”처럼 빠진 조건을 추가한다.

작업에 사용되는 문맥에는 스레드 전체가 포함된다. 다른 주제까지 섞인 긴 대화라면 별도 대화로 범위를 좁히거나 GitHub 앱에 직접 메시지를 보내는 편이 적절하다.

PR 생성 뒤에는 알림과 검토 흐름을 연결한다

Teams의 GitHub 통합은 채널에서 이슈·PR별 알림을 스레드로 묶고 카드에 상태를 표시한다. 공유 대화에서 Copilot이 만든 PR은 앱의 신원으로 생성된다. 저장소 규칙 세트가 이미 하나 이상의 승인을 요구한다면, 이러한 PR에 승인을 한 번 더 요구하는 옵션이 기본으로 켜져 있다.

리뷰와 CI 결과까지 채널에서 받으려면 알림 구독 설정도 맞춰야 한다. 이슈·PR 알림과 달리 리뷰·워크플로 알림은 기본 활성화 항목이 아니다. 아래 명령으로 두 종류를 추가할 수 있다.

@GitHub subscribe OWNER/REPO reviews workflows

팀의 작업은 “PR이 생겼다”에서 끝나지 않는다. 원래 버그가 재현되는 조건과 회귀 테스트를 대조하고 변경 내용을 승인한 뒤 병합한다. Teams는 요청과 후속 대화를 잇는 입구가 되고, PR은 변경 내용을 판단하는 장소로 남는다.