당신의 분류 체계(Taxonomy)는 이해합니다.

매주 새로운 AI 에이전트 (AI Agent) 프레임워크가 등장합니다.

어느 주는 LangGraph가 등장하고,

다음 주는 CrewAI가 등장합니다.

그다음은 AutoGen,

그다음은 OpenAI Agents,

그다음은 Model Context Protocol입니다.

생태계가 믿을 수 없을 정도로 빠르게 움직이고 있습니다.

자연스럽게 기업들은 똑같은 질문을 던집니다.

"우리 비즈니스를 위한 AI 에이전트를 구축할 수 있을까요?"

대답은 대개 '예'입니다.

하지만 저는 이것이 잘못된 질문이라고 생각합니다.

더 나은 질문은 다음과 같아야 합니다:

당신의 비즈니스에는 AI가 실제로 이해할 수 있는 언어가 있습니까?

왜냐하면 바로 그 지점에서 대부분의 엔터프라이즈 AI 프로젝트가 조용히 실패하기 때문입니다.

모든 비즈니스는 자신만의 언어를 가지고 있습니다

어떤 기업이든 들어가서 주의 깊게 들어보십시오.

사람들은 일반적인 영어를 사용하지 않습니다.

그들은 비즈니스의 언어를 사용합니다.

재무(Finance) 팀은 다음과 같은 것들에 대해 이야기합니다:

• 송장 (invoices)
• 구매 주문서 (purchase orders)
• 신용 전표 (credit notes)
• 계약서 (contracts)
• 대조/조정 (reconciliation)

제조(Manufacturing) 팀은 다음과 같은 것들에 대해 이야기합니다:

• 작업 지시서 (work orders)
• 생산 배치 (production batches)
• 자재 이동 (material movements)
• BOMs (Bill of Materials)
• 품질 검사 (quality inspections)

의료(Healthcare) 팀은 다음과 같은 것들을 논의합니다:

• 진료/접촉 (encounters)
• 진단 (diagnoses)
• 보험 청구 (insurance claims)
• 제공자 (providers)
• 의뢰 (referrals)

모든 산업에는 고유한 어휘가 있습니다.

인간은 시간이 지나면서 이를 학습합니다.

AI는 그렇지 않습니다.

문제는 지능이 아닙니다

AI 에이전트가 다음과 같은 메시지를 받는다고 가정해 봅시다.

PART PMT ALPHABRIDGE SOLUTIONS MFG-INV-000157

에이전트가 다음 질문에 답할 수 있을까요?

이 송장이 지급되었습니까?

즉시 답할 수 없습니다.

왜냐하면 에이전트는 다음을 알지 못하기 때문입니다:

"PART PMT"가 무엇인가?

"MFG"는 무엇인가?

"ALPHABRIDGE"는 고객인가?

공급업체인가?

파트너인가?

자회사인가?

이 송장은 무엇에 속하는가?

모델은 언어를 이해합니다.

하지만 당신의 회사를 이해하지는 못합니다.

이것이 분류 체계(Taxonomy)가 중요한 이유입니다

분류 체계(Taxonomy)는 단순히 라벨의 목록이 아닙니다.

그것은 당신의 비즈니스가 세상을 설명하는 방식에 대한 공유된 정의입니다.

모든 문서를 일반 텍스트로 취급하는 대신, 분류 체계는 의미에 구조를 부여합니다.

예를 들어:

PAYMENT_TYPE (결제 유형)

↓
...

CUSTOMER (고객)

↓
...

DOCUMENT (문서)

↓
...

STATUS (상태)

↓
...

갑자기 시스템은 더 이상 텍스트를 읽는 것이 아니게 됩니다.

비즈니스 개념을 해석하는 것입니다.

AI는 프롬프트가 필요하기 전에 정의(Definition)가 필요합니다

기업용 트랜잭션 인텔리전스 (Transaction Intelligence) 플랫폼을 구축하면서 한 가지 놀라운 사실을 발견했습니다.

