GitHub Copilot Slack·Teams 업데이트 후, 팀은 Agent를 어떻게 검수할까? 2026 체크리스트

증상: Slack이나 Teams에서 시작한 작업이 어떤 대화와 저장소를 바탕으로 만들어졌는지 불분명합니다.
빠른 조치: 작은 범위의 저위험 작업으로 자격, 대화 출처, 저장소 연결, 중단 복구를 확인한 뒤 확대하세요. 대화 스레드를 코드 변경 승인으로 간주해서는 안 됩니다.

이 안내는 Slack 또는 Microsoft Teams에서 GitHub Copilot cloud agent를 시험하려는 개발팀, 조직 정책을 맡은 관리자, 장시간 작업과 복구 절차를 운영하는 플랫폼 엔지니어를 위한 것입니다.

마지막 업데이트: 2026년 9월 27일. GitHub의 업데이트 공지와 각 플랫폼 접속 문서에서 미리 보기 상태와 기능 범위를 확인했습니다. 업데이트 공지, Slack 접속 안내, Teams 접속 안내

먼저, 미리 보기 자격과 운영 정책부터 대조합니다

GitHub는 2026년 9월 25일 업데이트에서 Slack 및 Microsoft Teams 통합을 공개 미리 보기로 안내했고, 일부 기능은 순차적으로 제공된다고 밝혔습니다. 따라서 다른 조직에서 기능을 봤다는 이유만으로 당신의 테넌트에도 열려 있다고 판단하지 마세요. 공지와 접속 문서의 요금제 자격 표현에 차이가 있다면 임의로 해석하지 말고, 관리자 설정과 시험 계정에서 실제 노출 여부를 확인해야 합니다.

화면이 다르게 보이거나 기능이 빠져 있다면 그 자체를 오류로 단정하지 마세요. 공개 미리 보기의 제공 시점이 계정마다 다를 수 있으므로, 접속 화면과 관리자 설정을 함께 보관하고 지원 범위를 확인한 뒤 시험 여부를 결정합니다. 클라우드 에이전트의 보안 설정은 클라우드 에이전트 보호 설정 안내와 대조하세요.

처음 연결할 때 계정과 저장소를 고정합니다

채널의 기본 저장소나 담당자 설정은 편의 설정일 뿐, 매 작업의 목표 저장소를 보장하는 증거가 아닙니다. 특히 개인 대화와 공유 채널은 실행 계정이나 앱 접근 범위가 다를 수 있습니다. 연결을 마쳤다면 시험 계정, 기본 저장소, 목표 브랜치, 쓰기 권한, 조직 정책을 한 기록에 남기세요.

구성 확인을 마쳤다면 민감한 내용이 없는 작은 요청으로 연결을 시험합니다. 저장소를 명시하고, 실행 전 목표 브랜치와 계정 권한을 다시 확인하세요. 기본값과 지정값이 다를 때 어느 쪽이 결과물에 반영되는지 확인하기 전까지는 실제 프로젝트에서 쓰지 않는 편이 낫습니다.

첫 작업은 대화 출처와 산출물을 한 쌍으로 검증합니다

업데이트 공지는 새 맥락 기능과 작업 링크를 다루지만, 모든 대화 요소가 모든 작업에 자동 전달된다고 단정할 근거는 아닙니다. Slack에서는 첨부 자료와 메시지 링크, Teams에서는 이미지와 전달된 내용이 해당 접속 문서에서 어떻게 설명되는지 확인하세요. 그리고 공개 문서의 설명과 시험 테넌트에서 관찰한 결과를 구분해 기록합니다.

• 민감 정보가 없는 대표 요청을 하나 고르고, 어느 메시지와 첨부 자료가 작업에 필요한 맥락인지 표시합니다.
• 실행 계정, 대상 저장소와 브랜치를 요청에 명시합니다.
• 생성된 issue 또는 PR에서 저장소와 변경 대상을 확인합니다.
• 결과물에서 원래 대화로 돌아가는 링크가 있는지 확인하고, 링크가 없다면 별도로 출처를 남깁니다.
• 스레드 전체가 결정 맥락에 포함될 수 있다는 데이터 경계를 검토하고, 공유 채널에는 비밀 정보나 불필요한 대화를 넣지 않습니다.

주의: 작업이 만들어졌다는 사실은 대화 출처가 정확하거나 코드 변경이 검토됐다는 뜻이 아닙니다. 출처 연결과 코드 검토는 별도의 승인 기준으로 유지하세요.

Teams에서 전달된 내용이나 이미지가 시험 결과에 나타나지 않으면, 공식 문서가 설명하는 기능 범위와 실제 결과를 구분해 기록하세요. 결과가 불완전한 상태에서 스레드 전체를 다시 보내면 민감한 내용까지 작업 맥락에 추가될 수 있습니다.

모델·저장소 변경과 중단 복구를 따로 점검합니다

