코드리뷰는 왜 필요한가?

내 이력서는 아래 문장으로 시작한다.

Seed 직후 1인 개발자로 합류한 스타트업에서 Series B 라운드까지 함께하며 개발팀을 리딩한 경험이 있습니다.

그래서 그 때의 경험들을 기록해보면 어떨까라는 생각이 들었다. 처음은 코드리뷰이다. 코드리뷰의 필요성을 처음 느꼈던 것은, 레포에 개인의 습관에서 비롯된 다양한 코드들이 등장하기 시작했기 때문이다.

기본적으로는

1. 변수를 선언할 때 규칙이 다르거나
2. 상대적으로 비효율적인 코드들이 보이기 시작했다.

혼자 개발하면서도 git flow를 유지하면서 개발 중이었는데, 새로 합류하시는 분들에게도 develop에 merge할 수 있는 권한이 있다보니 레포가 조금씩 일관성 없는 코드로 채워지기 시작했다. 당시 나는 개발 + CS를 담당하고 있어서, 매주 사용자 피드백도 같이 받고 있던 상황이기 때문에 바쁘다는 핑계로 그냥 두고 있었다. 하지만 앞으로 점점 개발팀이 커지면 문제가 될 수 있을 것 같아서 CTO님과 다른 개발자분들에게 코드리뷰를 제안했다.

1. 서로 코드를 봐주고
2. 이해가 안되는 부분은 질문하고
3. 고칠 수 있는 점들이 발견되면 제안하자

3가지 이유였다.

코드리뷰는 내가 작성한 코드를 다른사람에게 검사받는 시간이 아니라, 최선의 코드를 작성하기 위한 공동의 노력이다. 코드리뷰를 통해서 다른 개발자들과 소통할 수 있고, 생각하지 못했던 방식들을 배울 수도 있고, 더 좋은 프로젝트를 만들 수 있다. 이 부분은 동의하지 않는 분들도 있겠지만, 코드리뷰를 하게되면 누군가에게 보여주는 코드가 되기 때문에, 더 좋은 코드를 작성하기 위해 노력해야 겠다는 심리적 효과가 있다.

일반적으로 코드리뷰를 떠올리면 생각나는 이미지는 아마 아래 스크린샷일 것 같다. 사실 비개발자에게 코드리뷰를 설명할 때 결재 받는거라고 생각하면 된다고 하기 때문에, 단순하게 리뷰하는 사람의 마음에 들 때까지 수정할 부분을 언급하는 것이라고 생각할 수 있다. 고칠 수 있는 점을 제안하는 것은 아래처럼 할 수 있다.

하지만 코드리뷰는 결재가 아니라 최선의 코드를 작성하기 위한 공동의 노력이다. 따라서 리뷰 comment들이 항상 부정적(?)인 것은 아니다. 고칠 부분이 보인다면 왜 고쳐야 하는지 설명하고 수정을 요청하면 되고, 잘 작성된 코드는 아래처럼 칭찬도 할 수 있다. 그리고 다른 개발자가 작성한 좋은 코드를 보고 나도 성장할 수 있다.

또한 소통의 과정이기 때문에, 이해가 잘 안되는 부분은 PR author에게 질문한다.

의도가 불분명하다면 개선할 부분이 있다는 것이기 때문에, 코드를 작성한 사람에게도 도움이 된다.

위에 언급한 방식으로 코드리뷰를 하니, 비효율 적인 코드는 상당수 개선할 수 있었다. 하지만 변수를 선언하는 방식이 다르거나, package import 순서가 다르다거나, 함수의 위치가 달라서 코드 파악이 어려운 문제는 아직 남아있었다. 그래서 컨벤션을 작성하기로 했다.

