GitHub이 스택형 PR을 들이다: Meta·Google의 워크플로는 마침내 대중화되는가

스택형 diff 워크플로가 마침내 GitHub에서 주류가 되는 것인가, 아니면 git의 브랜치 모델이 본래 표현하지 못하는 것을 도구 계층으로 억지로 떠받치는 임시방편의 확산에 불과한가.

도입 — 7월 30일, GitHub이 늦게 도착한 자리

2026년 7월 30일, GitHub은 스택형 풀 리퀘스트 (stacked pull requests) 를 퍼블릭 프리뷰로 공개했다. 하나의 큰 변경을 순서 있는 여러 겹의 작은 PR로 쪼개고, 각 PR이 바로 아래 PR을 기반 브랜치로 삼아 쌓이도록 하는 기능이다. 리뷰어는 거대한 diff 하나가 아니라 focused된 작은 층 하나씩을 검토한다. GitHub CLI 확장으로 gh extension install github/gh-stack 을 깔면 쓸 수 있고, github.com 웹, GitHub CLI, 모바일 앱, 그리고 코딩 에이전트에서도 동작한다. 향후 며칠에 걸쳐 모든 리포지토리로 순차 배포되며, 머지 큐 (merge queue) 지원은 몇 주에 걸쳐 뒤따른다고 GitHub은 밝혔다.

이 발표가 Hacker News 첫 페이지에 올랐고, 게시물은 760점을 모았다. 흥미로운 것은 반응의 온도다. 새 기능에 대한 순수한 환영보다, “이제야?”에 가까운 목소리가 앞섰다. 이유는 분명하다. 스택형 diff는 새로운 아이디어가 전혀 아니기 때문이다. Meta는 Phabricator와 Sapling으로, Google은 Critique와 Gerrit으로 십수 년간 이 방식을 사내 표준으로 굴려 왔고, Graphite 같은 스타트업은 GitHub 위에서 이 워크플로 하나만으로 사업을 세웠다. 그러니 이번 발표의 본질은 “발명”이 아니라 “수용”이다. 이 글은 먼저 스택형 PR이 실제로 무엇을 하는지 확정하고, 왜 이 워크플로가 존재하며 왜 하필 git에서 그것이 어려웠는지를 해부한 뒤, 팀과 엔지니어에게 스택이 언제 이득이고 언제 과잉인지, 그리고 이 수용이 도구 생태계에 무엇을 남기는지 정리한다.

현상 — 스택 맵과 캐스케이드 머지: 스택형 PR이 실제로 하는 일

먼저 기능의 실체부터 확정한다. 스택형 PR의 핵심 UI는 스택 맵 (stack map) 이다. 각 PR 화면에 이 변경이 전체 스택의 어느 층에 놓이는지를 그림으로 보여 준다. 아래에서 위로 A → B → C 순서로 쌓인 세 개의 PR이 있다면, B의 리뷰어는 B가 A 위에 얹혀 있고 C가 B에 의존한다는 관계를 한눈에 본다. 이 지도가 있으므로 리뷰어는 각 층을 독립적으로 검토하고, 아래 층의 리뷰가 끝나기를 기다리지 않고 병렬로 승인을 진행할 수 있다.

두 번째 장치는 머지 동작이다. GitHub의 표현을 그대로 옮기면, 준비된 최신 PR을 머지하면 “그것과 그 아래의 아직 머지되지 않은 모든 층을 한 번의 단일 작업으로 랜딩” 시킬 수 있다. 스택의 꼭대기를 누르면 밑에 깔린 층까지 순서대로 함께 들어간다는 뜻이다. 반대로 아래층을 먼저 개별 머지하면, 그 위에 남은 PR들이 “자동으로 리베이스되고 재타겟팅 (retarget)” 된다. 즉 B가 main으로 먼저 들어가면, 원래 B를 기반으로 하던 C는 자동으로 기반 브랜치가 main으로 바뀌고 그 위에서 리베이스된다. 손으로 chain을 다시 엮던 작업이 사라지는 지점이 바로 여기다.

