8.9.3 금융(Finance) 도메인에서의 수치 정합성 및 약관 일치 여부 검증

은행, 증권사, 보험사와 같은 금융(Finance) 도메인은 숫자가 전부인 세계다. RAG 시스템이 “주택담보대출 금리는 연 3.5%입니다“라고 대답해야 할 것을 “연 3.0%“라고 잘못 대답하는 순간, 그 0.5%의 환각(Hallucination)은 즉각적인 금전적 손실 배상 청구와 금융감독원의 징계로 이어진다.

금융 RAG에서 텍스트의 유려함은 전혀 무가치하다. 타겟 LLM은 금융 약관과 이자율 표라는 거대한 스프레드시트를 읽어주는 ’숫자 파서(Number Parser)’로 철저히 전락해야 하며, 금융 오라클 시스템은 LLM이 텍스트를 생성하는 본능을 억제하고 **수치 정합성(Numerical Integrity)**과 **조건부 약관(Conditional Clause)**을 기계적으로 대조하는 데 데이터 파이프라인의 모든 자원을 쏟아부어야 한다.

1. 수치(Numeric) 토큰 스캐닝 및 Exact Match 오라클

일반 문서에서는 “대략 3천만 원“과 “30,000,000 원“이 같은 의미를 지니지만, 금융 시스템의 오라클은 이를 전혀 다르게 취급하며 철저한 ’토큰 동등성 검사(Token-level Equivalence Check)’를 요구한다.

1. 숫자 엔티티 강제 추출 (Numeric Entity Extraction): 타겟 모델이 답변을 렌더링하기 전, 오라클 파이프라인 전단(Frontend)에 위치한 정규 표현식(Regex) 기반 파서가 원본 문서(RAG Context) 내의 모든 아라비아 숫자, 백분율(%), 날짜, 통화 기호(₩, $)를 강제로 긁어내어 해시 테이블(Hash Table)에 저장한다.
2. 생성 텍스트의 토큰 대조: 타겟 LLM이 출력한 답변 텍스트에서도 동일한 방식으로 숫자 토큰들을 추출한다. 그리고 이 생성된 숫자 배열이 사전에 추출된 원본 문서의 숫자 해시 테이블 안에 100% 부분집합(Subset)으로 속하는지 기계적 교차 검증을 수행한다.
3. Fatal Mismatch 셧다운: 원본 문서에는 [3.5, 5000, 10]이라는 숫자만 있는데, LLM이 문맥을 매끄럽게 만든답시고 [3.0]이나 [3천5백] 같은 포맷 혹은 변조된 수치를 생성한 것이 적발되면 오라클은 즉시 텍스트 생성을 차단(Reject)한다. 자비 없는 숫자의 Exact Match야말로 금융 오라클의 가장 무거운 방패다.

2. 복합 조건문(If-Then-Else) 약관에 대한 논리표(Logic Table) 검증

금융 상품 약관은 일자형 텍스트 구조가 아니라, “만약 A이고 B라면 C이다” 형태의 방대한 **논리 트리(Logic Tree)**로 구성되어 있다. “무주택자이면서 연 소득 5천만 원 이하인 경우 0.2% 우대 금리 적용“과 같은 조항에서, LLM은 종종 ’무주택자’라는 조건 A를 빼먹고 ‘연 소득 5천만 원 이하’ 조건 B만으로 우대 금리가 보장된다고 대답하는 치명적인 논리 누락 에러(Logic Omission Error)를 발생시킨다.

이를 제어하기 위해 오라클은 단순 텍스트 비교를 넘어서, 약관 데이터를 결정 표(Decision Table) 구조로 이해하도록 프롬프트를 조향한다.

• 타겟 모델에게 답변 생성을 지시할 때, 단순 문자열 출력을 금지하고 약관의 논리 구조를 추적할 수 있는 [조건 1], [조건 2], [최종 결과] 형태의 JSON 포맷 렌더링을 강제한다.
• 오라클(Judge LLM)은 타겟 모델이 분해해 놓은 이 조건식 트리와 원본 문서의 조건을 비교하여, AND/OR 논리합이 단 하나라도 누락되었거나 변조되었는지를 검사하는 수학적 참/거짓(Boolean) 스캐너의 역할을 수행한다. 조건 누락 시 해당 트랜잭션은 즉시 파기된다.

3. 면책 및 고지 의무(Disclaimer & Disclosure) 자동 삽입 시스템

금융 상품 안내에는 법적으로 반드시 포함되어야 하는 고지 사항(예: “본 상품은 예금자보호법에 따라 보호되지 않습니다”, “투자 원금의 손실이 발생할 수 있습니다”)이 존재한다. LLM에게 이런 문구를 출력하라고 지시(Prompting)하는 것만으로는 충분하지 않다. LLM은 언제든 이 지시를 망각하거나 텍스트 길이를 이유로 잘라먹을 수 있기 때문이다.

금융 오라클 파이프라인에서는 어펜더(Appender) 아키텍처를 가동하여 결정론적으로 이 문제를 해결한다.

1. 타겟 LLM은 상품에 대한 설명만 생성하도록 역할을 극도로 제한한다.
2. 답변이 생성된 후 반환(Return)되기 직전 단계에서, 오라클 미들웨어는 타겟 LLM이 검색했던 문서의 메타데이터(예: Product_Type: 펀드)를 읽어 들인다.
3. 미들웨어가 해당 카테고리에 맵핑된 법적 고지문(Disclaimer)을 하드코딩된 데이터베이스에서 꺼내어, LLM의 텍스트 맨 마지막에 **물리적 문자열 결합(String Concatenation)**으로 덧붙여 버린다.

이러한 포스트 프로세싱(Post-processing)은 LLM의 확률적 변덕에서 완전히 자유로우며, 어떠한 경우에도 금융 규제가 명시하는 고지 의무를 100% 달성하게 해주는 무적의 컴플라이언스(Compliance) 방어막이 된다.

결국 금융 도메인에서의 RAG는 사실상 ’확률형 모델링’을 가죽으로 두른 ’결정론적 룰 엔진(Rule Engine)’으로 회귀한다. 문장은 부드러워야 하지만, 그 문장을 채우는 숫자와 조건식은 0과 1의 차가운 강철로 조립되어야만 시스템이 생존할 수 있다.