Generator–Verifier: 만드는 모델과 검사하는 모델

왜 만드는 모델과 검사하는 모델을 나누나

이 글은 Generator–Verifier 시리즈의 1편으로, 생성기와 검증기를 나눠 쓰는 생각의 뿌리와 연구 흐름을 정리한다. 생성기(Generator)는 답을 만들어 내는 모델이다. 검증기(Verifier)는 그 답이 맞는지 점수를 매기거나 판정하는 모델이나 프로그램이다.

출발점은 LLM이 여러 단계를 거치는 추론에서 한 번의 실수로 무너지기 쉽다는 관찰이다. GSM8K를 내놓은 검증기 연구논문는 자기회귀 모델(앞 토큰을 보고 다음 토큰을 하나씩 만드는 모델)에 생성 도중 자기 오류를 바로잡는 장치가 없다고 지적했다. 그래서 한 번 엇나간 풀이는 되돌리기 어렵다. 같은 연구는 생성 방식만으로 어려운 문제에서 성능을 올리려면 지나치게 많은 파라미터가 필요하다는 추세를 들어, 더 유리하게 확장되는 방법을 찾아야 한다고 봤다.

여기서 나온 핵심 아이디어가 '생성–검증 격차'다. 수학 문제를 처음부터 푸는 것보다 남이 쓴 답안을 채점하는 편이 대체로 쉽다. 같은 연구논문도 검증이 일반적으로 생성보다 단순한 과제라고 설명했다. 여기에 여러 후보 중 하나를 고를 수 있다는 '선택지'의 이점도 있다고 했다. 비유하자면 생성기는 답안을 여러 장 써 내는 수험생이고, 검증기는 그중 가장 믿을 만한 답안을 골라 내는 채점자다. 수험생 실력이 그대로여도 채점자가 좋으면 최종 제출되는 답의 질이 올라간다.

이 격차를 실제로 얼마나 활용할 수 있는지, 채점자가 틀리면 무슨 일이 생기는지가 이 시리즈 전체를 관통하는 질문이다.

흐름 ①: Best-of-N과 결과 검증기(ORM)

가장 단순한 사용법은 Best-of-N이다. 같은 문제로 생성기에서 풀이를 N개 뽑고, 검증기 점수가 가장 높은 하나를 고른다. GSM8K 검증기 연구논문는 초등 수준 수학 서술형 문제 8.5K개를 공개했다. 그리고 모델이 만든 풀이가 맞았는지 판단하도록 검증기를 학습시켰다. 테스트 때는 정해진 수만큼 후보를 뽑고, 검증기가 1등으로 매긴 풀이를 제출했다.

결과는 두 가지로 요약된다. 첫째, 파인튜닝만 한 기준선보다 검증기를 쓴 쪽이 모델 크기를 약 30배 키운 것과 비슷하게 성능이 올랐다. 둘째, 데이터를 늘릴수록 검증기 방식이 훨씬 잘 확장됐다. 이 연구는 dropout(학습 중 일부 연결을 무작위로 끄는 기법)이 파인튜닝과 검증 모두에서 강한 정규화 효과를 낸다는 점도 보고했다.

이처럼 최종 답이 맞았는지만 보고 풀이 전체에 점수를 주는 검증기를 결과 보상 모델(ORM, Outcome-supervised Reward Model)이라고 부른다. Let's Verify Step by Step논문의 정리로는 ORM은 CoT(Chain-of-Thought, 단계별 풀이)의 최종 결과만으로 학습한다. 라벨을 만들기 쉽다는 점이 장점이다. 정답이 정해진 문제라면 최종 답만 대조하면 되므로 사람 없이도 학습 데이터를 만들 수 있다.

약점도 같은 데서 나온다. Let's Verify Step by Step논문은 결과만으로 감독받은 모델이 틀린 추론으로 맞는 답에 도달하는 일이 잦다고 짚었다. ORM은 '답이 맞은 풀이'와 '추론까지 옳은 풀이'를 구별하지 못한다.

흐름 ②: 과정 보상(PRM)과 자동 단계 라벨

과정 보상 모델(PRM, Process-supervised Reward Model)은 풀이의 각 단계가 맞는지 따로 판단한다. Let's Verify Step by Step논문은 PRM의 장점을 세 가지로 들었다. 오류가 정확히 어디서 생겼는지 알려 주므로 피드백이 더 정밀하다. 사람이 해석하기 쉽다. 사람이 납득하는 추론 과정에 직접 보상을 준다.

