Slack과 Teams로 들어온 Copilot: 팀 대화가 코딩 작업의 시작점이 된다

장애 대화가 끝나기 전에 수정 작업을 시작한다

채팅방에서 오류 로그를 공유하고 원인을 설명한 뒤, 누군가 그 내용을 다시 IDE로 옮긴다. 이 과정의 문맥이 빠지기도 한다. 8월 22일 브리핑의 Copilot 통합은 팀이 논의하는 장소에서 작업을 시작하게 한다.

대화에서 에이전트 세션과 PR까지

GitHub는 8월 21일 Slack용 Copilot 경험을 공개 프리뷰로 발표했다. 대화에서 @GitHub를 호출해 문제 조사, 변경 계획, 구현과 검증, PR 생성으로 이어갈 수 있다고 설명한다.

같은 날 Microsoft Teams의 공유 에이전트 작업도 발표했다. 핵심은 한 사람이 따로 전달하던 요청을 팀이 함께 보고 문맥을 보탤 수 있다는 점이다. 실제 제공 범위와 조직의 활성화 정책은 따로 확인해야 한다.

공유된 요청에는 명확한 책임도 필요하다

여러 사람이 문맥을 보탤 수 있어도 완료 기준은 명확해야 한다. 의견이 오가는 동안 수정 범위가 늘면 처음 맡긴 문제와 다른 결과가 나올 수 있다.

공식 Slack 발표는 기존 GitHub 권한과 통제가 적용되며 추가 PR 승인을 요구할 수 있다고 설명한다. 대화에 참여한다는 이유만으로 모든 저장소 작업이 허용되는 것은 아니다.

좋은 요청은 검토 가능한 결과를 남긴다

팀 대화에서 맡길 때는 다음 네 가지를 짧게 적는 편이 좋다. 여기부터는 공유 작업의 품질을 위한 제안이다.

• 어떤 증상을 해결할지.
• 어떤 저장소와 범위에서 작업할지.
• 무엇을 확인하면 완료로 볼지.
• 누가 PR을 검토할지.

채팅에 붙이는 로그와 문서에는 필요한 문맥만 담자. 완성된 PR과 검증 결과를 원래 대화로 연결하면 논의와 변경 이유를 함께 추적하기 쉽다.

오늘의 방아쇠는 새로운 채팅 명령보다, 팀이 함께 이해할 수 있는 작업 요청 한 문장이다.

참고 자료

• The new GitHub Copilot experience in Slack — GitHub, 2026-08-21
• Shared agentic work with GitHub Copilot in Microsoft Teams — GitHub, 2026-08-21