Document AI와 Workflow AI는 별개의 제품이 아니다. 하나의 데이터 파이프라인을 구성하는 두 개의 레이어이며, 이 연결이 REINDEERS 거래까지 이어진다. 이 글에서는 두 서비스가 왜 분리되어 있는지, 어떻게 이벤트 기반으로 연결되는지, 실제 B2B 시나리오에서 어떻게 동작하는지, 그리고 사람은 결정, AI Agent는 실제 업무 실행이라는 원칙이 이 구조 위에서 어떻게 현실화되는지를 다룬다.
두 서비스는 왜 따로 존재하는가
Document AI와 Workflow AI를 처음 접하면 자연스럽게 드는 질문이 있다. "왜 두 개인가? 하나로 합치면 안 되는가?" 이 질문은 합리적이지만, 두 서비스가 분리되어 있는 데는 명확한 이유가 있다. 문서 생산(content generation)과 업무 실행(process execution)은 근본적으로 다른 문제이기 때문이다.
| 구분 | Document AI | Workflow AI |
|---|---|---|
| 역할 | 정보를 정리하고 문서를 생성 | 업무를 정의하고 자동 실행 |
| 입력 | 사용자 데이터, 거래 이력, 템플릿 | 이벤트(Event), 조건(Condition), 트리거(Trigger) |
| 출력 | 제안서, 견적서, 기술문서, 리포트 | 승인, 알림, 데이터 동기화, API 호출 |
| AI 활용 방식 | RAG 기반 텍스트 생성 + 포맷팅 | 조건 분기 판단 + 실행 순서 최적화 |
Document AI는 "무엇을 만들 것인가"에 집중한다. 사용자가 입력한 정보와 플랫폼에 축적된 거래 데이터를 조합하여, 비즈니스에 필요한 문서를 생성한다. 견적서, 제안서, 기술 문서, IR 자료 등 B2B 업무에서 반복적으로 필요한 문서를 AI가 생성하되, 실제 거래 데이터에 기반한 정확한 컨텍스트를 포함시킨다.
Workflow AI는 "어떻게 실행할 것인가"에 집중한다. 이벤트가 발생하면 미리 정의된 규칙에 따라 다음 업무를 자동 실행한다. 승인 요청을 보내고, 다음 단계 담당자에게 알리고, 외부 시스템에 API를 호출하고, 조건에 따라 분기한다. 문서가 만들어지는 것과 그 문서로 무언가를 하는 것은 완전히 다른 영역이다.
- 단일 책임 원칙 -- 각 서비스가 하나의 문제만 해결하면 복잡도가 선형적으로 증가한다
- 독립 배포 -- Document AI의 모델 업데이트가 Workflow AI의 실행 엔진에 영향을 주지 않는다
- 독립 확장 -- 문서 생성 트래픽과 워크플로우 실행 트래픽은 패턴이 다르다
- 이벤트 기반 결합 -- 느슨한 결합(loose coupling)으로 연결되어 각 서비스가 독립적으로 진화할 수 있다
그러나 분리는 격리가 아니다. 두 서비스는 이벤트로 연결되어 있으며, 이 연결이 전체 파이프라인을 완성한다. Document AI에서 문서가 생성되면 그것은 단순히 파일이 만들어지는 것이 아니라, Workflow AI가 후속 업무를 시작하는 신호가 된다.
연결 구조: 이벤트 기반 파이프라인
Document AI와 Workflow AI는 MQ(Message Queue)를 통한 이벤트 기반 아키텍처로 연결하는 구조로 설계했다. Document AI에서 문서가 생성되면 document.created 이벤트가 MQ에 발행(publish)되고, Workflow AI가 이를 구독(subscribe)하여 후속 프로세스를 실행한다.
[Document AI]
사용자가 견적서 생성 요청
-> AI가 거래 데이터 기반으로 문서 생성
-> document.created 이벤트 발행 -> MQ
[Message Queue]
topic: document.created
payload: { documentId, type, metadata }
-> 구독자(Workflow AI)에게 비동기 전달
[Workflow AI]
이벤트 수신 -> 트리거 조건 확인
-> 매칭되는 워크플로우 실행
-> 내부 승인 -> 고객 발송 -> 거래 등록
-> 실행 결과 이벤트 발행 -> MQ
이 구조의 핵심은 이벤트가 단방향이 아니라 양방향으로 순환한다는 점이다. Document AI가 이벤트를 발행하면 Workflow AI가 처리하고, Workflow AI의 실행 결과가 다시 이벤트로 발행되어 Document AI나 REINDEERS의 트리거가 된다. 이것이 단순한 "연동"과 "파이프라인"의 차이다.
실제로 이 연결이 동작하는 대표적인 흐름 세 가지를 살펴보자.
Flow A: 제안서 -> 승인 -> 발송 -- Document AI에서 제안서 생성 -> document.created 이벤트 발행 -> Workflow AI가 내부 승인 워크플로우 시작 -> 팀장 승인 -> 임원 승인 -> 승인 완료 후 고객에게 자동 발송되도록 설계했다 -> document.shared 이벤트 발행
Flow B: 견적서 -> 검증 -> 거래 등록 -- Document AI에서 견적서 초안 생성 -> Workflow AI가 가격 검증 워크플로우 시작 -> 과거 거래가 대비 이상치 검사 -> 검증 통과 시 REINDEERS 거래가 자동 등록될 예정이다 -> order.created 이벤트 발행
Flow C: 기술문서 -> 번역 -> 다국어 배포 -- Document AI에서 기술문서 생성 -> Workflow AI가 번역 워크플로우 시작 -> 대상 언어별 AI 번역 실행 (TH/KR/CN) -> 번역 검수 후 각 국가별 파트너에게 배포되도록 설계했다 -> document.distributed 이벤트 발행
세 가지 흐름 모두 동일한 패턴을 따른다. Document AI에서 생성 -> MQ에 이벤트 발행 -> Workflow AI에서 처리 -> 결과 이벤트 재발행. 이 패턴이 일관되기 때문에 새로운 흐름을 추가하는 것은 새로운 시스템을 구축하는 것이 아니라, 기존 파이프라인에 새로운 노드를 연결하는 것에 불과하다.
데이터 흐름의 기술적 구현
연결 구조가 실제로 동작하기 위해서는 정교한 기술적 설계가 필요하다. 이벤트 스키마, MQ 토픽 설계, 워크플로우 트리거 메커니즘, 그리고 End-to-End 추적을 위한 Correlation ID까지 각 요소가 어떻게 구현되는지 설명한다.
이벤트 스키마 (Event Schema)
모든 이벤트는 동일한 스키마를 따른다. Document AI, Workflow AI, REINDEERS 어느 시스템에서 발생하든 같은 구조로 MQ에 발행된다. 이 일관성이 시스템 간 통신을 단순하게 만든다.
{
"type": "document.created",
"source": "document-ai",
"payload": {
"documentId": "doc_2026040201",
"documentType": "quotation",
"companyId": "comp_0042",
"metadata": { ... }
},
"timestamp": "2026-04-02T09:15:30.000Z",
"correlationId": "corr_a1b2c3d4e5f6"
}
각 필드의 역할을 정리하면, type은 이벤트 종류를 식별하고 MQ 라우팅 키로 사용된다. source는 이벤트 발행자를 식별하며 디버깅과 감사에 활용된다. payload는 이벤트에 필요한 데이터를 담고, timestamp는 이벤트 순서 보장과 지연 시간 측정에 사용된다. correlationId는 하나의 비즈니스 프로세스를 관통하는 추적 ID로, End-to-End 추적의 핵심이다.
MQ 토픽 설계
MQ 토픽은 이벤트의 라우팅 경로를 결정한다. Document AI에서 발행하는 이벤트와 Workflow AI에서 발행하는 이벤트는 서로 다른 토픽으로 관리되며, 각 소비자는 자신에게 필요한 토픽만 구독한다.
| 토픽 | 발행자 | 주요 구독자 | 설명 |
|---|---|---|---|
| document.created | Document AI | Workflow AI | 문서 생성 완료 시 발행. 워크플로우 트리거의 시작점 |
| document.approved | Workflow AI | Document AI, REINDEERS | 승인 완료 시 발행. 문서 상태 업데이트 + 거래 등록 트리거 |
| document.shared | Workflow AI | Document AI, Notification | 문서 외부 공유 시 발행. 발송 이력 + 고객 알림 |
| workflow.completed | Workflow AI | REINDEERS, Document AI | 워크플로우 종료 시 발행. 후속 프로세스 트리거 |
| order.created | REINDEERS | Workflow AI, DVRP | 거래 등록 시 발행. 물류 프로세스와 후속 워크플로우 트리거 |
워크플로우 트리거 메커니즘
Workflow AI는 MQ consumer로 동작하며, 수신한 이벤트를 워크플로우 트리거와 매칭한다. 각 워크플로우는 하나 이상의 트리거 조건을 정의하고 있으며, 이벤트의 type과 payload가 조건과 매칭되면 실행을 시작한다.
{
"workflowId": "wf_quotation_review",
"trigger": {
"type": "event",
"eventType": "document.created",
"condition": {
"payload.documentType": "quotation"
}
},
"nodes": [
{ "id": "validate_price", "type": "action" },
{ "id": "manager_approval", "type": "approval" },
{ "id": "register_order", "type": "action" }
]
}
이 구조 덕분에 워크플로우 추가는 코드 변경이 아니라 설정(configuration) 변경이다. 새로운 문서 타입에 대한 새로운 워크플로우가 필요하면, 트리거 조건과 실행 노드를 정의하기만 하면 된다. 이벤트 발행-구독 인프라는 이미 존재한다.
Correlation ID: End-to-End 추적
B2B 거래는 하나의 요청이 수십 개의 단계를 거쳐 완료된다. "견적서 생성"에서 시작된 프로세스가 "내부 승인 -> 가격 검증 -> 거래 등록 -> 물류 배차"까지 이어질 때, 이 전체 흐름을 추적할 수 있어야 한다. 이를 위해 모든 이벤트에 correlationId가 포함된다.
09:15:30 Document AI
document.created 견적서 생성 완료09:15:31 Workflow AI
workflow.started 견적 검증 워크플로우 시작09:15:33 Workflow AI
action.completed 가격 이상치 검사 통과09:16:45 Workflow AI
approval.completed 팀장 승인 완료09:16:46 Workflow AI
document.approved 견적서 최종 승인09:16:47 REINDEERS
order.created 거래 자동 등록 완료
하나의 correlationId로 전체 프로세스를 역추적할 수 있다. 문서 생성부터 거래 등록까지 1분 17초 소요. 병목 구간은 팀장 승인 단계(약 72초). 이런 데이터가 축적되면 Workflow AI는 프로세스 병목을 자동으로 감지하고, 최적화 방안을 제안할 수 있게 된다.
실제 B2B 시나리오 3가지
앞서 설명한 기술 구조가 실제 비즈니스에서 어떻게 동작하는지, 구체적인 시나리오 세 가지를 통해 살펴본다.
Scenario 1. 공급사 제안서 자동화
태국의 산업자재 바이어가 한국 공급사에 화학 원료 견적을 요청하는 상황이다. 기존에는 영업 담당자가 과거 견적서를 찾고, Excel에서 가격을 계산하고, Word로 제안서를 작성하고, 상사 승인을 받고, PDF로 변환하여 이메일로 보냈다. 평균 소요 시간: 4~8시간.
자동화 파이프라인에서는 영업 담당자가 Document AI에서 바이어 정보와 요청 품목, 수량을 입력하면 AI가 과거 유사 거래 패턴을 참조하여 제안서 초안을 생성한다. document.created 이벤트가 Workflow AI로 전달되고, 사내 승인 워크플로우가 실행된다(영업팀장 -> 가격위원회 -> 최종 승인). 승인이 완료되면 제안서가 PDF + 태국어 요약으로 자동 생성되고, 고객별 맞춤 이메일이 자동 발송되도록 설계했다. 결과: 4~8시간이 대폭 단축될 것으로 기대한다. 담당자가 하는 일은 입력과 승인뿐이다.
Scenario 2. 견적-주문 파이프라인
바이어가 특정 품목의 견적을 요청하면, 이 견적이 실제 구매 주문(PO)으로 전환되기까지의 전체 과정이다. 기존에는 견적 작성, 사내 검토, 공급사 컨펌, PO 작성이 각각 별도의 시스템에서 이루어지고, 사람이 데이터를 수동으로 옮겼다.
자동화된 흐름에서는 Document AI에서 견적서 초안이 생성되면(과거 6개월 동일 품목 거래 가격 자동 참조), Workflow AI가 가격 검증을 실행한다(시장가 대비 +15% 이상 차이 시 경고 플래그). 검증을 통과하면 공급사에 확인 요청이 자동 발송되고(48시간 내 미응답 시 자동 리마인더), 공급사 확인이 완료되면 REINDEERS에 거래가 자동 등록되고 PO 문서가 자동 생성되도록 설계했다. 견적서의 품목, 수량, 가격, 납기가 PO에 자동 매핑된다. 중간에 데이터를 다시 입력하는 단계가 없다. 문서의 데이터가 곧 거래의 데이터이기 때문이다.
Scenario 3. 월간 리포트 자동화
매월 1일, 전월 거래 실적 리포트를 경영진과 주요 파트너에게 발송하는 업무다. 기존에는 데이터팀이 DB에서 데이터를 추출하고, Excel로 분석하고, PowerPoint로 보고서를 만들고, 이메일로 발송했다. 매월 2~3일이 소요되었다.
자동화 파이프라인에서는 Workflow AI 스케줄 트리거가 매월 1일 09:00에 실행되어 REINDEERS API에서 전월 거래 데이터를 수집한다. 수집이 완료되면 Document AI에 리포트 생성을 요청하고, 경영진용 리포트와 파트너용 요약본이 동시에 생성된다. 경영진 승인 워크플로우를 거친 뒤 수신자별 맞춤 이메일이 자동 발송되도록 설계했다. 이 시나리오에서 주목할 점은 Workflow AI가 먼저 시작한다는 것이다. 항상 Document AI가 먼저는 아니다. 양방향 순환이 동작하는 설계다.
왜 이 연결이 경쟁력인가
현재 시장에서 비슷한 결과를 내려면 여러 도구를 조합해야 한다. 문서 생성은 Notion이나 Google Docs, 자동화는 Zapier나 Make, 거래 관리는 별도의 ERP나 CRM. 이들을 연결하는 것은 이론적으로 가능하지만, 실제로는 많은 문제에 직면한다.
| 문제 | 도구 조합 방식 | REINDEERS 방식 |
|---|---|---|
| 데이터 모델 | 각 도구마다 다른 스키마. 매핑/변환 필요 | 전체 플랫폼이 동일한 데이터 모델 공유 |
| 이벤트 버스 | Webhook 기반. 실패 시 데이터 유실 위험 | MQ 기반. 메시지 보장, 재처리, 순서 보장 |
| 인증/권한 | 도구마다 별도 인증. OAuth 토큰 관리 부담 | SSO 기반 통합 인증. 한 번의 로그인 |
| AI 컨텍스트 | 각 도구의 AI는 해당 도구의 데이터만 참조 | 전체 플랫폼의 거래/문서/업무 데이터를 참조 |
| End-to-End 추적 | 불가능. 각 도구의 로그가 분산 | correlationId로 전체 프로세스 추적 |
| 유지보수 | 도구 API 변경 시 연동 전체 점검 필요 | 내부 이벤트 스키마 기반. 변경 영향 최소화 |
REINDEERS에서 Document AI와 Workflow AI가 강력한 이유는 세 가지 구조적 요인 때문이다. 첫째, 같은 데이터 모델 -- Document AI에서 생성한 견적서의 데이터 구조가 REINDEERS의 거래 데이터 구조와 동일하다. 변환이 필요 없다. 둘째, 같은 이벤트 버스 -- 모든 플랫폼이 하나의 MQ 인프라를 공유한다. 중간 변환 레이어가 존재하지 않는다. 셋째, 공유된 AI 컨텍스트 -- Document AI가 문서를 생성할 때 참조하는 데이터와 Workflow AI가 조건 판단에 사용하는 데이터가 같은 원천(source of truth)에서 온다.
Notion, Zapier, Google Docs는 각각 훌륭한 도구다. 하지만 이들은 도구 회사다. 각자의 문제를 잘 풀지만, 도구 사이의 문제는 사용자의 몫이다. REINDEERS는 플랫폼 회사다. 문서, 업무, 거래, 물류, 생산이 하나의 데이터 흐름 안에 있으며, AI가 이 전체 흐름의 데이터를 참조할 수 있다. 도구 조합 방식은 연동 복잡도가 도구 수의 제곱으로 증가하지만, 플랫폼 방식은 새로운 서비스를 추가해도 이벤트 버스에 연결하면 된다.
향후 확장: AI Agent가 두 서비스를 조율하는 구조
현재(Phase 1, Q2-Q3 2026)의 Document AI와 Workflow AI는 사용자가 명시적으로 문서를 생성하고, 워크플로우를 정의하는 구조다. 이벤트 기반 자동화가 이루어지지만, 초기 설정은 사람이 한다. Phase 2(Q4 2026~2027)에서는 이 구조 위에 AI Agent 레이어가 올라간다.
| 구분 | Tool 단계 (2026) | Assistant 단계 (2027) | Agent Team / Autonomous (2028~2030) |
|---|---|---|---|
| 시작점 | 사람이 문서 생성을 직접 요청 | AI Agent가 이벤트 기반 초안 제시 | CEO Agent가 목표를 Agent 팀에게 분해·실행 |
| 워크플로우 정의 | 사람이 노드를 직접 구성 | Agent가 템플릿 선택 · 노드 파라미터 추천 | Agent가 자연어 목표에서 워크플로우 자동 생성·실행 |
| 의사결정 | 규칙 기반 조건 분기 | Agent 판단 + 사람 승인 | Agent 팀 자율 판단 + 예외만 사람에게 에스컬레이션 |
| 사람의 역할 | 설정자 + 실행자 | 승인자 + 전략 조정자 | 전략 결정자 + 예외 판단자 |
| 자동화 비율 | 약 20% | 약 50% | 80% → 95% |
AI Agent의 동작 방식
Phase 2의 AI Agent는 Document AI와 Workflow AI를 "도구(tool)"로 사용한다. 사용자가 자연어로 지시하면, AI Agent가 어떤 문서를 만들어야 하고, 어떤 워크플로우를 실행해야 하는지 판단한다.
"태국 ABC Industries에 PP 수지 500톤 견적 보내줘.
지난 분기 가격 기준으로 5% 할인 적용하고,
팀장 승인 받으면 바로 발송해."
// AI Agent의 실행 계획
1. REINDEERS에서 ABC Industries 거래 이력 조회
2. 지난 분기 PP 수지 거래 가격 확인 -> 5% 할인 적용
3. Document AI에 견적서 생성 요청 (파라미터 자동 구성)
4. Workflow AI에 승인 워크플로우 구성 (팀장 -> 자동 발송)
5. 실행 계획을 사용자에게 확인 요청
6. 승인 시 실행 시작
여기서 핵심은 AI Agent가 실제 업무를 수행하고, 사람은 전략과 예외만 결정한다는 것이다. 가격 할인율은 Agent가 제안·실행하고, 사람은 정책 안에서 벗어나는 경우에만 개입한다. 문서 내용은 Agent가 생성·발송하고, 사람은 예외적인 건만 최종 결재한다. 이 구조에서 사람은 더 이상 매 건의 반복 업무를 수행하지 않는다. 직원 10명이 하던 견적·문서·발주·정산 업무를 한 명의 담당자와 Agent 팀이 함께 소화한다.
Agent Experience (AX)
Agent Team 단계에서 우리가 만들고자 하는 것은 단순한 챗봇이 아니다. 우리는 이것을 Agent Experience (AX)라고 부른다. UX(User Experience)가 사람과 인터페이스 사이의 경험을 설계하는 것이라면, AX는 사람과 AI Agent 사이의 경험을 설계하는 것이다. Agent가 조직의 구성원으로 일하는 환경에서는, 업무 인터페이스 자체가 "Agent가 수행한 일을 사람에게 어떻게 보여주고, 언제 개입하게 할 것인가"의 문제로 재정의된다.
AX의 세 가지 원칙은 다음과 같다. 투명성 — Agent는 실행 계획과 실행 결과를 감사 로그로 남긴다. 무엇을 했고, 왜 그렇게 판단했고, 어떤 데이터를 참조했는지를 사용자가 언제든 열람할 수 있다. 제어권 — 사용자는 Agent의 예산 한도, 신뢰도 임계치, 에스컬레이션 조건을 자유롭게 설정하고 언제든 수정할 수 있다. Agent는 자율적으로 실행하지만 경계는 사람이 정한다. 학습 — Agent는 사용자의 예외 판단과 수정 패턴을 학습한다. 같은 유형의 업무를 반복할수록 Agent의 판단 품질이 높아지고, 사람 개입 빈도가 줄어든다.
Tool 단계의 이벤트 기반 파이프라인이 Agent Team 단계의 실행 인프라가 된다. AI Agent가 Document AI에 문서 생성을 요청하면, 그 결과가 이벤트로 Workflow AI에 전달되고, Workflow AI가 후속 업무를 실행한다. 기존 파이프라인을 변경하지 않고, 그 위에 Agent 레이어만 추가하면 된다. 이것이 가능한 이유는 Tool 단계부터 이벤트 기반 아키텍처로 설계했기 때문이다.
마무리: 문서에서 거래까지, 하나의 파이프라인
Document AI와 Workflow AI는 별개의 제품이 아니다. 하나의 데이터 파이프라인을 구성하는 두 개의 레이어이며, 이 파이프라인이 REINDEERS 거래까지 연결된다.
Document AI는 정보를 문서로 변환한다. 거래 데이터가 견적서가 되고, 실적 데이터가 리포트가 된다. Workflow AI는 문서를 행동으로 변환한다. 견적서가 승인을 거쳐 발송되고, 거래로 등록된다. REINDEERS는 행동을 거래로 변환한다. 등록된 거래가 실행되고, 데이터가 축적된다. 그리고 축적된 데이터가 다시 Document AI의 원료가 된다. 순환이 완성된다.
이것을 가능하게 하는 기술적 기반은 동일한 데이터 모델, 동일한 이벤트 버스, 동일한 인증 체계다. 이 세 가지가 공유되기 때문에 시스템 간 경계가 사라지고, AI가 전체 흐름의 데이터를 참조할 수 있다.
Notion + Zapier + Google Docs를 조합하면 비슷한 결과를 흉내 낼 수 있다. 하지만 데이터 모델이 다르고, 이벤트 버스가 없고, AI 컨텍스트가 분산된다. 도구의 합은 플랫폼이 되지 않는다.
REINDEERS는 4,300+ 파트너, 2015년 IMARKET Thailand 설립 이후 약 11년간의 실거래 데이터, 그리고 구축하고 있는 통합 데이터 흐름 위에서 Document AI에서 Workflow AI로, Workflow AI에서 거래로, 거래에서 다시 문서로 이어지는 순환 파이프라인을 구축하고 있다. Tool 단계에서 이벤트 기반 실행을, Assistant 단계에서 Agent가 주도하는 초안·제안을, Agent Team/Autonomous 단계에서 CEO Agent와 부서 Agent 팀이 법인을 운영하는 구조로. 문서 자동화가 업무 자동화로, 업무 자동화가 AI Agent 법인 운영으로 이어지는 — 이것이 하나의 파이프라인이다.