AI 코드 리뷰는 몇 번 돌려야 할까.. 약 400번 돌려보고 알게 된 것

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일수록 진짜일 가능성이 높을 거라고 생각했습니다. 그런데 대상 파일 하나만 보여준 조건에서는 반대였습니다. 오탐이 실제 결함보다 더 자주 반복적으로 보고됐습니다. 여러 A...