기업용 생성형 AI를 구축할 때 가장 먼저 떠올리는 구조는 대부분 비슷합니다.
사용자 질문
↓
문서 검색
↓
Vector DB
↓
관련 문서
↓
LLM
↓
답변
전형적인 RAG(Retrieval-Augmented Generation) 구조입니다.
사내 규정, 매뉴얼, 기술 문서처럼 문서에 존재하는 정보를 찾아 답변하는 용도라면 이 구조만으로도 상당히 좋은 결과를 만들 수 있습니다.
그런데 실제 기업 업무와 AI를 연결하다 보면 어느 순간 문제가 달라집니다.
사용자는 단순히 "관련 문서를 찾아줘"라고만 묻지 않기 때문입니다.
예를 들어 이런 질문이 들어옵니다.
"이 Booking의 도착 일정이 변경되면 어떤 업무에 영향이 있어?"
이 질문에 답하려면 Vector DB에서 비슷한 문서를 몇 개 찾는 것만으로는 부족합니다.
Booking과 연결된 Voyage를 찾아야 하고, Customer와 Contract를 확인해야 할 수도 있으며, Invoice에 미치는 영향을 계산해야 할 수도 있습니다.
그리고 일부 정보는 문서가 아니라 현재 운영 시스템의 API에서 가져와야 합니다.
여기서부터 문제는 단순한 검색이 아니라 Business Context를 구성하는 문제로 바뀝니다.
1. RAG가 잘하는 것과 못하는 것
먼저 RAG가 부족하다는 의미는 아닙니다.
RAG는 Enterprise AI에서 여전히 매우 중요한 구성 요소입니다.
다만 잘하는 일이 명확합니다.
RAG의 핵심 질문은 "이 질문과 관련된 정보가 어디에 있는가?"입니다.
예를 들어 다음 질문에는 RAG가 매우 효과적입니다.
- 이 업무의 처리 절차가 어떻게 되나요?
- 계약 변경 관련 규정을 찾아줘.
- 제품 설치 매뉴얼에서 네트워크 설정 방법을 알려줘.
- 사내 보안 규정에서 비밀번호 정책을 찾아줘.
모두 문서 안에 답이 존재하는 문제입니다.
하지만 다음 질문은 성격이 다릅니다.
- 이 Booking과 연결된 Invoice는 무엇인가?
- 도착일 변경이 Finance 업무에 영향을 주는가?
- 이 Customer의 현재 계약 상태는 무엇인가?
- 이 변경을 실행하려면 누구의 승인이 필요한가?
- 승인되면 실제 시스템에서 변경을 수행할 수 있는가?
여기서는 문서 검색만으로 충분하지 않습니다.
2. 실제 업무는 문서가 아니라 '연결'되어 있다
기업 업무를 들여다보면 정보가 독립적으로 존재하지 않습니다.
하나의 업무 객체가 다른 업무 객체와 연결되어 있습니다.
Customer
│
▼
Contract
│
▼
Booking ───── Voyage
│
├──── Shipment
│
└──── Invoice
│
▼
Finance
예를 들어 Booking 하나를 이해하기 위해서도 Customer, Contract, Voyage, Shipment, Invoice 등의 관계를 함께 알아야 할 수 있습니다.
그래서 저는 Enterprise AI를 설계할 때 Business Object라는 관점이 중요하다고 생각합니다.
문서가 정보의 중심이 아니라 실제 업무 객체를 중심으로 필요한 정보를 연결하는 것입니다.
3. Vector DB와 Graph DB의 역할은 다르다
이 문제를 해결하기 위해 Vector DB를 Graph DB로 교체하면 될까요?
그것도 아닙니다.
두 기술은 해결하려는 문제가 다릅니다.
구성 요소주요 질문
| Vector DB | 어떤 정보가 의미적으로 관련되어 있는가? |
| Graph DB | 어떤 객체가 서로 연결되어 있는가? |
| Reranker | 찾아온 후보 중 무엇이 현재 질문에 더 중요한가? |
| API | 현재 실제 상태는 무엇인가? |
그래서 저는 이들을 경쟁 기술로 보기보다 서로 다른 역할을 담당하는 구성 요소로 보는 편이 맞다고 생각합니다.
Vector
→ 관련 정보
Graph
→ 관계
Reranker
→ 우선순위
API
→ 현재 상태
그리고 이들을 업무 관점에서 묶어주는 계층이 필요합니다.
그것을 여기서는 Business Layer라고 부르겠습니다.
4. Business Layer란 무엇인가?
Business Layer는 특정 제품 하나를 의미하는 것이 아닙니다.
Enterprise AI가 실제 업무를 이해할 수 있도록 업무 객체, 관계, 규칙, 상태와 실행 가능한 Action을 연결하는 논리적 계층으로 볼 수 있습니다.
예를 들어 다음과 같은 정보를 관리할 수 있습니다.
- Business Objects
- Object Relationships
- Business Rules
- Policies
- Current State
- Available Actions
중요한 것은 마지막의 Available Actions입니다.
AI가 정보를 이해하는 것과 실제 업무를 수행하는 것은 다른 문제이기 때문입니다.
5. Knowledge에서 Action으로
기존 RAG 시스템은 대부분 Knowledge에서 끝납니다.
Question
↓
Knowledge
↓
Answer
Agentic AI에서는 한 단계 더 나아갑니다.
Question
↓
Intent
↓
Business Object
↓
Knowledge + Current State
↓
Reasoning
↓
Available Action
↓
Execution
예를 들어 사용자가 다음과 같이 요청했다고 가정해 보겠습니다.
"이 Booking의 도착일 변경 영향을 분석하고 문제가 없으면 변경해줘."
시스템은 단순히 답변을 생성해서는 안 됩니다.
Booking을 식별하고 관련 객체를 찾아야 합니다.
필요한 규정은 RAG에서 찾고, 현재 일정과 상태는 API에서 조회할 수 있습니다.
그 결과를 분석한 뒤 실제 변경 가능 여부를 판단해야 합니다.
6. API, ChatFlow, n8n은 어디에 들어갈까?
Business Layer가 중요한 이유가 여기서 더 분명해집니다.
모든 Action을 동일한 방식으로 실행할 필요가 없습니다.
예를 들어 다음처럼 역할을 나눌 수 있습니다.
Business Object
│
▼
Available Actions
│
├── 조회 ─────────→ API
│
├── AI 분석 ──────→ ChatFlow / Agent
│
├── 업무 프로세스 ─→ n8n / Workflow
│
└── 변경 ─────────→ Enterprise API
예를 들어 단순 상태 조회는 API를 직접 호출하면 됩니다.
복잡한 영향 분석은 별도의 ChatFlow나 Agent가 담당할 수 있습니다.
여러 시스템을 순차적으로 호출하거나 알림·승인이 필요한 업무는 n8n과 같은 Workflow Automation이 더 적합할 수 있습니다.
즉, LLM이 모든 것을 처리하는 구조가 아닙니다.
LLM은 Business Layer가 제공하는 Context와 Action을 이용해 판단하는 하나의 구성 요소가 됩니다.
7. 제가 중요하게 보는 구조
실제 Enterprise AI를 고민하면서 저는 다음과 같은 구조가 점점 중요해진다고 보고 있습니다.
User
│
▼
AI Agent
│
▼
Business Layer
│
┌───────────┼───────────┐
│ │ │
▼ ▼ ▼
Business Business Business
Objects Rules Actions
│ │
▼ ▼
Knowledge Execution
│ │
┌─────┼─────┐ ┌──────┼──────┐
▼ ▼ ▼ ▼ ▼ ▼
RAG Graph API API ChatFlow n8n'IT 세상 > AI' 카테고리의 다른 글
| AI가 내 일자리를 뺏을까? 진짜 위기인 사람들의 공통점 (0) | 2026.01.16 |
|---|---|
| [긴급 뉴스] "엄마, 나 사고 쳤어" 아들 목소리인데 가짜? 'AI 목소리 사기' 대처법 (4) | 2026.01.06 |
| AI는 마법이 아닙니다: 모든 전문가가 알아야 할 7가지 AI 패턴 (6) | 2025.11.26 |
| "AI 전문가, 로봇 박사인가요?" 쉽게 풀이한 AI 이야기 (0) | 2025.11.20 |
| 🚀 2025 Google I/O 총정리: Gemini 2.5 Pro, Search AI Mode, 그리고 AI 하드웨어 생태계의 확장 (4) | 2025.05.30 |
