이 기능이 진짜 무서운 이유는 새 Git 명령어가 하나 더 생겼기 때문이 아니다. 2026년 4월 14일 Hacker News 상단에 GitHub Stacked PRs가 올라오자마자 사람들이 반응한 건, 리뷰 문화 자체를 GitHub가 네이티브 기능으로 다시 설계하려 든다는 신호가 보였기 때문이다. PR 하나에 변경을 몰아넣고 “한 번에 봐주세요”라고 말하던 습관이 이제는 플랫폼 차원에서 구식 취급을 받기 시작했다.
GitHub는 이미 Copilot과 Actions 쪽에서 자동화 영역을 넓혀왔는데, 이번엔 훨씬 더 실무적이다. 큰 기능을 작은 리뷰 단위로 쪼개고, 그 순서를 GitHub가 이해하고, 중간 PR이 머지된 뒤 나머지를 다시 맞춰주는 흐름까지 제품에 넣겠다고 선언했다. 질문은 하나다. 이게 정말 팀의 PR 지옥을 끝낼 카드가 될까, 아니면 또 하나의 멋진 데모로 남을까.
왜 오늘 갑자기 GitHub Stacked PRs가 터졌나
HN와 GeekNews가 같은 날 같은 신호를 줬다
2026년 4월 14일 기준 Hacker News에서 GitHub Stacked PRs는 456점과 260개 댓글까지 올라왔다. 같은 날 GeekNews 메인에도 같은 링크가 걸렸다. 점수만 보면 WordPress 공급망 백도어 이슈가 더 셌다. 그런데 내 기준에서 GitHub Stacked PRs가 더 오래 남을 주제인 이유는 다르다. 이건 보안 사고처럼 하루 만에 지나가는 화제보다, 개발팀의 일하는 방식에 직접 들어오는 제품 변화에 가깝다.
| 신호 | 지금 관찰된 근거 | 왜 중요한가 |
|---|---|---|
| 실시간성 | HN 456점 260댓글, GeekNews 동시 노출 | 단순 릴리스 노트가 아니라 즉시 토론 주제가 됐다 |
| 제품 무게 | GitHub 공식 사이트에서 별도 문서와 FAQ 제공 | 실험용 블로그 글이 아니라 제품화 의지가 보인다 |
| 체감도 | 큰 PR 분할, 연쇄 리베이스, 머지 큐 연동 | 개발자의 매일 반복 작업을 직접 건드린다 |
그래서 이 표가 중요한 이유는 조회 수 자랑이 아니다. 지금 주목해야 할 건 GitHub가 “리뷰 가능한 작은 단위”를 모범 사례로 말하는 수준을 넘어서, 그 구조를 UI와 CLI에 같이 심고 있다는 점이다.
기존 서드파티 툴이 아니라 GitHub 네이티브라는 차이
스택형 PR 자체는 완전히 새 개념이 아니다. Meta의 ghstack이나 Graphite 같은 도구를 써본 팀이라면 익숙한 이야기다. 그런데 이번 발표는 외부 도구가 아니라 GitHub 본체가 스택 관계를 이해한다는 데 의미가 있다. 공식 개요 문서를 보면 각 PR이 바로 아래 PR 브랜치를 대상으로 연결되고, GitHub UI에서 스택 맵을 보여주고, 최종 대상 브랜치 기준으로 보호 규칙과 CI를 평가한다고 설명한다.
이 대목은 예전에 다뤘던 GitHub Agentic Workflows와도 연결된다. GitHub는 이제 코드 호스팅을 넘어서 개발 절차 자체를 흡수하고 있다. 내 생각엔 Copilot보다 더 큰 변화가 이런 곳에서 나온다. 사람 손이 많이 타던 협업 구조를 플랫폼이 제품 기능으로 가져오기 시작했기 때문이다.
GitHub가 진짜로 고치려는 병목
문제는 PR 개수가 아니라 리뷰 단위였다
현장에서 리뷰가 밀리는 팀을 보면 PR 숫자가 많아서라기보다, 한 PR 안에 서로 다른 층위의 변경이 섞여 있는 경우가 많다. 데이터 모델 수정, API 응답 구조 변경, 프런트 UI 보정이 한 덩어리로 올라오면 리뷰어는 어디서부터 봐야 할지 잃어버린다. 그 결과는 익숙하다. 첫 리뷰가 늦어지고, 코멘트가 피상적이 되고, 결국 “일단 머지하고 나중에 보자”가 된다.
GitHub Stacked PRs는 이 병목을 꽤 정직하게 겨냥한다. 큰 변경을 쪼개되, 브랜치를 따로 놀게 두지 않고 순서 있는 체인으로 관리한다. 공식 FAQ에서도 스택형 PR은 결국 일반 PR이지만 base branch가 main이 아니라 아래 PR을 가리키는 구조라고 설명한다. 핵심은 리뷰 단위를 작게 만들면서도 전체 맥락을 잃지 않게 하는 데 있다.
연쇄 리베이스와 전체 머지가 실무 감각에 맞는다
문서에서 제일 눈에 띈 건 merge queue와 cascading rebase 부분이었다. 가장 아래 PR이 머지되면 나머지 PR의 base가 자동으로 다시 맞춰진다. 지금까지는 이 단계가 제일 귀찮았다. 승인 하나를 받으면 나머지 PR을 수동 리베이스하고, force push하고, 깨진 체크를 다시 기다려야 했다. 그 노동이 줄어들면 리뷰 문화가 좋아지는 이유도 단순하다. 팀이 작은 PR을 올릴 인센티브가 생기기 때문이다.
gh extension install github/gh-stack
gh stack alias
gs init auth-layer
gs add api-routes
gs add frontend
gs submit
이 명령 묶음은 GitHub가 의도하는 기본 흐름을 가장 짧게 보여준다. 큰 기능을 한 번에 보내지 말고, 레이어별로 잘라서 제출하라는 뜻이다.
좋아질 팀과 더 피곤해질 팀
모노레포와 플랫폼 팀은 바로 체감할 가능성이 크다
백엔드 계약 변경이 프런트와 인프라까지 연결되는 팀이라면 스택형 PR의 장점이 금방 드러날 수 있다. 리뷰어는 각 층을 따로 보고, 작성자는 전체 체인을 유지하고, 매니저는 어느 단계가 막혔는지 스택 맵으로 본다. 특히 한 기능이 여러 저장소가 아니라 한 저장소의 여러 계층을 동시에 건드리는 모노레포 환경이라면 효과가 더 크다.
반대로 작은 팀은 무조건 좋다고 보긴 어렵다. 리뷰어 한두 명이 모든 맥락을 이미 알고 있고, 하루 안에 큰 PR도 충분히 소화하는 팀이라면 스택 관리 비용이 더 크게 느껴질 수 있다. 내 생각엔 이 기능의 진짜 타깃은 코드가 복잡한 팀이라기보다, 리뷰 대기열과 머지 순서 때문에 계속 충돌이 나는 팀이다.
아직은 프리뷰라는 점도 잊으면 안 된다
공식 사이트 기준으로 이 기능은 아직 private preview다. 기다림 없이 전 팀에 바로 켤 수 있는 상태가 아니다. 그리고 새 협업 기능이 늘 그렇듯이, 도구가 병목을 없애기보다 병목을 더 선명하게 드러낼 가능성도 있다. 리뷰 SLA가 없는 팀, 작은 PR을 강제할 규칙이 없는 팀, base branch 전략이 뒤섞인 팀은 Stacked PRs를 켜도 금방 어지러워질 수 있다.
그럼에도 이 프리뷰가 중요한 이유는 분명하다. GitHub가 앞으로 좋은 PR을 “짧은 설명”이 아니라 “작고 순서 있는 구조”로 정의하려는 방향이 보이기 때문이다. 이건 기능 하나가 아니라 기준의 이동에 가깝다.
리뷰 속도보다 더 바뀌는 것
이제 팀은 변경량이 아니라 변경층을 설계해야 한다
나는 이번 기능을 보면서 앞으로 리뷰 잘하는 팀의 기준이 달라질 거라고 느꼈다. 예전에는 PR을 빨리 올리고 빨리 머지하는 팀이 강했다. 이제는 기능을 어떤 층으로 쪼개고, 어느 PR을 먼저 승격시키고, 나머지 체인을 어떻게 유지할지 설계하는 팀이 더 강해질 가능성이 크다. 결국 생산성 차이는 코드를 얼마나 빨리 쓰느냐보다, 변경을 얼마나 리뷰 가능한 단위로 설계하느냐에서 벌어진다.
GitHub Stacked PRs가 모든 팀의 PR 지옥을 끝내주지는 않을 것이다. 하지만 한 가지는 이미 증명했다. 이제 문제는 PR이 너무 많다는 게 아니라, 여전히 너무 크게 올린다는 점이다.