PR / 코드 리뷰는 어떻게 하는게 좋을까?

PR / 코드 리뷰는 어떻게 하는 게 좋을까?

현재 회사에서 근무를 한지 어느새 만 4년을 채우고도 몇 개월이 넘어가고 있는 이 시점에도 늘 고민하고 있는 주제입니다. 짧다면 짧고 길다면 긴 프로젝트를 진행해오며 어떻게 코드 리뷰를 정착시켰고 현재는 어떤 노력들을 하고 있는지 기록해 보고자 글을 작성하게 되었습니다.

---

2017

17년도 쯔음.. 프로젝트 초기에는 코드 리뷰를 진행하지 않았습니다. 1개의 프로젝트에서 1명~2명 이내의 개발자가 협업을 했고 추가되는 피쳐들이 작았던 것 때문인지 서로의 작업 내역을 대략적으로 파악하고 있었고 별다른 문제가 생기거나 느끼지 못했습니다. (생각해보니 코드 리뷰라는것이 있다는 걸 인지하고 있지도 못했던 것 같습니다.) 그저.. 서로의 브랜치를 merge 하는것이 전부였습니다.

2018

18년도에 들어서며 회사는 빠르게 성장하기 시작했습니다. 그에 맞춰 팀원과 프로젝트도 빠르게 늘어났습니다! 2개의 프로젝트를 3명, 1명이 나누어 진행하게 되었고, 프로젝트에 어떤 코드가 병합되고 있는지 점점 모르게 되는 순간이 오기 시작했습니다. 개발 세미나와 주변 동료 개발자분들을 통해 코드 리뷰 문화에 대해 접하게 되었고 필요성을 느끼게 되었습니다. 그 해 9월 그렇게 첫 코드 리뷰를 진행하게 되었습니다.

 

첫 코드리뷰!

처음으로 해본 PR(Pull Request) 기능입니다. 리뷰어도.. 설명도 없는 허전한 코드 리뷰네요. 주위에서 듣고 본 내용들로 git commit 메시지도 통일시켜보고 서로에게 용기를 주기 위해 LGTM(Looks Good To Me) 이라는 단어도 사용해본 시기입니다. 

 

2019-2020

그렇게 어설픈 리뷰를 진행하다가 19년도부터 GitFlow 전략을 도입하게 되면서 PR도 한걸음 더 나아가게 되었습니다. PR과 GitFlow가 무슨 관련이 있지?라고 생각이 되겠지만, 이제는 PR을 브랜치 따서 작업 후 PR요청이 아닌 기획/수정이 들어오는 요청 별로 feature를 나누기 시작했습니다. 조금 더 브랜치와 PR 단위에 대한 생각을 하게 되는 시기였습니다. GitFlow 전략에 대한 내용은 좋은 내용이 많아서 제가 참고했던 블로그 중 하나인 우아한형제들의 글 링크로 대체합니다.

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

프로젝트는 늘어났지만 개발자도 많이 늘어 여전히 프로젝트당 인원이 1-2명 정도 배치되어 있었습니다. 코드 리뷰를 하지 않던 때 보다 리뷰를 진행하니 확실히 서로의 코드를 보며 사전에 버그도 막을 수 있고 성장할 수 있는 계기가 되었던것 같습니다.

하지만, 문제점도 발견되었습니다. 프로젝트가 늘어났기 때문에 자신이 개발하지 않는 프로젝트의 코드는 볼 기회가 적었고 자연스레 A프로젝트 개발자, B프로젝트 개발자가 되어갔으며 각 프로젝트에서도 큰 기능들이 많이 들어가게 되면서 자신의 프로젝트에도 어떤 소스들이 들어가는지 놓치는 일들이 발생했습니다. ☠️

 

2021

