코드 리뷰 문화를 팀에 정착시킨 방법

신입 개발자가 코드를 읽다가 눈물을 흘렸다

이전 회사에 입사했을 때, 코드 리뷰가 없었다. 각자 코드를 짜고, 각자 main에 push하고, 각자 배포했다. 비슷한 유틸리티 함수가 3곳에 중복으로 존재했고, 에러 처리 방식이 파일마다 달랐고, 한 사람이 만든 코드를 다른 사람이 이해할 수 없었다.

온보딩하는 신입 개발자가 코드를 읽다가 진짜로 눈물을 흘리는 걸 보고 결심했다.

코드 리뷰를 도입하자고 했더니 팀원 한 명이 물었다. 솔직히 맞는 말이다. 단기적으로 속도는 느려진다. 근데 장기적으로 버그가 줄고, 코드 품질이 올라가고, 팀원의 코드 이해도가 올라간다.

이걸 말로만 설득하려 하니 잘 안 됐다. 그래서 2주간 시범 운영을 제안했다. "2주만 해보고, 안 맞으면 그만두자." 이 한마디가 저항을 줄이는 데 효과적이었다.

처음부터 엄격한 규칙을 세우면 거부감만 생긴다.

PR을 올리면 최소 1명이 승인해야 머지할 수 있다. 리뷰는 24시간 이내에 해야 한다. 이게 전부였다. 리뷰 방법, 코멘트 형식, 승인 기준 같은 건 정하지 않았다. 먼저 습관을 만들고, 디테일은 나중에 잡기로 했다.

문화를 만들려면 리더가 먼저 실천해야 한다. 나는 모든 코드를 PR로 올렸고, 사소한 변경도 리뷰를 받았다. 받은 피드백을 적극적으로 반영했다.

주니어 개발자가 내 코드에 코멘트를 달기 시작했을 때가 전환점이었다. 변수명에 대한 의견이었는데, 실제로 더 나은 이름이었다. "이거 좋네요, 반영할게요"라고 답했을 때 그 주니어의 표정이 밝아지는 게 보였다.

(솔직히 내 변수명이 구린 걸 지적당한 건 좀 민망했다.)

코드 리뷰는 위에서 아래로 하는 게 아니라 서로 하는 거다. 이걸 행동으로 보여주는 게 중요했다.

첫 달에 문제가 생겼다. 한 팀원이 다른 팀원의 코드에 "이건 왜 이렇게 짰나요?"라고 달았는데, 받는 사람이 기분 나빠했다. 텍스트는 톤이 전달되지 않는다. 질문이 추궁처럼 느껴질 수 있다.

이후로 리뷰 코멘트 가이드를 만들었다. "이 부분은 ~하면 어떨까요?"처럼 제안형으로 쓰기. 칭찬할 부분이 있으면 반드시 언급하기. 중요도를 표시하기(nit, suggestion, must-fix).

이 가이드 하나로 리뷰의 분위기가 확연히 달라졌다.

가장 흔한 핑계였다. 두 가지를 했다.

첫째, 아침 30분을 리뷰 시간으로 정했다. 출근하면 코드부터 짜는 게 아니라 PR부터 확인한다. 둘째, PR을 작게 만드는 문화를 장려했다. 500줄짜리 PR은 리뷰하기 싫지만, 100줄짜리는 10분이면 본다.

PR 크기를 줄이니 리뷰 속도가 빨라졌고, 리뷰 속도가 빨라지니 PR을 올리는 빈도도 늘었다. 선순환이 생겼다.

프로덕션 버그가 40% 줄었다. 단순한 실수, 빠진 null 체크, 잘못된 조건문 같은 것들이 리뷰에서 잡혔다. 더 중요한 건 팀원들의 코드 스타일이 비슷해지기 시작했다는 거다. 서로의 코드를 보면서 좋은 패턴을 자연스럽게 배웠다.

온보딩 시간도 줄었다. 새 팀원이 기존 PR을 보면서 코드 스타일을 파악할 수 있었다.

최소 3개월은 꾸준히 실천해야 습관이 된다. 가장 중요한 건 강요가 아니라 본보기다. 내 코드를 먼저 리뷰받고, 다른 사람의 코드를 정성스럽게 리뷰하고, 피드백을 열린 마음으로 받아들이는 모습을 보여주는 것.