소기업 금융을 위한 자동 추출 및 분류, 인간 검토, 문서 연결, 그리고 결정론적 완전성 검사

#NebiusServerlessChallenge · #ServerlessAI · #FinTech · #LLM

소기업의 금융은 대시보드에서 시작되지 않습니다. 누군가가 반드시 이해하고 정확하게 입력해야 하는 문서로 가득 찬 폴더에서 시작됩니다: 매입 및 매출 송장 (invoices), 비용 영수증, 급여 대장 (payroll registers), 은행 확인서 (bank confirmations), 급여 명세서 (payslips), 그리고 공급업체 명세서 (supplier statements).

운영상의 질문들은 묻기는 간단하지만 수동으로 답하기에는 비용이 많이 듭니다:

• 이 문서는 무엇이며, 어디에 속하는가?
• 이것이 공급업체 송장인가, 아니면 매출 송장인가?
• 예상된 모든 문서가 실제로 수령되고 기록되었는가?
• 어떤 문서들이 동일한 금융 이벤트를 설명하는가?
• 결제 또는 수금이 증빙 자료를 갖추고 있는가?
• 급여의 경우, 급여 대장, 은행 확인서, 그리고 급여 명세서가 일치하는가?

Archon은 이러한 제어 루프 (control loop)를 중심으로 구축되었습니다. Archon은 업로드된 금융 문서를 구조화되고, 분류되며, 검토 가능한 기록으로 변환합니다. 동일한 이벤트를 설명하는 문서들을 연결하며, 기간별 재무 관점을 생성하기 전에 명시적인 검사를 실행합니다. 목표는 재무 입력과 통제를 더 빠르고, 명확하며, 감사 가능하게 (auditable) 만드는 것입니다.

현재 빌드는 두 가지 제한된 제어 경로 (bounded control paths)를 가진 아키텍처를 증명합니다: 인간의 검토 게이트 (human review gate)가 포함된 자동 문서 처리, 그리고 결정론적 검증 (deterministic validation)을 통한 급여 이벤트 연결입니다. 또한 구조화된 명세서 입력을 위한 공급업체 명세서 조정 (reconciliation) 구성 요소를 포함하고 있습니다. 일반적인 송장-은행 결제 매칭, 수금 매칭, 중복 결제 탐지, 그리고 세금 납부 확인은 이 모델의 다음 확장 단계이며, 이 버전이 이미 수행하고 있다고 주장하는 기능이 아닙니다.

아키텍처 다이어그램 (Architecture diagram): 전체 컴포넌트 그래프는 공개 리포지토리 (public repository)에서도 확인할 수 있습니다. 이 다이어그램은 해당 테넌트(tenant)의 CPU AI-Jobs 할당량이 0인 상황에서, 라이브 엔드포인트 (Endpoint)가 사용하는 인라인 실행 모드 (inline execution mode)와 작업(Jobs) 기반의 대상 아키텍처 (target architecture)를 분리하여 보여줍니다.

그림 1 — Archon 아키텍처: Nebius AI Endpoint, Jobs-ready 파이프라인 (pipelines), 추론 API (Inference API), 객체 스토리지 (Object Storage), 그리고 관리형 PostgreSQL (Managed PostgreSQL).

제품 루프: 읽기, 분류, 검토, 기록, 통제

그림 2 — 추출 (Extraction), 문서 유형 분류 (document-type classification), 이벤트 연결 (event linking), 사람의 검토 (human review), 그리고 결정론적 분석 (deterministic analysis).

Archon은 사전에 정제된 행(rows)이 아닌 혼합된 파일들로부터 시작합니다. 추출 파이프라인 (extraction pipeline)은 PDF, DOCX 파일, 이미지, TIFF, 그리고 스캔된 PDF를 수용합니다. 디지털 문서는 텍스트 경로를 따릅니다. 스캔된 문서 및 이미지 기반 문서는 Nebius 추론 API (Inference API) 상의 Qwen2.5-VL-72B를 거칩니다.

