핵심 요약
AI가 코드를 대량 생산하면서 사람이 PR diff를 읽는 방식의 코드 리뷰는 병목이 되었고, 품질도 보장하지 못한다.
앞으로의 인간 역할은 코드 확인이 아니라 "무엇을 만들지"를 명확히 하는 스펙·수용 기준을 설계하고, 기계적으로 검증 가능한 레이어를 쌓는 것이다.
코드 리뷰가 '품질 게이트'가 되기 어려웠던 이유
코드 리뷰는 원래 "다른 사람이 한 번 더 봐서 실수를 잡자"는 사회적 장치였지만, 규모가 커질수록 실제로는 대기열과 형식적 승인(러버 스탬프)을 만들기 쉽습니다.
게다가 소프트웨어는 오래전부터 "리뷰가 있어도 장애는 난다"는 전제 위에 굴러왔습니다.
그래서 기능 플래그, 점진적 롤아웃, 즉시 롤백처럼 실패를 흡수하는 운영 장치를 발전시켜 왔고, 이는 리뷰가 유일한 안전장치가 아니라는 방증입니다.
AI가 만든 새 병목: 더 많은 PR, 더 긴 리뷰 시간
AI 도입 팀은 작업 완료량과 PR 머지가 크게 늘지만, 리뷰 시간도 함께 늘어난다는 데이터가 제시됩니다.
변화의 개수와 변화의 크기가 동시에 커지면, 사람의 "읽기 속도"가 병목이 됩니다.
특히 AI가 생성한 코드는 맥락 없이 쏟아져 나오는 경우가 많아, 동료가 쓴 코드보다 더 많은 정신적 노력을 요구한다는 불만이 생깁니다.
"AI 코드 리뷰"는 연명 치료일 수 있다
AI가 코드를 쓰고 AI가 리뷰까지 한다면, PR 화면에서 사람과 AI가 줄다리기하는 구조 자체가 어색해집니다.
이 관점에서는 PR 이후 리뷰는 점점 덜 중요해지고, 개발 주기의 더 앞(shift-left)에서 자동 검증이 돌도록 설계하는 편이 비용도 낮습니다.
핵심 가치는 "승인 게이트"가 아니라 "빠른 반복 루프"에 있다는 주장입니다.
코드 대신 '의도'를 검토하라: 스펙이 소스 오브 트루스
사람이 읽어야 할 것은 500줄 diff가 아니라 문제 정의, 제약, 계획, 수용 기준(acceptance criteria)입니다.
이 구조에서는 스펙이 진짜 원본이고 코드는 스펙에서 파생된 산출물에 가깝습니다.
인간의 승인 질문도 "이 코드를 잘 썼나?"에서 "올바른 문제를 올바른 제약으로 풀고 있나?"로 이동합니다.
신뢰를 만드는 방식: 판단에서 '검증 산출물'로
LLM은 지시를 자주 벗어나고 자기확신도 강합니다.
그래서 "잘 됐니?"라고 묻는 대신, 실패하면 변명할 수 없는 테스트·체크·검증 스크립트 같은 산출물을 만들게 해야 합니다.
요지는 인간의 감각적 판독을 늘리는 게 아니라, 기계적으로 통과/실패가 나는 장치를 늘리는 것입니다.
스위스 치즈 모델: 여러 레이어로 구멍을 어긋나게 하기
단일 관문(코드 리뷰)이 모든 결함을 잡는다는 발상 대신, 약한 방어막을 여러 겹 쌓아 빈틈이 겹치지 않게 만드는 방식이 제안됩니다.
첫 레이어는 다중 시도입니다.
하나의 에이전트에 올인하지 말고 여러 에이전트가 서로 다른 해법을 내게 한 뒤, 테스트 통과율·diff 크기·의존성 증가 여부 같은 신호로 더 나은 출력을 고릅니다.
두 번째 레이어는 결정적 가드레일입니다.
타입체크, 테스트, 계약 검증, 린트처럼 '의견'이 아니라 '사실'로 판정하는 장치가 필요하고, 이 검증 항목은 코드가 나오기 전에 스펙에서 먼저 정의되어야 합니다.
세 번째 레이어는 인간이 수용 기준을 작성하는 것입니다.
BDD처럼 "자연어로 기대 행동을 적고, 그것을 테스트로 자동화"하는 방식이 AI 시대에는 비용이 아니라 핵심 업무가 됩니다.
네 번째 레이어는 권한 설계입니다.
에이전트가 접근 가능한 파일·설정·인프라 범위를 과업 단위로 좁히고, 인증/DB 스키마/새 의존성 추가 같은 행위는 자동으로 인간 검토로 에스컬레이션되게 만듭니다.
다섯 번째 레이어는 적대적 검증입니다.
작성 에이전트와 검증 에이전트를 분리하고, 한쪽은 수정 권한 없이 깨뜨리기만 하게 하면(레드팀/블루팀), "자기 코드 자기 검증"의 약점을 줄일 수 있습니다.
"좋은 코드"의 정의가 바뀐다
에이전트 시스템의 동기는 "주어진 일을 끝내기"이지, 장기적 정확성이나 비즈니스 적합성이 아닐 수 있습니다.
따라서 장기적 요구를 보장하는 일은 코드 안의 미학보다 제약·검증·관측·롤백 설계에 더 많이 걸립니다.
미래의 운영 원칙은 "빨리 배포하고, 강하게 관측하고, 더 빨리 되돌린다"에 가깝습니다.
인사이트
PR diff를 더 열심히 읽는 것은 AI 시대의 근본 해법이 되기 어렵고, 인간의 시간을 "의도와 제약을 명료하게 만들기"에 재배치해야 합니다.
다음 스프린트부터 적용할 수 있는 실천은 간단합니다: 과업마다 수용 기준을 먼저 5~10줄로 쓰고, 그 기준을 통과/실패로 판정할 테스트·체크리스트를 코드보다 먼저 합의하세요.
사람이 코드를 읽어야만 안심되는 구간(인증, 결제, 스키마 변경 등)은 "예외적으로 읽는 구간"이 아니라 "항상 에스컬레이션되는 구간"으로 규칙화하면, 불안은 줄고 속도는 유지됩니다.
출처 및 참고 : How to Kill the Code Review - by Ankit Jain - Latent.Space
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.