비정형 은행 명세서에서 자동화된 SAP 대조(Reconciliation)까지

수년 동안 저는 AI가 기업 금융을 혁신할 것이라고 주장하는 기사들을 읽어왔습니다.

대부분은 챗봇(Chatbot)에 집중했습니다.

어떤 것들은 송장 OCR(Optical Character Recognition)에 집중했습니다.

다른 것들은 프로토타입 단계에 머물러 있는 인상적인 AI 데모를 보여주었습니다.

그러다 저는 매우 다른 문제를 마주하게 된 프로젝트에 참여하게 되었습니다.

그것은 텍스트를 생성하는 것에 관한 것이 아니었습니다.

또 다른 AI 어시스턴트를 구축하는 것에 관한 것도 아니었습니다.

그것은 제가 접해본 가장 큰 B2B 금융 운영 중 하나를 위한 대조(Reconciliation) 자동화를 돕는 것에 관한 것이었습니다.

그 도전 과제는 수천 건의 트랜잭션(Transaction) 단위로 측정되지 않았습니다.

그것은 비즈니스 파트너로부터 발생하는 연간 약 2조 원 규모의 입금 이체를 나타내는 기업 규모의 결제 흐름으로 측정되었습니다.

그리고 거의 모든 결제는 직접 은행 이체를 통해 이루어졌습니다.

결제 게이트웨이(Payment Gateway)도 없었습니다.

체크아웃(Checkout) 흐름도 없었습니다.

구조화된 메타데이터(Metadata)도 없었습니다.

그저 돈뿐이었습니다.

아무도 이야기하지 않는 기업의 현실

사람들이 디지털 결제에 대해 생각할 때, 보통 다음과 같은 것을 상상합니다:

고객

↓

체크아웃 (Checkout)

↓

결제 게이트웨이 (Payment Gateway)

↓

주문 완료

모든 것이 연결되어 있습니다.

모든 것이 결정론적(Deterministic)입니다.

기업 금융은 그렇게 작동하는 경우가 드뭅니다.

비즈니스 파트너는 기업 은행 계좌로 직접 돈을 이체합니다.

결제 조건은 계약을 통해 협상됩니다.

송장은 몇 주 또는 몇 달 후에 정산됩니다.

하나의 결제는 다음과 같은 것들을 정산할 수 있습니다:

• 단일 송장,
• 여러 송장,
• 계약 마일스톤(Milestone),
• 부분 결제,
• 또는 선급금.

은행은 오직 트랜잭션(Transaction)만을 수신합니다.

은행은 비즈니스를 이해하지 못합니다.

단일 트랜잭션은 많은 의미를 가질 수 있습니다

다음과 같은 트랜잭션을 받는다고 가정해 보십시오:

PART PMT ALPHABRIDGE SOLUTIONS MFG-INV-000157

회계사에게 이것은 즉각적인 의미를 전달합니다.

기계에게 이것은 그저 텍스트일 뿐입니다.

시스템은 여전히 다음 질문에 답해야 합니다:

• 어떤 고객이 결제를 했는가?
• 이 결제는 어떤 송장 (Invoice)을 참조하는가?
• 이것은 부분 결제 (Partial payment)인가?
• 어떤 계약 (Contract)이 이 거래를 규정하는가?
• 자동으로 대조 (Reconcile)할 수 있는가?
• SAP가 이 결제를 인식해야 하는가?

이것들은 언어의 문제가 아닙니다.

비즈니스 이해 (Business understanding)의 문제입니다.

전통적인 자동화가 한계에 도달한 이유

많은 기업용 대조 (Reconciliation) 시스템은 결정론적 규칙 (Deterministic rules)에 크게 의존합니다.

예를 들어:

거래에 송장 번호가 포함되어 있다면,

송장을 매칭한다.

단순합니다.

현실이 개입하기 전까지는 말이죠.

송장은 다양한 형식으로 나타납니다.

고객은 약어를 사용합니다.

계약은 진화합니다.

결제 참조 정보는 일관되지 않게 변합니다.

