좋은 아침이에요. 오늘은 새 제품이 아니라, 요즘 개발자들 사이에서 일하는 방식으로 굳어지고 있는 개념이에요.
뭔가요? 코드를 짠 모델과 다른 모델에게 리뷰를 맡기는 방식이에요. Claude Code로 짜고 Codex나 Gemini 같은 다른 회사 모델로 검토하는 식이죠. 같은 모델은 자기 실수를 같은 눈으로 보기 때문에 맹점이 겹치는데, 다른 모델은 다른 곳에서 걸려 넘어지니까 서로 빈틈을 메워줘요.
시점부터 짚으면, 새 기술은 아니에요. LLM에게 다른 LLM의 답을 채점시키는 아이디어는 2023년 6월 LLM-as-a-judge 논문(MT-Bench)에서 본격적으로 정리됐고, 모델이 자기 출력을 더 후하게 평가하는 경향은 2024년 연구들에서 보고됐어요. 이번에 다시 뜬 건 2026년 10월 12일 X에서예요. Claude로 리뷰를 돌리면 고칠 때마다 새 지적이 끝없이 나온다는 ‘슬롯머신 리뷰’ 불만에 900개 넘는 답글이 달렸고, 거기서 추린 다섯 가지 규칙 중 하나가 “리뷰는 다른 모델로”였어요(X 요약). 10월 10일에는 Prime Agent가 TypeScript에서 Rust로 자기 코드를 다시 쓰면서 모든 PR을 다른 모델의 적대적 리뷰 에이전트에게 검토시켰다는 사례도 돌았고요(X 요약).
Claude만 쓰던 개발자라면 이렇게 나눠 보세요.
- 역할: Claude는 작성자(여러 파일에 걸친 리팩터링, 설계 반영), 다른 모델은 리뷰어예요. 리뷰어에겐 diff와 완료 기준만 주고 “치명적인 문제만” 찾게 하세요.
- 완료 기준 먼저: 통과해야 할 테스트를 미리 정해 두고, 테스트가 다 통과하면 스타일 지적은 넘겨도 돼요.
- 반복은 세 번까지: 그 이상 돌리면 리뷰가 새 트집을 만들어낼 뿐이라, 거기서부턴 사람이 판단해요.
- LLM에 넘기지 않을 것: 테스트, 린트, 타입 체크처럼 정답이 있는 검사는 도구가 먼저 하고, 모델 리뷰는 그다음이에요. 운영 영향이나 배포 여부 같은 최종 결정은 사람 몫이고요.
연관 용어
- LLM-as-a-judge: LLM으로 다른 LLM의 출력을 평가하는 방법(2023년 정리).
- Self-preference bias: 모델이 자기가 쓴 답을 더 높게 쳐주는 경향. 다른 모델로 리뷰하는 이유가 바로 이거예요.
- Definition of Done: 애자일에서 온 ‘완료 기준’ 개념인데, 요즘은 에이전트에게 어디서 멈출지 알려주는 용도로 다시 쓰여요.