Slack 스레드에서 합의한 내용을 다시 이슈로 옮기고 코딩 에이전트에 설명하는 과정은 자주 끊깁니다. GitHub Copilot Slack 연동은 @GitHub 멘션으로 그 대화를 조사, 이슈 생성, 코드 변경과 PR까지 이어 줍니다. 이 글은 설치부터 첫 작업, 권한 통제까지 바로 적용할 순서로 정리합니다.
GitHub Copilot Slack 연동은 어떤 업무에 맞나
2026년 8월 31일 기준 GitHub Copilot의 Slack 연동은 공개 미리보기입니다. GitHub 공식 연동 문서에 따르면 DM, 채널, 스레드에서 cloud agent 세션을 시작할 수 있습니다. 에이전트는 대화와 허용된 저장소 컨텍스트를 이용해 조사하고, 이슈나 PR 같은 결과물을 만듭니다.
기존 /github 명령과 @GitHub 멘션은 쓰임이 다릅니다.
| 방식 | 맡길 일 | 결과 |
|---|---|---|
/github 명령 |
저장소 알림 구독, 이슈 열기·닫기 | 정해진 GitHub 동작 |
@GitHub 멘션 |
장애 조사, 작업 계획, 이슈 분해 | 답변 또는 GitHub 이슈 |
@GitHub 코드 작업 |
구현, 테스트, 수정 | cloud agent 세션과 PR |
알림만 필요하면 /github subscribe OWNER/REPO가 단순합니다. 대화의 맥락을 판단하고 여러 단계를 수행해야 한다면 @GitHub가 맞습니다.
시작 전에 확인할 조건
현재 공식 문서는 이 기능을 모든 유료 Copilot 플랜에서 사용할 수 있다고 안내합니다. 기능은 미리보기 중이므로 계정에 보이는 범위가 문서와 다른지 먼저 확인합니다. 조직이나 엔터프라이즈 계정은 관리자가 Copilot cloud agent와 cloud sandbox 정책을 허용해야 할 수 있습니다.
Slack 워크스페이스에는 GitHub 앱이 설치되어 있어야 합니다. 조직 저장소를 쓴다면 관리자가 앱이 접근할 저장소도 지정해야 합니다. 코드 변경을 시작하는 사람에게는 대상 저장소의 write 권한이 필요합니다.
Slack에 GitHub 앱을 연결하는 법
- Slack 관리자가 GitHub 앱을 설치하거나 최신 버전으로 갱신합니다.
- 사용할 채널에서
/invite @github를 입력해 앱을 초대합니다. - GitHub 앱과의 DM을 열고 안내에 따라 개인 GitHub 계정을 연결합니다.
- 스레드나 채널에서
@GitHub help를 보내 연동 상태를 확인합니다. - 채널에서
@GitHub settings를 열고 기본 저장소를 지정합니다.
기본 저장소는 채널 구성원에게 공통으로 적용됩니다. 저장소나 브랜치를 요청에 적지 않으면 채널의 기본 저장소와 그 저장소의 기본 브랜치가 선택됩니다. DM에는 채널 기본 저장소를 설정할 수 없으므로 요청마다 OWNER/REPO를 명시하는 편이 안전합니다.
@GitHub로 이슈와 PR 작업을 시작하는 법
처음에는 코드를 바꾸지 않는 요청으로 연결 범위를 확인합니다. 저장소, 대상 브랜치, 해야 할 일, 완료 조건을 한 요청에 넣으면 결과를 검토하기 쉽습니다.
@GitHub acme/storefront 저장소에서 최근 실패한 테스트를 조사해 주세요.
코드는 바꾸지 말고 원인 후보, 근거 파일, 재현 명령을 이 스레드에 정리해 주세요.
확인하지 못한 내용은 추측하지 말고 질문으로 남겨 주세요.
조사 결과가 맞으면 이슈 생성으로 범위를 넓힙니다. Copilot은 한 번에 여러 이슈를 만들고 상위·하위 관계를 지정할 수도 있습니다.
@GitHub acme/storefront에 결제 실패 로그 개선 이슈를 만들어 주세요.
완료 조건은 오류 코드 기록, 민감정보 마스킹, 실패 경로 테스트 추가입니다.
라벨은 observability와 payments를 사용하고 코드는 수정하지 마세요.
코드 변경 요청에는 브랜치와 검증 조건을 추가합니다. 에이전트는 격리된 cloud sandbox에서 비동기로 작업하고 결과 링크를 Slack에 남깁니다.
@GitHub acme/storefront의 develop 브랜치에서 issue #418을 구현해 주세요.
결제 모듈 밖은 수정하지 말고 관련 테스트와 타입 검사를 실행하세요.
실패한 검증이 있으면 숨기지 말고 PR 설명에 기록해 주세요.
DM·스레드·Slack Code는 어떻게 다른가
| 시작 위치 | 사용 신원 | 컨텍스트와 운영 방식 |
|---|---|---|
| GitHub 앱 DM | 연결한 개인 GitHub 계정 | 필요한 대화만 보내 컨텍스트를 좁히기 좋음 |
| 공유 스레드·채널 | GitHub 앱 신원 | 전체 스레드를 읽고 팀원이 함께 방향을 조정 |
| Slack Code 채널 | GitHub 앱 신원 | 한 작업의 계획, 브랜치, PR, 상태를 한곳에서 관리 |
공유 대화에서 시작한 이슈와 PR은 개인이 아니라 GitHub 앱 신원으로 생성됩니다. 작업이 Slack Code 채널로 옮겨지면 이후 지시는 그 채널에서만 이어갑니다. GitHub는 한 작업에 한 Code 채널을 사용하도록 안내하며, 완료 뒤 보관한 채널도 검색하거나 다시 열 수 있습니다.
권한·승인·비용을 통제하는 법
Copilot은 멘션이 달린 메시지만이 아니라 전체 스레드를 작업 컨텍스트로 사용합니다. 그 내용은 에이전트가 만든 결과물에도 남을 수 있습니다. 고객 정보, 비밀 키, 공개 범위가 다른 채널의 내용을 포함하지 말고, 필요한 맥락만 전달하려면 DM에서 새 요청을 시작합니다.
저장소에 write 권한이 있는 사용자만 코드 변경을 시작할 수 있습니다. 다른 일반 참여자는 스레드에서 정보를 보태며 세션을 조정할 수 있지만, Slack 게스트와 저장소 외부 협력자는 세션을 시작하거나 조정할 수 없습니다. 공유 컨텍스트에서 앱 신원으로 만든 PR은 저장소 ruleset이 이미 승인을 요구할 때 추가 승인 1개가 기본으로 붙습니다.
Copilot cloud agent 사용량은 GitHub AI Credits에 반영됩니다. GitHub Copilot 결제 문서는 개인, 조직, 코스트 센터, 엔터프라이즈 수준의 예산이 사용 허용과 차단을 결정한다고 설명합니다. 파일을 바꾸는 요청을 넓히기 전에 Billing & licensing의 AI 사용량과 조직 예산을 확인합니다.
첫 운영은 조사와 이슈 생성부터 시작한다
팀 채널 하나와 테스트 저장소 하나를 정합니다. 첫 요청은 읽기 전용 조사, 두 번째는 이슈 생성으로 제한합니다. 스레드 컨텍스트, 결과물 신원, 저장소 선택, AI Credits가 예상대로 기록된 것을 확인한 뒤에만 작은 코드 변경과 PR 생성으로 범위를 넓힙니다.
공개 미리보기의 지원 범위와 정책은 바뀔 수 있습니다. 실제 도입 직전에는 Slack용 GitHub 앱 사용 문서와 조직의 Copilot 정책 화면을 다시 확인합니다.
댓글 남기기