깃허브가 '스택 풀 리퀘스트(Stacked Pull Requests)'를 공개 프리뷰로 내놓았다. 하나의 거대한 변경을 통째로 올리는 대신, 서로 의존 관계로 쌓인 여러 개의 작은 풀 리퀘스트(PR)로 나눠 각각을 독립적으로 리뷰하고, 마지막에 한 번의 클릭으로 전체를 병합하는 방식이다. 각 PR은 바로 아래 계층을 기준(base)으로 삼아 순서대로 쌓이며, 하나의 변경을 여러 개의 '집중된 층'으로 구성한다는 것이 핵심 개념이다.
실무자라면 이 문제의 배경이 익숙할 것이다. 기능이 커질수록 PR도 커지고, 수백 줄이 넘어가는 diff는 리뷰어가 손대기를 꺼리게 된다. 그렇다고 작업을 여러 브랜치로 쪼개면 상위 브랜치를 계속 수동으로 리베이스해야 하는 부담이 생긴다. 스택 PR은 이 두 선택지 사이의 마찰을 줄이려는 시도다. 깃허브에 내장된 기능이라는 점도 중요하다. 기존의 리뷰, 체크(CI), 병합 요건, 브랜치 보호 규칙이 별도 설정 없이 그대로 적용되며, 무엇이 main에 도달할지는 여전히 기존 보호 규칙과 필수 체크가 통제한다.
어떻게 동작하나
사용 흐름은 첫 변경에 대한 브랜치와 PR을 만든 뒤, 그 위에 브랜치와 PR을 차례로 쌓아 올리는 형태다. 스택 안의 특정 PR을 열면 해당 계층의 diff만 따로 볼 수 있고, PR 상단의 '스택 맵'을 통해 지금 리뷰 중인 변경이 전체 작업에서 어디에 위치하는지 파악할 수 있다. 덕분에 팀원들이 서로 다른 계층을 병렬로 리뷰하면서도 후속 작업이 막히지 않는다.
병합 방식도 유연하다. 준비가 끝난 최상위 PR을 병합하면 그 아래의 병합되지 않은 모든 계층이 한 번의 작업으로 함께 반영된다. 반대로 스택의 일부만 먼저 내리고 싶다면 하위 계층 한두 개만 병합할 수 있는데, 이때 위쪽 PR들은 열린 상태로 남아 자동으로 리베이스되고 기준 브랜치가 재조정된다. 수동 리베이스의 번거로움을 줄여주는 부분이다.
작업 환경은 github.com 웹, GitHub CLI, 모바일 앱, 그리고 GitHub Copilot 같은 코딩 에이전트(gh-stack 스킬)까지 폭넓게 지원한다. CLI 확장을 설치하면 1분 안에 첫 스택을 만들 수 있다는 것이 깃허브의 설명이다.
사전 사용자들의 반응과 맥락
프리뷰 이전부터 여러 조직이 이 기능을 써왔다. 버셀의 팀 뉴트켄스 Next.js 리드는 지난 몇 달간 Next.js 개발에 스택 PR을 적용해 큰 기능을 출시하면서도 개별 변경을 더 작게 도입할 수 있었고 리뷰가 쉬워졌다고 밝혔다. jQuery 창시자 존 레식은 5개의 스택 PR을 병합 큐로 한꺼번에 올린 경험을 언급하며 CLI 도구와 에이전트 스킬의 도움을 높이 평가했다.
주목할 만한 것은 TED와 WHOOP 사례가 짚은 배경이다. TED의 앤디 메리먼 CTO는 AI가 개발 생산성을 크게 끌어올린 대신 PR이 리뷰어가 감당하기 힘들 만큼 커지는 새로운 병목이 생겼다고 지적했다. 스택 PR이 변경을 의존 순서대로 잘게 나눠 더 빠를 뿐 아니라 더 정확한 리뷰를 가능하게 한다는 것이다. AI 코딩 도구 확산으로 코드 생산량이 늘어난 조직일수록 리뷰 병목이 커지고, 이를 완화하려는 흐름 위에 이 기능이 놓여 있음을 보여준다.
다만 현재 시점의 한계도 분명히 볼 필요가 있다. 스택 PR은 앞으로 며칠에 걸쳐 모든 저장소에 순차 배포되는 공개 프리뷰 단계이며, 존 레식과 여러 사용자가 강조한 병합 큐(merge queue) 연동은 몇 주에 걸쳐 점진적으로 풀리는 상태다. 즉 조직에 따라 기능이 도착하는 시점이 다르고, 팀 워크플로에 완전히 녹여 쓰려면 병합 큐 지원까지 기다려야 할 수 있다. 다른 스택 PR 도구(예: Graphite 등 서드파티)를 이미 쓰고 있는 팀이라면, 기존 리뷰·체크와의 네이티브 통합이라는 이점과 프리뷰 단계의 불안정성을 함께 저울질하며 도입 시점을 판단하는 편이 현실적이다.