Asynchronous Code Review

코드 리뷰(Code Review)는 생각보다 어려운 일이다. 사람들끼리 대화를 주고 받아도 협업이 잘 안되는데 글로 공유하면서 협업을 잘 할 수 있을 지 미지수다. 아마도 회의실에 모여서 그림을 그리며 설명하는 편이 훨씬 더 생산적일 것이다. 깃허브(GitHub)에 코드 말고 그림을 한 껏 올려서 리뷰를 한다면 모를까 소스 코드(Source Code)와 댓글로 이루어진 리뷰 과정을 보면 협업을 위한 코드리뷰의 장점에 대해 회의감이 드는 것은 당연하다. 아마도 코드 리뷰의 목적에 대해 이야기한 것^[각주:1]을 읽고 공감하는 사람도 있겠지만, 피부에 닿지 않고 멀게 느껴지는 사람도 꽤 많이 있었을 것이다. 그래서 코드 리뷰를 접근하는 방법에 대해 생각해보고 실천해 보면 좋겠다고 생각해서 숙제 검사 이야기^[각주:2]와 형식적인 규제 이야기^[각주:3]를 했다. 이 이야기들을 통하여 코드 리뷰를 단지 업무에 대한 검토 요청이나 결재 상신으로 받아들이지 않는 것이 중요하다고 언급했다. 잘못된 사례를 언급하면서 말하고 싶었던 것은 코드 리뷰를 바라보는 인식 변화가 가장 중요하다는 것이었다. 방향이 잘못 되었다면 가는 방법과 수단이 아무리 뛰어나도 그 끝은 너무도 분명하게 틀릴 것이기 때문이다. 코드 리뷰의 목적에 공감했다면, 이제 효과적으로 코드 리뷰를 수행하기 위한 방법에 대해 알아볼 필요가 있다.

우리는 동료 또는 익명의 누군가와 공동으로 작업을 하며 그 들과 의견을 나눈다. ^[각주:4] 그 과정에서 코드에 댓글 또는 주석을 남겨서 자신의 생각을 설명하기고 하고 궁금한 점을 묻기도 한다. 그러나 이 과정에서 조바심이 나타나는 경우를 자주 목격했다. 코드 리뷰를 숙제 검사로 받아들이는 경우에 더욱 그랬으며 메신저에서는 코드 리뷰와 승인을 재촉하는 매시지가 계속 올라왔다. 리뷰가 늦어지면 풀 리퀘스트(Pull Request)로 올린 코드가 반영되지 않기 때문에 뒤에 밀린 코드를 반영할 수 없다고 으름장을 놓았다. 아주 가끔은 임원을 핑계로 긴급 리뷰를 요청하기도 했다. 이러한 방식은 리뷰의 속도 곡선을 왜곡하기 때문에 건전한 코드 리뷰를 방해한다.
 
