Building Enterprise AI Automation Systems 시리즈의 5부

서론

인공지능(Artificial Intelligence)은 기계가 비정형 정보(unstructured information)를 이해하는 방식을 극적으로 개선했습니다.

현대의 언어 모델(language models)은 문서에서 엔티티(entities)를 추출할 수 있습니다.

개체명 인식(Named Entity Recognition) 시스템은 송장(invoices), 계약서(contracts), 고객(customers), 결제 참조(payment references) 등을 식별할 수 있습니다.

엔티티 해소(Entity Resolution) 엔진은 이러한 엔티티를 마스터 레코드(master records)에 매핑할 수 있습니다.

많은 AI 튜토리얼은 여기서 멈춥니다.

추출된 엔티티가 표시됩니다.

데모가 끝납니다.

하지만 엔터프라이즈 자동화(enterprise automation)는 여정의 절반만을 마친 것입니다.

정보를 이해하는 것이 비즈니스 의사결정을 내리는 것과 같지는 않습니다.

AI 모델이 다음과 같은 엔티티를 성공적으로 추출했다고 가정해 봅시다:

{
    "customer_id":"CUS-00002",
    "invoice_number":"MFG-INV-000157",
...

이 거래를 대조(reconciled)할 수 있을까요?

반드시 그렇지는 않습니다.

비즈니스는 여전히 다음과 같은 질문에 답해야 합니다:

• 송장이 존재하는가?
• 송장이 이미 결제되었는가?
• 송장이 이 고객에게 속해 있는가?
• 결제 금액이 정확한가?
• 부분 결제가 허용되는가?
• 계약이 만료되었는가?
• 수동 승인이 필요한가?

이러한 질문들은 언어의 문제가 아닙니다.

이것은 비즈니스의 문제입니다.

이 지점에서 대조 엔진(Reconciliation Engine)이 엔터프라이즈 자동화의 핵심이 됩니다.

대조(Reconciliation)의 이해

많은 사람들이 대조(reconciliation)를 숫자를 맞추는 것과 연관 지어 생각합니다.

실제로 대조는 비즈니스 관계를 검증하는 과정입니다.

결제 금액이 일치한다고 해서 단순히 대조가 완료되었다고 간주되지 않습니다.

비즈니스 제약 조건(business constraints) 또한 충족해야 합니다.

예를 들어:

Customer
↓

...

모든 관계는 검증되어야 합니다.

올바른 송장을 참조하지만 잘못된 고객에게 속한 결제는 여전히 잘못된 것입니다.

비즈니스 컨텍스트(Business context)는 항상 중요합니다.

왜 AI만으로는 충분하지 않은가

대규모 언어 모델(Large Language Models)은 텍스트를 이해하는 데 탁월합니다.

하지만 금융 정책(financial policies)을 강제하도록 설계되지는 않았습니다.

AI 모델이 다음과 같이 예측한다고 가정해 봅시다:

{
    "invoice":"MFG-INV-000157"
}

해당 송장(invoice)이 자동으로 결제 완료(paid)로 표시되어야 할까요?

아니요.

AI는 송장을 식별했을 뿐입니다.

비즈니스 로직을 검증(validate)한 것은 아닙니다.

검증에는 결정론적 로직(deterministic logic)이 필요합니다.

엔터프라이즈 소프트웨어는 결정론적 동작(deterministic behavior)에 의존합니다.

이것이 바로 규칙 엔진(rule engines)이 현대 AI 아키텍처에서 계속해서 중요한 역할을 수행하는 이유입니다.

대조 파이프라인(Reconciliation Pipeline) 설계

우리의 대조 파이프라인은 여러 개의 독립적인 단계로 구성됩니다.

Bank Statement
        │
        ▼
...

각 단계는 정보를 제공합니다.

오직 결정 엔진(Decision Engine)만이 최종 결과를 결정합니다.

비즈니스 검증 규칙(Business Validation Rules)

결정 엔진은 여러 비즈니스 제약 조건(business constraints)을 평가합니다.

단 하나의 질문을 던지는 대신, 수많은 질문을 평가합니다.

고객 검증(Customer Validation)

결제 건이 예상된 고객의 것이 맞습니까?

예시:

Payment

↓
...

송장 검증(Invoice Validation)

송장이 존재합니까?

Invoice

↓
...

계약 검증(Contract Validation)

송장이 활성화된 계약(active contract)에 속해 있습니까?

Invoice

↓
...

금액 검증(Amount Validation)

결제 금액이 비즈니스 기대치(business expectations)를 충족합니까?

가능한 시나리오는 다음과 같습니다:

Exact Payment (정확한 결제)

Partial Payment (부분 결제)

Overpayment (초과 결제)

Underpayment (미달 결제)

조직마다 서로 다른 정책(policies)을 구현합니다.

결정 엔진은 설정 가능한 규칙(configurable rules)을 지원해야 합니다.

통화 검증(Currency Validation)

예시:

Invoice

EUR

Payment

USD

자동 대조(Automatic reconciliation)는 아마도 중단되어야 할 것입니다.

중복 결제 탐지(Duplicate Payment Detection)

동일한 송장에 대한 두 번째 결제는 다음과 같은 상황을 나타낼 수 있습니다:

• 중복 이체 (duplicate transfer)
• 회계 오류 (accounting error)
• 사기 (fraud)
• 의도적인 분할 결제 (intentional split payment)

엔진은 대조를 수행하기 전에 이러한 상황을 반드시 탐지해야 합니다.

결정 카테고리(Decision Categories)

엔진은 단순히 True 또는 False만을 반환하는 대신, 비즈니스 결정(business decisions)을 생성합니다.

예를 들어:

AUTO_RECONCILED

모든 것이 유효합니다.

사람의 개입이 필요하지 않습니다.

PARTIAL_PAYMENT

송장이 미결(open) 상태로 남습니다.

미결 잔액이 존재합니다.

OVERPAYMENT

고객이 예상보다 더 많은 금액을 지불했습니다.

환불 또는 신용 전표 (Credit Note)가 필요할 수 있습니다.

UNDERPAYMENT

결제가 완료되었습니다.

송장이 부분적으로 미결 상태로 남습니다.

MULTIPLE_INVOICES

하나의 트랜잭션이 여러 송장을 결제합니다.

REVIEW_REQUIRED

비즈니스 신뢰도가 불충분합니다.

재무 부서로 에스컬레이션 (Escalate) 하십시오.

이러한 결정들은 다운스트림 자동화 (Downstream Automation)의 언어가 됩니다.

규칙 엔진 (Rule Engine) 설계

규칙 엔진이 구식이라는 것은 흔한 오해입니다.

실제로는 그 반대입니다.

AI는 가능성을 식별합니다.

규칙은 확실성을 강제합니다.

단순화된 평가 흐름은 다음과 같습니다:

송장이 존재하는가? (Invoice Exists?)

↓
...

고객 매칭 여부? (Customer Match?)

↓
...

금액이 정확한가? (Amount Correct?)

↓
...

모든 결정이 결정론적 (Deterministic)이라는 점에 주목하십시오.

환각 (Hallucination)이 없습니다.

모호함이 없습니다.

정확히 엔터프라이즈 소프트웨어가 요구하는 사항입니다.

신뢰도 기반 결정 (Confidence-Based Decisions)

모든 예측이 자동화를 트리거해서는 안 됩니다.

개체 식별 (Entity Resolution) 결과가 다음과 같다고 가정해 봅시다:

{
    "customer_id":"CUS-00002",
    "confidence":0.98
...

자동 대조 (Automatic Reconciliation)가 아마도 허용될 것입니다.

이제 다음과 같은 상황을 상상해 보십시오:

{
    "customer_id":"CUS-00017",
    "confidence":0.54
...

ERP를 업데이트해야 할까요?

아마도 아닐 것입니다.

신뢰도 임계값 (Confidence Thresholds)을 통해 조직은 자동화와 운영 리스크 사이의 균형을 맞출 수 있습니다.

예를 들어:

신뢰도(Confidence) ≥ 0.95

↓
...

신뢰도(Confidence) ≥ 0.80

↓
...

신뢰도(Confidence) < 0.80

↓
...

이러한 접근 방식은 비용이 많이 드는 대조 실수를 극적으로 줄여줍니다.

설명 가능한 결정 구축 (Building Explainable Decisions)

규칙 기반 대조의 한 가지 장점은 설명 가능성 (Explainability)입니다.

단순히 다음과 같이 반환하는 대신:

Rejected

엔진은 그 이유를 설명해야 합니다.

예시:

{
    "status":"REVIEW_REQUIRED",
    "reason":"Invoice amount does not match payment amount."
...

또는:

{
    "status":"PARTIAL_PAYMENT",
    "remaining_balance":620.50
...

설명 가능성은 신뢰를 높입니다.

재무 팀은 자신의 결정을 정당화하는 AI 시스템을 채택할 가능성이 훨씬 더 높습니다.

비즈니스 규칙(Business Rules)과 AI의 통합

이 프로젝트를 통해 얻은 가장 중요한 아키텍처적 교훈 중 하나는 AI가 비즈니스 규칙(Business Rules)을 대체해서는 안 된다는 것입니다.

대신, AI는 비즈니스 규칙을 풍부하게 만들어야 합니다.

그 관계를 다음과 같이 생각해보세요.

NER

↓
...

모든 계층은 단일 책임(Single Responsibility)을 가집니다.

이러한 분리는 시스템을 테스트, 설명 및 유지 관리하기 더 쉽게 만듭니다.

교훈 (Lessons Learned)

대조 엔진(Reconciliation Engine)을 구축하는 과정은 엔터프라이즈 AI에 대한 저의 생각을 근본적으로 바꾸어 놓았습니다.

처음에 저는 머신러닝(Machine Learning)이 문제의 대부분을 해결할 것이라고 가정했습니다.

하지만 머신러닝은 '이해(Understanding)'를 해결했습니다.

비즈니스 규칙(Business Rules)은 '신뢰(Trust)'를 해결했습니다.

이 차이점은 프로젝트에서 가장 가치 있는 교훈 중 하나가 되었습니다.

조직은 언어를 이해하기 때문에 자동화하는 것이 아닙니다.

그들은 결정을 신뢰할 수 있기 때문에 자동화합니다.

신뢰는 결정론적 검증(Deterministic Validation)에서 옵니다.

단순한 예측(Prediction)만으로는 부족합니다.

결론

인공지능(Artificial Intelligence)은 문서를 이해하는 데 매우 탁월합니다.

하지만 엔터프라이즈 소프트웨어는 정책을 강제(Enforce)해야 합니다.

대조 엔진(Reconciliation Engine)은 이 두 세계를 연결합니다.

이 엔진은 추출된 엔티티(Entities)를 검증된 비즈니스 결정으로 변환합니다.

AI를 결정론적 비즈니스 로직(Deterministic Business Logic)과 결합함으로써, 조직은 신뢰성, 감사 가능성(Auditability) 또는 설명 가능성(Explainability)을 희생하지 않고도 재무 운영을 자동화할 수 있습니다.

따라서 엔터프라이즈 자동화의 미래는 'AI 대 규칙(AI vs Rules)'이 아닙니다.

그것은 '규칙과 함께 작동하는 AI(AI working together with rules)'입니다.

다음 단계는?

파트 6 — FastAPI를 이용한 트랜잭션 인텔리전스(Transaction Intelligence) API 구축

다음 기사에서는 전체 파이프라인을 프로덕션 환경에 적합한 REST API로 노출하는 방법을 다룹니다.

다음 내용을 포함합니다:

• 깔끔한 API 계약(API Contracts) 설계
• 요청(Request) 및 응답(Response) 스키마
• 추론(Inference) 파이프라인
• 스트리밍 예측(Streaming Predictions)
• 에러 핸들링(Error Handling)
• 신뢰도 보고(Confidence Reporting)
• FastAPI를 이용한 프로덕션 배포

우리는 트랜잭션 인텔리전스(Transaction Intelligence) 파이프라인을 ERP 시스템, 재무 플랫폼, AI 에이전트 및 엔터프라이즈 애플리케이션이 실시간으로 사용할 수 있는 서비스로 변환할 것입니다.