코드 리뷰
Code Review
코드 리뷰란?
- 동료가 코드를 검토해 오류·개선 찾기
- 혼자 못 보는 실수를 잡음
- AI 코드도 리뷰 필요
코드 리뷰가 자리 잡으면 코드의 주인이 바뀝니다. '이건 김 대리가 짠 모듈'이라는 말이 사라지고, 병합된 순간부터 팀 전체가 함께 책임지는 자산이 됩니다. 담당자가 휴가를 가거나 퇴사해도 코드가 고아가 되지 않습니다. 동시에 문제를 만나는 시점이 앞당겨집니다. 장애가 터진 새벽에 로그를 뒤지며 찾아내던 실수를 병합 직전 질문 한 줄로 잡아냅니다. 리뷰는 일정을 잡아먹는 절차가 아니라 뒤에서 터질 시간을 앞으로 당겨 쓰는 일입니다.
운영 방식은 크게 두 갈래입니다. 화면을 함께 보며 즉석에서 주고받는 동기 리뷰는 구조가 크게 흔들리는 변경에 맞고, PR에 코멘트를 남기는 비동기 리뷰는 일상적인 변경에 맞습니다. 관건은 단위입니다. 수천 줄로 불어난 PR은 리뷰어가 끝까지 읽어내지 못해 결국 승인 도장만 찍히므로, 팀마다 PR 한 건의 상한선을 정해 잘게 쪼개는 편이 낫습니다. 역할 경계도 분명해야 합니다. 들여쓰기·네이밍·미사용 변수 같은 지적은 린터와 정적 분석 도구에 맡기고, 사람은 설계 의도와 예외 상황을 봅니다. 동작이 맞는지 확인하는 일은 테스트 코드와 QA의 몫이지 리뷰어가 눈으로 실행해 볼 일이 아닙니다.
현장에서 가장 자주 깨지는 지점은 '승인은 하는데 읽지는 않는' 상태입니다. 리뷰어가 시니어 한두 명에게 몰리면 PR이 사나흘씩 밀리고, 급해진 작성자가 '일단 머지하고 나중에 보시죠'라고 말하는 순간 리뷰는 형식만 남습니다. 반대로 리뷰를 개인 취향을 관철하는 자리로 쓰면 주니어는 PR 올리기 자체를 두려워해 변경을 몰아서 한 번에 던지게 됩니다. AI가 생성한 코드도 다르지 않아, 잘 돌아간다는 이유로 읽지 않고 병합하는 습관이 쌓이면 몇 달 뒤 아무도 내부를 설명하지 못하는 코드가 서비스 한가운데 남습니다.
소프트웨어 공학의 품질 관리 관행에서 발전했으며, Git·풀 리퀘스트의 확산으로 일상적 개발 문화가 됐습니다.
가상의 사례로 살펴보겠습니다. 임직원 140명 규모의 이커머스 플랫폼 A사는 개발자가 22명인데, 지난 분기에만 배포 후 롤백이 14건 나왔습니다. 기능 일정을 맞추느라 리뷰 없이 바로 머지하는 관행이 굳어져 있었고, 결제 모듈은 사실상 한 사람만 내용을 알고 있었습니다.
- 분기 회고에서 CTO가 '롤백 14건 중 8건은 배포 전에 잡을 수 있던 것'이라고 짚으면서, 리뷰 없는 머지를 그만두기로 했습니다.
- 백엔드 리드가 PR 한 건을 300줄 이내로 쪼개게 하고, 리뷰어 2명 중 1명이 승인하기 전에는 병합이 막히도록 브랜치 보호를 걸었습니다.
- 첫 2주간 컨벤션 지적으로 코멘트가 도배되자, 린터와 정적 분석을 CI에 붙여 기계가 잡을 것은 빼고 사람은 설계와 예외 처리만 보게 했습니다.
- 리뷰 대기가 평균 31시간까지 늘어나자, 매일 오전 10시 20분을 '리뷰 타임'으로 고정하고 첫 코멘트는 24시간 안에 단다는 약속을 붙였습니다.
- 'LGTM' 한 줄 승인을 금지하고 '결제 실패 재시도 경로만 확인했습니다'처럼 무엇을 봤는지 남기게 하자, 형식적 승인이 눈에 띄게 줄었습니다.
- 3개월 뒤 월 롤백이 3.5건에서 0.8건으로, 리뷰 대기는 31시간에서 7시간으로 줄었고, 신입 개발자 온보딩 기간도 6주에서 3주로 짧아졌습니다.