13.2.1 입력 데이터 정의: 인보이스, 영수증, 발주서(PO), 견적서의 혼합 처리

엔터프라이즈급 AI 파이프라인을 구축할 때 가장 먼저 선행되어야 할 작업은, 백엔드 서버의 인그레스 입구(Input Gateway)로 사정없이 쏟아져 들어오는 무질서한 데이터 스트림(Data Stream) 페이로드의 정체와 악의성을 정확히 규명하고 명세(Specification)하는 것이다.
혹독한 실무 엔터프라이즈 환경에서, 데이터 파이프라인은 큐(Queue)를 통해 밀려드는 텍스트 덤프를 보며 *“지금 처리할 문서가 친절하게 분류된 1번 템플릿 인보이스다”*라는 사전 힌트 메타데이터를 결코 제공받지 못한다. 페이로드는 철저한 블랙박스(Black-box)다.

따라서 우리의 LLM 파싱(Parsing) 에이전트 모듈은 단 하나의 공통된 인퍼런스(Inference) 라우팅을 통해, 아래와 같이 텍스트의 발생 원리와 물리적 형태가 극단적으로 이질적인(Heterogeneous) 네 가지 재무 문서들을 동시에 닥치는 대로 스캔하고, 스스로 문서의 위상을 분류(Classification)하며 역분해해 내야만 한다.

1. 인보이스 (Invoice / 정식 세금 계산서)

겉보기에는 규칙적으로 선이 그어져 가장 정형화되어 보이지만, 수천 개의 벤더(Vendor)마다 표를 그리는 템플릿 좌표 레이아웃이 천차만별인 매우 기만적인 문서 매체다.

• 구조적 특징: 다수의 구매 품목(Line Items)이 무한대의 중첩된 표(Table) 형태로 본문을 차지하며, 표 외곽의 예측 불가능한 위치(우측 상단, 혹은 좌측 하단 등)에는 총청구금액(Total Amount), 세액(Tax), 공급가액(Subtotal), 결제 만료일(Due Date) 등 거시적 메타데이터가 파편화되어 흩뿌려져 있다.
• LLM 시스템의 난제: OCR 모듈이 2차원 공간을 가로로 무식하게 스캔할 때, 공백 셀(Empty Cell)의 좌표가 틀어지면서 품목 명칭과 그에 해당하는 금액 숫자가 한 줄 위아래로 어긋나버리는 끔찍한 위상 병합 현상.

2. 간이 영수증 (Receipt)

현장 물류 직원이나 출장 영업 사원이 식당이나 주유소에서 모바일 카메라로 무성의하게 찍어 ERP 모바일 앱으로 업로드하는, 아키텍처 관점에서 최악의 노이즈 컨테이너(Noise Container)다.

• 구조적 특징: 싸구려 감열지 특유의 폰트 뭉개짐 현상, 카메라의 흔들림으로 인한 끔찍한 저해상도, 배경에 찍힌 직원의 손가락 등 시각적 픽셀 노이즈가 폭발한다. 시스템이 타겟팅하는 데이터는 극도로 생략(omission) 또는 절삭되어 있으며, 때로는 돈을 지불 받은 공급자(가게 이름) 조차 로고 이미지로만 박혀 있어 텍스트 스크래핑 자체가 불가능한 경우도 허다하다.
• LLM 시스템의 난제: 노이즈 레벨이 극에 달해 OCR 단계에서부터 알파벳 대문자 ’O’와 숫자 ‘0’, 숫자 ’1’과 문자 ’l’이 완전한 붕괴를 일으킨다. 하단에 박힌 의미 없는 프로모션 홍보 문구(“포인트 적립하세요”)와 진짜 비즈니스 텍스트 찌꺼기를 필터링(Filtering) 없이 LLM에 넘길 경우 어텐션 낭비와 환각을 유발한다.

3. 발주서 (Purchase Order, PO)

물품을 받기 전 구매 부서에서 벤더에게 발송하는 선행 요청(Request) 문서로, 최종 결제 청구가 아닌 ’재화의 사전 명세와 계약’에 집중한다.

• 구조적 특징: 인보이스와 시각적 레이아웃이 너무나 흡사하지만, 기업 간 트랜잭션을 증명하는 절대적인 외래키(Foreign Key) 인덱스 속성인 **“PO Number(발주 번호)”**를 생명줄처럼 지닌다. 또한 확정된 금액 정보 없이, 단순 수량과 품목 번호(SKU 플래그)만 텍스트로 기재된 경우도 빈번하다.
• LLM 시스템의 난제: 텍스트의 분포 역학이 인보이스와 90% 이상 흡사하기 때문에, LLM 모델이 발주서를 세금 인보이스로 착각(Classification Error)하고, 아예 존재하지도 않는 최종 승인 ‘총금액(Total Amount)’ 필드를 과거 경험치에서 억지로 꺼내어 추론해 내는 창조적 환각(Generative Hallucination) 현상이 매우 강력하게 발생한다.

4. 견적서 (Quote / Estimate)

미래에 일어날 트랜잭션의 “예상” 비용을 기술하는, 아직 계약이 성립되지 않은 비확정적 허수 문서다.

• 구조적 특징: 견적일 기준으로 명시된 유효 기간(Valid Until), 향후 수량에 따른 조건부 할인(Conditional Discount, "100개 이상 구매 시 10% 할인") 과 같은 IF-THEN 조건문의 비결정론적 텍스트 블록들이 문서 내에 중첩되어 산재해 있다.
• LLM 시스템의 난제: 백엔드 시스템은 장부에 기록할 단 하나의 “확정된 결제 총금액 텐서“를 찾고자 목말라하지만, LLM은 “만약 옵션 A를 선택할 경우에는 얼마이고, B일 경우에는 얼마입니다“라는 조건부 텍스트를 멍청하게 전부 파싱하려 시도하다가 컨텍스트 윈도우(Context Window) 컴퓨팅 리소스를 낭비하고 치명적인 분기 망상에 빠지게 된다.

이처럼 지옥 같은 변수들로 얼룩진 4가지 다형성 문서들을 하나의 추출 모델로 관통하기 위해, 우리의 파이프라인 아키텍트는 반드시 LLM 프롬프트 주입 단계에서 이 문서들의 본질 종류(Doc_Type)를 동적(Dynamic)으로 분류(Classification)하는 Enum 플래그를 심어 넣어야 한다. 그리고 각 추출된 문서 플래그 타입 다형성(Polymorphism)에 따라, 파이썬 백엔드에서 작동하는 오라클의 유효성 검사 로직(Rule Engine)이 동적으로 다르게 발동할 수 있도록 인터페이스를 철저히 분리해서 준비해야만 한다.