깃허브가 드디어 '스택 PR'을 열었다 — AI가 코드를 쏟아내는 시대, 병목은 리뷰였습니다

깃허브가 스택 풀 리퀘스트(stacked pull requests)를 퍼블릭 프리뷰로 열었습니다. 2008년 서비스 시작 이후 사실상 처음으로 PR 위에 PR을 쌓는 워크플로를 공식 지원합니다. “그게 뭐 대단한 일이냐” 싶으실 수도 있는데요, 기능 하나 늘린 것치고는 시점이 묘합니다. AI가 코드를 쏟아내기 시작한 상황에 깃허브가 내놓은 답에 가깝거든요.

스택 PR이 뭔가요

기존 깃허브 방식은 이렇습니다. 브랜치를 하나 따고 작업하고 main에 PR을 올린 뒤 리뷰를 기다립니다. 그동안 개발자는 할 일이 없죠. 다음 작업이 방금 올린 PR에 의존한다면 더더욱요.

그래서 다들 둘 중 하나를 고릅니다. 리뷰가 끝날 때까지 기다리거나, 그냥 다 합쳐서 2천 줄짜리 거대 PR을 던지거나. 앞쪽은 느리고 뒤쪽은 리뷰어를 고문합니다. 2천 줄 PR을 받아본 사람은 압니다. 대충 스크롤하다가 LGTM 찍고 넘어가게 되죠.

스택 PR은 세 번째 길입니다. PR #1의 브랜치 위에 다시 브랜치를 따서 PR #2를 올리고 그 위에 PR #3을 올립니다. 각각 100~200줄쯤으로 작게 유지하니 리뷰어는 논리적으로 완결된 조각을 하나씩 봅니다. 개발자는 앞 PR의 리뷰를 기다리는 동안 뒷 작업을 계속하고요.

관건은 리베이스 자동화입니다. PR #1에 리뷰 피드백이 들어와 손을 대면 그 위에 쌓인 #2와 #3도 전부 다시 베이스를 맞춰야 합니다. 손으로 하면 지옥이죠. 깃허브가 이번에 지원하는 게 정확히 이 부분입니다. 스택 전체의 의존 관계를 인식해서, 하나가 머지되면 나머지의 베이스 브랜치를 알아서 갱신해줍니다.

15년간 남의 집이었던 영역

이 문제를 깃허브만 몰랐던 게 아닙니다. 오히려 모두가 알았지만 깃허브만 안 고쳤던 문제입니다.

메타는 사내에서 아예 다른 길을 갔습니다. Sapling이라는 자체 버전 관리 시스템을 만들어 커밋 단위로 리뷰하는 문화를 정착시켰죠. 구글의 Critique, 페이스북 시절의 Phabricator도 마찬가지입니다. 이런 회사에서 온 개발자가 깃허브 기반 스타트업에 합류하면 첫 문화 충격이 “여기는 왜 PR을 이렇게 크게 올리지?“라고들 합니다. 업계에서 반복적으로 도는 레퍼토리죠.

그 빈자리를 서드파티가 채웠습니다. Graphite가 대표적입니다. 메타 출신 창업자들이 만든 도구인데 “깃허브 위에 Sapling 경험을 얹는다"는 컨셉으로 사용자를 상당히 모았고 여러 스타트업의 표준 워크플로가 됐습니다. git-branchless, spr 같은 오픈소스 대안도 꾸준히 쓰였고요.

깃허브의 이번 발표는 이 생태계 전체를 정면으로 건드립니다. 플랫폼 사업자가 서드파티가 개척한 영역으로 내려오는 전형적인 흡수 패턴인데요, 이럴 때 서드파티가 살아남는 길은 하나뿐입니다. 플랫폼이 못 따라오는 층위로 올라가는 수밖에 없죠. Graphite가 최근 AI 코드 리뷰 쪽에 힘을 준 게 우연은 아닐 겁니다.

왜 하필 지금인가

15년간 안 고치던 걸 왜 2026년에 와서 고칠까요.

PR이 감당 못 할 만큼 쏟아지기 때문입니다. 코딩 에이전트가 일상이 되면서 한 명의 개발자가 하루에 만들어내는 변경량이 예전과 비교가 안 됩니다. 에이전트에게 작업을 던져놓고 다른 걸 하다 돌아오면 PR이 올라와 있습니다. 이제 흔한 풍경이죠.

