2.5.1. AI 오라클의 새로운 요구사항: 유창성(Fluency), 사실성(Factuality), 일관성(Consistency)

전통적인 소프트웨어 테스트의 오라클(Oracle)이 관장하던 영역은 “이 연산은 명세서(Specification)와 일치하는가?“라는 단일 차원의 검증이었다. 그러나 능동적으로 언어를 창조하는 거대 언어 모델(LLM)이 비즈니스의 프론트엔드 자리를 차지하면서, 단일한 기능 검증만으로는 시스템의 품질을 보증할 수 없게 되었다.

아무리 연산(로직)이 정확하더라도 시스템이 어색한 외계어를 늘어놓거나(유창성 결여), 사실을 그럴싸하게 위조하거나(사실성 결여), 어제와 오늘 다른 대답을 한다면(일관성 결여) 그 소프트웨어는 무용지물이기 때문이다.

결과적으로, AI 시대를 통제하기 위한 새로운 오라클 아키텍처는 과거의 1차원적 ‘정확성(Accuracy)’ 잣대를 버리고, 다음 세 가지의 독립적이고 핵심적인 차원(Dimension)을 동시에 관측하는 3차원 복합 검증기로 재설계되어야 한다. 본 절에서는 이 새로운 3대 필수 요구사항인 **유창성(Fluency), 사실성(Factuality), 일관성(Consistency)**의 정의와 기술적 한계를 분석한다.

1. 유창성(Fluency): 문법적, 구조적 무결성의 검증

유창성은 AI가 생성한 텍스트가 해당 도메인의 언어적 규칙, 문법, 그리고 출력 포맷을 얼마나 자연스럽게 준수하는가를 평가하는 지표다. 이는 가장 표면적인 계층의 요구사항이며, 모델의 ‘말하기 능력’ 그 자체를 검증한다.

자연어 유창성: 문법적 오류(Grammatical Error)가 없고, 맥락이 부드럽게 이어지는가? “결제 완료되었습니다“를 “결제 하셨다. 완료됨“처럼 기계 번역투로 출력하지 않는가?
구조적 유창성: 시스템 프롬프트에서 요구한 데이터의 규격을 완벽하게 따르는가? 예를 들어, JSON 형식의 반환을 요구했을 때 쉼표나 괄호가 누락되지 않은 완벽한 문법의 코드를 생성하는가?

과거에는 이러한 자연어 파싱조차 오라클에게 버거운 짐이었으나, 최근 LLM들의 구문 생성 능력이 기하급수적으로 상향 평준화됨에 따라 유창성은 오라클이 통과시켜야 할 가장 기초적인 ’위생 요인(Hygiene Factor)’으로 자리 잡았다.

2. 사실성(Factuality): 환각(Hallucination)에 맞서는 진실의 방벽

유창성이 ’어떻게 말하는가’의 문제라면, 사실성은 ’무엇을 말하는가’의 문제, 즉 생성된 데이터가 물리적 진실(Ground Truth)과 얼마나 일치하는가를 엄격히 검열하는 가장 중요한 요구사항이다.

LLM은 유창하게 말하는 데 특화되어 있을 뿐, 자신이 뱉어내는 말의 진위를 판별하는 내재적 로직이 존재하지 않는다(2.4.3절 환각 현상 참조). 따라서 오라클은 모델의 매끄러운 화법에 속지 않고 팩트(Fact)의 뼈대만을 발라내어 외부의 진실과 대조해야 하는 무거운 책임을 진다.

내재적 진실(Intrinsic Factuality): 모델이 훈련 과정에서 학습한 상식과 사실을 왜곡하지 않고 인출해내는가?
맥락적 진실(Contextual Factuality / 충실도 Fidelity): 검색 증강 생성(RAG) 환경에서, 모델이 주어진 참조 문서(Reference Document)에 적힌 내용만을 브리핑하고 쓸데없는 외부 지식을 억지로 덧붙이거나 누락하지 않았는가?

사실성 오라클을 구축하는 것은 지식 베이스(Knowledge Base)와 연동해야 하므로 매우 높은 연산 비용(Oracle Cost)을 요구하지만, 의료나 금융과 같은 규제 산업(Regulated Industry)에서는 절대 타협할 수 없는 무결성의 제1원칙이기도 하다.

