Blog of Reindeers

REINDEERS DVRP AI CORE ENGINE 소개 REINDEERS는 2026년 음력 설 이후, 2월 중순을 목표로 DVRP(Dynamic Vehicle Routing Platform) 베타 서비스를 공식 오픈 AI가 실시간으로 판단·결정·지시·최적화 이번 글은 기술팀의 시각에서, DVRP가 어떤 구조로 설계되었고 AI가 어떻게 업무를 실제로 “대신 수행”하도록 만든 기술적 기반을 설명합니다. 프레임워크나 언어는 보안상 비공개하지만, 핵심 알고리즘·AI 아키텍처·동기화 구조·RAG 전략 1. 서비스 개요 — AI 기반 물류 엔진의 출현 REINDEERS DVRP는 다음의 핵심 기능들을 통합한 하나의 AI 플랫폼입니다. 트럭·기사·창고 간 배차 자동화 Direct DO(직배송)의 다구간 경로 계산 입고 ASN·출고 ASN·DO 생성 전체 자동화 GPS 기반 실시간 위치 추적 및 ETA 예측 FIFO·CBM·거리·로트 기반 재고 할당 엔진 LLM 기반 AI 오케스트레이션(업무 지시 자동화) RAG 기반 현실 데이터 참조형 AI 의사결정 대규모 트럭 운영(1000대 규모)을 위한 MQ · 비동기 구조 이 모든 기능은 REINDEERS CORE ENGINE 이라는 단일 구조에서 작동합니다. Web, Mobile Web, Native App이 동일 엔진을 공유하도록 만들어져 있으며 AI가 어느 디바이스에서든 같은 판단을 내릴 수 있는 구조입니다. 2. 프론트 구조 — Web · Mobile Web · Native App 통합 2-1. Web 대량의 데이터 조회, 트럭/기사 모니터링, 창고 운영, DO 처리 등을 담당합니다. 업무 플로우를 AI가 자동으로 생성하기 때문에 Web은 단순히 입력·확인 UI 역할을 합니다. 2-2. Mobile Web 운전기사와 창고 담당자를 위한 현장 중심 UI입니다. 입출고 스캔, 사진 제출, GPS 이벤트 전송, 증빙...

2025-12-01 이후, 개발팀이 보는 다음 단계 2025년 12월 1일, reindeers.com은 “정식 오픈”이라는 이름으로 서비스를 시작한다. 하지만 개발팀 입장에서 보면, 이 날은 완성의 순간이 아니라 “현장에서 검증을 시작하는 첫날” 에 가깝다. 구조는 준비됐고, 데이터는 흐르기 시작했지만, 실제 사용자의 손을 타기 전까지는 알 수 없는 것들이 너무 많다. 1) 초기 오픈 후, 항상 다시 드러나는 현실적인 문제들 플랫폼을 초기 오픈하면 공통적으로 반복되는 현상이 있다. REINDEERS도 예외는 아니다. 업무 플로우와 화면 흐름의 괴리 기획·설계 단계에서 수십 번 회의를 거친 플로우라고 해도, 실제 고객사/공급사가 사용하는 순간 “이 단계는 너무 길다”, “이 정보는 이 타이밍에는 안 보인다” 같은 피드백이 나온다. 특히 견적 → 주문 → 생산/조달 → 물류 → 인도까지 이어지는 긴 체인은 한 단계만 UX가 어색해도 전체가 불편해진다. 경계 케이스(edge case)의 폭발 내부 테스트에서는 정상 플로우(happy path)를 중심으로 검증한다. 하지만 실제 환경에서는 “중간에 결제 방식을 바꾸고 싶다”, “견적은 두 개 받고 PO는 하나로 묶고 싶다”, “수출은 취소됐지만 내수 전환을 하고 싶다” 같은 복합 케이스가 튀어나온다. 이때는 플로우 설계 자체를 손봐야 하는 경우도 생긴다. 개념어에 대한 이해 차이 내부에서는 당연히 통하는 단어(예: DO, ASN, OSN, 결제국, 고객사/공급사 구분 등)가 실제 사용자에게는 처음 듣는 용어일 수 있다. 용어 하나 때문에 입력을 멈추거나, 잘못된 메뉴로 들어가는 일이 반복되면 결국 “시스...

