내 코드 좀 봐주세요

내가 작성한 코드는 리뷰된 적이 별로 없다.

내가 작성한 코드는 리뷰된 적이 별로 없다. 여러 가지 이유가 있을 것이다. 일단 다들 바쁘다. 코드 작성 및 디버깅할 여유도 없는데 남의 코드 봐줄 시간이 있을 리가 없다. 그리고 내 경우 팀 내에 JavaScript 개발자는 거의 항상 내가 유일했다. 다른 언어를 주로 사용하는 팀원들이 내 코드를 리뷰하기 어려웠을 것이다. 그리고 심리적인 요인도 존재할 것이다. 코드 리뷰를 많이 겪어보지 않은 사람이라면, 특히 자존감이 낮은 사람이라면, 자신의 코드를 자신과 동일시하기 쉽고 다른 이의 리뷰에 자존심이 구겨지는 느낌을 가질 수 있다. 그리고 그 경험을 바탕으로 남에게도 피드백을 주지 않고 "다 좋습니다" 라며 넘어갈 수 있다. 그러나 난 정말 의견을 듣고 싶었다. 남들은 이 코드를 어떻게 달리 작성할지 궁금했다.

지금 다니는 이 회사에 입사하기 전, 화상 통화로 면접을 진행했다. 하지만 최종 면접은 파리로 가야 했다. 회사에서 비행기, 숙소 그리고 약간의 체류비용을 지원해줬다. 면접은 하루 동안 꽤 강도 높은 스케줄로 진행되었다. 중간에 내 매니저가 될 사람과 1:1 인터뷰를 가졌다. 그가 내게 이 회사에서 기대하는 부분에 대해 물었다. 나는 많이 배우고 싶다고 했다. 그리고 코드 리뷰를 포함해서 피드백을 주고받으며 일하고 싶다고 말했다. 그는 내게 답했다.

네가 작성한 코드의 버그는 네 책임이야. 하지만 코드 리뷰가 이루어지고 난 후에 발견되는 버그는 너와 리뷰한 모든 사람의 책임이야.

마찬가지로 너도 다른 이의 코드를 리뷰해야 하고, 너도 그 코드에 대한 책임을 갖게 되는 거야.

머리를 한 대 맞은 기분이었다. 코드 작성만큼이나 코드 리뷰는 동등하게 중요한 업무로 여겨지고 있다는 것이었다. 실제로 입사해서 업무를 해보니 정말 그렇다는 걸 느끼고 있다. 다만, 이걸 잘못 해석하면 안 된다. 책임 소재를 트래킹 하기 위한 방법이 아니다. 그런 분위기의 조직이라면 코드 리뷰를 하든 말든, 소용없다.

조금 구체적으로 얘기해보자. 개발은 develop 브랜치 위에서 이루어진다. 하지만 아무도 develop 브랜치에 바로 작업하지 않는다. 항상 새 브랜치를 생성해서 작업한 후 pull-request를 보낸다. Repository에 따라 어떤 repo는 한 명의 reviewer 가 approve 하면 merge 되며, 어떤 repo는 두 명의 reviewer 가 approve 해야만 merge 될 수 있기도 하다. github에서 설정이 가능하다. 다들 적극적으로 의견을 제시한다. 하지만 드라이하다. 더 낫다 생각되는 이유만 간결히 제시한다. 그리고 PR 작성자는 의견을 수동적으로 전부 반영하진 않는다. 서로 주고받는다. 그러다 보면 한 PR 내에 커밋 개수가 많아진다. 하지만 괜찮다. 팀마다 다르겠지만 내가 일하는 팀에서는 PR 은 무조건 squash & merge 되도록 github에 설정이 되어 있다. 하나의 커밋으로 merge 되기 때문에 히스토리가 복잡해질 염려도 없고, 그 커밋에 대한 세부 내용은 추후 PR 상에서 오간 대화를 참고하면 된다.

단 한 줄을 수정하더라도 PR 생성은 필수이다. 누가 만든 커밋인지, 누가 approve 했는지, 남겨진 대화를 통해 그 결정에 대한 히스토리를 알 수 있다.

이런 절차를 거치는 이유는 서로가 서로를 보완해주며 높은 품질의 코드를 작성하기 위함이다. 당장은 느려 보이지만 혼자 작성한 코드가 배포된 후에 장애를 일으키고, 장애 상황에서 버그를 찾아내고, 고객에게 끼치는 피해를 최소화한 후에 새로 업데이트하는 비용을 고려하면, 이 느려 보이는 프로세스가 사실은 더 빠르고 효율적이다. 게다가 배포에 자신감이 생기며, 리뷰를 할 때마다 조금씩 배우게 된다.

이런 프로세스를 가지는 데 있어 가장 큰 걸림돌은 아마 시스템일 것이다. 팀원들은 하고 싶더라도, 이런 문화를 이해하지 못하는 매니저라면 시작조차 할 수 없으며, 시작하더라도 시늉만 하다 흐지부지 된다. 코드 리뷰를 도입하면 당장은 코드를 생산해내는 속도가 줄어든다. 코딩을 하는 시간을 덜고 그 시간에 리뷰를 하기 때문에 당연하다. 하지만 이게 결국엔 더 좋은 결과를 낸다는 믿음이 있는 매니저는 코드 리뷰를 감안해서 스케줄링을 한다. 이렇게 코드 리뷰가 업무 시간의 일부를 정식으로 차지해야 한다. 시간과 노력의 투자 없이 개발 문화는 풍성해질 수 없다.

결국 코드 리뷰는, 팀원들이 바빠서, 언어가 달라서, 동료에게 미안한 마음 때문에 못했던 게 아니다. 단지 그 프로세스가 우리 업무 속에 없었을 뿐이다. QA 팀에서 버그를 발견했다고 개발자에게 미안해하거나, 버그가 발견되었다고 개발자가 부끄러워하지 않는 것은 업무 프로세스가 원래 그런 것이기 때문이다. 코드 리뷰도 코딩만큼이나 중요한 하나의 업무로써 프로세스 안으로 들어오면 된다. 그러면 버그를 줄일 수 있으며, 자신감이 생기고, 매일매일 배우게 되며, 결과적으로는 팀 전체가 성장한다.