개발기초 팀에 코드 리뷰 문화 정착시키며 겪은 어려움 (실제 시행착오와 정착 과정)

MES 시스템 스마트팩토리 당시  프로젝트 에서 코드 리뷰 없이 각자 알아서 커밋하고 배포하던 방식으로 개발이 이루어지고 있었는데, 버그가 운영 단계에서야 발견되는 일이 반복되면서 코드 리뷰 프로세스를 도입하게 되었습니다. 말은 쉬웠지만 실제로 팀에 정착시키기까지 여러 시행착오가 있었습니다.

상황: 왜 코드 리뷰가 필요했나

데이터 중복 저장 문제 가 운영 배포 이후에야 발견되었고, 원인을 찾아보니 코드 작성 단계에서 조금만 살펴봤어도 걸러낼 수 있는 실수였습니다. 이 사건을 계기로 코드 리뷰를 도입하자는 이야기가 나왔습니다.

문제 1: 리뷰가 형식적으로 흘러갔다

처음 도입했을 때는 "LGTM(좋아 보여요)"만 남기고 승인하는 경우가 대부분이었습니다. 실질적으로 코드를 꼼꼼히 보는 사람이 거의 없었습니다.

원인: 다들 본인 업무가 바빠서 리뷰에 시간을 쓰기 부담스러워했고, 또 어떤 기준으로 리뷰해야 하는지에 대한 공감대도 없었습니다.

해결: 팀 내에서 최소한의 체크리스트(네이밍 규칙, 예외 처리 여부, 테스트 코드 포함 여부 등)를 만들어서 이 기준만큼은 반드시 확인하도록 정했습니다. 체크리스트가 생기니 리뷰가 훨씬 구체적으로 바뀌었습니다.

문제 2: 리뷰 코멘트가 감정적으로 받아들여지는 경우가 있었다

코드에 대한 지적이 마치 그 사람에 대한 지적처럼 느껴진다는 이야기가 나온 적이 있었습니다. 특히 [연차 차이가 있는 팀원 간]에는 이런 분위기가 더 조심스러웠습니다.

해결: 리뷰 코멘트를 남길 때 "이건 틀렸다"보다는 "이 부분은 어떤 이유로 이렇게 작성하셨나요?" 같은 질문형으로 남기는 걸 팀 차원에서 권장했습니다. 또한 리뷰는 코드에 대한 의견이지 사람에 대한 평가가 아니라는 점을 팀 미팅에서 명확히 짚고 넘어갔습니다.

문제 3: 리뷰가 쌓이면서 병목이 되었다

리뷰어가 소수에게 몰리면서, 특정 사람의 승인을 받기까지 며칠씩 기다리는 상황이 생겼습니다. 오히려 배포 속도가 느려지는 부작용이 나타났습니다.

해결: 리뷰어를 고정하지 않고 [기능 영역별로 로테이션하거나 / 최소 1명 이상 승인이면 진행 가능하도록] 규칙을 완화했습니다. 급하지 않은 리뷰와 급한 리뷰를 구분해서 처리 우선순위를 정하는 것도 도움이 됐습니다.

마무리하며

코드 리뷰 문화를 정착시키면서 느낀 건, 도구나 규칙보다 팀원들이 "왜 이걸 하는지" 공감하는 게 먼저라는 점이었습니다. 처음에 형식적으로 흘러갔던 이유도, 결국 필요성에 대한 공감대가 부족했기 때문이었다고 생각합니다.

코드 리뷰를 새로 도입하려는 팀이 있다면, 체크리스트 같은 구체적인 기준을 먼저 세우고 시작하시는 걸 추천합니다.