Slack의 Copilot, 프런트·백엔드 저장소를 함께 보며 버그 찾기

화면 오류의 원인이 API인지도 같은 대화에서 물을 수 있다

프런트엔드와 API가 별도 저장소에 있어도 Slack에서 대화를 두 개로 나눌 필요 없이 함께 조사하도록 요청할 수 있다. GitHub는 10월 15일 Slack·Teams의 다중 저장소 대화 지원을 발표하면서, 두 저장소의 코드를 참고하는 버그 조사를 예로 들었다.

가령 로그인한 뒤 장바구니가 비어 보이는 문제가 있다면, 화면을 만드는 코드와 목록을 반환하는 API를 함께 지정할 수 있다. 아래는 저장소 이름과 증상을 바꿔 쓸 수 있는 요청 예시다.

“@GitHub my-org/web와 my-org/api에서 로그인 후 장바구니가 비어 보이는 원인 후보를 찾아줘. 화면이 보내는 요청과 API가 반환하는 필드를 대조하고, 관련 파일과 추가로 필요한 재현 정보를 알려줘. 지금은 코드 변경이나 PR 생성 없이 조사 결과만 보여줘.”

두 저장소를 언급하는 이유는 조사에 필요한 코드 범위를 분명히 하기 위해서다. 원인 후보를 받은 뒤 수정할 저장소와 작업 범위를 정하면 된다. 여러 저장소를 참고하는 조사 기능이 두 저장소의 수정과 배포까지 한 번에 완료한다는 뜻은 아니다.

이름을 빼면 채널 기본 저장소로 돌아간다

채널 기본값은 저장소와 브랜치를 생략한 요청에 사용된다. 채널에 기본 저장소가 없었다면 첫 세션에서 사용한 저장소가 기본값이 된다. 이후 API 문제를 물었는데 웹 저장소가 선택되는 상황이 생길 수 있는 이유다.

채널 기본값을 바꾸려면 @GitHub settings를 보내 저장소를 선택하고 저장한다. 이 설정은 채널의 모든 사용자에게 적용된다. 한 번의 버그 조사를 위해 다른 저장소가 필요하다면 채널 전체 기본값을 바꾸기보다 요청에 조직/저장소와 필요한 브랜치를 명시하는 편이 목적이 분명하다.

Copilot과의 DM에는 채널용 기본 저장소를 설정할 수 없다. 채널에서 쓰던 기본값이 DM에도 이어진다고 가정하지 말고 대상 이름을 적는다.

원인 조사에 필요한 대화를 한 스레드에 모은다

Slack 연동은 요청 한 줄뿐 아니라 해당 스레드 전체를 맥락으로 사용한다. 예시처럼 ‘장바구니가 비어 보인다’는 증상을 전달할 때는 재현 순서, 기대한 화면, 실제로 본 결과를 같은 대화에 모아 두는 편이 낫다. 관련 없는 업무 대화가 길게 섞였다면 새 스레드나 DM으로 조사 범위를 좁힐 수 있다.

GitHub의 Slack 제품 안내는 여러 단계의 작업을 전용 Code Channel에서 이어가는 흐름을 제시한다. 이곳에서 팀은 계획을 보고 맥락을 보태며, 브랜치와 결과 PR을 함께 추적할 수 있다. Code Channel이 생긴 뒤에는 그 채널에서 후속 지시를 이어간다.

조사와 코드 변경은 결과를 읽는 기준도 다르다. 조사 결과에서는 원인 후보와 관련 파일을 검토하고, 수정 작업으로 이어졌다면 PR의 변경 내용과 검사를 봐야 한다. 대화에 참여했다는 사실만으로 코드 변경의 승인·병합 권한을 얻지는 않는다.

채팅방 초대와 저장소 접근은 별도 설정이다

2026년 10월 26일 기준 Copilot Slack 연동은 유료 Copilot 요금제에서 공개 미리보기로 제공된다. 시작하려면 GitHub 앱을 Slack에 설치하고 GitHub 계정을 연결해야 한다. 클라우드 샌드박스와 cloud agent 사용 정책도 허용돼 있어야 하며, 조직 설정에 따라 소유자의 활성화가 필요하다.

cloud agent 작업을 시작하는 사용자는 대상 저장소 쓰기 권한이 필요하다. 엔터프라이즈 저장소에서는 관리자가 Slack용 GitHub 앱에 허용한 저장소 범위도 확인해야 한다. 워크스페이스 게스트와 저장소 외부 협업자는 Slack에서 세션을 시작하거나 지시할 수 없다.

두 저장소를 조사할 준비가 됐다면 이름과 증상을 명시한 요청부터 시작한다. Slack에 쌓인 논의를 옮겨 적는 수고를 줄이면서도, 실제로 어느 코드에 근거한 답인지와 다음에 무엇을 바꿀지는 팀이 확인할 수 있어야 한다.