Blog

동남아시아 제조 기업의 현장을 보면 흥미로운 모순이 있다. 시스템은 존재하지만, 데이터는 연결되지 않는다. REINDEERS는 이 간극을 메우기 위해 POP(Production Operation Platform)를 설계했다. MES(제조실행), ERP(자원관리), WMS(창고관리)를 단일 SaaS로 통합하되, 독립 시스템이 아니라 기존 REINDEERS 생태계의 일부로 동작하게 만드는 것이 핵심이다. 하나 먼저 짚고 가자. POP의 아키텍처 선택은 단순히 "MES+ERP+WMS를 하나로 묶는다"는 수준이 아니다. 최종 목표는 회사 운영 자체가 AI로 전환될 수 있는 구조 를 만드는 것이다. 사람은 전략과 방향을 결정하고, 실제 업무는 조직도에 등록된 AI Agent와 로봇이 실행한다. 이 글에서 설명하는 데이터 모델, 이벤트 구조, 모듈 경계, API-First 설계는 모두 그 AI 전환을 가능하게 하기 위한 기술적 전제 조건이다. 이 글은 POP의 설계 원칙과 논리 구조를 정리한 것이다. 왜 이 구조가 필요한지부터, 데이터 모델, 멀티테넌시, 모듈 통합, 기존 플랫폼과의 연결, AI Agent 통합 설계, 플랫폼 축까지 다룬다. 왜 POP가 필요한가 동남아 제조업의 현실: 시스템은 있지만, 흐름은 없다 태국의 중소 제조 공장을 예로 들어 보자. 생산 라인에서는 엑셀이나 구형 MES로 작업지시를 관리하고, 창고에서는 별도의 재고 장부나 WMS를 쓰며, 회계팀은 로컬 회계 패키지에서 매출과 원가를 관리한다. 각 시스템은 나름대로 동작하지만, 이들 사이에 실시간 데이터 흐름은 없다. 이 구조에서 다음 문제가 반복적으로 발생한다. 이중 입력 -- 생산 완료 수량을 MES에 기록하고, 같은 숫자를 다시 재고 시스템에 수동 입력한다. 데이터 지연 -- 원자재 소진이 회계에 반영되기까지 1~3일 걸린다. 그사이 발주 타이밍을 놓친다. 가시성 부재 -- "지금 이 제품을 얼마나 만들 수 있는가...

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 업무에서 반복적으로 필...

기존 B2B SaaS는 대부분 기능 단위로 분리되어 있다. 문서는 문서 도구에서, 자동화는 Workflow 도구에서, 거래는 ERP나 별도 시스템에서 처리된다. 각각의 도구는 충분히 잘 만들어져 있지만, 문제는 이 도구들 사이에서 발생한다. 각 도구에 데이터가 흩어지면서 전체 업무 맥락이 사라지고, 문서 작성 → 승인 → 견적 → 발주 사이에 사람이 수동으로 데이터를 옮기며, AI가 참조할 수 있는 연결된 데이터가 존재하지 않게 된다. 동남아 산업자재 B2B 시장의 규모는 $130B 이상이지만, 이 시장에서 발생하는 거래의 30% 이상이 서류 오류, 수작업, 시스템 부재로 인해 지연된다. 연간 $300억 이상의 기회비용이 여기서 발생한다. 기업의 실제 업무는 연결되어 있는데, 시스템은 분리되어 있기 때문이다. REINDEERS의 접근: 기능이 아니라 업무 흐름을 가져온다 REINDEERS는 기능을 제공하지 않는다. 대신 흐름을 가져온다. Document AI와 Workflow AI는 각각 독립적인 제품이 아니라, 하나의 데이터 흐름 위에서 동작하는 두 개의 레이어다. 레이어 역할 데이터 상태 Document AI 업무의 시작점 — 정보 정리, 문서 생성 제안서, 견적서, 기술문서, IR 자료 운영 중 Workflow AI 업무의 실행 구조 — 이벤트 기반 자동화 승인, 알림, 리포트, 데이터 동기화 운영 중 REINDEERS 거래 중계 — 견적/주문/결제/정산 PQ, PO, DO, CI, 결제, 정산 운영 중 DVRP 물류 실행 — 3PL 재고/배차/경로 최적화 DO, 트럭, 기사, 경로, ETA ...

