깃허브, 스택드 PR 공개 프리뷰 시작…큰 변경을 작은 리뷰 단위로 쪼갠다

• 깃허브가 Stacked Pull Requests를 공개 프리뷰로 열었음

  • 큰 변경을 하나의 거대한 PR로 올리는 대신, 순서 있는 작은 PR 여러 개로 나누는 기능임
  • 각 PR은 변경의 한 레이어를 나타내고, 아래 레이어를 대상으로 쌓이는 구조임
  • 리뷰와 체크는 각 PR 단위로 독립적으로 볼 수 있음

• 이 기능이 노리는 문제는 명확함. 큰 PR은 리뷰가 느리고 대충 보기 쉬움

  • 팀은 짧고 좁은 범위의 PR을 병렬로 리뷰할 수 있음
  • 기존 브랜치 보호와 필수 체크는 그대로 적용됨
  • 전체 스택을 한 번에 머지하거나, 일부 레이어만 먼저 머지하는 선택도 가능함

• 시작은 GitHub CLI 확장으로 함

  • 설치 명령은 gh extension install github/gh-stack
  • 터미널이나 github.com에서 스택을 만들 수 있음
  • GitHub CLI, GitHub 모바일 앱, GitHub Copilot 같은 코딩 에이전트와 함께 쓰는 흐름도 언급됨

• 동작 방식은 “첫 브랜치와 PR을 만들고, 그 위에 브랜치와 PR을 계속 쌓는” 형태임

  • 각 PR은 바로 아래 레이어를 대상으로 함
  • 특정 PR을 열면 그 레이어의 diff만 리뷰할 수 있음
  • PR 상단의 stack map으로 지금 보는 변경이 전체 작업에서 어디에 있는지 확인할 수 있음

• 머지도 스택에 맞춰 설계됨

  • 준비된 최신 PR을 머지하면 그 아래 아직 머지되지 않은 레이어까지 한 번에 들어감
  • 일부만 랜딩하고 싶으면 아래쪽 레이어 한 개 이상만 머지할 수 있음
  • 위쪽 PR들은 열린 상태로 남고, 자동으로 rebase와 target 변경이 처리됨

• 실제 사용 사례로는 Next.js, TED, WHOOP 쪽 코멘트가 들어감

  • Next.js 쪽은 큰 기능을 작은 변경으로 나눠 리뷰하기 쉬워졌다고 말함
  • TED 쪽은 AI로 개발 생산성이 올라가자 PR이 커지는 병목이 생겼고, Stacked PR이 리뷰를 더 작고 정확한 단위로 만든다고 설명함
  • jQuery 만든 John Resig는 스택 PR 5개를 머지 큐로 한 번에 랜딩하는 흐름을 언급함

• 배포는 순차적으로 진행됨

  • 모든 저장소에 공개 프리뷰가 며칠에 걸쳐 롤아웃됨
  • Stacked PR의 merge queue 지원은 몇 주에 걸쳐 점진적으로 풀릴 예정임
  • 기존 리뷰, 체크, 머지 요구사항을 그대로 쓴다는 점이 도입 장벽을 낮추는 포인트임

---

기술 맥락

• Stacked PR의 선택은 코드 변경을 “기능 단위”가 아니라 “리뷰 가능한 의존 레이어”로 나누는 데 있어요. 큰 기능 하나라도 데이터 모델, 내부 API, UI 연결, 테스트 보강처럼 순서를 나눌 수 있으면 리뷰어가 훨씬 작은 맥락에서 판단할 수 있거든요.

• 기존에는 이런 흐름을 쓰려면 Graphite 같은 별도 도구나 수동 rebase 습관이 필요했어요. 깃허브가 이걸 기본 PR 경험 안에 넣으면, 팀 입장에선 새 리뷰 시스템을 도입하지 않고도 같은 브랜치 보호와 체크를 유지할 수 있어요.

• merge queue와의 결합이 중요한 이유는 스택 여러 개를 한 번에 넣을 때 main 안정성이 깨지기 쉽기 때문이에요. 준비된 레이어만 순서대로 검증하고 머지해야, 작게 쪼갠 PR이 오히려 통합 리스크를 키우지 않아요.

• AI 코딩 도구가 퍼진 팀에선 이 기능의 가치가 더 커져요. 코드 작성 속도가 빨라질수록 리뷰어가 감당해야 할 diff가 커지는데, Stacked PR은 생성 속도보다 검토 가능한 구조를 만드는 쪽에 초점을 맞추기 때문이에요.