코드 리뷰에 어려움을 느끼는 이유는 무엇일까?

개발자라면 누구나 한번쯤 ‘코드 리뷰’에 대한 내용을 접해봤을 것이며, 이미 다수의 개발자들은 ‘코드 리뷰’가 하나의 필수적인 요소라고 강조하기도 한다.

하지만 많은 조직들이 ‘코드 리뷰 문화’의 도입 제안 또는 도입을 수긍하는 과정에서는 다소 막연한 어려움이 느낀다.

실제로도 성공적으로 코드 리뷰 문화를 도입한 조직들 또한 여러 차례의 시도와 실패를 경험한 뒤 어렵게 도입에 성공했음을 알 수 있다.

과연 어떤 요소들이 해당 문화를 도입하는데에 어려움을 주는 것일까? 그리고 어떤 방법으로 이를 보다 쉽게 해결할 수 있을까?

1. 내 코드를 리뷰받는 것에 대한 두려움

주니어 개발자 및 시니어 개발자 모두가 어려워하는 요인 중에 하나다.

지금까지 본인이 개발한 소스 코드를 타인에게 공개, 소개하는 일을 경험해보지 않은 개발자들이 주로 두려움을 느끼는 부분으로 '내가 작성한 소스가 후배들에게 보여줄만한 소스인가?' 또는 '시니어 개발자에게 보여주기에는 아직 내가 작성한 코드에 대한 확신이 없다.'라고 느낀다고 한다.

하지만 코드 리뷰를 도입함으로써 아래와 같은 긍정적인 수확이 가능하기에 두려움을 갖기보다는 내가 이후에 개발자로써 얻어갈 수 있는 부분들을 생각하는 것이 중요하다.

1. 주니어 개발자는 자연스러운 질문의 기회와 실전에서 사용되는 실전형 로직을 얻을 수 있고, 시니어 개발자는 자연스러운 교육이 가능하고 새로운 접근 방식과 기발한 아이디어를 얻을 수 있다.
2. 타인과 소스를 공유, 리뷰하는 과정에서 점점 모두가 개발 표준을 준수하게 된다.
3. 내가 지금껏 하던 코딩 방식이 타인이 봤을 때도 끄덕일 수 있는 부분인지 점검할 수 있고, 혹시나 지금까지 잘못 알고 있는 부분은 없었는지 배울 수 있다.
4. 내가 작성한 소스, 로직에 대해 설명할 수 있는 실력이 성장하고, 타인에게 피드백을 주거나 받는 부분에서 좀 더 유연한 사고가 가능해진다. 커뮤니케이션 능력 또한 이제는 개발자의 역량이다.
5. 배포 전 버그의 조기 발견이 가능해지기에 나중에 발생할 버그로 인해 발생하는 비용보다는 코드 리뷰로 인해 발생하는 비용이 더 적을 것이다.

2. 일하는 시간을 빼앗긴다.

하나의 영역에 몰두해서 방해받지 않고 개발을 진행하고 싶을 때는 분명히 있을 것이다. 이 과정에서 코드 리뷰의 개입으로 인해 흐름이 끊긴다면 업무 효율성이 떨어진다고 생각하기 쉽다.

또한 '코드 리뷰를 할 시간에 한 줄이라도 더 작성하는 게 낫겠다..' 라고 생각하는 개발자들 또한 많다.

하지만 이는 막연히 생산성 측면에서만 바라본 시점이라고 생각한다.

그렇지만 문화라는 것은 구성원들이 함께 적극적으로 참여해야 도입이 가능하고 의미가 있는 것, 코드 리뷰의 장점과 필요성에는 공감하지만 시간 할애를 하는데에 있어 거부감을 느끼는 개발자들에게는 어떤 방법들을 제안하는 것이 좋을까?

1. 점심 식사 이후, 커피를 마시고 난 이후등 업무에 몰두하는 시간보다는 잠깐 쉬어가는 시간을 활용하여 코드 리뷰를 진행하기를 추천한다. 반드시 업무 중간에 끼어들 필요는 없다는 뜻이다.
2. 한번에 리뷰 받는 코드는 500줄 이하가 적당하다. 코드가 길어지면 리뷰어들이 시간을 할애하기에 거부감을 느낄 수 있고 그만큼 집중해서 이슈 제기를 받을 수 있는 소스 코드 또한 줄어들기 때문이다.
3. 하나의 리뷰에 적당한 리뷰어 수는 3~4명이다.

3. 의사 소통 중 생기는 마찰

코드 리뷰 또한 피드백을 위한 하나의 커뮤니케이션 수단 중 하나이다.

의사 소통 중 감정이 상하여 제 2의 문제가 발생하지 않도록 상대방을 존중하고 배려하는 느낌의 댓글을 남기는 것 또한 중요하다.

1. LGTM (Looks Good To Me, 나에게는 좋아보인다), NIT: (Nitpick, 필수적으로 수정할 필요는 없다) 식의 확실한 의사 표현을 나타내자.
2. 의도하진 않았지만 코멘트로는 표정, 억양, 상황, 기분을 알 수 없다. 최대한 친절하고 구체적으로 코멘트를 남기자.
3. '내 의견은 이런데 어떻게 생각하시나요?' 와 같은 제안하는 방식의 말투를 선호하자.
4. 불필요한 마찰은 피하자 (if문 vs switch문, 변경하기에 애매한 변수명 제안)

일단 시작해보자!

모두가 각자 다른 상황을 갖고 있기에 정답이라고 정해진 하나의 방법은 없다.

하지만 구성원들과 계속해서 소통하고 점점 다듬어가면 언젠가는 그 조직에 맞는 문화로 거듭나있으리라 생각한다.

그래도 막연하게 시작하기에 어려움이 있다면 아래에 필자가 작성한 가이드를 추가로 참고해보자.

1. 코드 리뷰 없이는 배포가 불가능한 환경 조성하자
2. 도입 초반, 쌓여가는 노하우와 경험을 공유하는 시간을 주기적으로 갖는다.
3. 리뷰를 요청하는 Request 본문에는 해당 소스의 상세한 설명, 리뷰 중점을 작성하고 반드시 원하는 리뷰어를 태깅하자.
4. 코드 리뷰 툴을 적극 활용하자 (github, gitlab request 등)
5. 코드 리뷰로 인한 배포 병목 현상이 발생한다면 어떤 방식으로 해결할지 논해보자.

마무리

어떠한 문화라도 강제성만으로 문화를 도입하고자하면 꾀를 부리기 쉽고, 충분한 어필 없이 문화를 도입하고자 하면 그 문화는 점차 희미해져 사라진다. 문화에 참여시키고자 하는 구성원들에게 충분히 어필하여 그 필요성을 스스로 느끼게 하는 방법이 제일 좋다고 필자는 생각한다.

끝