그런데 리뷰 용량은 그대로입니다. 코드를 읽고 판단하는 건 여전히 사람 몫이고 사람의 하루는 여전히 24시간입니다. 생산 라인 속도를 열 배로 올렸는데 검수대는 한 개 그대로인 공장을 떠올려보세요. 검수대 앞에 재고가 쌓입니다.

이게 지금 많은 조직에서 실제로 벌어지는 일입니다. 코드를 만드는 비용은 급격히 떨어졌는데 그 코드를 이해하고 책임지는 비용은 그대로거든요. 오히려 늘었을 수도 있습니다. 내가 안 쓴 코드를 읽는 게 내가 쓴 코드를 읽는 것보다 훨씬 어려우니까요.

스택 PR은 이 병목을 겨냥한 처방입니다. 큰 덩어리를 작게 쪼개 리뷰어의 인지 부하를 낮추고 리뷰 회전율을 높이자는 거죠. 깃허브 입장에서는 “우리 플랫폼에서 리뷰가 막히면 코파일럿도 안 팔린다"는 계산이 섰을 겁니다.

그런데 이게 정말 해법일까요

다만 미심쩍은 구석이 있습니다.

우선 PR을 쪼갠다고 총량이 줄지는 않습니다. 2천 줄짜리 하나가 200줄짜리 열 개가 되면 리뷰어는 열 번 컨텍스트를 스위칭해야 합니다. 각각은 가볍지만 합계는 그대로거나 오히려 늘 수 있죠. 스택 PR이 제대로 굴러가려면 각 조각이 논리적으로 완결돼야 하는데, 이건 도구가 아니라 사람의 설계 능력에 달렸습니다.

도구가 문화를 만들어주지도 않습니다. 메타에서 스택 워크플로가 작동한 건 도구 때문만이 아니라 작은 단위로 나눠 올리는 게 당연하다는 합의가 있었기 때문입니다. 같은 도구를 문화 없는 조직에 넣으면 “스택으로 쌓인 2천 줄"이 나올 뿐입니다.

더 근본적인 질문도 있습니다. AI가 코드를 쏟아내는 판에 인간 리뷰를 붙들고 있는 게 맞을까요. 한쪽에서는 “결국 AI가 짠 코드는 AI가 리뷰하게 될 것"이라고 하고, 다른 쪽에서는 “그럼 아무도 이해 못 하는 코드가 프로덕션에 들어간다"고 반박합니다. 스택 PR은 이 논쟁에서 인간 리뷰를 살리는 쪽에 베팅한 기능입니다. 병목을 없애는 게 아니라 견딜 만하게 만드는 방향이죠.

실무자가 지금 할 일

프리뷰 단계라 전면 도입은 이르지만 지금 확인해둘 만한 건 있습니다.

CI 비용부터 보셔야 합니다. 스택이 깊어지면 리베이스가 연쇄적으로 일어나고 그때마다 파이프라인이 다시 돕니다. 스택 중간에 있는 PR을 매번 풀 빌드할지 최종 머지 시점에만 돌릴지 정책을 정해두는 게 좋습니다.

머지 순서도 문제입니다. 스택 중간의 PR만 먼저 머지하고 싶을 때 위에 쌓인 것들을 어떻게 처리할지 팀 규칙이 필요합니다. 브랜치 보호 규칙과 필수 리뷰어 설정이 스택 구조와 어떻게 맞물리는지도 미리 확인해두시고요.

이미 Graphite 같은 도구를 쓰고 계시다면 서둘러 갈아탈 이유는 없습니다. 프리뷰 기능은 대체로 기존 도구보다 거칠고, 성숙한 서드파티가 제공하는 스택 시각화나 일괄 업데이트 같은 기능은 아직 없거나 얕습니다.

마무리

이번 발표에서 눈여겨볼 건 기능보다 병목이 이동했다는 신호입니다. 몇 년 전만 해도 개발의 병목은 코드를 쓰는 일이었습니다. 지금은 쏟아지는 코드를 이해하고 책임지는 일로 옮겨갔죠. 도구 회사들이 리뷰 워크플로에 투자하기 시작한 것도 그래서입니다.

여러분 팀에서 지금 가장 오래 걸리는 단계는 어디인가요. 코드를 쓰는 시간인가요, 아니면 올라온 PR이 승인을 기다리며 방치되는 시간인가요. 후자라면 이미 문제는 시작됐습니다. 스택 PR이 그 답이 될지는 각자 확인해볼 일이고요.