다음 중 코드 리뷰를 하는 이유에 해당하는 것을 모두 고른다면?
① 오류를 줄이기 위해서
② 개발 속도를 높이기 위해서
③ 팀원의 성장을 돕기 위해서
① ② 이유가 크다. ③을 가장 최우선 목적에 두고 코드 리뷰를 하지는 않는다. 부수적 효과에 가깝다.
① 오류를 줄이기 위해서
이 이유가 가장 크다. 꽤 큰 스타트업이라면 이미 사용자가 많다. 아주 사소한 실수로 서비스 장애가 발생할 수도 있다. 이 장애로 인한 손실도 크다. 시간이 들더라도 당연히 미리 점검하는 게 더 이익이다. 코드 리뷰를 통해서 주로 장애 발생 가능성을 살펴보게 된다. 그래서 코드 리뷰 시 단골 사항이 데이터베이스 부하 관련, 메모리 부하 관련, 예외 처리 등이 된다.
② 개발의 속도를 높이기 위해서
단기적으로 코드 리뷰를 하면 개발 속도가 느려진다. 하지만 장기적으로는 빨라진다.
큰 개발팀에서는 필연적으로 여러 명이 작업하게 된다. 학교 다닐 때 팀 프로젝트와 비슷한 상황이다. 보고서를 작성하는데 모두 각자의 문체로 작성할 수는 없다. 누구는 요약체로 적고, 누구는 존댓말을 써서 적은 걸 단순 합쳐 놓았다고 생각해보자. 시간이 지나서 그 보고서를 읽을 때 빠른 속도로 읽을 수 없게 된다. 코드도 마찬가지다. 코드도 언어가 프로그래밍 언어일 뿐 글이다. 누구는 탭 띄어쓰기를 3칸으로 하고, 누구는 2칸으로 한다면? 가독성이 떨어지게 된다. 그래서 개발팀에서 코딩 컨벤션부터 정하게 되는 거다. 구현 방식에 대한 통일도 그래서 필요하다. 테스트 코드를 짜든, 기본 API를 구현하든 누구는 A, 누구는 B방식으로 각각 제각각이라면 나중에 파악할 때 시간이 오래 걸린다.
③ 팀원의 성장을 돕기 위해서
① ②를 위해서 코드 리뷰를 하게 되면 자연스럽게 팀원들의 실력이 올라오게 된다. 다른 사람들의 리뷰를 통해서 한번 더 생각하고, 어떤 코드가 더 바람직할지 고민하게 되기 때문이다.
왜 작은 스타트업에서는 코드 리뷰를 하지 않을까?
작은 스타트업이라면 백엔드 1명, 웹 1명, 앱 2명(iOS, Android) 형태로 구성될 수 있다. 각자 코드를 다른 사람과 공유하지 않는다. 혼자 글을 쓰는 격이니 리뷰가 필요 없다. 약간 더 커져서 백엔드가 2명이 되었다고 해도, 코딩 컨벤션 정도만 정하고 나머지는 각자 알아서 하게 된다. 사용자가 별로 없는 상황에서는 장애가 발생해도 그때가서 대처해도 되기 때문이다. 작은 스타트업은 장기적인 개발 속도가 중요하지 않다. 단기적 개발 속도가 중요하다. 언제 망할지 모르는 상황에서 가장 중요한 것은 코드 품질이 아니라 코드 생산성이기 때문이다. 품질을 약간 포기하더라도 속도를 얻는 게 더 중요하다.
코드 리뷰를 받고 싶다면?
코드 리뷰를 통해서 개발자로 성장하고 싶다면, 얼른 실력을 쌓아서 큰 개발팀이 있는 회사로 이직을 하면 된다. 큰 개발팀이 있는 회사는 코드 리뷰를 할 수밖에 없으니까.
당장 이직이 어렵다면 내가 사용하는 프레임워크를 쓴 깃허브 공개 저장소를 찾아 코드를 읽고 따라 쓰자. 많이 읽으면 도움이 된다.