PR 사이즈를 200줄로 강제했더니 일어난 일

우리 팀에서 PR 이 커지는 건 하나의 패턴을 따랐다. 기능 하나를 구현하다 보면 연관된 리팩터링이 눈에 들어오고, 그걸 함께 처리하다 보면 500줄, 800줄짜리 PR 이 만들어진다. 리뷰어는 끝까지 읽기 버겁고, 결국 “LGTM” 이 빠르게 달리거나, 리뷰가 밀려서 머지가 늦어지거나 둘 중 하나였다.

이 문제를 해결하기 위해 팀 내에서 비공식 규칙을 정했다. PR 하나당 diff 200줄 이하. 테스트 파일 제외, 설정 파일 제외. 순수 로직 변경 기준이다.

처음 한 달: 저항과 적응

처음에는 불편함이 컸다. 기능을 쪼개야 한다는 게 추상적으로 들렸고, 어디서 끊어야 할지 감이 안 왔다. “이건 붙어 있어야 의미가 있는 코드인데”라는 말이 자주 나왔다.

그런데 억지로 쪼개다 보니 재미있는 일이 생겼다. 분리가 어렵다고 느낀 코드가 실제로는 결합도가 높아서 분리가 어려웠던 것이고, 그 자체가 설계 문제의 신호였다. PR 을 쪼개는 행위가 아키텍처 문제를 드러내는 도구가 됐다.

두 번째 변화는 커밋 메시지가 좋아졌다는 것이다. PR 이 작아지면 그 PR 이 무엇을 하는지 한 줄로 설명하기가 쉬워진다. 반대로 PR 이 크면 제목이 “여러 개 수정” 이나 “작업분 반영” 처럼 모호해진다.

리뷰 품질의 변화

200줄 상한이 자리를 잡은 두 번째 달부터 리뷰 댓글 수가 늘었다. 줄 수가 줄어드니까 리뷰어가 각 변경사항을 집중해서 읽게 됐다. 전에는 피로감 때문에 흘려 보냈을 부분들에서 질문과 제안이 나왔다.

특히 도움이 됐던 건 “이 PR 은 왜 이 변경이 필요한가”를 PR 설명에 쓰는 습관이 생긴 것이다. 작은 PR 은 그 이유를 설명하기도 쉽다. 맥락이 좁기 때문에 작성자도 더 명확하게 이유를 쓸 수 있고, 리뷰어도 그 맥락 안에서 집중할 수 있다.

트레이드오프

단점도 있다. 큰 피처를 여러 PR 로 나눠서 올리면 의존성 관리가 생긴다. 앞 PR 이 머지되기 전에 다음 PR 을 올리면 브랜치 체인이 생기고, 앞 PR 에서 수정이 일어나면 이후 PR 들을 모두 리베이스해야 한다. 이 오버헤드는 무시할 수 없다.

우리가 찾은 절충점은 피처 플래그다. 큰 피처를 여러 PR 로 나누되, 플래그 뒤에 숨겨 두면 중간 상태가 메인 브랜치에 들어가도 실제 사용자에게 노출되지 않는다. 각 PR 은 독립적으로 머지 가능하고, 마지막에 플래그를 켜는 PR 하나로 피처가 완성된다.

3개월 후

규칙 자체보다 규칙이 만들어낸 습관이 더 중요하다는 걸 느꼈다. 코드를 작게 나누는 연습이 설계 능력을 키웠고, 리뷰 속도가 빨라지면서 병목이 줄었다. 200줄이라는 숫자 자체에 의미가 있는 게 아니라, “리뷰어가 한 번에 집중할 수 있는 크기”를 팀이 의식하게 됐다는 것이 핵심이다.

— by mings