Will Larson — AI 시대, 코드 리뷰를 다시 설계하는 법

원문: https://lethain.com/small-changes/ | Will Larson, 2026년 10월 17일

핵심 요약

Will Larson은 AI 도구로 풀 리퀘스트(PR) 생산량이 급증한 환경에서, 모든 변경에 똑같은 인간 리뷰를 요구하는 관행이 오히려 병목이 되고 있다고 말한다. 그의 팀은 코드 크기, 자동 검증 결과, 작성자의 해당 서비스 경험, 영향 범위를 조합해 일부 변경만 빠른 승인 경로로 보내는 small-change 제도를 시험 중이다. 핵심은 ‘AI가 사람을 대체해 리뷰한다’가 아니라, 리뷰가 맡아 온 서로 다른 역할을 분해하고 각 역할에 더 적합한 통제를 배치하자는 데 있다.

리뷰가 느려진 것이 아니라, 변경 생산 속도가 바뀌었다

코드 리뷰는 오랫동안 안전장치이자 협업의 의식이었다. 동료가 변경을 읽고 버그를 잡고, 설계 의도를 묻고, 팀의 암묵지를 나누며, 때로는 규정 준수의 흔적까지 남긴다. 그래서 리뷰 대기열이 길어지면 보통 ‘리뷰어가 더 빨리 봐야 한다’거나 ‘PR을 더 작게 쪼개야 한다’는 처방이 나온다.

Larson이 제시하는 장면은 조금 다르다. Imprint에서는 2년 전보다 엔지니어 한 사람당 병합하는 PR 수가 약 네 배로 늘었고, 일부 팀은 열 배 수준에 이르렀다. 동시에 중간 리뷰 시간은 33분에서 77분으로 길어졌다. 흥미로운 점은 품질 지표도 나빠졌다고만 말할 수 없다는 것이다. 그는 같은 기간 사고와 심각한 사고가 줄었다고 보고한다. 즉, ‘속도를 내면 품질이 떨어진다’는 익숙한 도식보다, 변화량이 늘어난 조직에서 사람이 읽는 리뷰가 가장 희소한 자원이 됐다는 진단에 가깝다.

물론 이는 한 회사의 자체 보고이며 외부 검증된 보편 법칙은 아니다. 그러나 AI 보조 코딩이 작은 수정과 실험용 코드를 값싸게 만들어 낼수록, 검토해야 할 diff의 양이 사람의 주의력보다 빨리 증가한다는 문제는 많은 팀이 공유한다. 이때 병목을 ‘리뷰어의 성실성’으로만 설명하면 해법도 개인에게 과도한 야근을 요구하게 된다.

`small-change`는 신뢰의 자동화가 아니라 자격의 자동화다

Larson의 실험은 PR 제목이나 작성자의 자기신고를 믿어 자동 승인하는 방식이 아니다. CI가 기계적으로 자격을 판정한다. 예시 기준은 1,000줄 미만, AI 리뷰에서 심각도 높은 발견이 없음, 작성자가 해당 서비스에 과거 병합 경험을 충분히 가짐, 영향 서비스 수가 제한됨 등이다. 공용 라이브러리와 결제·보안 같은 민감 영역은 제외하고, 저장소별 설정으로 더 좁힐 수 있다. 라벨은 사람에게 보여 주는 표식일 뿐, 승인 자격은 사람이 바꿀 수 없는 빌드 검사가 결정한다.

이 설계에서 중요한 것은 ‘작은 변경’이라는 이름보다 배제 규칙이다. 줄 수가 작아도 공용 모듈 하나를 건드리면 파급 효과가 클 수 있고, 새 서비스에 익숙하지 않은 작성자의 200줄은 위험할 수 있다. 반대로 익숙한 경계 안에서 검증이 촘촘한 400줄은 반복적인 인간 확인보다 자동화에 더 어울릴 수 있다. 따라서 이 제도는 인간의 판단을 없애는 스위치가 아니라, 어떤 변경에 인간의 비싼 주의를 써야 하는지 명시적으로 선언하는 정책이다.

