Verifier 역할은 검증된 검증자가 아니다

TRINITY가 Verifier 역할을 출시했습니다. 누가 테스트해 보았나요?

업계는 Verifier 테스트를 출시하는 속도보다 Verifier 역할을 출시하는 속도가 더 빠릅니다.

Sakana AI가 동시에 두 가지를 내놓았습니다. TRINITY — LLM 풀(pool) 위의 코디네이터(coordinator)를 공식화한 ICLR 2026 논문으로, 할당된 역할 중 하나가 **Verifier (검증자)**입니다. 그리고 Fugu — 단일 OpenAI 호환 엔드포인트로 제공되는 프로덕션용 멀티 에이전트 오케스트레이션(multi-agent orchestration) 시스템으로, Sakana의 연구가 제품으로 향하는 방향성을 제시합니다. Fugu 기술 보고서는 오케스트레이션 설계 선택 사항과 벤치마크 방법론을 다룹니다.

이 순간은 에이전트 검증(agent verification)이 사후 고려 사항이 아닌, 최상위 연구소의 논문에서 명명된 일급 역할(first-class role)이 되는 시점입니다. 이는 중요한 일입니다. 평가에서 누락된 부분 또한 마찬가지입니다.

이것은 Sakana의 결과에 대한 비판이 아닙니다. 더 좁은 질문이며, 제가 가장 깔끔하게 표현할 수 있는 방식은 다음과 같습니다: 역할 라벨은 아키텍처(architecture)의 선언이지, 능력(capability)의 증거가 아닙니다. 시스템이 Verifier 역할을 명명했다면, 해당 검증자가 단순히 오케스트레이션에 참여하는 것이 아니라 심어진 오류를 탐지한다는 것을 무엇이 증명할 수 있을까요?

TRINITY가 명명한 것

TRINITY 논문의 섹션 3.2는 다음과 같이 말합니다:

Verifier는 𝒞{k−1}에 축적된 솔루션이 정확하고, 완전하며, Q에 응답하는지 확인합니다. 이는 판단 u_k ∈ {ACCEPT, REVISE}와 선택적 진단 δ_k를 출력합니다._

이것이 계약(contract)입니다. Verifier는 축적된 트랜스크립트(transcript)와 원래의 쿼리(query)를 소비하여 이진 판단(binary judgment)을 반환하며, 진단을 제공할 수 있습니다. 이 역할은 코디네이터에 의해 호출되며, 코디네이터는 7개의 후보 모델(GPT-5, Gemini-2.5-pro, Claude-4-Sonnet 및 4개의 오픈 소스 모델) 중 하나에 역할을 할당합니다.

논문이 명시하지 않은 두 가지가 있습니다.

Verifier는 어떤 독립적인 참조(independent reference)를 바탕으로 정답 여부를 확인하는가? 대화 기록(transcript)과 질의(query)가 모두 루프 내부에 존재합니다. 외부의 정답(ground truth), 격리된 명세(held-out spec), 혹은 제2 채널의 오라클(second-channel oracle)이 없습니다. Verifier는 시스템 자체의 출력물을 시스템이 재진술한 문제 내용과 대조하여 확인하고 있는 것입니다.

Verifier가 Thinker 또는 Worker와 동일한 베이스 모델(base model)을 공유하는지 여부. 논문은 역할-모델 할당(role-to-model assignment)을 코디네이터(coordinator)가 학습하는 것으로 설명하지만, 동일한 실행(run) 내에서 같은 모델이 Thinker와 Verifier로 동시에 할당될 수 있는지 여부는 명시하지 않습니다. 7개의 모델 풀(pool)이 있다면, 라운드 간 역할 중복이 발생할 확률은 무시할 수 없습니다. 만약 GPT-5가 $k$ 라운드에서는 Thinker이고 $k+1$ 라운드에서는 Verifier라면, 두 번째 의견은 첫 번째 의견과 동일한 뇌를 공유하는 셈입니다.

Fugu 기술 보고서는 지연 시간(latency)을 고려한 변형 모델(latency-aware variant)을 위해 다음과 같은 관련 설계 선택 사항을 추가했습니다:

