PR 사이즈가 크다는 뜻은 하나의 PR(Pull Request)에 변경 사항이 너무 많다는 것을 의미합니다. PR 사이즈가 크면 리뷰어가 리뷰할 때 시간이 많이 필요하게 됩니다. 이해하기 쉬운 코드를 작성하기 위해 노력한다 해도 타인이 작성한 코드를 읽고 이해하는 일은 쉽지 않은 일입니다. PR 사이즈를 줄이고 싶어서 일의 단위를 작게 나누려고 노력하는 편인데, 변경 사항의 양을 만족스러운 수준으로 줄이기는 쉽지 않았습니다. 그 이유가 무엇인지 생각해보는 시간을 가졌습니다. 크게 세 가지 정도의 이유가 있었습니다.
혹시 코드 리뷰가 무엇인지, 어떤 장단점이 있는지 알고 싶으신 분들은 여기(👈click!!) 를 참조하세요!
여유 없는 일정
첫 번째 이유는 너무나 흔한 이유입니다. 누구나 한 번 쯤은 겪어 봤을 텐데요, 바로 프로젝트 일정에 여유가 없는 것입니다.
일정은 촉박하고 해야 할 일이 너무 많으면 PR 사이즈를 작게 유지하기 힘듭니다.
일의 단위를 어떻게 나눌지 고민해서 스토리를 만들고, 브랜치를 생성하고, PR을 생성해서 피드백을 받고, 피드백을 반영해서 기존 코드 베이스에 변경 사항을 통합하는 일을 반복하는 데에는 생각보다 많은 시간이 소요됩니다.
변경 사항이 너무 많아서 PR 사이즈가 커지면 리뷰 할 엄두도 안 날 뿐더러 다들 자기 일만 하기에도 벅찰 겁니다. 최대한 빨리 일을 쳐내야만 하는 상황이니까요.
그렇게 형식적인 과정에 소중한 시간을 허비할 바에야 바쁘면 코드 리뷰 과정을 생략하는 것도 상황에 따라서는 괜찮을 것 같습니다. 단, 개발자들이 어느정도 숙련되어 믿을 수 있는 수준이라면요. 그러면 중요한 사항은 함께 논의해서 결정하고, 일정 주기를 정해서 그동안의 변경 사항을 서로 간략하게 공유하는 시간을 만들면 되지 않을까요?
일정을 소화하기에는 무리라는 것을 깨달았을 때 최대한 빠르게 계획을 수정하는 게 바람직하지만, 그럴수 없는 경우가 대부분일 거라고 생각해요.
모두가 너무 바쁠 때는 정말 크리티컬한 문제가 있는 코드인지만 빠르게 확인하고 승인 해주는 것을 규칙으로 만드는 것도 괜찮은 방법이라는 생각이 듭니다.
느린 코드 리뷰
PR 사이즈가 커지는 두 번째 이유는 PR을 생성하고 리뷰어를 지정했는데, 아무도 적극적인 리뷰를 해주지 않는 상황입니다. 일정 수 이상의 승인을 받아야 코드를 통합할 수 있는 룰이 걸려있다면 코드를 통합할 수 없는거죠. 아무도 승인 해주지 않고 피드백도 없을 수 있어요. 바쁘면 그냥 승인해주기도 합니다.
그런 상황을 겪게 되는 이유는 여러 가지가 있겠죠. 앞에서 이야기 했던 ‘여유 없는 일정’도 큰 몫을 차지할 거예요.
일정에 여유가 없는 게 원인이 아니라면, 너무 큰 PR을 올렸거나 리뷰어들이 배경 지식이 부족한 경우일 수 있습니다. 아니면 그냥 이해하기 어려운 코드를 작성했을 지도요.
리뷰를 하는 사람도 노력해야겠지만, 리뷰하기 쉬운 PR을 생성해주는 것이 조금 더 중요하다 할 수 있겠어요.
물론 슬프게도 리뷰어가 그냥 코드를 리뷰할 생각이 없을 수도 있습니다만.. 우리는 그런 리뷰어들에게서도 리뷰를 받아내기 위한 노력을 해 볼 수 있습니다. 예를 들면, 만약 정말 작은 단위의 PR만 생성하고, 충분히 상세한 설명을 동반한 상태에서 피드백을 요청한다면 리뷰어들도 빠르게 피드백을 줄 수 있지 않을까요? PR에 상세한 설명과 코멘트를 달아서 리뷰어가 쉽게 이해할 수 있게 도와줄 수도 있고, 오프라인으로 회의를 열거나 자리로 찾아가서 변경 사항에 대해 설명해주는 방법도 있습니다.
저는 자리로 잠시 와 달라고 부탁해서 코드를 간략하게 설명하고, 어떻게 동작하는지 보여주면서 의견을 묻는 방법이 꽤 효과적이었던 것 같습니다.
예상하지 못했던 추가적인 변경 사항
PR 사이즈가 커지는 세 번째 이유입니다. 모든 것이 설계된 상태에서 코드를 작성할 수 없다는 사실이 원인일 수도 있습니다.
설계를 하지 않고 개발을 한다니, 이게 무슨 소리일까요?
물론 설계를 할 필요가 없다는 의미는 아닙니다. 설계는 필요합니다. 단, 핵심적인 기능을 위주로 틀을 먼저 잡아 놓고 그 위에 살을 붙이거나 구조를 개선하는 방식으로 개발해나가는 것이 제가 선호하는 방법입니다. 『실용주의 프로그래머』 라는 제목의 책에서 ‘예광탄 개발 방법’으로 소개하고 있는 방법입니다. 괜찮은 방법이니 여러분도 한 번 시도해 보세요. PR 사이즈를 줄이기 위해 업무 단위를 최대한 신경 써서 잡더라도, 예상치 못한 변경사항이 많을 수 있습니다. 그럴 땐 커밋이라도 자주 해줘야 합니다. 어떤 의미있는 변경들이 모인 결과물인지 알 수 있게요.
모든 요구 사항을 예측해서 설계를 완료한 채로 개발을 시작한다는 건 꿈과 같은 이야기입니다. 제 생각이지만요. 충분히 고민해서 설계를 마쳤다고 생각했는데 개발을 진행하다 보면 처음에는 예상하지 못했던 상황이 펼쳐집니다. 높은 확률로요. 생각보다 많은 변경이 필요하게 되고, 추가적인 개발이 수반되는 경우가 많아요. 그러니 양 끝 단을 오고 가며 빠르게 피드백을 받고 방향을 수정해 나가는 편이 합리적이라는 생각이 듭니다. 만약 제 생각에 동의하신다면 ‘예광탄 개발 방법’을 한 번 따라해 보시는 걸 추천 드려요.
마지막으로 Pull Request 사이즈에 대한 흥미로운 글이 있어서 공유합니다. 1시간 안에 코드 검토를 완료할 확률이 90% 이상이 되려면 변경 사항을 200 라인으로 제한해야 한다는 의견을 제시하고 있습니다.
