Stacked PR 써봤더니 코드 리뷰 속도가 달라졌다

Stacked PR(스택 PR)이라는 걸 처음 들었을 때 "그냥 PR 여러 개 올리는 거 아냐?"라고 생각했다. 근데 팀에서 도입해보고 나서 코드 리뷰 속도가 달라지는 걸 느꼈다.

개념 자체는 간단하다. 큰 기능 하나를 작은 PR 여러 개로 쪼개서, 서로 의존성을 가진 채로 순서대로 머지한다. "스택"이라는 이름이 붙은 이유다.

왜 큰 PR이 문제인가

300줄 넘어가는 PR 리뷰해본 사람은 안다. 리뷰어가 제대로 보기가 힘들다. 처음엔 열심히 보다가 중간부터 "LGTM" 찍고 싶어진다. 그리고 솔직히 그걸 탓하기도 어렵다.

큰 PR은 리뷰 시간을 늘리고, 머지 대기 시간도 늘어나고, 결국 다음 작업이 막힌다. 개발자가 리뷰 기다리면서 멍하니 다른 일 하는 시간이 쌓인다.

Stacked PR의 실제 흐름

예를 들어 "결제 기능 추가"라는 큰 작업을 한다고 하면:

• PR 1: 결제 데이터 모델 추가
• PR 2: 결제 API 엔드포인트 (PR 1 기반)
• PR 3: 결제 UI 컴포넌트 (PR 2 기반)
• PR 4: 통합 테스트 (PR 3 기반)

각 PR이 100줄 내외면 리뷰어가 집중해서 볼 수 있다. 그리고 PR 1이 머지되면 나머지가 연쇄적으로 올라가는 구조다.

문제는 Git CLI가 이 방식을 위해 설계되지 않았다는 거다. 중간 PR에 변경이 생기면 뒤에 쌓인 PR들을 전부 rebase해야 한다. 수동으로 하면 고통스럽다.

도구 없이는 힘들다

Graphite 같은 전용 도구가 이 rebase를 자동화해준다. 명령어 하나로 스택 전체를 동기화한다. 스택 관리 없이 손으로 하다가 중간에 포기하는 팀을 여럿 봤다. 도구 없이 도입하면 오히려 역효과 날 수 있다.

GitHub 자체에도 스택 PR 지원이 일부 들어오고 있는데, Graphite나 spr 같은 전용 CLI만큼 편하진 않다.

Asana 사례에서 도입 후 중간 PR 크기가 11% 줄고, 주간 7시간 절약됐다는 데이터가 있다. Shopify는 개발자당 PR 머지가 33% 늘었다고 한다. 숫자가 크게 느껴지는 건, 그만큼 기존 대형 PR 워크플로우가 비효율적이었다는 뜻이기도 하다.

팀 전체가 바꿔야 한다는 게 제일 어렵다

개인이 혼자 스택 PR 써봤자 의미가 없다. 리뷰어도 스택 구조를 이해하고 순서대로 봐야 하고, 머지 전략도 팀 전체가 맞춰야 한다. 도입 비용이 있다.

그래도 한 번 팀에 자리잡으면 PR 대기 시간이 확 줄어드는 걸 느낄 수 있다. 리뷰어도 덜 힘들고, 올리는 사람도 피드백을 빨리 받는다. 어차피 코드 리뷰가 병목인 팀이라면 한 번 시도해볼 만하다.

---

📎 참고 자료

• How to use stacked PRs to unblock your entire team — Graphite Blog
• Managing Stacked PRs — Axolo Blog
• The Stacking Workflow — stacking.dev