3.2 왜 결정론적 정답지가 필수적인가? (Necessity)

소프트웨어 시스템에 거대 언어 모델(LLM)을 통합하는 순간, 엔지니어들은 기존에 경험하지 못했던 낯선 위기에 직면한다. 코드는 동일하고 인프라도 정상적이지만, 어제는 잘 작동하던 시스템이 오늘은 엉뚱한 응답을 뱉어낸다. 확률론적 엔진이 초래하는 이러한 비결정성(Nondeterminism)의 혼돈 속에서, ’결정론적 정답지(Deterministic Ground Truth)’의 구축은 단순한 품질 통제(Quality Control) 수단을 넘어 시스템의 생존을 담보하는 필수적인 컴포넌트로 기능한다.

1. 베이스라인(Baseline) 상실로 인한 파이프라인의 붕괴

전통적인 소프트웨어는 assert(2 + 2 == 4)와 같이 명확한 참고 거짓의 경계를 지닌다. 그러나 자연어 처리에서는 “환불 정책을 요약해줘“라는 입력에 대해 수만 가지의 유효한 문자열 배열이 존재할 수 있다.

정답지가 없다면 개발자는 눈으로 텍스트를 읽고 “대충 맞는 것 같다“라는 직관적이고 주관적인 평가를 내릴 수밖에 없다. 이러한 평가는 다음의 치명적인 공학적 실패를 초래한다.

• 회귀(Regression)의 인지 불가: 새로운 모델 가중치(Weights)를 배포하거나 시스템 프롬프트를 수정했을 때, 응답이 어제보다 나아졌는지 악화되었는지 수치화(Quantification)할 수 없다.
• CI/CD의 무력화: 승인과 배포(Deployment) 자동화를 지탱하는 핵심은 테스트 통과율(Pass Rate) 100%라는 결정론적 지표다. 주관성의 개입은 파이프라인의 멈춤을 초래하거나, 반대로 모든 버그를 통과시키는 ’눈먼 자동화’로 시스템을 전락시킨다.

2. 모호한 지시(Ambiguous Prompt)의 공학적 정제

어떤 프롬프트 엔지니어링 기술도 모호한 목적 위에서는 힘을 발휘하지 못한다. 개발자가 AI에게 내리는 프롬프트 지시문은 종종 추상적이고 추론의 범위가 열려(Open-ended) 있다.

• 결정론적 정답지를 작성하는 행위 자체는, 시스템 기획자가 AI에게 바라는 바를 데이터 타입, 길이, 포함해야 할 핵심 논리, 넘어서는 안 될 경계 값(Edge Case) 등의 공학적 명세서로 깎아내고 구체화하는 고도화 과정이다.
• “이 데이터가 정답지에 어떻게 기록될 수 있는가?“를 자문하는 과정에서, 평가가 불가능한 모호한 시스템 기획들은 조기에 기각되고, 검증 가능한 확정적 기능만이 파이프라인에 살아남게 된다.

3. 평가용 오라클(LLM-as-a-Judge)의 환각 통제

거대 언어 모델의 출력을 평가하기 위해 또 다른 언어 모델을 사용하는 ‘LLM-as-a-Judge’ 아키텍처는 최근 품질 보증(QA)의 대세가 되었다. 그러나 평가하는 모델 역시 환각(Hallucination)의 지배를 받는 동일한 확률적 엔진일 뿐이다.

• 평가 모델에게 “이 요약이 원본을 잘 반영하고 있는가?“라고 묻는 것만으로는 충분하지 않다. 평가 모델 자신이 자의적 기준으로 점수를 부풀리기 때문이다.
• 평가 모델의 환각을 통제하는 유일한 족쇄는, 평가용 프롬프트와 함께 **“반드시 포함되어야 할 3가지 사실(Ground Truth)”**을 하드코딩된 변수로 주입하는 것이다. 정답지는 모호한 ’평가’를 명확한 ’채점’으로 격상시켜, LLM-as-a-Judge가 인간 검수자에 필적하는 신뢰도를 확보하게 하는 핵심 동력이 된다.

결과적으로 결정론적 정답지가 필수적인 이유는 단순명료하다. 확률의 바다에서 항해하는 AI 시스템이 의도한 항로를 이탈하지 않았음을 수학적으로 증명할 수 있는 유일한 ’절대 좌표’가 바로 정답지이기 때문이다.