세 번째로, 기존 규칙은 그대로 살아 있다. 브랜치 보호 규칙 (branch protection) 과 필수 체크는 스택 위에서도 동일하게 적용되어, 무엇이 main에 도달할 수 있는지를 계속 통제한다. 스택형 PR이 리뷰 게이트를 우회하는 뒷문이 아니라는 점은 도입 저항을 줄이는 설계다. 접근 경로도 넓다. 웹, CLI, 모바일에 더해 코딩 에이전트를 위한 gh-stack 스킬이 함께 제공되어, 사람이 아니라 에이전트가 큰 작업을 스스로 여러 층으로 쪼개 올리는 시나리오까지 겨냥한다. 뒤에서 보겠지만, 이 “에이전트를 위한 스택”이라는 각도는 이번 발표의 타이밍을 읽는 하나의 열쇠다.

GitHub은 발표에 Vercel(Next.js 팀), TED, WHOOP, 그리고 jQuery 창시자의 추천사를 붙였다. 이들은 스택형 PR 덕분에 큰 기능을 작은 변경으로 나눠 보내기 쉬워졌다고 말한다. 다만 이 인용들은 제품 발표에 실린 마케팅 문구이므로 중립적 증거가 아니라 홍보로 취급하는 것이 옳다. 실제 반응의 결은 커뮤니티 쪽이 더 정직하게 드러낸다. HN 스레드의 한 참여자는 스쿼시 머지 시 PR마다 재승인을 요구하거나 스택 전체를 원자적으로 머지하지 못하는 등 초기 구현에 버그가 적지 않다는 취지로 지적한다. 반면 Phabricator 시절 이 워크플로에 익숙했던 다른 참여자는 GitHub에서 오래 “그리워하던” 방식이 돌아왔다는 취지로 환영한다. 요컨대 v1의 완성도에 대한 불만과, 방향 자체에 대한 반가움이 공존한다.

심층 — 왜 스택인가, 그리고 왜 git에서는 그것이 어려운가

스택형 diff가 왜 존재하는지부터 짚어야 이번 수용의 의미가 잡힌다. 출발점은 리뷰의 경제학이다. 리뷰 품질은 diff의 크기에 반비례한다. 400줄짜리 PR과 4,000줄짜리 PR을 같은 집중도로 읽는 리뷰어는 없다. 큰 변경 하나를 통째로 올리면 리뷰어는 압도되고, 진짜 위험한 20줄이 지루한 2,000줄 속에 묻힌다. 스택형 diff의 첫 번째 논거는 여기다. 하나의 큰 목표를 논리적으로 독립된 작은 층으로 쪼개면, 각 층은 작고, 각 층의 리뷰는 깊어진다.

두 번째 논거는 병렬성이다. 큰 기능을 단일 브랜치에 쌓으면, 그 기능이 머지될 때까지 그 위의 후속 작업은 손을 대기 어렵다. 스택은 이 사슬을 끊는다. A를 올려 리뷰를 받는 동안 그 위에 B를, 다시 C를 쌓아 작업을 이어 갈 수 있고, A가 머지되면 B·C가 자동으로 따라 내려온다. 세 번째 논거는 원자적 되돌리기 (atomic revert) 다. 각 층이 하나의 온전한 변경이면, 문제가 생겼을 때 그 층만 정확히 골라 되돌릴 수 있다. 스무 가지 일이 뒤섞인 거대 커밋은 이 정밀 되돌리기를 불가능하게 만든다. 정리하면 스택이 제거하려는 고통은 명확하다. 서로 의존하는 브랜치들의 사슬을, 아래가 바뀔 때마다 손으로 리베이스하며 유지하는 노동이다.

