13.4.4 교차 필드 유효성 검사(Cross-Field Validation): 통화(Currency) 코드와 국가 코드의 일치 여부

13.4.4 교차 필드 유효성 검사(Cross-Field Validation): 통화(Currency) 코드와 국가 코드의 일치 여부

비정형 문서의 전체 데이터 추출 과정에서, 개별 필드(Key-Value 쌍) 하나하나를 완전히 독립적으로 단독 검사했을 때는 모두 구문상 정상이고 완벽한 데이터로 보였으나, 서로 연관된 두 개 이상의 필드들을 묶어서 논리적으로 교차 비교해 보았을 때 심각한 모순(Contradiction)이 발견되는 경우가 존재한다.
이렇게 LLM이 문서 레이아웃의 거시적 맥락을 잃어버리고 파편화된 시야에 갇혀 발생하는 고차원적인 어텐션 붕괴(Attention Collapse)를 잡아내는 통제망이 바로 **‘교차 필드 유효성 검사(Cross-Field Validation)’**다.

가장 대표적이고 치명적인 글로벌 B2B 트랜잭션의 환각 사례가 바로 **‘벤더사의 주요 활동 지리적 국가(Country)’**와 ‘청구 금액의 거래 통화 단위(Currency)’ 간의 맥락적 불일치다.
예를 들어 일본 도쿄에 소재한 로컬 식당의 영수증을 처리할 때, 문서의 언어는 전형적인 일본어이고 식당의 물리적 주소 역시 도쿄(Tokyo)로 오차 없이 완벽하게 추출(vendor_country="JP") 했음에도 불구하고, 금액 숫자에 붙어있는 엔결제 지류 기호(¥)를 Vision LLM이 달러($, USD) 로 대충 뭉뚱그려 해석하거나, 혹은 똑같이 생긴 중국 위안화(¥, CNY)로 혼동하여 USD나 CNY로 추출해 버리는 환각은 글로벌 파이프라인에서 고질적이고 반복적으로 발생하는 문제다.

만약 이 환각이 교차 필드 오라클을 통과해 버리면, 실제로는 1,000엔(약 1만 원) 짜리 점심 식삿값이 시스템 장부에는 1,000달러(약 130만 원)로 결제 승인되는 치명적인 재무적 횡령 버그가 발생한다.
따라서 2단계 오라클은 이런 재앙을 막기 위해, 이 두 개의 독립된 변수 필드를 런타임에 하나로 묶어, ’지리적 맥락’과 ’경제적 기호’가 논리적으로 서로 공존 가능한 텐서인지 교차 검증을 반드시 수행해야만 한다.

1. 지리-경제적 다대다(N:M) 맵핑 검증 룰 구현

이 입체적인 교차 필드 검증을 수행하기 위해서는 오라클 시스템 컴파일러 내부에 현실 세계의 룰(World Rule)을 수학적으로 하드코딩해 넣은 일종의 **‘매핑 사전(Mapping Dictionary)’**이 필요하다. 우리는 이를 통해 추출된 국가 코드가 허용하는 닫힌 교집합(Closed Set) 안에, LLM이 추출한 통화 코드가 무사히 존재하는지 포함 관계 연산을 수행한다.

from pydantic import BaseModel, model_validator

# 오라클 내부에 하드코딩으로 이식된 시스템 상식 (지리적-금융 맥락 맵핑 규칙)
# 글로벌 무역의 특성을 반영하여 하나의 국가가 여러 통화를 수용할 수 있는 다대다 룰 세팅
VALID_COUNTRY_CURRENCY_MAP = {
    "US": {"USD"},                   # 미국 로컬은 무조건 USD
    "KR": {"KRW", "USD"},            # 한국 B2B 수출입 벤더의 경우 USD 외화 청구를 합법적으로 허용함
    "JP": {"JPY", "USD"},            # 일본 기업
    "CN": {"CNY", "USD"},            # 중국 기업
    "EU": {"EUR"},
    "UK": {"GBP", "EUR", "USD"}      # 영국은 지리적 특성상 3개 기축 통화 수용
}

class CrossFieldIntegrityOracle(BaseModel):
    vendor_country: str # 앞선 정규식/Enum 관문을 통과한 국가 코드 
    currency: str       # 앞선 Enum 관문을 통과한 통화 코드
    
    @model_validator(mode='after')
    def verify_currency_geographic_context(self):
        """ 벤더 국가와 추출된 환종(Currency) 기호가 서로 경제적 맥락에 부합하는지 교차 검증한다. """
        
        # 1. 시스템에 등록된 관리 가능한 국가인지 타겟 확인
        allowed_currencies = VALID_COUNTRY_CURRENCY_MAP.get(self.vendor_country)
        
        if not allowed_currencies:
            # 글로벌 매핑 사전에 없는 미지원 국가일 경우(예: 아프리카 신흥국), 안전을 위해 수동 심사(HITL)로 넘김
            raise ValueError(f"[시스템 예외] 현재 관리망이 지원하지 않는 국가 코드(Unknown Country): {self.vendor_country}")
            
        # 2. 교차 유효성(Cross-Field) 본 검사: 이 벤더 국가가 이 통화를 쓰는 것이 논리적인가?
        if self.currency not in allowed_currencies:
            # 집합 기호 연산 실패 시, 지리적 정보와 경제 기호 스캔 정보 충돌로 인한 환각 선언
            raise ValueError(
                f"[교차 맥락 붕괴 검출] 벤더 국가({self.vendor_country})의 회계 맥락 내에서 "
                f"절대 사용될 수 없는 통화 코드({self.currency})가 무단 추출되었습니다. "
                f"(기호 인식 환각, 예: ￥기호를 앞뒤 문맥 없이 CNY로 착각한 경우). 요격합니다."
            )
            
        return self

2. 모순(Contradiction) 요격 엔진의 가치와 통찰

이 교차 필드 검증 로직이 런타임에 실패하여 ValueError가 터졌다는 것은, 이 JSON 페이로드 내부에 존재하는 두 개의 필드 중 최소 단 하나는 무조건 시스템을 망가뜨리는 거짓(False) 토큰이라는 완벽한 수학적 증명(Proof)을 의미한다.
즉, LLM이 기업의 주소를 잘못 읽어서 다른 나라 벤더로 인식했든지(사실 중국의 영수증이었음), 아니면 영수증은 일본이 맞는데 화폐 기호를 잘못 보아서 JPY를 CNY나 USD로 멍청하게 파싱한 것이다.

어느 쪽의 확률이 맞든 해당 데이터 트랜잭션의 텐서는 이미 치명적으로 오염되었다.
2단계 오라클은 이처럼 완전히 관련 없어 보이게 파편화된 두 개의 자연어 지식을 강제로 충돌(Collision) 시키고 교집합을 구함으로써, 단순한 1차원적 구문 트리(Syntax Tree) 검증을 뛰어넘는다. 비정형 문서가 내포하고 있는 거대한 **‘지리적, 거시 경제적 시맨틱(Macro-Economic Semantic)’**을 한 치 오차 없는 코드의 연산으로 엄격하게 수호하는 진정한 문지기(Gatekeeper)의 역할을 완벽하게 달성해 냈다.