코드 리뷰의 속도 곡선은 구성원들이 코드 변화를 시간의 흐름에 따라 이해할 수 있는 정도를 표현한다. 좋은 코드리뷰를 수행한 팀은 코드 리뷰의 목적을 잘 달성할 것이다. 그렇다면 구성원은 코드가 변경된 내용에 대해 인지하고 있기 때문에, 이 후 리뷰 시간은 점차 짧아질 것이고 실수가 줄어 든다. 그래서 시간이 흐를수록 업무에 가속도가 붙게 되는데, 이것은 마치 훈련이 잘 된 조직이 운동경기에서 뛰어난 조직력으로 좋은 성과를 내는 것과 같다. 선수들끼리 눈빛만으로도 생각을 읽고 상대편보다 빠르게 움직일 수 있는 것과 같다. 따라서 좋은 코드 리뷰가 반복되고 시간이 흐르면 좋은 팀이 만들어지고 좋은 팀은 효율성과 생산성을 높여서 좋은 성과를 낸다. 반대로 나쁜 코드 리뷰를 수행한 팀은 시간이 흘러도 코드 리뷰에 들이는 시간이 줄어들지 않고 오히려 늘어난다. 코드 리뷰 초반에 충분한 검토를 거치지 않게 되면, 코드 변화에 대해 이해 수준이 다르게 되고, 코드에 대한 이해가 부족한 상태에서 급하게 일을 진행하기 떄문에 오류나 실수가 많아지는 것이다. 그러다가 '원래 그렇다. 어쩔 수 없다'는 핑계로 긴급 패치를 남발하게 된다. 소 잃고 외양간 고치는 일에 더 많은 시간을 소비하게 되는 것이다. 마치 경기 중 혼자 공을 몰고 가다가 상대방에게 둘러싸여 어쩔 수 없이 패스 하게 되는 상황과 비슷하다. 선수들은 서로에게 답답해하며 화를 내지만 나아지는 것은 없다. 나쁜 코드 리뷰를 수행하는 조직은 소수의 뛰어난 선수에게만 의지하는 조직과 비슷하다. 이러한 팀은 결국 경기를 어렵게 풀어나갈 수 밖에 없다. 그래서 코드 리뷰의 속도 곡선이 시간이 지나도 변화가 없거나 오히려 상승하는 모양을 보일 것이다.
 
그런 면에서 '전자우편 이야기'를 통하여 좋은 코드 리뷰가 어떤 것인 지 이야기해 볼 필요가 있다. 전자 우편이 동작하는 방식은 비동기 방식이다. 전화의 경우 신호 대기 후 통화가 연결되며 통화를 종료할 때까지 회선을 유지 된다. 이러한 동기식 방식은 직관적으로 즉각적이지만, 참여자를 붙들어 두어야 한다. 반면 전자우편의 경우 상대방에게 전달한 다음 회신이 오기까지 기다려야 하는 비동기 방식이다. 비동기 방식은 즉각적인 반응을 요구하지 않아서 답답할 수 있지만, 느슨한 결합을 통하여 소통하는 대상이 작업이나 상황에 얽매이지 않고 자신의 상황에 맞게 매시지를 해석하고 대응할 수 있는 장점이 있다. 코드 리뷰 중 서로 의견을 교환할 때 이러한 비동기 방식을 지향해야할 필요가 있다는 것을 이야기하기 위해서 전자우편 이야기를 가져왔다.
 

Synchronous vs. Asynchronous communication (https://www.cloudamqp.com/blog/2016-09-13-asynchronous-communication-with-rabbitmq.html)

 
좋은 코드 리뷰를 훈련하기 위한 가장 쉬운 방법은 (전자)우편을 보내는 것처럼 비동기 방식으로 리뷰를 진행해야 한다. 답신이 바로 오면 좋지만 그건 상대방에게 달린 문제이다. 리뷰를 요청하고 기다리는 시간이 초조하고 흐름이 끊어지는 느낌을 받을 수 있다. 코드 리뷰가 길어지면 메인 브랜치와 코드가 달라질 까봐 걱정이 되어 조바심이 날 수 있다. ^[각주:5] 그러나 의도적으로라도 여유를 갖고 꾸준히 비동기 방식으로 코드리뷰를 진행하다보면 어느 순간 팀 전체가 1주일 이상을 앞 서서 풀 리퀘스트를 올리고 있을 것이다.

---

 

1. Purpose of Code Review [본문으로]
2. About Pull Requests [본문으로]
3. Code Review, Thumbs-up [본문으로]
4. 1인 기업이거나 공부하는 과정에서 혼자 프로젝트를 진행하는 경우를 제외한다면, 코드 리뷰를 통한 협업이 필요하다 [본문으로]
5. 인간은 본능적으로 (빠른) 회신을 받고 싶어하기 때문에 바로 댓글이 달리지 않거나 답장이 오지 않으면 초조하고 불안해진다. 그래서 즉각적으로 빠르게 소통하는 인스턴트 메시징(Instant Messaging)의 소통 방식이 사람들에게 유리해 보인다. [본문으로]