슬랙과 마이크로소프트 팀즈에서 깃허브를 쓰는 개발팀은 이제 대화 하나에서 여러 코드 저장소를 함께 다룰 수 있다. 이슈 생성부터 코드 수정과 버그 조사까지, 저장소별로 대화를 새로 열지 않고 이어갈 수 있다는 변화다.
1. 저장소가 달라도 대화는 이어진다
깃허브는 2026년 10월 15일 변경 로그에서 다중 저장소 지원을 발표했다. 저장소는 프로젝트의 코드와 변경 이력을 모아 두는 공간이다. 이번 개선은 서로 다른 공간에 있는 작업을 하나의 대화에서 요청할 수 있게 한 것이다.
예를 들어 화면을 담당하는 코드와 서버를 담당하는 코드가 다른 저장소에 있어도, 두 곳을 함께 살펴보는 버그 조사를 요청할 수 있다. 대화의 단위가 저장소 하나에 묶이지 않는다는 점이 핵심이며, 여러 저장소를 하나로 합친다는 뜻은 아니다.
2. 이슈 생성부터 변경 요청 확인까지
원문은 네 가지 활용 예를 제시한다. 첫째는 대화에서 나온 버그를 추적하도록 특정 저장소에 이슈를 만들고, 해당 대화의 맥락을 활용하게 하는 요청이다. 논의 내용을 작업 항목으로 옮기는 사례다.
둘째는 화면 쪽 저장소의 버그를 고치고 변경 요청을 열게 하는 것이다. 변경 요청은 수정한 코드를 프로젝트에 반영하기 전에 검토할 수 있도록 올리는 제안이다. 여기서는 코드 수정과 검토 요청 생성을 한 요청으로 연결한다.
셋째는 여러 저장소에 걸쳐 자신이 열어 둔 변경 요청을 모아 보고, 주의가 필요한 항목을 짚게 하는 것이다. 넷째는 화면 쪽과 서버 쪽 저장소의 코드를 함께 사용해 이슈를 조사하게 하는 요청이다. 각각 흩어진 작업을 확인하거나, 저장소 경계를 넘는 문제를 살피는 예다.
3. 호출 위치와 슬랙 맥락 활용도 바뀐다
메시지에서 깃허브를 부르는 위치도 자유로워졌다. 이제 메시지 맨 앞뿐 아니라 어느 위치에서든 @GitHub를 언급할 수 있다. 원문은 대화 중 저장소를 더 쉽게 전환할 수 있도록 개선했다고도 설명한다.
슬랙에서는 공유된 메시지와 대화 묶음인 스레드를 작업 맥락으로 사용할 수 있다. 앞서 나눈 논의를 다시 설명하기 위해 세부 내용을 복사해 붙여 넣는 수고를 덜어 주는 변화다. 다만 같은 맥락 활용 기능을 팀즈에도 제공하는지는 제시되지 않았다.
4. 작업 시작과 중단 뒤 복구를 개선했다
깃허브는 두 메신저에서 오류를 줄이고 작업 시작을 개선했으며, 중단 뒤에도 작업을 더 원활하게 복구하도록 손봤다고 밝혔다. 이는 여러 저장소 지원과 함께 발표된 신뢰성 개선이다.
이 설명을 작업이 중단 없이 끝난다는 보장으로 읽어서는 안 된다. 오류 감소 폭이나 작업 시작 시간, 복구 성공률 같은 수치는 제시되지 않았다. 따라서 개선의 방향은 알 수 있지만, 빨라지거나 안정된 정도를 수치로 비교할 근거는 없다.
5. 전환 부담과 검토 범위를 함께 봐야 한다
이득은 저장소마다 대화를 옮기는 부담이 줄어든다는 점이다. 특히 여러 저장소의 코드를 함께 살펴야 하는 조사에서는 관련 요청을 한 흐름에 둘 수 있다. 슬랙의 대화 맥락 활용은 여기에 앞선 논의를 다시 전달하는 수고까지 줄이는 역할을 한다.
반면 여러 저장소를 한 번에 다루는 편의와 결과 검토의 범위는 구분해서 볼 필요가 있다. 팀은 대화 전환이 줄어드는 이익뿐 아니라, 요청 대상과 결과가 어느 저장소에 해당하는지 살피는 부담도 함께 따져보는 편이 좋다.
한 대화에서 다룰 수 있는 저장소 수의 상한, 저장소 전환의 구체적인 조작 방법, 요금제와 과금 범위는 원문에 제시되지 않았다. 도입을 검토한다면 실제 사용 조건을 별도로 확인할 항목이다.
이번 개선의 핵심은 여러 저장소의 작업을 한 대화로 연결하는 데 있으며, 도입 판단은 전환의 편의와 작업 범위를 검토하는 부담을 함께 기준으로 삼아야 한다.