대화 도중 모델을 바꾸거나 저장소를 전환했을 때 기존 선택이 계속 적용되는지는 실제 대화에서 확인해야 합니다. Slack의 기본 담당자나 저장소 관련 갱신 사항도 마찬가지입니다. 작업 시작 때 지정한 저장소와 최종 PR의 저장소, 원래 대화 링크가 같은 대상을 가리키는지 대조하세요.

복구 검증은 문제를 일부러 반복 실행하는 방식보다, 안전한 시험 작업의 상태 변화와 저장소 기록을 관찰하는 방식으로 진행하세요. 작업이 멈췄거나 응답이 만료된 듯 보여도, 상태와 issue·PR을 확인하기 전에 같은 요청을 다시 보내지 마세요. 중복 산출물이나 이전 저장소의 활동이 발견되면 재시도를 보류하고 세션 상태를 담당자가 확인하도록 합니다.

증거 등급으로 시험 확대와 보류를 결정합니다

아래 등급은 이 글에서 제안하는 운영 판정 기준입니다. 제품 기능을 점수화한 것이 아니며, 실제 테넌트에서 확보한 증거에 적용하세요.

정책·권한·보호 설정이 클라우드 에이전트의 허용 범위와 맞는지도 확인하세요. 대화 기록과 저장소 권한을 같은 증거로 취급해서는 안 됩니다. 또한 Copilot 대화나 클라우드 작업은 결정적 테스트, 코드 리뷰, 병합 승인 절차를 대신하지 않습니다.

Apple 도구 체인이 필요한 프로젝트는 별도로 검증해야 합니다. Slack이나 Teams 통합이 맥OS 실행 환경이나 엑스코드 빌드를 제공한다는 뜻은 아닙니다. 실제 빌드가 납품 조건이라면 엑스코드 빌드 시스템 문서를 참고하고, 원격 맥에서의 검수 범위는 원격 맥과 엑스코드 빌드 안내처럼 별도 환경 기준으로 정하세요.

자주 확인하는 항목

Slack과 Teams에서 접속 방식은 어떻게 구분하나요?

두 플랫폼의 접속 문서를 각각 따라야 합니다. 실제 테넌트에서 기능이 보이는지, 앱이 어느 계정과 저장소 범위에 접근하는지 확인한 뒤 저위험 시험을 시작하세요. 공지에서 공개 미리 보기와 순차 제공을 안내하므로, 한 플랫폼에서 동작한다고 다른 플랫폼에서도 같은 자격과 동작을 기대해서는 안 됩니다.

대화가 실제 작업 맥락에 포함됐는지 어떻게 남기나요?

작업에 사용한 메시지, 링크, 첨부 자료를 구분해 기록하고, 생성된 issue 또는 PR에서 원래 대화로 돌아갈 수 있는지 확인하세요. 링크가 보이지 않거나 첨부 자료의 전달 여부가 모호하다면 추정으로 채우지 마세요. 문서 설명과 시험 결과를 나란히 남기고, 전체 스레드가 맥락이 될 가능성을 고려해 공유 채널의 민감 정보를 제한합니다.

Teams에서 생성된 PR의 저장소가 맞는지 무엇을 봐야 하나요?

요청에 쓴 저장소와 브랜치, 실제 실행 계정의 권한, 생성된 PR의 저장소와 변경 대상을 서로 대조하세요. 채널 기본 저장소만 확인하는 것으로는 부족합니다. 원래 Teams 대화로 이어지는 링크도 함께 확인하고, 저장소나 출처가 맞지 않으면 코드 리뷰 전이라도 시험을 멈춰 설정과 작업 상태를 다시 확인해야 합니다.

끊긴 대화를 다시 보내기 전에 무엇을 확인해야 하나요?

현재 작업 상태, 저장소 변경 내역, 기존 issue와 PR을 먼저 살펴보세요. 이전 요청이 계속 실행 중이거나 이미 산출물이 만들어졌다면 재요청이 중복 작업을 일으킬 수 있습니다. 상태를 명확히 알 수 없으면 담당자가 세션과 결과물을 대조한 뒤 재시도 여부를 정하세요. 복구 기능은 공식 설명과 실제 관찰 기록을 구분해 운영 문서에 남깁니다.

현재 Slack이나 Teams 기반 클라우드 작업은 대화에서 저장소 작업으로 넘어가는 흐름에는 적합할 수 있지만, 실행 환경이 보이지 않을 수 있고, 세션 복구와 산출물 귀속을 별도로 확인해야 하며, 엑스코드 빌드를 대신하지도 않습니다. 반대로 실제 애플 도구 체인이 필요한 작업이라면 맥 환경을 분리해 검증해야 합니다. 이 통합만을 위해 맥을 빌릴 필요는 없지만, 기간이 정해진 맥OS·엑스코드 시험 환경이 필요하다면 MacPull의 맥 대여 환경을 확인해 실제 빌드와 제출 기준을 검증할 수 있습니다. 자세한 이용 정보는 MacPull 안내에서 확인하세요.

자주 묻는 질문