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

안녕하세요! 오늘은 코드 리뷰에 관한 이야기를 간단히 해보려고 합니다. 코드 리뷰는 말 그대로 코드를 리뷰(Code Review) 하는 행위를 말합니다. 코드 리뷰는 좋은 개발 문화 중에 하나로 인식되고 있습니다. 하지만 그저 코드를 리뷰한다고 좋은 개발 문화가 이루어지지는 않을 것입니다. 리뷰를 어떻게 하느냐와 왜 하느냐가 중요한 안건이 될 수도 있는 것이지요. 또, 바쁜 업무 와중에 코드를 리뷰한답시고 회사에 근무하고 있는 모든 개발자들을 불러다가 코드 리뷰를 강제로 참석하게 하는 것은 회사 입장에서도 꽤나 큰 업무 시간의 Loss가 발생할 수 있는 요지가 있습니다. 이번 글에서는 코드 리뷰를 왜 하는지와, 어떻게 해야 코드 리뷰가 좋은지 작성해보고자 합니다.

가장 먼저 코드 리뷰의 목적에 대해 알아보겠습니다.

---

목적

버스 팩터 (Bus Factor) 

버스 팩터라는 용어는 다소 생소하실 수도 있습니다. 팀원 중 한명이 다른 팀원이 버스를 직접 몰고 운행하다가 버스에 치여서 큰 부상을 입거나 사망하는 경우 프로젝트가 망할 수 있는 가능성에 대한 지수를 의미합니다. 이 지수는 프로젝트가 내포하고 있는 리스크와도 직결되고, 지수가 낮다는 것은 프로젝트가 한 사람에게 집중되어 있고, 그 맥락이 팀원 한명에 의해 좌지우지되어 정보가 제대로 공유되지 않고 언밸런스한 것을 의미하기도 합니다. 

그렇다면 코드 리뷰를 통해서 코드를 살펴보면 어느 한 명에게 중심이 쏠리게 되는 것을 방지할 수 있을까요? '단편적인 코드 리뷰' 만으로는 사실 프로젝트의 모든 정보를 파악하는 것은 한계가 존재합니다. 되려 버스 팩터 지수를 높이기 위해선 지속적으로 작업이 진행되는 과정에 대해 공유하고 알려주며 속도를 맞추어 서로가 같이 평행하게 나갈 수 있도록 지켜주는 것이 더 좋을 것입니다. 

논 버그 프로덕션 (Non-Bug Production)

리뷰를 통해 버그를 차단할 수 있지만, 코드 리뷰를 하면서 발생하는 버그를 잡을 확률보다 런타임(즉, 가동중인 프로그램)에서 발생하는 에러들이 훨씬 많이 존재할 것입니다. 이러한 버그는 코드 리뷰 단계에서 파악하기가 어렵죠. 그리고 설령 버그를 모두 수정해서 올리는 것도 상당한 공수와 비용이 발생합니다. (인력을 비용이라고 가정하였을 때)

 

그렇다면 코드 리뷰를 진행하며 발생하는 부작용은 무엇이 있을까요?

가장 대표적으로 시간이 문제가 됩니다. 많은 사람들이 공동으로 코드를 확인하면서 드는 비용은 복구하기 어렵습니다. 그만큼의 퍼포먼스도 필요하고 앞으로 똑같은 실수를 번복하지 않기 위한 시간이 필요로 합니다. 그리고 좋은 코드 (다른 말로 클린 코드)를 만들기 위해서는 재사용성을 높이고 의존성을 낮추는 (응집도를 높이고 결합도를 낮추는 소프트웨어 공학적인 말) 방법이 가장 우선시되기에, 다른 사람이 작성한 코드를 재활용하여 나의 서비스 또는 개발 방법에 적용하는 것이 무엇보다도 중요합니다. 코드 리뷰는 그러한 장으로 주로 이루어져야 합니다. 

설령 이런 코드를 내가 공들여서 작성하였는데, 중복되거나 비슷한 코드가 다른 사람도 작성하였다면 서로 협의를 하여 코드를 하나로 통합하는 리팩터링 과정도 코드 리뷰를 하면서 발견할 수 있습니다. 하지만 그런 와중에 서로를 존중하며 책임 소재를 물으면 안될 것입니다. 

가끔 코드 리뷰를 진행하면서 서로가 자신의 코드 방식이 옳은 것 같아 다투게 되는 일도 종종 발생합니다. 아무래도 성인이기도 하거니와 자신의 경력이 무시당하는 것 같아 불의를 못참고 언성을 높이다가 감정 싸움으로까지 번질 수 있는 위험한 순간들이 종종 등장합니다. 하지만 모든 코드에 정답은 없습니다. 추천하는 방법은 존재하겠죠. 그리고 아무래도 개발자들은 주로 컴퓨터로 채팅을 하면서 대화를 하는 것이 주 업무이다 보니 커뮤니케이션 스킬이 부족할 수 있고, 공격적으로 발언을 할 수도 있다고 생각합니다. 말투를 바꾸더라도 상처가 될 수 있고, 리뷰를 받는 사람이 리뷰를 자신에 대한 비난이라고 생각할 수도 있기 때문입니다. 

