B2B 국제 무역에서 하나의 거래가 완료되기까지 관여하는 시스템과 사람의 수는 예상보다 훨씬 많다. 견적 요청에서 시작해 공급사 선정, 발주, 포워딩 비딩, 통관 서류 준비, 출하, 배송, 정산까지 — 각 단계마다 서로 다른 담당자가 서로 다른 도구에서 수작업을 반복한다.
이 현장에서 반복적으로 발생하는 비효율은 분명하다. 바이어가 견적을 확정하면 공급사에게 이메일이나 메신저로 직접 통보해야 하고, 결제가 완료되면 수동으로 정산 시트에 옮기면서 1~3일이 소요된다. 출하 후에는 선적 정보를 기반으로 CI, PL, CO를 수동 생성하며 누락이 발생하고, 배송 완료 후 공급사/포워더 정산을 수작업으로 대조하면서 오차가 누적된다. ERP, 이메일, 스프레드시트, CRM에 같은 데이터를 반복 입력하는 것도 일상이다.
이 문제들의 공통점은 명확하다. "이벤트가 발생했을 때 후속 작업이 자동으로 실행되지 않는다"는 것이다. 견적이 확정되었다는 '사실'은 시스템에 기록되지만, 그 사실이 다음 단계의 업무를 자동으로 트리거하지는 않는다.
Reindeers Workflow는 이 문제를 해결하기 위해 만들어졌다. 단순히 "자동화 도구를 제공한다"가 아니라, REINDEERS 플랫폼에서 발생하는 실제 거래 이벤트를 기반으로 후속 업무가 자동 실행되는 구조를 만드는 것이다.
REINDEERS 플랫폼과의 연결: 거래 이벤트가 워크플로우를 트리거한다
Reindeers Workflow의 가장 중요한 차별점은 범용 자동화 도구가 아니라 REINDEERS 본 플랫폼의 거래 이벤트에 직접 연결된다는 것이다. REINDEERS에서 발생하는 핵심 거래 이벤트가 MQ(Message Queue)를 통해 워크플로우의 트리거가 된다.
| 거래 이벤트 | 트리거되는 워크플로우 | 실행 내용 |
|---|---|---|
| quote.confirmed | 공급사 알림 워크플로우 | 견적 확정 내역을 공급사에게 이메일/텔레그램으로 자동 발송, PO 초안 생성 |
| payment.completed | 정산 워크플로우 | 결제 데이터를 기반으로 공급사/포워더 정산 데이터 자동 집계, 승인 요청 발송 |
| order.confirmed | DO 생성 워크플로우 | Delivery Order 자동 생성, 포워더 배정 요청, DVRP 연동 트리거 |
| shipment.departed | 통관 서류 준비 워크플로우 | 선적 정보 기반 CI/PL 초안 생성, HS Code 분류, 원산지증명 체크, 누락 시 담당자 알림 |
| delivery.completed | 정산 산출 워크플로우 | 공급사/포워더별 정산 금액 자동 산출, 차이 발생 시 알림, 정산서 초안 생성 |
이 구조에서 핵심은 사람이 "견적을 확정한다"는 행위만 하면, 이후의 공급사 통보, PO 생성, 포워딩 요청, 서류 준비, 정산 산출이 이벤트 체인으로 자동 실행된다는 점이다. 사람의 역할은 "확인"과 "승인"으로 축소되고, 반복 작업은 워크플로우가 대체한다.
실행 흐름 예시: 견적 확정에서 정산까지
바이어가 견적을 확정하면 quote.confirmed 이벤트가 MQ로 발행된다. Workflow가 이벤트를 수신하면 공급사 3곳에 확정 알림을 자동 발송하고, 공급사 확인 후 주문이 확정되면 order.confirmed 이벤트가 발생한다. DO가 자동 생성되어 등록된 포워더에게 비딩 요청이 자동 발송되고, 포워더 선정 후 출하가 이루어지면 shipment.departed 이벤트가 통관 서류 자동 체크를 트리거한다. 누락된 인증서가 있으면 담당자에게 알림이 가고, 배송 완료 시 delivery.completed 이벤트가 공급사/포워더 정산 데이터 자동 집계와 승인 워크플로우를 실행한다.
Document AI에서 시작된 문서가 거래로 이어지는 흐름
REINDEERS의 또 다른 AI 서비스인 Document AI(doc.reindeers.ai)는 견적서, 제안서, 기술문서, IR 자료 등을 AI로 생성하는 서비스다. 중요한 점은 Document AI와 Workflow AI가 분리된 제품이 아니라 하나의 데이터 흐름 위에서 동작한다는 것이다.
[Document AI]
바이어가 견적 요청서 작성 (AI 기반 템플릿 + 과거 거래 참조)
→ document.created 이벤트 발행
[Workflow AI]
이벤트 수신 → 견적서 내용 파싱
→ 매칭 공급사 자동 선별 (카테고리 + 지역 + 과거 이력 기반)
→ 공급사별 견적 요청 자동 발송
→ 견적 회신 수집 → 비교 테이블 자동 생성
[REINDEERS]
바이어가 비교 테이블 확인 → 공급사 선정 → 견적 확정
→ quote.confirmed → PO 자동 생성 → 거래 시작
이 흐름에서 사람이 직접 개입하는 지점은 "견적 요청서 작성", "공급사 선정", "최종 확인"뿐이다. 문서 생성부터 공급사 매칭, 견적 비교, 거래 시작까지의 나머지 과정은 Document AI와 Workflow AI의 연계로 자동 실행된다. 업무의 시작점(문서)과 실행 구조(워크플로우)가 동일한 데이터 파이프라인 위에 있기 때문에 가능한 구조다.
이 연결이 만드는 차이는 구체적이다. 수동 문서 작성이 과거 거래 데이터를 참조한 AI 기반 자동 생성으로 바뀌고, 수동 공급사 탐색이 문서 내용 기반 자동 매칭으로 바뀐다. 수신된 견적은 파싱되어 표준화된 비교표가 자동 생성되고, 견적 확정 이벤트가 PO 생성과 후속 워크플로우를 자동으로 트리거한다.
Event-driven 아키텍처: MQ + Redis 기반 실행 구조
Reindeers Workflow는 단독으로 동작하는 자동화 도구가 아니다. REINDEERS 생태계 전체의 이벤트를 수신하고 실행하는 Event-driven 아키텍처 위에서 동작한다. 플랫폼 간 이벤트 전달에는 LavinMQ(AMQP 호환 메시지 큐)를, 세션 관리와 실행 상태 캐싱에는 Redis를 사용한다.
[이벤트 발생]
REINDEERS: quote.confirmed, payment.completed, order.confirmed
DVRP: shipment.departed, delivery.completed
Document AI: document.created, document.shared
Workflow 자체: form.submitted, webhook.received, schedule.triggered
[메시지 큐 (LavinMQ)]
이벤트 → Exchange → Routing Key 기반 Queue 분배
Queue별 Consumer가 해당 워크플로우 실행
실패 시 Dead Letter Queue → 재처리 또는 알림
[워크플로우 실행]
트리거 노드 → 조건 분기 (IF/Switch) → 액션 노드 실행
실행 상태: Redis에 캐싱 (TTL 기반 자동 만료)
중복 방지: Redis idempotency key (이벤트 ID 기반)
실행 이력: PostgreSQL에 영구 저장
[후속 이벤트]
워크플로우 실행 결과 → 새로운 이벤트 발행 → 다음 워크플로우 트리거
(이벤트 체이닝으로 플랫폼 간 자동 흐름 형성)
이 구조에는 세 가지 핵심 특성이 있다.
첫째, 비동기 분리(Decoupling)다. REINDEERS 본 플랫폼과 Workflow AI는 MQ를 통해 비동기로 연결된다. REINDEERS가 이벤트를 발행하면 그 즉시 응답을 반환하고, 워크플로우 실행은 별도 프로세스에서 독립적으로 처리된다. 한쪽의 장애가 다른 쪽으로 전파되지 않는다.
둘째, 멱등성 보장(Idempotency)이다. 동일한 이벤트가 중복 수신되어도 워크플로우가 두 번 실행되지 않는다. Redis에 이벤트 ID 기반의 idempotency key를 저장하고, 이미 처리된 이벤트는 건너뛴다. 네트워크 재시도나 MQ 재전달 시에도 정확히 한 번 실행을 보장한다.
셋째, 이벤트 체이닝(Chaining)이다. 하나의 워크플로우 실행 결과가 새로운 이벤트를 발행하여 다음 워크플로우를 트리거할 수 있다. 견적 확정 → PO 생성 → DO 생성 → 포워딩 요청이 하나의 이벤트 체인으로 자동 실행된다. 각 단계는 독립적이지만 MQ를 통해 하나의 흐름으로 연결된다.
기술 스택: n8n 기반 TypeScript 모노레포
Reindeers Workflow는 n8n 워크플로우 엔진을 기반으로 자사 인프라와 브랜딩에 맞게 커스터마이징한 형태다. 전체 코드베이스는 TypeScript로 작성되어 있으며, pnpm 워크스페이스와 Turbo를 사용하는 모노레포 구조를 채택했다.
| 계층 | 기술 | 역할 |
|---|---|---|
| 프론트엔드 | Vue 3 (editor-ui) | 노드 기반 캔버스 에디터 — 드래그, 연결, 파라미터 패널 |
| 백엔드 API | Node.js 22+ (cli) | HTTP API, 웹훅 라우팅, 스케줄 관리, RBAC, 자격 증명 관리 |
| 실행 엔진 | TypeScript (core, workflow) | 노드 실행 스택, 트리거 활성화, 서브워크플로우 호출, 표현식 평가 |
| 노드 라이브러리 | nodes-base | 트리거/일반 노드/자격 증명 타입 정의 (수백 개 내장 노드) |
| 데이터베이스 | PostgreSQL + TypeORM | 워크플로우 정의, 활성 버전, 실행 이력, 자격 증명(암호화), 사용자/프로젝트 |
| 메시지 큐 | LavinMQ (AMQP) | 플랫폼 간 이벤트 비동기 전달, Dead Letter Queue, 재처리 |
| 캐시 | Redis | 세션, 실행 상태 캐싱, 중복 방지(idempotency key) |
| 리버스 프록시 | Caddy | 자동 HTTPS (Let's Encrypt), 80/443 포트 처리 |
| CI/CD | Drone | main push → build → Docker push → SSH deploy → docker compose up |
| 배포 | Docker Compose | Postgres + App + Caddy 컨테이너 세트, 볼륨 기반 데이터 영속화 |
packages/
workflow/ // 워크플로우 그래프, 노드 실행 규칙, 표현식 평가
core/ // 실행 엔진 (노드 실행 스택, 트리거, 서브워크플로우)
cli/ // HTTP 서버, 웹훅, DB, 자격 증명, RBAC
nodes-base/ // 트리거/노드/자격 증명 타입 정의
editor-ui/ // Vue 3 워크플로우 에디터 (캔버스 기반)
design-system/// 공통 UI 컴포넌트
// 빌드 및 배포
pnpm build // Turbo로 전체 패키지 병렬 빌드
build-n8n.mjs // 프로덕션 빌드 → compiled/ 디렉토리
docker build → push // Docker 이미지 생성
docker compose up -d // Postgres + App + Caddy 실행
배포 흐름은 단순하다. 코드를 main 브랜치에 푸시하면, Drone CI가 빌드를 수행하고, Docker 이미지를 레지스트리에 푸시한 뒤, SSH로 운영 서버에 접속하여 최신 이미지를 pull하고 docker compose up -d를 실행한다. 앱 컨테이너만 교체되고 PostgreSQL 데이터 볼륨은 유지되므로, 워크플로우 정의와 실행 이력이 배포 과정에서 손실되지 않는다.
B2B 무역 특화 자동화 시나리오
범용 자동화 도구와의 차이는 시나리오에서 드러난다. Reindeers Workflow의 자동화 시나리오는 "리드 수집 → 이메일 발송"과 같은 일반적 패턴이 아니라, B2B 국제 무역의 실제 업무 흐름에 기반한다.
견적 자동 발송 및 비교
바이어 견적 요청이 등록되면(Form Trigger 또는 REINDEERS API 이벤트), 요청 상품의 카테고리/규격/수량을 파싱하여 매칭 공급사를 자동 선별한다(과거 거래 이력 + 카테고리 + 지역 기반). 공급사별 견적 요청서가 자동 생성되어 이메일/텔레그램으로 발송되고, 견적 회신을 수집한다(웹훅 대기 + 7일 타임아웃). 회신이 모이면 비교 테이블이 자동 생성되어 바이어에게 발송된다. 견적 취합 시간이 기존 3~5일에서 자동 수집 후 즉시 비교로 단축된다.
포워딩 비딩 자동화
order.confirmed 이벤트가 발생하면, PO 데이터에서 출발지/도착지/물량/중량을 추출하여 등록된 포워더 30+사에 비딩 요청을 자동 발송한다. 포워더별 견적을 수집(웹훅 수신 + 파싱)한 뒤 해상/항공/육상 운임 비교 테이블을 자동 생성하고, 가격/리드타임/과거 이력을 기반으로 최적 포워더를 추천한다. 포워더 선정 시간이 5~7일에서 2일 내로 줄어든다.
통관 서류 자동 준비
shipment.departed 이벤트가 발생하면, 선적 정보(B/L, 컨테이너, 선박명) 기반으로 CI/PL 초안을 자동 생성한다. 상품별 HS Code를 AI 기반 + 과거 분류 이력을 참조하여 자동 분류하고, 도착국 인증 요건(TISI, FDA, MFDS 등)을 자동 체크한다. 원산지증명서(CO) 발급 필요 여부를 판단하고, 누락 서류가 있으면 담당자에게 즉시 알림을 발송한다(텔레그램/이메일). 서류 누락으로 인한 통관 지연이 80% 감소한다 — 사후 대응에서 사전 체크로 전환되기 때문이다.
배송 완료 후 정산 자동 산출
delivery.completed 이벤트가 발생하면, 해당 거래의 PO/DO/결제 데이터를 자동 집계한다. 공급사 정산(납품 금액 - 선급금 - 클레임 차감액)과 포워더 정산(운임 - 보험료 - 추가 비용)을 각각 산출하고, 정산 차이가 발생하면 자동 플래그 + 담당자 알림을 보낸다. 정산서 초안이 자동 생성되어 승인 워크플로우를 트리거한다. 정산 처리 시간이 3일에서 배송 완료 당일 자동 산출로 단축된다.
주기적 환율 변동 알림 및 견적 자동 재계산
Schedule Trigger가 매일 09:00(Asia/Shanghai)에 실행되어 환율 API를 조회한다(THB, KRW, CNY, MYR → USD). 전일 대비 변동률을 계산하고, 변동률이 2%를 초과하면 관련 진행 중 견적을 자동 재계산한다. 영향 받는 견적 목록 + 재계산 결과를 담당자에게 알림으로 보내, 환율 변동에 의한 견적 손실 리스크를 사전 차단한다.
보안과 권한: 파트너 단위 격리
B2B 환경에서 워크플로우 플랫폼을 운영하려면 보안과 권한 관리가 필수다. Reindeers Workflow는 세 가지 계층으로 보안을 구현한다.
표현식 샌드박스 — 노드 파라미터의 표현식은 사용자 입력을 그대로 eval하지 않는다. AST 파서로 파싱한 뒤 허용된 연산과 예약 변수($json, $node 등)만 통과시키는 샌드박스를 적용한다. with, eval, 전역 객체 접근은 차단된다.
자격 증명 암호화 — API 키, OAuth 토큰 등 자격 증명은 PostgreSQL 저장 전 암호화된다. 복호화는 실행 시 해당 워크플로우에 권한이 있을 때만 수행된다. 프로젝트 단위로 자격 증명을 공유(SharedCredentials)하며, 노드에서는 "어떤 자격 증명을 쓸지"만 선택하면 실행 시 안전하게 주입된다.
RBAC (역할 기반 접근 제어) — credential:owner, workflow:owner 등 역할 기반으로 접근을 제어한다. 웹훅/폼 요청이 들어와도 해당 워크플로우를 소유한 프로젝트 기준으로 실행 컨텍스트가 결정되므로, 파트너 A의 워크플로우가 파트너 B의 자격 증명에 접근할 수 없다.
파트너 격리가 특히 중요한 이유가 있다. REINDEERS는 바이어 2,500+사, 공급사 1,800+사, 포워더 30+사가 함께 사용하는 플랫폼이다. 프로젝트 단위 격리가 없다면, 공급사 A가 공급사 B의 단가 정보를 포함한 워크플로우를 열람하거나 실행할 수 있게 된다. RBAC과 프로젝트 기반 실행 컨텍스트는 이런 데이터 유출을 구조적으로 방지한다.
AI Agent 통합 로드맵: 자동화에서 자율 실행으로
현재 Reindeers Workflow는 사람이 노드를 연결하여 워크플로우를 설계하고, 이벤트가 이를 트리거하는 구조다. 그러나 이 구조는 이미 AI Agent가 올라갈 수 있는 토대를 갖추고 있다. 워크플로우 정의가 JSON 기반이고, 실행이 이벤트 기반이며, 결과가 구조화된 데이터로 저장되기 때문이다.
| 단계 | 시기 | 구현 내용 | 상태 |
|---|---|---|---|
| 현재 | Q1 2026 | n8n 기반 워크플로우 엔진, 이벤트 트리거, 노드 편집기 | 운영 중 |
| Phase 1 | Q2-Q3 2026 | 견적/발주/포워딩 AI 지원 — AI가 과거 데이터 기반으로 최적 옵션 추천, 사람이 확인 | 개발 중 |
| Phase 2 | Q4 2026 - 2027 | 통합 AX (Agent Experience) — AI Agent가 워크플로우를 자동 생성/실행/최적화 | 계획 |
Phase 1에서는 AI가 워크플로우 내에서 의사결정을 보조한다. 예를 들어, 견적 요청이 들어왔을 때 AI가 과거 유사 거래 데이터를 분석하여 "이 상품은 공급사 A가 평균 납기 7일, 가격 경쟁력 상위 20%"와 같은 추천을 제공한다. 사람은 이 추천을 확인하고 승인하는 역할만 한다. 워크플로우 자체는 사람이 설계하지만, 각 노드에서 AI가 데이터 기반 판단을 지원하는 구조다. 구현 방식은 워크플로우 노드에 AI Function 노드를 추가하고, RAG 기반 컨텍스트 검색(과거 거래/문서/물류 데이터)을 수행하며, 구조화된 추천 결과를 JSON 스키마 기반으로 반환하고, Human-in-the-loop 승인/거절 노드를 두는 것이다.
Phase 2에서는 AI Agent가 워크플로우 자체를 자동으로 생성하고 실행한다. 사용자가 "태국 공급사에서 스틸 파이프 100톤 견적 받아줘"라고 요청하면, AI Agent가 요청 의도를 파악하여 적합한 워크플로우 템플릿을 선택하고, 과거 거래 데이터에서 적합한 태국 공급사를 자동 선별한 뒤, 워크플로우 노드를 자동 구성(견적 요청 → 수집 → 비교 → 알림)하여 실행하고 결과를 보고한다. 실행 이력을 기반으로 다음 요청 시 더 정확한 워크플로우를 생성할 수 있게 된다.
사용자 자연어 요청
→ Intent 분석 (거래 유형, 상품, 국가, 긴급도)
→ 워크플로우 템플릿 매칭 또는 동적 생성
→ 필요한 자격 증명/노드/파라미터 자동 설정
→ 워크플로우 실행 (기존 이벤트 기반 엔진 활용)
→ 실행 결과 구조화 → 사용자에게 보고
→ 피드백 수집 → 워크플로우 최적화 학습
// 핵심: 기존 n8n 워크플로우 엔진이 그대로 실행 레이어로 동작
// AI Agent는 워크플로우를 "생성"하는 역할, 실행은 검증된 엔진이 담당
이 로드맵의 핵심은 AI Agent가 완전히 새로운 시스템을 만드는 것이 아니라, 기존에 검증된 워크플로우 엔진 위에서 동작한다는 점이다. 실행 안정성은 이미 검증된 n8n 기반 엔진이 보장하고, AI는 "어떤 워크플로우를 만들 것인가"라는 설계 레이어에 집중한다. 이 분리 덕분에 AI의 환각(hallucination)이 실행 안정성에 영향을 주지 않는 구조가 된다.
Workflow AI는 자동화 도구가 아니라 업무 수행 레이어다. REINDEERS 플랫폼의 거래 이벤트를 직접 수신하고, 후속 업무를 자동 실행한다. Document AI에서 시작된 문서가 Workflow를 통해 실제 거래로 이어지고, Event-driven 구조(MQ + Redis)로 REINDEERS, Document AI, DVRP, POP가 각각 독립적으로 배포되면서도 이벤트를 통해 하나의 실행 흐름으로 연결된다.
비개발자도 Vue 기반 노드 에디터에서 드래그와 연결만으로 워크플로우를 만들 수 있다. 그리고 2026 Q4부터는 AI Agent가 이 워크플로우를 자연어 명령만으로 자동 생성하고 실행하는 구조로 진화한다. 4,300+ 파트너의 업무 데이터가 쌓일수록, AI Agent는 더 정확한 워크플로우를 더 빠르게 생성할 수 있게 된다.