AI 코딩 도구가 팀에 정착하면서 예상치 못한 병목이 생겼다. 코드를 쓰는 속도는 빨라졌는데, 코드를 검증하는 속도가 따라가지 못하는 것이다. VentureBeat 보고에 따르면 AI 생성 코드 변경의 43%가 프로덕션에서 디버깅이 필요하다. CodeRabbit은 AI 코드가 PR당 이슈를 인간 코드 대비 1.7배 더 많이 만들어낸다고 측정했다. 그리고 치명적인 것은 그 오류의 60%가 '조용한 실패(silent failure)'—컴파일도 되고 테스트도 통과하지만 결과값이 틀린 코드라는 점이다.
문제는 AI가 '나쁜 코드'를 쓴다는 게 아니다. AI는 다른 방식으로 실수한다. 전통적인 리뷰가 사람의 실수(논리 오류, 누락, 오타)를 잡도록 설계되어 있다면, AI의 실패 모드는 패턴이 다르다. dev.to에 공개된 분석에 따르면 수천 건의 AI 생성 diff를 검토한 결과 버그 패턴은 다섯 가지로 수렴한다.
① 그럴듯하지만 틀린 로직. 가장 흔하고 가장 잡기 어렵다. 코드는 정상 동작하고 기본 테스트는 통과하지만, 엣지 케이스를 조용히 틀리게 처리한다. 날짜 파서가 04/05/2026을 미국 형식으로 파싱하는데 코드베이스는 ISO 8601을 쓰는 경우가 전형적 사례다. 에러도 없고 크래시도 없다. 그냥 틀린 데이터다. ② 자신감 넘치는 리팩토링이 호출자를 깬다. 모듈 내부는 깔끔해졌는데, 파라미터명이 바뀌거나 리턴 타입이 달라진다. TypeScript가 명시적 인터페이스 변경은 잡아도 3파일 떨어진 호출자의 동작 변화는 못 잡는다. ③ 구현을 테스트하는 테스트. AI가 작성하는 테스트는 '통과하도록' 만들어진다. expected 값이 함수의 리턴값을 그대로 복붙한 경우, 또는 모든 걸 mock해서 정작 코드가 아닌 mocking framework를 검증하는 경우가 대표적이다. ④ 유사 컴포넌트 간 copy-paste 드리프트. 첫 번째 컴포넌트에서 복사하되 일관성 없이 복사한다. 한 엔드포인트는 입력 검증을 하고 다른 엔드포인트는 안 한다. 개별로 보면 괜찮지만 나란히 놓으면 문제가 드러난다. ⑤ 의존성 난립. 날짜 피커 하나 추가하는데 프로젝트에 이미 있는 date 라이브러리를 무시하고 새 패키지를 설치한다.
이 다섯 패턴의 공통점이 있다. AI는 '현재 파일 안의 맥락'에는 능숙하지만, '프로젝트 전체의 암묵적 관습'에는 무지하다. 리뷰어가 AI 코드를 볼 때 "방금 합류한 스마트한 외주 개발자의 코드"처럼 가정해야 하는 이유다. 관습을 문서로 명시하지 않으면 AI는 알 수 없다.
그렇다면 AI 리뷰 자체는 믿을 수 있을까. 사내 AI 리뷰 도구를 운영하며 품질을 정량 측정한 사례(GeekNews)가 이 질문에 직접 답한다. 초기 벤치마크 점수는 33점이었다. "잘 되는 것 같다"는 감각은 극소수 성공 사례에 의한 착각이었다. 서브에이전트 오케스트레이션을 시도했더니 탐지율은 오히려 떨어지고 비용은 1.5~3배 올랐다. 컨텍스트 압축에 의한 정보 손실, 관심사 제한으로 인한 시야 축소, 교차 영역 책임 공백이 원인이었다. 프롬프트 자동 튜닝 루프를 돌렸더니 벤치마크 데이터가 오염되어 "Division by Zero를 체크하라" 같은 구체적 지시의 나열로 수렴했다. 외부 벤치마크로 모델 선택 근거를 세울 수 없다는 것도 확인했다.
이 팀이 돌파구로 설계한 지표가 Adoption Rate다. 리뷰가 실제 코드 변경으로 이어지면 'adopted', 답글로 상호작용만 있으면 'engaged', 아무 반응이 없으면 'noised'로 분류한다. 리뷰 시점 commit SHA와 머지 시점 SHA를 비교해, 코멘트 라인 ±3줄 내 변경이 있으면 adopted로 판정하는 방식이다. Opus 4.6과 GPT-5.2 Codex를 PR 번호 홀짝으로 A/B 테스트한 결과, Codex가 느리지만 꼼꼼하고 재요청 시점에서도 유효한 추가 지적이 많아 Codex로 고정했다. 세 가지 추가 조치—불확실한 지적을 질문으로 바꾸기, PR 템플릿에 Intent/Decisions 섹션 추가, 리뷰 반영 확인 시 스레드 자동 resolve—로 오탐을 29% 줄이고 월간 반영률 63%를 달성했다. 단, 이 팀은 스스로 경계한다. "채택 = 정답"이 아니므로 Adoption Rate 지표 역시 오염될 수 있다고.
생성 단계의 품질을 올리는 가장 직접적인 방법은 AI에게 주는 규칙을 정교화하는 것이다. Cursor TypeScript 규칙 사례(dev.to)는 AI가 TypeScript를 쓸 때 반복적으로 저지르는 실수 여섯 가지를 규칙으로 차단하는 전략을 제시한다. any 타입을 금지하고 unknown과 타입 가드를 쓰게 하고, boolean 플래그 조합 대신 discriminated union으로 불가능한 상태를 타입 레벨에서 제거하고, 제네릭에 extends 제약을 반드시 붙이고, catch 블록에서 에러 타입을 명시하고, Result 패턴으로 호출자가 실패 경로를 강제로 처리하게 한다. 핵심은 "더 나은 프롬프트"가 아니라 "더 나은 규칙"이라는 관점이다. 규칙은 CLAUDE.md나 Cursor rules 파일에 팀 공유 자산으로 관리해야 한다.
이 세 가지 사례가 수렴하는 구조적 교훈이 있다. 생성(Generation)·리뷰(Review)·측정(Measurement) 세 단계가 각각 독립적 방어선이어야 한다는 것이다. 생성 단계에서는 규칙(TypeScript rules, CLAUDE.md)으로 AI의 나쁜 습관을 사전 차단한다. 리뷰 단계에서는 AI 코드의 고유한 실패 패턴—경계, 암묵적 관습, 호출자 영향—을 기준으로 검토한다. 측정 단계에서는 "잘 되는 것 같다"는 감각이 아니라 Adoption Rate처럼 행동 기반 지표로 리뷰 품질을 정량화한다. 세 단계 중 하나라도 빠지면 나머지 두 개가 버텨주지 못한다.
팀 리드에게 내일 당장 적용 가능한 순서로 정리하면 이렇다. 첫째, 팀의 AI 규칙 파일에 any 금지와 discriminated union 강제를 오늘 추가한다. 둘째, AI 코드 리뷰 체크리스트를 다섯 버그 패턴 기준으로 재작성한다. 셋째, AI 리뷰 도구의 성과를 '피드 수'가 아니라 '실제 코드 변경으로 이어진 비율'로 측정하기 시작한다. AI가 코드를 쓰는 속도는 이미 팀의 리뷰 속도를 앞질렀다. 품질 방어선을 구조로 심지 않으면, 속도가 빠를수록 부채가 빠르게 쌓인다.