[스타트업 개발문화] 개발팀에 작은 PR 원칙 만들기

상황

나는 20년 12월 경 인원이 10명 대의 작은 커머스 회사에 첫 번째 프론트 개발자로 입사하게 되었다.

내가 입사하기 전에는 개발은 외주로 맡겨져 있었고 내가 입사했을 때 개발팀이 처음으로 꾸려진 것이었다. 

 

그렇기에 개발팀의 체계가 전무했다. 

모든 회사가 그렇듯, 처음에는 주먹구구식으로 흘러갔지만 나는 더 나은 방향, 더 나은 시스템에 대한 갈증이 생겼고

나는 조금씩 개발팀의 체계를 만들기 위한 제안과 노력들을 해나갔다.

 

[스타트업의 개발문화] 섹션은 그런 전무한 상황 속 개발팀에 체계를 만들기 위해 노력했던 이야기를 담아보고자 한다. 

 

---

 

내가 입사하고 2년 사이 총 인원이 10명대에서 40명대로 개발팀 인원이 3명에서 8명으로 늘어났다. 

 

처음에는 프론트 개발을 전담했는데, 프론트 개발자가 하나 둘 씩 입사하더니 이제는 4명으로 프론트 팀이 생겼다.

우리 팀은 너나 할 것 없이 모두 의욕적으로 프론트팀으로서 필요한 컨벤션 및 시스템을 하나 둘 씩 만들기 시작했다. 

 

그 중, 오늘은 '작은 PR 원칙'  을 도입한 배경과 그 결과로 어떤 점이 나아졌는 지에 대한 포스팅이다.

문제

프론트 개발자가 늘어나고 프론트 팀이 생기면서 자연스럽게 PR 양이 늘어났다. 

PR 양이 늘어나는 것은 곧 리뷰어가 봐야 할 PR의 양이 늘어나는 것을 의미한다. 

 

이것 자체로는 문제가 아니다. 이는 자연스러운 현상이다

(내가 입사할 때만 하더라도 코드리뷰 조차 없었 기 때문에 PR을 하는 것도, 리뷰하는 것에 대한 시스템이 아예 없었다.)

문제는 PR을 올릴 때 한번에 너무 많은 코드를 올리는 데에 있었다.

 

PR을 올리는 것에 대한 규칙이 없었기 때문이다.

 

예를 들어 한 달짜리 프로젝트를 맡고 있는 A 개발자는 프로젝트가 끝날 때 즈음에 PR을 올리는 경우가 빈번했다.

배포 전에 디자인 검수, 기획 QA 검수를 맡아야 하는데 검수 과정에서 코드의 수정이 필요하기 때문에 그 수정 작업을 다 한 후에 올릴려고 하는 것이다.

 

이렇게 될 경우 그 PR의 양은 한 달짜리 커밋양 + 검수 중 수정사항이 겹치면서 엄청난 코드가 올라간다. 

더군다나 배포 전에 PR 했기 때문에 코드리뷰를 위한 시간 자체가 여유롭지 않다.

 

부끄럽지만 이전의 내 PR 커밋양이다.

 

이렇게 되면 뭐가 문제일까?

1. 리뷰어는 바빠요! → 귀한 시간을 내주는 리뷰어는 저 많은 커밋을 읽기 위해 많은 시간을 내기 힘들어요!
2. 리뷰어의 집중도가 떨어져요! → 변경내역이 많을 수록 리뷰어는 좋은 리뷰를 남길 집중도가 떨어져요!
3. 코드리뷰 할 시간이 줄어들어요! → 한 번에 모든 작업을 올리려다 보니 마감 전까지 붙들게 된다. 마감 전에 올리는 PR은 → 급한 approve 요청 → 세세하게 못봄 → 낮은 퀄리티, 버그 발생!

PR은 리뷰어에게 나 이만큼 작업했어 자랑하는 것이 아니라 공손하게 리뷰어에게 "내가 작업한 것을 봐주세요" 라고 부탁하는 것이다.

그러니 당연히 리뷰어에 대한 배려가 필수적이다. 

하지만 우리는 리뷰어가 피로감이 생길 정도로 많은 코드양과 적은 리뷰 시간으로 리뷰어에 대한 배려가 없었다.

 

해결

문제가 한 PR에 많은 코드양과 적은 코드 리뷰 시간라면 해결법은 간단하다. 

PR에 대한 코드 양을 줄이고 절대적은 코드 리뷰 시간을 확보하면 된다.

 

그래서 우리팀에 "작은 PR원칙" 을 제안했다.

 

이는 내가 만든 방법론이 아니라 이미 많은 개발팀이 사용하고 있는 방법론이다.

 

---

 

작은 PR원칙이란 ? 

한 번에 많은 코드를 리뷰하기 힘드므로 리뷰어를 위해 작은 단위로 PR하자는 약속이다.

세부적인 내용으로는 아래와 같이 두었다.

• 1개의 PR은 1000줄을 넘길 수 없다
• 티켓의 subtask를 최대한 나눠서 PullRequest, Commit의 단위는 최소의 기능 단위로 세분화한다
• 퍼블리싱 및 테스트 코드는 Mock json 이 라인 수의 대부분을 차지하므로 제한을 두지 않는다.

 

이전

이전에는 팝업관리에 대한 모든 작업은 DH-718이라는 브랜치 하나에 모두 담았다.

이렇게 되면 DH-718 브랜치의 PR은 그 양이 얼마나 많겠는가. 

 

변경

 

위 작업은 내가 한 작업 중 추천퀴즈 프로젝트 였는데 기능 혹은 페이지 단위로 정말 잘게 쪼개서 브랜치 및 PR을 구분하고자 했다.

결과

한 작업을 기능 및 페이지 단위로 잘게 쪼개서 PR의 양이 엄청 많다.

 

PR의 빈도는 늘어났지만 한 번 볼때 리뷰하기 부담스럽지 않은 코드양이기 때문에 자연스럽게 리뷰어가 더 꼼꼼히 볼 수 있게 됐다. 

또한 배포 전에 지속적으로 PR을 날려 해당 프로젝트에 대한 이해도를 리뷰어들도 가지게 됐고 이전처럼 쫓기면서 리뷰하는 문제를 없앨 수 있게 됐다. 

 

팀원의 회고 중

 

물론 PR의 양이 늘어나고 브랜치를 합치는 과정이 조금 번거롭지만 장점이 단점을 상쇄할 정도로 좋다는 평가를 받았다.

개발팀의 체계를 만드는 데 조금이나마 일조한 것 같아 기분이 좋다.