Building Enterprise AI Automation Systems 시리즈의 8부

서론

지난 7개의 기사를 통해 우리는 처음에는 금융 자동화 프로젝트처럼 보일 수 있는 무언가를 구축해 왔습니다.

우리는 MT950 은행 명세서를 파싱(Parsing)했습니다.

우리는 정형 데이터 구조(Canonical data structures)를 설계했습니다.

우리는 합성 기업 데이터셋(Synthetic enterprise datasets)을 생성했습니다.

우리는 금융 개체명 인식(Financial Named Entity Recognition) 모델을 학습시켰습니다.

우리는 비즈니스 엔티티(Business entities)를 해결했습니다.

우리는 대조 엔진(Reconciliation engine)을 구축했습니다.

우리는 이 모든 것을 프로덕션 준비가 된 API를 통해 노출했습니다.

언뜻 보기에 이것은 금융 시스템처럼 보입니다.

하지만 그렇지 않습니다.

우리가 실제로 구축한 것은 재사용 가능한 기업 인텔리전스 레이어(Enterprise Intelligence Layer)입니다.

비정형 운영 데이터를 구조화된 비즈니스 이해로 변환할 수 있는 레이어입니다.

이 차이점은 중요합니다.

왜냐하면 기업 AI의 미래는 챗봇(Chatbots)에 관한 것이 아니기 때문입니다.

그것은 비즈니스가 실제로 어떻게 운영되는지 이해할 수 있는 시스템에 관한 것입니다.

MT950을 넘어

많은 독자들이 이 시리즈를 은행 명세서와 연관 지을 수 있습니다.

그것은 단지 하나의 유스케이스(Use case)일 뿐입니다.

아키텍처 자체는 도메인 독립적(Domain independent)입니다.

MT950을 다음과 같은 것으로 교체해 보십시오:

• 보험 청구(Insurance Claims)
• 구매 주문서(Purchase Orders)
• 의료 기록(Medical Records)
• 법률 계약서(Legal Contracts)
• 선적 서류(Shipping Documents)
• 세무 보고서(Tax Reports)
• 제조 주문(Manufacturing Orders)

파이프라인(Pipeline)은 거의 변하지 않습니다.

송장을 추출하는 대신,

보험 증권을 추출합니다.

고객 대신,

환자를 추출합니다.

계약서 대신,

허가증을 추출합니다.

인텔리전스 레이어는 동일하게 유지됩니다.

이것이 바로 구현(Implementation)보다 아키텍처가 더 중요한 이유입니다.

기업 AI는 챗봇이 아니다

오늘날 AI를 둘러싼 가장 큰 오해 중 하나는 모든 지능형 시스템이 ChatGPT처럼 보여야 한다는 것입니다.

많은 조직이 즉시 이렇게 묻습니다:

"챗봇을 추가할 수 있을까요?"

더 나은 질문은 다음과 같습니다:

"우리 시스템이 우리 비즈니스를 이해할 수 있을까요?"

기업 AI는 대화로 시작하는 경우가 드뭅니다.

그것은 운영 데이터를 이해하는 것에서 시작됩니다.

송장.

이메일.

계약서.

명세서.

보고서.

ERP 내보내기 데이터.

이러한 문서들은 이미 업무를 자동화하는 데 필요한 지식을 포함하고 있습니다.

문제는 지능이 부족한 것이 아닙니다.

문제는 접근할 수 없는 지능입니다.

문서에서 의사결정으로

우리가 구축한 것을 검토해 봅시다.

원시 문서 (Raw document):

PART PMT ALPHABRIDGE SOLUTIONS MFG-INV-000157

↓

표준 변환 (Canonical Transformation)

↓

비즈니스 분류 체계 (Business Taxonomy)

↓

개체명 인식 (Named Entity Recognition)

↓

개체 해소 (Entity Resolution)

↓

비즈니스 검증 (Business Validation)

↓

의사결정 인텔리전스 (Decision Intelligence)

↓

REST API

↓

기업 워크플로 (Enterprise Workflow)

모든 단계에서,

정보는 더욱 의미 있어집니다.

문서는 서서히 비즈니스 의사결정으로 변모합니다.

이러한 과정은 기업용 AI (Enterprise AI)의 진정한 목표를 나타냅니다.

예측이 아닙니다.

이해입니다.

지능은 하나의 레이어입니다

많은 AI 아키텍처는 언어 모델 (Language Model)을 중심에 둡니다.

우리의 경험은 다른 것을 시사했습니다.

다음 대신에:

문서 (Documents)
↓
...

기업 시스템은 다음과 같이 요구합니다:

운영 데이터 (Operational Data)
↓
...

중요한 점을 주목하십시오.

AI 에이전트 (AI Agent)는 끝부분 근처에 나타납니다.

시작점이 아닙니다.

이는 의도적인 것입니다.

에이전트는 비즈니스 지식을 오케스트레이션 (Orchestrate)해야 합니다.

비즈니스 지식을 생성해서는 안 됩니다.

