깃허브가 드디어 '스택 PR(Stacked Pull Requests)' 기능을 퍼블릭 프리뷰로 공개했어요. 메타나 구글 같은 회사에서는 오래전부터 표준처럼 쓰던 워크플로우인데, 깃허브 사용자들은 그동안 서드파티 도구로 어렵게 흉내 내야 했거든요. 그 기능이 이제 깃허브에 기본으로 들어온 거예요.
스택 PR이 뭐냐면
큰 기능 하나를 개발한다고 생각해볼게요. DB 스키마 변경, API 추가, UI 연결까지 하다 보면 변경된 파일이 수십 개, diff가 수천 줄짜리 PR이 되기 쉽죠. 이런 PR은 리뷰어가 열어보는 순간 한숨부터 나와요. 제대로 읽기 어려우니 리뷰 품질도 떨어지고, 승인까지 한참 걸리고요. 스택 PR은 이걸 해결하는 방식이에요. 작업을 논리적인 단위로 쪼개서 PR 1(스키마) 위에 PR 2(API)를, 그 위에 PR 3(UI)를 '쌓는' 거예요. 각 PR은 바로 아래 PR의 브랜치를 베이스로 삼아요. 그러면 리뷰어는 300줄짜리 PR 세 개를 각각 편하게 리뷰할 수 있고, 나는 PR 1의 리뷰를 기다리는 동안 그 위에서 PR 2, 3 작업을 계속할 수 있죠. 리뷰 대기 시간에 일이 멈추지 않는다는 게 핵심이에요.
그동안 뭐가 문제였냐면
개념 자체는 깃허브에서도 베이스 브랜치를 지정하면 흉내 낼 수 있었어요. 문제는 유지보수였는데요. 맨 아래 PR이 머지되는 순간 지옥이 시작되거든요. 위에 쌓인 PR들의 베이스를 일일이 바꿔주고, 리베이스하고, 강제 푸시하고... 이 과정에서 diff가 꼬여서 리뷰어 화면에 이미 머지된 코드가 다시 변경사항으로 뜨는 일도 흔했어요. 아래쪽 PR을 리뷰 반영으로 수정하면 그 위의 모든 PR을 다시 리베이스해야 하는 것도 고역이었고요. 그래서 Graphite 같은 전문 서비스나, 메타가 만든 ghstack, Sapling 같은 도구들이 이 틈새를 파고들어 꽤 큰 생태계를 이뤘어요. '깃허브가 안 해주니 우리가 한다'는 시장이었던 거죠.
이제 뭐가 달라지나요
공식 지원의 요점은 이 수작업을 깃허브가 대신해준다는 거예요. PR들이 하나의 스택으로 묶여 있다는 걸 깃허브가 인지하고, UI에서 스택 전체 구조를 보여줘요. 아래 PR이 머지되면 위 PR들의 베이스가 자동으로 정리되고, 리뷰어는 각 PR에서 해당 단계의 변경분만 깔끔하게 볼 수 있게 되는 거죠. 스택을 순서대로 머지하는 흐름도 훨씬 매끄러워지고요. 아직 퍼블릭 프리뷰라 세부 동작이나 지원 범위는 다듬어지는 중이지만, 방향 자체는 서드파티 도구들이 수년간 증명해온 워크플로우를 플랫폼 차원에서 흡수하는 거예요. 그동안 이 도구들을 쓰려고 팀 전체가 별도 CLI를 익혀야 했던 진입 장벽이 사라진다는 게 커요.
한국 팀들이 눈여겨볼 지점
사실 이 기능의 진짜 가치는 도구보다 '리뷰 문화'에 있어요. PR이 작아지면 리뷰가 빨라지고, 리뷰가 빨라지면 머지 주기가 짧아지고, 배포 리스크도 줄어들거든요. 많은 팀이 작은 PR이 좋은 건 알면서도 쪼개는 게 번거로워서 큰 PR을 방치해왔잖아요. 그 핑계가 사라지는 셈이에요. 당장 해볼 수 있는 건 다음 기능 개발 때 커밋을 논리 단위로 정리하고 스택으로 올려보는 거예요. 다만 팀 차원에서는 규칙을 먼저 맞추는 게 좋아요. 스택 중간 PR에 리뷰 코멘트가 달렸을 때 반영하는 방식, 머지 순서, CI를 스택 단위로 돌릴지 개별 PR 단위로 돌릴지 같은 것들이요. Graphite 같은 유료 도구 도입을 검토하던 팀이라면, 공식 기능으로 충분한지 먼저 따져볼 타이밍이기도 하고요.
요약하면, 대형 PR을 잘게 쪼개 쌓아 올리는 워크플로우가 이제 깃허브의 기본기가 됐다는 소식이에요. 여러분 팀의 평균 PR 크기는 어느 정도인가요? 스택 PR을 계기로 리뷰 문화를 바꿔볼 만하다고 생각하시나요?
🔗 출처: Hacker News