거대 언어 모델(LLM)은 세 가지 익숙한 차원을 따라 성장해 왔습니다. 더 많은 텍스트를 입력하여 사전 학습(pre-training) 규모를 키웁니다. 사후 학습(post-training)을 통해 지시 이행 능력을 정교화합니다. 그리고 추론 시 연산량(test-time compute)을 투입하여 답변 속도를 높입니다. 이 각각의 방식은 모델이 더 나은, 더 빠른, 더 일관된 문장을 생성하도록 유도합니다. 하지만 이 중 어느 것도 더 어려운 문제, 즉 생성된 문장이 실제로 맞는지 아는 문제를 직접적으로 해결하지는 못합니다.
그 간극은 위험해지고 있습니다. 모델은 들여쓰기와 논리적 구조가 완벽한 파이썬 스크립트를 내놓지만, 실행하는 순간 오류를 일으킬 수 있습니다. 차분하고 권위 있는 말투로 의학적 증상을 설명하면서도 진단을 정반대로 내릴 수도 있습니다. 챗봇에게 이는 당혹스러운 버그에 불과하지만, 인간의 감독 없이 작동하는 자율 에이전트에게는 실질적인 결과를 초래하는 실패입니다. 생성과 진실은 같은 기술이 아니며, 이 차이를 인식하는 것이 우리가 신뢰할 수 있는 시스템을 구축하기 위한 첫걸음입니다.
생성의 함정
세 가지 표준 확장 경로는 인식론적 정확성(epistemic accuracy)이 아닌 유창성과 작업 완료를 최적화합니다. 사전 학습은 수조 개의 토큰에 걸쳐 광범위한 통계적 패턴을 구축합니다. 사후 학습은 모델을 인간의 선호도에 맞추는데, 이는 종종 엄격한 정확성보다는 공손함과 자신감에 보상을 줍니다. 추론 시 연산량은 요청당 더 많은 사고 토큰(thinking tokens)을 모델에 제공하여 형식과 단계별 구조를 개선하지만, 여전히 최종 출력을 검증된 답변이 아닌 독백으로 취급합니다.
그 결과는 '유창성의 함정'입니다. 코드는 깔끔해 보이고, 설명은 권위 있게 들리며, 사실은 맞는 것처럼 느껴집니다. 하지만 겉모습의 매끄러움이 근본적인 오류를 가립니다. 생성된 코드를 면밀히 검토하지 않고 운영 파이프라인에 붙여넣는 개발자는 시스템 중단 위험을 감수해야 합니다. AI 어시스턴트를 사용하는 임상의는 모델이 유사한 두 가지 약물 상호작용을 혼동할 경우 심각한 법적 책임을 질 수 있습니다. 우리는 모델이 스스로를 감사(audit)하도록 학습시킨 것이 아니라, 수행(perform)하도록 학습시켰습니다.
확장 축으로서의 검증
LLM-as-a-Verifier라고 불리는 프레임워크는 이 문제를 완전히 재정의합니다. 검증을 사후 고려 사항이나 별도의 인간 검토 단계로 취급하는 대신, 이를 사전 학습, 사후 학습, 추론 가속화와 나란히 하는 네 번째 확장 축으로 취급합니다.
핵심 아이디어는 모델의 기존 추론 능력을 사용하여 자신의 출력을 판단하는 것입니다. 후보 답변을 생성한 후, 동일한 모델이 한 걸음 물러나 이를 평가합니다. 이는 '생성, 점수 매기기, 수정, 반복'이라는 폐쇄 루프(closed loop)를 만듭니다. 모델이 새로운 가중치나 데이터셋으로 재학습되는 것이 아닙니다. 단지 이미 보유한 지능을 저자가 아닌 비평가의 관점이라는 다른 프롬프트 템플릿에 적용하는 것뿐입니다.
이러한 변화가 중요한 이유는 능력(capability)과 신뢰성(reliability)을 분리하기 때문입니다. 검증을 잘하는 작은 모델이 검증을 못 하는 큰 모델보다 더 나은 성능을 낼 수 있습니다. 이는 단순히 파라미터 수를 늘리는 것이 아니라 판단력을 확장하는 것이며, 이는 시스템이 안전하게 수행할 수 있는 작업의 범위를 변화시킵니다.
확률적 점수 매기기의 힘
대부분의 검증 시도는 이진 판정(binary verdict)을 요구하기 때문에 실패합니다. "이 답변이 맞습니까? 예 또는 아니오."와 같은 투박한 신호는 정보를 낭비합니다. 답변이 대부분 맞지만 치명적인 결함 하나를 포함하고 있을 수도 있고, 대부분 틀렸지만 가치 있는 통찰 하나를 담고 있을 수도 있습니다. 이진 점수는 이러한 모든 뉘앙스를 단 하나의 비트로 압축해 버립니다.
LLM-as-a-Verifier는 이를 확률적 점수 매기기(probabilistic scoring)로 대체합니다. 찬성 또는 반대 대신, 모델은 0.92와 같은 연속적인 숫자를 반환합니다. 이 소수점은 의미를 담고 있습니다. 0.92는 모델이 답변이 맞다고 거의 확신한다는 것을 의미하며, 0.34는 무언가 잘못되었다는 느낌을 준다는 것을 알려줍니다. 시스템을 운영하는 사람은 임계값(threshold)을 설정할 수 있습니다. 0.60 미만은 자동 재생성을 트리거할 수 있고, 0.60에서 0.85 사이의 구간은 인간의 검토 대상으로 표시할 수 있습니다. 0.90 이상이면 시스템이 자율적으로 작동합니다.
연속적인 점수는 신뢰도에 대한 산술 연산도 가능하게 합니다. 여러 번의 확인 결과를 평균 내거나, 프롬프트 변형에 따라 가중치를 부여하거나, 여러 후보 답변의 점수를 비교하여 최적의 답변을 선택할 수 있습니다. 이진 판정은 이러한 미세한 의사결정을 지원하지 못합니다.
세 가지 실질적인 장점
이 프레임워크는 세 가지 구체적인 특성에서 강점을 얻습니다.
세밀도. 0.82라는 점수는 "정확함"이라는 표현이 전달하지 못하는 무언가를 전달합니다. 이는 약간의 의구심이 남아있지만 거의 확실하다는 것을 의미합니다. 소프트웨어 공학에서는 코드가 컴파일되고 주요 케이스를 처리하지만, 예외 상황을 놓쳤을 가능성이 있음을 의미할 수 있습니다. 의료 추론에서는 확진 검사가 여전히 필요한 유력한 진단을 나타낼 수 있습니다. 세밀한 점수는 하위 시스템이 모든 성공을 동일하게 취급하는 대신, 그에 맞춰 대응을 조정할 수 있게 해줍니다.
반복. 검증은 생성에 비해 비용이 저렴하기 때문에, 프롬프트를 약간 변형하거나 온도(temperature) 설정을 바꾸어 여러 번 실행할 수 있습니다. 세 번의 독립적인 검사 결과가 각각 0.91, 0.89, 0.93으로 나온다면 합의된 결과라고 볼 수 있습니다. 반면 결과가 0.91, 0.42, 0.87처럼 크게 흩어진다면, 모델이 불확실하며 답변을 보완해야 한다는 것을 알 수 있습니다. 이진 판정기(binary judges)를 통한 다수결 방식은 투박합니다. 연속적인 점수를 평균 내면 모호함이 드러납니다.
분해. 복잡한 작업이 한꺼번에 모든 곳에서 실패하는 경우는 드뭅니다. 로봇 공학 작업은 인지, 계획, 동작 실행으로 나뉠 수 있습니다. 소프트웨어 공학 작업은 알고리즘 설계, 구현, 테스트 커버리지로 분리될 수 있습니다. 확률적 점수 산정은 검증자가 각 하위 구성 요소를 개별적으로 평가할 수 있게 해줍니다. 답변이 부족하다는 사실뿐만 아니라, 어느 부분이 부족한지까지 알 수 있습니다. 이러한 진단적 정밀도는 수정 작업을 더 빠르고 정밀하게 만들어 줍니다.
어려운 도메인에서의 결과
이 프레임워크의 유용성은 드러납니다