VerifierBench: AI가 만든 검증기는 맞는 풀이도 알아볼까

배경과 문제

LLM 에이전트가 작업을 수행할 때 자신의 출력을 신뢰성 있게 검증하는 것은 매우 중요하다. 특히 데이터 중심의 재귀적 자기 개선(RSI)에서는 에이전트가 자신의 학습 데이터를 만들고, 강화학습 보상으로 사용할 검증 함수를 함께 생성하기도 한다. 검증기가 잘못되면 위반 사례에 계속 보상을 주거나 유효한 풀이를 버릴 수 있어 학습 과정 전체가 오염될 수 있다. 이 논문은 '검증기 생성(verifier generation)' 문제를 다룬다. 즉, 과제를 푸는 에이전트가 받는 것과 동일한 지시문과 환경만을 받고, 어떤 후보 풀이에 대해서도 PASS 또는 FAIL을 반환하는 실행 가능한 검증기를 작성해야 한다.

일반적인 풀이 생성기(solver)는 하나의 유효한 풀이만 찾으면 되지만, 검증기는 모든 유효한 풀이를 받아들이고 모든 잘못된 풀이를 거부해야 한다. 따라서 과제의 필수 요구사항과 풀이마다 달라질 수 있는 선택적 요소를 구분해야 한다. 예를 들어, 신용카드 유지 과제에서 읽기 전용 조회 도구가 허용되는데, 검증기가 이 도구를 허용 목록에서 빠뜨리면 그 도구를 사용한 올바른 풀이를 거부하게 된다. 기존 연구는 테스트 단언, 단위 테스트, 이슈 재현 테스트 등을 평가했지만, 도구 호출·환경 상태·코드 변경에 따라 정답이 달라지는 에이전트 과제 완료 검증은 다루지 않았다.

기존 접근의 한계

기존의 실행 가능한 검증기 생성 연구는 주로 정적 분석 검사기, 테스트 단언, 단위 테스트 생성에 초점을 맞췄다. 예를 들어 nl2postcond는 자연어 의도를 형식적 사후 조건으로 변환하고, CodeSpecBench는 실행 가능한 행동 명세를 생성하며, CheckerBench는 정적 분석 검사기를 다룬다. 그러나 이들은 에이전트가 실제로 도구를 호출하고 환경 상태를 변화시키며 코드를 수정하는 과제 완료 상황을 평가하지 않는다. 이런 상황에서는 검증기가 도구 상호작용, 결과 환경 상태, 코드 변경을 모두 고려해야 하므로 훨씬 더 어렵다.

기대 풀이 하나만 통과하는지 확인해서는 검증기의 품질을 충분히 알 수 없다. 한 정답은 통과시키면서 다른 유효한 풀이는 거부할 수 있고, 일반적인 실수는 잡으면서도 검증의 빈틈을 악용하는 공격은 받아들일 수 있기 때문이다. VerifierBench는 과제마다 여러 유효 변형과 오류·공격 사례를 넣어, 정답 수용과 오답 거부를 함께 시험한다.

연구방법을 단계별로

VerifierBench는 6개 오픈소스 에이전트 벤치마크(BFCL v4, ACEBench, τ²-bench, AppWorld, AgentDojo, SWE-bench Verified)에서 222개 과제를 추출했다. 각 과제는 도구 호출(95개), 상태 기반(80개), 코드 검증(47개) 중 하나로 분류된다. 각 과제에 대해 지시문과 환경만 제공하고, 참조 검증기와 숨은 테스트 사례는 생성자에게 주지 않는다. 테스트 사례는 네 그룹으로 구성된다: 참조 풀이 222개(양성), 유효 변형 1,344개(양성), 일반 오류 2,629개(음성), 공격 798개(음성). 유효 변형은 표현만 바꾸거나 다른 구현·실행 경로를 사용하지만 과제 요구사항을 모두 만족하는 풀이다.

테스트 사례의 라벨이 신뢰할 수 있어야 하므로 Verifier4Verifier(V4V)라는 6단계 감사를 수행한다. ① 재생(Replay): 소스 검증기를 모든 테스트 사례에 실행해 구성 라벨과 비교, ② 반복성(Repeatability): 같은 초기 조건에서 결정이 안정적인지 확인, ③ 출처(Provenance): 모든 결정을 테스트 사례 내용과 검증기 버전에 연결, ④ 입력-라벨 일관성: 동일한 정보를 받는 사례가 반대 라벨을 갖지 않는지 확인, ⑤ 사소한 기준선: 항상 수용·항상 거부·참조만 수용하는 검증기가 드러나는지 확인, ⑥ 변이 테스트(Mutation testing): 소스 검증기의 검사 하나를 변경했을 때 테스트 스위트가 그 변화를 감지하는지 확인. 이 감사에서 확인된 결함으로 45개 과제가 제외되었고, 남은 222개 과제의 소스 검증기가 참조 검증기가 된다.

