5.6.4. 사실 관계 확인(Fact-checking)을 위한 하드코딩된 지식 베이스(Knowledge Base) 대조 오라클
당신이 아무리 거대하고 훌륭한 파라미터를 지닌 언어 모델(LLM)을 사용하더라도, 그리고 그 모델이 아무리 컨텍스트 윈도우 내의 텍스트를 능수능란하고 우아하게 문법적으로 다루더라도, 본질적으로 LLM은 확률적인 단어 연결기(Next-token Predictor)에 불과하다는 뼈아픈 엔지니어링 현실을 잊어서는 안 된다.
따라서 사용자가 *“우리 회사의 엔터프라이즈 환불 규정 3조항의 페널티 요율은 무엇입니까?”*라고 집요하게 물었을 때, 모델이 프롬프트(Prompt)에 명확히 제공된 사내 원본 RAG 문서를 교묘하게 무시해 버리고, 모델 자신의 사전 학습 데이터(Pre-trained Data) 가중치 속에 깊게 남아있던 완전히 다른 회사의 환불 규정 텍스트를 맥락상 가장 ’그럴싸한 퍼즐 조각’으로 선택하여 멋대로 가져다 붙이는 이른바 ‘사실적 환각(Factual Hallucination)’ 사태가 프로덕션 현장에서 빈번하게 발생한다.
결정론적 검증 오라클(Deterministic Oracle)은 모델이 뱉어내는 화려하고 유창한 문법이나 완벽한 JSON 포맷의 구조적 정합성에 절대 만족하거나 속아 넘어가서는 안 된다. 특히 치명적인 법적 / 재무적 책임이 따르는 기업 로직 파이프라인에서는 시스템이 도출해 낸 특정 업무 엔티티(Entity, 예: 사람의 고유 명사, 제품 가격표, 사내 부서 이름, 정책 번호)가 **‘통제된 진실(Ground Truth)’**에 정확히 부합하는지 중간 과정에서 날카롭게 대조하는 정밀한 팩트 체크(Fact-checking) 오라클 메커니즘이 필수적이다.
1. 하드코딩된 골든 딕셔너리(Golden Dictionary) 구축 철학
자동화 오라클이 스크립트 내부에서 사실 관계를 0.1초 만에 검증해 내려면, 비교의 대상이 되는 ’절대적인 진리의 국소적 레퍼런스(Local Reference of Truth)’가 CI/CD 런타임 코드 메모리 안에 즉시 접근 가능한 상태로 존재해야 한다.
매번 회귀 테스트(Regression Test) 환경을 돌릴 때마다 무겁고 느린 프로덕션 데이터베이스 클러스터 전체를 띄우거나 외부 API 네트워크를 타는 것은 시스템 아키텍처상 극도로 비효율적이다. 따라서 핵심 도메인 지식만을 추려낸 아주 가벼운 파이썬 딕셔너리(Dictionary) 해시맵이나, 읽기 전용 정적 JSON / YAML 파일을 메모리 상에 올려 유닛 테스트(Unit Test) 내부에 하드코딩된 지식 베이스(Hardcoded Knowledge Base) 상수로 선언해 두는 방식을 취한다.
# 단위 테스트 환경의 오라클이 '절대적인 진리'로 삼는 메모리 상의 하드코딩된 지식 베이스
GOLDEN_KNOWLEDGE_BASE = {
"product_codes": {
"A100": {"name": "엔터프라이즈 스마트폰", "price": 1200, "is_active": True},
"B200": {"name": "개발자용 노트북", "price": 3500, "is_active": False}
},
"departments": ["인사팀", "재무팀", "코어 엔지니어링팀", "보안 감사팀"],
"max_discount_rate": 0.20, # 20%를 초과하는 할인은 시스템상 절대 불가능
"ceo_name": "John Doe"
}
2. 중간 추론 단계(Intermediate Steps)의 추출과 팩트 체크 교차 검증
오라클의 검증은 LLM이 내뱉는 최종 사용자 답변(Final Answer) 텍스트의 끝자락에서만 이루어져서는 안 된다. AI 에이전트가 함수 호출(Function Calling)을 계획하거나 체인 오브 소트(CoT, Chain-of-Thought) 논리를 전개하는 치열한 중간 과정 중, 모델이 특정 제품 코드 식별자나 부서 이름, 조건부 수치를 ’추출’하거나 DB 파라미터로 ’매핑’하는 결정적 순간이 등장한다.
이때 오라클은 파이프라인의 멱살을 잡고 해당 중간 변수(Intermediate Variable)의 텐서를 가로채어, 앞서 시스템 메모리에 상주시켜 둔 절대 진영인 GOLDEN_KNOWLEDGE_BASE 안에 이 값이 합법적으로 존재하는지(파이썬의 in 연산자 등 해시 검색 활용)를 극도로 엄격하게 교차 검증(Cross Validation)해야 한다.
def test_fact_checking_oracle_on_intermediate_reasoning(llm_intermediate_steps):
"""
LLM의 추론 사슬 단계에서 도출된 엔티티가 '사실'인지 검증하는 오라클 함수
"""
# 1. LLM이 스스로 파악했다고 주장하는 도메인 엔티티 캡처
extracted_product_code = llm_intermediate_steps.get("found_product_code")
extracted_department = llm_intermediate_steps.get("assigned_department")
suggested_discount = llm_intermediate_steps.get("calculated_discount")
# 2. 사실 관계 검증: LLM이 그럴싸하게 지어낸 가짜 코드가 아닌지 골든 딕셔너리와 대조
assert extracted_product_code in GOLDEN_KNOWLEDGE_BASE["product_codes"], \
f"[Fact-Check Fail] 치명적 환각 감지: 사내 DB에 존재하지 않는 허구의 제품 코드 '{extracted_product_code}'를 모델이 지어내어 매핑했습니다."
assert extracted_department in GOLDEN_KNOWLEDGE_BASE["departments"], \
f"[Fact-Check Fail] 환각 감지: 회사 조직도에 없는 공식 부서가 아닌 '{extracted_department}' 유령 부서로 업무 할당을 시도했습니다."
assert suggested_discount <= GOLDEN_KNOWLEDGE_BASE["max_discount_rate"], \
f"[Fact-Check Fail] 정책 위반: AI가 제안한 할인율({suggested_discount})이 정책상 최대 허용 한도(20%)를 초과했습니다. 재무적 손실 방어 루틴 가동."
3. RAG(Retrieval-Augmented Generation) 시스템과의 ‘Exact Match’ 연계 검증
이 무식하지만 가장 확실한 하드코딩 기반 팩트 체킹 기법은 사내 문서 검색 기반의 RAG 파이프라인 오라클을 구축할 때 그 방어 위력이 가장 파괴적으로 극대화된다. RAG의 아키텍처 중간 과정에서는 Vector DB에서 지름길로 문서 벡터를 검색(Retrieval)해 오고, 그 문서의 번역본이나 청크(Chunk)를 프롬프트의 텍스트 컨텍스트 공간에 한가득 주입한다.
이때 RAG 전용 오라클은 LLM의 최종 스트리밍 응답이나 중간 답변 과정에서 인용(Citation) 문구로 언급된 사내 문서의 고유 ID 스트링, 혹은 응답의 핵심 인용구(Quotation Block)를 정규식으로 캡처한다. 그리고 그 발췌된 텍스트가 “방금 전 파이프라인을 통해 Vector DB가 정확히 모델에게 반환해 주었던 실제 컨텍스트 원본 텍스트 블록 배열” 속에 단 1바이트의 오차도 없이 100% 동일한 문자열 사본으로 포함되어 존재하는지(Exact Match / Substring Check) 가혹하게 기계적으로 검사한다.
만약 모델이 마치 검색된 팩트를 가져온 것처럼 화려하게 출력한 정보 텍스트가, 데이터베이스가 제공한 원본 컨텍스트 문자열 창고 텍스트와 단 한 글자의 명사라도 다르게 변형되어 있다면(조사나 띄어쓰기 변경 제외), 오라클은 이 상황을 즉시 **“모델이 검색된 진실된 지식을 바탕으로 요약하여 대답한 것이 아니라, 그 기저에 깔린 자의적인 가중치 지식으로 소설을 ’창작(Fabrication)’하고 거짓말을 섞은 것”**으로 간주하고 처단한다. 이를 런타임에 즉각 적발하여 붉은색 경고 플래그를 띄우고 답변 출력을 강제 소거해 버리는 것이, 팩트 체킹 전담 오라클의 가장 위대하고도 궁극적인 방어 임무다.
모델의 그 화려하고 유창한 화술 뒤에 교묘하게 독버섯처럼 숨겨진 ’그럴싸한 거짓말(Plausible Lies)’의 치명도를 원천적으로 차단해 내는 소프트웨어 공학의 유일한 해법은, 아무리 똑똑해 보여도 결국엔 신용할 수 없는 확률적 단어 조합기(LLM) 앞에, 인간 엔지니어가 피 땀 흘려 가장 무식하고 결정론적으로 타이핑해 놓은 **하드코딩된 ‘진리의 사전(Dictionary of Truth)’**을 절대 속일 수 없는 깐깐한 수문장처럼 무겁게 세워두는 것뿐이다.