이 방식의 선례는 길다. Meta의 Phabricator는 arc diff 와 Differential로 커밋 단위 리뷰와 스택을 일찍부터 다뤘고, Meta는 이후 이를 계승한 버전 관리 시스템 Sapling을 오픈소스로 공개했다. Google은 Critique와 Gerrit에서 “커밋 하나가 곧 리뷰 단위”라는 change-per-commit 모델을 사내 표준으로 삼았다. ghstack 은 Meta 계열의 오픈소스 도구로, 각 커밋을 개별 PR로 쪼개 GitHub에 올린다. git-branchless 와 Sapling은 스택 편집을 위한 별도 워크플로를 제공한다. 그리고 Graphite는 이 모든 흐름을 상품화해, GitHub 위에서 스택형 PR 경험을 통째로 제공하는 벤처 투자를 받은 스타트업으로 성장했다. 다시 말해 GitHub이 이번에 낸 것은 이미 존재하던 시장의 네이티브 편입이다.

그렇다면 질문은 뒤집힌다. 이렇게 오래된 좋은 아이디어를, 세계 최대의 코드 호스팅 플랫폼은 왜 이제야 내놓았는가. 답의 핵심은 git의 데이터 모델에 있다. git은 브랜치와 커밋을 안다. 그러나 “이 브랜치는 저 브랜치 위에 쌓인 스택의 한 층”이라는 관계는 git이 네이티브로 표현하지 못한다. 스택은 git의 1급 개념이 아니다. 그래서 모든 스택 도구는 git 바깥에 자기만의 메타데이터를 덧붙여 스택을 흉내 낸다. ghstack은 커밋 메시지에 식별자를 심고, Graphite는 자체 서버에 스택 구조를 저장하며, GitHub의 이번 구현은 PR의 기반 브랜치 지정과 스택 맵으로 그 관계를 관리한다. 이 “바깥에 덧댄 메타데이터”가 스택 도구가 서로 호환되지 않고 저마다 락인 (lock-in) 을 만드는 근본 원인이다.

바로 여기서 이번 구현의 설계 선택이 논쟁을 부른다. GitHub은 변경의 단위로 커밋이 아니라 브랜치/PR을 택했다. HN 스레드의 한 참여자는 이 지점을 파고들어, GitHub이 Gerrit·Phabricator가 오래전에 확립한 change ID와 버전 추적을 도입하지 않았다는 취지로 비판한다. change ID가 있으면 리베이스를 거쳐도 각 변경의 정체성이 유지되어, 리뷰 코멘트가 사라지지 않고 리비전 간 interdiff 리뷰(직전 리뷰 이후 무엇이 바뀌었는지만 보기)가 가능하다. 커밋을 리뷰 단위로 두고 잘 정제된 커밋 히스토리를 중시하는 git 문화와, 브랜치를 원자 단위로 다루는 GitHub의 PR 문화가 여기서 정면으로 부딪힌다. 이는 단순한 취향 다툼이 아니라, 리뷰의 연속성이라는 실질에 닿는 문제다.

트레이드오프는 그래서 양쪽으로 벌어진다. 한쪽에는 스택 자체의 비용이 있다. 스택은 인지 부하를 늘린다. 개발자는 이제 코드뿐 아니라 스택의 위상 — 어느 층이 어디에 의존하는지, 무엇을 먼저 머지해야 하는지 — 을 머릿속에 유지해야 한다. 아래층에서 충돌이 나면 그 위 모든 층으로 리베이스 충돌이 연쇄 (cascade) 하고, 자동 리베이스가 있어도 사람이 풀어야 하는 충돌은 남는다. 도구 락인도 실재한다. HN에서는 gh stack CLI에 대한 의존이 git 자체를 중심으로 표준화하기보다 GitHub 종속을 낳는다는 취지의 우려가 제기됐고, 다중 리포지토리(polyrepo)에 걸친 스택을 지원하지 않는 한계도 지적됐다.

