400줄 넘으면 리뷰어가 눈을 감는다: GitHub가 뒤늦게 따라온 스택드 PR
TL;DR GitHub가 네이티브 스택드 PR을 private preview로 출시했다. Microsoft Research와 Google 연구에 따르면 변경 규모가 400줄을 넘으면 리뷰어가 결함을 발견할 확률이 급격히 떨어지며, 500줄 이상 PR의 리뷰 시간은 200줄 이하 대비 4.5배 길다. 이는 Meta와 Google이 15년째 사용해온 워크플로우가 일반 개발팀에게도 현실적인 선택지가 됐다는 의미다.
오픈소스 프로젝트 하나를 진행하다가 PR 하나에 1,200줄을 올린 적이 있다. 리뷰 요청 후 9일이 지나도록 아무 연락이 없었고, 결국 ‘나중에 보자’며 머지했다. 그 PR은 나중에 세 번의 핫픽스를 만들었다. 당시엔 ‘큰 PR이 문제구나’ 정도로만 생각했는데, 나중에 알게 된 사실은 이 고통이 이미 Big Tech에서는 오래전부터 해결된 문제였다는 점이다. GitHub가 이제야 스택드 PR을 공식 지원하기 시작하면서, 그 해결책이 우리 앞에 놓이게 됐다.
리뷰 품질이 400줄에서 무너지는 과학적 근거
Microsoft Research의 2015년 연구와 Google 내부 연구는 명확한 숫자를 보여준다. PR 변경 규모가 400줄을 넘어가면 리뷰어가 의미 있는 피드백을 줄 확률이 급격히 감소한다. SmartBear의 ‘State of Code Review 2022’ 보고서에서는 500줄 이상 PR의 평균 리뷰 시간이 200줄 이하 PR 대비 4.5배 길었다. GitHub Merge Queue를 도입한 조직에서는 merge conflict로 인한 재작업이 평균 37% 줄었다. Meta는 2010년대부터 Phabricator로 stacked diffs를 기본 워크플로우로 사용해왔고, Google 역시 Critique 시스템으로 비슷한 접근을 취했다. 2024년 기준 Graphite 같은 전문 도구는 이미 1,200개 이상 조직에서 사용 중이며, Scale·Figma·Ramp 같은 회사는 엔지니어링 팀의 60~80%가 스택드 방식을 기본으로 삼고 있다.
하나의 PR이 아니라 하나의 레이어로 보는 사고전환
기존 방식은 큰 변경을 하나의 브랜치에 몰아넣거나, 완전히 독립된 PR 여러 개를 동시에 올리는 것이었다. 전자는 리뷰 품질을 떨어뜨리고 후자는 숨겨진 의존성을 만든다. 스택드 PR은 각 PR이 바로 아래 PR의 브랜치를 base로 삼아 의존성을 명시적으로 드러낸다. GitHub의 새로운 기능은 여기서 핵심이다. 단순히 UI에 스택 맵을 보여주는 데 그치지 않고, 브랜치 보호 규칙을 최종 base 브랜치 기준으로 적용하고, CI도 스택 전체를 고려해 돌린다. 한 번의 cascading rebase로 상위 모든 PR을 업데이트할 수도 있다. 다만 stack이 8~10개를 넘어가면 rebase 비용과 인지 부하가 비선형적으로 증가한다는 한계가 분명하다. Trunk-Based Development를 강하게 주장하는 Kent Beck 같은 개발자들은 이를 ’long-lived branch의 변종’으로 보기도 한다.
우리 팀이 스택을 감당할 수 있을까, 현실적인 트레이드오프
Figma와 Ramp 같은 회사가 스택드 방식을 대규모로 도입한 사례를 보면 생산성 향상이 실질적이다. 하지만 오픈소스 프로젝트에서는 외부 기여자가 스택 구조를 이해해야 하는 진입 장벽이 생긴다. GitHub가 CLI와 함께 AI 코딩 에이전트용 ‘Skills’까지 공개한 것은 의미심장하다. Copilot Workspace나 Cursor 같은 도구가 처음부터 스택드 워크플로우를 이해하고 코드를 제안하게 하려는 전략으로 보인다. 다만 ‘한 번의 클릭으로 전체 머지’라는 표현은 branch protection과 required checks를 고려하면 다소 과장된 면이 있다. 실제로는 ‘전체 스택을 merge queue에 한 번에 넣는다’에 가깝다. 결국 팀의 규모, monorepo 여부, senior engineer의 리뷰 병목 현상까지 종합적으로 봐야 하는 선택이다.
15년 동안 Big Tech에서만 가능했던 워크플로우가 이제 일반 개발팀에게도 열리고 있다. 그런데 진짜 질문은 ‘우리 팀이 이 방식을 제대로 소화할 수 있는 문화와 프로세스를 갖추고 있는가’다. 스택을 쌓는 기술보다, 스택을_review_하는 감각을 팀 전체가 갖추는 것이 더 어려운 과제일지도 모른다.
참고문헌
[1] GitHub Stacked PRs 공식 페이지 - https://github.github.com/gh-stack/
[2] SmartBear State of Code Review 2022
[3] Microsoft Research Code Review Study (2015)
[4] Graphite 2024 Customer Stories
[5] Meta Phabricator Differential Documentation