Slack·Teams의 @GitHub GA: 대화 맥락·권한·PR 승인 점검

대화에서 코드 변경과 사람의 검토로 이어지는 흐름을 표현한 생성형 개념 이미지. 실제 제품 화면은 아니다.

GitHub가 November 6, 2026 Slack과 Microsoft Teams의 @GitHub를 정식 출시했다. 대화에서 버그를 조사하고 이슈를 만들거나 코드 변경과 풀 리퀘스트(PR)를 요청할 수 있다. 이번 발표에는 Teams Canvas, 메시지에서 저장소를 파악하는 온보딩 개선, 생성한 이슈·PR에 대화 출처와 요청자를 표시하는 변경도 포함됐다. 공식 출시 발표

팀에서 도입할 때 먼저 정할 것은 어떤 대화를 전달하고, 누가 변경을 지시하며, 누가 결과를 승인할지다. 아래는 November 8, 2026 공식 문서 기준의 동작과 이를 바탕으로 제안하는 도입 점검 순서다.

1. 호출 한 줄보다 넓은 대화 맥락이 전달된다

GitHub 문서는 @GitHub 호출 시 스레드 전체를 작업 맥락으로 수집하며, 이 맥락이 에이전트가 만드는 산출물에 저장된다고 설명한다. 맥락을 좁히려면 GitHub 앱과의 직접 메시지를 사용할 수 있다. Slack 보안 고려 사항

예를 들어 장애 대응 스레드에는 재현 절차뿐 아니라 고객 식별 정보, 내부 운영 주소, 아직 확정하지 않은 추측이 섞여 있을 수 있다. 이 스레드를 그대로 구현 요청에 연결하기보다, 별도 대화에 필요한 재현 조건과 기대 동작만 정리하는 편이 좋다. 직접 메시지를 쓰더라도 입력한 정보가 에이전트에 전달된다는 사실은 같으므로 비밀값을 붙여 넣지 않는다.

실무적으로는 다음 세 가지를 먼저 정리하자.

• 입력 범위: 필요한 메시지만 남긴 새 스레드 또는 직접 메시지에서 시작한다.

• 작업 범위: 대상 저장소·기준 브랜치·수정할 부분을 명시한다.

• 산출물 확인: 생성된 이슈와 PR 설명에 불필요한 내부 정보가 들어갔는지 검토한다.

2. 대화 참여와 변경 지시는 권한이 다르다

공유 채널이나 그룹 스레드에서 생성되는 PR 등의 산출물은 Copilot 앱의 신원으로 만들어진다. 직접 메시지에서는 연결한 개인 GitHub 계정의 권한을 사용한다. 세션의 변경을 시작하거나 지시하려면 선택한 모든 저장소에 write 권한이 필요하지만, 대화 참여자는 누구나 맥락을 제공할 수 있다. 워크스페이스 게스트와 저장소의 외부 협업자는 세션을 시작하거나 지시할 수 없다. Teams 협업 세션과 권한

따라서 운영 담당자의 “이 동작도 필요하다”는 메시지와, 권한 있는 개발자의 변경 지시를 팀에서 구분해야 한다. 권한이 없는 참여자의 의견도 작업 맥락에 들어갈 수 있으므로, 담당자가 확정된 요구사항을 다시 정리하는 절차가 유용하다.

설치 권한도 함께 검토해야 한다. 공식 권한 목록에는 코드 읽기 외에 콘텐츠 쓰기와 워크플로 읽기·쓰기가 포함되어 있다. 이는 PR 생성과 에이전트 세션 시작 등에 쓰인다. 기존에 알림용으로 사용하던 연동을 확장할 때도 실제 승인 화면과 저장소 접근 범위를 확인하자. Slack 권한 목록, Teams 권한 목록

3. Slack Code와 Teams Canvas의 역할을 구분한다

Slack에서는 작업용 Slack Code 채널이 만들어지고, 이후 세션 지시는 그 채널에서 이어간다. 채널 하나는 작업 세션 하나를 위한 공간이다. 원래 논의 스레드에만 후속 지시를 남겨 놓고 반영됐다고 가정하지 않는 것이 좋다. 유료 Copilot 플랜과 설치된 GitHub 연동이 필요하며 조직 정책도 확인해야 한다. Slack 사용 문서

Teams의 Canvas에서는 계획, 파일 변경, 생성한 PR 개요를 대화 옆에서 확인한다. 공식 문서상 Canvas는 읽기 전용이며, 연결된 GitHub 계정으로 이미 볼 수 있는 내용만 표시한다. 팀원이 화면을 볼 수 있다는 사실과 병합을 승인했다는 사실을 혼동하면 안 된다. Teams Canvas 문서

양쪽 모두 작업은 클라우드 샌드박스에서 비동기로 진행된다. 채팅 응답만 기다리기보다 세션의 저장소·브랜치와 최종 PR 링크를 기준으로 검토 대상을 맞추는 것이 좋다.

4. 앱이 만든 PR의 추가 승인 조건을 확인한다

GitHub ruleset에는 사람에게 귀속되지 않는 Copilot PR에 추가 승인을 요구하는 설정이 있다. 이 설정은 공개 미리보기이며, 새 ruleset과 기존 ruleset에 기본 활성화되어 있다.

• 원래 승인 1개가 필요한 ruleset이면, 해당 Copilot PR에는 write 권한이 있는 사람들의 승인 2개가 필요하다.

• 원래 승인 0개인 ruleset에는 이 설정이 효과를 내지 않는다.

• 설정을 끄면 원래 지정한 승인 개수만 요구한다.

공유 대화에서 앱 신원으로 만들어진 PR을 도입할 때 확인할 조건이다. “GA가 되었으니 모든 저장소에서 추가 승인이 보장된다”는 식으로 일반화해서는 안 된다. 적용되는 ruleset과 우회 권한, 필수 상태 검사를 실제 저장소에서 확인해야 한다. ruleset의 추가 승인 규칙

5. 첫 도입은 작은 변경 하나로 검증한다

다음은 공식 기능 설명을 바탕으로 한 운영 제안이다. 처음부터 여러 저장소와 외부 도구를 연결하기보다, 테스트 저장소의 작은 문서 변경으로 경계를 확인하자.

1. 앱의 저장소 접근 범위, 유료 플랜, 조직의 Copilot 정책을 확인한다.

2. 내부 정보가 없는 새 대화에서 저장소와 기준 브랜치를 명시한다.

3. 생성된 세션의 실제 대상과 PR 작성 신원, 대화 출처 표시를 확인한다.

4. 변경 파일·PR 설명·CI 결과·필요 승인 수를 사람이 검토한다.

예를 들어 테스트 저장소에서 다음처럼 요청할 수 있다. example-org/docs-sandbox와 main은 실제로 승인된 테스트 대상으로 바꿔야 한다.

이는 요청 예시일 뿐, 자연어 문구만으로 권한이나 병합 제한이 강제되는 것은 아니다. 허용 범위는 앱 설정과 저장소 규칙으로 제한하고 결과를 검토해야 한다.

@GitHub의 실용적인 가치는 대화에서 합의한 내용을 구현 작업으로 옮기는 수고를 줄이는 데 있다. 그 이점을 유지하려면 대화 입력, 실행 권한, PR 검토의 경계를 먼저 확인하는 것이 좋다.

검증 범위: 이 글은 공식 공개 발표와 문서를 대조해 작성했다. Slack·Teams 앱 설치, 계정 연결, 에이전트 실행, 실제 PR 생성이나 과금 테스트는 하지 않았다. 플랜별 사용량·가격과 조직별 허용 정책은 도입 시 별도로 확인해야 한다.