13.2.3 주요 추출 필드: 공급자 정보, 품목 명세, 금액, 날짜, 세금 정보

앞선 13.2.2절에서 Pydantic 스키마의 차갑고 융통성 없는 철제 거푸집(Container)을 완성했다면, 이제 추출 파이프라인의 에이전트가 그 더럽고 노이즈 낀 텍스트의 바다에서 낚시질하여 이 거푸집 안으로 부어 넣어야 할 핵심 데이터 타겟, 즉 **‘주요 추출 필드(Core Extraction Fields)’**들의 속성과 그들이 지닌 본질적 취약성을 인프라 관점에서 정의할 차례다.

거대 언어 모델(LLM)은 단순히 화면의 텍스트를 복사해서 붙여넣기(Copy-Paste) 하는 무지성 복사기가 아니다. 각 추출 필드는 저마다 특유의 비즈니스 종속성과, 모델의 어텐션(Attention)을 교란시키는 치명적인 환각(Hallucination) 유발 포인트를 내부적으로 품고 있다. 파이프라인 설계자는 적의 위치를 알듯 이 함정들을 사전에 섬세하게 인지해야만, 13.3절 이후부터 전개될 가장 방어적이고 공격적인 유효성 검증 파이썬 룰(Rule)을 완벽하게 작성할 수 있다.

본 이종 재무 문서 시나리오에서 시스템이 반드시 추출하고 목숨 걸고 검증해 내야 할 핵심 필드 5가지는 다음과 같이 정의된다.

1. 공급자 정보 (Vendor Information)

회사(우리 쪽 시스템)에서 돈을 지불받는 청구의 주체(Entity)이자, 향후 ERP 지불원장(Accounts Payable) 데이터베이스에 조인(Join)될 물리적 기준점인 강력한 외래키성(Foreign Key) 레퍼런스정보다.

• 추출의 난제 (Hallucination Trigger): 영수증이나 청구서 최상단에 거대한 폰트와 화려한 로고로 쓰인 마케팅용 프랜차이즈 상호명(예: “스타벅스 강남 1호점”)과, 문서 최하단 구석에 쥐구멍만 한 폰트로 적힌 진짜 법적 회사 법인명(예: “(주)에스씨케이컴퍼니”)이 문서 위에서 서로 충돌한다. LLM은 압도적인 크기의 마케팅 상호명에 시선(Attention)을 빼앗겨 법적 주체를 놓칠 확률이 높다.
• 오라클 방어 포인트: 유효성 검사 모듈은 추출된 이 문자열이 무엇이든 간에, 이를 맹신하지 않고 13.5절에서 다룰 ’외부 지식 기반(Ground Truth Lookup) 데이터베이스 검색 오라클’의 쿼리로 태워 진짜 국세청에 등록된 유효한 사업자 벤더명인지 물리적 교차 대조 페이로드로 사용하게 된다.

2. 날짜 정보 (Date Constraints)

기록될 트랜잭션의 시간적 흐름을 특정하고, 악의적인 이중 청구(Double-billing)를 필터링하는 ERP 시스템의 거시적 타임스탬프(Timestamp)다.

• 추출의 난제: 송장 내부에는 문서 발행일(Invoice Date), 상품 배송일(Delivery Date), 결제 만료 기한(Due Date) 등 ’모양은 똑같은데 의미가 완전히 다른 여러 개의 시계열 날짜 데이터’가 파편처럼 흩어져 존재한다. LLM은 문맥을 오독하여 결제 만료 기한 필드에 과거의 배송일을 매핑하는 의미론적 바인딩 환각을 쉽게 일으킨다.
• 오라클 방어 포인트: 입력받는 즉시 오직 ISO-8601 네이티브 포맷(YYYY-MM-DD)으로의 시스템 강제 형 변환(Parse) 로직이 대수학적으로 발동된다. 9999년이라는 장난 같은 미래나, 02월 30일과 같은 허수 역학 날짜는 파이썬 datetime 모듈의 물리적 방어막에 부딪혀 즉각적인 파이프라인 붕괴(Exception)를 선언하게 된다.

3. 품목 명세 (Line Items & Description Array)

실제 트랜잭션이 왜 발생했는지 증명하는 개별 구매 내역의 물리적로우(Row) 데이터 배열이다.

• 추출의 난제: 영수증의 경우 감열지 인쇄 퀄리티 불량으로 물품명이 기형 외계어(“ㅋr푸ㅊ1노 1잔”)로 찌그러져 있거나, 인간만이 알아볼 수 있는 시스템 약어(“A4 Cpy Ppr 500Sht”)로 표기된다. 또한 OCR 스캐너는 다중 줄 바꿈 속성으로 인해 하나의 긴 품목 설명이 표의 두 줄에 걸쳐 이어질 때, 데이터의 행(Tuple) 자체를 중간에서 강제로 찢어버려 무의미한 유령 배열 아이템을 창조해 낸다.
• 오라클 방어 포인트: 스키마 계층에서 추출된 품목 리스트 제네릭(Array)의 크기(length())는 반드시 1 이상이어야 함을 하드코딩으로 강제한다. 물건을 하나도 사지 않은 텅 빈 껍데기([]) 결제 배열 객체는 시스템 우주에 생성될 수조차 단절시킨다.

4. 금액 및 세금 정보 (Financial Amount & Tax Data)

이 이종 문서 추출 파이프라인 전체가 피투성이가 되며 존재하는 궁극적이고 유일한 이유이자, 단 1센트(Cent)의 오차도 기업을 재무적으로 파멸하게 만들 수 있는 절대적인 심장(Core) 수치 연산 코어다.

• 추출의 난제: 원본 OCR 텍스트에는 국가별 통화 기호($, ₩, €)와 천 단위 구분자(쉼표 ,), 소수점(.) 단위가 폭력적으로 혼재되어 있어, 이 문자열을 파싱하는 시스템의 Float 캐스팅 에러를 일일이 유발한다. 또한 일부 영수증 벤더는 세금(Tax) 항목 자체를 표기하지 않거나, 친절한 총액(Total Amount) 필드 없이 세부 단가의 합만 불친절하게 적어두는 지독한 모호함을 시스템에 선물한다.
• 오라클 방어 포인트: 시스템으로 반환된 모든 숫자 텍스트는 화폐 기호와 콤마의 껍데기를 잔인하게 탈피하고 순수한 부동소수점 실수(Float)나 정수로 강제 캐스팅(Casting) 변환되어야만 파이프라인에 진입이 허락된다. 그 어떤 쓰레기 텍스트 수식어나 친절할 멘트라도 달려있다면 즉시 에러 요격 로직이 가동된다.

이 5가지의 핵심 필드들은 LLM에 의해 단순히 물리적 공간에서 문자를 뜯어내 시스템 메모리로 올려놓는 행위를 넘어선다. 데이터베이스의 입구 앞에서 이 토큰들은, **서로가 서로를 대수학 방정식으로 강하게 지탱하는 엄격한 수학적 논리 연산 구조망(Logical Mathematical Web)**으로 얽히고 합쳐지게 된다.
이 5개의 필드 숫자들이 결합하며 충돌하는 환각과 논리 붕괴의 에러 로그는, 곧장 다음 13.2.4절에 기술될 **‘비즈니스 제약 조건(Business Constraints) 재판소’**로 넘겨져 가장 차갑고 처절한 시스템의 심판을 마주하게 될 것이다.