2030 비전 — 데이터가 만드는 새로운 산업경제 생태계 요약: 2030년, 산업은 더 이상 제품 중심이 아니라 데이터 중심으로 움직인다. REINDEERS는 제조, 물류, 인증, 정산 데이터를 하나의 네트워크로 통합해 국가와 산업의 경계를 넘어선 새로운 경제 생태계를 구축하고자 한다. 이번 글은 REINDEERS가 그리는 2030년 산업경제의 구조를 제시한다. 1. 산업의 경계가 사라지는 시대 과거의 산업은 구분되어 있었다. 제조는 생산, 물류는 이동, 유통은 판매였다. 하지만 2030년의 산업은 다르다. 모든 과정이 데이터로 연결되고, 그 데이터가 곧 가치가 된다. REINDEERS는 그 중심에서 “데이터가 움직이는 무역경제” 를 만들고 있다. 제품이 이동하기 전에 데이터가 먼저 이동한다. 데이터는 공급망의 새로운 화폐가 되었다. 2. 데이터 중심 산업경제의 구조 REINDEERS의 2030 모델은 다음 세 가지 축으로 구성된다: Data Flow: 모든 산업 프로세스가 데이터 이벤트로 연결됨 Trust Layer: 데이터 무결성과 이력 추적을 보장하는 구조 Prediction Core: AI가 실시간으로 수요·공급 변화를 예측 [Factory] → [REINDEERS Data Core] → [AI Prediction Layer] → [Global Trade Node] 이 구조에서 기업은 단순히 제품을 판매하지 않는다. 자사의 데이터를 네트워크에 기여하며, 그 데이터가 다른 기업의 의사결정을 돕는다. R...

2025년 11월 11일, 드디어 오픈 — 베타 서비스를 넘어 글로벌로 요약: 2025년 11월 11일, REINDEERS는 공식적으로 베타 서비스를 오픈했다. 하지만 이 날은 단순한 테스트가 아니라, 플랫폼이 처음으로 스스로 작동하기 시작한 ‘실질적 오픈일’이었다. AI, MQ, MCP, Cloud Function, 그리고 4개 리전의 인프라가 하나의 시스템처럼 연결된 날이었다. 1. 4년의 끝, 그리고 출발점 REINDEERS의 지난 4년은 하나의 목적을 향해 있었다. 단순히 플랫폼을 완성하는 것이 아니라, 사람이 개입하지 않아도 스스로 판단하고 실행할 수 있는 구조를 만드는 것. 그리고 그 구조가 실제로 작동한 날이 바로 2025년 11월 11일이었다. 우리는 그날을 ‘베타 오픈’이라 부르지만, 실제로는 완성된 시스템의 첫 가동일이었다. 2. 오픈의 방식 — 네 리전의 동시 구동 베타 오픈은 하나의 서버나 국가에서 진행되지 않았다. 태국, 한국, 말레이시아, 중국 4개 리전이 동시에 연결되며 거래, 결제, 물류, 인증 데이터가 실시간으로 교차 동작했다. 모든 프로세스는 MQ를 통해 전달되고, Cloud Function이 이를 받아 MCP에서 실행했다. 각 리전의 서버는 독립되어 있었지만, 결과적으로 하나의 플랫폼처럼 움직였다. 3. AI가 운영을 시작하다 이날부터 AI Agent는 실제 운영의 일부가 되었다. 거래 검증, 견적 검수, 일정 생성, 번역, 데이터 동기화 등 이전까지 사람이 직접...