선택된 모델은 항상 워커(worker)로 호출되며, 이는 조정 공간(coordination space)을 줄이고 오케스트레이션 지연 시간(orchestration latency)을 낮춥니다.

따라서 그곳에 기술된 지연 시간 고려형 Fugu 변형 모델에서는 역할이 폐지됩니다. 즉, 선택된 모델은 항상 워커로 호출됩니다. 품질 우선형 변형 모델인 Fugu-Ultra는 액세스 리스트(access lists)를 통한 격리를 포함한 멀티 에이전트 조정(multi-agent coordination)에 의존합니다. TRINITY Verifier 프리미티브(primitive)는 연구용 산출물(research artifact)입니다. 프로덕션 시스템은 한 가지 변형 모델에서 지연 시간 문제로 인해 역할을 폐지하는 방식을 선택했습니다. 그 자체로 하나의 신호입니다.

작업 결과는 인상적이다

차이점을 논하기 전에, 증거를 살펴보겠습니다. Fugu는 Sakana의 벤치마크 페이지에서 실질적인 승리를 거두고 있습니다:

Rubik's Cube Solver (루빅스 큐브 솔버): Fugu-Ultra는 300개의 큐브를 모두 해결했습니다. 다른 모든 프론티어 모델 (frontier model)은 유효한 해답을 단 하나도 내놓지 못했습니다. 이는 통계적 노이즈가 아닌 실제적인 압도입니다.
Classical Japanese Text (고전 일본어 텍스트): Fugu-Ultra는 NED 0.80을 기록했으며, 그다음으로 우수한 경쟁자는 0.24를 기록했습니다. 대부분의 프론티어 모델이 거의 다루지 않는 언어 작업에서 3배 이상의 성능 향상을 보였습니다.
SWE Bench Pro: Fugu Ultra는 73.7을 기록했으며, Opus는 69.2 대비 4.8을 기록했습니다. 어려운 소프트웨어 엔지니어링 (software-engineering) 벤치마크에서 4.5포인트의 격차를 보였습니다.

이것들은 실제 수치이며 실제 엔지니어링의 결과입니다. 이 글에서 다루고자 하는 것과 동일한 캘리브레이션 격차 (calibration gap)는 벤치마크 해석에서도 나타납니다. Fugu의 블라인드 체스 (blindfold-chess) 결과는 Elo 2100으로 설정된 Stockfish를 상대로 한 것이며, 논문에는 정직하게 기재되어 있으나 소셜 미디어의 에코 체임버 (echo chamber)에서는 왜곡되었습니다. 증거는 실재하지만, 그 증거가 전달되는 프레임 (framing)은 주의 깊게 읽어야 할 부분입니다.

질문은 더 좁혀집니다. 오케스트레이션 (orchestration) 내부의 Verifier (검증자) 역할이 실제로 작동하고 있는 것인지, 아니면 최종 작업 정확도 (end-task accuracy)가 검증과는 아무런 상관이 없는 이유로 상승하고 있는 것인지에 대한 문제입니다.

벤치마크 승리는 Verifier 테스트가 아니다

최종 작업 정확도와 Verifier의 신뢰도는 동일한 측정 지표가 아닙니다. 시스템은 다음과 같은 이유로 강력한 벤치마크 수치를 기록할 수 있습니다:

Thinker (생각하는 모델)와 Worker (작업하는 모델)가 개별적으로 강력한 프론티어 모델이며, 코디네이터 (coordinator)가 이들을 잘 라우팅 (routing)하는 경우
모델 풀 (model pool)이 검증을 통해서가 아니라 라우팅을 통해 실패 모드 (failure modes)를 다양화하는 경우
Verifier가 대부분의 출력물에 대해 승인 (rubber-stamps)을 내리고, 소수의 REVISE (수정) 단계가 우연히 중요한 사례들을 잡아내는 경우
Verifier가 결코 거절하지 않으며, Worker들이 이미 충분히 뛰어나기 때문에 시스템이 승리하는 경우

