AI가 코딩하는 동안 무엇을 하시나요? 저는 AI끼리 논쟁하게 합니다

AI 요약

AI 에이전트가 코드를 작성하는 동안 생성 과정을 지켜보기만 하는 대신, 작성한 결과를 다른 모델이 공격적으로 검토하게 만드는 방법을 실험한 글입니다. 저자는 처음에는 두 개의 LLM(Large Language Model)을 같은 Pull Request에 투입하고 서로 논쟁하도록 요청했습니다. 결과는 자신감 있는 주장과 반박, 마지막의 깔끔한 결론까지 갖춘 토론처럼 보였습니다. 그러나 원시 로그(raw logs)를 확인하자 실제 분석이 아니라 미리 만들어진 문장을 되풀이하는 대화에 가까웠습니다. 두 모델 모두 입장을 바꾸지 않았고, 새로운 근거도 제시하지 않았습니다. 겉으로는 토론이었지만 실제로는 토론의 녹음본과 같았으며, 원시 출력을 확인하지 않았다면 작동하는 시스템으로 오인한 채 배포했을 것이라고 설명합니다.

■ 일반적인 멀티 모델 검토의 문제

저자는 많은 멀티 모델 검토 워크플로가 실제로는 독립적인 검토가 아니라고 지적합니다. 일반적인 흐름은 Model A가 산출물을 검토하고, Model B가 산출물과 Model A의 결과를 함께 본 뒤, 두 번째 결과를 독립적인 검토로 부르는 방식입니다. 하지만 Model B의 컨텍스트에 Model A의 판정이 포함되는 순간, Model B는 이미 첫 번째 결론에 영향을 받습니다. 이는 독립 분석이라기보다 기존 판정에 대한 검증 또는 사회적 압력에 저항하는 과정에 가깝습니다. 사람도 이 문제를 반복해서 겪기 때문에, 인간의 동료 평가에서는 수십 년 전부터 double-blind review 같은 장치를 사용해 왔지만 AI 파이프라인에서는 이 보호 장치를 자주 생략한다고 설명합니다.

해결책은 프롬프트로 독립성을 요청하는 것이 아니라 시스템 구조로 앵커링(anchoring)을 차단하는 것입니다. Model B는 자신의 판단을 완전히 확정하기 전까지 Model A의 출력에 접근할 수 없어야 합니다. 이 원칙을 구현한 프로젝트가 MIT 라이선스의 AdversarialDebate입니다. 두 모델은 공유 컨텍스트 없이 병렬로 산출물을 분석하고, 구조화된 주장과 근거를 포함한 판정을 각각 확정합니다. 그 다음 제한된 토론을 시작합니다. 모든 반론은 특정 반대 주장(counter-claim)을 지목해야 하고, 모든 주장은 검토 대상 산출물의 구체적인 텍스트를 인용해야 합니다. 끝까지 해결되지 않는 사안은 하나의 결론으로 억지로 합치지 않고, 양쪽 입장과 해결되지 않은 쟁점을 모두 담은 구조화된 disagreement report로 남깁니다.

■ 합의가 아니라 불일치를 보존하는 설계

저자는 많은 멀티 에이전트 시스템이 합의(consensus)를 목표로 설계되어 있으며, 의견 불일치를 매끄럽게 제거해야 할 실패로 취급한다고 봅니다. 그러나 독립적으로 검토한 두 모델이 서로 다른 근거를 바탕으로 다른 결론에 도달했다면, 그 긴장 자체가 두 검토자를 사용한 이유입니다. 이를 하나의 자신감 있는 판정으로 축약하면 검토 과정에서 발견한 중요한 신호를 잃게 됩니다. 따라서 AdversarialDebate는 합의에 도달하지 못한 결과도 실패가 아니라 기록해야 할 결과로 취급합니다.

초기 구현에서는 논쟁처럼 보이는 대화의 89%가 사실상 연극(theater)이었다고 확인했습니다. 이후 구조를 수정한 v0.2.0에서는 217개 논쟁(debate)을 대상으로 한 theater rate가 0%라고 기록했습니다. 저자는 실제 공개 저장소의 Pull Request 70개를 사용해 첫 현장 테스트도 진행했으며, 이 과정에서 411개의 논쟁을 실행했습니다. 핵심 검증 질문은 각 논쟁의 주장이 실제 PR에서 무엇이 잘못되었는지를 설명하는지였습니다. 그 결과 논쟁 주장의 81%가 문서화된 PR 결과와 일치했습니다. 시스템이 문제를 찾아냈을 때는 대체로 실제 문제를 찾아낸 셈입니다.

■ 실제 저장소에서 드러난 구현 버그