결국 규칙 엔진 (Rule engine)은 유지보수가 점점 더 어려워집니다.

새로운 예외가 발생할 때마다 또 다른 규칙이 추가됩니다.

결국 규칙 자체가 문제가 됩니다.

우리는 질문을 바꾸었습니다

다음과 같이 묻는 대신:

"거래를 어떻게 매칭할 것인가?"

우리는 다음과 같이 물었습니다:

"기계가 비즈니스 거래를 이해하도록 어떻게 도울 것인가?"

이 작은 변화가 아키텍처 (Architecture)를 완전히 바꾸어 놓았습니다.

매칭 엔진 (Matching engine)을 구축하는 대신,

우리는 트랜잭션 인텔리전스 시스템 (Transaction Intelligence System)을 구축했습니다.

아키텍처 (Architecture)

파이프라인 (Pipeline)은 다음과 같았습니다.

MT950 은행 명세서 (Bank Statement)
        │
        ▼
...

각 계층 (Layer)은 서로 다른 문제를 해결했습니다.

단일 AI 모델이 모든 것을 책임지지는 않았습니다.

자동화에 앞선 이해

이 프로젝트에서 얻은 가장 중요한 교훈 중 하나는 이것입니다:

인공지능 (Artificial Intelligence)은 비즈니스 이해 (Business understanding)를 대체하는 것이 아닙니다.

그것을 증폭시키는 것입니다.

시스템이 무엇인가를 자동화하기 전에, 먼저 이해해야 할 것들이 있었습니다:

• 고객 (Customers),
• 송장 (Invoices),
• 계약 (Contracts),
• 구매 주문 (Purchase orders),
• 결제 유형 (Payment types),
• 비즈니스 관계 (Business relationships).

이러한 개념들이 구조화된 후에야 비로소 확신을 가지고 대조 (Reconciliation)를 자동화할 수 있었습니다.

합성 데이터 (Synthetic Data)가 필수적이 된 이유

많은 기업 환경과 마찬가지로, 저희도 기밀 금융 기록을 단순히 공개하거나 이를 통해 학습시킬 수는 없었습니다.

대신, 저희는 민감한 정보를 노출하지 않으면서도 비즈니스 관계를 보존하는 합성 기업 데이터셋 (synthetic enterprise dataset)을 설계했습니다.

이 데이터셋에는 다음이 포함되었습니다:

• 고객 마스터 데이터 (customer master data),
• 계약서 (contracts),
• 송장 (invoices),
• 구매 주문서 (purchase orders),
• MT950 은행 명세서 (MT950 bank statements),
• 대조 정답 데이터 (reconciliation ground truth).

이를 통해 개인정보 보호 및 컴플라이언스 (compliance) 요구 사항을 준수하면서 전체 파이프라인 (pipeline)을 개발, 벤치마킹 및 개선할 수 있었습니다.

개체명 인식 (Named Entity Recognition) 그 이상

많은 NLP 프로젝트는 개체 (entities)를 추출하는 단계에서 멈춥니다.

기업용 소프트웨어는 그럴 수 없습니다.

다음과 같이 추출하는 것은:

ALPHABRIDGE SOLUTIONS

유용합니다.

이것이 다음 항목에 해당한다는 것을 아는 것은:

Customer ID:
CUS-00002

혁신적입니다.

개체 해상 (Entity Resolution)은 언어를 비즈니스 정체성과 연결했습니다.

비즈니스 규칙 (Business rules)은 정체성을 운영 의사결정과 연결했습니다.

그 조합이 신뢰할 수 있는 자동화를 가능하게 했습니다.

인텔리전스에서 실행으로

최종 목표는 결코 더 나은 NLP 모델을 구축하는 것이 아니었습니다.

목표는 운영상의 영향 (operational impact)이었습니다.

트랜잭션 (transactions)을 충분한 신뢰도로 해석할 수 있게 되자, 대조 엔진 (reconciliation engine)은 결제 건이 자동으로 인식되어 기업 재무 워크플로우 (financial workflow)로 전달될 수 있는지 여부를 결정했습니다.