이 네 가지 경우 모두 벤치마크 점수는 올라갑니다. 하지만 그중 오직 한 가지 경우에만 Verifier가 그 역할 이름이 시사하는 바와 같은 일을 수행하고 있는 것입니다. 최종 작업 정확도만으로는 이들을 구분할 방법이 없습니다.

이는 quorum verification (정족수 검증)에 대한 devto-09의 주장과 같은 형태입니다. 즉, 독립성(independence)이란 아무도 검증하지 않는 가정이라는 것입니다. 여기서는 한 단계 더 나아갔습니다. 의도적으로 심어진 오류(planted errors) 하에서 테스트되지 않는 Verifier 역할은 검증자가 아닙니다. 그것은 오케스트레이션 (orchestration)에 참여하는 제3의 의견일 뿐입니다. 그것이 여전히 유용할 수는 있겠지만, _verifier_라는 단어가 약속하는 바는 아닙니다.

도구 사용 (Tool-use)은 검증 경계를 이동시킬 뿐, 제거하지 않는다

체스 예시 외에서 나올 수 있는 자연스러운 반론은 다음과 같습니다: 하지만 에이전트 시스템 (agentic systems)은 코드를 작성하고, 도구를 호출하며, 솔버 (solvers)를 실행하고, 출력을 확인할 수 있습니다. 모델이 내부적으로 모든 것을 계산할 필요는 없습니다. 도구가 계산을 수행할 수 있기 때문입니다.

맞습니다. 그리고 바로 그 지점이 검증 경계가 사라지는 것이 아니라 이동해야 하는 지점입니다.

Fugu의 눈 가리고 체스 두기 예시는 사실 정반대의 사례입니다. 기술 보고서(technical report)에 따르면 해당 작업은 에이전트 스캐폴드 (agentic scaffold)를 사용하지 않으며, 모든 모델은 가공되지 않은 API를 통해 직접 질의되고, 보드 상태는 결코 재진술되지 않습니다. 이는 체스 결과가 도구 사용 (tool-use) 결과가 아니라, 더 깔끔한 롱 컨텍스트 (long-context) 및 상태 추적 (state-tracking) 결과임을 의미합니다.

에이전트가 버그가 있는 도구 코드를 작성합니다. 인덱스 오차 (off-by-one indexing), 잘못된 상수, 비용 함수 (cost function) 내 변수 뒤바뀜 등이 발생할 수 있습니다. 도구는 예외 (exception)를 발생시키지 않고 실행됩니다. 출력값은 조용히 틀린 상태가 됩니다. 만약 해당 버그가 테스트 분포 (test distribution)에서 트리거되지 않는다면, 홀드아웃 테스트 (held-out test)에서의 최종 작업 정확도 (end-task accuracy)는 여전히 괜찮아 보일 수 있습니다.
에이전트가 도구 출력을 잘못 파싱합니다. 도구는 정답을 반환합니다. 에이전트는 이를 유사하지만 틀린 값—숫자, 부호, 단위 등—으로 전사 (transcribe)합니다. 도구는 올바르게 작동했습니다. 통합 경계 (integration boundary)가 깨진 것입니다.
에이전트가 잘못된 도구로 라우팅하거나, 잘못된 시점에 라우팅합니다. A에 대해 질문을 받았는데 B를 위한 도구를 호출합니다. B에 대해 질문을 받았는데 존재하는 도구를 호출하는 대신 학습 데이터 (training data)를 바탕으로 추론하려고 시도합니다. 라우팅 (routing)은 모델 측의 결정이며, 롱 컨텍스트 (long-context) 및 다단계 파이프라인 (multi-step pipelines)에서는 운에 따라 결정될 수 있습니다.

TRINITY의 Verifier는 최종적으로 축적된 솔루션을 원래의 쿼리 (query)와 대조하여 확인합니다. 현재 작성된 계약 (contract)상, Verifier는 도구 호출의 출처 (tool-call provenance), 파싱 충실도 (parse fidelity), 또는 라우팅 결정 (routing decisions)을 확인하지 않습니다. 만약 에이전트가 파이프라인 중간에서 조용히 정보를 망가뜨렸음에도 불구하고, 최종 답변이 여전히 기대되는 형태와 패턴이 일치한다면, Verifier는 ACCEPT를 반환합니다.

