AI가 만든 결과를 다른 AI가 점검하면 얼마나 나아질까

배경과 문제

대규모 언어 모델(LLM) 기반 코딩 에이전트는 저장소 수준의 소프트웨어 공학 작업을 수행한다. 이 에이전트는 하네스 안에서 도구를 통해 행동하고 결과를 관찰하며 목표를 향해 반복한다. 하네스는 단순히 도구를 노출하는 것을 넘어 에이전트의 지시사항을 정하고, 개입 시점을 제어하며, 작업을 수락하기 전에 검증을 조정한다. 이러한 선택은 에이전트의 작업을 확인하고 수정하는 데 계산 자원을 할당하므로 검증은 하네스 설계의 중요한 부분이 된다.

그러나 하네스에서 검증을 어떻게 조직해야 하는지에 대한 체계적 증거는 부족하다. 기존 연구는 학습된 검증기, 자기 수정, 도구 지원 검사 등 개별 메커니즘을 발전시켰지만, 실제 하네스 설계는 공학적 휴리스틱과 반복적 경험에 의존하는 경우가 많다. 예를 들어 Claude Code는 완료 검사를 위한 훅을 제공하고 Codex는 자기 검토와 반복을 사용하지만, 어떤 설계가 어떤 모델과 작업에서 성능을 높이는지, 그 이득이 추가 계산 비용을 정당화하는지에 대한 비교 지침은 제한적이다. 이 논문은 검증을 테스트 시간 확장의 한 축으로 연구하여 '언제 개입할지, 누가 검사할지, 발견 사항이 어떻게 수정으로 이어질지'라는 세 가지 질문을 중심으로 설계 공간을 체계화한다.

기존 접근의 한계

기존 검증 연구는 크게 세 갈래로 나뉜다. 첫째, 학습된 검증기는 완전한 해답이나 중간 추론 단계를 평가하여 후보 선택을 안내한다. 둘째, 자기 수정 방법은 자연어 비평과 반성을 통해 출력을 수정하거나 이후 시도를 개선한다. 셋째, 도구 지원 검증은 코드 실행과 외부 도구의 증거를 기반으로 오류 탐지를 근거 짓는다. 이러한 연구들은 유용한 평가 및 피드백 메커니즘을 제공하지만, 하네스 수준에서 검사와 수정을 어떻게 조직해야 하는지에 대한 비교 지침은 제공하지 못한다.

저자들은 검증의 내용뿐 아니라 작업 흐름에 끼어드는 방식도 결과를 바꿀 수 있다고 본다. 같은 점검 요청을 처음부터 주는지, 편집 직후에 주는지, 완료 선언 뒤에 주는지에 따라 에이전트가 쓰는 계산과 반응이 달라진다. 별도 검토자가 독립된 관점으로 결과물을 살피게 하는 방법도 비교한다. 이런 설계 선택을 함께 평가하는 것이 이 실험의 목적이다.

연구방법을 단계별로

연구진은 에이전트 수명주기를 따라 검증 설계를 네 계층으로 구분했다. L0 초기 지시는 작업 시작 전에 검증 지침을 초기 프롬프트에 추가한다. 시스템 역할과 사용자 역할 두 가지 변형을 비교했는데, 시스템 변형은 시스템 프롬프트에 상시 지침으로 추가하고, 사용자 변형은 동일한 프롬프트를 초기 사용자 요청에 덧붙인다. 두 변형 모두 에이전트에게 결과물을 실제 인터페이스로 실행하고 출력을 검사하며 발견된 결함을 수정하도록 요청한다.

L1 실행 중 알림은 코드베이스 변경이 누적되는 동안 에이전트가 최근 변경 사항을 확인하도록 장려한다. 실험에서 편집 턴의 6.2~13.6%만이 다음 편집 턴이나 실행 종료 전에 인식된 검사 명령으로 이어지는 것으로 나타났다. 따라서 주기적 알림(시스템), 편집 후 알림(시스템), 편집 후 알림(사용자) 세 가지 설계를 평가했다. 주기적 알림은 편집 후 몇 턴 뒤에, 편집 후 알림은 파일을 변경한 턴 직후에 전송된다. 시스템 역할 알림에는 자동화된 자기 검증 체크포인트임을 나타내는 마커가 포함되지만, 사용자 역할 알림에는 마커가 없다.

