Building Enterprise AI Automation Systems 시리즈의 Part 2

서론 (Introduction)

엔터프라이즈 AI (Enterprise AI)에서 가장 큰 장애물 중 하나는 모델을 선택하는 것이 아닙니다.

데이터를 찾는 것입니다.

대부분의 튜토리얼은 학습 데이터가 이미 존재한다고 가정합니다.

현실은 매우 다릅니다.

대규모 조직은 운영 데이터셋 (operational datasets)을 거의 공유하지 않습니다.

금융 거래에는 기밀 정보가 포함되어 있습니다.

계약서에는 민감한 합의 사항이 포함되어 있습니다.

송장 (Invoices)은 상업적 관계를 드러냅니다.

은행 거래 내역서는 고객 활동을 노출합니다.

법적, 규제적, 경쟁적 이유로 인해 이러한 데이터셋은 거의 공개되지 않습니다.

이는 AI 엔지니어들에게 어려운 문제를 야기합니다.

필요한 데이터에 접근할 수 없을 때 어떻게 지능형 시스템을 구축할 수 있을까요?

그 답은 합성 데이터 (synthetic data)입니다.

불행히도, 온라인에서 발견되는 대부분의 합성 데이터셋은 무작위로 생성된 CSV 파일에 불과합니다.

그것들은 이름, 숫자, 날짜를 포함하고 있습니다.

하지만 훨씬 더 중요한 무언가를 완전히 무시합니다:

비즈니스 관계 (Business relationships).

이 글에서는 실제 비즈니스 로직을 보존하며 머신러닝 (machine learning), 자동화 (automation), 벤치마킹 (benchmarking), 그리고 AI 엔지니어링 (AI engineering)에 사용할 수 있는 합성 엔터프라이즈 데이터셋을 설계하는 방법을 탐구할 것입니다.

무작위 데이터는 합성 데이터가 아니다 (Random Data Is Not Synthetic Data)

많은 개발자들은 합성 데이터가 단순히 가짜 값을 생성하는 것을 의미한다고 믿습니다.

예를 들어:

Customer,Invoice,Amount
John,INV001,500
Alice,INV002,1200
...

기술적으로 이것은 합성 데이터입니다.

실무적으로는 쓸모가 없습니다.

왜일까요?

엔터프라이즈 시스템은 관계를 중심으로 구축되기 때문입니다.

송장은 계약에 속합니다.

계약은 고객에게 속합니다.

결제는 송장을 참조합니다.

구매 주문서 (Purchase orders)는 송장을 승인합니다.

은행 거래는 송장을 결제합니다.

이러한 관계가 없다면 학습할 수 있는 의미 있는 것이 아무것도 없습니다.

고립된 레코드 (isolated records)로 학습된 머신러닝 모델은 고립된 패턴만을 학습합니다.

실제 엔터프라이즈 자동화에는 연결된 데이터가 필요합니다.

엔터프라이즈 시스템처럼 생각하기 (Thinking Like an Enterprise System)

Python 코드를 한 줄이라도 쓰기 전에, 한 가지 질문을 던지십시오:

"비즈니스는 실제로 어떻게 운영되는가?"

한 제조 기업을 상상해 보십시오.

고객이 계약을 체결합니다.

계약에는 다음 사항들이 정의됩니다:

• 제품 (products),
• 결제 일정 (payment schedules),
• 마일스톤 (milestones),
• 통화 (currencies),
• 가격 책정 (pricing).

계약으로부터 송장 (Invoices)이 생성됩니다.

구매 주문 (Purchase orders)은 조달을 승인합니다.

결국, 은행 거래 내역서 (bank statement)에 결제 내역이 나타납니다.

그 결제는 결코 독립적이지 않습니다.

그것은 항상 비즈니스 프로세스 (business process)에 속해 있습니다.

따라서 우리의 합성 데이터셋 (synthetic dataset)은 해당 프로세스를 보존해야 합니다.

데이터 모델 설계 (Designing the Data Model)

무작위 테이블을 생성하기보다는, 비즈니스 엔티티 (business entities)를 설계하는 것부터 시작하십시오.

이 프로젝트의 핵심 엔티티는 다음과 같았습니다:

Customer
        │
        ▼
...

이 계층 구조는 실제 엔터프라이즈 운영 (enterprise operations)을 반영합니다.

모든 엔티티는 부모로부터 컨텍스트 (context)를 상속받습니다.

고객 마스터 (Customer Master)

고객 마스터는 신뢰할 수 있는 단일 원천 (source of truth) 역할을 합니다.

예시:

{
  "customer_id":"CUS-00002",
  "legal_name":"ALPHABRIDGE SOLUTIONS",
...

고객 정보는 거의 변경되지 않습니다.

그 외의 모든 것은 고객을 참조합니다.

계약 마스터 (Contract Master)

계약은 상업적 관계를 설정합니다.

예시:

{
  "contract_id":"CNT-2024-587",
  "customer_id":"CUS-00002",
...

계약이 고객을 참조하고 있음에 주목하십시오.

고객 정보를 절대 중복해서 작성하지 마십시오.

식별자 (identifiers)를 사용하십시오.

송장 마스터 (Invoice Master)

송장은 계약으로부터 컨텍스트를 상속받습니다.

{
  "invoice_number":"MFG-INV-000157",
  "contract_id":"CNT-2024-587",
...

다시 한번 강조하지만, 값 (values)보다 관계 (relationships)가 더 중요합니다.

은행 거래 내역서 (Bank Statements)

고객, 계약, 송장이 존재한 후에야 거래 (transactions)가 생성되어야 합니다.

예시 내역 (narrative):

PART PMT ALPHABRIDGE SOLUTIONS MFG-INV-000157

내역이 기존의 비즈니스 엔티티를 참조하고 있음에 주목하십시오.

이것이 현실적인 합성 데이터 (synthetic data)와 무작위 텍스트 생성 (random text generation)의 차이점입니다.

관계가 중요한 이유 (Why Relationships Matter)

어떤 송장이 다음을 참조한다고 가정해 봅시다:

MFG-INV-000157

해당 송장은 항상 다음과 같이 연결되어야 합니다:

Customer
↓

...

그렇지 않다면:

• 개체 해상도 (Entity Resolution)를 평가할 수 없습니다.
• 대조 (Reconciliation)를 검증할 수 없습니다.
• 정답 (Ground truth)이 사라집니다.

합성 데이터는 참조 무결성 (referential integrity)을 보존해야 합니다.

정답 (Ground Truth) 구축하기

합성 데이터의 한 가지 장점은 완전한 통제권입니다.

생성된 모든 트랜잭션은 이미 다음 사항을 알고 있습니다:

• 어느 고객이 소유하고 있는지,
• 어느 계약 (contract)에 의해 생성되었는지,
• 어느 송장 (invoice)을 참조하는지,
• 부분 결제 (partial payment)인지 여부,
• 대조 (reconciliation)가 성공해야 하는지 여부.

이러한 숨겨진 지식이 정답 (ground truth)이 됩니다.

정답 (ground truth)은 벤치마킹 (benchmarking)을 가능하게 합니다.

다음과 같이 묻는 대신:

"모델이 성능을 잘 냈는가?"

우리는 다음과 같이 물을 수 있습니다:

"모델이 올바른 비즈니스 관계를 복구했는가?"

이것이 훨씬 더 강력한 평가 방식입니다.

실제 세계의 노이즈 (Real-World Noise) 시뮬레이션하기

실제 기업 데이터는 지저분합니다.

송장은 항상 일관되게 작성되지 않습니다.

예시:

INV-001
INV001
INV 001
...

고객 이름은 변합니다:

ALPHABRIDGE SOLUTIONS
ALPHABRIDGE LTD
ALPHA BRIDGE
...

합성 데이터셋은 의도적으로 이러한 가변성을 포함해야 합니다.

그렇지 않으면 모델은 현실적인 데이터 대신 완벽한 데이터만을 학습하게 됩니다.

목표는 데이터셋을 깨끗하게 만드는 것이 아닙니다.

목표는 데이터셋을 믿을 수 있게 만드는 것입니다.

개체 분포 (Entity Distribution)의 균형 맞추기

또 다른 흔한 실수는 불균형입니다.

다음과 같은 데이터셋을 상상해 보십시오:

송장 레이블 (Invoice Labels) : 50,000
계약 레이블 (Contract Labels) : 35
구매 주문서 (Purchase Orders) : 40

트랜스포머 (transformer) 모델은 자연스럽게 계약보다 송장을 더 잘 학습할 것입니다.

문제는 모델이 아닙니다.

데이터셋이 문제입니다.

균형 잡힌 개체 분포는 학습 품질을 향상시키고 더 신뢰할 수 있는 평가 지표를 생성합니다.

따라서 합성 생성은 양(volume)뿐만 아니라 다양성(diversity)도 제어해야 합니다.

왜 합성 데이터가 더 나은 AI를 가능하게 하는가

관계가 존재하기만 하면, 단일 합성 데이터셋이 여러 AI 작업을 지원할 수 있습니다.

예를 들어:

개체명 인식 (Named Entity Recognition)

추출:

• 고객 (Customer)
• 송장 (Invoice)
• 계약 (Contract)
• 구매 주문서 (Purchase Order)

개체 해상도 (Entity Resolution)

해결:

ALPHABRIDGE

↓
...

대조 (Reconciliation)

결제(payment)가 송장(invoice)을 올바르게 정산하는지 여부를 결정합니다.

에이전트 워크플로우 (Agentic Workflows)

다음과 같은 후속 조치를 트리거(trigger)합니다:

• 승인 (approve),
• 에스컬레이션 (escalate),
• 알림 (notify),
• 대조 (reconcile),
• ERP 업데이트 (update ERP).

동일한 데이터셋이 여러 머신러닝 (Machine Learning) 작업에서 재사용 가능해집니다.

교훈 (Lessons Learned)

수십만 개의 합성 엔터프라이즈 트랜잭션 (synthetic enterprise transactions)을 생성한 후, 한 가지 교훈이 명확해졌습니다.

단순한 양(Volume)만으로는 의미가 없습니다.

관계(Relationships)가 중요합니다.

비즈니스 로직 (Business logic)이 중요합니다.

그라운드 트루스 (Ground truth)가 중요합니다.

만약 당신의 합성 데이터셋이 실제 비즈니스처럼 동작한다면, 당신의 AI 시스템은 실제 비즈니스 문제를 해결하는 법을 배웁니다.

만약 당신의 합성 데이터셋이 무작위 CSV 파일처럼 동작한다면, 당신의 AI 시스템은 무작위성 (randomness)을 배웁니다.

결론 (Conclusion)

합성 데이터 (Synthetic data)는 지름길이 아닙니다.

그것은 하나의 엔지니어링 규율 (engineering discipline)입니다.

잘 설계된 합성 데이터셋은 비즈니스 로직 (business logic), 엔티티 관계 (entity relationships), 참조 무결성 (referential integrity), 그리고 현실적인 변동성 (realistic variability)을 보존합니다.

이러한 특성들은 머신러닝 (machine learning)뿐만 아니라 벤치마킹 (benchmarking), 소프트웨어 테스트 (software testing), API 검증 (API validation), 그리고 엔터프라이즈 자동화 (enterprise automation)에서도 가치를 발휘하게 합니다.

다음 기사에서는 이 합성 데이터셋을 사용하여 엔터프라이즈 은행 거래 내역을 이해하고 이를 구조화된 비즈니스 지식으로 변환할 수 있는 금융 개체명 인식 (Financial Named Entity Recognition, NER) 파이프라인을 구축할 것입니다.

다음 기사

Part 3 — Doccano와 IndoBERT를 사용한 금융 개체명 인식 파이프라인 구축

다음 내용을 다룹니다:

• 비즈니스 분류 체계 (business taxonomy) 설계
• 자동 사전 레이블링 (Automatic pre-labeling)
• 어노테이션 가이드라인 (Annotation guidelines)
• Doccano 워크플로우 (workflow)
• BIO 태깅 (BIO tagging)
• IndoBERT 파인튜닝 (Fine-tuning)
• 정밀도 (precision), 재현율 (recall), F1-score 평가
• 상도 (Entity resolution)를 위한 데이터 준비