GitHub가 서로 의존하는 작은 PR들을 묶는 Stacked Pull Requests를 정식 제공했습니다. 큰 변경을 나눠 리뷰하고 함께 병합할 수 있도록 하며, 리베이스·승인 유지·서명과 병합 큐 동작의 개선을 설명합니다. GitHub 공식 발표
리뷰가 작아져도 아래 PR 없이는 위 PR이 동작하지 않는 의존성이 남습니다. 각 PR이 어떤 기반에 의존하는지와 스택 전체가 통과해야 하는 시험을 명시해야 해요.
이 글의 목차
큰 변경을 작게 나누어도 기반 관계는 남습니다
PR은 코드 변경을 검토하고 병합하기 위한 단위입니다. 큰 기능을 여러 PR로 나누면 각 변경의 목적을 설명하기 쉬워질 수 있지만, 뒤의 변경이 앞의 코드에 의존한다면 단순한 독립 PR 목록이 되지는 않습니다. 스택은 이 의존 관계를 드러내며 검토하도록 돕습니다. 작은 diff를 만드는 것과 독립적으로 배포 가능한 변경을 만드는 것은 서로 다른 설계입니다.
예를 들어 공통 함수를 추가하는 PR, 이를 사용하는 API 변경, 새 화면을 연결하는 PR로 나눌 수 있습니다. 리뷰어는 각 층의 차이를 작게 볼 수 있지만 API 변경은 공통 함수가 있는 기반에서 시험해야 합니다. PR 설명에는 해당 변경의 목적과 함께 어떤 아래쪽 변경을 전제로 하는지도 적어야 검토자가 맥락을 놓치지 않습니다.
리베이스 뒤에는 승인과 시험의 의미를 확인합니다
기반 브랜치가 바뀌면 위쪽 브랜치도 새 기반에 맞추는 리베이스가 필요할 수 있습니다. 코드가 그대로인 부분의 승인을 유지하는 기능은 반복 검토를 줄일 수 있지만, 새 기반과 합친 동작의 시험까지 대신하는 것은 아닙니다. 승인 기록과 CI가 확인한 커밋 조합을 구분해서 봐야 합니다.
서명된 커밋과 병합 큐의 동작도 조직 규칙에 맞춰 확인합니다. 스택이 하나의 병합 그룹으로 처리되는 경우에는 스택 전체의 준비 상태와 각 PR의 책임 범위를 함께 이해해야 합니다. 기능 발표에서 설명한 동작과 자동 병합처럼 순차 배포되는 기능의 현재 상태도 분리해 확인하면 팀 규칙을 잘못 적용하는 일을 줄일 수 있습니다.
데이터베이스 변경에서는 복구 단위를 먼저 정합니다
스키마 추가, 새 필드를 사용하는 앱, 기존 필드 제거를 스택으로 나눈 상황을 생각해 볼 수 있습니다. 리뷰는 순서대로 진행하더라도 운영에서 모두 동시에 배포할 수 있는지는 별도 문제입니다. 기존 앱과 새 앱이 함께 동작할 기간이 필요할 수 있고, 롤백할 때 이미 바뀐 데이터가 예전 코드와 호환되는지도 확인해야 합니다.
처음 도입할 때는 작은 기능 하나로 PR별 CI와 스택 전체 CI, 부분 병합과 복구를 시험합니다. 리뷰 대기 시간과 재검토 부담이 실제로 줄었는지 팀의 기록으로 비교하면 사용 방식을 조정하기 좋습니다. 공급업체가 제시한 다른 저장소의 개선 수치를 자신의 팀에서 얻을 결과로 약속하지 않고, 의존성을 더 명확히 드러내는 도구로 평가합니다.
스택 기반 리뷰 도입 전
- PR별 책임 범위와 의존 관계를 설명합니다.
- 브랜치 규칙·서명·병합 큐 조건이 스택에 적용되는지 시험합니다.
- 부분 병합과 롤백 시나리오를 작은 변경으로 검증합니다.
기능의 정식 제공이 팀의 처리 속도 향상을 보장하지는 않습니다. 자동 병합 등 세부 기능의 배포 상태와 실제 리뷰 대기 시간을 확인합니다.
발표문 기준일: 2026-10-06 · 확인일: 2026-10-24
.jpg){kind=link}