AI와 MQ, 그리고 MCP — 우리가 기술로 문제를 해결한 방식 요약: REINDEERS는 단순한 자동화 시스템이 아니다. 우리는 AI, MQ, MCP를 결합해 사람이 하던 의사결정과 실행을 시스템화했다. 업무의 절반은 사람이, 나머지 절반은 AI Agent가 처리한다. 이번 글은 REINDEERS가 기술로 문제를 해결한 실제 방식을 공개한다. 1. AI가 들어오기 전의 문제 2025년 5월 내부 리셋 이후, 가장 큰 문제는 속도였다. 팀의 기술 수준은 높았지만, 다국적 협업 환경에서는 작은 결정 하나에도 시간이 걸렸다. “이 데이터는 어디에 저장할까?”, “이 로직은 누가 승인해야 하지?” 이런 질문이 하루를 지연시켰다. 사람의 의사결정을 코드로 바꾸는 방법이 필요했다. 그 해답이 AI Agent 였다. 2. MCP + MQ + AI의 결합 구조 REINDEERS의 내부 구조는 세 가지 축으로 이루어져 있다. MCP(Multi-Commerce Platform)는 전체 트랜잭션의 뼈대, MQ(Message Queue)는 데이터 흐름의 신경망, AI Agent는 그 신경망을 제어하는 두뇌 역할을 한다. [MCP] — [MQ Router] — [AI Agent] — [Cloud Functions] — [Data Layer] ↘︎ Logging ↙︎ ↘︎ Scheduler ↙︎ AI는 사람이 하지 않아도 되는 “판단성 업무”를 맡았다. 예를 들어, MQ에 “quote.confirmed” 이벤트가 들어오면 AI가 자동으로 주문 구조...

왜 태국·한국·말레이시아·중국인가 — REINDEERS의 글로벌 확장 전략 요약: REINDEERS는 태국, 한국, 말레이시아, 중국 4개국을 중심으로 글로벌 무역 플랫폼의 기술과 운영 인프라를 동시에 구축했다. 특히 개발은 한국과 중국 양쪽에서 병렬로 진행되며, 두 리전이 서로의 백업 및 실험 환경 역할을 수행한다. 이번 글은 각 리전의 역할과 기술적 이유를 기록한다. 1. 동시 오픈의 배경 REINDEERS는 처음부터 하나의 국가에서 완성될 수 없는 구조였다. 무역은 복수의 국가가 동시에 참여해야 완전한 프로세스를 이룬다. 그래서 우리는 서비스 초기부터 네 개 국가의 리전을 병렬 설계했다. 태국은 시장이자 물류의 중심, 한국과 중국은 개발의 중심, 말레이시아는 운영과 금융의 허브였다. 네 리전이 동시에 작동해야만 “무역이 움직이는 플랫폼”이 가능했다. 2. 태국 — 시장과 물류의 실시간 거점 태국은 REINDEERS의 실제 비즈니스 거래가 이루어지는 핵심 리전이다. 고객사의 견적 요청, 공급사의 견적 발행, DO 생성, 결제, 인보이스 발행 등 모든 상거래 이벤트가 태국 리전의 MCP에서 최초로 발생한다. 서비스 인프라는 Tencent Cloud Bangkok 리전에 구축되었으며, 정적 파일과 이미지 리사이징은 COS Function으로 처리된다. 프론트엔드는 홍콩 CDN에서 배포되어 인접 국가에서도 빠른 응답 속도를 유지한다. 3. 한국 — 기술의 중심이자 MCP의 제어 리전 한국은 REINDEERS의 핵...