L2 완료 게이트는 에이전트가 작업을 끝내려 할 때 작업을 다시 열어 검사와 수정을 유도한다. 변경 사항 검사, 실행 및 확인, 완료 거부 등 다양한 요청을 비교했고, 메시지 역할(시스템/사용자)과 자동화 마커 유무, 개입 시점(일반/조기)을 변화시켰다. 예를 들어 'Reject completion'은 자동화된 검증 패스가 작업이 완료되지 않았다고 판단했다는 메시지를 보내 계속 작업하도록 한다. 이는 실험에서 정한 메시지 조건이지, 별도 검증기가 실제 결함을 발견했다는 뜻은 아니다.

L3 독립적 검토는 별도의 모델(비평가)이 에이전트의 결과물을 평가한다. 비평가는 새로운 컨텍스트에서 시작하여 작업 명세와 라이브 샌드박스에 접근해 자체 검사를 실행한다. 비평가의 컨텍스트는 작업 요구사항만으로 안내되는 Task-first와 에이전트의 가정과 주장도 포함하는 Claim-guided로 나뉜다. 또한 Changes 조건은 작업과 에이전트의 변경 사항만 제공하고, Trajectory 조건은 에이전트의 실행 궤적까지 포함한다. 비평가는 결과물을 수정할 권한이 없으며, 발견 사항을 에이전트에게 반환하여 수정을 안내한다.

결과와 숫자의 의미

L0 초기 지시는 코딩 벤치마크에서 평균적으로 소폭의 이득을 보였지만 모델 간 차이가 컸다. 시스템 역할 지시는 Terminal-Bench에서 +3.3%p, SWE-bench Verified에서 +3.9%p의 평균 정확도 향상을 보인 반면, 사용자 역할 지시는 각각 +1.2%p, -1.1%p로 효과가 미미하거나 오히려 감소했다. 비용 변화는 작아서 시스템/사용자 지시 모두 기준 대비 0.93~1.08배 수준이었다. 그러나 VisualBench에서는 L0가 기준 대비 평균 순선호도 -3.2점으로 오히려 부정적이었다.

L1 실행 중 알림은 시스템 역할에서 주기적 알림과 편집 후 알림이 유사한 평균 효과를 보였다(TB +3.8 vs +3.5%p, SWE +3.1 vs +3.6%p). 편집 후 알림의 메시지 역할을 사용자로 바꾸면 TB에서는 평균 이득이 +5.4%p로 상승했지만 SWE에서는 -0.3%p로 하락했다. 흥미롭게도 L1 설계들은 평균 출력 토큰을 TB에서 14~25%, SWE에서 7~10% 감소시켰다. 즉, 더 적은 출력으로 더 높은 정확도를 달성한 경우도 있었다.

L2 완료 게이트는 비용 대비 이득이 제한적이었다. 자동화된 Reject completion은 TB/SWE에서 각각 +4.0/+5.3%p의 이득을 보였지만, Inspect changes는 +0.7/+0.5%p에 그쳤다. 조기 개입을 적용한 사용자 Reject completion은 TB/SWE에서 +6.0/+6.2%p로 L2 중 가장 큰 평균 이득을 보였지만, 거부 기반 설계의 비용은 TB에서 기준 대비 1.60~1.76배, SWE에서 1.48~1.56배로 크게 증가했다. 반면 조기 사용자 재검토는 1.13/1.20배의 낮은 비용으로 이득을 달성했다.

L3 독립적 검토는 네 가지 설계 모두에서 모델 평균 정확도 개선을 보였다. TB에서 평균 정확도가 +5.9~9.5%p, SWE에서 +3.9~6.6%p 향상되었고, 비용은 비평가 검토와 에이전트 수정을 포함해 TB에서 기준 대비 1.13~1.25배, SWE에서 1.00~1.04배에 불과했다. 가장 강력한 L2 설계와 비교하면, 가장 강력한 L3 설계는 TB에서 더 큰 이득(+9.5 vs +6.0%p)을, SWE에서 비슷한 이득(+6.6 vs +6.2%p)을 더 낮은 비용으로 달성했다. VisualBench에서는 네 가지 L3 설계 모두 +13.2~+23.8점의 순선호도를 기록하며 평가된 L0~L2 설계를 능가했다.

구체적인 예시

L3 독립적 검토의 효과를 보여주는 사례가 있다. regex-log 작업에서 MiniMax-M2.5는 자체 테스트를 통과하고 완료를 선언했지만, 비평가는 날짜가 IP 주소보다 앞에 나오는 경우를 테스트하여 정규식이 일치하지 않음을 발견했다. 에이전트는 이 반례를 바탕으로 정규식을 수정하여 통과했다. cobol-modernization 작업에서는 Qwen3.7-Max의 구현이 자체 검사를 통과했지만, 비평가가 산술 언더플로를 테스트하여 Python이 음수 부호를 기록하는 반면 COBOL의 부호 없는 필드는 이를 생략하여 레코드 형식이 깨지는 문제를 발견했다. 에이전트는 불일치를 재현하고 숫자 형식을 수정하여 외부 채점을 통과했다.