프롬프트 엔지니어링 (Prompt engineering)이 가장 어려운 부분은 아니었습니다.

비즈니스 어휘 (Business vocabulary)를 구축하는 것이 가장 어려웠습니다.

단 하나의 모델을 학습시키기 전에, 우리는 다음과 같은 것들을 정의하는 데 시간을 보냈습니다:

• 고객 엔티티 (Customer entities)
• 인보이스 구조 (Invoice structures)
• 결제 유형 (Payment types)
• 대조 상태 (Reconciliation states)
• 계약 관계 (Contract relationships)
• 문서 카테고리 (Document categories)

그제서야 모델은 신뢰할 수 있는 결과를 생성할 수 있었습니다.

공유된 정의가 없다면, 모든 예측은 모호해집니다.

분류 체계 (Taxonomy)가 일관성을 만듭니다

열 명의 개발자가 서로 다른 열 개의 서비스를 구축한다고 상상해 보십시오.

분류 체계 (Taxonomy)가 없다면:

한 서비스는 이를 다음과 같이 부릅니다:

Invoice

다른 서비스는 다음과 같이 말합니다:

Billing Document

또 다른 서비스는 다음과 같이 사용합니다:

Reference

누군가는 다음과 같이 저장합니다:

Invoice ID

결국 모든 API가 서로 다른 언어로 말하기 시작합니다.

이제 AI 에이전트 (AI agent)를 도입한다고 상상해 보십시오.

에이전트는 어떤 용어를 신뢰해야 할까요?

분류 체계는 기업용 AI의 토대입니다

잘 설계된 분류 체계 (Taxonomy)는 인간, 소프트웨어, 그리고 AI 사이의 계약이 됩니다.

모든 것이 동일한 언어로 소통합니다.

문서 (Documents).

데이터베이스 (Databases).

API.

모델 (Models).

대시보드 (Dashboards).

에이전트 (Agents).

이러한 일관성은 조직 전체의 모호성을 극적으로 줄여줍니다.

이것은 머신러닝 (Machine Learning)보다 더 큰 문제입니다

많은 엔지니어들이 분류 체계 (Taxonomy)를 자연어 처리 (NLP)와 연관 짓습니다.

실제로 이는 소프트웨어 엔지니어링의 거의 모든 부분에 영향을 미칩니다.

데이터베이스 설계 (Database design).

API 계약 (API contracts).

검색 (Search).

분석 (Analytics).

데이터 웨어하우스 (Data warehouses).

지식 그래프 (Knowledge graphs).

피처 스토어 (Feature stores).

머신러닝 파이프라인 (Machine learning pipelines).

심지어 관측 가능성 (Observability)까지.

비즈니스 어휘 (Business vocabulary)가 표준화되면, 모든 다운스트림 시스템 (Downstream system)을 구축하기가 더 쉬워집니다.

AI 에이전트는 지능뿐만 아니라 컨텍스트 (Context)가 필요합니다

제가 자주 보는 오해 중 하나는 더 나은 모델이 자동으로 더 나은 기업용 에이전트를 만들어낼 것이라는 생각입니다.

실제로 에이전트가 실패하는 이유는 훨씬 더 단순합니다.

충분한 컨텍스트 (Context)가 없기 때문입니다.

컨텍스트는 거대언어모델 (LLM) 내부에서 마법처럼 나타나지 않습니다.

그것은 구조화된 지식 (Structured knowledge)에서 나옵니다.

고객 마스터 (Customer masters).

계약 관계 (Contract relationships).

비즈니스 규칙 (Business rules).

분류 체계 (Taxonomies).

표준 데이터 모델 (Canonical data models).

그것이 기업의 진정한 메모리 (Memory)입니다.

우리는 더 똑똑한 에이전트를 먼저 필요로 하지 않습니다

우리는 더 똑똑한 데이터가 필요합니다

기업용 AI (Enterprise AI)의 다음 돌파구는 아마도 또 다른 프롬프트 (Prompt)에서 오지 않을 것입니다.

