엔터프라이즈 AI 시스템을 위한 정규 데이터 레이어(Canonical Data Layer) 구축

엔터프라이즈 AI 자동화 시스템 구축 시리즈의 파트 1

서론

매주 새로운 AI 프레임워크(Framework)가 등장합니다.

새로운 AI 에이전트(Agent) 아키텍처가 나타납니다.

새로운 자율 워크플로우(Autonomous workflow)가 기업 운영을 혁신할 것이라고 약속합니다.

하지만 AI를 둘러싼 열기에도 불구하고, 대부분의 엔터프라이즈 자동화 프로젝트는 의미 있는 운영 환경(Production) 도입에 이르지 못합니다.

흔한 가정은 이러한 프로젝트들이 모델의 한계 때문에 실패한다는 것입니다.

하지만 실제로 실패는 훨씬 더 일찍 발생합니다.

AI 시스템이 비즈니스에 대해 추론(Reasoning)하기 전에, 먼저 비즈니스를 이해해야 합니다.

그리고 이해가 가능해지기 전에, 데이터가 일관성(Consistent)을 가져야 합니다.

이 지점이 바로 대부분의 조직이 어려움을 겪는 곳입니다.

그들은 다음과 같은 분야에 막대한 투자를 합니다:

• 대규모 언어 모델 (Large Language Models)
• AI 에이전트 (AI Agents)
• 벡터 데이터베이스 (Vector Databases)
• 멀티 에이전트 프레임워크 (Multi-Agent Frameworks)
• 프롬프트 엔지니어링 (Prompt Engineering)

그러면서 스택(Stack)에서 가장 중요한 레이어를 간과합니다:

정규 데이터 레이어 (The Canonical Data Layer).

이 글에서는 왜 정규 데이터(Canonical data)가 중요한지, 이것이 어떻게 엔터프라이즈 자동화를 가능하게 하는지, 그리고 어떻게 대규모 AI 시스템을 지원할 수 있는 정규 아키텍처를 설계할 수 있는지 탐구할 것입니다.

진짜 문제는 AI가 아니다

대기업 내부의 재무 부서를 상상해 보십시오.

정보는 여러 시스템으로부터 들어옵니다:

ERP
CRM
Excel 파일
...

각 시스템은 비즈니스 정보를 서로 다르게 저장합니다.

다음과 같은 고객 이름을 생각해 보십시오:

ALPHABRIDGE SOLUTIONS

ERP에는 다음과 같이 저장될 수 있습니다:

ALPHABRIDGE SOLUTIONS

CRM에는 다음과 같이 저장될 수 있습니다:

ALPHABRIDGE LTD

계약 저장소에는 다음과 같이 포함될 수 있습니다:

ALPHA BRIDGE

은행 거래 내역에는 다음과 같이 참조될 수 있습니다:

ABS

인간은 이러한 기록들이 동일한 회사임을 즉시 인식합니다.

기계는 그렇지 못합니다.

표준화(Standardization) 없이는 자동화가 매우 어려워집니다.

이러한 과제는 어디에나 존재합니다:

• 재무 (Finance)
• 조달 (Procurement)
• 공급망 (Supply Chain)
• 보험 (Insurance)
• 통신 (Telecommunications)
• 제조 (Manufacturing)
• 의료 (Healthcare)

문제는 AI가 아닙니다.

문제는 파편화된 비즈니스 정보입니다.

정규 데이터(Canonical Data)란 무엇인가?

정규 데이터(Canonical data)는 비즈니스 정보의 표준화된 표현입니다.

이를 조직 내의 모든 시스템이 사용하는 공통 언어라고 생각하면 됩니다.

각 소스 시스템(Source system)이 자체적인 구조를 정의하도록 두는 대신, 정보가 다운스트림(Downstream) 프로세스에 진입하기 전에 일관된 형식으로 변환됩니다.

예시:

원시 ERP 레코드 (Raw ERP Record)