태국에서 시작된 혁신 — 10년간 쌓아온 MRO 유통의 노하우 요약: REINDEERS의 시작은 태국 법인 IMARKET Thailand 였다. 10년 넘게 쌓아온 산업소모품(MRO) 유통 경험과 데이터, 그리고 제조업 고객과 공급사 간의 관계가 오늘의 플랫폼을 만든 토대가 되었다. 이번 글은 REINDEERS가 태국에서 쌓은 산업적 이해를 어떻게 기술로 바꿨는지를 기록한다. 1. IMARKET Thailand — REINDEERS의 출발점 REINDEERS의 역사는 태국 법인 IMARKET Thailand Co., Ltd. 에서 시작되었다. 이 법인은 2014년 설립되어 10년간 태국 산업재 유통 시장에서 활동해왔다. MRO(Maintenance, Repair, Operations) 제품을 중심으로 3만여 개 SKU를 관리하고, 2,000여 개 기업 고객을 직접 대응한 경험이 있었다. REINDEERS는 이 법인의 실제 유통·조달 데이터 위에서 설계되었다. 기술보다 먼저 있었던 것은 산업이었다. IMARKET Thailand가 10년간 쌓은 거래 데이터, 구매 패턴, 납기 리듬이 오늘날 REINDEERS 데이터베이스의 기반이 되었다. 2. 태국 산업재 시장의 현실 태국의 MRO 시장은 규모는 크지만, 데이터화는 더뎠다. 공장마다 거래 방식이 다르고, 같은 제품도 이름과 단위가 달랐다. 하나의 절연테이프가 브랜드마다 다른 코드로 유통되었고, 주문서는 대부분 이메일이나 팩스로 처리되었다. REINDEERS는 바로 이 비효율에서 기회를 보았다. 2020년부터 SKU 표준화(No...

Buybly에서 REINDEERS로 — 브랜드 리포지셔닝의 비밀 요약: Buybly는 단순한 유통 플랫폼이었다. 하지만 우리가 만들고자 했던 것은 “산업의 언어를 바꾸는 기술 플랫폼”이었다. 이름이 바뀐 것이 아니라, 존재의 방향이 달라졌다. 이번 글은 Buybly가 REINDEERS로 진화한 이유와 그 전략적 배경을 기록한다. 1. Buybly의 한계 — 이름보다 방향의 문제 Buybly는 2021년, 산업재와 소비재를 동시에 다루는 B2B 플랫폼으로 시작되었다. 이름은 “Buy + Easily”의 조합으로, 빠르고 간편한 구매를 의미했다. 하지만 시간이 지나면서 이 이름은 우리가 만들고자 한 시스템의 본질과 멀어졌다. Buybly는 거래 중심의 사고에서 출발했지만, REINDEERS는 데이터 중심의 사고 에서 출발했다. 우리는 “무엇을 팔 것인가”보다 “산업이 어떻게 연결되어야 하는가”를 고민하기 시작했다. 그 순간, Buybly라는 이름은 한계가 되었다. 2. 리브랜딩의 출발 — 철학부터 다시 세우다 리브랜딩은 단순한 네이밍 작업이 아니었다. Buybly는 기능적인 이름이었고, REINDEERS는 방향이 있는 이름이어야 했다. 그래서 우리는 기술, 사람, 그리고 시장의 본질에서부터 새로운 철학을 세웠다. 기술의 본질: 자동화와 데이터가 사람의 일을 돕는 구조 산업의 본질: 제조와 공급이 언어 없이도 연결되는 구조 조직의 본질: 글로벌 팀이 하나의 목표를 공유하는 구조 이런 철학을 표현할 새로운 이름이 필요했다. 그 이름이 바로 REINDEE...

IT와 무역이 만나다: 제조업의 새로운 길을 설계하다 요약: REINDEERS는 단순한 플랫폼이 아니다. 우리는 “무역”이라는 복잡한 산업 언어를 소프트웨어 언어로 바꾸는 실험을 했다. 그리고 그 과정에서 IT와 무역은 충돌했지만, 결국 하나의 구조로 융합되었다. 이번 글은 REINDEERS가 무역 프로세스를 기술로 재정의한 과정을 기록한다. 1. 무역은 코드보다 복잡했다 REINDEERS의 출발점은 단순했다. “제조업과 유통을 연결하자.” 하지만 그 말 한 줄을 시스템으로 바꾸는 데 4년이 걸렸다. 무역은 전자상거래와 다르다. 주문에는 견적(Quote), 발주(PO), 납품서(DO), 상업송장(CI), 관세, 운송, 보험까지 포함된다. 각 단계가 독립적이지만 서로 연결되어야 한다. 한 문서가 늦으면 물류 전체가 멈춘다. 우리는 이 복잡한 절차를 단순한 버튼 하나로 연결해야 했다. 그 시작이 바로 **MCP (Multi-Commerce Platform)** 였다. 2. MCP — 무역 절차를 시스템화한 첫 구조 MCP는 단순한 백엔드 시스템이 아니었다. PO, DO, CI, BL, Payment, Refund 등 각 무역 단계를 독립된 서비스로 나누고, 메시지 큐(LavinMQ)를 통해 연결한 분산 구조였다. 각 서비스는 **이벤트 기반(Event-Driven Architecture)** 으로 작동했다. “견적 확정” 이벤트가 발생하면 자동으로 “운송 일정 생성”과 “결제 요청” 이벤트가 이어졌다. 관리자는 버튼을 누르지 않아도 업무가 진행되었다. ...

팀을 네 번 교체하며 배운 것들 — 진짜 글로벌 팀을 만들기까지 요약: REINDEERS의 개발팀은 네 번의 전면 교체를 거쳤다. 각 시도마다 기술보다 중요한 것은 ‘이해’였고, 문화보다 중요한 것은 ‘책임’이었다. 실패의 반복 끝에, 우리는 기술 중심이 아니라 데이터·AI·협업 언어 로 움직이는 진짜 글로벌 팀을 만들었다. 1. 첫 번째 팀 — 외주 개발사의 한계 REINDEERS의 첫 번째 팀은 외부 개발사였다. 계약은 단순했고, 목표는 “무역 플랫폼의 MVP 구축”이었다. 그러나 현실은 달랐다. 개발사는 무역을 이해하지 못했고, 제조 유통의 흐름을 전자상거래처럼 처리하려 했다. 결과적으로 견적(Quote), 주문(Order), 물류(Logistics), 결제(Payment)가 같은 테이블에 얽혀 있었다. 개발은 빨랐지만, 구조는 위험했다. 첫 번째 팀은 “코드를 만들었지만, 플랫폼은 만들지 못했다.” 2. 두 번째 팀 — 내부화의 첫 시도 두 번째 시도는 “내부 개발팀 구성”이었다. 외주가 실패한 이유를 외부 탓으로 돌릴 수 없다고 판단했기 때문이다. 관리 인력과 몇 명의 풀스택 개발자가 합류해, 직접 시스템을 만들기 시작했다. 하지만 문제는 여전히 같았다. “기술은 있지만 이해가 없었다.” 플랫폼이 무엇을 해야 하는지보다, “어떻게 코드를 짤 것인가”에만 집중했다. 결과적으로 기능은 많았지만, 방향은 없었다. 3. 세 번째 팀 — ‘조직’은 있었으나 ‘구조’는 없었다 세 번째 팀은 형식적으로 완벽했다....

REINDEERS, 4년의 여정 — 동남아 제조업 혁신을 향한 출발점 요약: REINDEERS 프로젝트는 동남아 제조·유통 시장의 불균형을 해결하기 위해 시작된 글로벌 무역 플랫폼 구축 여정이었다. 4년에 걸친 시행착오 끝에, 기술 중심의 조직으로 재편되고 AI를 핵심 전략으로 채택하며 새로운 출발선을 맞이했다. 1. 출발 — 동남아 제조 유통의 혁신을 꿈꾸다 REINDEERS의 시작은 단순한 플랫폼 사업이 아니었다. 동남아 제조업체들이 글로벌 시장에 직접 접근하지 못하는 구조를 바꾸기 위한 시도였다. 태국, 말레이시아, 베트남의 수많은 중소 제조사는 여전히 전화와 이메일로 거래를 이어가고 있었고, 가격 비교·납기 관리·운송 연계 등 모든 과정이 수작업에 머물러 있었다. 이러한 현실을 개선하기 위해 우리는 “제조업 기반 B2B 무역 플랫폼”을 설계하기로 했다. 하지만 초기 단계에서 가장 큰 문제는 기술이 아니라 이해의 부족 이었다. 2. 외주 개발의 한계 2021년, 우리는 첫 번째 개발을 외주로 진행했다. 그러나 개발사는 무역의 구조와 산업재 유통의 특성을 이해하지 못했다. 전자상거래의 논리를 그대로 적용하려 했고, 복잡한 견적·PO·DO·물류 절차를 단일 주문 로직으로 단순화시켜버렸다. 결과적으로 플랫폼은 외형만 존재했을 뿐, 실제 무역 프로세스를 처리할 수 없었다. 외주 개발은 그 시점에서 중단되었다. 3. 내부 개발팀의 첫 시도와 실패 외주 프로젝트 종료 이후, 내부적으로 개발 관리 인력을 영입해 자체 개발을 시도했다. 그러나 시스템의 복잡성과 기술적 요구 수준은 생...