AI 코드리뷰 도구, 데모 말고 백테스트로 검증하기

도구 도입 의사결정을 데이터 문제로 바꾸는 법 — 그리고 빠지기 쉬운 함정 세 가지

TL;DR — 3줄 요약

새 AI 코드리뷰 도구의 도입 판단을 데모가 아니라 과거 실제 버그 18건의 백테스트로 내렸다 — 결론은 "대체"가 아닌 병행.
비교 자체보다 중요한 건 세 가지 함정: ①봇의 실제 모델 버전을 실측하라 ②정답셋의 선택편향을 의심하라 ③단회 비교를 믿지 마라.
얻은 것: 도구 도입이라는 취향·정치의 문제를 재사용 가능한 데이터 문제(백테스트 하네스)로 바꿨다.

검출력 · Python50 vs 56%도구 A vs 기존 봇 — 대등

검출력 · Scala40 vs 67%언어 따라 격차

오탐 (헛경보)~3 vs ~0정밀도는 기존 봇 우위

상위 티어 재런56 → 61%모델이 결과를 바꾼다

1. 왜 백테스트인가

새로운 AI 코드리뷰 도구를 도입하자는 제안이 왔다. "기존 것보다 좋다"고 했다. 데모도 인상적이었다. 그런데 "좋다"는 게 뭘까? 우리 코드베이스에서, 우리가 실제로 겪는 버그를, 기존 도구만큼 잡아줄까? 데모와 벤치마크 점수로는 답할 수 없다. 그래서 과거의 실제 버그들을 두 도구에게 다시 리뷰시켜 실측했다.

2. 백테스트 설계

백테스트 파이프라인 — 채점 기준을 리뷰 실행 전에 문서로 고정하는 것이 핵심이다

정답셋: 기존 봇이 과거에 "크리티컬"로 잡았고 사람이 유효 확인한 실제 버그 18건. 주 언어가 다른 두 저장소(Python·Scala/JVM)에서 뽑아 언어 편향을 볼 수 있게 했다.
동일 조건: 각 버그가 포함된 PR의 diff를 그대로 재생해 동일 입력을 부여. 채점 기준(잡음/부분/놓침)은 실행 전에 문서로 고정 — 결과를 보고 기준을 움직이는 것을 막기 위해.
측정 4축: 검출력 · 오탐 · 속도 · 심각도 신호. 검출력만 보면 안 된다.

결과는 위 스탯 타일 그대로다. 결론은 "대체"가 아니라 병행 — 서로 놓치는 영역이 달랐고, 도구 A의 "비용 0 + 원클릭 설치"도 실재하는 가치였다. 하지만 이 결론보다 중요한 건 과정에서 발견한 함정들이다.

3. 빠지기 쉬운 함정 3가지

함정 1 — 봇이 어떤 모델로 돌고 있는지 "실측"하라

우리 봇의 성능이 기대보다 낮아 로그를 파보니, 모델이 고정(pin)돼 있지 않아 런타임 기본값인 하위 티어로 돌고 있었다. 상위 티어로 재실행하자 검출력 56%→61%, 특히 여러 파일·규칙을 엮어야 보이는 크로스컨텍스트 버그에서 이득이 컸다. 도구 이름이 아니라 실행 시점의 모델·버전을 CI 로그로 확정해 기록하라 — 없으면 비교는 재현도 해석도 불가능하다.

함정 2 — 정답셋의 출처가 결과를 결정한다 (선택편향)

우리 정답셋은 "기존 봇이 잡았던 버그"였다 — 기존 봇에게 절대적으로 유리한 세트다. 그래서 봇과 무관하게 발생한 실제 hotfix 버그로 다시 측정했더니 두 도구 모두 검출력이 ~30% 이하로 떨어졌다. 이게 진짜 실력이다. 이 재측정은 겸손만 준 게 아니라 "AI 리뷰가 놓치는 버그 유형"을 드러내 개선 백로그가 됐다.

함정 3 — AI 리뷰는 비결정적이다. 단회 비교를 믿지 마라

같은 코드를 같은 도구에 여러 번 리뷰시키면 매번 지적이 조금씩 다르다. 한 번의 비교는 동전 던지기의 스냅샷일 수 있다. 판정이 갈리는 케이스는 복수 실행으로 "안정적으로 잡음/가끔 잡음/안정적으로 놓침"을 구분했다. 비결정성 자체도 도구의 속성이다.

4. 도구 도입 체크리스트

데모가 아니라 자기 코드베이스의 과거 버그로 백테스트하라
채점 기준은 실행 전에 문서로 고정하라
도구가 실제 사용하는 모델·버전을 로그로 실측하라 — 티어가 결과를 바꾼다
정답셋의 편향을 의심하고 독립적인 세트(hotfix 등)로 교차 검증하라
복수 실행으로 비결정성을 측정하라
검출력 외에 오탐·속도·비용·설치 편의까지 축에 넣어라 — 의사결정은 벡터다

가장 큰 수확은 특정 도구의 승패가 아니었다. "도구 도입"이라는, 보통 취향과 정치로 결정되는 문제를 데이터 문제로 바꿨다는 것이다. 다음에 또 새로운 도구가 나타나면 — 분명 나타난다 — 같은 하네스에 넣고 돌리기만 하면 된다.