Jev로 검증기 만들기: Generator–Verifier 성능 개선 설계

왜 Jev를 검증기 자리에 두나

이 글은 Generator–Verifier 시리즈의 2편이다. 1편에서는 생성기가 후보를 여러 개 내고 검증기가 그중 하나를 고르면 생성기를 바꾸지 않고도 성능을 올릴 수 있다고 했다. 다만 추론 시간 계산을 늘릴수록 검증기가 병목이 된다는 점도 함께 봤다. 이번 편은 그 검증 자리에 LLM 대신 TypeSafe AI의 의사결정 모델 Jev를 놓았을 때 성능을 어떻게 끌어올릴지 설계해 본다.

TypeSafe 공식 문서글는 이렇게 설명한다. LLM은 사람이 읽을 글을 만들도록 설계돼 있어서, 코드가 받아 쓸 판정을 시키면 글을 다시 구조화된 값으로 파싱해야 하는 어긋남이 생긴다. Jev는 글을 생성하지 않고 타입이 정해진 값과 확률 분포를 바로 돌려준다. 질문 유형은 세 가지다. Choice는 목록에서 하나를 고르고(choice·probabilities·confidence), Score는 루브릭(채점 기준표)으로 점수를 매기며(score·probabilities·confidence), Noul은 어떤 진술이 참인지를 0~1 값으로 답한다. LLM-as-Jev 연구논문도 같은 세 형식을 각각 선택, 이진 검증, 순서형 채점으로 정리했고, Jev의 가중치와 학습 방법은 공개되지 않았다고 적었다. JEVal 연구논문에 따르면 Jev는 호스팅 API로만 쓸 수 있다.

이 글에서는 두 종류의 문장을 나눠 쓴다. '근거:'로 시작하는 내용은 논문이나 공식 문서에 있는 사실이다. '설계 제안:'으로 시작하는 내용은 그 근거에서 필자가 이끌어 낸 제안이며 검증된 결과가 아니다. TypeSafe가 직접 밝힌 속도·가격 수치는 제공자가 자체 측정했다는 점을 따로 밝힌다.

핵심 아이디어: 빠른 1차 판독, 느린 2차 심사

공항 보안 검색대를 떠올리면 쉽다. 모든 가방은 X선 판독기를 빠르게 지나가고, 판독이 애매한 가방만 사람이 열어 본다. Jev는 판독기 역할을 맡는다. 모든 후보에 값싸게 붙어 점수와 확신도를 낸다. 가방을 여는 정밀 검사는 강한 LLM 검증기나 사람이 맡는다.

근거: Jev에서 영감을 받은 프리필 전용 결정 모델을 다룬 연구논문가 있다. 프리필 전용이란 입력만 한 번 읽고 글자를 하나씩 이어 쓰는 디코딩은 하지 않는다는 뜻이다. 이 연구에 따르면 이런 모델은 한 번의 순전파로 선택지 전체를 채점하므로, 호출 한 번이 같은 규모의 생성형 언어 모델보다 1~2자릿수 싸다. TypeSafe 공식 문서글도 같은 상태에 대한 여러 질문을 한 번에 병렬로, 서로 독립적으로 평가하므로 질문을 늘려도 응답 시간이 거의 늘지 않는다고 설명한다. 반대편에 있는 생성형 검증기 GenRM논문은 판정을 글로 생성한다. 그래서 CoT(Chain-of-Thought, 단계별 풀이)와 다수결을 쓸 수 있고, Best-of-N에서 GSM8K 정확도를 73%에서 93.4%로 올렸다. 대신 1편에서 봤듯 검증 한 번에 드는 비용이 크다.

설계 제안: 두 검증기를 경쟁시키지 않고 층으로 쌓는다. Jev는 모든 후보를 보는 1차 검증기로 두고, 생성형 검증기는 Jev가 애매하다고 본 사례에만 부른다. 근거: 프리필 전용 연구논문의 실험에서는 같은 비용일 때 확신도 기반 캐스케이드가 같은 모델에 다시 묻는 어떤 방식보다 나았다. 이 층 구조가 터무니없지 않다는 신호지만, 그 연구의 과제와 모델에서 나온 결과라는 점은 기억해야 한다.

어떻게 작동하나: 재순위·단계 검사·라우팅