부족하지만 저는 Android팀의 팀장이 되었고, 어느새 Android 팀원은 10명, 프로젝트는 5~6개를 진행하고 있게 되었습니다. 담당하고 있었던 프로젝트에서도 개발에 직접적인 참여는 조금 낮아지고 팀원이 개발해주는 큰 기능들이 더욱 빠르게 진행이 되고 있는 상황이었습니다. 또한 나만의 프로젝트가 아닌 여러 프로젝트들을 관리하게 되었습니다. 팀원들도 점차 코드 리뷰의 문제점들을 인지하였습니다. 좋은 방안을 찾기 위해 지금까지의 문제점들을 다시 짚어보고 개선하기 위해 좋은 코드 리뷰 문화를 가진 블로그와 유튜브를 많이 참고했습니다. 그중 몇 가지를 공유드립니다.

코드 리뷰 in 뱅크샐러드 개발 문화 | 뱅크샐러드

카카오스토리 팀의 코드 리뷰 도입 사례 - 코드 리뷰, 어디까지 해봤니?

크몽 FE 팀 코드리뷰문화 개선기(1+1=3)

각 회사마다 리뷰를 하는 방법들은 정말 다양했습니다. 좋은 꿀팁들중 현재 상황에 맞는 실행 가능한 작은 것들부터 팀원들과 함께 보완해나갔고 '실천-보완'을 반복하며 몇 가지 규칙을 세웠습니다. 지금까지 개선해온 규칙들은 다음과 같습니다. 

 

리뷰어 지정

앞으로 입사하시는분들은 어느 프로젝트를 누구에게 리뷰어로 지정해야 할지 모를 수 있기 때문에 리뷰어 선택에 관한 룰을 정리했습니다. 각 프로젝트당 필수 리뷰어가 존재하며 필요시 다른 프로젝트에 참여하고 있는 개발자도 리뷰어로 참여할 수 있습니다. 

리뷰어 지정 룰

Slack을 통한 추가 알림

Github에 PR을 생성하고 리뷰어를 지정하면 자동으로 메일이 발송되기는 합니다만 메일을 계속 보고 있지 않는 이상 빠른 피드백이 어렵다고 생각됩니다. 리뷰를 요청하는 개발자는 리뷰어 지정 룰을 참고하여 PR 생성 후 Slack 채널에 해당 개발자들을 태그 하여 노티합니다. (hook을 사용하여 자동화할 수도 있지만 봇이 하는건 잘 안 보는 경향이 있는 것 같습니다) 리뷰 댓글의 경우도 스레드로 알려주어 서로 빠른 커뮤니케이션을 할 수 있게 노력하고 있습니다.

Template

PR에 대한 설명이 부족하면 리뷰어 입장에서는 어디를 수정한것인지 한눈에 알기 어려워 내용을 이해하는 시간이 낭비되었습니다. 이 부분은 Github의 Template 기능을 사용해서 해결하였습니다. 리뷰 설명에 대한 내용을 통일하고 중점적으로 꼭 봐야 하는 곳은 요청 가능하도록 개선했습니다. 실제로 PR의 설명이 자세할수록 코드를 이해하는 속도는 빨라졌습니다. 항목은 두번 정도 수정이 되었는데 현재는 아래와 같이 사용하고 있습니다.

 

설명 : PR에 대한 대략적인 설명이 포함됩니다. 필요한 경우 스크린샷을 첨부하기도 합니다.

추가 및 수정 : 추가 또는 수정된 클래스를 적고 어떤 부분이 중점적으로 개발되었는지 간략하게 정리합니다.

이건 꼭 봐주세요! : 중요한 로직을 수정했거나 우려되는 부분들이 있다면 이곳에 메모를 남겨 중요하게 확인해줄것을 요청을 합니다.

현재 사용중인 Template

Github에서 Template 생성 방법은 아래 링크를 참고해주세요.

게으른 개발자 | 게으른 개발자

Label

