GitHub Copilot 앱에서 스택 세션 및 스택 PR 출시: 다중 에이전트 병렬 개발을 위한 인프라

AI 코딩 에이전트가 팀처럼 병렬로 작업하기 시작하면 개발자에게 필요한 것은 더 이상 "더 나은 단일 완성"이 아니라 "다중 병렬 워크플로"를 관리하기 위한 인프라입니다. GitHub는 7월 30일에 답변을 제공했습니다. GitHub Copilot 앱은 Stacked Sessions 및 Stacked Pull Requests(Stacked PR)를 도입했으며, Stacked PR은 같은 날 공개 미리 보기에 들어갔습니다.

스택 워크플로는 어떤 문제를 해결하나요?

전통적인 개발 모델은 "한 번의 변경 → 한 번의 PR → 병합 후 다음 작업 수행"입니다. 에이전트 중심 개발을 효율적으로 개발하려면 병렬성이 필요합니다. 대규모 변경 사항을 서로 의존하는 여러 개의 작은 PR로 분할하고 Copilot 앱에서 여러 에이전트 세션을 병렬로 유지 관리합니다. 각 세션은 분기/변경 사항에 해당합니다. 이는 대규모 코드 기반에서 공동 작업의 효율성을 향상시키는 핵심입니다. 여러 에이전트 세션이 동시에 작동하고 각각 변경 사항에 중점을 두고 마지막으로 종속성 순서에 따라 병합됩니다.

제3자에서 정식 제품화까지

Stacked PR은 이전에는 주로 타사 도구에서 지원되었으며 GitHub에서는 이를 Copilot 앱으로 제품화할 예정입니다. 그 이면에는 중요한 제품 판단이 있습니다. AI 코딩 에이전트의 인기로 인해 개발자는 "단일 스레드 수기 코드"에서 "다중 에이전트 병렬 개발"로 전환하고 있으며 스택 세션/PR은 이 새로운 워크플로를 관리하기 위한 인프라입니다. 이러한 기능 세트를 공식 일류 시민으로 만드는 사람은 누구든지 에이전트 시대의 개발자 플랫폼을 활용할 수 있게 될 것입니다.

업계 관점에서 볼 때 Stacked Sessions 및 Stacked PR은 GitHub가 개발자 플랫폼으로서의 지위를 강화하고 Cursor/Devin 생태계와 경쟁하기 위한 중요한 수단입니다. 그것이 밝혀낸 신호는 AI 프로그래밍 경쟁이 "모델 기능"에서 "워크플로 조정"으로 확장되었다는 것입니다. 하나의 에이전트로는 충분하지 않고 여러 에이전트가 병렬로 필요한 경우 협업을 질서 있게 만들고 PR을 명확하고 검토 가능하게 만드는 방법은 엔터프라이즈 수준 팀의 실제 관심사입니다. 국내 코드 호스팅 및 개발 플랫폼의 경우 이는 AI가 코드를 더 효율적으로 작성할 수 있는 것이 아니라 "다중 에이전트 협업"을 위한 완전한 엔지니어링 지원을 제공할 수 있는 경쟁의 다음 단계를 촉발합니다.

앞으로 추적할 가치가 있는 몇 가지 방향은 다음과 같습니다.

1. GA Rhythm 공개 미리보기: Stacked PR의 공식 출시 시간 및 안정성.
2. 타사 스택 도구와의 관계: 공식 제품화 후 Graphite와 같은 도구에 미치는 영향.
3. 여러 에이전트 세션의 충돌 처리: 병렬 변경 간의 종속성 및 충돌 해결 메커니즘.
4. 국내 개발 플랫폼에 대한 후속 조치: Gitee와 같은 플랫폼이 유사한 스택 워크플로우 기능을 제공합니까?