돌아가기만 하면 되는데 변수명이 뭐가 그렇게 중요하냐고 생각할 수 있지만, 일관성 있는 코드는 가독성에 유리하다. 우리는 팀으로 일을 하기 때문에, 필연적으로 다른 사람이 작성한 코드를 보면서 작업한다. 또한 내가 작성 한 코드에서 발생한 문제를 다른 개발자가 해결해야 하는 경우도 있는데, 이 경우에 코딩 컨벤션이 지켜진다면 많은 시간을 아낄 수 있다.

백엔드는 당시 Django를 사용해서, 파이썬 변수명에 대한 코딩 컨벤션을 만들었다. PEP8 규칙을 따르려고 노력했고, 노션으로 공유한 문서에 팀원들 피드백을 받아서 우리 팀만의 파이썬 컨벤션을 작성했다. 엔드포인트에 다양한 method들을 작성할 수 있으면 Class-Based View를 사용하고, 하나의 method만 작성할 경우에 Function-Based View를 사용하기로 했다. 아! 그리고 파이썬 코드는 align 해야한다. 어쩌면 우리 모두가 vim을 사용해서 가능했던걸지도? 라고 생각했는데 VSCode를 비롯한 다른 IDE도 해당 기능을 지원하는 것 같다.

프런트엔드는 조금 복잡했다. React와 React Native를 사용했는데, 타입스크립트 컨벤션, 리액트 컨벤션, 그리고 eslint, prettier 규칙까지 정해야했다. 기본적으로는 airbnb에서 추천하는 방식을 따르고, 컴포넌트 내 함수와 hook들의 위치. import 순서, eslint 규칙들을 모든 프런트엔드 개발자들이 모여서 결정했다. 예전에 발표자료에서 보니 토스는 토스 린트가 있어서 컨벤션을 지켜주던데, 가능하다면 같은 기능을 하는 자체 모듈을 개발하고싶다. 프론트엔드는 대부분 VSCode로 개발하니, 작업 내용을 저장하면 자동으로 팀에서 정한 컨벤션대로 코드를 변경해주는 것이다. import같은 경우는 sort-imports 라는 eslint 규칙이 있는데, 함수명 등도 알파벳 순으로 정렬되면 좋겠다.

기능만 잘 작동하면 되는데 왜 굳이 코드리뷰를 해서 시간을 낭비하느냐고 생각할 수도 있다. 리뷰를 하게되면 데드라인이 금요일까지라면 목요일까지는 완성해야 리뷰를 반영해서 해당 feature를 완성할 수 있다. QA, bug fix까지 고려하면 사실 더 빨리 끝내야한다. 바쁜데 리뷰까지 하라고? 라는 생각을 할 수도 있다.

하지만 코드리뷰는 시간을 낭비하는 것이 아니라 아끼는 방법이다. 내가 놓쳤던 부분을 다른 개발자가 확인해서 에러를 미연에 방지할 수 있다. 코드 효율이 개선되면 사용자들의 시간을 아낄 수 있고, 컨벤션을 통해서 규칙적인 코드를 작성한다면, 내가 작성한 코드를 다른사람도 쉽게 이해할 수 있다. 그리고 그동안은 주석 없이도 이해할 수 있는 코드가 좋은 코드다라고 생각해서 주석은 제거하자는 생각이었는데, 팀이 커지고 프로젝트 규모가 커지면서 주석도 잘 활용하면 좋겠다는 생각이 든다. 그리고 MITOpenCourseware에서 강의를 종종 듣는데, MIT 교수님도 주석을 권장하시더라.

2월에 이직을 했는데, 지금 팀에는 아직 컨벤션도 리뷰하는 문화도 없다. 다행히 같이 입사한 다른 개발자 분과는 서로 리뷰를 하는 중인데, 기존에 있던 분들은 아직 리뷰를 시도하지 못해서 어느정도 지금 프로젝트가 안정기에 돌입하면 코드리뷰 문화를 전파할 계획이다. 이곳에서도 예전에 했던것처럼 잘 이루어질 수 있었으면 좋겠다.