코드리뷰를 요청하는 팀원들이 많아짐에 따라 PR 목록도 많아졌습니다. 리뷰를 진행 중인 PR.. 업데이트가 팬딩 되어 대기 중인 PR.. 등.. 각 PR들의 상태를 한눈에 알아보기 쉽도록 Label을 만들어 관리했습니다. Label의 종류는 6가지 정도로 시작했지만 현재는 아래 4가지만 사용하고 있습니다. 예를 들어 긴급 Label이 붙은 경우에는 최우선으로 검토를 요하는 리뷰입니다.

Label 4가지

Label을 활용한 PR 목록입니다. 여러가지 이슈들이 있지만 지금 스크린샷은 대부분 리뷰가 끝난 후 업데이트를 기다리면서 병합 대기 중인 PR 뿐이네요. 🤩

대기중..

Approve & 병합

코드 리뷰의 마지막은 병합이라고 생각합니다. 병합의 기준은 리뷰어로 지정된 모든 리뷰어(약 2~4명)가 Approve를 해야 병합이 가능했었으나 리뷰어가 많아질수록 모든 리뷰어에게 Approve를 받으려니 병합이 늦어지는 경우가 생겼습니다. 

병합이 늦어지는것은 곧 일정 병목을 발생시켰습니다. 문제를 해결하기 위해 최소 리뷰어 1명에게만 통과를 받으면 병합이 가능하도록 개선했습니다. 단, 리뷰이가 판단하기에 해당 PR을 꼭 봐주어야 하는 리뷰어가 있다면 꼭 리뷰를 진행해 주어야 합니다.

최소 리뷰어 1명 룰을 만들었지만 서로가 최대한 리뷰를 빨리 진행해주려고 하기 때문에 긴급한 경우를 제외하면 대부분 절반 이상의 리뷰어가 확인하는 경우가 많았습니다.

느슨한 정책

약간의 느슨한 정책들도 가지고 있습니다. 리뷰하기 마땅치 않은 수정 건에 대해서는 PR을 올려 진행한다면 서로가 피로가 누적될 수 있다고 생각했습니다. 해당 건들은 리뷰를 진행하지 않고 develop 브랜치에 바로 푸시한 후 Slack을 통해 관련 개발자들에게 "푸시한 거 한번 봐주세요~" 정도로 간단하게 마칩니다. 정말 간단한 변수 재설정이나 상수값 변경, 주석 삭제 등.. 정도가 해당됩니다.

 

마치며..

주절주절 정리해본 글이 눈에 잘 들어오는지 모르겠습니다. 안전한 코드리뷰를 위해 빈 땅부터 나름 열심히 개선해 왔다고 생각됩니다. 하지만 아직 여러 문제점들을 겪고 있습니다.

바로 직면해 있는 문제로는 PR단위의 부담입니다. 현재 PR단위는 한 개의 기능 브랜치를 기준으로 올리고 있습니다. 한 개의 기능 브랜치가 크면 클수록 한 번에 리뷰어가 감당해야 하는 리뷰의 양이 많아지고(300개 이상의 파일을 보는 경우도..) 해당 코드를 검토하는 데에 있어 집중도가 매우 떨어지게 되는 문제가 있습니다. 이 문제는 코드 리뷰를 진행했음에도 버그를 사전에 찾지 못하는 케이스를 발생시키기도 했습니다. 이 문제를 해결하기 위해 브랜치에 서브 브랜치를 사용하여 PR을 잘게 쪼개는 연습을 진행하고 있습니다. 잘게 쪼개는 것이 막상 개발 및 PR을 진행하면 코드 겹침이나 어떤 단위까지 PR을 올려야 하는가 등.. 여러 가지 이슈가 발생합니다. 그저 쉬운 일은 아니기 때문에 천천히 적응하며 진행해야 할 것 같습니다.

 

확실히 코드리뷰를 진행하는것은 코드의 품질뿐아니라 개발자의 실력 향상에도 도움을 주는것 같습니다. 개선해야할 점들이 많고 어려운 부분이지만 앞으로도 좋은 코드리뷰를 만들어 나가기 위해 노력하고자 합니다.