AI 코드 리뷰는 몇 번 돌려야 할까
https://edgelog.dev/ko/blog/how-many-ai-code-reviews/
AI 코드 리뷰는 몇 번 돌려야 할까
같은 코드에 400회의 LLM 호출을 썼다. 리뷰 1회는 실제 결함의 34%만 본다. 그리고 가장 자주 지적된 항목 4개는 전부 오탐이었다.
edgelog.dev
AI 코드 리뷰는 몇 번 돌려야 할까? 약 400번의 LLM 호출로 직접 측정해봤습니다
AI로 코드를 작성하고 리뷰까지 맡기다 보면 생각보다 자주 이런 상황을 만납니다.
코드 작성 → 리뷰 → 수정 → 다시 리뷰 → 다시 수정 → 또 리뷰...
처음 리뷰에서 문제를 몇 개 찾아 고쳤는데, 다시 리뷰하면 새로운 문제가 나옵니다.
그걸 고치고 다시 돌리면 또 다른 지적이 나옵니다.
리뷰 → 수정 → 리뷰 → 수정이 끝나지 않습니다.
그러다 보면 애매해집니다.
대체 언제 끝내야 할까?
- 지적(이슈)가 0개가 될 때까지?
- 테스트가 모두 통과하면?
- 2~3번 정도 돌리면 충분한가?
- 계속 돌릴수록 실제로 코드가 좋아지는가?
특히 이 과정을 에이전트나 CI에 자동화하려고 하면 더 문제가 됩니다.
review → fix → review → fix
루프를 만드는 건 어렵지 않은데, 언제 멈춰야 하는지에 대한 근거가 없습니다.
저도 최대 3라운드까지 자동 반복하는 워크플로를 사용하고 있었는데, 어느 순간 궁금해졌습니다.
정말 리뷰와 수정을 반복할수록 코드가 좋아질까?
그래서 실제 C 펌웨어 코드와 별도의 벤치마크 과제를 대상으로 리뷰어와 수정자를 분리하고, 약 400회의 LLM 호출을 돌려 직접 측정해봤습니다.
결과는 생각했던 것과 조금 달랐습니다.
1. 리뷰만 반복하는 것은 효과가 있었습니다
같은 코드를 수정하지 않고 반복해서 리뷰하면 실제 결함 커버리지가 대략
34% → 61% → 76%
로 증가했습니다.
같은 코드, 같은 모델이어도 매번 보는 문제가 달랐습니다.
어떤 실제 결함은 10번 중 한 번만 발견되기도 했습니다.
즉, AI 리뷰 한 번만으로 충분하다고 보기는 어려웠습니다.
2. 하지만 리뷰와 수정을 반복하는 것은 다른 문제였습니다
리뷰 → 수정 → 리뷰 → 수정
루프를 반복했을 때 테스트/계약 준수율은 그대로인데, 코드는 조건에 따라
+24% ~ +152%
까지 커졌습니다.
즉,
리뷰를 반복하는 것과 리뷰-수정 루프를 반복하는 것은 같은 일이 아니었습니다.
발견의 이득은 리뷰에서 나오지만, 수정할 때마다 새로운 변경과 새로운 위험도 함께 생깁니다.
3. 여러 번 지적됐다고 더 정확한 것도 아니었습니다
처음에는 여러 리뷰에서 반복적으로 나온 finding일수록 진짜일 가능성이 높을 거라고 생각했습니다.
그런데 대상 파일 하나만 보여준 조건에서는 반대였습니다.
오탐이 실제 결함보다 더 자주 반복적으로 보고됐습니다.
여러 AI가 독립적으로 리뷰하더라도 모두 같은 context를 잃고 있다면,
같은 잘못된 가정에서 출발해서 같은 방향으로 틀릴 수 있었습니다.
4. Repository context가 오탐 제거에 상당히 중요했습니다
대상 파일 하나만 보여준 조건에서는 고유 지적의 29%가 오탐이었습니다.
반면 호출자, 헤더, 초기화 경로 등 repository를 읽을 수 있게 하자 동일한 오탐들이 사라졌습니다.
코드 리뷰에서는 모델 자체뿐 아니라,
모델에게 어디까지 볼 수 있게 할 것인가
도 상당히 중요한 변수였습니다.
5. AI가 조용해졌다고 리뷰가 끝난 것도 아니었습니다
몇 라운드 이후 "지적 없음"이 나오더라도 같은 코드를 다른 관점으로 구조화해서 리뷰하면 새로운 failure mode가 다시 나왔습니다.
그래서 단순히
finding == 0
을 종료 조건으로 쓰기도 어려웠습니다.
6. 테스트 통과만으로도 종료를 판단하기 어려웠습니다
여러 조건에서 테스트 결과는 계속 동일했습니다.
그런데 코드 크기와 복잡도는 크게 달라졌습니다.
즉,
테스트를 계속 통과한다 = 코드가 계속 좋아지고 있다
라고 보기는 어려웠습니다.
그래서 현재 제가 쓰고 있는 가장 단순한 원칙은:
리뷰는 여러 번, 수정은 한 번.
여러 독립 리뷰에서 finding을 먼저 모으고, 사람이 한 번 선별한 다음 수정자에게 한꺼번에 넘깁니다.
그리고 수정 폭이 충분히 크다면 다음 리뷰는 단순한 '재리뷰'가 아니라,
새로 생긴 코드에 대한 첫 리뷰
라고 보는 편이 더 맞다고 생각합니다.
다만 아직 일반화하기에는 작은 실험입니다.
다른 조건이나 모델에서도 다시 확인된 결과는 일부뿐이고, Python 벤치마크 과제도 두 개뿐입니다. 언어나 코드베이스가 달라졌을 때 결과가 달라진 경우도 있었습니다.
그래서 이 결과를 모델 성능 비교보다는,
“AI 코딩 에이전트의 review/fix loop를 어떻게 설계하고, 어디서 멈출 것인가?”
에 대한 실험으로 보는 것이 맞습니다.
실험 과정에서 초기 결론이 여러 번 뒤집혔고, 그 과정과 원 데이터, 벤치마크 코드, 현재의 실무 처방, 한계까지 모두 공개했습니다.
관련 자료
- 연구 전문 — EdgeLog
https://edgelog.dev/ko/blog/how-many-ai-code-reviews/
- GitHub 연구 원문
https://github.com/Ecro/harness-bench/…
- 측정 결과를 기반으로 정리한 실전 처방
https://github.com/Ecro/harness-bench/…
- 자신의 AI 코딩 파이프라인에 적용하기 위한 가이드
https://github.com/Ecro/harness-bench/…
- 이 실험으로 주장할 수 없는 것 / 연구의 한계
https://github.com/Ecro/harness-bench/blob/main/docs/LIMITS.ko.md
'AI_LLM' 카테고리의 다른 글
| [취재수첩] AI로 인건비 줄였으니 사업비 깎자?…무지가 넘친다 (0) | 2026.08.26 |
|---|---|
| 아마존이 인공지능(AI) 모델 학습용 데이터를 확보하기 위해 희귀·절판 도서를 대량으로 사들인 뒤 제본을 잘라내어 스캔하고 원본을 폐기하고 있는 것으로 드러나 논란이 일고 있습니다 (0) | 2026.08.26 |
| 「AI 시대의 필수 지식 MCP 이 영상 하나로 끝내세요!」 — 조코딩 JoCoding (0) | 2026.08.25 |
| 클로드 코드 에이전트 팀 사용법, 역할별 AI 팀으로 개발 자동화하기 (0) | 2026.08.21 |
| [AI] 클로드코드에서 에이전트 병렬로 실행하기 (0) | 2026.08.21 |