도구 증강 쿼럼 (tool-augmented quorum)의 가면을 쓰고 있는 단일 장애점 (single point of failure)입니다. 이는 도구를 사용하지 않는 에이전트의 검증 격차 (verification gap)와 동일한 형태이며, 각 경계마다 자체적인 결함 주입 테스트 (planted-fault tests)가 필요합니다.

누락된 실험: 주입된 Verifier 결함

Verifier 역할을 실제로 평가하려면 무엇이 필요할까요? 이것들은 불가능에 가까운 (moonshot) 실험이 아닙니다. 부록 수준의 규모를 가진 평가들입니다.

1. 탐지 능력 (Detection power). TRINITY가 이미 실행 중인 벤치마크에서 200개의 예시를 가져옵니다.

Verifier에게 _정답(correct)_을 제공합니다. ACCEPT(수락) 비율을 측정합니다. 1.0에 가까워야 합니다.
Verifier에게 미묘하게 틀린(subtly wrong) 솔루션을 제공합니다: 오프 바이 원(off-by-one), 잘못된 상수, 변수 바뀜, 부호가 어딘가 뒤집힌 그럴듯한 구조 등. REJECT(거부) 비율을 측정합니다. 진정한 Verifier라면 이들 대부분을 거부해야 합니다.
Verifier에게 그럴듯하지만 무관한(plausible-but-irrelevant) 솔루션을 제공합니다: 다른 질문에 대한 잘 형식이 갖춰진 답변. REJECT(거부) 비율을 측정합니다.

세 가지 카테고리 모두를 비슷한 비율로 ACCEPT(수락)하는 Verifier는 아무것도 탐지하지 못하고 있는 것입니다. 그것은 투표를 하고 있는 것입니다.

2. 독립성 테스트 (Independence test). 동일한 200개의 예시를 두 번 실행합니다:

Verifier가 검증 중인 라운드의 Thinker와 _동일한 베이스 모델(same base model)_을 사용합니다.
Verifier가 _다른 베이스 모델(different base model)_을 사용합니다 — 다른 계열(family), 다른 사전 학습 데이터(pretraining data).

의도적으로 오류를 심은 조건(planted-wrong condition)에서의 REJECT(거부) 비율을 비교합니다. 만약 비율이 같다면, 역할 할당(role assignment)은 실질적인 의미가 없습니다. 즉, Verifier는 Thinker와 뇌를 공유하든 아니든 동일하게 동작한다는 뜻입니다. 만약 다른 계열의 Verifier가 더 많이 거부한다면, 독립성이 실제로 제 역할을 하고 있는 것이며, 역할 할당 시 소프트한 선호 사항(soft preference)에서 하드한 제약 조건(hard constraint)으로 격상되어야 합니다.

3. 도구 경계 테스트 (Tool-boundary test). 도구를 사용하는 파이프라인(pipelines)의 경우, 경계 지점에 오류를 심습니다:

올바른 도구 호출, 올바른 출력, 하지만 트랜스크립트(transcript)에 잘못 기록됨(mistranscribed).
잘못된 도구 선택, 그럴듯한 출력, 하지만 정확한 것처럼 그대로 전달됨.
일관성 있어 보이지만 틀린 결과를 생성하는 버그가 있는 도구 코드.

Verifier가 각각을 얼마나 자주 잡아내는지 측정합니다. 최종적으로 축적된 솔루션만 확인하고 이를 생성한 파이프라인을 확인하지 않는 Verifier는 구조적으로 이들 대부분을 놓치게 됩니다.

이 실험들 중 그 어떤 것도 새로운 인프라를 요구하지 않습니다. 단지 이 실험들을 실행하기로 결정하는 것만이 필요할 뿐입니다.

패턴은 구조적입니다

