13.2.4 비즈니스 제약 조건: 금액 계산의 정확성, 날짜의 논리적 순서, 필수 필드 존재 여부

13.2.2절에서 선언한 Pydantic 스키마가 각 필드(Field)가 마이너스나 쓰레기 문자를 갖지 않도록 막아주는 1단계 ‘원자의 방어막(Atomic Wall)’ 이라면, 본 절에서 정의할 **‘비즈니스 제약 조건(Business Constraints)’**은 그 원자들이 결합하여 만들어낸 텍스트 분자(전체 페이로드)가 엔터프라이즈 거시 경제 논리에 위배되지 않는지를 심판하는 2단계 **‘관계 대수적 방어막(Relational Wall)’**이다.

거대 언어 모델(LLM)이 수량(int) 필드와 단가(float) 필드 각각을 예쁘고 정상적인 숫자 타입으로 뽑아내는 데 성공했다고 해서 박수를 쳐 줄 수는 없다. 만약 수량 10개와 단가 1,000원을 추출해 놓고, 환각 상태에 빠져 품목 합계를 50,000원이라고 기입했다면, 이는 타입 검사는 무사히 통과하지만 비즈니스 런타임에서는 치명적인 횡령(Embezzlement) 버그를 유발하는 결함 데이터이기 때문이다.

따라서 오라클 시스템은 반드시 페이로드를 데이터베이스 트랜잭션에 올리기 직전, 다음과 같은 세 가지 축의 대수학적 제약 조건 규칙(Rule Engine)을 발동하여 무자비한 심판을 내려야 한다.

1. 금액 계산의 절대적 정확성 (Financial Accuracy)

단 1원의 오차조차 허용되지 않는 재무 모듈의 핵심 방정식이다. 오라클은 문서에서 추출된 스칼라(Scalar) 값들을 메모리 위에서 직접 덧셈과 곱셈 연산을 수행하여 LLM의 대수학적 인지 결함을 색출해 낸다. 이 검증은 부동소수점 오차를 방지하기 위해 파이썬의 decimal.Decimal이나 반올림(Rounding) 로직을 적용하여 엄격하게 진행되어야 한다.

품목 단위 무결성 (Line Item Integrity): 어레이(Array) 내의 모든 n번째 품목에 대해, $Quantity_n \times UnitPrice_n = LineTotal_n$ 공식이 완벽하게 성립해야 한다. 이 수학 공식에 어스름한 환각이 묻어있다면 즉시 파이프라인을 타격한다.
거시 텐서 무결성 (Global Roll-up Integrity): 추출된 모든 품목 합계의 누적합 $\sum LineTotal_n$ 은 1계층의 $Subtotal$ (총 공급가액) 필드와 정확히 일치해야 한다. 나아가 $Subtotal + TaxAmount = TotalAmount$ (최종 청구액)의 방정식 역시 오라클의 통제망을 무사히 통과해야만 한다.

2. 날짜의 타임라인 및 논리적 순서 (Chronological Logic)

시간은 단방향으로 흐르며 절대 역전될 수 없다. 인보이스와 발주서 등에 흩어져 있는 날짜 필드들을 추출했을 때, 오라클 알고리즘은 타임스탬프(Timestamp) 간의 상대적 위상 크기를 비교 검증해야 한다.

시간 역전 환각 (Time-travel Hallucination) 차단: 계약서나 발주서에서 추출한 계약 시작일(Start Date)의 타임스탬프가 계약 종료일(End Date)보다 미래의 값으로 세팅되어 있다면, 이는 명백히 LLM이 문서 위상 좌표를 헛짚은 논리 붕괴(Semantic Crash)다. 이 경우 즉시 에러 익셉션을 던져야 한다.
미래 청구 차단: 원칙적으로 문서 발행 일자(Document Date)가 MLOps 백엔드 검증 서버의 현재 물리적 System Time보다 아득한 미래로 산출되었다면(예: 서기 3024년), OCR 혹은 치명적 환각 노이즈로 간주하고 롤백시켜야 한다.

3. 다형성에 따른 필수 필드(Required Fields) 존재 여부 검사

13.2.1절에서 우리는 문서가 총 4가지 종류(인보이스, 영수증, 발주서, 견적서)의 다형성(Polymorphism)을 띠고 시스템 문을 두드린다고 정의했다. 이 문서 타입별로 논리적으로 반드시 존재해야 할 ’필수 키(Key)’의 위상이 각각 다르므로, 맹목적인 not null 검사가 아닌 조건부 다형성 검증이 요구된다.

인보이스(INVOICE) 룰: 트랜잭션의 절대 식별자인 인보이스 번호(document_id)가 null 이거나 비어있으면 즉각 사형 선고를 내린다.
발주서(PURCHASE_ORDER) 룰: 청구 문서가 아니므로 세금(Tax) 필드를 굳이 환각으로 추론해서 채워 넣을 필요가 없다. 이 문서에서 Tax가 채워져 있다면 오라클은 의심(Suspicion) 핑을 띄운다. 반대로 발주 번호(PO Number)는 절대로 null이 될 수 없다.
영수증(RECEIPT) 룰: 길거리 감열지 특성상 공식 식별번호가 없는 경우가 많으므로 document_id가 null인 것을 시스템이 조건부 관용으로 허용(Allow)한다.

이 피도 눈물도 없는 ’관계 대수학 및 비즈니스 제약 엔진’이야말로, 단순히 토큰을 예쁘게 정규화시키는 것을 초월하여 인간의 회계 사관(Auditor)을 코드로 치환해 낸 이 장의 가장 위대한 검문 트랜잭션이라 할 수 있다.