---
title: "깃허브, 스택드 PR 공개 프리뷰 시작…큰 변경을 작은 리뷰 단위로 쪼갠다"
published: 2026-07-30T16:26:16.000Z
canonical: https://jeff.news/article/5252
---
# 깃허브, 스택드 PR 공개 프리뷰 시작…큰 변경을 작은 리뷰 단위로 쪼갠다

깃허브가 여러 PR을 순서 있는 스택으로 묶어 리뷰하고 한 번에 머지할 수 있는 Stacked PR 공개 프리뷰를 시작했어. 큰 변경을 작은 레이어로 나누면서도 기존 리뷰, 체크, 브랜치 보호, 머지 큐 흐름을 그대로 쓰는 게 핵심이야.

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

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

> [!TIP]
> 큰 기능을 만들 때 “완성된 뒤 PR 하나”로 올리는 팀이라면, 스택 단위로 설계를 쪼개는 것만으로 리뷰 품질이 꽤 달라질 수 있음. 특히 생성형 AI로 변경량이 커진 팀에선 리뷰 가능한 단위가 병목이 됨.

- 시작은 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은 생성 속도보다 검토 가능한 구조를 만드는 쪽에 초점을 맞추기 때문이에요.

## 핵심 포인트

- Stacked PR은 각 PR이 아래 레이어를 대상으로 하는 순서 있는 PR 묶음이야.
- 리뷰어는 각 레이어의 diff만 따로 보고, 준비된 전체 스택이나 일부 레이어만 머지할 수 있어.
- 시작은 gh extension install github/gh-stack 명령으로 설치하는 CLI 확장부터 가능해.

## 인사이트

AI 코딩 도구 때문에 PR 생산량과 변경 크기가 같이 커지는 팀에 특히 잘 맞는 기능이야. 리뷰 병목을 줄이려면 코드 생성 속도보다 리뷰 가능한 단위로 쪼개는 능력이 더 중요해지고 있어.