Pull Request, 이대로 괜찮을까? PR 워크플로우를 다시 생각하다

PR, 우리 모두의 일상이 된 병목

개발자라면 매일같이 PR(Pull Request)을 만들고, 리뷰하고, 머지하잖아요. 근데 솔직히 말해서, PR 프로세스가 불편하다고 느낀 적 없으신가요? 코드를 다 짜고 PR을 올렸는데 리뷰어가 바빠서 이틀째 방치된다거나, 리뷰 코멘트가 달려서 수정했더니 또 다른 코멘트가 달리고, 이러다 보면 단순한 기능 하나 머지하는 데 일주일이 걸리기도 하죠. lubeno.dev의 "Reinventing the Pull Request"라는 글에서 바로 이 문제를 정면으로 다루고 있어요.

핵심 주장은 이거예요. 현재의 PR 모델은 2008년 GitHub가 도입한 이후 근본적으로 바뀌지 않았는데, 개발 방식은 완전히 달라졌다는 거예요. 특히 AI 코딩 어시스턴트가 코드 생성 속도를 극적으로 높인 지금, 코드를 작성하는 시간보다 리뷰를 기다리는 시간이 더 긴 아이러니한 상황이 벌어지고 있다는 거죠.

기존 PR 모델의 문제점

기존 PR 모델의 가장 큰 문제는 비동기적이고 단절적이라는 거예요. 작성자가 코드를 올리고, 리뷰어가 시간이 날 때 보고, 피드백을 주면, 다시 작성자가 시간이 날 때 수정하고... 이 핑퐁이 반복되면서 하나의 변경사항이 머지되기까지 엄청난 대기 시간이 생겨요.

또 하나의 문제는 PR의 크기예요. 이상적으로는 작은 PR을 자주 올리는 게 좋다고 다들 알고 있지만, 현실에서는 기능 하나를 완성하려면 여러 파일을 건드려야 하고, 결국 수백 줄짜리 PR이 만들어지죠. 큰 PR은 리뷰하기 부담스럽고, 리뷰 품질도 떨어져요. 500줄짜리 PR에 달리는 "LGTM"이 정말 꼼꼼히 본 건지 다들 의문이잖아요.

세 번째는 컨텍스트 부족 문제예요. PR의 diff만 보면 "이 코드가 왜 이렇게 바뀌었는지"를 이해하기 어려운 경우가 많아요. PR 설명에 적어놓긴 하지만, 복잡한 변경사항의 의도를 텍스트로 다 전달하기는 쉽지 않거든요.

어떤 대안들이 제시되고 있나

글에서 제안하는 방향 중 하나는 스택 PR(Stacked PRs) 방식이에요. 이게 뭐냐면, 하나의 큰 변경사항을 여러 개의 작은 PR로 쪼개되, 이 PR들이 서로 의존 관계를 가지고 순서대로 쌓이는(stack) 구조예요. 마치 레고 블록을 하나씩 쌓아올리듯이, 각 PR은 이전 PR 위에 올라가는 거죠.

Graphite, ghstack 같은 도구들이 이 워크플로우를 지원하는데요. 리뷰어는 한 번에 거대한 diff를 보는 대신, 논리적으로 분리된 작은 변경사항을 순서대로 볼 수 있어서 리뷰 품질이 올라가요. 작성자 입장에서도 리뷰 피드백을 반영하기가 훨씬 수월하고요.

또 다른 방향은 실시간 협업 리뷰예요. Google의 내부 코드 리뷰 도구인 Critique가 이런 방향인데, 코드 작성과 리뷰가 좀 더 동기적으로 이루어지는 거예요. 작성자와 리뷰어가 거의 실시간에 가깝게 대화하면서 코드를 발전시키는 방식이죠.

그리고 AI 코드 리뷰도 점점 현실화되고 있어요. AI가 명백한 버그나 스타일 이슈를 먼저 잡아주고, 사람 리뷰어는 설계 결정이나 비즈니스 로직 같은 고수준 리뷰에 집중하는 방식이에요. 이미 CodeRabbit, Graphite의 AI 리뷰어, GitHub Copilot의 코드 리뷰 기능 등이 이 방향으로 발전하고 있죠.

트렁크 기반 개발과의 관계

이 논의를 더 넓게 보면 트렁크 기반 개발(Trunk-Based Development)과도 연결돼요. 이건 오래 사는 피처 브랜치를 만들지 않고, 짧은 주기로 메인 브랜치에 직접 커밋하거나 아주 짧은 수명의 브랜치만 사용하는 방식인데요. Google, Meta 같은 대규모 조직에서 실제로 사용하고 있어요.

트렁크 기반 개발에서는 전통적인 의미의 PR이 아예 없거나 매우 가벼워요. 대신 피처 플래그로 미완성 코드를 안전하게 숨기고, 자동화된 테스트와 CI로 품질을 보장하죠. PR 리뷰에 의존하는 대신 시스템적으로 안전장치를 마련하는 거예요.

한국 개발자에게 주는 시사점

한국의 많은 개발팀이 GitHub Flow나 Git Flow를 기반으로 PR 리뷰를 하고 있을 텐데요. 만약 팀에서 PR 리뷰가 병목이 되고 있다면, 몇 가지 실험해볼 수 있어요.

우선 PR 크기에 대한 팀 가이드라인을 만들어보세요. "PR 하나당 변경 300줄 이하"같은 기준을 정하면 자연스럽게 변경사항을 쪼개는 습관이 생겨요. Graphite 같은 스택 PR 도구를 도입해보는 것도 좋고요. AI 코드 리뷰 도구를 CI에 붙여서 기계적인 리뷰는 자동화하고, 사람은 정말 중요한 부분에 집중하게 만드는 것도 효과적이에요.

리뷰 문화도 중요한데요. "리뷰는 24시간 이내에 응답한다"는 팀 약속만으로도 PR 체류 시간이 크게 줄어들 수 있어요.