{
  "cust_name": "ALPHABRIDGE LTD",
  "inv_num": "INV001"
...

원시 CRM 레코드 (Raw CRM Record)

{
  "customer": "ALPHA BRIDGE",
  "invoice": "INV-001"
...

정규 표현 (Canonical Representation)

{
  "customer_name": "ALPHABRIDGE SOLUTIONS",
  "invoice_number": "INV-001"
...

원래의 소스(Source)가 무엇이든 관계없이, 모든 다운스트림 시스템은 동일한 구조를 전달받습니다.

이는 분석(Analytics), 자동화(Automation), 머신러닝 (Machine Learning), 그리고 AI 워크플로우를 극적으로 단순화합니다.

AI 시스템이 정규 데이터에 의존하는 이유

많은 AI 프로젝트가 언어 모델(Language models)을 운영 시스템(Operational systems)에 직접 연결하려고 시도합니다.

그 결과는 대개 취약한 자동화로 이어집니다.

다음과 같은 거래 내역(Transaction narrative)을 고려해 보십시오:

PART PMT ALPHABRIDGE SOLUTIONS MFG-INV-000157

언어 모델은 이 문장을 이해할 수 있을 것입니다.

하지만 엔터프라이즈 자동화(Enterprise automation)에는 다음과 같은 이해가 필요합니다:

• 어떤 고객이 결제를 했는가?
• 어떤 송장(Invoice)이 정산되고 있는가?
• 어떤 계약(Contract)이 해당 거래를 규정하는가?
• 결제가 부분 결제인가?
• 결제 금액이 정확한가?

이러한 질문들은 구조화된 비즈니스 컨텍스트(Business context)를 요구합니다.

정규 데이터는 바로 그 컨텍스트를 제공합니다.

정규 변환(Canonical transformation)이 없다면, AI 시스템은 동일한 해석 문제를 반복해서 해결해야 합니다.

정규 변환이 있다면, AI 시스템은 표준화된 비즈니스 엔티티(Business entities)를 기반으로 작동합니다.

정규 데이터 모델(Canonical Data Model) 설계하기

흔히 하는 실수는 데이터베이스(Database)를 중심으로 정규 모델을 설계하는 것입니다.

더 나은 접근 방식은 비즈니스 개념(Business concepts)을 중심으로 설계하는 것입니다.

예시:

고객 (Customer)

{
  "customer_id": "",
  "legal_name": "",
...

계약 (Contract)

{
  "contract_id": "",
  "customer_id": "",
...

송장 (Invoice)

{
  "invoice_number": "",
  "contract_id": "",
...

트랜잭션 (Transaction)

{
  "transaction_id": "",
  "amount": "",
...

이러한 엔티티(Entity)들은 비즈니스 이해를 위한 구성 요소가 됩니다.

MT950을 사용한 실무 사례

최근 제가 진행했던 프로젝트 중 하나는 기업용 은행 명세서(Bank Statements)와 관련된 것이었습니다.

유입되는 트랜잭션(Transaction)은 SWIFT MT950 형식으로 들어왔습니다.

트랜잭션 내역(Narrative)은 다음과 같은 형태일 수 있습니다:

PART PMT ALPHABRIDGE SOLUTIONS MFG-INV-000157

첫 번째 단계는 원시 트랜잭션(Raw Transaction)을 정규 구조(Canonical Structure)로 변환하는 것이었습니다.

원시 트랜잭션 (Raw Transaction)

{
  "narrative": "PART PMT ALPHABRIDGE SOLUTIONS MFG-INV-000157"
}

정규 트랜잭션 (Canonical Transaction)

{
  "transaction_id": "TXN-00001",
  "payment_type": "PARTIAL_PAYMENT",
...

표준화가 완료되면 트랜잭션을 처리하기가 훨씬 쉬워집니다.

개체명 인식 (Named Entity Recognition, NER)을 통해 비즈니스 엔티티(Business Entities)를 식별할 수 있습니다.

엔티티 해소 (Entity Resolution)를 통해 이를 마스터 레코드(Master Records)와 매칭할 수 있습니다.

대조 엔진 (Reconciliation Engines)은 결제 관계를 검증할 수 있습니다.

이 모든 것은 정규 레이어(Canonical Layer)가 존재하기 때문에 가능합니다.

정규 아키텍처 (Canonical Architecture)

전형적인 엔터프라이즈 아키텍처는 다음과 같은 모습일 것입니다:

Raw Data Sources
        │
        ├── ERP
...

AI가 어디에 나타나는지 주목하십시오.

끝부분에 나타납니다.

시작 부분이 아닙니다.

이것은 엔터프라이즈 AI에서 가장 중요한 교훈 중 하나입니다.

흔한 실수들

조직들은 빈번하게 다음과 같은 실수를 저지릅니다:

실수 #1: 에이전트(Agents)부터 구축하기

많은 팀이 즉시 AI 에이전트를 구축하기 시작합니다.

정규 데이터(Canonical Data) 없이는 에이전트가 일관되지 않은 정보로 작동하게 됩니다.

그 결과는 신뢰할 수 없는 자동화입니다.

실수 #2: 모든 시스템을 다르게 취급하기

모든 소스 시스템은 각자의 스키마(Schema)를 도입합니다.

표준화가 없다면 통합 복잡도는 기하급수적으로 증가합니다.

실수 #3: 비즈니스 엔티티(Business Entities) 무시하기

문서(Documents)는 비즈니스 객체(Business Objects)가 아닙니다.

송장(Invoices), 계약(Contracts), 고객(Customers), 그리고 트랜잭션(Transactions)이 바로 비즈니스 객체입니다.

정규 모델(Canonical models)은 문서 구조(document structures)보다는 비즈니스 엔티티(business entities)에 집중해야 합니다.

정규 데이터(Canonical Data)의 이점

잘 설계된 정규 레이어(canonical layer)는 다음과 같은 이점을 제공합니다:

더 단순한 통합 (Simpler Integrations)

모든 시스템이 동일한 언어로 소통합니다.

더 나은 분석 (Better Analytics)

일관된 보고(reporting)가 가능해집니다.

더 신뢰할 수 있는 AI (More Reliable AI)

모델이 구조화된 비즈니스 정보 위에서 작동합니다.

더 쉬운 자동화 (Easier Automation)

비즈니스 규칙(business rules)이 단순해집니다.

확장 가능한 아키텍처 (Scalable Architecture)

다운스트림 워크플로(downstream workflows)를 재설계하지 않고도 새로운 시스템을 통합할 수 있습니다.

교훈 (Lessons Learned)

트랜잭션 인텔리전스(transaction intelligence) 시스템, 대조 엔진(reconciliation engines), 그리고 엔터프라이즈 자동화 워크플로를 구축한 후, 한 가지 교훈이 명확해졌습니다:

가장 어려운 부분은 AI가 아닙니다.

가장 어려운 부분은 비즈니스 정보에 대한 공유된 이해(shared understanding)를 만드는 것입니다.

정규 데이터(Canonical data)가 바로 그 이해를 제공합니다.

정규 데이터는 파편화된 기록들을 현실에 대한 일관된 표현(consistent representation)으로 변환합니다.

그리고 그러한 표현이 없다면, AI 모델이 아무리 정교하더라도 자동화는 취약해질 수밖에 없습니다.

결론 (Conclusion)

대부분의 엔터프라이즈 AI 논의는 모델(models)에 집중합니다.

하지만 실제로는, 성공적인 자동화는 데이터 기반(data foundations)에 훨씬 더 많이 의존합니다.

에이전트(agents)를 구축하기 전에, 이해(understanding)를 구축하십시오.

지능(intelligence)을 배포하기 전에, 정보를 표준화(standardize)하십시오.

의사결정을 자동화하기 전에, 비즈니스에 대한 정규 표현(canonical representation)을 확립하십시오.

AI 시스템은 자신의 데이터조차 이해하지 못하는 조직을 이해할 수 없기 때문입니다.

다음 아티클

파트 2에서는 AI 학습을 위한 대규모 합성 엔터프라이즈 데이터셋(synthetic enterprise datasets)을 생성하는 방법을 탐구하며, 다음 내용을 포함합니다:

• 고객 마스터 데이터 (Customer Master Data)
• 계약 데이터 (Contract Data)
• 인보이스 데이터 (Invoice Data)
• MT950 은행 명세서 (MT950 Bank Statements)
• 그라운드 트루스 관계 (Ground Truth Relationships)

또한 왜 합성 데이터(synthetic data)가 현대 엔터프라이즈 AI 엔지니어링에서 가장 중요한 도구 중 하나가 되었는지 알아봅니다.