이 패턴은 단 일주일 만에 여러 독립적인 스택에서 나타납니다. 에이전트형 IDE (agentic IDE) 툴링에서의 '두 번째 시각 (second-view)' 규율, 다른 운영자의 오픈 프레임워크에서 나타나는 일정한 리듬과 외부에서 작성된 제약 조건을 가진 '검증자 (verifier)' 형태, 세 번째 스택에서의 '적용/자문 (apply/advisory)' 분리. 그리고 이제는 최첨단 연구소 (frontier lab)의 ICLR 논문에서 프로덕션 엔드포인트 (production endpoint)와 결합된 명시적인 '검증자 (Verifier)' 역할이 등장했습니다.

사용되는 어휘는 다르지만, 형태는 동일합니다. 모든 계층에서 시스템은 검증 (verification)을 명시하고 있지만, 그 어떤 계층에서도 검증자 (verifier) 자체가 틀릴 수 있다는 가정하에 테스트되지 않습니다. 역할에 붙은 라벨이, 아직 역량 증거 (capability evidence)가 수행하도록 요구받지 않은 일을 대신하고 있는 것입니다.

이것은 조정 (coordination)의 문제가 아닙니다. 이는 범주적 격차 (category gap)입니다. 이 분야의 검증자들은 그들이 독립적인 논평을 제공해야 하는 바로 그 종류의 증거, 즉 '최종 작업 정확도 (end-task accuracy)'에 의해 평가됩니다. 검증자와 검증 대상인 시스템이 동일한 지표로 점수가 매겨질 때, 검증자가 유용하게 이견을 제시할 여지는 없습니다. 결국 '수락 (ACCEPT)'이 평형 상태 (equilibrium)가 됩니다.

Devto-09는 이를 한 단계 아래에서 이렇게 명명했습니다: 독립성은 아무도 검증하지 않는 가정이다. TRINITY는 그보다 한 단계 위에서 이름까지 붙여진 동일한 격차를 보여줍니다. 역할을 명명하는 것만으로는 루프를 닫을 수 없습니다. 의도적으로 심어진 결함 (planted faults) 하에서 그 역할을 테스트해야 루프가 닫힙니다.

결론

공로를 돌려야 할 곳에는 돌려야 합니다. Sakana AI 팀은 TRINITY에서 검증자 (Verifier)를 일급 객체 역할 (first-class role)로 격상시키고, 기술 보고서 (technical report)를 첨부한 프로덕션급 멀티 에이전트 엔드포인트인 Fugu를 출시함으로써 이 분야에 기여했습니다. 두 결과물 모두 논의를 진전시킵니다. 다음 단계는 검증자 (Verifier)를 하나의 독립된 개체로서 테스트하는 것입니다. 위의 실험들은 작고 공개적이며, 해당 논문이 이미 사용 중인 7개 모델 풀을 대상으로 재현 가능합니다.

그때까지, 검증자 (Verifier)가 루프에 포함된 모든 벤치마크 승리에는 별표(*)가 붙을 것입니다. 시스템은 작동했습니다. 하지만 시스템 내부의 검증자가 제대로 작동했는지는 별개의 문제이며, 아직 그 질문은 던져지지 않았습니다.

역할 레이블 (role label)은 아키텍처 (architecture)에 대한 선언입니다. 의도적 결함 삽입 평가 (planted-fault eval)는 해당 아키텍처가 레이블이 주장하는 바를 실제로 수행하고 있는지 보여주는 가장 저렴한 증거입니다. 현재 업계는 검증자 (Verifier) 역할에 대한 배포를 검증자 테스트 (Verifier testing)의 배포보다 더 빠르게 진행하고 있습니다. Sakana는 이를 변화시킬 수 있는 위치에 있습니다. 그들에게는 오케스트레이터 (orchestrator), 모델 풀 (model pool), 벤치마크 (benchmarks), 그리고 엔지니어링 역량 (engineering bench)이 있기 때문입니다. 의도적 결함 삽입 평가 (planted-fault eval)는 단 하나의 부록 (appendix)만으로도 구현될 수 있습니다. 이 평가가 우리에게 알려줄 것은, 세 번째 의견이 검증자 (verifier)인지 아니면 단순한 투표 (vote)인지 여부입니다.