에이전트는 자신의 숙제를 스스로 채점하지 않는다

Claude에게 당신의 코드를 검토해 달라고 요청합니다. Claude는 "좋아 보입니다, 깔끔하고 구조화가 잘 되어 있네요"라고 말합니다. 당연한 결과입니다. 그 코드는 5분 전에 Claude가 직접 작성한 것이니까요. 당신은 방금 저자에게 자신의 논문을 채점해 달라고 요청했고, 그는 스스로에게 A 학점을 주었습니다.

AI가 코드를 검토하는 방식은 효과가 있습니다. 하지만 방금 코드를 작성한 이에게 요청해서는 안 됩니다. 품질은 더 똑똑한 모델에서 나오는 것이 아니라, 어떤 역할도 스스로를 검증하지 않는 아키텍처(Architecture)에서 나옵니다.

자기 선호 편향 (The self-preference bias)

이것은 단순한 직감이 아니라 측정된 사실입니다. 자신의 출력을 평가하는 모델은 동일한 품질일 때 다른 모델의 출력보다 자신의 것을 더 높게 평가합니다. 이는 2024년 Panickssery와 공동 저자들이 기록한 '자기 선호 편향 (self-preference bias)'이며, 이는 상관관계가 아닌 인과관계입니다. 모델은 자신의 스타일을 인식하고 그것을 선호합니다.

실제로 이는 "작성하고, 방금 작성한 것을 검토한다"라는 단순한 루프가 구조적으로 결함이 있음을 의미합니다. 당신은 검토를 받는 것이 아니라 정당화를 받는 것입니다. 에이전트는 코드를 생성하는 순간 이미 자신의 코드가 좋다고 결정했습니다. 다시 묻는 것은 단지 확인 절차일 뿐입니다.

눈먼 검토자 (The blind reviewer)

따라서 첫 번째 규칙은 다음과 같습니다: 검토자는 결코 저자가 되어서는 안 됩니다. 저의 설정에서 검토 에이전트(Review agents)는 **클린 컨텍스트 (clean context)**에서 실행됩니다. 그들은 구현 프롬프트(Implementation prompt)를 보지 못하며, 저자가 어떤 제약 조건을 설정했는지 알지 못합니다. 그들은 월요일 아침의 동료처럼 차이점(Diff)을 마주합니다. 그리고 저자가 알려진 모델인 경우, 스타일 인식을 깨뜨리기 위해 검토자는 **다른 계열 (different family)**의 모델을 사용합니다.

다른 모든 것만큼 중요한 세부 사항이 하나 있습니다: 개발자의 이름은 검토자의 프롬프트에 절대 포함되지 않습니다. "이것은 시니어 개발자가 작성했습니다"라거나 "이 모델의 작업물을 검토하세요"와 같은 말은 없습니다. 저자의 정체성은 편향을 유발하는 바로 그 정보입니다. 우리는 그 정보를 원천 차단합니다.

증거 없는 발견은 없다 (No finding without a receipt)

두 번째 함정은 첫 번째와 반대되는 것입니다. AI 검토자, 특히 클린 컨텍스트에 있는 검토자는 과도하게 플래그(Flag)를 지정하는 경향이 있습니다. 유용해 보이기 위해 문제를 만들어내거나, 실제로는 존재하지 않는 "취약점 (vulnerabilities)"을 지적합니다. 모든 줄마다 양치기 소년처럼 경고를 울리는 검토는 안일한 검토와 다를 바 없습니다. 어느 쪽이든 당신은 더 이상 귀를 기울이지 않게 될 것입니다.

따라서 수령 규칙 (receipt rule)이 필요합니다. 모든 발견 사항은 표면화되기 전에 반드시 file:line을 인용해야 하며 검증을 통과해야 합니다. 즉, 발생을 증명하는 grep, 샌드박스 실행 (sandbox run), 실패하는 테스트, 또는 데이터 흐름 추적 (data-flow trace) 등이 필요합니다. 누구도 증명할 수 없는 발견 사항은 논쟁 없이 조용히 폐기됩니다.

발견 사항: "매개변수화되지 않은 SQL 호출, 인젝션 위험"
  → 수령 요건: 사용자 입력 → 쿼리 흐름을 grep으로 확인
  → 만약 해당 값이 코드 상수라면: 폐기
...

판단에 앞서 증명이 선행되어야 합니다. 검토자(reviewer)는 단지 직감만으로 당신을 번거롭게 할 수 없습니다.

반박 패널 (The refute panel)

머지 (merge)를 차단할 수 있는 중요한 발견 사항의 경우, 저는 마지막 계층을 추가합니다. 바로 독립적인 회의론자들로 구성된 패널입니다. 이들의 지침은 확인하는 것이 아니라 반박하는 것입니다. 각 패널 구성원은 발견 사항을 전달받아 이를 무너뜨리려 시도합니다: "이것이 버그가 아닌 이유는 다음과 같습니다"라고 말이죠. 발견 사항을 유지하기 위해 다수결이 필요하다면, 그럴듯한 오탐 (false alarms)은 살아남지 못할 것입니다. 끝까지 살아남은 것들은 파괴적인 시도를 견뎌낸 것들입니다.

이는 단순한 루프 (naive loop)와 정반대되는 방식입니다. 하나의 모델이 정답을 맞히려고 노력하는 대신, 여러 모델이 서로를 부정하려고 노력합니다. 결과적으로 도출된 진실은 스스로 선포된 것이 아니라, 공격을 견뎌낸 것입니다.

권력 분립 (Separation of powers)

종합하자면, 이는 역할이 절대 겹치지 않는 에이전트 팀을 구성하는 것입니다. 코드를 작성하는 자는 테스트를 작성하는 자가 아니며, 테스트는 코드가 아닌 명세 (spec)만을 바탕으로 작성됩니다. 검토자는 코드를 작성하지 않았습니다. 그리고 인간이나 LLM이 의견을 내기 전에도, 객관적인 게이트 (빌드, 린트, 테스트)가 반드시 통과(green)되어야 합니다. 모델의 판단은 기계의 판단 이후에만 이루어지며, 기계의 판단을 대신할 수는 없습니다.

이것은 AI에 대한 무분별한 불신이 아닙니다. 이는 뉴스룸, 회계 팀, 법원을 다스리는 것과 동일한 원칙입니다. 누구도 자신의 작업에 스스로 승인하게 하지 마십시오. 왜냐하면 그 누구도 자기 자신을 객점적으로 판단하는 데 능숙하지 않기 때문입니다. 자기 선호 편향 (self-preference bias)이 입증된 LLM은 다른 존재들보다 더욱 그러합니다.

결론

코딩을 잘하는 모델을 마주했을 때 유혹을 느끼기 쉽습니다. 작성, 테스트, 검토, 승인까지의 전체 사이클을 모델에게 맡겨버리고 싶은 유혹 말입니다. 하지만 그것은 정확히 당신이 하지 말아야 할 행동입니다. 왜냐하면 각 단계는 이전 단계를 수정하는데, 스스로를 수정하는 수정자는 아무것도 수정하지 못하기 때문입니다. AI 검토 (AI review)의 품질은 모델의 지능에 의해 측정되지 않습니다. 그것은 당신이 모델이 스스로를 채점하는 것을 얼마나 많이 막았느냐에 의해 측정됩니다.