① Best-of-N 재순위. 설계 제안: LLM이 후보 N개를 만들면, 각 후보를 '질문+후보'라는 상태로 Jev Score에 넣어 루브릭 점수와 확률 분포를 받는다. 그다음 기대 점수나 최고 등급 확률로 후보를 정렬한다. 근거: TypeSafe 공식 문서글는 질문 하나가 좁고 분명한 한 가지만 묻게 하라고 권한다. 여러 요소를 따져야 하는 질문은 요소별로 나눠 묻고, 결과는 코드에서 합치라는 것이다. 이를 따르면 '이 답이 좋은가' 하나를 묻기보다 '요구한 형식을 지켰나', '질문의 조건을 모두 다뤘나', '근거와 결론이 맞물리나'를 따로 묻고 가중합을 코드로 정하게 된다. 우선순위가 바뀌면 프롬프트를 다시 쓰지 않고 계수만 바꾸면 된다.

② 단계·조건 검사. 설계 제안: 풀이나 실행 계획의 각 단계를 '3단계의 계산은 2단계의 결과에서 맞게 이어진다' 같은 진술로 바꿔 Noul에 넣고, 참일 확률을 받는다. 1편의 과정 보상(PRM)이 하던 일을 학습 없이 질문으로 흉내 내는 셈이다. 근거: LLM-as-Jev 연구논문는 이런 모델이 '증거가 규칙을 만족하는지 검증'하는 결정에 쓰인다고 설명한다. JEVal 연구논문에 따르면 판단 근거가 입력에 들어 있을 때 결정 모델은 경쟁력이 있었다. 반면 의학·금융·법처럼 전문 지식이 필요한 영역에서는 뒤처졌다. 그러니 Noul 진술은 판단에 필요한 사실이 입력 안에 함께 들어가도록 만든다.

③ 확신도 라우팅. 설계 제안: 확신도가 높으면 그대로 통과시키고, 중간이면 강한 LLM 검증기에 넘기고, 그래도 애매하면 사람에게 보낸다. 사람이 판정한 사례는 평가 세트로 다시 모은다. 근거: TypeSafe 홈페이지글는 언제 자동으로 행동하고 언제 검토를 요청할지 사용자가 기준값을 정하라고 안내한다. System Switch 연구논문에서는 확신도가 가장 낮은 30%의 결정을 추론 모델에 넘겼다. 이때 무작위로 넘기는 것보다 나은 정도가 1차 모델의 AUROC에 비례했다(순위 상관 0.87). AUROC는 확신도가 맞은 답과 틀린 답을 얼마나 잘 가르는지 보여 주는 지표다. 라우팅의 효과는 정확도보다 이 '가르는 힘'에 달려 있다는 뜻이다.

비용과 지연 계산하기

설계 제안: 전체 비용은 대략 '생성 N회 + 검증 호출 + (상위로 넘긴 비율 × 강한 검증기 비용) + 사람 검토 비용'으로 계산한다. 후보 N개를 Score로 따로 채점하면 상태가 후보마다 달라서 검증 호출도 N번이다. 다만 후보마다 여러 질문을 묻더라도, 같은 상태에 대한 질문은 한 호출로 묶을 수 있다고 TypeSafe 공식 문서글는 설명한다. 후보 전체를 한 상태에 넣고 Choice로 하나를 고르게 하면 호출은 한 번으로 줄지만, 뒤에서 볼 선택지 라벨 위험을 함께 따져야 한다. 대개 비용의 대부분은 생성기 N회가 차지하고, 실제 예산을 좌우하는 변수는 상위로 넘기는 비율이다.

근거(제공자 자체 측정): TypeSafe 홈페이지글는 System One 작업용 워크플로를 기준으로 Jev가 LLM보다 193.6배 빠르고 444.6배 싸다고 밝혔다. 예시로는 Jev가 0.114초·0.000081달러, LLM이 8.566초·0.013880달러였다. 가격은 입력 토큰 10억 개당 42달러로, Claude Fable 5.1보다 입력 가격이 238배 낮다고 밝혔다. 모두 제공자가 고른 조건에서 낸 수치다. 독립 연구 쪽 근거로는 앞의 프리필 전용 연구논문가 밝힌 1~2자릿수 차이와, InnerJev-27B가 일반적인 질의에 약 0.1초에 답했다는 JEVal 연구논문의 보고가 있다.

지연은 평균보다 꼬리를 봐야 한다. 근거: JEVal 연구논문는 τ-bench에서 Jev로 다음 행동을 고르게 했다. 그러자 에피소드 시간의 중앙값은 줄었지만 과제 성공률이 떨어지고 꼬리 지연은 늘었다. 설계 제안: 라우팅을 쓰면 애매한 사례만 느려지므로, 중앙값과 상위 구간 지연을 따로 기록하고 상위로 넘기는 비율을 예산 변수로 관리한다.

