회의 대화가 바로 코드가 된다면, AI에게 어디까지 읽게 해야 할까요?

핵심 요약 (TL;DR)

GitHub는 9월 25일 Slack과 Microsoft Teams용 Copilot의 문맥 처리와 작업 연결을 개선했다고 발표했습니다. 대화 속 자료를 참고하고, 만들어진 GitHub 작업에서 원래 논의로 돌아갈 수 있게 하는 변화입니다. 회의 내용을 다시 설명하는 수고를 줄일 가능성이 있습니다. 대신 채팅방의 어느 부분이 코드 작성의 근거가 되는지 먼저 정해야 합니다.

대화에서 무엇을 가져올 수 있게 됐을까요?

공식 발표는 Slack의 지원되는 파일·첨부·메시지 링크, Teams의 인라인 이미지·전달된 메시지 문맥·채널과 스레드 이력을 설명합니다. 새 이슈를 만들기 전에 비슷한 이슈를 확인하고, 결과 작업과 원래 대화 사이의 링크도 남깁니다. 모든 파일 형식을 읽는다거나 중복 이슈를 완전히 없앤다는 보장은 아닙니다.

다음 메시지에 쓸 모델을 바꾸고 그 선택을 대화에서 유지할 수 있으며, Slack에서는 기본 소유자와 저장소를 지정할 수 있다고 합니다. 저장소를 바꾼 뒤 이전 세션이 옛 저장소에서 계속 작업하지 못하도록 하는 개선도 포함됐습니다.

채팅방이 곧 요구사항 문서여도 괜찮을까요?

회의 대화에는 확정된 결정만 있지 않습니다. 취소한 아이디어, 고객이 보낸 개인정보, 농담처럼 나온 제안이 함께 쌓입니다. Teams 공식 문서는 GitHub를 호출하면 전체 스레드가 문맥으로 수집되고, 생성된 산출물에 그 문맥이 저장된다고 안내합니다. 편리한 연결인 동시에 자료를 가져가는 범위가 넓어지는 변화입니다.

따라서 긴 기존 대화에서 곧바로 구현을 맡기기보다, 새 스레드에 확정한 요구사항만 정리하는 편이 좋습니다. ‘견적 입력 후 담당자가 검토해 저장한다’처럼 행동을 적고, 고객 발송이나 결제는 이번 작업에서 제외한다고 덧붙여 보세요. 이는 팀이 정할 운영 방식입니다.

작은 팀은 어떤 순서로 시험하면 좋을까요?

첫 작업은 중요한 고객 기능보다 테스트 저장소의 작은 수정으로 고르세요. 시작 전에 대상 저장소와 브랜치, 허용할 변경, 완료 조건을 확인합니다. AI가 계획을 제시하면 대화에서 나온 추정이 확정 요구사항으로 섞이지 않았는지 먼저 읽어 보세요.

결과 링크를 받았다고 작업이 끝난 것은 아닙니다. 변경된 파일과 실행 결과를 보고, 요청한 화면이나 동작을 직접 확인해야 합니다. 원래 대화로 돌아가는 링크는 ‘왜 고쳤는가’를 추적하는 데 유용하지만 ‘올바르게 고쳤는가’를 증명하지는 않습니다. 논의의 기록과 제품 검증은 따로 남겨야 합니다.

이번 발표는 Business·Enterprise 조직을 대상으로 한 공개 미리보기이며 일부 기능은 점진적으로 제공된다고 명시합니다. 사용량도 기존 Copilot 이용 한도와 클라우드 에이전트 예산에 반영됩니다. 설치만 하면 누구나 같은 기능을 무료로 쓸 수 있다고 해석하지 마세요. 이 글은 공식 발표와 문서의 정리이며 실제 계정 연결이나 비용 비교 실험은 하지 않았습니다.

FAQ: Teams에 참여한 사람이라면 누구나 코드를 바꿀 수 있나요?

공식 문서상 변경을 시작하려면 저장소 쓰기 권한이 필요합니다. 다만 다른 대화 참여자의 입력도 작업 문맥에 들어갈 수 있으므로, 실행 권한과 입력 자료의 범위를 따로 살펴야 합니다.

FAQ: 전체 스레드가 들어가는 것을 줄일 수 있나요?

Teams 문서는 문맥을 제한하려면 GitHub 앱에 직접 메시지를 보내는 방법을 안내합니다. 새 스레드에 필요한 내용만 적는 방식도 검토하되, 민감한 자료를 붙이기 전에 조직의 허용 범위를 확인하세요.

출처: https://github.blog/changelog/2026-09-25-updates-to-github-copilot-for-slack-and-microsoft-teams/
공식 문서: https://docs.github.com/copilot/how-tos/copilot-integrations/integrate-cloud-agent-with-teams
관찰 시점: 2026-09-27 KST