AI 에이전트에는 컨텍스트가 필요합니다

에이전트에게 다음과 같이 질문한다고 상상해 보십시오:

"이 송장이 결제되었나요?"

컨텍스트 (Context) 없이는,

답을 내는 것이 불가능합니다.

에이전트는 먼저 다음을 알아야 합니다:

• 어떤 고객인가?
• 어떤 송장인가?
• 어떤 계약인가?
• 어떤 결제인가?
• 어떤 트랜잭션 (Transaction)인가?

이러한 답변 중 어느 것도 언어 모델 (Language Model)에서 나오지 않습니다.

그것들은 인텔리전스 레이어 (Intelligence Layer)에서 나옵니다.

이것이 바로 트랜잭션 인텔리전스 (Transaction Intelligence)가 기업용 AI의 메모리가 되는 이유입니다.

의사결정 인텔리전스의 부상

대부분의 조직은 문서 인텔리전스 (Document Intelligence)에 집중합니다.

텍스트 추출.

보고서 요약.

설명 생성.

차세대 기업 시스템은 문서 이해를 넘어설 것입니다.

그들은 의사결정 인텔리전스 (Decision Intelligence)에 집중할 것입니다.

의사결정 인텔리전스는 다음과 같은 질문에 답합니다:

이 결제 건을 조정 (Reconcile)해야 하는가?

이 송장을 승인해야 하는가?

이 거래가 사기 조사 (Fraud investigation)를 트리거해야 하는가?

이 고객에게 신용 (Credit)을 부여해야 하는가?

이 구매 주문 (Purchase order)을 승인 (Release)해야 하는가?

변화에 주목하십시오.

시스템은 더 이상 정보를 추출하는 것에 그치지 않습니다.

시스템은 의사결정을 내리고 있습니다.

엔터프라이즈 인텔리전스 스택 (The Enterprise Intelligence Stack)

이 시리즈를 통해,

우리는 점진적으로 다음과 같은 구조의 아키텍처 (Architecture)를 구축했습니다.

Enterprise Documents

↓
...

모든 계층 (Layer)은 존재 이유가 있습니다.

어떤 계층이라도 제거하면 전체 시스템이 약화됩니다.

이 아키텍처는 금융을 넘어 확장성이 뛰어납니다.

휴먼 인 더 루프 AI (Human-in-the-Loop AI)

자율 시스템 (Autonomous systems)이 사람을 대체해서는 안 됩니다.

시스템은 반복적인 업무를 줄여주어야 합니다.

개발 과정에서 한 가지 교훈이 점점 더 명확해졌습니다.

모든 의사결정이 자동화될 가치가 있는 것은 아닙니다.

대신,

시스템은 업무를 분류해야 합니다.

높은 신뢰도 (High Confidence)
↓
자동 처리 (Automatic Processing)

중간 신뢰도 (Medium Confidence)
↓
인간 검증 (Human Validation)

낮은 신뢰도 (Low Confidence)
↓
수동 조사 (Manual Investigation)

이러한 접근 방식은 신뢰를 구축합니다.

엔터프라이즈 AI (Enterprise AI)는 인간이 일상적인 운영이 아닌 예외적인 사례 (Exceptional cases)에 대해 통제권을 유지할 때 성공합니다.

거대 언어 모델 (Large Language Models)의 역할

이 시리즈에서는 의도적으로 프롬프트 엔지니어링 (Prompt engineering)에 대해 논의하는 시간을 매우 적게 할애했습니다.

이는 우연이 아닙니다.

프롬프트 엔지니어링은 빈번하게 변합니다.

비즈니스 아키텍처 (Business architecture)는 그렇지 않습니다.

거대 언어 모델 (Large Language Models)은 아키텍처 내부의 또 다른 서비스가 되어야 합니다.

모델은 다음과 같은 작업을 보조할 수 있습니다:

• 설명 생성 (Explanation generation)
• 이상 징후 요약 (Anomaly summarization)
• 예외 분석 (Exception analysis)
• 권장 사항 생성 (Recommendation generation)
• 대화형 인터페이스 (Conversational interfaces)

모델이 결정론적 시스템 (Deterministic systems)을 대체해서는 안 됩니다.

대신,

모델은 이를 보완해야 합니다.

엔터프라이즈 자동화의 미래

매시간 수천 개의 운영 문서 (Operational documents)를 받는 기업을 상상해 보십시오.

송장 (Invoices).

이메일 (Emails).

계약서 (Contracts).

은행 명세서 (Bank statements).

구매 주문서 (Purchase orders).

컴플라이언스 보고서 (Compliance reports).

모든 것을 사람 운영자에게 전달하는 대신,

시스템은 다음과 같은 작업을 수행합니다:

이해 (Understanding).

분류 (Classification).

검증 (Validation).

의사결정 (Decision making).

에스컬레이션 (Escalation).

실행 (Execution).

인간의 개입은 신뢰도가 낮을 때만 발생합니다.

이것은 공상 과학(Science Fiction)이 아닙니다.

