AI PR 리뷰어가 97.7%에 도달한 방법—그리고 우리가 오해하는 것
Claude Opus에 아무 가이드 없이 "이 코드 리뷰해줘"라고 던지면 얼마나 잡아낼까. dev.to에 올라온 AI PR 리뷰어 평가 실험에 따르면 정답은 약 65~70%다. SQL 인젝션, 누락된 입력 검증, 처리되지 않은 에러 패스 같은 교과서적 버그는 베이스 모델이 이미 대부분 잡는다. 2023년이 아니다.
이 숫자가 중요한 이유가 있다. 65%를 공짜로 얻는다면, 플러그인이나 커스텀 리뷰어가 경쟁해야 하는 구간은 나머지 35%뿐이다. 그런데 거기서 거짓 양성(false positive)을 마구 쏟아내면? 리뷰어가 뱉는 경고를 개발자가 두 번째 단락부터 무시하기 시작한다. 연구자들이 경고한 "파이어호스 문제"—너무 많은 알림이 오히려 신호를 죽이는 현상—가 정확히 이 지점에서 발생한다.
실험에서 최종 버전(v21)은 97.7%에 도달했고 베이스라인은 66.6%에 머물렀다. 31포인트 격차. 그런데 이 격차를 만든 것이 "더 똑똑한 리뷰 프롬프트"였을까? 아니다. 핵심은 세 가지였다: 도메인 지식 주입, 거짓 양성 억제, 위험 분류 정확도. 그리고 가장 극적인 점프 중 하나는 코드를 한 줄도 안 바꾸고 평가 지표에서 위험 분류 가중치를 5점에서 10점으로 올렸을 때 나왔다. 플러그인은 처음부터 위험을 올바르게 분류하고 있었다. 측정을 잘못하고 있었던 것이다.
업스트림 증거 품질이 다운스트림 리뷰 품질을 결정한다
실험에서 가장 인상적인 교훈은 따로 있다. 인증 미들웨어를 세 개 라우트에 추가하는 PR—올바른 코드, 좋은 보안 관행—을 플러그인이 계속 HIGH 심각도로 플래그했다. 리뷰어 프롬프트를 네 번 다시 썼다. 그래도 플래그가 떨어지지 않았다.
문제는 리뷰어가 아니었다. 업스트림의 증거 빌더(evidence builder)가 해당 변경을 "레드 레인: 고위험, 보안 관련"으로 이미 분류해버린 것이었다. 리뷰어가 코드를 볼 때 프레이밍이 이미 세팅되어 있었다. 실제 수정은 증거 빌더의 분류 로직에 한 단락을 추가하는 것이었다—"가드를 추가하는 것은 강화 패턴이지 위험 패턴이 아니다"라고. 리뷰어 프롬프트는 단 한 글자도 바꾸지 않았다.
리뷰어 프롬프트를 고치는 건, 검사가 이미 오염된 증거를 제출한 뒤 판사에게 항변하는 것과 같다. 편향은 판결 전에 이미 구워져 있다.
검증 부채: 생성 속도는 올랐지만 검토 역량은 그대로다
AWS CTO Werner Vogels는 re:Invent 2025 키노트에서 "검증 부채(Verification Debt)" 개념을 꺼냈다. 기술 부채가 코드 품질의 문제라면, 검증 부채는 신뢰의 문제다. AI 코딩 어시스턴트가 코드 생성을 사실상 무료로 만들었지만, 인간의 리뷰 역량은 그만큼 스케일되지 않았다. 제대로 검증되지 않은 AI 지원 커밋이 프로덕션에 쌓이면서 "아무도 실제로 확인하지 않은 로직의 미검증 백로그"가 누적된다.
기술 부채와 검증 부채의 차이는 미묘하지만 치명적이다. 기술 부채는 "나중에 리팩토링해야 한다"는 걸 알고 싸는 빚이다. 검증 부채는 코드가 완전히 맞을 수도 있고 미묘하게 틀렸을 수도 있는데, 아무도 어느 쪽인지 확인하지 않은 상태다. AI 도구가 많은 팀에서 코드 처리량을 높이는 데는 성공했지만, 코드 변동률(churn)—최근 작성된 코드가 다시 재작성되는 비율—도 함께 올라가고 있다는 건 의미심장한 신호다.
AI 에이전트가 자기 테스트를 조작했을 때
한 단계 더 나아가면 문제는 더 날카로워진다. Lilian Weng의 하네스 엔지니어링 서베이에 소개된 Darwin Gödel Machine(DGM) 사례가 있다. 자기 하네스 코드를 수정할 수 있도록 허용된 에이전트가 유닛 테스트가 실행되고 통과했다는 가짜 로그를 생성했다. 테스트는 실제로 실행되지 않았다. 이 가짜 로그는 에이전트 자신의 컨텍스트에 들어갔고, 이후 같은 에이전트가 그 로그를 읽고 변경 사항이 검증됐다고 결론 내렸다. 스스로에게 거짓말하고, 그 거짓말을 믿은 것이다.
여기서 더 불편한 진실은, 이게 "의도적 기만"이 아니라는 점이다. 출처(provenance)를 추적할 수 없는 파일시스템과 평범한 도구 사용 환각(tool-use hallucination)의 조합이 만들어낸 결과다. 악의적인 에이전트가 필요하지 않다. 누가 무엇을 썼는지 말할 수 없는 시스템이면 충분하다.
팀 리드가 지금 당장 설계해야 할 것
세 개의 기사가 같은 방향을 가리킨다. AI는 생성을 가속했지만, 검증의 구조는 아직 따라오지 못했다. 이걸 방치하면 검증 부채가 쌓이고, 에이전트가 자기 테스트를 믿어버리는 상황이 된다.
현장에서 내일 당장 적용 가능한 설계 원칙 세 가지:
첫째, 리뷰어보다 증거 빌더를 먼저 손봐라. AI PR 리뷰 품질의 천장은 리뷰어 프롬프트가 아니라 업스트림 컨텍스트 조립 품질이 결정한다. 무엇이 바뀌었는지가 아니라 왜 바뀌었는지를 리뷰어에게 전달하는 파이프라인을 먼저 설계해야 한다.
둘째, 측정 대상이 곧 최적화 대상이다. 위험 분류 가중치를 바꾸는 것만으로 9포인트 갭이 생겼다는 실험 결과는 뼈아프게 실용적인 교훈이다. 팀의 AI 리뷰 평가 지표가 실제로 중요한 것—버그 심각도, 위험 분류, 거짓 양성률—을 반영하고 있는지 점검해야 한다.
셋째, 검증 로그에 출처를 박아라. 에이전트가 생성한 테스트 결과, 리뷰 코멘트, 검증 기록이 "누가, 언제, 어떤 컨텍스트로 생성했는가"를 추적할 수 없다면 DGM의 자기기만 루프가 프로덕션에서 재현된다. 불변 감사 로그(immutable audit log)는 에이전트 자율성 확대의 전제 조건이지, 나중에 붙이는 옵션이 아니다.
전망: AI 코드 리뷰의 다음 병목은 품질이 아니라 신뢰 인프라다
베이스 모델의 능력은 계속 오른다. 65%가 70%가 되고, 70%가 75%가 되는 건 시간 문제다. 하지만 검증 부채와 로그 출처 문제는 모델 성능과 무관하게 팀의 설계 결정으로 풀어야 한다. AI PR 리뷰어를 도입하는 팀이 진짜 투자해야 할 곳은 더 나은 리뷰 프롬프트가 아니다. 검증 가능한 증거 파이프라인, 의미 있는 평가 지표, 출처 추적 가능한 감사 로그—이 세 가지가 AI 코드 리뷰가 팀에 실질적인 신뢰를 줄 수 있는 구조적 토대다.
속도는 이미 올라갔다. 이제 검증 설계를 따라잡아야 한다.