다른 한쪽에는 더 근본적인 반론이 있다. 정말 필요한 것이 정교한 PR 사슬이냐는 물음이다. 트렁크 기반 개발 (trunk-based development) 진영은, 애초에 큰 변경을 며칠씩 리뷰 사슬로 끌지 말고 작은 커밋을 자주 main에 넣되 미완성 기능은 피처 플래그 (feature flag) 뒤에 숨기라고 말한다. 이 관점에서 스택은 문제의 해결이 아니라 우회다. 오래 살아 있는 분기와 큰 배치 리뷰라는 근본 원인을 놔둔 채, 그 위에 관리 도구를 얹는다는 것이다. 물론 반대편의 재반론도 성립한다. 피처 플래그는 그 자체로 런타임 복잡도와 죽은 코드 경로, 플래그 정리 부채를 낳으며, 서로 강하게 의존하는 리팩터링은 플래그로 깔끔히 분리되지 않는다. 두 진영 모두 “작고 자주”라는 목표는 공유한다. 다만 그 목표에 도달하는 경로 — 리뷰 시점의 스택이냐, 통합 시점의 플래그냐 — 가 갈릴 뿐이다. 이 갈림은 취향이 아니라 팀의 릴리스 구조와 결합도에 달린 실증적 문제다.

전망 — 스택이 이득이 되는 순간과 과잉이 되는 순간

실무적 시사점은 “스택을 쓸 것인가”가 아니라 “언제 스택이 값을 하는가”로 좁혀야 한다. 스택이 명확히 이득인 국면은 두 가지다. 첫째는 큰 리팩터링이다. 인터페이스를 바꾸고, 호출부를 모두 고치고, 낡은 경로를 걷어 내는 작업은 본질적으로 순서 있는 의존 사슬이다. 이런 변경을 단일 PR로 올리면 아무도 제대로 못 읽고, 여러 개의 독립 PR로 억지로 쪼개면 서로 컴파일되지 않는다. 스택은 정확히 이 틈을 메운다. 둘째는 서로 의존하는 연속 작업을 앞 작업의 머지를 기다리지 않고 이어 가야 할 때다. 앞 PR이 리뷰 대기 중일 때 뒤 작업을 멈추지 않아도 된다는 것은, 리뷰 지연이 곧 개발 정체가 되는 큰 조직에서 실질적 처리량 이득을 준다.

반대로 스택이 과잉이 되는 국면도 분명하다. 서로 독립적인 작은 변경들, 하루 안에 리뷰되고 머지되는 PR들, 리뷰어와 작성자가 같은 두세 명뿐인 소규모 팀에서는, 스택이 주는 이득보다 위상을 관리하는 인지 비용이 크다. 이럴 때는 그냥 각각을 독립 PR로 올리고 빠르게 머지하는 편이 낫다. 도구는 문제가 있을 때 도입해야지, 도구를 정당화하려고 문제를 키워서는 안 된다. 스택형 diff를 오래 써 온 조직들이 공통으로 말하는 것도 이 지점이다. 스택은 만능이 아니라 특정 형태의 큰 작업을 위한 전문 도구다.

생태계 차원의 파장은 Graphite에 집중된다. Graphite의 핵심 가치 제안은 “GitHub에 없는 스택 경험”이었다. 그 결핍을 GitHub이 네이티브로 채우기 시작한 이상, Graphite의 해자 (moat) 는 좁아진다. 특히 스택 맵이 GitHub 자체 PR 화면 안에 산다는 점은 결정적이다. 리뷰어가 아무것도 설치할 필요가 없다는 것은, 별도 도구를 깔아야 하는 서드파티가 구조적으로 따라잡기 어려운 지점이기 때문이다. 다만 Graphite에는 GitHub v1이 아직 통과 중인 수많은 엣지 케이스를 이미 푼 연차가 있다. 앞서 본 스쿼시 머지 버그, change ID 부재, 다중 리포 미지원 같은 미성숙이 GitHub의 약점이라면, 성숙도는 당분간 서드파티의 방어선이 된다. 플랫폼 소유자가 기능을 네이티브로 흡수할 때 그 위에 서 있던 스타트업이 겪는 전형적 압박 — 이른바 “플랫폼에 먹히는” 구도 — 이 여기서 반복된다.