또는 또 다른 프레임워크 (Framework)에서도.

또는 또 다른 모델 (Model)에서도 아닐 것입니다.

그것은 마침내 자신들의 비즈니스 지식을 기계가 추론 (Reasoning)할 수 있는 무언가로 정리하는 조직으로부터 올 것입니다.

그것은 분류 체계 (Taxonomy)에서 시작됩니다.

나의 가장 큰 교훈

기업용 AI를 구축하는 것은 소프트웨어에 대한 나의 생각을 바꾸어 놓았습니다.

처음에 나는 언어 모델 (Language model)이 아키텍처 (Architecture)의 중심이 될 것이라고 믿었습니다.

시간이 흐르면서 나는 다른 것을 깨달았습니다.

중심은 모델이 아니었습니다.

그것은 비즈니스 어휘 (Business vocabulary)였습니다.

모델은 단지 그것을 소비할 뿐이었습니다.

우리의 분류 체계 (Taxonomy)가 더 좋아질수록...

모든 다운스트림 시스템 (Downstream system)은 더 신뢰할 수 있게 되었습니다.

마치며

인공지능 (Artificial Intelligence)은 언어를 생성하는 데 믿을 수 없을 정도로 뛰어납니다.

하지만 기업용 소프트웨어 (Enterprise software)는 언어 위에 구축되지 않습니다.

그것은 의미 (Meaning) 위에 구축됩니다.

의미는 공유된 정의 (Shared definitions)에서 나옵니다.

공유된 정의는 분류 체계 (Taxonomy)가 됩니다.

분류 체계는 지식 (Knowledge)이 됩니다.

지식은 자동화 (Automation)가 됩니다.

그리고 나서야 비로소 AI 에이전트 (AI agents)가 진정으로 유용해집니다.

어쩌면 우리가 던져야 할 다음 질문은 이것이 아닐지도 모릅니다:

"어떤 AI 모델을 사용해야 할까요?"

어쩌면 이것일지도 모릅니다:

"우리 비즈니스에는 AI가 실제로 이해할 수 있는 언어가 있는가?"

그 질문은 내가 소프트웨어를 구축하는 방식을 바꾸어 놓았습니다.

나는 이 질문이 향후 10년 동안 기업용 AI를 변화시킬 것이라고 확신합니다.

리소스 (Resources)

이 기사의 아이디어는 대규모 비즈니스 대조 (Business reconciliation)를 위해 설계된 완전한 **기업용 AI 트랜잭션 인텔리전스 시스템 (Enterprise AI Transaction Intelligence System)**을 구축하는 과정에서 나왔습니다.

전체 구현 범위는 다음과 같습니다:

• 정형 데이터 아키텍처 (Canonical Data Architecture)
• 비즈니스 분류 체계 설계 (Business Taxonomy Design)
• 합성 엔터프라이즈 데이터셋 엔지니어링 (Synthetic Enterprise Dataset Engineering)
• 금융 개체명 인식 (Financial Named Entity Recognition (NER))
• 개체 식별 (Entity Resolution)
• 비즈니스 규칙 (Business Rules)
• 자동 대조 (Automated Reconciliation)
• FastAPI 프로덕션 API (FastAPI Production APIs)
• 엔드 투 엔드 평가 프레임워크 (End-to-End Evaluation Framework)

아키텍처, 소스 코드, 데이터셋 및 구현 내용을 심도 있게 살펴보고 싶다면, 여기에서 모든 내용을 확인하실 수 있습니다:

📘 Enterprise AI Automation Blueprint

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

또한 저는 Dev.to를 통해 엔터프라이즈 AI 엔지니어링 (Enterprise AI Engineering), AI 자동화 (AI Automation), 소프트웨어 아키텍처 (Software Architecture), 그리고 프로덕션 시스템 (Production Systems)에 관한 시리즈를 지속적으로 연재하고 있습니다.

단순한 데모가 아닌 실제 비즈니스를 위한 AI를 구축하고 계신다면, 이 여정에 함께하시길 바랍니다.