N도 크게 잡을 이유가 적다. 근거: 재샘플링의 한계를 다룬 연구논문는 검증기에 거짓 양성이 있으면 최적 시도 횟수가 10 미만인 경우가 많다고 보고했다. 거짓 양성의 손해가 이득을 넘어서 추론 스케일링 곡선이 아래로 꺾였다는 것이다.

보정 확인과 기준값 정하기

보정(calibration)이란 모델이 80%라고 말한 판정들이 실제로 80% 안팎으로 맞는 상태를 말한다. 근거는 한 방향을 가리키지 않는다. JEVal 연구논문에서는 결정 모델이 가장 그럴듯한 답은 맞히면서도 그 확률을 크게 부풀리는 경우가 많았다. TypedBench논문에서는 한 호스팅 모델이 정책은 따랐지만 문구에 민감했고, 확신도를 체계적으로 낮게 냈다. 비용이 비대칭인 상황에서는 그 확률을 쓰는 편이 그냥 1순위 답을 쓰는 것보다 나빠지기도 했다. 반면 LLM-as-Jev 연구논문는 학습하지 않은 Qwen3.5-4B에서 다음 토큰 확률을 읽는 방식이 강한 보정을 보였다고 보고했다. 모델·과제·문구에 따라 방향이 다르므로, 제공자의 '보정된 확신도'라는 설명글은 출발점일 뿐 확인을 대신하지 못한다.

근거: 프리필 전용 연구논문는 선택지 목록만 바꿨을 때의 정확도를 첫 호출의 확률로 예측했다. 순위로 예측하면 4.2점 이내로 맞았지만, 확률값 수준으로 예측하면 21.0점이 틀렸다. 같은 연구에서 같은 모델에 균일하게 호출을 더해도 보정은 좋아졌지만 정확도는 거의 오르지 않았다. 설계 제안: Best-of-N 재순위처럼 순위만 쓰는 곳에는 Jev를 비교적 일찍 들여도 된다. 반면 '0.9 이상이면 통과'처럼 확률의 절댓값을 쓰는 곳은 내 데이터에서 보정을 확인한 뒤에 켠다.

설계 제안: 확인 방법은 이렇다. 실제 트래픽에서 뽑아 정답 라벨을 붙인 평가 세트를 만든다. 확신도를 구간으로 나눠 구간마다 실제 정답률을 비교하고, AUROC도 함께 잰다. 근거: System Switch 연구논문는 정확도, 보정, 확신도로 정답과 오답을 가르는 힘이 서로 다른 성질이라고 밝혔다. 정확도가 비슷한 모델끼리도 AUROC는 크게 달랐다. 설계 제안: 기준값은 '거짓 통과 1건의 비용'과 '상위 호출 1건의 비용'을 놓고 정한다. 정할 때 쓰지 않은 데이터로 다시 확인하고, 질문 문구를 바꾸면 처음부터 다시 잰다. 문구에 민감하다는 TypedBench논문의 결과 때문이다.

위험: 부풀린 확률, 라벨 함정, 오류 누적, 과최적화

확률 부풀림. 근거: JEVal 연구논문는 결정 모델이 확률을 과대평가하는 경향을 보고했다. 재샘플링의 한계를 다룬 연구논문는 검증기의 거짓 양성이 다시 뽑기로 줄지 않아 정확도에 상한을 만든다고 했다. 설계 제안: 확신도가 높은 거짓 통과는 라우팅을 그냥 지나가므로, 높은 확신 구간에서도 일부를 표본으로 뽑아 사람이 감사한다.

선택지 라벨 함정. 근거: Option-Channel 공격 연구논문는 오픈웨이트 결정 모델 7개를 에이전트 가드레일로 시험했다. Jev 자체를 시험한 것은 아니다. 정책과 무관한 서버 로그 여섯 줄을 끼워 넣자, 원래는 맞게 판정하던 정책에서 금지된 행동을 허용하는 비율이 0%에서 63%로 올랐다. 허용 쪽 선택지에 오해를 부르는 이름만 붙였을 때는 라벨을 입력에 넣는 모델 4개에서 이 비율이 93~100%가 됐다. 공격으로 뒤집힌 판정은 원래 판정보다 확신도가 낮지 않아서, 확신도가 가장 낮은 판정을 올려 보내는 방식도 도움이 되지 않았다. System Switch 연구논문에서는 선택지 순서만 바꿔도 일부 모델의 정확도가 달라졌다. 설계 제안: 선택지 이름과 정의는 코드에 고정된 중립적인 표현으로 두고, 생성된 후보 글은 신뢰하지 않는 입력으로 다룬다. 순서를 섞어 판정이 바뀌는지 확인하는 공격 테스트도 평가 세트에 넣는다.

