# GitHub Stacked PR 공개 프리뷰 시작 > Clean Markdown view of GeekNews topic #32001. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=32001](https://news.hada.io/topic?id=32001) - GeekNews Markdown: [https://news.hada.io/topic/32001.md](https://news.hada.io/topic/32001.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-31T07:31:58+09:00 - Updated: 2026-07-31T07:31:58+09:00 - Original source: [github.blog](https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/) - Points: 1 - Comments: 1 ## Topic Body - 큰 변경을 작고 검토 가능한 계층으로 나누는 **Stacked pull requests**가 모든 저장소에 공개 미리보기로 순차 제공됨 - 각 PR은 바로 아래 계층을 대상으로 삼아 팀원들이 좁은 범위의 diff를 **병렬로 독립 검토**할 수 있음 - 최신 PR을 병합하면 아래의 미병합 계층까지 한 번에 반영되며, 일부만 병합할 경우 위쪽 PR은 **자동 리베이스 및 대상 변경**됨 - 기존 PR 검토, 필수 검사, 브랜치 보호, 병합 요건이 그대로 적용되며 GitHub.com·CLI·모바일 앱·GitHub Copilot에서 스택을 다룰 수 있음 - 공개 미리보기는 며칠에 걸쳐 전체 저장소로 확대되고, **Merge queue 지원**은 이후 몇 주 동안 점진적으로 제공됨 --- ### 작은 변경을 쌓는 PR 구조 - 큰 변경을 작고 집중된 여러 PR로 나누고, 각 PR을 순서가 있는 **변경 계층**으로 구성함 - 첫 변경용 브랜치와 PR을 만든 뒤 그 위에 브랜치와 PR을 추가하며, 각 PR은 바로 아래 계층을 대상으로 삼음 - 단일 대형 PR을 검토하거나 여러 브랜치를 수동으로 계속 리베이스해야 하는 불편을 줄임 - Next.js 팀은 큰 기능을 출시하면서도 개별 변경을 작게 유지해 PR 검토가 쉬워졌다고 평가함 ### 스택 생성과 작업 환경 - CLI 확장 기능은 다음 명령으로 설치함 ```bash gh extension install github/gh-stack ``` - **GitHub.com**, GitHub CLI, GitHub 모바일 앱에서 스택을 만들고 관리할 수 있음 - GitHub Copilot 같은 코딩 에이전트에서는 `gh-stack` skill을 이용할 수 있음 ### 계층별 독립 검토 - 스택 안의 PR을 열면 전체 변경이 아닌 해당 계층의 **diff만 검토**할 수 있음 - PR 상단의 스택 맵에서 현재 변경이 전체 작업 중 어디에 위치하는지 확인 가능함 - 팀원들이 서로 다른 계층을 병렬로 검토할 수 있어 이후 작업이 검토 완료까지 막히지 않음 - 기존 브랜치 보호 규칙과 계층별 검토를 함께 적용해 각 단계의 품질을 관리함 - TED는 AI 도입으로 개발 생산성이 높아진 뒤 커진 PR이 검토 병목으로 이어졌으며, 변경을 의존성 순서에 따라 작은 논리 단위로 나눠 검토 속도와 정확도를 높였다고 밝힘 ### 전체 또는 일부 스택 병합 - 준비가 끝난 최신 PR을 병합하면 해당 PR과 그 아래의 모든 미병합 계층을 **한 번에 반영**함 - 아래쪽 계층 하나 이상만 골라 스택 일부를 먼저 병합할 수도 있음 - 위쪽 PR은 열린 상태로 유지됨 - 병합된 변경에 맞춰 자동으로 리베이스되고 대상 브랜치도 변경됨 - 기존 **브랜치 보호**, 필수 검사, 병합 요건은 계속 적용돼 `main`에 들어가는 변경을 통제함 - 전체 스택뿐 아니라 한 계층 또는 일부 계층만 선택적으로 병합 가능함 ### 공개 미리보기와 지원 일정 - Stacked pull requests는 며칠에 걸쳐 **모든 저장소**에 공개 미리보기로 순차 배포됨 - [Merge queue](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue?utm_source=changelog-merge-queue-docs&utm_medium=changelog&utm_campaign=stacked-prs-gtm-public-preview-2026) 지원은 이후 몇 주에 걸쳐 점진적으로 배포됨 - 자세한 사용법은 [stacked pull requests 문서](https://gh.io/stacks?utm_source=changelog-stacked-pr-docs&utm_medium=changelog&utm_campaign=stacked-prs-gtm-public-preview-2026)에서 확인할 수 있으며, [stacks discussion](https://gh.io/stacks-feedback?utm_source=changelog-pr-stacks-feedback&utm_medium=changelog&utm_campaign=stacked-prs-gtm-public-preview-2026)에서 피드백을 받음 ## Comments ### Comment 62641 - Author: neo - Created: 2026-07-31T07:31:59+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=49112232) - 프리뷰를 한동안 써봤는데, 해결되지 않은 문제가 많은 상태에서 대상을 확대한다는 점이 놀라움 예를 들어 스택 전체 병합은 여러 상황에서 완전히 망가짐: [https://github.com/github/gh-stack/discussions/212]() 하나씩 병합할 수는 있지만 **스쿼시 병합**과 필수 리뷰를 함께 사용하면 스택의 PR마다 재승인을 받아야 해서, 스택형 PR의 가장 큰 이점을 잃게 됨 `gh stack`이 수작업을 조금 줄여주지만 여전히 `git rebase`를 정확히 이해해야 함. 로컬 브랜치가 원격과 동기화되지 않았으면 UI가 안내하는 `gh stack rebase`도 실패하며, 도구는 그 원인을 알려주지 않음 반면 스택 UI는 단순하면서도 PR 간 관계를 충분히 보여줘서 마음에 듦. 이미 PR을 쌓아야 할 이유가 있다는 전제에서 작업 흐름만 편하게 만들 뿐, 새로운 기능을 제공하는 도구는 아님 - **스쿼시 병합 문제**를 해결하는 버그 수정들을 순차적으로 배포 중임 내부의 CPRMC(Create Pull Request Merge Commit)는 충돌 여부부터 승인 내용이 실제 생성될 커밋과 일치하는지까지 검사해 PR의 병합 준비 상태를 판단함 여러 PR을 스쿼시 병합하려면 연속된 스쿼시 커밋을 계산한 뒤 규칙과 리뷰에 다시 연결해야 함. 첫 PR은 비교적 쉽지만 두 번째부터는 조상 커밋이 스쿼시되어 브랜치에 원형대로 존재하지 않으므로 복잡해지고, 부모가 여러 개인 상황은 훨씬 더 어려워짐 현재 스택 병합의 **99%가 성공**하지만 이를 훨씬 높이는 것이 팀의 최우선 과제임 - 오늘 스택형 PR이 가리키는 브랜치를 삭제하자 추가 안내 없이 계속 **`merging` 상태에 멈추는 버그**를 겪음 PR 시스템의 부분 장애인가 싶어 GitHub 상태 페이지까지 확인했지만 스택형 PR 기능 자체의 버그였음 - 2021년 이후 업계 전체가 완전히 **준비하고 쏘고 조준하는 방식**으로 바뀐 듯함 - 회사에서도 최근 이 기능과 **병합 대기열** 때문에 문제가 아주 많았음 - GitHub Stacked PRs 팀에서 이제 누구나 스택을 만들 수 있도록 더 넓게 공개함: [https://gh.io/stacks]() 특히 UI와 CLI에 관한 피드백을 원하며 PR 사용 경험을 개선할 업데이트도 많이 준비 중임 Actions와 보호 규칙부터 CLI와 모바일 앱까지 거의 모든 서비스를 아우르는 **GitHub 역사상 가장 큰 출시 중 하나**라서, 설계 결정과 내부 동작에 관한 질문에도 답할 수 있음 - 오늘 처음 시험해본 결과는 마음에 듦 이미 자체 로컬 UI로 스택형 PR의 의존성을 트리로 보고 각 PR의 리뷰·CI 상태를 관리하므로, **GitHub 웹 UI에도 트리와 상태 표시**가 있으면 좋겠음 웹 UI에서는 스택 맨 아래 PR만 병합하는 기능이 지원되지 않는 듯한데, 기존 작업 흐름과 코드를 공유할 수 있으니 GitHub 기본 도구에도 들어가길 바람 - 가까운 시일 내에 **포크를 넘나드는 스택형 PR**을 지원할 예정인지 궁금함 공개 저장소에서 유용하려면 중요한 기능으로 보여서 공개 프리뷰보다 먼저 제공되지 않은 점이 의외임 - Gerrit에서 가장 그리웠던 기능이 바로 이것임 - 작업 분할 단위로 추가 PR을 선택한 이유가 궁금함 커밋 단위로 리뷰·적용·수정할 수 있는 제대로 된 UI 대신, 이 방식의 원조인 메일링 리스트의 **패치 묶음** 작업 흐름을 무시하고 사실상 ‘패치 묶음의 묶음’을 택한 데 별도의 통찰이 있었는지 알고 싶음 - 수년간 GitHub에 적용된 변경 중 손꼽히게 큼 세계 최대 규모의 코드 호스팅 플랫폼 중 하나에 **스택형 작업 흐름**이 도입되면서, 많은 개발자가 존재조차 몰랐던 방식을 접하게 될 수 있음 스택이 더 좋은 소프트웨어를 만든다는 전제가 맞는다면 실제로 많은 개발자에게 도움이 될 가능성도 큼 - 잘 정리된 커밋들을 커밋별로 리뷰하는 방식과 비교해 이런 **스택형 PR의 이점**이 무엇인지 궁금함 더 큰 문제는 대규모 AI 생성 PR에 별도의 리뷰 방식이 필요하다는 것임. 함수 정의 변경, 호출부, 테스트 순으로 보여주는 것처럼 차이의 표시 순서만으로도 읽기 쉬운 정도가 크게 달라짐 문해적 프로그래밍이 코드와 산문을 엮듯 차이와 설명을 결합한 **문해적 차이 또는 문해적 PR**이 필요할 수도 있지만 아직 비슷한 도구를 찾지 못함 - Phabricator 등에서 스택형 차이를 쓰는 사람에게는 이것이 바로 잘 정리된 커밋을 하나씩 리뷰하는 방식임 리뷰 단위인 PR 또는 차이가 하나의 제한된 변경으로 유지되므로 논의가 해당 변경에 집중되고, 기능이 커져도 PR 자체는 비대해지지 않음 또 스택의 각 부분을 서로 다른 대상에게 맡길 수 있음. 외부 팀, 같은 팀 동료, 변경을 사용하는 팀처럼 리뷰어를 나누면 각자가 무엇을 승인하는지 모호하지 않음 GitHub 리뷰가 **변경 ID(change ID)** 를 도입해 리베이스 후에도 댓글을 유지하면 더욱 좋겠음 - 스택의 첫 PR에 커밋을 추가하면 전체 커밋 순서의 중간에 삽입할 수 있음 이후 PR을 리베이스하고 수정해야 한다는 점은 거대한 단일 PR의 후속 커밋들을 고치는 것과 같지만, 변경 전체에 임시 수정 커밋을 무작위로 붙이는 대신 **기반 변경의 커밋을 한데 유지하기 쉬워짐** 기반 변경에 관한 논의도 함께 모이며, 전체 스택을 미리 제시하면 리뷰어가 최종 방향을 파악하면서 작업은 비동기로 계속 진행할 수 있음 - 핵심은 ‘잘 정리된’ 커밋을 실제로 만드는 사람이 많지 않다는 데 있음 커밋을 게임 저장 지점처럼 사용하고 `fix bug`, `do work` 같은 메시지만 남긴 뒤 `git rebase -i`로 정리하지 않으므로, 필수 스쿼시 병합을 켜지 않으면 로그가 쓰레기 커밋으로 가득 참 이런 개발자에게는 **PR이 곧 커밋**이며, 스택형 PR을 통해 하나의 변경을 구성하는 여러 커밋과 비슷한 구조를 비로소 사용할 수 있게 됨 - 스택을 사용하면 리뷰 가능한 크기의 차이를 계속 만들면서 긴 변경 작업을 이어갈 수 있음 병합된 차이는 현재 HEAD 위로 리베이스할 수 있고, 이를 지원하는 팀에서는 보통 브랜치를 직접 관리하지 않고 **트렁크에서 작업**하며 변경이 들어올 때마다 리베이스함 - PR에서는 커밋을 하나씩 병합할 수 없지만 스택에서는 가능함 기능의 앞 **4개 부분이 준비**됐고 5번째에 문제가 있다면 전체를 막을 필요가 없음 - 의존성 있는 PR이 선형 이력이 아닌 **트리 구조**를 이루는 경우는 언제 지원되는지 궁금함 Google에서 스택형 변경을 사용했을 때 이런 경우가 흔했고, 병렬 코딩 에이전트가 늘어난 지금은 더욱 자주 생길 듯함 - 사람이 관리하기도 어려운 구조인데, 소프트웨어와 그에 따른 AI가 이런 방식을 장려하도록 만드는 것이 정말 바람직한지 의문임 - 메뉴 전환 버튼이 팬케이크 더미 이모지(U+1F95E)인 이유가 스택 기능 때문인지 궁금함 장난스러운 표현 자체는 괜찮지만 무엇을 보고 있는지 **강한 의심을 유발하는 UI**였음 - 내부에서 팬케이크 이모지를 사용해 재미있는 이스터 에그로 넣었음 몇 시간만 표시한 뒤 일반 아이콘으로 되돌릴 예정임 - 맞음: [https://github.com/orgs/community/discussions/203497]() - 처음 소식을 들었을 때부터 `gh stack` CLI를 사용했고 도구 자체는 매우 좋았지만, 프리뷰 승인을 받아 접한 웹 UI는 기대에 크게 못 미쳤음 승인 전에도 CLI는 작업을 여러 원자적 PR로 나누는 자동화를 쉽게 해줬지만, 푸시하면 서로 연결되지 않은 독립 PR로 표시됐음 승인 후에도 거의 동일하며, 상단의 작은 탐색 드롭다운에 같은 스택의 다른 PR이 표시되는 것이 전부라서 **의미 있는 UI 변화가 없음** 드롭다운에서 CLI 기능 일부를 수행할 수 있지만 웹에서 파일을 편집하는 기능처럼 부수적인 편의에 가깝고, 실제 개발 작업 흐름에서는 CLI나 IDE 플러그인이 중심이 될 것임 이 정도의 선택적 UI 때문에 왜 오랫동안 일반 공개를 미뤘는지 의문이며, 스택 CLI는 발표 당시부터 이미 일반 공개 상태였음 - 처음에는 최소한의 기능으로 시작해야 했지만 훨씬 광범위한 **PR UI 개편**을 진행 중임 스택을 항상 인식하고 클릭을 많이 하지 않아도 각 계층을 오갈 수 있도록 스택을 지속적으로 보여주는 화면도 포함할 예정임 - jujutsu는 브랜치를 갱신하면 그 브랜치에서 갈라진 다른 브랜치도 자동으로 리베이스해주는 점이 좋음 리뷰하기 쉽게 작업을 나눌 때 자주 `jj`로 전환하며, Git으로 만든 복제본과 **같은 작업 디렉터리에서 함께 사용**해도 잘 동작함 - `jj absorb`도 훌륭함 변경 내용을 가장 가까운 관련 변경으로 옮겨주므로 여러 PR에 영향을 주는 수정도 쉽게 처리할 수 있음 - Graphite를 사용한 뒤에는 스택 없는 GitHub로 돌아가기 매우 어려웠음 GitHub의 지원으로 **스택형 PR 작업 흐름**이 보편화되고 거대한 PR을 대신할 쉬운 선택지가 생기길 기대함 - `git-spice`를 추천함 사용하기 쉽고 강력한 오픈소스이며, Graphite는 기능에 비해 지나치게 복잡하게 느껴졌음 - PR 쌓기는 두 상황에서 유용하다고 이해했음 첫째, 서로 연관된 여러 저장소에 걸쳐 있어 하나의 PR로 합칠 수 없을 때이고, 둘째, 첫 PR을 리뷰하는 동안 같은 브랜치 위에 후속 PR을 쌓아 작업을 파이프라인화할 때임 하지만 이 기능은 둘 다 충족하지 않고, 단일 PR에 커밋을 쌓는 또 다른 형태처럼 보임 일반적으로는 원자적이고 의미 있는 커밋을 만들고 리베이스로 리뷰어가 이해하기 좋은 흐름을 구성하며, 리뷰어도 원하면 커밋별로 살펴볼 수 있음 이 방식에서 놓치고 있는 **고유한 이점**이 무엇인지 궁금함