AI 승인 도구가 ‘승인’ 또는 ‘보류’만 하고 장황한 코멘트를 남기지 않는다는 점도 눈여겨볼 만하다. Larson은 자동 생성 코멘트를 사람이 다시 읽고 답하는 과정이 실제 학습이나 책임을 만들지 못한 채 병목을 흉내 낼 수 있다고 비판한다. 그가 말하는 이른바 ‘meat proxy review’의 위험은, AI가 낸 의견을 다른 AI가 반박하고 사람이 형식적으로 확인하는 순환이다. 이 경우 늘어난 것은 안전이 아니라 텍스트의 양일 수 있다.

버그가 나면 작성자가 아니라 시스템을 고친다

가장 생산적인 전제는 small-change에서 나온 오류를 개인의 일탈로만 보지 않는다는 것이다. 빠른 경로가 만든 사고는 자격 판정, 테스트, 정적 분석, 배포 가드레일, 감사 로그 중 어디가 부족했는지를 알려 주는 신호로 취급한다. 이 관점은 자동 승인 자체보다 더 어렵다. 자동화가 믿을 만하려면 테스트가 빨라야 하고, 권한·민감 경로가 분류돼야 하며, 사고 뒤에 기준을 조정할 조직적 여유가 필요하기 때문이다.

초기에는 전체 변경의 약 10%만 이 경로에 들어간다고 한다. 숫자가 작아 보이지만, 이는 실패가 아니라 보수적으로 시작했다는 뜻일 수 있다. 빠른 길의 비율을 목표로 삼으면 팀은 기준을 느슨하게 만들어 숫자만 키우기 쉽다. 반대로 예외와 사고를 관찰하며 검증 범위를 넓히면, 비율은 신뢰의 결과가 된다. ‘더 많은 자동 승인’보다 ‘더 많은 변경을 안전하다고 설명할 수 있는 능력’이 목표가 되어야 한다.

커뮤니티가 던지는 반론: 작은 diff는 작은 맥락이 아니다

이 글의 직접 토론은 아직 널리 축적되지 않았지만, 최근 공유·요약 글들은 기준을 빌드가 강제하고 민감 영역을 제외하는 점을 실험의 강점으로 본다. 한편 Hacker News에서 오래 이어진 ‘리뷰 없는 기본값’과 작은 변경 논의는 중요한 반론을 제공한다. 작은 PR만 각각 보면 공통 추상화의 붕괴, 비슷한 코드의 중복, 여러 변경을 합쳤을 때의 설계 문제가 잘 보이지 않을 수 있다는 지적이다. 다른 참여자들은 리뷰의 가치는 줄 수보다 변경의 목적, 테스트 계획, 사전 설계 대화에 달려 있다고 말한다.

이 반론은 Larson의 제안을 무효화하기보다 경계를 선명하게 한다. 자동화가 잘하는 것은 정해진 정책 위반과 반복적 검증이다. 반면 제품 방향, 서비스 경계의 재설계, 팀원이 무엇을 배워야 하는가 같은 질문은 diff 크기나 과거 병합 횟수만으로 판정하기 어렵다. 그래서 원문에 함께 등장하는 ‘PR 묶음 단위의 리뷰’는 빠른 개별 승인의 보완책이다. 작은 변경은 빨리 통과시키되, 인간의 대화는 사라지는 대신 더 큰 패턴과 설계에 집중해야 한다.

우리 팀에 남는 질문

이 모델을 곧바로 복제할 필요는 없다. 금융 서비스와 다수의 내부 도구를 가진 조직의 기준을 작은 팀에 가져오면 과잉 절차가 될 수 있다. 다만 각 팀은 이번 주에 세 가지를 물어볼 수 있다. 첫째, 현재 리뷰가 실제로 잡는 위험은 무엇인가. 둘째, 그 위험 중 무엇을 테스트·권한 규칙·배포 관찰로 더 싸고 일관되게 잡을 수 있는가. 셋째, 자동화로 아낀 리뷰 시간을 설계 토론과 동료 성장에 정말 다시 투자할 수 있는가.

AI 시대의 리뷰 문제는 사람을 승인 버튼에서 제거하는 문제가 아니다. 어떤 변경이 충분히 검증됐다는 판단을 코드와 운영 시스템 안에 얼마나 정직하게 새길 수 있는가의 문제다. small-change는 그 답을 완성했다고 주장하지 않는다. 오히려 오래된 관행을 매주 다시 검증할 준비가 있는가를 묻는, 작지만 불편한 실험이다.