코드 리뷰는 병목이 될 수도 있습니다. 하나의 프로젝트를 만들기 위해 두 사람이 하나의 브랜치에서 공동으로 작업을 진행하는 경우 이러한 일이 빈번하게 발생할 수 있습니다. 코드 푸시 후 충돌을 해소하기 위해 공수를 들여 다시 서로의 코드를 확인하고 그 합을 맞추는 것조차 벅찰 환경일 경우도 있습니다. 심지어 내가 작성한 결과물이 다른 사람이 임의로 엎어치기를 하여 코드가 증발한다면 거기서 오는 분노는 참기 어렵습니다. 말만 들어도 혼란스럽지만 실제로 이러한 일은 자주 발생하는 일 중 하나입니다. 그러면서 결과물을 다시 만들어내기 위해 바쁘게 개발을 진행하게 되면 안정성 부분에서 떨어질 수 있습니다. 

 

---

 

그럼 어떠한 방식으로 코드 리뷰를 진행할까요?

1. 레퍼런스를 찾아놓습니다.

코드 리뷰를 하기 전에 개발하게 된 블로그라던지 참고하게 된 레퍼런스를 적어놓습니다. 책이면 가지고 오지는 않아도 어떠한 문장이나 표현에 근거해 코드를 작성하였다고 하는 것이 나의 신뢰도를 더 쌓고 다른 개발자들이 같이 공감하고 볼 수 있는 방법이 가장 중요합니다. 그렇게 되면 자연스럽게 다툼이나 논쟁이 줄겠죠.

 

2. 공유하는 작업 공간에 대한 대비를 합니다.

소스 코드의 특성상 어느 부분의 영역에 도달하게 되면 다른 개발자와 작업 공간이 겹치게 될 수 있습니다. 이러한 부분을 최소화하기 위해 그 부분을 개발한 개발자와 같이 이야기를 나누고 커밋이나 푸시를 하기 전 (푸시해서 충돌이 된 것을 확인하기 전)에 한 번 검토하는 것이 필요합니다. 그리고 공동으로 개발을 하는 개발 브랜치에서는 주기적으로 pull 또는 fetch 를 받아 소스를 최신화합니다. 때에 따라 Pull Request 를 통해 공동 작업자에게 리뷰를 요청합니다. 

 

3. 작업 방향을 보다 명확하게 구분합니다.

기획 의도와는 다르게 개발이 되는 것을 방지하기 위해 명확하게 어떤 부분을 개발할지 주석을 달거나 메모를 하는 것을 습관화합니다. 코드를 바라보는 관점이 가장 중요하기 때문에 다른 사람이 개발을 한 소스 코드에 대해 궁금한 점이 있으면 자주 질문하고 또 그러한 질문을 받았을 때 왜 그렇게 작성을 했는지 더 상세히 작성합니다. 그리고 되도록 이러한 질문들을 하기 전 먼저 간단한 검색을 통해 찾아보며 정보를 얻는 것 또한 하나의 방법입니다.

 

4. 상관이 없더라도 들어보려 합니다. 

지금 당장 나와는 영향도가 없는 소스 코드일 수도 있습니다. 하지만 그 부분이 정작 필요할 때 이전에 설명해준 내용을 귀담아 듣지 않으면 이해하고 코드를 사용하기 어렵기 때문에 잘 듣고 모르는 부분이 있었다면 적어놓는 것이 중요합니다. 결국은 다른 사람이 설명할 때 경청할 수 있는 가장 중요한 요소인 서로를 배려할 수 있는 자세가 필요하겠죠.

 

다른 사람이 시간을 투자한 소스를 수정하는 것은 고쳐야 하는 입장에서는 어쩔 수 없이 수정을 해야 하지만 사실은 큰 실례를 범하게 되는 일입니다. 보다 높은 완성도와 퀄리티를 지닌 소스 코드를 개발하기 위해 같이 생각을 공유하고 이를 코드로 풀어내는 개발자들이 많지만 소스 코드를 리뷰하다가 되려 역행할 수 있는 위험이 있기 때문에 항상 조심하고 신중하게 생각을 해보는 것이 좋겠다는 것이 개인적인 의견입니다. 

다소 따분할 수도 있는 글이지만 읽어주셔서 감사합니다 :)