구글 연구팀이 10월 1일 arXiv에 논문을 제출하며 'VeriHarness'라는 에이전트 검증 프레임워크를 공개했다. 코드도 동시에 GitHub에 Apache 2.0 라이선스로 올라왔다. 이 프레임워크가 다루는 문제는 구체적이다. 에이전트가 수십 단계에 이르는 장시간 작업을 실행해 표나 보고서, 수정된 파일을 제출했을 때, 그 결과물이 맞는지 누가 판단하느냐는 것이다.
VeriHarness의 방식은 답을 생성한 모델 자신이 검토자 역할을 맡는 것이다. 같은 문제를 같은 모델로 여러 번 독립적으로 실행해 여러 개의 결과를 얻은 뒤, 이를 나란히 비교해 '의견 불일치'와 '의견 일치' 두 가지로 나눠 각각 처리한다.
두 가지 검토 경로
첫 번째는 의견 불일치를 처리하는 경로다. 여러 결과가 결론에서 서로 다르면 검토자는 다시 작업 환경으로 돌아가 증거를 찾는다. 원본 파일을 다시 열거나 표의 특정 셀을 확인하는 식으로, 환경에서 확인할 수 있는 사실을 이용해 잘못된 주장을 걸러낸다.
두 번째는 의견 일치를 처리하는 경로다. 여러 결과가 일치해도 프레임워크는 그대로 통과시키지 않는다. 오히려 그 결론을 뒤집을 수 있는 증거를 적극적으로 찾고, 동시에 모든 실행이 과제의 특정 요구사항을 똑같이 빠뜨리지는 않았는지 점검한다. 논문의 전제는 여러 번 실행해 같은 답이 나왔다고 해서 그 답이 맞다는 보장은 없다는 것이다. 모델이 매번 똑같은 실수를 반복할 수도 있기 때문이다.
두 경로가 끝나면 판정 단계로 들어간다. 가장 완성도 높은 결과를 기준으로 골라 찾아낸 증거에 따라 수정하고, 필요하면 전체를 다시 작성하며, 그래도 해결되지 않은 문제는 따로 기록해 둔다. 프레임워크는 검토자에게 작업 공간, 증거 수집 도구, 재사용 가능한 '검증 스킬' 세트를 제공하는데, 논문에 따르면 이 스킬들은 실패 피드백을 바탕으로 스스로 개선될 수 있다고 한다.
무엇을 테스트했고, 얼마나 올랐나
평가는 장시간 업무 환경 벤치마크 5종을 대상으로 한다. APEX-Agents, Workspace-Bench Lite, WorkBuddy Bench, SpreadsheetBench 2, JobBench로, 대부분 사무 문서나 표, 구직 자료처럼 완성된 파일을 제출해야 하는 과제다. 생성과 검토 모두 같은 모델이 맡으며, Gemini 3.5 Flash와 Claude Opus 4.8 두 모델을 테스트했다. 두 모델 모두 Vertex AI를 통해 호출했다.
논문과 README에 따르면 VeriHarness는 다섯 개 벤치마크 모두에서 '선택 점수' 1위를 차지했으며, 비교 대상에는 단일 실행과 기존 LLM-as-a-Verifier 방식이 포함된다. 증거 기반 수정을 더한 결과 단일 실행 대비 Gemini 3.5 Flash는 평균 6.2점, Claude Opus 4.8은 평균 6.4점 상승했다.
연구팀은 또 Hugging Face에 약 2만 6천 건의 실행 기록을 공개했다. 두 모델이 다섯 개 벤치마크에서 문제마다 10번씩 실행한 결과로, 렌더링된 실행 과정과 제출 파일, 채점 결과가 함께 담겼다. 벤치마크의 입력값과 정답은 공개되지 않았다. 논문에 따르면 이 데이터셋을 만드는 데 10만 달러 이상이 들었다.
'여러 번 돌려서 다수결'과 어떻게 다른가
모델을 여러 번 실행해 다수결로 답을 정하는 방식은 업계에서 흔히 쓰는 정확도 향상법이다. 비용이 적고 구현도 쉬워 짧은 질의응답에서는 효과가 뚜렷하다. 하지만 장시간 과제에 적용하면 두 가지 문제가 생긴다. 결과물이 파일이라면 단순히 다수결로 정할 수 없고, 여러 결과가 일치할 경우 다수결은 공통된 오류를 그대로 남겨둔다. VeriHarness의 두 경로는 바로 이 두 문제를 겨냥한다.
또 다른 흔한 방식은 모델을 심사자로 세워 여러 결과를 읽고 바로 점수를 매기게 하는 것이다. 이 방식은 심사자의 독해와 판단에 의존하며 환경으로 돌아가 다시 확인하지 않는다. VeriHarness는 '주장이 환경 속 증거로 뒷받침되는가'를 중심에 두는데, 그 대가로 검토 자체가 도구를 호출하고 토큰을 쓰는 에이전트 작업이 된다. 논문은 검토 단계가 생성 단계에 비해 얼마나 더 많은 비용을 쓰는지 수치로 제시하지 않았다. 기업이 이 비용을 계산하려면 지금은 직접 측정하는 수밖에 없다.
본지는 앞서 마이크로소프트의 'ThinkingBox' 벤치마크를 다룬 적이 있다. 같은 과제를 20번 반복 실행해 에이전트 결과가 얼마나 안정적인지 보는 방식이다. 두 작업은 같은 방향을 가리킨다. 장시간 과제에서는 한 번의 실행 성적이 지니는 참고 가치가 제한적이며, 여러 번 실행한 결과 사이의 차이 자체가 신호가 된다는 것이다. 한쪽은 이를 안정성 측정에 쓰고, 다른 한쪽은 오류를 잡아내는 데 쓴다.
지금 바로 쓸 수 있나
README에는 실행 환경이 Linux이며 Python 3.10 이상, Node.js 22.19 이상, Docker, 비특권 사용자 네임스페이스가 필요하다고 적혀 있다. 내부적으로는 오픈소스 'pi' 런타임 위에서 동작해 pi가 지원하는 모델 제공업체라면 모두 연동할 수 있다. 프로젝트 페이지에는 이런 문구도 있다.
"이것은 구글이 공식적으로 지원하는 제품이 아닙니다."
즉 지금은 연구용 코드일 뿐이며 구글이 유지보수를 약속하지는 않는다는 뜻이다. 논문에서 테스트한 두 모델 모두 각 회사의 최신 세대가 아니며, Gemini 4나 Opus 5.5로 바꿨을 때 향상 폭이 얼마나 남을지는 저자들도 테스트하지 않았다. 이 부분은 제3자의 재현을 기다려야 한다.
참고 출처: arXiv 논문 "VeriHarness: Scaling Agentic Verification for Long-Horizon Tasks", Google Research GitHub 프로젝트 페이지, CocoLoop, Hugging Face 데이터셋 페이지; 논문과 README에서 다섯 개 벤치마크 명칭, 두 모델의 평균 상승 점수, 약 2만 6천 건의 실행 기록, 실행 환경 요구사항을 확인했다.