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

새로운 AI 코드리뷰 도구를 도입하자는 제안이 왔다. "기존 것보다 좋다"고 했다. 데모도 인상적이었다.

그런데 "좋다"는 게 뭘까? 우리 코드베이스에서, 우리가 실제로 겪는 버그를, 기존 도구만큼 잡아줄까? 데모와 벤치마크 점수로는 이 질문에 답할 수 없다. 그래서 우리는 **백테스트**를 설계했다. 과거의 실제 버그들을 두 도구에게 다시 리뷰시켜, 누가 무엇을 잡는지 실측하는 것이다.

이 글은 그 백테스트의 설계와, 하면서 빠질 뻔했던 함정 세 가지의 기록이다. 결과 수치보다 **함정**이 더 중요하다 — 이걸 모르고 하면 잘못된 의사결정을 확신을 갖고 내리게 된다.

## 백테스트 설계

**정답셋**: 기존 리뷰봇이 과거에 "크리티컬"로 잡았고 사람이 유효하다고 확인한 실제 버그 18건. 주 언어가 다른 두 저장소(Python·Scala/JVM)에서 뽑아 언어 편향을 확인할 수 있게 했다.

**동일 조건 재현**: 각 버그가 포함됐던 PR의 diff를 그대로 재생(replay)해 두 도구에게 동일한 입력을 줬다. 채점 기준(잡았다/부분적으로 잡았다/놓쳤다)은 리뷰를 돌리기 전에 문서로 못 박았다 — 결과를 보고 기준을 움직이는 것을 막기 위해서다.

**측정 항목**: 검출력만 보면 안 된다. 우리는 네 축을 쟀다 — ①정답 버그 검출력 ②오탐(깨끗한 코드에 대한 헛경보) ③응답 속도 ④심각도 신호의 유용성.

## 결과 요약

- **검출력(Python)**: 도구 A 50% vs 기존 봇 56% — 사실상 대등
- **검출력(Scala)**: 기존 봇 67% vs 도구 A 40% — 언어에 따라 격차가 벌어짐
- **오탐**: 도구 A ~3건 vs 기존 봇 ~0건 — 정밀도는 기존 봇 우위
- **속도**: 기존 봇이 약 1.5배 빠름
- 도구 A의 결정적 강점은 **비용 0 + 원클릭 설치**

결론은 "대체"가 아니라 **병행**이었다. 서로 놓치는 영역이 달랐고, 비용·설치 편의성 같은 비기술 요소도 실재하는 가치였기 때문이다. 하지만 이 결론보다 중요한 건, 결론에 도달하는 과정에서 발견한 함정들이다.

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

비교 도중 이상한 점을 발견했다. 우리 리뷰봇의 성능이 기대보다 낮았다. 로그를 파보니 — 봇에 모델이 고정(pin)되어 있지 않아서, **런타임 기본값인 하위 티어 모델로 돌고 있었다.**

같은 정답셋을 상위 티어 모델로 교체해 재실행하자 검출력이 56% → 61%로 올랐다. 특히 **여러 파일과 규칙을 엮어야 보이는 크로스컨텍스트 버그**(빌드 산출물 미재생성, 실행 순서 의존성, 중복 정의 등)에서 상위 모델의 이득이 컸다.

교훈: AI 도구를 비교할 때 "도구 이름"만 보면 안 된다. **그 도구가 실제로 어떤 모델·버전으로 실행되는지 로그로 확정**하고 기록해야 한다. 우리는 실행 당일의 CI 로그에서 모델 문자열을 추출해 문서에 박았다. 이게 없으면 비교 결과는 재현도 해석도 불가능하다.

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

백테스트를 마치고 보고서를 쓰다가 스스로 발견한 문제가 있다. 우리의 정답셋은 "**기존 봇이 잡았던** 버그"였다. 즉 기존 봇에게 절대적으로 유리한 세트다. 기존 봇의 56%는 "자기가 잡았던 걸 다시 잡는" 비율이니 과대평가다.

그래서 봇과 무관하게 발생한 **실제 hotfix 버그들**로 정답셋을 다시 만들어 재측정했다. 결과: 두 도구 모두 검출력이 **~30% 이하**로 떨어졌다. 이게 진짜 실력이다.

이 재측정이 준 것은 겸손만이 아니다. "AI 리뷰가 놓치는 버그의 유형"이 드러났고, 그게 곧 리뷰 프롬프트와 파이프라인의 개선 백로그가 됐다. 자기에게 유리한 정답셋을 스스로 의심하는 것 — 백테스트의 절반은 여기에 있다.

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

같은 코드를 같은 도구에게 여러 번 리뷰시키면, **매번 지적이 조금씩 다르다.** 한 번의 비교로 "A가 이 버그를 잡았다/놓쳤다"를 단정하면, 그 결과는 동전 던지기의 스냅샷일 수 있다.

그래서 판정이 갈리는 케이스는 복수 실행으로 확인하고, "안정적으로 잡는다 / 가끔 잡는다 / 안정적으로 놓친다"를 구분했다. 비결정성 자체도 도구의 속성이다 — 리뷰 결과가 들쭉날쭉한 도구는 개발자의 신뢰를 잃는다.

## 정리: 도구 선택도 엔지니어링이다

AI 도구 도입 의사결정에서 우리가 얻은 체크리스트:

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

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