이 연구는 GPT-4 기반 모델로 ORM과 PRM을 비교했고, 어려운 MATH 데이터셋에서 PRM이 ORM보다 크게 앞섰다. 가장 좋은 PRM은 MATH 테스트셋의 대표 부분집합에서 78.2%를 풀었다. 평가 방식도 검증기 관점이다. 생성기는 고정해 두고, 보상 모델이 Best-of-N에서 정답 풀이를 얼마나 잘 골라 내는지로 성능을 쟀다. 이 연구는 단계별 사람 라벨 80만 개를 모은 PRM800K를 공개했다. 또 Active Learning(능동 학습: 모델이 헷갈려 하는 사례를 골라 라벨을 받는 방법)으로 과정 감독의 데이터 효율을 2.6배 높였다.

문제는 비용이다. 최종 답은 자동으로 채점할 수 있지만, 단계별 판정을 자동화할 간단한 방법은 없다. 그래서 이 연구는 사람 라벨러에 의존했다. Math-Shepherd논문는 이 병목을 겨냥해, 사람 주석 없이 자동으로 만든 단계별 감독 데이터로 PRM을 학습했다. 이렇게 만든 PRM은 두 곳에 쓰였다. 여러 출력의 순위를 다시 매기는 검증기, 그리고 단계별 PPO(강화학습 알고리즘의 하나)의 보상이다.

Math-Shepherd논문의 보고에 따르면 Mistral-7B는 단계별 PPO로 정확도가 GSM8K에서 77.9%→84.1%, MATH에서 28.6%→33.0%로 올랐다. 여기에 Math-Shepherd 검증까지 더하면 각각 89.1%와 43.5%가 됐다. 이 흐름의 요점은 같은 PRM이 학습 신호로도, 추론할 때 답을 고르는 도구로도 쓰인다는 것이다.

흐름 ③: 생성형 검증기와 LLM-as-a-Judge

지금까지 본 검증기는 대개 풀이를 넣으면 점수 하나를 내는 판별형 분류기였다. Generative Verifiers 연구논문는 이 방식이 사전학습된 LLM의 글 생성 능력을 활용하지 못한다고 봤다. 그래서 검증 자체를 다음 토큰 예측으로 학습하는 생성형 검증기 GenRM을 제안했다. GenRM은 '이 풀이가 맞는가'라는 물음의 답을 글로 생성하며, 풀이 생성과 검증을 함께 학습한다.

이렇게 하면 LLM의 장점을 그대로 쓸 수 있다. 지시 튜닝과 자연스럽게 결합되고, 판정 전에 CoT로 근거를 풀어 쓸 수 있다. 같은 검증을 여러 번 생성해 다수결로 정하면, 검증 단계에도 테스트 타임 컴퓨트(추론 시점에 더 쓰는 계산)를 들일 수 있다. Generative Verifiers 연구논문는 GenRM이 판별형 검증기와 DPO 검증기보다 낫고, LLM-as-a-Judge(별도 학습 없이 LLM에게 채점을 맡기는 방식)보다도 낫다고 보고했다. Best-of-N 기준 정확도는 알고리즘 과제에서 5%→45.3%, GSM8K에서 73%→93.4%로 올랐다. 쉬운 문제로 학습해 어려운 문제에 적용하는 설정에서도 MATH가 28%→44.6%로 올랐다. 합성한 검증 근거로만 학습해도 수학 풀이의 미묘한 오류를 잡아낼 수 있었다.

정리하면 검증기는 '점수 하나를 내는 분류기'에서 '이유를 말하며 판정하는 모델'로 넓어졌다. 판정에 설명이 붙으면 사람이 검증기의 판단을 점검할 수 있고, 그 설명을 생성기에게 수정 지시로 되돌려 줄 수도 있다. 다만 판정을 글로 생성하는 만큼 검증 한 번에 드는 비용도 커진다. 이 비용은 다음 흐름에서 중요한 문제가 된다.

흐름 ④: 추론 시간 계산에서 검증기가 병목이 되는 이유

Large Language Monkeys논문는 '여러 번 뽑기'를 성능을 키우는 또 하나의 축으로 다뤘다. 여러 과제와 모델에서 커버리지(coverage, 뽑은 샘플 중 하나라도 문제를 푼 비율)는 샘플 수를 네 자릿수 범위로 늘리는 동안 계속 올랐다. 그 관계는 로그-선형인 경우가 많았다. 코딩이나 형식 증명처럼 답을 자동으로 확인할 수 있는 영역에서는 커버리지가 곧바로 성능이 됐다. SWE-bench Lite에서 DeepSeek-Coder-V2-Instruct의 해결 비율은 샘플 1개일 때 15.9%였고, 250개일 때 56%로 올랐다. 당시 단일 샘플 최고 기록인 43%를 넘는 수치다.

