Purpose of Code Review

회사에서도 코드 리뷰(Code Review)를 강조하기 시작했다. 몇 년 전 부터 애자일(Agile) 바람이 불더니 코드 리뷰를 많이하는 사람에게상을 주기 시작했다. 역시나 본질을 왜곡했기 때문에 마음에 들지는 않지만 어쨌든 회사차원에서 코드 리뷰라는 단어에 관심을 가졌다는 것만으로도 무척 고무적인 일이었다.

회사에서는 애자일이 단지 빠른 주기로 개발 및 개선을 해서 결과를 만드는 것이라서 애자일 방법을 적용하기만 하면 모든 문제가 빠르게 해결될 것 이라고 오해하는 것처럼 보였다. '애자일을 적용하여 다음 번 모델의 출시일을 앞당기겠다.'라는 기사를 보면서 확실히 애자일에 대해 오해하고 있음을 알 수 있었다. 비슷하게 코드 리뷰도 그러한 오해를 받고있다. 코드 리뷰란 능력있는 직원이 능력없는 직원의 작업을 검토해서 제품의 품질을 높이고 출시일을 앞당기는 방법으로 생각하고 있다. 누가 그런 얼토당토않는 생각을 할까 의문이 들겠지만, 실제로 그렇게 생각하는 사람이 있었다. 월요일 오전 주간회의에서 어떤 사람이 다음과 같은 말을 했다. '애자일을 도입하면 각 직원의 실력이 모두에게 드러나기 때문에 오히려 (여러 분들에게) 나쁜 것 이라고 생각한다 (나는 상관없지만).' 이라고 자신의 생각을 이야기했다. 물론 괄호 안의 글은 그 분의 몸짓과 눈 빛, 그리고 말의 뉘앙스를 참고하여 덧붙였다.
 
그래서 매우 주관적이지만, 코드 리뷰의 목적과 장점에 대해 이야기해보려고 한다. 먼저, 코드 리뷰란 좋은 품질의 소프트웨어(Software) 서비스(Application Service)를 만들기 위하여 자신과 다른 사람의 작업을 검토하고 의견을 공유하는 절차를 말한다. 글을 쓰고 출판하는 절차를 떠올리면 쉽게 이해할 수 있을 것이다. 우리는 글을 쓰고나면 퇴고를 한다. 그 이유는 글을 쓰는 동안 몰입/몰두해 있어서 전체적인 관점에서 놓치는부분들이 있기 때문이다. 그래서 글을 마무리 짓기 전에 자신이 쓴 글을 다시 읽어보기도 하고 주변에 부탁해서 내용이 이해하기 쉬운 지 묻기도 한다. 밤 늦은 시간에 감수성이 폭발하여 막힘없이 글을 썼던 경험이 있다면, 다음 날 일어나서 자신이 쓴 글을 구겨버린 기억도 (아마) 있을 것이다. 코드 리뷰도 이와 같다.
 
그렇다면 이제 코드 리뷰의 좋은 점을 몇 가지 짚어보겠다. 먼저, 바로 위에서 언급한 것과 같이 퇴고 과정을 거칠 수 있게 한다. 다른 사람들 (아마도 대부분은같이 일하는 동료들)에게 리뷰를 요청하기에 앞 서 오탈자 등을 점검할 기회를 가질 수 있다. 그리고 코드 리뷰를 올리면 스스로에게 도움이 된다. 동료들에게 리뷰를 요청하려면 자신이 구현한 내용을 설명할 수 있어야하는데, 그러기 위해서 작업자는 구현해야 할 요구사항을 보다 깊이있게 분석할 기회를 갖게 된다. 어떤 자료에서는 테디베어 효과(Teddy-bear effect)라고 설명하기도 한다.

 

다음으로, 숨겨져 있지만 가장 중요한 장점이라고 생각하는 것인데, 코드 리뷰를 하면 우리 조직(팀, 그룹)이 만들고 있는 목표과 방향에 대해 효율적으로 공유하고 의사결정을 빠르게 수행할 수 있다는 것이다. 코드 리뷰가 없는 상황을 설명하기 위해서 잠시 앞 서 이야기한 그 사람의 예를 들어보겠다. 그 분은 항상 모든 사람을 모아놓고 주기적으로 회의하는 것을 즐겼는데, 자신의 매니저인 임원들에게 보고하기 위해서 회의시간동안 자신이 궁금한 것을 묻고 작업진행 상황을 파악하기 위해서였다. 어쩔 수 없이 수십명에 달하는 사람들이 희의실에 모여 각자맡은 부분의 내용을 순서에 맞춰 보고를 했고, 그 분은 회의시간이 자신뿐아니라 실무자들이 다른 사람의 업무를 파악할 수 있는 좋은 기회라고 합리화를 했다. 하지만 실상은 부서장 학습시간일 뿐이었으며, 자신의 보고 순서가 아닐때는 각자 전화기를 쳐다 보고 있었다. 그러나 성숙한 코드 리뷰를 하는 조직에서는 이러한 비효율적인 회의를 할 필요가 없다. 언제든 각자가 원하는 시간에 원하는 장소에서 코드를 보고 업무 현황을 따라갈 수 있으며, 모든 구성원은 가장 최신 정보를 기준으로 현황을 파악할 수 있게 된다^[각주:1]

 