반면 L2 완료 게이트의 실패 사례도 있다. git-multibranch 작업에서 Kimi-K2.7-Code는 조기 재검토 요청에 응답하여 배포 테스트를 실행했지만, 테스트 콘텐츠를 서비스 브랜치에 커밋하고 푸시하여 최종 결과물이 실패했다. 통과한 기준 실행은 필요한 브랜치 내용을 복원했지만, 재검토 실행은 테스트로 인해 상태가 변경되어 채점에 실패했다. 이는 추가 실행만으로는 충분하지 않으며, 완료 게이트가 수리 기회를 만들지만 에이전트가 여전히 관련 결함을 식별하고 유효한 최종 결과물을 보존해야 함을 보여준다.

한계와 오해하기 쉬운 점

이 설명은 최초 제출일이 2026년 10월 25일(UTC)인 arXiv v1 PDF 전체를 기준으로 한다. 이 연구의 결과는 특정 조건에서 도출되었다. Terminal-Bench는 89개 등록 과제 중 사전 난이도 기준으로 선택한 31개 과제만 사용했고, SWE-bench Verified는 처음 30개를 선정한 후 기준 성능에 따라 조정했다. 따라서 전체 벤치마크에 대한 일반화에는 주의가 필요하다. 또한 비평가는 모든 코딩 모델에 대해 Qwen3.7-Plus 하나만 사용했으므로, 다른 비평가 모델을 사용하면 결과가 달라질 수 있다. 코딩 조건은 모델·과제별 3회, VisualBench의 내부 과제 18개는 2회 실행하도록 설정했다. 비용은 논문의 API 토큰 가격으로 주 에이전트·검토자·수정 비용을 합친 값이다. 실제 소요 시간이나 현재 제공 가격과는 다르다. 사전공개 논문이며 여기서 실험을 독립 재현한 것은 아니다.

모델별 결과는 일관되지 않다. 예를 들어 L0 시스템 지시는 TB에서 Qwen3.7-Max에 +7.1%p, Qwen3.8-Max에 +8.0%p의 이득을 주었지만, Kimi-K2.7-Code에는 -2.4%p, MiniMax-M2.5에는 0.0%p였다. SWE에서는 MiniMax-M2.5가 +12.6%p로 크게 향상된 반면 Qwen3.8-Max는 -2.3%p로 감소했다. 따라서 '모든 모델이 일관되게 향상된다'고 단정해서는 안 된다. 또한 VisualBench의 순선호도는 자동 코딩 정답률이 아니라 전문가의 블라인드 비교에 기반한 주관적 평가다. 변경 사항 기반 리뷰가 궤적 기반보다 VisualBench에서 더 높은 선호도를 보였지만, TB 평균 정확도는 궤적 기반이 더 높았다. 전체 궤적이 항상 낫거나 나쁘다고 해석해서는 안 되며, 코딩 평가에서 궤적 기반 검토자의 비용은 29~43% 더 컸다. 전체 에이전트 비용의 증가율과는 구별해야 한다.

실제로 어떻게 활용할까

저자들은 별도의 저비용 검토자가 결과물을 검사하고 원래 에이전트가 수정하게 하는 구성을 권한다. 비평가에게는 작업 요구사항과 에이전트의 변경 사항을 기본 컨텍스트로 제공하는 것이 좋다. 전체 실행 궤적을 제공하면 일부 경우에 도움이 될 수 있지만 비용이 크게 증가하므로 기본값으로는 권장되지 않는다. 추가 검토 라운드나 여러 비평가를 사용하면 평균 정확도를 더 높일 수 있다. 예를 들어 TB에서 비평가 1명 1라운드는 62.7% 정확도를 달성했지만, 4라운드는 66.1%, 4명의 비평가는 65.8%를 달성했다. 4명의 비평가는 4라운드와 비슷한 정확도를 19% 낮은 총비용으로 달성했다.

저자들은 시작할 때 간결한 검증 지침을 주고, 편집 후에는 코드뿐 아니라 결과물의 실제 동작을 확인하도록 유도할 것을 제안한다. 완료 시점에 같은 에이전트를 계속 되돌려 보내는 방식은 이 실험에서 비용 대비 이득이 작았다. 이는 완료 전 점검을 모두 없애라는 보편 법칙이 아니다. 자신의 과제에서도 누가 어떤 증거를 보고 점검하는지, 개선된 결과와 추가 비용이 얼마인지 나란히 측정해 설정을 골라야 한다.