원더월 테크팀 코드리뷰의 역사

2023년 6월 29일

kimsg

#wonderwall
#fromm
#code review
#코드리뷰
#github
#codestream
#jira

들어가며

원더월 테크팀은 태초부터 현재까지 코드리뷰를 포함한 대부분의 업무에 있어서 하나의 방식으로 이어져 온 것이 없습니다.
항상 더 나은 방향과 방법이 있다고 생각되면, 새로운 것을 시도하고 변화하고를 반복 중 입니다.
코드리뷰도 마찬가지로 몇 년에 걸쳐 변화되어 왔으며, 앞으로도 많은 변화가 있겠지만 현재까지의 기록을 남겨보고 공유하고자 합니다.

태초

태초에 1인 개발 체계에서는 코드리뷰가 없었습니다.
혼자 코드를 다시 뜯어보거나 회고를 해보거나 할 수는 있었지만, 팀원이 없었으니 슬프지만 당연하게도 팀 코드리뷰는 할 수 없었습니다.

유년기 (시작)

두 명이 합류해, 팀이 세 명이 되었을 때 팀 코드리뷰를 시작했습니다.

당시에 빠르고 쉽게 사용할 만 한 코드리뷰 툴을 찾아다니던 중, New Relic CodeStream 이라는 오픈소스를 발견했습니다.
CodeStream은 VSCode 익스텐션, JetBrains 계열 IDE의 플러그인으로 제공되어 당시 팀원들의 모든 개발 환경에서 손쉽게 적용해 볼 수 있었습니다.

또한 IDE에서 바로 코드를 드래그해서 이슈를 남기고, 누군가 남긴 이슈를 클릭하면 바로 코드로 이동하는 등 다양한 편의 기능이 제공되고,
익스텐션 형태로 제공되어 IDE에 붙어있다보니 코딩중에도 알림을 놓치지 않고 받을 수 있어 빠른 업무 진행이 가능했습니다.

(출처: codestream.com)

성장기 (변화)

서비스가 2년차 정도 되고, 각 팀별로 2 ~ 3인 일 때 까지는 CodeStream으로 그럭저럭 버틸만 했습니다.

그런데 회사가 성장하며 서비스가 커지고 외부팀(기획, 운영, 디자인 등)과도 체계적으로 업무를 처리해야 할 필요성이 생겼고
테크팀 내부에서도 새로운 팀이 생기고, 팀원이 늘어나고, 업무가 복잡해지고, 히스토리가 쌓여감에 따라 변화가 필요해졌습니다.

외부팀과의 협업을 위해 Jira 를 도입하게 되었고, Jira 티켓과 GitHub 브랜치를 연결하게 하면서 이 시기에 맞춰 코드리뷰도 GitHub Pull Request(PR)로 옮기게 되었습니다.
시간이 지남에 따라 CodeStream 에서는 히스토리를 찾기가 어려웠고, 리뷰 후에 아카이브가 되긴했지만 팀내에선 휘발되는 느낌이 강했습니다.
(저희팀이 제대로 사용을 못했거나, 현재는 많이 개선되었을 수 도 있습니다.)
하지만 GitHub PR을 사용하게되면 코드와 리뷰가 한 곳에 응집되고, 시간이 지나고 새로운 팀원이 들어와도 히스토리 추적이 편해집니다.

GitHub 브랜치 사용 전략, Jira 사용 전략, 코드리뷰 규칙 등을 문서로 정립했고 모든 팀원이 같은 방식으로 리뷰하기 시작했습니다.
이 때 정말 많은 조사를 하고 다른 회사의 기술블로그를 보며 우리팀에 맞는 좋은 점들을 도입하려고 노력했습니다.

현재까지 사용 중인 몇 가지 코드리뷰 규칙을 소개하자면

300줄 이하의 변경에 대한 리뷰 요청을 권장합니다.

불가피한 경우를 제외하고는 최대한 300줄 이하로 리뷰를 요청하도록 권장하고 있습니다. 리뷰할 코드의 양이 많을 수록 시간이 오래걸리고 집중력이 떨어지며 코드리뷰 품질이 저하됩니다.

리뷰 요청자는 리뷰의 우선순위를 라벨로 표시합니다.

priority: hotfix

priority: high

priority: medium

priority: low

이 외에도 각 팀의 상황에 맞게 라벨을 추가하여 사용합니다.

리뷰 작성자는 리뷰 중요도(Wn)를 표시합니다.

W1 : 오류나 버그 등 꼭 반영해야하는 리뷰 (Request Changes)

W2 : 적극적으로 반영하길 바라는 리뷰 (Request Changes)

W3 : 웬만하면 반영하길 바라는 리뷰 (Comment)

W4 : 반영하지 않아도 괜찮은 리뷰 (Approve)

W5 : 사소한 의견 (Approve)