AI 에이전트가 반박 전 검증 기록을 남겨 잘못된 수정을 줄인다

무엇인가

사용자와 여러 턴에 걸쳐 코드를 고치거나 보고서를 작성하는 LLM 에이전트는 이미 테스트를 통과한 패치나 검증한 계산도 사용자가 '틀렸다'고 말하면 쉽게 버린다. 반대로 무조건 버티라고 지시하면 실제 버그나 요구사항 변경까지 무시한다. 이 논문은 문제의 원인을 반박을 읽은 뒤 에이전트가 자기 이전 검증을 할인하는 데서 찾고, 반박을 읽기 전에 주장과 검증 근거, 신뢰도를 비공개로 적어 두는 Thinking-in-Bets를 제안한다. 훈련이나 가중치 접근이 필요 없는 추론 시점 방법이라는 점이 핵심이다.

어떻게 동작하나

방법의 중심은 Claim Checklist다. 각 항목은 검증 가능한 주장 c_i, 그 주장이 맞다고 보는 0과 1 사이의 신뢰도 p_i, 통과한 테스트나 파일·줄 위치, 프롬프트 구절, 아직 확인하지 않았다는 메모 같은 근거 e_i로 구성된다. 여기에 실패해서 제외한 선택지 목록도 남겨 같은 실패를 반복하지 않게 한다. 사용자 반박이 오면 관련 주장만 매칭하고, 임계값 0.5를 기준으로 강한 주장과 모호한 반박이면 검증된 작업을 유지하며 어떤 경우가 실패했는지 묻고, 강한 주장과 구체적 반박이면 도구나 테스트로 확인한 뒤 실제 오류가 드러날 때만 고친다. 약한 주장이면 모호할 때 질문하고 구체적일 때 해당 주장만 수정한다. 확인 후 신뢰도를 갱신해 0.5 이상이면 유지, 미만이면 고친다.

무엇과 다른가

기록 시점도 설계의 일부다. Always-On Betting은 매 턴 반박을 읽기 전 전체 체크리스트를 쓰며 완성된 패치·보고서·답안 검토에 맞는다. On-Demand Betting은 진행 중 코딩에서 먼저 현재 작업의 전체 신뢰도를 0~1로 빠르게 평가해 0.9 이상이면 체크리스트를 생략하고, 0.9 미만일 때만 작성한다. Draft-First Betting은 사용자 피드백이 없는 비대화형 작업에서 초안을 만든 뒤 핵심 주장을 나열하고 가장 낮은 신뢰도의 주장을 제출 전에 재확인하며, 구체적 모순이나 계산 오류가 있을 때만 수정한다. 평가는 이미 만족한 요구사항을 잘못된 비판 때문에 깨뜨리는 false reversal과, 유효한 피드백을 받고도 고치지 않는 missed correction을 함께 본다. 그래서 균형 정확도와 기대 오류 비용을 사용한다.

어떻게 쓰나

실험은 Gemini 3.5 Flash-Lite, 3.5 Flash, 3.6 Flash, 3.8 Flash, 4.0 Argon 다섯 모델과 SWE-Together, SWE-Interact, DeepSWE, Agents' Last Exam, Humanity's Last Exam, SycEval, Vals Finance, Terminal-Bench 여덟 벤치마크에서 이뤄졌다. 비교군에는 표준 실행, 길이 맞춘 위약 프롬프트, 단순 버티기 규칙, 네 단계의 완고함 프롬프트, 근거나 신뢰도 숫자를 뺀 기록, 반박을 읽은 뒤 기록하기, 대화 상태 추적기, 최소 편집 규칙, 사후 신뢰도 게이트, 3샘플 다수결, 검증 후 응답 등이 포함됐다. 단일 턴 패치 리뷰에서 반박 전 기록은 다섯 모델 통합 false reversal을 12.2%에서 0.02%로 거의 없앴고 Holm 보정 후에도 유의했다. Agents' Last Exam의 20개 시나리오 검토에서는 통과한 초안에 대한 잘못된 반박 시 false reversal이 54.7%에서 12.0%로 4배 이상 줄었고, 결함 있는 초안 92%는 여전히 고쳤으며, 검토 후 통과 비율은 58%에서 89%로 올랐다. 같은 체크리스트를 비판을 읽은 뒤 쓰면 통과 비율이 65%에 그쳐 이득의 4분의 1도 회복하지 못했다. 체크리스트와 수정 규칙은 둘 다 필요했고, 근거 텍스트는 실제 테스트나 문헌 확인이 있을 때만 도움이 됐으며, 폐쇄형 Humanity's Last Exam에서는 '수동으로 확인함' 같은 채우기 문구가 정확도를 오히려 낮췄다.

