지속가능한 SW 개발을 위한 코드리뷰

이번 포스팅은 지난 4월 27일에 우아한테크세미나에서 진행했던 백명석 연사님의 <지속 가능한 SW 개발을 위한 코드 리뷰> 영상을 보고 내용을 정리해보고 싶어 적게 되었습니다. 영상의 내용에는 왜 코드 리뷰가 필요한 지부터 시작하여 실질적인 코드 리뷰 절차와 팁들에 대해 다루고 있지만, 제 포스팅에서는 실질적인 리뷰 절차와 기법들에 대해서만 간단히 정리하도록 하겠습니다. 자세한 내용은 아래 링크의 영상을 참고하시면 좋을 것 같네요!

코드 리뷰 절차

코드 리뷰는 저자, 리뷰어, 변경 내역으로 구성되어 있다. 우선 저자의 경우 코드의 작성자로써 자신이 작업한 코드 변경 내역을 리뷰어들에게 리뷰를 요청하게 된다. 리뷰어는 저자로부터 받은 변경 내역을 확인하여 코드를 읽고 병합(merge) 요청을 받아들일지 결정하게 된다. 변경 내역의 경우 리뷰 시작 전에 저자가 리뷰어들에게 리뷰를 요청 하기 위해 작성하게 되는데, 병합을 원하는 소스 코드에 대해서 일련의 변경 사항들에 대해 미리 작성해야 한다.

코드 리뷰의 기법들

코드 리뷰를 하기 위한 기법들은 다양한 것들이 있다. 동료와 짝을 이뤄 한명은 손으로 코딩을 하고, 나머지 한 명은 입으로 코딩하는(?) 페어 코딩, Github(또는 Gitlab)의 Pull Request(PR)이나 Merge Request(MR) 시스템을 활용한 리뷰가 가장 많이 언급되는 코드 리뷰 방법일 것이다. 이번 세미나에서는 PR을 활용하는 방법과 리뷰를 효율적으로 하기 위한 벙법에 대해 중점적으로 다루었다.

효율적인 Pull Request 방법

우선 PR은 오픈소스 개발과정에서도 자주 활용되는 방법이다. 오픈소스의 Git 저장소의 내용을 내 컴퓨터의 로컬 환경으로 복제(Clone) 해 와서 일부 수정하여 공유하고 싶다면, 해당 오픈소스 git 저장소의 관리자에게 내 저장소의 변경 사항들을 원본 저장소로 당겨(Pull) 달라 요청하는 것을 PR이라고 한다.

PR 과정을 효율적으로 하기 위해선 단순 반복되는 지루한 작업은 먼저 컴퓨터로 처리를 한 다음 리뷰 요청을 해야 한다. 리뷰 과정에서 띄어쓰기, 한 줄당 코드 길이 제한, 변수 이름 규칙 등과 같은 포맷에 대한 내용과 같이 가독성을 높이기 위해서 필요하긴 하지만, 실제 성능에는 크게 영향이 없어 중요도는 떨어지는 반복 작업들은 다양한 방법을 통해 자동화를 함으로써 해결할 수 있다. Visual studio를 활용해 C/C++를 개발한다면 clang-format을 사용하여 자동으로 포맷을 맞출 수 도 있고, 코딩 스타일 가이드를 위해 linter를 적용한다면 가이드를 위반한 내용에 대해서 IDE는 경고를 띄울 것이다(여기서 IDE에 모든 경고를 에러로 변환 속성을 추가한다면, 모든 가이드를 고치기 전에는 절대 사용할 수 없도록 강제할 수도 있다.) 또한 git의 pre-commit이나 hook을 추가하여 반복적인 지루한 작업들의 상당수는 선제적으로 제거할 수 있다.