B2B 국제 무역에서 하나의 거래가 완료되기까지 관여하는 시스템과 사람의 수는 예상보다 훨씬 많다. 견적 요청에서 시작해 공급사 선정, 발주, 포워딩 비딩, 통관 서류 준비, 출하, 배송, 정산까지 — 각 단계마다 서로 다른 담당자가 서로 다른 도구에서 수작업을 반복한다. 이 현장에서 반복적으로 발생하는 비효율은 분명하다. 바이어가 견적을 확정하면 공급사에게 이메일이나 메신저로 직접 통보해야 하고, 결제가 완료되면 수동으로 정산 시트에 옮기면서 1~3일이 소요된다. 출하 후에는 선적 정보를 기반으로 CI, PL, CO를 수동 생성하며 누락이 발생하고, 배송 완료 후 공급사/포워더 정산을 수작업으로 대조하면서 오차가 누적된다. ERP, 이메일, 스프레드시트, CRM에 같은 데이터를 반복 입력하는 것도 일상이다. 이 문제들의 공통점은 명확하다. "이벤트가 발생했을 때 후속 작업이 자동으로 실행되지 않는다" 는 것이다. 견적이 확정되었다는 '사실'은 시스템에 기록되지만, 그 사실이 다음 단계의 업무를 자동으로 트리거하지는 않는다. Reindeers Workflow는 이 문제를 해결하기 위해 만들어졌다. 단순히 "자동화 도구를 제공한다"가 아니라, REINDEERS 플랫폼에서 발생하는 실제 거래 이벤트를 기반으로 후속 업무가 자동 실행되는 구조를 만드는 것이다. REINDEERS 플랫폼과의 연결: 거래 이벤트가 워크플로우를 트리거한다 Reindeers Workflow의 가장 중요한 차별점은 범용 자동화 도구가 아니라 REINDEERS 본 플랫폼의 거래 이벤트에 직접 연결 된다는 것이다. REINDEERS에서 발생하는 핵심 거래 이벤트가 MQ(Message Queue)를 통해 워크플로우의 트리거가 된다. 거래 이벤트 트리거되는 워크플로우 실행 내용 quote.confirmed 공...

B2B 업무 현장에서 문서는 매출과 신뢰를 결정짓는 핵심 자산이다. 제안서, 서비스 소개서, 사업계획서, 기술 문서, IR 자료 등 상대를 설득하거나 정보를 전달하기 위한 문서가 항상 필요하고, 그 작성 과정은 회사마다 형태만 다를 뿐 구조적으로 동일하다. 자료를 모으고, 목차를 잡고, 섹션별로 작성하고, 표현을 다듬고, 검토하고, 내보내는 과정이 반복된다. 문제는 기존 AI 문서 도구가 이 반복 구조를 해결하지 못한다는 점이다. 대부분의 생성형 도구는 "프롬프트 한 줄 입력 → 결과물 한 덩어리 출력"으로 끝난다. 한 번 생성된 결과를 부분적으로 수정하거나, 과거 문서의 패턴을 재활용하거나, 생성된 내용의 사실 관계를 검증하는 구조가 없다. 기존 생성형 AI 도구에는 네 가지 근본적인 한계가 있다. 단발성 생성이라 전체를 한 번에 만들고 끝나서 섹션 단위 편집이 불가능하고, 기업의 과거 데이터나 도메인 지식을 참조하지 못하며, 할루시네이션 체크나 스타일 일관성 검증이 없고, Token 사용량이 보이지 않아 통제할 수 없다. Reindeers Document AI는 이 문제를 문서를 조작 가능한 섹션 단위로 분리하여 관리하는 운영 플랫폼 으로 해결한다. 단순히 AI가 문장을 생성하는 도구가 아니라, 구조화된 데이터 입력 → 섹션별 생성 → 편집 → 품질 검증 → 공유/출력까지 이어지는 문서 운영 체계다. 섹션 기반 데이터 모델 기술 스택은 Next.js App Router 기반이며, Cloudflare Workers에 배포된다. 데이터 저장은 Turso 기반 libSQL과 Drizzle ORM을 사용하고, 인증은 JWT 쿠키 방식으로 구성했다. 핵심은 문서를 "하나의 파일"이 아니라 "프로젝트 → 섹션"의 2레벨 계층 구조 로 관리한다는 점이다. 엔티티 주요 필드 역할 Proje...