오류 누적. 근거: JEVal 연구논문는 τ-bench에서 빠른 지역 결정의 장점이 긴 Trajectory에 걸친 결정 오류 누적으로 상쇄됐다고 밝혔다. 설계 제안: 단계 검사를 여러 번 통과했다고 전체가 맞다는 뜻은 아니다. 되돌릴 수 없는 단계 앞에는 더 엄격한 기준값이나 상위 검증을 두고, 단계 검사와 별도로 최종 결과 검사를 남긴다.

검증기 과최적화. 1편에서 본 보상 해킹처럼, 같은 검증기로 고르고 같은 검증기로 성과를 재면 검증기의 빈틈에 맞춘 후보가 이긴다. 근거: 재샘플링의 한계를 다룬 연구논문는 검증기로 걸러 학습 데이터를 만드는 방식도 같은 거짓 양성의 한계를 갖는다고 지적했다. 설계 제안: 선택에 쓴 Jev 질문과 최종 평가에 쓰는 기준(사람 라벨, 또는 다른 검증기)을 분리한다. 'Jev 점수는 오르는데 따로 둔 평가 세트의 정답률은 그대로'인 상황을 과최적화 신호로 본다.

작게 시작하는 실험 순서

아래는 모두 설계 제안이다. 첫째, 평가 세트를 만든다. 실제 입력에 사람이 정답이나 판정 라벨을 붙이되 쉬운 사례, 애매한 사례, 앞에서 본 라벨·순서 공격 사례를 함께 넣는다. 둘째, 기준선을 잰다. 생성기 1회 답의 정확도와, 강한 LLM 검증기만 썼을 때의 정확도·비용·지연이 기준선이다. 셋째, Jev를 '그림자 모드'로 붙인다. 판정을 기록만 하고 행동에는 쓰지 않으면서 확신도 구간별 정답률, AUROC, 문구를 바꿨을 때의 흔들림을 잰다.

넷째, 기준값 두 개를 정한다. 하나는 그대로 통과시키는 기준, 다른 하나는 사람에게 보내는 기준이다. 거짓 통과 비용과 상위 호출 비용을 놓고 정하며, 정할 때 쓰지 않은 데이터로 확인한다. 다섯째, 단계적으로 켠다. 순위만 쓰는 작은 N의 Best-of-N 재순위부터 시작하고, 보정이 확인되면 확신도 라우팅을, 마지막으로 Noul 단계 검사를 더한다. 여섯째, 운영 중에는 상위 호출 비율, 표본 감사에서 나온 거짓 통과율, 상위 구간 지연을 계속 본다.

비교군으로 오픈 모델도 한 줄 넣어 두면 좋다. 근거: LLM-as-Jev 연구논문는 학습 없이 오픈 LLM의 다음 토큰 확률에서 결정을 읽는 방법을 제시했다. JEVal 연구논문는 InnerJev-27B가 JEVal에서 Jev와 비슷한 성능을 냈다고 보고했다. 설계 제안: 호스팅 API 하나에만 의존하지 않도록, 같은 평가 세트에 이런 오픈 대안을 함께 돌려 두면 비교 기준이 생긴다.

더 공부하려면

Jev가 어떤 결정에 강하고 약한지 먼저 보려면 JEVal 연구논문를 읽는다. 확률 부풀림과 τ-bench의 오류 누적이 이 글의 위험 부분과 바로 이어진다. 그다음 프리필 전용 결정 모델 연구논문에서 '순위는 안정적이고 확률은 덜 안정적'이라는 성질과 캐스케이드 비교를 보면, 재순위와 라우팅을 왜 나눠서 다뤘는지 알 수 있다.

보정과 기준값을 실제로 재는 방법은 TypedBench논문와 System Switch 연구논문가 구체적이다. 보안 관점에서는 Option-Channel 공격 연구논문를 꼭 읽어 둔다. 오픈 모델로 비슷한 검증기를 만들 생각이라면 LLM-as-Jev 연구논문가 출발점이다.

생성형 검증기를 2차 심사로 둘 때의 배경은 GenRM논문, N을 작게 잡아야 하는 이유는 재샘플링의 한계 연구논문에 있다. 제품의 실제 사용법은 TypeSafe 공식 문서글에서 시작하면 된다. 문서가 다음 단계로 안내하는 Confidence와 Patterns 항목이 확신도 활용과 구성 패턴을 다룬다.