2.6.2. LLM 전용 지표(Perplexity, Truthfulness 등)와 비즈니스 요구사항의 괴리

2.6.1절에서 전통적인 N-gram 기반 지표(BLEU, ROUGE)의 처참한 실패를 목격한 AI 연구계는, 거대 언어 모델(LLM)의 특성에 돌맞춤된 새로운 세대의 평가 지표들을 쏟아내기 시작했다. 당혹도(Perplexity), 그리고 벤치마크 데이터셋 기반의 Truthfulness(진실성), Helpfulness(유용성) 지표들이 그 대표적인 예시다.

그러나 이러한 최신 LLM 전용 지표들조차도 데이터 과학자의 연구실과 실제 사용자가 마주하는 비즈니스 프로덕션(Production) 환경 사이의 좁힐 수 없는 근본적인 괴리(Gap)를 지니고 있다. 본 절에서는 이 지표들이 왜 오라클의 자리를 대체할 수 없는지를 비즈니스 로직과 시스템 아키텍처 관점에서 해부한다.

1. 당혹도(Perplexity, PPL): 유창한 거짓말의 함정

언어 모델 평가에 가장 근원적으로 사용되는 지표는 당혹도(Perplexity)다. 이는 모델이 다음 토큰(단어)을 예측할 때 얼마나 헷갈려(Perplexed) 하는지를 나타내는 수치 계산으로, 낮을수록 모델이 해당 문장 구조에 대해 확신을 가지고 자연스럽게 생성하고 있음을 의미한다.

• 수학적 의미: 언어 모델 파이프라인의 엔트로피(Entropy)를 지수화한 값이다.
• 오라클 적용의 치명적 문제: Perplexity는 문장의 ’형식적 유창성(Fluency)’을 평가할 뿐, ’사실적 정합성(Factuality)’이나 ’비즈니스 제약’과는 전혀 무관하다.

만약 모델이 “대한민국의 수도는 도쿄다“라는 환각(Hallucination) 문장을 생성할 때, 해당 문법과 토큰 배열이 학습 데이터의 어떤 왜곡된 패턴에 의해 지극히 자연스럽다고 판단한다면(Overconfident), Perplexity 모델은 이 문장에 아주 훌륭한(매우 낮은) PPL 점수를 부여한다.
비즈니스 파이프라인에서 “PPL이 낮으므로 안전하다“고 믿고 통과시키는(Pass) 것은, 사기꾼의 말투가 유창하다는 이유 하나만으로 은행 대출을 승인해 버리는 것과 같은 최악의 위양성(False Positive) 재앙을 초래한다.

2. 벤치마크 기반 지표(Truthfulness)와 프라이빗 도메인의 절벽

TruthfulQA, HellaSwag, MMLU 등과 같은 지표들은 모델의 상식 추론 능력과 진실성을 검증하기 위해 고안되었다. 이들은 모델 릴리스 보도자료(Press Release)에서 화려한 지표 성능을 입증하는 데 필수적인 무기다.

하지만 기업의 비즈니스 앱을 테스트하는 시스템 엔지니어에게 이 지표들은 아무런 의미가 없다.

• 정적이고 보편적인 지식의 한계: TruthfulQA는 “달 착륙 음모론“이나 “백신 괴담“과 같은 범용적(General)이고 퍼블릭(Public)한 인터넷 상식만을 검증한다.
• 비즈니스 동적 지식과의 충돌: 실제 제품의 오라클이 검증해야 할 대상은 범용 상식이 아니다. “우리 회사의 A 고객이 어제 가입한 보험 상품의 특약 계산이 올바른가?“라는, 모델의 사전 훈련(Pre-training) 데이터에는 전혀 존재하지 않는 프라이빗(Private)하고 동적인 비즈니스 로직이다. 모델이 MMLU에서 90점을 맞았다고 해서, 어제 개정된 사내 환불 규정을 오늘 정확히 파싱(Parsing)해 낼 것이라는 보장은 통계적으로 완벽한 0\%다.

3. 통계적 지표와 비즈니스 요구사항(Business Requirements)의 근본적 불일치

비즈니스 소프트웨어 개발은 정확하게 정의된 요구사항(Requirements)과 기능 명세(Specification)의 연속이다. 이를 코드로 번역하여 검증하는 것이 테스트 오라클이다.

• 비즈니스 요구사항: “비밀번호는 반드시 특수문자를 포함해야 하며, 오류 메시지는 JSON 배열 안에 담아 응답할 것.”
• LLM 지표의 대답: “이 텍스트의 당혹도(PPL)는 8.5이며, 유용성(Helpfulness) 스코어는 상위 5\%입니다.”

위의 예시에서 볼 수 있듯, 지표와 로직은 서로 대화조차 성립하지 않는다. 지표는 연속적인 분포(Distribution)와 확률(Probability)에 대해 이야기하는 반면, 비즈니스 오라클은 시스템의 생사(Pass/Fail)를 가르는 불변식(Invariant)을 요구하기 때문이다.

4. 소결: 지표는 ’관찰’하고 오라클은 ’통제’한다

LLM 전용 평가 지표들은 모델 모니터링 대시보드(Dashboard)를 장식하거나 거시적인 기술 부채(Technical Debt)를 추적하는 데 있어서는 훌륭한 계기판(Instrument) 역할을 수행한다. 그러나 비즈니스 프로세스 파이프라인의 실행 제어권을 이들에게 넘겨주는 것은 불가능하다.

따라서 쏟아지는 새로운 LLM 지표 점수에 기만당하지 않으려면, 엔지니어는 **“지금 내가 측정하려는 것이 모델의 일반 지능(General Intelligence)인가, 아니면 이 기능(Feature)의 결함 여부인가?”**를 철저하게 분리해야 한다.

그렇다면, 피할 수 없는 현실적인 문제가 남는다. 만약 경영진이 “우리 AI의 품질을 숫자로 증명해달라“고 요구하며, 이 모호한 정량적 점수(Score)를 기반으로 배포 여부를 결정하라고 압박한다면 시스템 아키텍트는 어떻게 이 연속된 점수를 이분법의 틈새인 오라클로 비틀어 우겨넣어 변환(Tuning) 시켜야 하는가? 이어지는 2.6.3절에서는 이 위험천만한 ’임계치(Threshold) 치환 작업’의 민낯을 분석한다.