GitHub이 7월 30일 발표한 Stacked Pull Request 공개 프리뷰는 코드 리뷰 방식을 바꾸는 기능이다. 큰 변경 사항을 하나의 거대한 PR로 올리는 대신, 서로 의존하는 여러 개의 작은 PR을 순서대로 쌓아 올리고, 각각을 따로 검토한 뒤 한 번에 병합할 수 있게 한다.
지금까지 개발자들이 흔히 겪은 문제는 이렇다. 기능 하나를 완성하려면 데이터 모델 변경, API 스키마 수정, UI 적용처럼 여러 단계를 거쳐야 하는데, 이를 하나의 PR로 올리면 리뷰어가 검토하기 버겁고, 여러 브랜치로 나누면 이번엔 개발자가 브랜치 사이의 리베이스를 계속 손으로 맞춰야 했다. Stacked PR은 이 두 문제를 GitHub 안에서 해결하려는 시도다.
레이어마다 따로 리뷰하고, 합쳐서 한 번에 병합한다
구조는 이렇다. 첫 변경에 대해 브랜치와 PR을 하나 만들고, 그 위에 또 다른 브랜치와 PR을 쌓는다. 각 PR은 자신의 바로 아래 레이어를 대상으로 한다. 리뷰어는 전체 변경이 아니라 자신이 맡은 레이어의 diff만 보면 되고, PR 상단의 스택 맵으로 이 레이어가 전체 작업에서 어디에 해당하는지 확인할 수 있다. 여러 사람이 서로 다른 레이어를 동시에, 서로를 막지 않고 검토할 수 있다는 뜻이다.
병합도 한 번에 끝난다. 스택에서 가장 위에 있는, 준비된 PR을 병합하면 그 아래 병합되지 않은 레이어까지 한꺼번에 main에 반영된다. 반대로 하위 레이어 일부만 먼저 병합하는 것도 가능한데, 이 경우 위에 남은 PR들은 자동으로 리베이스되고 새 대상으로 재타겟팅된다. 기존에 설정해 둔 브랜치 보호 규칙과 필수 체크는 그대로 적용된다. 별도로 설정을 바꿀 필요가 없다.
CLI와 코딩 에이전트에서도 쓸 수 있다
Stacked PR은 github.com 화면뿐 아니라 GitHub CLI, 모바일 앱에서도 다룰 수 있다. `gh extension install github/gh-stack` 명령으로 CLI 확장을 설치하면 1분 안에 첫 스택을 만들 수 있다고 안내한다. GitHub Copilot 같은 코딩 에이전트도 `gh-stack` 스킬을 통해 스택을 다룰 수 있게 했다는 점이 눈에 띈다. AI가 코드를 빠르게 생성하면서 PR 크기가 커지는 문제를 겪는 팀이 늘어난 상황과 맞물려 있다.
실제로 GitHub이 함께 공개한 사용 후기에서도 이 맥락이 드러난다. TED의 CTO는 "AI 덕분에 개발자 생산성은 크게 올랐지만, 그만큼 PR이 커져서 리뷰어가 버거워하는 새로운 병목이 생겼다"며 Stacked PR로 이를 완화했다고 언급했다. Next.js를 만드는 Vercel도 몇 달간 실제로 이 기능을 써 왔다고 밝혔다.
지금 당장 모든 저장소에 적용되지는 않는다
GitHub은 이번 발표에서 Stacked PR이 앞으로 며칠에 걸쳐 모든 저장소에 순차적으로 롤아웃된다고 밝혔다. 머지 큐(merge queue)와의 연동은 앞으로 몇 주에 걸쳐 점진적으로 지원될 예정이다. 즉 지금 자신의 저장소에서 곧바로 보이지 않더라도, 순서대로 배포되는 과정 중일 수 있다. 큰 조직에서 머지 큐를 필수로 쓰고 있다면, 그 지원이 따라오기까지는 완전한 활용에 시차가 있을 수 있다는 뜻이기도 하다.
개인 개발자 입장에서 당장 체감할 변화는 크지 않을 수 있다. 혼자 작은 프로젝트를 다룰 때는 굳이 스택으로 나눌 필요가 적기 때문이다. 하지만 여러 명이 함께 큰 기능을 순차적으로 쌓아 올리는 팀, 특히 AI 코딩 도구로 변경량이 늘어난 팀에서는 리뷰 병목을 줄이는 실질적인 도구가 될 가능성이 있다. 브랜치 보호 규칙이 이미 복잡하게 설정된 저장소라면, 실제로 적용해 보기 전에 스택 병합이 그 규칙과 충돌 없이 동작하는지 확인해 보는 것이 안전하다.
출처: GitHub Changelog, Stacked pull requests are now in public preview