그 결과물은 문서 유형 (document type), 날짜 (date), 공급업체 (supplier), 수취인 (recipient), 세금 식별자 (tax identifier), 통화 (currency), 송장 번호 (invoice number), 부가가치세 (VAT), 합계 (totals), 그리고 품목 (line items)과 같은 필드를 가진 구조화된 기록 (structured record)입니다. 급여 관련 문서는 직원 수 (employee count), 총급여 (gross pay), 실수령액 (net pay), 고용주 비용 (employer cost)과 같은 목적별 필드를 추가합니다.

추출 이후에는 결정론적 분류 (deterministic classification)가 뒤따릅니다. 이 두 번째 단계가 중요한 이유는 LLM이 문서를 정확하게 읽더라도 잘못된 회계 유형을 할당할 수 있기 때문입니다. ClassifierAgent는 도메인 규칙 (domain rules)을 사용하여 모호한 결과를 정제함으로써, 명백한 분류 오류가 다운스트림 계산 (downstream calculations)에 영향을 미치지 않도록 합니다.

사용자는 분석을 진행하기 전에 성공적으로 추출된 문서들을 확인합니다. 사용자는 유형을 수정하거나, 관련 없는 파일을 제외하고, 다음 단계로 진행할 세트를 확정할 수 있습니다. Archon은 또한 문서가 이름이나 세금 식별자(tax identifier)를 통해 설정된 회사에 속하는지 여부를 확인합니다.

실패한 파일과 관련하여 현재 중요한 제한 사항이 있습니다. 추출 과정에서 Archon은 각 실패한 파일명과 사유를 Object Storage 내의 업로드별 documents.json 아티팩트(artifact)에 기록하고, 해당 실패 내용을 작업 로그(job log)에 작성합니다. 현재의 검토 API와 UI는 해당 실패 목록을 노출하지 않으며, 검토된 세트를 확정하면 실패 메타데이터를 전달하지 않은 채 업로드별 문서 아티팩트를 교체해 버립니다. 따라서 실패는 처리 과정 중에 기록되지만, 제품 내 검토자에게는 아직 보이지 않습니다. 이를 완전한 실패 처리 루프(failure-handling loop)라고 부르기 위해서는 검토 과정을 통해 실패 내용을 드러내고 보존하는 기능이 필요합니다.

이러한 검토 게이트(review gate)는 의도된 설계입니다. 자동화는 장부 책임자로부터 통제권을 앗아가지 않으면서도 반복적인 입력 작업을 제거해야 합니다.

# jobs/extraction/agents/classifier.py
def run(docs):
    for doc in docs:
...

승인 후에는 Object Storage가 권위 있는 원본 및 구조화된 아티팩트(artifacts)를 보유합니다. 관리형 PostgreSQL은 문서, 급여 이벤트(payroll events), 직원 및 검증 결과에 대한 관계형 읽기 모델(relational read model)을 제공합니다. 데이터베이스 미러(database mirror)는 의도적으로 최선 노력(best-effort) 방식으로 운영됩니다. 즉, 일시적인 데이터베이스 문제로 인해 이미 생성된 보고서가 사라져서는 안 되기 때문입니다.

하나의 이벤트를 설명하는 문서 연결하기

그림 3 — 하나의 급여 이벤트에 대한 상호 보완적 증거: 은행이 확인한 순급여(net pay), 장부에 보고된 고용주 비용, 직원 수준의 급여 명세서.

분류(Classification)가 "이것은 무엇인가?"에 답한다면, 연결(Linking)은 "이것은 무엇과 함께 속해 있는가?"에 답합니다.

급여(Payroll)는 하나의 급여 실행(run)이 서로 다른 역할을 하는 여러 문서를 생성하기 때문에 유용한 실례가 됩니다.