코드 리뷰가 일상적이 된 성숙한 조직에서는 코드를 보고 질문을 남기거나, 질문에 답변을 단다. 모든 관련자들은 각자의 여건에 따라 코드를 읽고 소프트웨어가 어떻게 동작하는 지 파악할 수 있으며, 궁금한 점을 질문을 통해 해결한다. 팀에 새로 온 사람은 질의응답 이력을 통해 맥락을 쉽게 이해할 수 있다. 따라서, 모든 관련자들을 한 자리에 모으는 회의를 하지 않더라도 소프트웨어가 소비자들에게 어떤 방식으로 제공될 지 이해할 수 있게된다. 또한 회의는 휘발성이지만, 코드리뷰는 누적되기 때문에 시간이 흐를수록 의사통의 비용 감소에 탄력이 붙게 된다. 소프트웨어 품질을 높이기 위한 가장 기본적인 것은 모든 직원이 같은 목표를 공유하고 일관된 결과물을 만들어서 실수를 줄이는 것인데, 코드 리뷰는 가장 훌륭하면서 효율적인 방법이다.

당연한 이야기지만, 여러 사람의 눈과 생각을 거치면 소프트웨어의 품질은 보다 단단해 진다. 여기서 말하는 단단해진다의 의미는 문제점이 발생할 가능성이 점점 줄어들어 소프트웨어가 안정적이 되는 모습을 묘사한 것^[각주:2]이다. 코드 리뷰를 하면 품질이 올라가게 되는데 그 이유는 리뷰를 하는 사람들이 다양하기 때문이다. 사람은 누구나 강점이있고, 개성이 있다. 누구는 꼼꼼하고 누구는 기발하다. 누구는 오탈자를 잘 찾아내고 누구는 추상화에 관심이 많다. 그렇게 다양한 사람들에게 리뷰를 요청하면 사람들은 자신의 경험과 배경지식을 바탕으로 코드 리뷰를 한다. 같은 코드라도 서로 다른 관점으로 바라 보는 것이다. 이렇게 다양한 관점에서 바라보면 우리는 다양한 관점을 미리 체험해 볼 수있다. 그래서 거의 모두가 놓친 문제점을 발견할 수도 있고, 다른 팀과 협업하기 좋은 모양으로 코드를 개선할 수도 있다. 따라서 우리 팀의 소프트웨어가 시장에 출시해서 임의의 사용자에게 전달 되더라도 우리는 이미 예방주사를 맞았기 때문에 덜 아프다.
 
마지막으로, 잘하는 사람이 잘 못하는 사람을 가르칠 수 있다. 이 부분은 코드 리뷰의 장점 중에서 작은 부분이기 떄문에 강조하지 않기를 바란다. 이 특징만 너무 강조하면 앞에서 언급한 것과 같이 오해를 낳을 수 있기 때문이다. 잘 못하는 사람은 당연이 기술숙련도(Skill)가 떨어지기 때문에 실수하거나 놓치는 부분이 있을 수 있다. 그런 부분들을 잘하는 사람이 바로 잡을 수 있다. 그러나 그 부분이 제일 중요한 것이 절대 아니다. 기술숙련도는 개인이 각자 알아서 갈고 닦아야 할 부분이기 때문에 채점을 통한 훈육방식으로 해결할 문제가 아니다. 오히려 잘하는 사람과 새로 들어온 사람이 짝을 이루어 개발과 코드 리뷰를 같이하는 이유는 새로 들어온 사람이 그 조직에 스며드는 시간이 짧아지기 때문이다. 새내기의 실수를 부드럽게 감싸 안아주는 달콤한 채찍은 어디까지나 덤일 뿐이다.
 
지금까지 코드 리뷰의 목적과 코드 리뷰의 좋은 점에 대한 생각을 정리해 보았다. 다음 기회에는 어떻게 코드 리뷰를 하면 좋을 지에 대해 이야기해 보면 좋을 것 같다.

---

 

1. 영어로는 Aligned, On the same page라고 표현한다. 같은 맥락을 이해하고 있고 생각이 일치하여 오해가 없는 상태를 뜻한다. [본문으로]
2. 단단하다를 경직되어 있다로 오해할 수 있기 때문에 부연설명을 달았다. [본문으로]