3. 일관성(Consistency): 비결정성 세계에서의 신뢰성 탈환

가장 달성하기 어려우며 오라클 설계자들을 좌절시키는 마지막 계층이 바로 일관성이다.
일관성이란 **“동일한 시간, 동일한 맥락, (유사한) 프롬프트가 주어졌을 때 모델이 언제나 논리적으로 모순되지 않는 결과를 도출하는가”**를 묻는 신뢰성(Reliability)의 척도다.

시계열 일관성 (Temporal Consistency): 프롬프트 $A$ 를 오늘 100번 호출했을 때와 다음 주에 100번 호출했을 때 답변의 기조가 흔들리지 않는가?
맥락 내 일관성 (Intra-Context Consistency): 대화형(Chat) 세션 안에서, 모델이 첫 번째 프롬프트에서는 “A 제품은 무료입니다“라고 답변해 놓고, 세 번째 프롬프트에서 갑자기 “A 제품은 유료입니다“라고 자신의 발언을 스스로 부정하는 자기 모순(Self-Contradiction)을 범하지 않는가?
변형 프롬프트 일관성 (Perturbation Consistency): “장점 3가지를 정리해 줘“와 “3가지 장점을 요약해 줘” 등 의미상 동일한 변용 공격(Adversarial perturbation)에도 논리적 뼈대를 일관되게 유지하는가?

graph TD
    subgraph Classical Oracle
        I1(System Input) --> Logic(Business Logic)
        Logic --> Result[Status: Success/Fail]
        Result --> Check1(Oracle: Accuracy == 100%)
    end

    subgraph The Triad of AI Oracles
        P1(Prompt / Context) --> LLM(LLM Engine)
        LLM --> Gen[Generated Text]
        
        Gen --> Fluency{"1. Fluency \n (Is it readable/parsable?)"}
        Fluency -.-> |Syntax Parsing| Gram[Grammar / JSON Schema]
        
        Gen --> Fact{"2. Factuality \n (Is it objectively true?)"}
        Fact -.-> |Fact-checking| DB[(RAG / Knowledge Graph)]
        
        Gen --> Con{"3. Consistency \n (Is it logically stable?)"}
        Con -.-> |Self-Reflection| His[Dialogue History / Perturbation]
    end
    
    style Check1 fill:#ccc,stroke:#666,stroke-width:2px;
    style Fluency fill:#d4e157,stroke:#9e9d24,stroke-width:2px;
    style Fact fill:#64b5f6,stroke:#1e88e5,stroke-width:2px;
    style Con fill:#ef5350,stroke:#e53935,stroke-width:2px;

4. 소결: 세 요소 간의 비극적 트레이드오프(Trade-off)

이 3가지 요구사항(유창성, 사실성, 일관성)은 이상적인 AI 시스템의 완벽한 삼위일체(Trinity)처럼 보이지만, 실제 공학 환경에서는 심각한 **트레이드오프(Trade-off)**를 발생시킨다.

사실성을 강박적으로 준수하도록 오라클의 설정 온도(Temperature)를 한없이 낮추면, 시스템의 대답은 딱딱하고 기계적으로 변하여 유창성을 잃어버린다. 반대로 인간처럼 말하는 유창성과 맥락 수용성을 극대화하면, 반드시 모델의 사실성 통제력이 무너져 환각을 뿜어낸다.

따라서 현대의 QA 파이프라인에서 오라클의 역할은 단순히 ’검증을 수행하는 채점관’을 넘어, 이 파괴적인 세 변수 사이에서 **’비즈니스가 수용 가능한 타협점(Acceptance Threshold)이 무엇인지’를 정량적으로 설정하고 통제하는 균형자(Balancer)**의 역할을 수행해야 한다.

이어지는 **2.5.2절(확률적 결과에 대한 결정론적 검증 경계 설정 전략)**에서는 이 철학적이고 추상적인 3대 요구사항을, 공학자가 CI/CD 파이프라인 속에서 어떻게 실수(Real Number) 단위의 임계치(Threshold)로 쪼개어 자동화할 수 있는지 그 수리적인 제어 전략을 파헤칠 것이다.