AI 코드 리뷰에는 종료 조건 문제가 있다고 생각함
I think AI code review has a stopping-condition problem
핵심 요약
AI 에이전트 간의 무한한 코드 리뷰 루프를 방지하기 위해 사전 정의된 종료 조건과 중요도 분류를 도입하는 방법론을 제안함.
- 종료 조건 문제 — 리뷰어가 끊임없이 새로운 개선점을 찾아내어 작업이 무한히 반복되는 현상
- 사전 정의된 기준 — 리뷰 시작 전 수락 기준을 명확히 설정하여 불필요한 루프를 차단함
- 결과물 분류 — 발견된 사항을 '블로커'와 '백로그'로 나누어 의사결정의 명확성을 확보함
- 독립적 검증 — 구현과 테스트를 동일 에이전트가 수행하지 않도록 하여 검증의 신뢰성을 높임
AI 코드 리뷰에는 '종료 조건' 문제가 있는 것 같음.
난 에이전트 하나가 코드를 짜고, 다른 에이전트가 리뷰하는 워크플로우를 써왔음.
처음엔 이게 당연히 더 안전할 줄 알았지.
Claude가 코드를 짜고 → 리뷰어가 뭘 찾아내고 → Claude가 고치고 → 리뷰어가 다시 돌리고.
근데 문제는 괜찮은 리뷰어라면 거의 항상 '뭔가 더' 찾아낸다는 거야.
또 다른 엣지 케이스.
더 빡세게 짤 수 있는 테스트.
스펙상의 모순.
더 깔끔한 추상화.
실제 코드랑 대조 안 해본 무언가.
근데 짜증 나는 건 그 지적들이 대부분 맞는 말이라는 거지.
그래서 "더 이상 틀린 게 없을 때까지 계속 리뷰한다"는 건 사실상 무한 루프나 다름없음.
"최대 2회 리뷰" 같은 걸로 해결될 문제도 아님. 그건 그냥 무한 루프를 임의의 숫자로 때우는 것뿐이니까.
그래서 난 리뷰를 시작하기 전에 종료 조건을 정의하는 방식으로 실험 중임.
예를 들어, 변경 사항을 승인하기 전에 이런 기준을 세우는 거지.
- B1: 승인 기준 충족 여부
- B2: 기존 동작 X가 퇴보하지 않았는지
- B3: 변경 사항이 저장된 상태를 망가뜨리지 않는지
- B4: 관련 실패 경로가 복구 가능한지
그다음, 각각에 대해 이렇게 따져봄.
- 어떤 증거가 실제로 충분한가?
- 그 속성에 대해 권한을 가진 소스는 무엇인가?
- 어떤 관찰 결과가 그 주장을 거짓으로 증명할 것인가?
이렇게 하니까 지적 사항을 대하는 태도도 달라짐.
리뷰어가 변수명 문제나 추가적인 방어적 테스트를 지적한다면, 고칠 가치는 있겠지만 그게 자동으로 의사결정을 다시 원점으로 돌리지는 않음.
그래서 지적 사항을 대략 이렇게 나누고 있음.
BLOCKER
현재 결정에 필요한 사항을 부정하거나 뒷받침하지 못하는 경우.
BACKLOG / YELLOW
개선할 점은 맞지만, 지금 당장 결정을 막을 정도는 아닌 경우.
이제 GREEN(통과)은 이런 뜻이 아님.
"더 이상 개선할 게 없다."
대신 이런 뜻이지.
"이 결정을 내리는 데 필요한 주장들은 충분한 증거를 갖췄고, 이를 반박할 미해결된 실질적 증거는 없다."
그리고 요즘 점점 더 의심스러운 게 하나 있는데, 같은 에이전트한테 구현이랑 테스트를 다 맡겨놓고 테스트 통과했다고 독립적인 증거라고 믿는 거임.
그래서 난 변경 전의 기준 증거들(기존 테스트, 승인 기준, 픽스처, 불변 조건, 커밋 상태 등)을 따로 보관해두고, 에이전트가 마음대로 수정하지 못하게 한 상태에서 새 구현을 검증하고 있음.
아직 테스트 중인 방식이라 어디서 터질지 궁금하네.
Claude Code + Codex/Gemini/기타 리뷰어 조합 쓰는 형들.
형들은 실제 종료 조건을 어떻게 잡고 있음?
"리뷰어가 좋다고 할 때" 말고.
도대체 뭘 보고 "아, 이제 리뷰 더 돌려봐야 시간 낭비다"라고 판단함?