하지만 자동 검증기가 없는 영역에서는 이야기가 다르다. Large Language Monkeys논문에 따르면 후보 중 하나를 고르는 흔한 방법인 다수결과 보상 모델은 샘플이 수백 개를 넘으면 정체됐다. 늘어난 샘플 예산을 다 살리지 못한 것이다. 정답이 후보 더미 안에 있어도 골라내지 못하면 소용이 없다. 샘플은 늘릴수록 좋아지는데 고르는 능력이 따라가지 못한다는 점, 이것이 검증기가 병목이 되는 이유다.

Snell 등의 테스트 타임 컴퓨트 연구논문는 추론 시간 계산을 쓰는 두 방식을 비교했다. 하나는 단계별 과정 검증기를 기준으로 탐색하는 방식이고, 다른 하나는 모델이 답을 고쳐 가며 응답 분포를 바꾸는 방식이다. 어느 쪽이 나은지는 문제 난이도에 따라 크게 달랐다. 그래서 문제마다 계산을 알맞게 나눠 주는 '계산 최적' 전략을 쓰자 Best-of-N보다 효율이 4배 넘게 좋아졌다. 계산량을 맞춘 비교에서는 작은 모델이 어느 정도 성공률을 내는 문제에 한해 14배 큰 모델을 앞서기도 했다.

두 연구를 함께 보면 메시지가 분명하다. 추론 시간 계산은 많이 뽑는 것으로 끝나지 않는다. 무엇을 고르고 어디에 계산을 더 쓸지 판단하는 검증기의 품질과 비용이 전체 성능의 한계를 정한다. 검증기 호출이 비싸면 후보를 많이 뽑을수록 검증 비용도 같이 불어난다.

흐름 ⑤: 규칙 기반 검증기로 학습하기(RLVR)와 요즘 방향

검증기는 추론할 때 답을 고르는 데만 쓰이지 않고 학습 신호로도 쓰인다. RLVR(검증 가능한 보상 강화학습)은 수학 정답 대조나 단위 테스트 통과처럼 규칙으로 확인할 수 있는 결과를 보상으로 삼아 모델을 강화학습하는 방식이다. Let's Verify Step by Step논문이 짚었듯 정답을 자동으로 확인할 수 있는 문제라면 결과 감독은 사람 없이 줄 수 있다. 그래서 규칙 기반 검증기로는 학습 신호를 대량으로 싸게 만들 수 있다. 재샘플링 한계 연구논문도 rejection sampling(거절 샘플링: 검증기를 통과한 풀이만 남기는 방법)으로 추론 모델의 학습 데이터를 고르는 흐름을 언급한다. 앞서 본 Math-Shepherd논문는 규칙 대신 학습한 PRM을 PPO의 보상으로 쓴 경우다.

규칙으로 확인할 수 없는 과제에는 다시 학습한 검증기가 필요하다. SWE-Critix논문는 코딩 에이전트 작업에는 성공 기준을 정해 주는 오라클(정답 판정기)이 없는 경우가 많다는 데서 출발했다. 이 연구가 학습한 범용 검증기는 과제와 실행 Trajectory(코드 저장소·도구와 수백 번 주고받은 실행 기록)를 받아 완료 여부를 예측하고, 판단 이유를 자연어로 설명한다. SFT(지도 미세조정)와 강화학습을 결합해 30B 모델들을 학습했다. 보류된 테스트셋에서 분류 정확도는 기본 Qwen3-30B-A3B 추론 모델의 57%에서 SFT 후 66%, 강화학습 후 78%로 올랐다.

다른 방향은 검증기 자체를 고치고 키우는 것이다. 검증기 공진화 연구 'Who Verifies the Verifier?'논문는 정해진 검증기가 없는 열린 과제의 문제를 짚었다. 손으로 쓴 루브릭이나, 자기와 비슷한 모델을 채점하는 LLM 판정기를 그대로 쓰면 보상 해킹과 공통된 사각지대가 생기기 쉽다는 것이다. 그래서 이 연구는 실패 사례에서 작고 대부분 결정적인 결함 탐지기들을 합성하고, 이를 조합해 점검 가능한 검증기를 만들었다. 검증기는 에이전트 점수가 아니라 열 개 항목의 기준 세트와 얼마나 일치하는지로 골랐다. MBPP+에서는 손으로 짠 초기 조합보다 보류 데이터 일치도가 0.21 올랐다.

불완전한 검증기의 한계와 실무 패턴