다만 저자는 모델의 정확도를 신뢰하기 전에 13개의 버그를 먼저 수정해야 했습니다. PR 설명에 포함된 쉼표 때문에 CSV parser가 깨지는 문제, model slug가 조용히 잘못된 provider로 라우팅되는 문제, join bug로 데이터셋이 2,333개 행에서 359개 행으로 축소되는 문제가 포함됐습니다. 이 문제들은 아키텍처 자체의 결함이 아니라 실제 저장소를 충분한 규모로 실행하지 않았기 때문에 발견하지 못했던 운영상의 결함이었습니다. 저자는 멀티 모델 시스템을 만들 때 모델 설계만큼 실제 데이터와 규모를 기준으로 한 검증이 중요하다는 점을 이 사례로 보여줍니다.

v0.2.0에서는 네 개 도메인의 산출물 150개를 대상으로, 수정된 2,333개 행 데이터셋과 비교해 88.7%의 binary match를 기록했고 fabrication은 거의 발생하지 않았다고 보고합니다. 검토기 실행 360회의 총 비용은 0.42달러였습니다. 저자는 이 비용을 점심 한 끼보다 적은 수준으로 표현하며, 이 실험에서 병목은 compute가 아니었다고 설명합니다. 더 중요한 요소는 prompt engineering과 ground-truth measurement였습니다. 즉 모델을 여러 개 호출할 수 있는지가 아니라, 무엇을 정답으로 볼지 정의하고 그 결과를 실제 근거와 비교할 수 있는지가 핵심이었다고 봅니다.

■ 모델 조합과 학습 목표의 다양성

가장 좋은 조합은 가장 강력한 두 모델이 아니었습니다. GPT-4o-mini와 Mistral Small 3.2처럼 OpenAI의 소형 모델과 유럽 계열의 소형 모델을 조합했을 때 가장 나은 논쟁이 나왔습니다. 반대로 GPT와 Gemini 조합은 논쟁 라운드는 많았지만 양보가 거의 없고 해결도 잘 되지 않는 최악의 결과를 냈습니다. 저자는 미국 대형 연구소의 RLHF(Reinforcement Learning from Human Feedback) 중심 모델 두 개가 조화를 선호하도록 학습되어 빠르게 동의하는 경향이 있을 수 있다고 설명합니다. GPT-mini와 Mistral 조합에서는 실제 이견, 양보, 최종 수렴이 나타났습니다.

저자의 작업 가설은 논쟁 품질을 결정하는 요인이 순수한 모델 능력보다 학습 목표의 다양성일 수 있다는 것입니다. 이후 실행에서는 Mistral 이외의 모델들이 서로의 판단을 그대로 승인하는 현상일 가능성도 고려하게 되었고, 실용적인 조언을 ‘벤치마크 점수보다 먼저 서로 다른 연구소의 모델을 선택하라’에서 ‘항상 Mistral을 포함하라’로 구체화했습니다. 다만 이 가설을 엄밀하게 입증한 것은 아니며, 현재 데이터와 일치하는 느슨한 가설로 유지하고 있다고 명시합니다.

■ 88.7%의 한계와 보이지 않는 거짓 음성

88.7%의 결과는 단일 패스 검토보다 좋지만 보장된 안전장치는 아닙니다. 두 모델이 같은 실제 문제를 함께 놓치고 ‘문제없음’으로 수렴하면, 깔끔한 판정만 남고 이후 문제가 발생할 때까지 오류를 알아차릴 방법이 없습니다. 특히 11.3%의 부분 일치 또는 오판은 사고 보고서(incident report)와 변경 제안(change proposal)처럼 정답의 경계가 모호한 서술형 도메인에 집중되었습니다. 코드 검토에서 작동하는 일반 프롬프트가 postmortem에 그대로 적용되지는 않았습니다. 두 개의 독립 모델이 동시에 문제를 놓쳐야 한다는 점은 단일 패스 검토보다 높은 기준이지만, 이를 보장이라고 부르지는 않는다고 저자는 선을 긋습니다.

결국 AI가 코딩하는 동안 저자가 하는 일은 더 이상 커서와 diff를 지켜보는 것이 아닙니다. 두 번째 모델이 첫 번째 모델의 작업을 무너뜨리도록 하고, 사람에게 필요한 작업인 실패 모드 읽기, 평가 기준 작성, ‘좋은 결과’의 정의에 집중합니다. 이는 수동적으로 기다리는 방식이 아니라 인간의 주의를 다른 곳에 배치하는 방식입니다. AdversarialDebate의 핵심은 모델을 더 많이 붙이는 데 있지 않고, 독립 판정·구조화된 근거·제한된 반론·미해결 불일치 보존을 시스템의 규칙으로 강제하는 데 있습니다.

원문: dev.to / 번역·요약: Trawling