재무 팀에게 모든 유입 트랜잭션을 수동으로 조사하도록 요청하는 대신, 시스템은 결정론적 비즈니스 로직 (deterministic business logic)과 AI 지원 이해를 바탕으로 트랜잭션을 분류, 검증 및 후속 처리를 위해 준비했습니다.

이는 대규모 기업 결제 데이터 전반에 걸쳐 일관성을 개선하는 동시에 수동 작업량을 크게 줄였습니다.

내가 배운 것

이 프로젝트는 기업용 AI (Enterprise AI)에 대해 생각하는 방식을 근본적으로 바꾸어 놓았습니다.

가장 어려운 부분은 트랜스포머 (transformer)를 학습시키는 것이 아니었습니다.

API를 구축하는 것도 아니었습니다.

모델을 배포하는 것도 아니었습니다.

가장 어려운 과제는 비즈니스가 실제로 어떻게 운영되는지를 이해할 수 있는 시스템을 설계하는 것이었습니다.

기업용 AI는 프롬프트 (prompts)에 관한 것이 아닙니다.

그것은 아키텍처 (architecture)에 더 가깝습니다.

모델에 관한 것이 아닙니다.

지식 (knowledge)에 더 가깝습니다.

자동화에 관한 것이 아닙니다.

이해 (understanding)에 더 가깝습니다.

마치며 (Final Thoughts)

AI 산업은 종종 모델을 찬양합니다.

기업 조직은 성과 (outcomes)를 측정합니다.

AI로 가장 큰 가치를 창출하는 기업은 반드시 최신 모델을 사용하는 기업은 아닐 것입니다.

그들은 파편화된 운영 데이터 (operational data)를 신뢰할 수 있는 비즈니스 인텔리전스 (business intelligence)로 변환할 수 있는 역량을 가진 기업일 것입니다.

그곳이 바로 자동화 (automation)가 진정으로 시작되는 지점입니다.

AI 에이전트 (AI agent)와 함께가 아닙니다.

챗봇 (chatbot)과 함께가 아닙니다.

바로 이해 (understanding)와 함께입니다.

기업용 AI 시스템을 구축하고 싶으신가요?

이 프로젝트는 실제 운영 가능한 트랜잭션 인텔리전스 시스템 (Transaction Intelligence System) 뒤에 숨겨진 전체 엔지니어링 프로세스를 기록하도록 저에게 영감을 주었습니다.

Enterprise AI Automation Blueprint 내부에서는 다음 내용을 확인하실 수 있습니다:

• 기업용 AI 아키텍처 (Enterprise AI Architecture)
• 정형 데이터 설계 (Canonical Data Design)
• 금융 개체명 인식 (Financial Named Entity Recognition (NER))
• 합성 기업 데이터셋 엔지니어링 (Synthetic Enterprise Dataset Engineering)
• 개체 해소 (Entity Resolution)
• 자동 대조 (Automated Reconciliation)
• FastAPI 프로덕션 API (FastAPI Production APIs)
• 평가 및 벤치마킹 (Evaluation & Benchmarking)
• 프로덕션 준비 완료된 Python 소스 코드 (Production-ready Python source code)

단순한 프로토타입이 아니라 실제 기업의 문제를 해결하는 AI 시스템 구축에 관심이 있다면, 여기에서 전체 블루프린트를 살펴보실 수 있습니다:

📘 Enterprise AI Automation Blueprint

👉 https://uigerhana.gumroad.com/l/enterprise-ai-automation-blueprint

또한 저는 Dev.to에 기업용 AI (Enterprise AI), 소프트웨어 아키텍처 (Software Architecture), AI 자동화 (AI Automation), 그리고 프로덕션 AI 시스템 (Production AI Systems)을 다루는 무료 엔지니어링 시리즈를 게시하고 있습니다.

단순히 지능을 생성하는 것을 넘어, 측정 가능한 비즈니스 임팩트 (business impact)를 전달하는 시스템을 구축하는 데 이 내용이 도움이 되기를 바랍니다.