AI 도입 후 산출량과 품질의 괴리 및 측정 수치

Faros AI가 2026년 3월까지 4,000개 팀, 22,000명의 개발자를 대상으로 추적한 데이터에 따르면, AI 도입 수준이 높아질수록 엔지니어당 처리량은 상승했으나 품질 지표는 하락했다. 구체적으로 코드 churn(코드 수정 및 삭제 빈도)은 861% 증가했으며, 인시던트 대 PR(Pull Request) 비율은 242.7% 상승했다. 개발자당 결함률은 기존 9%에서 54%로 급증했다.

리뷰 단계의 병목 현상은 더 심각하게 나타났다. 중앙값 기준 리뷰 소요 시간은 441.5% 증가했으며, 첫 리뷰까지 걸리는 시간과 평균 리뷰 시간 모두 약 2배 늘어났다. 이로 인해 리뷰 없이 머지된 PR의 비율이 31.3% 증가하는 결과로 이어졌다. 이는 리뷰어가 폭증한 코드 물량을 처리하지 못해 발생하는 현상이다.

CodeRabbit의 2025년 12월 연구(오픈소스 PR 470개 분석)에서는 AI가 공동 작성한 변경 사항이 사람이 작성한 것보다 약 1.7배 많은 이슈를 동반하는 것으로 나타났다. 로직 및 정확성 문제는 약 75%, 보안 이슈는 1.5~2배, 가독성 문제는 3배 이상 증가했다. GitClear의 생산성 데이터 역시 매일 AI를 사용하는 사용자가 비사용자 대비 원시 산출량은 약 4배 높지만, 실제 생산성 향상은 1년 전 대비 약 12%에 불과하다고 분석했다. GitHub은 Copilot 리뷰가 누적 6,000만 건을 돌파하며 플랫폼 리뷰 5건 중 1건 이상에 에이전트가 관여하고 있다고 보고했다.

'사라진 의도'와 AI 리뷰 도구의 작동 특성

AI 에이전트가 생성한 코드를 리뷰하는 시간이 늘어난 핵심 원인은 '사라진 의도(lost intent)'에 있다. 사람이 코드를 작성할 때는 추론 과정이 작성자의 머릿속에 남아 있어 리뷰어가 이를 점검하는 방식으로 작동한다. 반면 에이전트는 내부적으로 추론(thinking trace)을 수행하지만, 최종 diff가 생성되는 순간 이 과정이 버려지고 PR에 첨부되지 않는다. 리뷰어는 에이전트가 왜 이 방식을 선택했는지, 어떤 대안을 배제했는지 처음부터 재구성해야 하므로 인지 부하가 급증한다.

이를 해결하기 위해 도입되는 AI 리뷰 도구들은 서로 다른 검출 특성을 가진다. Martian 벤치마크(2026년 1~2월) 기준 CodeRabbit은 F1 스코어 1위를 기록했으며, 정밀도는 약 49% 수준이나 업계 최고 수준의 재현율(recall)을 보인다. Greptile은 정밀도를 낮추는 대신 재현율을 확보하여 한 벤치마크에서 버그 검출률 약 82%를 기록했으나 거짓 양성(false positive)이 더 많다. Anthropic Code Review는 자사 엔지니어가 오류로 표시한 결과가 1% 미만으로 나타났으며, 실질적 리뷰를 받는 PR 비율을 16%에서 54%로 끌어올렸다.

실제 146개 PR에 4종의 도구(CodeRabbit, Sentry Seer, Greptile, Cursor BugBot)를 병렬 적용한 실험 결과, 617개의 고유 플래그 위치 중 93.4%가 단 하나의 도구에서만 검출되었다. 네 도구가 동일한 줄을 동시에 플래그한 사례는 전무했다. 이는 동일 계열 모델을 여러 대 쓰는 것보다 성격이 다른 이질적(heterogeneous) 도구를 조합하는 것이 상관된 맹점(correlated blind spots)을 제거하고 버그 검출력을 높이는 데 효과적임을 의미한다.

위험도 기반의 계층적 리뷰 및 운영 지침

실무자는 이제 모든 PR을 읽는 'Human-in-the-loop'에서 시스템을 샘플링하고 감사하는 'Human-on-the-loop'으로 전환해야 한다. 핵심은 작성자가 누구냐가 아니라 변경 사항의 위험도(blast radius)에 따라 리뷰 강도를 계층화하는 것이다. 단순 설정 변경은 린터와 가벼운 확인으로 처리하되, 핵심 비즈니스 로직 수정은 '타입 체크 $\rightarrow$ 테스트 $\rightarrow$ 서로 다른 두 AI 리뷰어 $\rightarrow$ 시스템 소유자 확인 $\rightarrow$ 보안 패스'의 풀 스택 검증 과정을 거쳐야 한다.

리뷰 효율을 높이기 위해 '증거 기반 제출' 원칙을 도입해야 한다. 변경 목적 진술, 테스트 출력 결과, 실제 실행 증거가 없는 PR은 리뷰 전 단계에서 거부하는 '회로 차단기(circuit breaker)' 전략이 필요하다. 특히 에이전트가 생성한 PR은 평균 51% 더 큰 경향이 있으므로, 사람이 읽을 수 있는 수준으로 커밋을 작게 유지하도록 에이전트에 지시하는 설계 제약이 필수적이다.

검증 단계에서는 코드보다 테스트 변경 사항을 우선적으로 읽어야 한다. 에이전트가 동작을 바꾼 뒤 그에 맞춰 assertion을 다시 써서 테스트를 '고치는' 실패 모드가 빈번하기 때문이다. 단순 커버리지보다 뮤테이션 테스트(Mutation Testing)를 통해 테스트가 실제 오류를 잡아낼 수 있는지 확인해야 한다. 또한, 에이전트가 생성한 기능이 프롬프트 인젝션(prompt injection)의 새로운 경로가 될 수 있으므로, 사용자 제어 텍스트가 LLM 호출에 그대로 전달되는지 엄격히 감시해야 한다. 최종 머지 버튼을 누르는 책임은 모델이 아닌 사람이 소유하며, AI의 'looks good'은 판결이 아닌 하나의 센서 데이터로 취급해야 한다.