코드 리뷰의 서서히 진행되는 붕괴 - 어떻게 대처하고 계신가요?
The slow collapse of code reviews - how do you deal with it?
핵심 요약
AI 도입 후 코드 리뷰가 사라지며 품질 저하를 겪는 작성자가 다른 팀의 대처법을 묻는 글입니다.
- 코드 리뷰 생략 — 속도를 위해 리뷰를 없앴으나 코드 이해도와 품질이 하락함
- AI 에이전트 활용 — 인간 리뷰어 대신 여러 에이전트를 도입했으나 병목 현상 발생
- 리뷰의 본질 — 리뷰는 단순히 버그를 찾는 것보다 작성자가 코드를 깊이 이해하게 만드는 강제 장치임
- 업계 관행 논쟁 — 코드 리뷰가 수십 년간 표준이었다는 주장에 대해 업계마다 다르다는 반론 제기
manager.dev
원문 사이트로 이동
5개월 전까지만 해도 우리 팀의 모든 PR은 최소 두 명, 즉 코드를 짠 엔지니어와 한 명 이상의 리뷰어가 검토했어. 지난 수십 년간 전 세계 소프트웨어 엔지니어링 팀 99%가 일해온 딱 그 방식이지.
그러다 4월에 프로덕션 걱정할 필요 없는 완전히 새로운 제품을 만들기 시작했어. 그래서 속도를 좀 내보려고 코드 리뷰를 선택 사항으로 바꿨지.
처음엔 대부분의 PR이 여전히 리뷰를 거쳤어. 우리 모두 프로덕션에 뭘 올리는 거에 대한 건강한 공포가 있었거든. 근데 몇 시간씩 기다릴 거 없이 몇 분 만에 PR을 프로덕션에 올리는 맛을 보니까 이게 중독성이 장난 아니더라고. 그래서 두어 달 지나니까 코드 리뷰 건수가 거의 0에 수렴하게 됐어.
그래도 난 다들 자기 에이전트가 짠 코드를 완벽하게 읽고 이해하길 바랐고, 'Claude가 짠 건데요' 같은 변명은 안 받아줬어. 코딩 워크플로우에 에이전트 리뷰 단계도 추가했지(서로 다른 지시를 받은 에이전트 3개를 돌려서 코드를 검토하고 결과를 취합하는 기술이야). 그러니까 사람 2명이 리뷰하던 걸 사람 1명(작성자)이랑 에이전트 여러 개가 대신하게 된 셈이지.
근데 그것도 병목이 되더라. 우린 경쟁이 치열한 시장에 있고, 엄청나게 빨리 움직여야 하거든. 어차피 버릴 UI 코드 짜는데, 내가 이걸 완벽하게 이해하는 게 무슨 상관인가 싶더라고.
그래서 업무를 두 가지 유형으로 나눴어.
-
Validation - 피벗할 경우 바로 버릴 일회성 코드. 온보딩 플로우나 대부분의 UI, 현재 제품에만 특화된 기능 같은 것들.
-
Infra - 피벗을 해도 계속 가져갈 핵심 기능이나 부품들.
우리는 인프라 작업은 꼼꼼히 리뷰하고, 밸리데이션 작업(대부분 프론트엔드 코드였지)은 그냥 슥 훑어보기만 했어.
근데 그것도 오래 못 가더라.
코드 리뷰 단계는 사람들이 코드를 꼼꼼히 읽고 에이전트가 짠 내용을 '진짜로' 이해하게 만드는 강제 장치였거든. 리뷰를 안 거치면 PR에 달린 질문이나 코멘트에 답을 못 하니까(코딩 에이전트 시켜서 답변 달게 하는 건 눈치 보이는 짓이었고) 어쩔 수 없이 읽어야 했으니까.
그 강제 장치를 없애버리니까 다들 요령만 피우기 시작했어. 코드를 보긴 보는데, 이해도는 점점 떨어지더라고.
그렇게 5개월 만에 코드 100%를 사람 2명이 리뷰하던 팀에서, 대부분의 코드를 0명이 리뷰하는 팀이 돼버렸어.
결과는 지금까지 영 좋지 않아.
속도는 포기하기 싫은데, 품질은 높이고 싶거든.
다른 엔지니어링 팀들은 이 문제를 어떻게 해결하고 있어?