다음으로 실제 PR을 보내기 전에 마지막으로 준비해야 하는 것은, 저자가 직접 자신의 코드의 변경점들을 확인하고 리뷰어가 확인해주었으면 하는 내용들을 미리 코멘트로 달아 놓는 것이다. 코드 리뷰 과정에서 한명의 저자가 여러 리뷰어에게 요청을 하는 것이므로, 여러 사람들의 시간을 절약해 주기 위해서 본인이 1차적인 검수를 먼저 거치는 것이 효율적이다.

효율적인 리뷰 방법

효율적인 리뷰를 위해 가장 먼저 생각해볼 것은 왜 코드 리뷰를 하려고 하지 않는 지에 대한 것이다. 실제로 현재 재직 중인 회사에서 몇몇 분들과 이야기를 나누었을 때, 코드 리뷰에 대한 생각은 대체로 '할 수 있다면 좋겠지만, 너무 바빠서 할 수가 없네.'였다.  이를 해결하기 위해선 PR의 검토해야 할 양을 최소화하고, 리뷰 또한 최대한 간단하게 해서 지나갈 수 있어야 한다. 또한 리뷰 과정에서 소요되는 시간을 최소화하기 위해선 코드 리뷰를 업무 중에서 높은 우선순위로 놓고 최대한 빠르게 진행해야 한다.

리뷰하는 순서 또한 중요하다. 한번에 많은 양의 코멘트를 남기려 노력하지 말아야 한다(세미나에서는 20 ~ 50개의 의견은 저자에게 부담스러울 수도 있다고 한다.) 리뷰 과정을 몇 가지 단계로 나누어 처음에는 고수준으로 시작하여 버그, 장애, 성능, 보안 등의 큼직한 이슈를 먼저 다루고 나서 점차 저수준으로 내려가야 한다고 한다. 다음으로는 모든 코드를 최선을 다해 수정하려 노력하기 보다는 한 단계만 더 나아질 수 있도록 해야 한다. 모든 코드가 최상의 상태이면 당연히 좋겠지만, 장시간에 걸쳐 이루어지는 개발 과정에 있어서 뛰어난 리뷰어 입장에서는 코드가 불만족스러울지라도 단계적으로 코드의 성장과 함께 다른 개발자들도 성장해 나갈 수 있는 편이 더 좋다. 만약 저자가 신입 개발자 거나, 잘 모르는 분야에 대한 코드를 담당했다면 리뷰어는 간단한 예제 코드를 선물로 주는 것도 아주 좋은 방법이다(단 너무 많은 예제 코드는 오히려 부담스러울 수 있다.)

이렇게 좋은 코드 리뷰는 왜 우리가 적용하기 어려운가?

코드 리뷰를 포함해 새로운 프로세스를 회사에 적용하기 위해서는 필연적으로 손실을 감수해야 한다. 구성원들이 새로운 프로세스에 적응해가는 과정에서 이전보다 생산성이 떨어질 수 밖에 없다. 아래 리뷰에 나온 것처럼 도입 초반에는 생산성이 잠시 증가하는 것처럼 보이다가, 이후에는 고통의 계속 속에 빠지게 된다. 이 계곡 속에 갇혀 포기하게 된다면 '역시 이런 프로세스는 필요 없는 것이었네'가 되는 것이고, 만약 탈출한다면 '역시 도입하길 잘했네!'가 되는 것이다.

만약 본인의 조직에서 코드 리뷰를 하지 않는다면, 고통의 계곡을 감내하며 꼭 도입하는 것을 추천한다. 우선 코드 리뷰는 실력이 떨어지는 개발자의 실수를 능력있는 개발자가 뒤처리 해주는 것이 아니다. 코드 리뷰 과정에 참여하는 모든 개발자들은 자기가 알지 못했던 새로운 사실을 알아갈 수 있고, 이미 알고 있던 내용을 다시 한번 정리하는 기회가 될 수도 있고, 사람과 사람의 소통을 통해 더 많은 관계를 쌓아갈 수도 있기 때문에 모두를 위해 도입해야 한다.