개별 기술들은 이미 존재합니다.

과제는 이 기술들을 일관된 아키텍처 (Architecture)로 조립하는 것입니다.

마지막 교훈 (Final Lessons)

이 프로젝트가 시작되었을 때,

목표는 비교적 단순했습니다.

금융 개체명 인식 (Financial Named Entity Recognition) 모델을 구축하는 것이었습니다.

시간이 흐르면서,

목표는 변했습니다.

이 프로젝트는 기업 시스템이 가공되지 않은 운영 데이터 (Raw Operational Data)를 어떻게 비즈니스 이해 (Business Understanding)로 변환하는지에 대한 탐구가 되었습니다.

가장 가치 있는 교훈은 또한 가장 단순했습니다.

인공지능 (Artificial Intelligence)은 단지 하나의 계층 (Layer)일 뿐입니다.

기업 지능 (Enterprise Intelligence)이 바로 그 시스템입니다.

향후 10년 동안 AI로 성공할 기업들이 반드시 가장 큰 언어 모델 (Language Models)을 보유하게 되는 것은 아닙니다.

그들은 자신들의 비즈니스에 대한 최선의 이해를 보유하게 될 것입니다.

결론 (Conclusion)

AI에 대한 흥분은 종종 모델 (Models)에 집중됩니다.

기업의 전환 (Enterprise Transformation)은 아키텍처 (Architecture)에 달려 있습니다.

표준 데이터 (Canonical Data).

비즈니스 분류 체계 (Business Taxonomies).

개체 해소 (Entity Resolution).

의사결정 지능 (Decision Intelligence).

신뢰할 수 있는 API (Reliable APIs).

설명 가능한 자동화 (Explainable Automation).

이것들이 자율 기업 시스템 (Autonomous Enterprise Systems)이 구축될 토대입니다.

트랜잭션 인텔리전스 (Transaction Intelligence)는 단지 하나의 구현 사례일 뿐입니다.

그 근간이 되는 아키텍처는 보편적입니다.

귀하의 조직이 송장 (Invoices), 보험 청구 (Insurance Claims), 법률 계약 (Legal Contracts), 물류 문서 (Logistics Documents), 또는 의료 기록 (Healthcare Records)을 처리하든 관계없이,

원칙은 동일합니다.

이해 (Understanding)가 자동화 (Automation)보다 앞섭니다.

지식 (Knowledge)이 에이전트 (Agents)보다 앞섭니다.

아키텍처 (Architecture)가 지능 (Intelligence)보다 앞섭니다.

시리즈 요약 (Series Recap)

파트 1

표준 데이터 계층 (Canonical Data Layer) 구축

↓

파트 2

합성 기업 데이터셋 (Synthetic Enterprise Datasets) 생성

↓

파트 3

금융 개체명 인식 (Financial Named Entity Recognition)

↓

파트 4

개체 해소 (Entity Resolution)

↓

파트 5

조정 엔진 (Reconciliation Engine)

↓

파트 6

트랜잭션 인텔리전스 API (Transaction Intelligence API)

↓

파트 7

기업 벤치마킹 (Enterprise Benchmarking)

↓

파트 8

자율 기업 AI (Autonomous Enterprise AI)

마지막 생각 (Final Thoughts)

이 시리즈 전체를 따라오셨다면, 여러분은 이미 프로덕션급 기업 AI (Enterprise AI) 시스템 뒤에 있는 모든 주요 빌딩 블록 (Building Blocks)을 확인하신 것입니다.

이 기사 전반에 걸쳐 보여준 구현은 다음을 포함하는 완전한 트랜잭션 인텔리전스 (Transaction Intelligence) 프로젝트를 기반으로 합니다:

• 합성 기업 데이터셋 (Synthetic enterprise datasets)
• MT950 생성기 (MT950 generators)
• 정형 변환 파이프라인 (Canonical transformation pipeline)
• 금융 NER (Financial NER) 학습 파이프라인
• Doccano 어노테이션 (Doccano annotations)
• 엔티티 해상도 엔진 (Entity Resolution engine)
• 대조 엔진 (Reconciliation engine)
• FastAPI 프로덕션 서비스 (FastAPI production service)
• 평가 프레임워크 (Evaluation framework)
• 엔드 투 엔드 아키텍처 문서화 (End-to-end architecture documentation)

전체 구현 내용은 **트랜잭션 인텔리전스 핸드북 (Transaction Intelligence Handbook)**의 일부로 제공되며, 여기에서는 모든 구성 요소가 프로덕션 준비가 된 예시, 아키텍처 다이어그램, 데이터셋 및 소스 코드와 함께 더욱 심도 있게 설명되어 있습니다.

만약 여러분이 단순한 AI 데모가 아닌 기업용 소프트웨어를 위한 AI를 구축하고 있다면, 이 시리즈가 단순히 언어만을 이해하는 것이 아니라 비즈니스를 이해하는 시스템을 설계하기 위한 실질적인 청사진을 제공하기를 바랍니다.

읽어주셔서 감사합니다.