• 은행 확인서(Bank confirmation)는 직원들에게 이체된 순액(net amount)을 기록합니다.
• 급여 대장(Payroll register)은 총급여(gross pay), 고용주 부담금(employer contributions), 직원 수, 그리고 전체 고용주 비용(employer cost)을 기록합니다.
• 개별 급여 명세서(Individual payslips)는 직원 수준의 금액을 설명합니다.

이것들은 하나의 숫자에 대한 서로 경쟁하는 버전이 아니라, 동일한 이벤트의 서로 다른 부분에 대한 상호 보완적인 기록들입니다. Archon의 EventLinkerAgent는 이들을 회사와 기간별로 그룹화하여 PayrollEvent로 만듭니다. 현금 흐름(cash-flow) 관점은 은행 거래를 읽고, 관리 비용(management expense) 관점은 급여 대장을 읽으며, 검증(validation) 단계에서는 증빙 기록들이 일치하는지 확인합니다.

# jobs/extraction/agents/event_linker.py
def _build_event(company, period, docs):
    bank = _pick_one(docs, DocType.BANK_CONFIRMATION)
...

그 다음, 네 가지 명명된 규칙(named rules)이 연결된 증거를 확인합니다:

• R1: 은행 순액은 급여 명세서 순액의 합계와 ±2% 이내로 거의 일치해야 합니다.
• R2: 순급여(net pay) 대비 고용주 비용의 비율이 명시된 예상 범위 내에 있어야 합니다.
• R3: 은행 확인서의 날짜는 급여 기간의 종료일보다 늦지 않아야 합니다.
• R4: 급여 대장의 인원수가 급여 명세서의 개수와 일치해야 합니다.

각 결과는 적용된 규칙, 비교된 값, 그리고 소스 파일을 인용합니다. 출력값은 "AI가 무언가 수상하다고 생각함"이 아닙니다. 그것은 검토자가 수동으로 재현할 수 있는 통제(control)입니다.

더 넓은 제품 방향성도 동일한 패턴을 따릅니다. 공급업체 송장(Supplier invoice)은 결제 증빙(settlement evidence)과 연결되어야 합니다. 매출 송장(Sales invoice)은 대금 회수(collection)와 연결되어야 합니다. 은행 거래는 문서나 의무(obligation)에 의해 설명될 수 있어야 합니다. 세금 및 사회 보장 부채(social-security liabilities)는 납부(remittances)와 연결되어야 합니다. 이러한 연결은 자연스러운 다음 이벤트 가족(event families)이며, 제출된 빌드는 이것들이 이미 완료되었다고 가정하지 않습니다.

공급업체 완전성: 정밀한 현재 경계

Archon에는 공급업체 명세서(supplier statement)의 사전 구조화된 항목을 시스템에 존재하는 송장 번호 및 합계와 비교하는 단위 테스트가 완료된 ReconciliationAgent가 포함되어 있습니다. 해당 필드들이 제공되면, 업로드된 세트에서 누락된 명세서 송장, 명세서에 없는 업로드된 송장, 그리고 잔액 불일치(balance discrepancy)를 보고할 수 있습니다.

이는 문서 완전성(document-completeness) 구성 요소이며, 아직 은행 결제 매칭(bank-payment matcher) 단계는 아닙니다. 이 구성 요소는 구조화된 명세서 데이터가 존재하지만, 현재의 추출 프롬프트(extraction prompt)가 statement_entries, statement_balance 또는 statement_overdue를 요청하지 않고 리뷰 UI에서 이를 수집하지 않을 때 분석 파이프라인(analysis pipeline)에 의해 호출됩니다. 따라서 이 구성 요소는 분석 경계(analysis boundary)에서 테스트되지만, 원본 공급업체 명세서부터 추출 및 리뷰를 거치는 엔드 투 엔드(end to end)로 연결되어 있지는 않습니다. “이 은행 결제가 해당 송장을 정산했다”는 기능은 별도의 로드맵 작업입니다.

