Hacker News가 반긴 GitHub의 stacked PR 실험, 큰 diff를 작게 쪼개는 쪽으로

Hacker News에서 GitHub Stacked PRs가 바로 화제가 된 이유는 설명이 길지 않다. 큰 pull request는 review가 느려지고, conflict는 늘어나고, 결국 feedback 품질도 떨어진다는 걸 다들 체감하고 있기 때문이다. GitHub가 공개한 overview를 보면 Stacked PRs는 큰 변경을 서로 의존하는 작은 PR들의 ordered chain으로 나누고, 각 layer를 독립적으로 review하면서도 마지막에는 함께 landing할 수 있게 만드는 기능이다. GitHub UI 안에서 stack map을 보여 주고, terminal에서는 gh stack CLI로 branch 생성, rebase, push, submit을 처리한다.

문서에서 눈에 띄는 부분은 stack을 GitHub가 end-to-end로 이해하려 한다는 점이다. 각 PR은 바로 아래 branch를 base로 삼지만, branch protection과 CI는 최종 target branch를 기준으로 계산된다. 또 stack의 일부만 merge하거나 merge queue를 통해 한 번에 여러 layer를 넘길 수 있고, 아래쪽 PR이 들어가면 남은 PR base를 자동으로 다시 맞춘다. GitHub는 이 흐름을 monorepo나 긴 refactor branch를 다루는 팀에게 특히 매력적인 도구로 보이게 만들고 있다.

• 각 PR은 하나의 focused layer로 나뉘고 GitHub UI에서 순서를 따라갈 수 있다.
• gh stack CLI는 branch 생성, cascading rebase, push, submit을 담당한다.
• AI coding agent를 위한 integration 안내도 함께 내놨다.

community discussion noted 환호만 있었던 것은 아니다. HN에서는 “이건 monorepo에 특히 잘 맞겠다”는 반응과 함께, 여러 repo에 걸친 dependency chain도 다뤄야 한다는 요구가 바로 나왔다. 또 “애초에 commit을 더 잘 나누면 되는 것 아니냐”는 냉소도 보였는데, 오히려 그 반응이 이 기능의 핵심을 드러낸다. 사람들은 이상적인 commit discipline을 원하지만 실제 product 개발에서는 review 가능한 단위와 release 가능한 단위가 항상 같지 않다.

결국 GitHub가 노리는 지점은 tooling으로 review 비용을 낮추는 것이다. PR을 무조건 더 많이 만들라는 메시지가 아니라, 큰 변경을 작은 review surface로 유지하면서도 merge 순서와 CI 문맥을 잃지 않게 하겠다는 쪽에 가깝다. HN가 여기에 반응한 것도 새 버튼이 멋져서가 아니라, 매일 겪는 코드 리뷰 병목을 GitHub가 드디어 제품 차원에서 건드렸다고 느꼈기 때문이다.