평가 지표는 과제별로 양성 사례 중 PASS를 받은 비율(TPR)과 음성 사례 중 FAIL을 받은 비율(TNR)을 계산한 뒤, 과제 간 평균을 내고 두 클래스를 동일하게 가중한다. 주 지표는 정규화된 균형 정확도 BAnorm = TPR + TNR − 100이다. 항상 PASS 또는 FAIL을 반환하면 0점, 완벽한 일치는 100점이 된다. 무응답이나 충돌도 분모에 남고 점수를 받지 못한다. 19개 모델을 공통 하네스 Pi에서 평가하고, 하네스 효과를 보기 위해 17개 추가 구성(네이티브 하네스 등)을 실험했다. 생성 예산은 과제당 5,400초, 응답당 출력 토큰 32,768개, 상태·코드 과제의 환경 실행(run_public)은 생성 중 과제당 20회로 제한된다. 이 예산은 탐색과 자기 시험이 공유하며 숨은 평가의 실행 예산과는 별개다.

결과와 숫자의 의미

공통 Pi 하네스에서 19개 모델의 BAnorm은 10.6에서 62.1까지 분포한다. 최고는 GPT-6-astra(62.1)이고, Claude Opus 4.8(54.0), Kimi K3(53.4)가 뒤를 잇는다. 모든 모델이 TPR(21.1~70.2%)이 TNR(79.2~96.3%)보다 낮다. 즉, 유효한 풀이를 받아들이는 것이 공통적인 약점이다. 통과하지 못한 양성 사례 중 57.1~100%가 무응답이 아닌 명시적 FAIL이었다. 유효한 풀이를 적극적으로 거부하는 문제가 큰 비중을 차지한다. 과제 유형별로 보면 도구 호출 과제의 평균 TPR은 79.2%로 비교적 높지만, 상태 과제는 27.7%, 코드 과제는 40.2%로 크게 떨어진다.

분석한 기록에서 오탈락은 '전부 거부(all-reject)' 검증기에 특히 집중됐다. 전부 거부 검증기는 해당 과제의 모든 테스트 사례(양성·음성 모두)에 유효한 FAIL을 반환한다. 9개 모델의 보존 기록을 분석한 결과, 전부 거부 검증기가 각 모델의 양성 FAIL 결정의 87.9~96.0%를 차지했다. 별도의 Astra 추적 배치(4가지 조건)에서도 68~75개의 검증기가 전부 거부였고, 오탈락의 93.3~95.5%를 기여했다. 이는 거부 비율만 높게 만들면 좋은 검증기가 된다는 생각의 한계를 보여준다. 다만 모든 FAIL이 의미적으로 지나친 조건 때문이라고 확인한 것은 아니다.

하네스 효과는 방향이 일정하지 않다. Claude Opus 4.8은 Pi에서 54.0이지만 Claude Code에서는 66.2로 12.2점 상승해 전체 36개 구성 중 최고가 되었다. 반면 GPT-6-astra는 Pi 62.1에서 Codex 58.0으로 4.1점 하락했다. Gemini 3.5 Flash는 Gemini CLI에서 15.0점 상승했지만, Gemini 2.5 Pro는 9.2점 하락했다. Codex는 실행한 5개 모델 모두의 점수를 낮췄다. 하네스는 프롬프트, 도구, 추론 설정이 다르므로 이 차이는 모델 능력 단독의 인과 효과가 아니라 구성(configuration) 간 비교로 해석해야 한다. 추론 노력(HIGH vs LOW)은 Astra 배치에서 Pi 기준 BAnorm +0.5, Claude Code 기준 −1.3으로 거의 변화가 없었지만, 과제 유형별로는 코드 과제는 개선되고 상태 과제는 악화되는 상반된 효과가 있었다.

구체적인 예시

논문은 12개 과제, 16개 검증기 사례에서 119개의 양성 FAIL(90개 서로 다른 사례)을 분석했다. 이들은 모두 '과제가 요구하지 않는 검사(unjustified check)' 때문이었다. 예를 들어, τ²-bench 은행 과제 044에서 검증기가 도구 허용 목록을 만들면서 허용된 읽기 전용 조회 도구 get_user_dispute_history_7291을 빠뜨렸다. 이 검증기는 합법적인 조회를 '지원되지 않는 변형'으로 간주해 9개 양성 사례를 모두 환경 실행 전에 거부했다. 자가 시험에서도 같은 도구를 빠뜨려서 문제를 발견하지 못했다.

또 다른 예로, retail/34 과제에서 사무용품 3개(기계식 키보드, 헤드폰, 사무용 의자)를 제거해야 하는데, 검증기가 사무용품 목록에 'Headphones'를 빠뜨려 2개만 인식했다. 그 결과 9개 양성 사례 모두 FAIL을 받았다. 코드 과제에서는 Django-11734에서 검증기가 __init__.py 파일 수정을 금지했는데, 참조 수정과 표현 변형으로 된 양성 사례 4개 모두 그 파일을 수정했다. 서로 독립적인 수정 전략 4개라는 뜻은 아니다. 자가 시험은 query.py만 수정해서 이 제한을 시험하지 못했다.