세 시나리오로 정리한다. 낙관은 이렇다. GitHub이 change ID와 interdiff, 다중 리포, 안정적 원자 머지까지 채워 넣으면, 스택형 diff는 특권적 도구를 갖춘 빅테크의 전유물에서 벗어나 모든 팀의 기본 워크플로가 된다. Meta와 Google이 사내에서 누리던 리뷰 문화가 업계 표준으로 내려온다는 뜻이다. 비관은 이렇다. git이 스택을 네이티브로 표현하지 못하는 근본 한계가 그대로인 한, GitHub의 구현 역시 바깥에 덧댄 또 하나의 메타데이터 계층일 뿐이어서, 리베이스 연쇄 충돌과 도구 락인이라는 오래된 통증을 이름만 바꿔 재생산한다. 현실적 전망은 그 사이다. 스택형 PR은 큰 리팩터링과 의존 사슬이라는 특정 문제에서 실질적 이득을 주며 빠르게 자리 잡되, 트렁크 기반+피처 플래그와 경쟁하며 공존하고, Graphite 같은 서드파티는 네이티브가 아직 못 미치는 성숙도와 다중 리포·고급 기능으로 상위 시장에서 버티는 그림이다.

한 가지 각도를 덧붙인다. 이번 발표가 코딩 에이전트를 위한 gh-stack 스킬을 함께 실은 것은 우연이 아니다. HN에서도 이 기능이 전통적 개발보다 AI 생성 코드의 워크플로를 겨냥한 것 아니냐는 취지의 관찰이 나왔다. 에이전트가 큰 작업을 자율적으로 여러 층으로 쪼개 올리면, 사람 리뷰어는 그 층들을 작게 나눠 검토해야 한다. 에이전트가 생성하는 코드의 양이 늘수록, 그 코드를 사람이 감당 가능한 크기로 절단하는 장치의 수요도 늘어난다. 스택형 PR의 대중화 타이밍은 리뷰 대상의 생산 주체가 사람에서 에이전트로 옮겨 가는 흐름과 무관하지 않다.

결론 — 주류화인가, 도구 계층의 이동인가

도입의 질문으로 돌아간다. 스택형 diff는 마침내 GitHub에서 주류가 되는가, 아니면 git의 브랜치 모델이 표현하지 못하는 것을 억지로 떠받치는 임시방편의 확산인가. 답은 양자택일이 아니다. 둘 다 참이다. 세계 최대 플랫폼이 이 워크플로를 네이티브로 품었다는 사실만으로 스택형 diff의 대중화는 이미 되돌릴 수 없는 방향이 됐다. Meta와 Google이 특권적 사내 도구로 누리던 리뷰 문화가, 설치 없이 리뷰어의 화면 안으로 들어온 것은 진짜 진전이다. 그러나 그 진전이 git의 근본 한계를 지운 것은 아니다. 스택은 여전히 git의 1급 개념이 아니고, GitHub의 구현도 바깥에 덧댄 메타데이터 계층이라는 점에서 다른 도구들과 본질이 같다. 락인의 주체가 서드파티에서 플랫폼으로 옮겨 갔을 뿐, 락인 자체가 사라진 것은 아니다.

그래서 이번 수용의 진짜 의미는 “문제가 풀렸다”가 아니라 “논쟁의 무대가 커졌다”에 가깝다. 커밋이냐 브랜치냐, 스택이냐 트렁크+플래그냐, 리뷰의 연속성을 어떻게 보장하느냐는 물음은 이제 빅테크의 사내 위키가 아니라 모든 팀의 일상 위에서 다뤄진다. GitHub이 늦게 도착했다는 사실은 흠이 아니라, 이 워크플로가 소수의 실험을 지나 검증된 표준이 되었다는 방증이다. 남은 것은 각 팀이 자신의 결합도와 릴리스 구조를 정직하게 보고, 스택이 값을 하는 국면과 과잉이 되는 국면을 구분하는 일이다. 도구가 대중화될수록, 그 도구를 언제 쓰지 않을지를 아는 판단이 더 중요해진다.

출처: