GitHub Stacked PRs, pull request UI에 native stack workflow를 들여오다

GitHub가 내놓은 것

GitHub는 GitHub Stacked PRs의 private preview를 열고, 큰 변경을 서로 의존하는 작은 pull request 체인으로 나누는 workflow를 제시했다. GitHub 모델에서는 각 PR이 곧바로 default branch를 향하는 대신 바로 아래 branch를 base로 삼는다. gh stack CLI가 branch 생성, push, rebase, PR 제출을 맡고, pull request UI는 stack map을 보여줘 reviewer가 layer 사이를 오가도 맥락을 잃지 않도록 한다.

제품 메시지는 단순하다. 큰 diff는 review가 느리고 흐름을 깨기 쉽다. GitHub는 feature를 작고 순서 있는 단위로 나눠 review comment를 국소화하고, 점진적으로 merge하고, 결국 “거대한 PR 하나가 모든 것을 막는” 상황을 줄이겠다고 말한다.

엔지니어들이 주목한 이유

이번 Hacker News 토론이 눈길을 끈 이유는 GitHub가 stacked development를 외부 관행이 아니라 core PR system의 일급 기능으로 다루려 하기 때문이다. preview 문서에 따르면 branch protection rule은 direct base branch만이 아니라 최종 target branch를 기준으로 평가된다. CI 역시 stack 안의 각 PR을 최종 branch로 향하는 것처럼 실행한다. 이는 중간 PR은 green인데 실제 최종 merge에서는 깨지는, 기존 self-made stack workflow의 큰 빈틈을 줄이는 방향이다.

GitHub는 stack 전체 또는 일부만 merge할 수 있고, merge 뒤 남은 PR은 lowest unmerged PR이 올바른 branch를 다시 가리키도록 자동 rebase된다고 설명한다. 이미 Graphite나 Meta의 오래된 ghstack 방식에 익숙한 팀에게 중요한 신호는 아이디어 자체보다, 그 아이디어가 GitHub native UI와 merge flow 안으로 들어왔다는 점이다.

앞으로 볼 지점

아직은 private preview이므로 branch protection이 강한 저장소, merge queue, 여러 팀이 얽힌 review 환경에서 얼마나 안정적으로 동작하는지가 진짜 시험대가 된다. 그럼에도 이번 출시는 GitHub가 stacked change를 expert용 우회로가 아니라 mainstream review pattern으로 본다는 뜻에 가깝다. 문서에 npx skills add github/gh-stack 기반의 AI agent integration 경로까지 포함된 점도 흥미롭다. GitHub가 사람뿐 아니라 coding agent 역시 stack을 만들고, 탐색하고, 유지하는 흐름을 일상적인 개발 방식으로 상정하고 있음을 보여주기 때문이다.