검증기가 틀리면 계산을 더 써도 소용이 없다. 재샘플링 한계 연구논문는 거짓 양성(false positive, 검증기가 틀린 답을 통과시키는 경우)을 분석했다. 거짓 양성 확률이 0이 아니면 다시 뽑아도 그 확률은 줄지 않으므로, 계산 예산과 상관없이 정확도에 상한이 생긴다. 단위 테스트 커버리지가 제한된 HumanEval과 MBPP에서는 모델의 단일 샘플 정확도와 거짓 양성 비율이 강하게 연관돼 있었다. 그래서 약한 모델을 아무리 많이 뽑아도 충분히 강한 모델의 단일 샘플 정확도에는 이르지 못한다고 봤다. 거짓 양성의 손해가 이득을 넘어서면서, 최적 시도 횟수는 10번 미만인 경우가 많았다.

검증기를 보상으로 쓰면 문제가 더 커진다. 생성기가 검증기가 좋아하는 것을 학습하기 때문이다. Prover-Verifier Games 연구논문는 정답 여부만 기준으로 CoT 풀이를 최적화하면 풀이가 읽고 확인하기 어려워질 수 있음을 보였다. 그래서 작은 검증기를 속이는 틀린 풀이를 내는 '교활한(sneaky)' 생성기와, 검증기가 받아들이는 맞는 풀이를 내는 '도움을 주는(helpful)' 생성기를 번갈아 학습시켰다. 그 결과 검증기의 견고성과 풀이의 읽기 쉬움이 함께 좋아졌다. 검증기 공진화 연구논문의 발견은 더 경고적이다. 기준 세트라는 안전장치를 빼자 검증기는 무엇이든 통과시키는 빈 채점기로 무너졌다. 그런데도 그 검증기로 학습한 스킬은 똑같이 좋아 보였다. 연구진은 하위 과제 점수만으로는 스스로 진화한 검증기를 보증할 수 없다고 결론지었다.

이런 한계를 감안한 실무 패턴은 네 가지로 정리된다. 첫째, 뽑고 고르기(Best-of-N)는 가장 단순하지만 정확도가 검증기의 거짓 양성에 묶이므로 샘플 수를 무작정 늘리지 않는다. 둘째, 탐색에서는 단계별 검증기로 중간 단계에서 가지를 쳐 계산을 아낀다. 테스트 타임 컴퓨트 연구논문가 보였듯 문제 난이도에 따라 계산 배분도 달리한다. 셋째, 생성–비평–수정 루프는 검증기의 설명을 생성기에 돌려줘 답을 고치게 한다. Generative Verifiers 연구논문처럼 판정에 이유가 붙는 검증기와 잘 맞는다.

넷째, 코딩 에이전트에서는 단위 테스트가 가장 손쉬운 규칙 기반 검증기다. 그러나 재샘플링 한계 연구논문가 보였듯 테스트 커버리지가 좁으면 테스트가 그대로 거짓 양성의 통로가 된다. 테스트만으로 확인하기 어려운 긴 작업 기록은 SWE-Critix논문 같은 학습한 검증기로 보완하는 방향이 연구되고 있다.

더 공부하려면, 그리고 2편으로 이어지는 질문

처음 읽는다면 GSM8K 검증기 연구논문로 Best-of-N과 검증기의 기본 구도를 잡고, Let's Verify Step by Step논문으로 ORM과 PRM의 차이를 익히는 순서를 권한다. 다음으로 Large Language Monkeys논문와 재샘플링 한계 연구논문를 이어 읽으면 좋다. 샘플을 늘렸을 때의 가능성과, 검증기의 거짓 양성이 만드는 상한을 한 쌍으로 이해할 수 있다. Generative Verifiers 연구논문와 테스트 타임 컴퓨트 연구논문는 그다음에 읽을 심화 자료다.

이 편을 마치며 남는 질문은 '어떤 검증기가 좋은 검증기인가'다. 지금까지 본 연구들에 비춰 보면 적어도 세 가지 성질이 필요해 보인다. 첫째는 정확도, 특히 틀린 답을 통과시키지 않는 능력이다. 둘째는 비용이다. 후보가 수백 개로 늘거나 탐색의 모든 단계에서 검증기를 부르면, 검증 한 번의 속도가 전체 계산량을 좌우한다. 셋째는 점수의 보정(calibration)이다. 검증기가 '80% 확신'이라고 할 때 실제로 그만큼 맞아야 언제 더 뽑고, 언제 멈추고, 언제 사람에게 넘길지 정할 수 있다.

2편에서는 이 질문을 이어받는다. 빠르고 보정된 판단을 목표로 하는 의사결정 모델 Jev(제브)를 검증기로 쓰면 생성기–검증기 구조의 성능을 어떻게 끌어올릴 수 있는지 살펴본다. 출발점은 두 가지 물음이다. 생성형 검증기처럼 길게 설명하는 판정과 빠른 판정 중 무엇을 언제 쓸 것인가. 거짓 양성을 줄이려면 확신도를 어떻게 활용할 것인가.