코드 리뷰의 진짜 목적, 버그 잡기가 아니라고요?

여러분 팀에서 코드 리뷰는 어떤 분위기인가요? PR(풀 리퀘스트, 내가 작성한 코드를 합쳐달라고 요청하는 것)을 올리면 시니어가 빨간 줄을 잔뜩 그어서 돌려보내고, 승인을 받아야만 머지할 수 있는 일종의 '검문소' 같은 느낌이라면, 오늘 이야기가 꽤 흥미로울 거예요. Perl 커뮤니티의 전설적인 프로그래머이자 『Higher-Order Perl』의 저자인 마크 제이슨 도미너스(Mark Jason Dominus)가 마스토돈에 올린 글이 개발자들 사이에서 많은 공감을 얻었는데요. 요지는 이겁니다. "많은 사람들이 코드 리뷰의 목적을 오해하고 있다."

리뷰의 목적은 버그 잡기가 아니라고요?

보통 코드 리뷰라고 하면 '나쁜 코드가 저장소에 들어오지 못하게 막는 문지기' 역할을 떠올려요. 버그를 찾아내고, 스타일을 지적하고, 품질 기준에 미달하면 돌려보내는 거죠. 그런데 도미너스의 주장은 다릅니다. 코드 리뷰의 진짜 핵심 목적은 지식 공유라는 거예요. 리뷰를 통해 작성자 말고 적어도 한 명이 더 그 코드를 이해하게 되고, 그래서 코드베이스의 각 부분을 아는 사람이 팀 안에 여럿 생기는 것. 그게 리뷰가 주는 가장 큰 가치라는 겁니다.

이게 왜 중요하냐면, 소프트웨어 팀의 진짜 리스크는 버그가 아니라 '그 코드를 아는 사람이 한 명뿐인 상황'이거든요. 흔히 '버스 팩터'라고 부르는데, 특정 개발자가 버스에 치이면(현실적으로는 퇴사하면) 프로젝트가 멈춰버리는 위험을 말해요. 리뷰는 이 위험을 매일 조금씩 줄여주는 장치인 거죠.

연구 결과도 같은 이야기를 해요

재미있는 건, 이게 그냥 한 사람의 의견이 아니라는 점이에요. 마이크로소프트 리서치가 2013년에 발표한 유명한 연구 「Expectations, Outcomes, and Challenges of Modern Code Review」가 있는데요. 개발자들에게 "리뷰를 왜 하나요?"라고 물으면 대부분 "버그를 찾으려고"라고 답하지만, 실제 리뷰 코멘트를 분석해보니 결함 발견은 생각보다 적었고, 코드 개선 제안이나 지식 전달, 대안 논의가 훨씬 많았다고 해요. 기대와 실제 효과가 다른 거죠.

생각해보면 당연하기도 해요. 리뷰어는 보통 diff(변경된 부분만 보여주는 화면)만 보잖아요. 코드를 직접 실행해보지도 않고, 전체 맥락을 다 파악하지도 못한 상태에서 몇 분 만에 훑어보는데, 여기서 깊숙한 로직 버그를 잡아내길 기대하는 건 무리예요. 버그는 테스트와 CI(코드를 올릴 때마다 자동으로 빌드하고 테스트하는 시스템)가 잡는 게 맞고, 사람은 사람이 잘하는 걸 해야 한다는 거죠. "이 설계 의도가 뭐예요?", "이 부분은 이런 방법도 있는데 어떻게 생각해요?" 같은 대화요.

리뷰를 '검문'으로 보는 팀 vs '대화'로 보는 팀

이 관점의 차이는 팀 문화에 엄청난 차이를 만들어요. 리뷰를 검문으로 보는 팀에서는 리뷰어가 권력자가 되고, 작성자는 방어적이 돼요. 지적 하나하나가 공격처럼 느껴지고, 리뷰가 무서워서 PR을 최대한 미루게 되죠. 반대로 리뷰를 지식 공유로 보는 팀에서는 리뷰어도 배우는 사람이에요. "오, 이런 API가 있었네요, 배워갑니다" 같은 코멘트가 자연스럽게 나오고요.

구글의 리뷰 문화가 좋은 예인데요. 구글에는 'readability'라는 제도가 있어서, 리뷰의 상당 부분이 "이 코드를 다른 사람이 읽고 이해할 수 있는가"에 맞춰져 있어요. 코드는 한 번 쓰이고 수백 번 읽히니까, 읽는 사람 관점의 피드백이 곧 팀 전체의 생산성이 된다는 철학이죠.

요즘처럼 AI 코딩 도구가 코드를 대량으로 만들어내는 시대에는 이 관점이 더 중요해져요. 기계적인 버그나 스타일 문제는 AI 리뷰 도구와 린터가 점점 더 잘 잡아주거든요. 그러면 사람 리뷰에 남는 역할은 뭘까요? 결국 "우리 팀이 이 코드를 함께 이해하고 있는가"를 확인하는 일이에요.

그래서 어떻게 하면 좋을까요

실무에 적용할 만한 팁을 정리해보면요. 첫째, 리뷰 코멘트를 명령이 아니라 질문으로 써보세요. "이렇게 바꾸세요"보다 "이런 케이스는 어떻게 처리되나요?"가 대화를 만들어요. 둘째, PR을 작게 유지하세요. 500줄짜리 PR은 지식 공유가 아니라 승인 도장 찍기가 될 수밖에 없거든요. 셋째, 주니어에게도 리뷰어 역할을 주세요. 버그를 못 잡아도 괜찮아요. 리뷰의 목적이 지식 공유라면, 주니어가 리뷰하면서 코드베이스를 배우는 것 자체가 목적 달성이니까요.

정리하면, 코드 리뷰는 나쁜 코드를 막는 문이 아니라 팀의 이해를 넓히는 창이라는 이야기였어요. 여러분 팀의 리뷰는 어느 쪽에 가까운가요? 리뷰 때문에 힘들었던 경험이나, 반대로 리뷰 덕분에 성장했던 경험이 있다면 댓글로 나눠주세요.