Hacker News 2026.04.14 22

GitHub가 공식 지원하는 Stacked PR, 대체 뭐가 좋은 걸까?

PR이 너무 커서 리뷰가 안 되는 경험, 다들 있으시죠?

개발하다 보면 하나의 기능을 구현하는데 변경 파일이 수십 개가 되는 경우가 종종 있어요. 이런 큰 PR(Pull Request)을 올리면 리뷰어 입장에서는 "이걸 어디서부터 봐야 하지..."라는 막막함이 밀려오고, 결국 대충 LGTM(Looks Good To Me)을 날리게 되는 경우가 생기곤 하죠. 이런 문제를 해결하기 위한 워크플로우가 바로 "Stacked PR"인데요, GitHub에서 드디어 이걸 공식적으로 지원하는 도구 gh-stack을 내놓았어요.

Stacked PR이 뭔데요?

Stacked PR은 이름 그대로 PR을 "쌓아올리는" 방식이에요. 하나의 큰 변경사항을 논리적인 단위로 쪼개서 여러 개의 작은 PR로 만드는 건데, 핵심은 이 PR들이 서로 의존 관계를 갖는다는 점이에요.

예를 들어볼게요. 새로운 API 엔드포인트를 만든다고 해봐요. 이걸 하나의 PR로 올리면 데이터베이스 스키마 변경, 서비스 레이어 로직, API 컨트롤러, 테스트 코드가 전부 한꺼번에 들어가겠죠. 대신 Stacked PR 방식을 쓰면 이렇게 나눌 수 있어요: 첫 번째 PR은 DB 마이그레이션, 두 번째 PR은 서비스 로직(첫 번째 PR 위에 쌓기), 세 번째 PR은 API 엔드포인트(두 번째 위에 쌓기), 네 번째 PR은 테스트 추가. 이렇게 하면 각 PR이 200~300줄 수준의 집중된 변경이 되니 리뷰 품질이 확 올라가요.

gh-stack은 어떻게 동작하나요?

gh-stack은 GitHub CLI의 확장 기능(extension)으로, 터미널에서 바로 사용할 수 있어요. 기본적으로 git 브랜치 체인을 관리해주는 도구인데요, 핵심 기능을 살펴보면 이래요.

스택을 만들 때는 각 단계의 브랜치를 순서대로 생성하면서 이전 브랜치를 베이스로 설정해요. 그러면 gh-stack이 이 의존 관계를 추적하면서, PR 생성 시 자동으로 베이스 브랜치를 올바르게 설정해줘요. 가장 큰 장점은 중간 PR에 변경이 생겼을 때예요. 기존에는 중간 브랜치가 바뀌면 그 위에 쌓인 모든 브랜치를 일일이 rebase해야 했는데, gh-stack이 이 과정을 자동화해줘요.

또한 각 PR의 설명에 스택 전체의 구조를 보여주는 테이블을 자동으로 삽입해줘서, 리뷰어가 "이 PR이 전체에서 어디에 위치하는지"를 한눈에 파악할 수 있게 해줘요. 이전 PR이 머지되면 다음 PR의 베이스 브랜치를 자동으로 main으로 업데이트하는 기능도 있고요.

기존 도구들과 뭐가 다른가요?

사실 Stacked PR 개념 자체는 새로운 건 아니에요. 이미 Graphite, gitstack, spr 같은 서드파티 도구들이 이 워크플로우를 지원하고 있었거든요. 특히 Graphite는 스타트업이 만든 도구로 꽤 인기가 있었는데, 자체 대시보드와 분석 기능까지 제공해요.

그런데 gh-stack이 의미 있는 이유는 GitHub 공식 도구라는 점이에요. 별도의 서비스에 가입하거나 추가 권한을 부여할 필요 없이, GitHub CLI만 있으면 바로 쓸 수 있거든요. 회사에서 보안 정책 때문에 외부 서드파티 도구 도입이 까다로운 경우에도 "GitHub 공식이니까"라는 명분이 생기는 거죠.

구글이나 메타 같은 빅테크에서는 모노레포(monorepo) 환경에서 이런 스택형 코드 리뷰가 이미 표준이에요. 구글의 내부 도구나 Meta의 Sapling이 이런 워크플로우를 기본으로 제공하고 있죠. 이번에 GitHub가 공식 지원에 나선 건, 오픈소스와 일반 기업 환경에서도 이 방식이 점점 표준이 되어가고 있다는 신호로 볼 수 있어요.