자가 시험의 실패 패턴은 두 가지로 나뉜다. 첫째, '확증적 자가 시험(confirmatory self-testing)'은 검증기가 이미 허용하는 풀이만 시험하는 것이다. 예를 들어 DNA 분석 과제에서 mutation_type 인자가 기본값 insertion을 갖는데, 검증기가 인자를 생략하면 빈 문자열로 처리했다. 자가 시험은 항상 인자를 명시적으로 제공해서 이 오류를 놓쳤다. 둘째, '수용을 확인하지 못하는 자가 시험'은 의도한 양성 풀이조차 완전한 PASS를 받지 못하는 경우다. 은행·소매 과제 8개 검증기에서 에이전트가 양성 자가 시험을 시도했지만 예산 소진 등으로 완전한 PASS를 얻지 못했고, 최종 응답에서 이를 인정했다. 이들은 평가에서 72개 양성 판정을 모두 환경 실행 없이 거부했다.

한계와 오해하기 쉬운 점

이 연구의 점수는 유한하게 구성된 테스트 스위트에서 참조 검증기와의 일치도를 측정한 것이다. V4V가 45개 과제를 제외했지만, 구성 라벨과 참조 결정의 일치가 모든 라벨이 의미적으로 정확함을 보장하지는 않는다. 또한 36개 구성은 하네스 프롬프트, 도구, 추론 설정이 다르므로 교차 하네스 차이는 구성을 설명할 뿐 단일 하네스 구성 요소의 효과를 분리하지 못한다. 순위는 반복 생성이나 유의성 검정이 없는 점 추정치다.

오탈락 집중 분석은 9개 모델의 과거 보존 기록과 1개 모델(GPT-6-astra)의 Astra 추적 배치를 사용했다. 전체 19개 모델의 최종 과제별 기록을 직접 계산한 것이 아니다. 따라서 '전체 19개 모델에서 전부 거부 검증기가 오탈락의 87.9~96.0%를 차지한다'고 일반화하면 안 된다. 사례 분석은 실패를 설명하기 위해 선별된 검증기(주로 GPT-6-astra)를 대상으로 하며, 코드 읽기로 원인을 귀속하고 개입 실험이나 각 자가 시험 시점의 버전 복원을 하지 않았다. 따라서 메커니즘의 유병률(prevalence)을 추정하지 않는다.

숫자 해석에서도 주의가 필요하다. BAnorm 62.1은 전체 정확도 62.1%가 아니다. 과제별 TPR과 TNR을 각각 평균해 더한 뒤 100을 뺀 값이다. 또한 표의 반올림은 독립적으로 이루어져 합계가 0.1점 차이날 수 있다. 공격 허용률(FPRh)이 낮다고 해서 신뢰할 수 있는 검증기라는 뜻은 아니다. 예를 들어 상태 과제에서 GPT-5.6-sol은 FPRh 0.0%이지만 양성의 23.0%만 받아들여 BAnorm이 16.1에 불과하다. 코드 과제에서는 17개 모델이 FPRh 0.0%인데도 BAnorm이 −25.9에서 76.9까지 넓게 퍼져 있다.

실제로 어떻게 활용할까

이 연구의 실용적 시사점은 검증기 생성 시 자가 시험을 어떻게 설계해야 하는가에 있다. 자가 시험은 두 가지 목표를 가져야 한다. 첫째, 선택한 풀이를 검증기가 받아들이는지 확인하는 것, 둘째, 과제가 허용하는 다른 풀이를 거부하지 않는지 확인하는 것이다. 두 번째 목표를 위해서는 모든 수용 조건을 지시문, 도구 정의, 환경 규칙으로 추적하고, 그 요구사항에서 파생된 사례로 시험해야 한다. 예를 들어, 허용된 속성을 바꾸면서 과제는 여전히 만족하는 사례(다른 파일 수정, 기본 인자 생략, 인가된 사용자 측 호출 등)를 시험하고, 반대로 하나의 필수 조건을 위반하는 사례도 시험해야 한다.

논문은 '좋은 풀이 하나와 다른 허용 풀이를 모두 검사하고, 각 거부 조건을 지시와 대조하라'는 방향을 제안한다. 그러나 이 개선책의 실제 효과나 새로운 RL 학습 성능은 이 논문에서 시험하지 않았다. 또한 생성 중 탐색과 자가 시험이 실행 예산을 공유하므로, 최종 검증기를 시험할 예산을 따로 확보하고 실행 실패와 요구사항 실패를 구분해야 한다. 예를 들어 차단된 테스트는 검사를 미해결로 남기며, 실행을 고친다고 해서 테스트가 다루지 않은 검사가 검증되지는 않는다. 데이터 중심 RSI에서 생성된 검증기가 훈련 데이터를 선별한다면, 이런 과도한 제한이 합법적인 풀이 전략을 반복적으로 배제할 수 있다는 점을 인지해야 한다.