전제와 한계

다중 턴 코딩에서는 표준 에이전트가 잘못된 불만의 절반 이상 뒤에 소스 파일을 고쳤고, 반박 후에 작동하는 사후 필터와 추적기도 대부분 파일을 다시 썼다. 반박 전 기록은 평가된 모든 모델에서 불필요한 파일 수정을 38~60% 줄였고 3.8 Flash의 작업 완료율을 55%에서 70%로 높였다. 진행 중 Q&A 17개 과제에서는 Always-On이 11건의 유효한 버그 보고를 모두 미완성 요구사항에 반영하면서 완료된 부분을 보호했지만, 작은 모델에서는 테스트 전에 전체 체크리스트를 쓰면 미완성 초안을 너무 일찍 고정할 수 있었다. On-Demand는 체크리스트 토큰 비용을 85% 줄이고, 반복 버그가 생기는 세션을 네 Flash 모델 모두에서 4배 이상 줄였으며, 3.8 Flash에서는 유효 버그 수정률을 52%에서 74%로 올리며 가장 높은 균형 정확도를 냈다. 110개 DeepSWE 과제의 SWE-Pushback-Hidden에서는 테스트가 끝난 패치에 대해 반박 전 기록이 네 Flash 모델 모두에서 잘못된 불만에 의한 false reversal을 줄였고 세 모델에서 최종 통과율을 크게 높였다. 패치 전체가 아니라 리뷰어가 지적한 특정 요구사항의 신뢰도를 물을 때 Brier 오차가 크게 낮아졌다. 비대화형 HLE와 Vals Finance에서는 Draft-First가 네 모델 모두에서 답 정확도와 신뢰도 보정을 개선했고, 라벨링된 검증 데이터가 필요 없었다. 자율 DeepSWE에서는 3.8 Flash와 4.0 Argon의 통과율을 높이고 긴 컨테이너 실행에서 토큰을 27~41% 줄였지만, 30개 매칭 과제 비교에서는 git 커밋만 남기기와 제출 전 diff 검토만으로 전체 Draft-First의 순수 과제 승리 6개 중 5개가 재현됐고, 짧은 Terminal-Bench 과제에서는 추가 사전 점검이 오히려 해로웠다.

개발자에게 이 논문의 실무적 메시지는 에이전트에게 '사용자에게 무조건 맞서라'거나 '무조건 따르라'를 주는 대신, 반박을 읽기 전에 검증 상태를 요구사항 단위로 남기게 하라는 것이다. 특히 테스트가 이미 돈 패치 리뷰, 여러 요구사항이 얽힌 보고서 검토, 사용자가 중간에 버그를 제기하는 코딩 세션에서 유효하다. 완성된 산출물 검토에는 Always-On이 맞고, 아직 작성 중인 코드에는 불확실할 때만 기록하는 On-Demand가 토큰과 조기 고정 문제를 줄인다. 사용자 피드백이 없는 배치 작업에는 Draft-First로 가장 약한 주장을 제출 전에 점검할 수 있다. 다만 신뢰도는 실제 테스트나 계산 같은 구체적 검증에 붙을 때만 믿을 만하며, 기록을 기계적으로 적용해 사용자 지적을 무시하는 장치로 쓰면 안 된다.

저자들이 밝힌 한계는 분명하다. 대화형 실험의 사용자는 시뮬레이션이며, 잘못된 비판은 대개 실패 사례를 동반하지 않은 짧은 반박이라 실제 사용자처럼 한 메시지에 유효한 지적과 잘못된 지적을 섞는 경우를 충분히 반영하지 못한다. 평가는 Gemini 모델에 한정됐고 모든 결정 임계값은 데이터로 튜닝한 것이 아니라 손으로 고른 고정값이다. 긴 Agents' Last Exam 컨테이너 실행에서는 모델이 체크리스트 작성을 자주 건너뛰었고, 다중 턴 코딩에서는 이전의 잘못된 불만이 나중 체크리스트에 검증된 사실처럼 복사될 수 있었다. Always-On은 턴마다 모델 호출을 한 번 더 늘리며, On-Demand가 대부분의 비용을 없애지만 작은 모델에서 세션 중간 기록은 테스트 전 미완성 코드를 고정할 위험이 남는다.