이러한 구분 때문에 Archon은 공급업체 명세서를 손익(P&L) 및 현금 흐름(cash-flow) 산술 계산에서 제외합니다. 명세서는 참조 증거(reference evidence)입니다. 이를 비용으로 계산하면 명세서에 나열된 송장들이 중복 계산될 것입니다.

Nebius Serverless AI가 워크플로에 적합한 이유

그림 4 — 관리형 추론(Managed inference)이 모델 집약적인 작업을 처리하는 동안, CPU 오케스트레이션(orchestration)과 스토리지(storage)가 각 문서 배치(batch)를 중심으로 확장됩니다.

금융 문서 처리는 간헐적(bursty)입니다. 기업은 월간 배치를 업로드하고, 이를 처리하고, 결과를 검토한 다음, 며칠 또는 몇 주 동안 아무것도 하지 않을 수 있습니다. 이러한 패턴을 위해 전용 GPU를 계속 온라인 상태로 유지하는 것은 낭비일 것입니다.

Archon은 오케스트레이션(orchestration)과 배치 작업(batch work)을 분리합니다:

• **CPU AI 엔드포인트 (CPU AI Endpoint)**는 FastAPI 백엔드와 업로드, 검토, 작업 상태(job-status), 분석 및 보고 API를 호스팅합니다.
• **추출 AI 작업 (extraction AI Job)**은 업로드된 배치를 처리하고 구조화된 산출물(artifacts)을 작성하기 위해 설계된 온디맨드(on-demand) 경로입니다.
• **분석 AI 작업 (analysis AI Job)**은 승인된 기록을 읽고, 금융 에이전트(financial agents)를 실행하며, 보고서를 작성하기 위해 설계된 온디맨드(on-demand) 경로입니다.
• Nebius Inference API는 시각적 추출을 위한 Qwen2.5-VL-72B와 경영진 보고용 내러티브를 위한 Llama-3.3-70B를 제공합니다.
• **객체 스토리지 (Object Storage)**와 **관리형 PostgreSQL (Managed PostgreSQL)**은 내구성이 있는 산출물과 관계형 읽기 모델(relational read model)을 제공합니다.
• Nebius Container Registry는 추출 및 분석 작업(Job) 이미지를 보유합니다. 엔드포인트 백엔드 이미지는 GitHub Container Registry에서 가져옵니다.

GPU는 Archon의 컨테이너가 아닌 관리형 추론 계층(managed inference layer)에 존재합니다. 추출 및 분석 패키지는 작업(Jobs)으로 실행되든 아래의 폴백(fallback)을 통해 실행되든 CPU 전용으로 유지됩니다.

현재 라이브 배포는 JOB_RUNNER_BACKEND=inline을 사용합니다. 즉, 동일한 두 패키지가 CPU 엔드포인트 내부에서 격리된 서브프로세스(subprocesses)로 실행되며, 동일한 객체 스토리지 및 상태 계약(status contracts)을 사용합니다. 작업(Jobs) 제출 코드, 이미지 및 용량 처리(capacity handling)는 구현 및 테스트가 완료되었으나, 이 테넌트(tenant)의 CPU AI-Jobs 할당량(quota)이 0이기 때문에 어떤 작업도 성공적으로 프로비저닝되지 않았습니다. "AI 작업(AI Jobs)으로 설계됨"과 "현재 인라인(inline)으로 실행 중"은 의도적으로 분리된 주장입니다.

React 프런트엔드와 얇은 BFF(Backend For Frontend)는 공개 호스팅, 인증 및 브라우저 엣지 TLS를 위해 Firebase에서 실행됩니다. 따라서 정확한 배포 정의는 다음과 같습니다: Nebius는 도메인 백엔드, 작업 설계, 추론, 스토리지, 레지스트리 및 금융 데이터 서비스를 실행하며, Firebase는 공개 브라우저 엣지(public browser edge)를 제공합니다.

두 개의 단일 책임 파이프라인 (Two single-responsibility pipelines)