Blog

REINDEERS가 처음 시작된 건 태국에서 한국 산업 자재를 수입하는 B2B 무역이었다. 그때는 아무도 이걸 "데이터 회사"라고 부르지 않았다. 바이어와 공급사를 연결하고, 견적을 주고받고, 물류를 관리하는 무역 중개 플랫폼이었다. 11년이 지났다. 25,000건 이상의 거래, 4,300개 이상의 파트너사, 태국-한국-중국-말레이시아 4개국에 걸친 무역 데이터가 플랫폼 안에 쌓였다. 그리고 어느 시점부터 이 데이터 자체가 플랫폼의 가치를 결정하는 핵심 자산이 되기 시작했다. 기능은 복제할 수 있다. 그러나 11년간 축적된 동남아 산업 무역 데이터는 복제할 수 없다. 최근 1년 동안 이 데이터의 용도가 한 단계 더 바뀌었다. 이전까지 데이터는 '더 좋은 추천'을 만드는 연료였다. 지금 이 데이터는 'AI Agent가 사람 대신 업무를 실행할 수 있게 하는' 연료다. REINDEERS와 POP, DVRP는 지금 AI로 전환되는 구조 위에 올라서 있다. 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 실행한다. 이 전환은 데이터가 없으면 시작조차 할 수 없다. 그래서 데이터 플라이휠의 의미가 단순히 "추천 정확도"에서 "AI Agent의 판단 근거"로 넘어간다. REINDEERS 데이터 플라이휠 거래 → 데이터 → AI → 인사이트 → 다시 거래. 네 단계가 순환하며 자기 강화. 1 거래 실행 REINDEERS 거래 플랫폼 · DVRP 물류 · POP 운영 · 실제 B2B 거래가 일어난다 ↓ 2 데이터 축적 모든 이벤트 · 상태 · 로그가 append-only로 기록된다 (11년 × 25,000+ 실거래) ↓ 3 AI 학습 · 판단 도메인 특화 모델이 환각 없이 판단 · AI Agent가 실제 업무 실행 ↓ 4 인사이트 제공 가격 · 공급 · 경로 추천 · 파트너...

올해 1분기, 이상한 일이 반복됐다. REINDEERS 영업팀 미팅 로그를 보면 동남아 제조·유통 기업들로부터 컨설팅 요청이 쏟아지고 있었는데, 내용이 기대와 달랐다. B2B 거래 플랫폼 문의가 아니었다. "REINDEERS가 쓰고 있다는 AI, 우리도 적용할 수 있나요?" 태국 식품 가공업체, 말레이시아 부품 제조사, 중국 원자재 무역상까지. 업종은 제각각인데 질문은 같았다. 처음에는 단순히 AI 트렌드에 편승한 문의라고 생각했다. 요즘 어디서나 AI 이야기가 나오니까. 하지만 미팅을 직접 다녀 보면 상황이 달랐다. 그들은 막연한 호기심이 아니라 구체적인 고통을 가지고 있었다. 그리고 그 고통의 근원을 추적해 보면, 놀랍도록 동일한 지점에서 출발하고 있었다. 미리 한 가지를 짚고 가자. POP는 단순한 MES+ERP+WMS SaaS가 아니다. 우리가 설계한 것은 회사 운영 자체가 AI로 전환되는 구조 다. 사람은 결정과 방향을 제시하고, 실제 업무는 AI Agent가 실행한다. 조직도 안에서 사람, AI Agent, 로봇이 같은 단위로 등록되어 함께 일한다. POP의 진짜 얼굴은 이 구조에 있다. POP 조직도 사람은 전략, CEO Agent가 지휘, 하위 AI Agent · 사람 · 로봇이 실제 업무를 수행 사용자 (사람) 전략 · 방향 결정 ↓ 방향 제시 CEO Agent 전사 조율 · KPI 모니터링 · 자원 배분 ↓ 부서별 업무 지시 구매 Agent 발주 · 공급사 관리 생산 Agent 계획 · 실행 감독 영업 · 물류 · 재무 · 통관 Agent 각 부서별 업무 관리 ↓  세부 업무 지시  ↓ ━━━ 실행 레이어 ━━━ AI 하위 AI Agent 세부 업무 자동 실행 · API 호출 · 문서 생성 · 승인 요청 人 사람 (담당자) 판단 · 예외 처리 · 거래처 대면 · 최종 승인 ⚙ 로봇 물리 작업...

동남아시아 제조 기업의 현장을 보면 흥미로운 모순이 있다. 시스템은 존재하지만, 데이터는 연결되지 않는다. 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 업무에서 반복적으로 필...