몇달 전 회사 근처 맥도날드에서 맥모닝을 살 때였다. 점원은 일을 시작한 지 얼마 안 되었는지 주문을 받는 게 서툴렀고, 주문 줄은 점점 길어졌다. 성미가 급한 나는 당연히 짜증이 났다. 한동안 계속 그랬고, 맥도날드에 들어갈 때 다른 점원이 주문을 받는 걸 보면 기쁘기까지 했다. 그러다가 매장 안에 자동 주문 기계가 생겼다. 기계로 주문을 하면서는 기다리는 시간이 줄고, 내 주문이 제대로 들어갈지 걱정하지 않아도 돼서 편했다. 그 뒤로 서툴렀던 점원은 이제는 빠르게 주문을 받는 듯 보였지만 나는 여전히 기계로 주문을 한다. 이 일을 겪으면서 새삼 자동화 기계가 얼마나 편한지 느꼈는데 최근에 회사서도 비슷한 경험을 했다.
소프트웨어를 개발하는 곳에서는 이제 코드 리뷰는 익숙한 개념이다. 실제로 쓰는 거와는 별개지만 말이다. 남들도 쓰고 좋다고 하니 코드 리뷰를 도입하다 보면 겪게 되는 문제가 있다. 옆자리에 앉아서건 코드 리뷰 툴을 통해서 하건 다음과 같은 말들이 나온다.
“코드 사이 사이에 왜 이렇게 빈 줄이 많아요? 줄여주세요.”
“배열 인자 끝에도 콤마 찍어주세요. 나중에 배열에 추가할 때 콤마 빼먹을 걸요.”
“여긴 var대신 const 써야해요.”
“80칸 넘는데 줄 내려주세요.”
…
바로 코딩 스타일 지적에 대한 문제이다. 이런 말을 들으면 약간 기운이나 빠지거나 화가 난다. ‘왜 달을 안 보고 손가락을 보는 거야?’라는 생각이 절로 든다. 설계의 문제를 논의하거나 코딩한 방법에 대한 노하우를 나누는 기회를 기대했다가 실망을 하게 된다. 리뷰하는 입장에서는 (남의 허물이 더 잘 보이는 거처럼) 코딩 스타일에 문제가 보여서 얘기를 해준 건데 고마워하기는커녕 기분 나빠 보이는 개발자가 이해가 안 된다. (재미있는 건 서로 역할이 바뀌면 똑같이 행동한다는 것이다.)
그래서 코드 리뷰를 하면서 서로 감정이 상하기가 쉽다. 실제로 이런 일은 자주 발생해서 개발자 사이가 안 좋아지거나, 아예 팀 차원에서 코딩 스타일은 코드 리뷰할 때 보지 말자는 얘기도 나온다.
그렇지만 코딩 스타일은 맞춰야 장기적으로 유지보수가 쉬워진다. 실제로는 달도 보고 손가락도 챙겨야 하는 것이다. 깨진 유리창 이론이 여기도 적용돼서 코딩 스타일을 안 맞춘 코드가 존재한다면 나중에는 점점 늘어나게 된다. 코드의 할렘화가 되는 것이다. 그렇게 되면 곱게 자란 개발자들은 당연히 그 속으로 들어가길 꺼려한다. “이건 너무 더러워요.”, “뭔가 고치려면 새로 짜거나 리팩토링을 하는 게 빠를 걸요.” 제품은 점점 더 유지보수하기 어려워지고 그러다가 결국에는…
안 할 수는 없고, 실행되기는 어려운 일이라서 고민을 하다가 코드 리뷰 프로세스에서 자동 리뷰 기능을 추가했다. 기존에는 다음의 방식으로 코드 리뷰를 하고 있었다.
coding → shelve → review → commit
새 방식은 아래와 같은 순서로 진행된다. 개발자가 리뷰하기 전에 코드 검사를 자동으로 먼저 하는 것이다.
coding → shelve → auto review → review → commit
우리 회사에서는 버전관리시스템으로 perforce를 쓰고 있고, 같은 제품군인 swarm을 코드 리뷰 툴로 쓰고 있다. 이 swarm에 web hook 기능이 있어서 코드 리뷰가 올라올 때마다 자동으로 코드 검사를 하게 했다. 개발 언어를 javascript(es6+)를 쓰고 있어서 검사툴은 eslint와 js-codemod를 사용했다.
코드 리뷰가 올라오면 자동으로 eslint와 js-codemod가 실행되서 코드 검사를 한다. 그리고 결과를 댓글로 알려준다. eslint는 실행 결과를 알려주고, js-codemod는 코드를 직접 고치기 때문에 개발자가 올린 코드와 자동으로 바꾼 코드의 diff 결과를 알려주게 했다.
도입한 이후로 직접 써보니 개인적으론 기대했던 것보다 더 좋은 경험을 하고 있다. 개발자 입장으로는 다른 개발자와의 리뷰 전에 코딩 스타일에 관한 검토를 먼저 해볼 수 있어서 좋고, 리뷰하는 개발자도 코딩 스타일에 신경 쓸 필요가 없어져서 시간을 줄일 수 있어서 좋았다. 프로젝트 차원에서는 앞으로 점점 늘어나는 코드에서 시스템적으로 코딩 스타일의 균일성을 지킬 수 있어졌다.
조금 더 개인적인 경험이면서 더 중요하다고 생각되는 건 기계가 사람 사이의 감정소모를 줄여준다는 점이다. 위의 그림에서 기계가 검사해준 결과물을 보면 아무리 깐깐한 사람이어도 개발자 기분 생각해서 넘어갈 부분들도 다 지적을 하고 있다. 기계가 아닌 사람에게 이런 지적을 받았다면 분명 안 좋은 생각이 들었을 것이다. 코드 수정을 하는 것도 억지로 따르거나 나중으로 미뤘을 것이다. 그런데 기계에 지적에는 별다른 감정이 안 생기고 기계적으로 고치려고 했다. 에러가 없다는 기계의 댓글에는 기뻐하기도 했다. 왜 이럴까 생각해보니 두가지 정도 이유가 있는 거 같다.
하나는 개발을 시작하면서부터 컴파일러의 에러 메시지를 보고 고치는 게 습관이 되어서다. 실행과 관련이 없는 코딩 스타일 문제에 까지도 습관적으로 기계의 메시지를 보고 수정하게 되는 것이다. (내가 이렇게 기계에 길들여졌다니!)
또 다른 이유라면 지적을 하는 기계에 감정도 다른 의도도 없다는 걸 확신하기 때문 아닐까. 사람에 대해서는 아주 약간의 의심이라도 들 수가 있고 그렇게 되면 아무리 좋은 말도 안 따르기 마련이니까.
이유야 어쨌건 사람과 사람 사이에 자동화 기계를 하나 두었더니 일이 편해진 좋은 경험이었다. 버전컨트롤시스템을 쓰고 있고 코드 리뷰를 하고 있다면 자동으로 코딩 스타일 검사하는 것도 해보길 추천한다. 개발자들 사이의 불필요한 논쟁을 줄여주고 더 생산적인 코드 리뷰가 되도록 도와줄 것이다.