Blog

REINDEERS 플랫폼에서는 최근 견적(PQ–QA–QB)과 주문(PO–DO–포워딩–결제) 전반의 UI/UX를 다시 설계했다. 겉으로 보면 “화면이 더 깔끔해졌다” 정도로 보일 수 있지만, 실제로는 내부적으로 이미 정리된 고객사–공급사–포워딩 관계 구조 를 사용자 화면에 그대로 노출하기 위한 구조 개편이었다. 현재 시점은 명확하다. 플랫폼의 거래 구조(고객사/공급사/포워딩 연결)는 개선을 완료했고, 이제는 DVRP 베타(2026년 3월 예정) 를 위한 개발이 진행되는 단계다. 즉, 지금 UI/UX 개편은 “보기 좋은 화면”이 목적이 아니라, 실행 레이어(DVRP)로 연결 가능한 형태의 데이터·흐름을 UX로 고정 하는 작업에 가깝다. 1) UI/UX 개편의 출발점: “상태 리스트”는 국제 거래를 설명하지 못한다 국제 무역/물류 플랫폼에서 거래는 ‘단계’가 아니라 ‘관계’다. 견적이 주문을 만들고, 주문은 여러 DO로 분기되고, 포워딩 선택은 DO 단위로 붙으며, 결제는 확정된 실행 결과를 기준으로 발생한다. 문제는 기존 화면이 이 구조를 “리스트”로 표현하고 있었다는 점이다. 문서가 나열되고 상태가 나열되면, 사용자는 결국 다음 질문을 하게 된다. 어떤 견적이 확정되었고, 그 확정이 주문과 어떻게 연결되었나? 왜 DO가 여러 개로 나뉘고, 각각의 물류 실행은 어떤 차이가 있나? 포워딩은 언제 선택하는가? 결제는 무엇을 기준으로 묶이는가? 이 질문은 사용자가 부족해서가 아니라, UI가 “흐름”을 전달하지 못해서 생긴다. 그래서 이번 개편은 디자인보다 먼저 흐름의 표현 단위 를 재정의하는 것에서 시작했다. 2) 견적 흐름 재정의: PQ → QA → QB (객체 분리 + 분기 표현) 견적은 다음 구조로 정리되었다. PQ (Purchase Quote) : 고객사의 견적 시작점 QA (Quote Request) : 공급사에 전달되는 요청 단위(분기 가능) QB (Quote...

레인디어스 플랫폼은 특정 기능이나 특정 산업만을 위한 도구로 설계되지 않았다. 플랫폼의 출발점은 항상 동일했다. "현실의 거래 구조와 운영 흐름을 그대로 수용하면서, 이를 기술로 연결할 수 있는가" 라는 질문이다. 앞선 글에서 설명했듯이 레인디어스는 구매자-공급사-포워딩-물류를 하나의 흐름으로 연결하는 구조로 전환했고, DVRP를 통해 창고와 배차까지 통합하는 단계에 이르렀다. 이번 글에서는 그 다음 질문, "플랫폼이 확장될수록 왜 더 복잡해지지 않는가" 에 대해 설명한다. 1) 왜 운영 안정화가 확장보다 우선인가 무역과 물류, 포워딩이 결합된 영역에서 작은 오류 하나는 단순한 불편이 아니라 직접적인 비용 손실과 신뢰 붕괴 로 이어진다. 일정이 어긋나고, 책임이 불분명해지고, 결국 사람의 개입이 폭발적으로 늘어난다. 레인디어스는 이 문제를 구조적으로 해결하기 위해 기능 확장 이전에 운영 안정성 을 최우선 설계 기준으로 삼았다. 모든 업무는 버튼 클릭이나 단일 이벤트가 아니라, 명확한 상태(State)를 가지는 단계적 흐름 으로 정의된다. 한 단계가 끝나기 전에는 다음 단계로 이동할 수 없고, 각 단계에는 명확한 책임 주체가 존재한다. 이 구조 덕분에 참여자가 늘어나도 "지금 어디에서 문제가 발생했는지"를 즉시 파악할 수 있다. 실제 운영에서 이 원칙이 적용되는 방식은 구체적이다. 예를 들어 구매자가 발주를 확정하면, 해당 주문은 CONFIRMED 상태로 전이된다. 이 시점에서 공급사 화면에는 생산 착수 버튼이 활성화되고, 포워딩 업체 화면에는 아직 아무 액션도 노출되지 않는다. 공급사가 생산 완료를 보고하고 READY_TO_SHIP 상태로 전환되어야만 포워딩 견적 요청이 시작된다. 각 상태 전이에는 타임스탬프와 책임 주체가 기록되기 때문에, 지연이 발생했을 때 어느 단계에서 얼마나 머물렀는지 데이터로 확인할 수 있다. 2) 확장을 전제로 한 플랫폼의 기본 구조 레인디어스는...

레인디어스 플랫폼은 초기 단계에서 구매자(Buyer) - 레인디어스 - 공급사(Supplier) 를 연결하는 구조로 출발했다. 이 구조에서 레인디어스는 단순 중개를 넘어, 선사 스케줄 정보를 수집-표준화하고 이를 기반으로 포워딩 업무를 자동화하여 "정보 비대칭을 줄이고 의사결정 속도를 높이는" 방향을 목표로 했다. 그러나 실 운영 단계에서 현실의 견적 형성 구조 와 플랫폼의 자동화 방식 사이에 괴리가 발생했고, 이는 비용 구조 및 운영 안정성 측면에서 개선이 필요한 지점으로 드러났다. 레인디어스는 이 문제를 해결하기 위해 플랫폼 구조를 재정의하고, 포워딩 업체가 직접 참여하는 확장형 플랫폼 으로 전환했다. 1) 기존 구조의 한계: 스케줄 기반 자동화의 현실 괴리 포워딩 견적은 단순히 선사 스케줄만으로 결정되지 않는다. 견적은 다양한 변수를 통해 시장 참여자에 의해 실시간으로 형성 된다. 예를 들어 다음과 같은 요소가 견적에 직접적인 영향을 준다. 선복(스페이스) 수급 상황과 노선별 수요 변화 시기별 계약 단가, 단기 스팟 운임 변동 포워딩 업체별 확보한 스페이스/네트워크/운영 전략 긴급 출항, 지연, 환적 조건 등 일정 리스크 레인디어스는 이 데이터를 확보하기 위해 NCP Cloud Functions 기반의 스크래퍼를 운영하여 HMM, KMTC, SM Line 등 주요 선사의 스케줄 정보를 자동 수집해왔다. 각 선사별 크롤러는 10분 타임아웃으로 실행되며, 수집된 데이터는 Reindeers API로 전송되어 노선별 스케줄 DB를 구성한다. 그러나 이렇게 수집된 스케줄 데이터만으로는 실제 운임을 산정할 수 없었다. 결과적으로, 플랫폼 내부에서 스케줄 기반으로 자동 산출한 견적과 실제 포워딩 업체의 견적 간 차이가 반복적으로 발생했고, 이는 운영 측면에서 다음과 같은 문제로 이어졌다. 실제 비용과 불일치하는 견적으로 인한 의사결정 왜곡 수동 보정 업무 증가 및 운영 리소스 소모 ...

이번 파트는 REINDEERS 전체 기술 구조의 “최종 정리”이다. 단일 기능이 아니라 무역(Trading) + 3PL WMS + DVRP 배송 + AI 자동화 + 글로벌 동기화 + 비용 엔진 + 멀티리전 인프라 가 하나의 시스템으로 결합된 형태를 기술적으로 설명한다. 이 설계는 2025년 5월부터 시작해 단일 아키텍처로 다시 작성된 결과물이며, 최종 오픈 일정인 2026년 3월 1일 을 목표로 현재도 확장·검증 중이다. 57. 전체 아키텍처의 상위 개념 REINDEERS는 “EC + SCM + 물류센터 + 운송 + 무역”을 하나로 합친 시스템이다. 기존 시장에서는 이 기능을 보통 4~6개의 시스템으로 분리해 운영하지만, REINDEERS는 모두 단일 엔티티로 통합 설계했다. 57.1 상위 구조 [Trading Layer] ├─ 견적(E-Quotation) ├─ 발주(PO) ├─ 인증(TISI/FDA/COO) ├─ 수입/수출 스케줄 └─ 비용/정산 [WMS Layer] ├─ ASN (입고) ├─ OSN (출고) ├─ 재고관리 ├─ FEFO/lot/유통기한 ├─ 실사/반품/폐기 └─ Workforce Scheduling [DVRP Layer] ├─ DO 생성 ├─ Route Optimization ├─ Driver Assignment ├─ ETA Prediction └─ Re-dispatch Engine [AI MCP Layer] ├─ Orchestrator (Action Schema) ├─ Translator-Agent ├─ Logistics-Agent ├─ Trading-Agent ├─ RAG Contracts Manager └─ Cost Predictor [Infra ...

REINDEERS 플랫폼은 단순히 WMS와 DVRP를 연결하는 시스템이 아니다. 산업형 3PL · Trading · Fulfillment 환경에서는 "비용 구조의 정확성"이 서비스 품질만큼이나 중요한 요소다. 특히 동남아 지역의 산업 물류 특성상 고객사는 단순 배송비가 아니라 보관료 · 패키지 사용료 · 수입·통관 비용 · 외주 차량 비용 · 반품/폐기 비용 까지 모두 포함된 총 비용 관리를 요구한다. REINDEERS가 운영하는 4개국(한국, 태국, 말레이시아, 중국) 법인 각각에서 비용 계산 방식이 다르고, 4,300개 이상의 파트너사 중 고객사별 계약 조건이 모두 상이하다. 이런 환경에서 엑셀 기반의 수동 정산은 누락과 오류의 원인이 된다. 이에 REINDEERS는 데이터를 기반으로 자동 계산되고 예측되는 AI Cost Optimization Engine 을 구축했다. 46. 비용 엔진이 필요한 근본 이유 산업 물류에서 비용은 단순 계산이 아니다. 보관료는 CBM 기준일 수도 있고, SKU 기준일 수도 있다. 출고비는 피킹 난이도·로케이션·Zone 혼잡도에 따라 달라진다. 배송료는 CBM·중량·거리·시간·차종에 따라 달라진다. 외주 차량 비용은 업체별로 상이하며, 고정 단가가 아니다. 반품/폐기 비용은 유통기한·로트별 재고 흐름과 연동된다. 실제 사례를 들면, 태국의 한 고객사는 CBM 기준 보관료를 적용하면서 동시에 팔레트 단위 최소 과금을 요구했다. 다른 고객사는 Cold Zone 보관 시 일반 Zone 대비 2.5배 단가를 적용하되, 월 보관량이 일정 기준을 넘으면 할인율을 적용하는 조건이었다. 이런 복잡성을 단순 규칙으로 처리하면 고객사마다 다른 정책을 적용할 수 없고, 실수·과금 누락·중복 청구가 빈번해진다. 따라서 비용 계산...

이번 파트에서는 REINDEERS 플랫폼의 DVRP 코어 엔진 , 즉 DO 생성 → 배차 → 경로 최적화 → ETA 보정 → 재배차(Re-dispatch) 까지 이어지는 전체 기술 구조를 정리한다. 여기서 다루는 내용은 이론적인 DVRP 설명이 아니라, 실제로 운영 가능한 수준으로 구현한 제약 기반 최적화 + AI 보정 + MQ/캐시 구조 에 대한 기록이다. 37. DO 시스템의 기본 구조 재정리 REINDEERS는 모든 운송 지시를 DO(Delivery Order) 로 통일했다. Pickup DO — 고객사 → 창고 (입고용) Delivery DO — 창고 → 고객사 (출고용) Direct DO — 고객사 → 목적지 (직배송, 창고 미경유) ASN/OSN은 어디까지나 입·출고 계획(Notice) 이고, 실제 트럭이 움직이는 단위는 DO이다. DVRP 엔진이 다루는 모든 대상은 결국 “DO 집합”이다. ASN / OSN (계획) ↓ (DO 생성기) DO 집합 (Pickup / Delivery / Direct) ↓ (DVRP 엔진) 트럭·기사·경로·ETA 38. DVRP 엔진의 목표와 제약 조건 REINDEERS DVRP 엔진은 전형적인 VRP를 그대로 구현하지 않는다. 실제 현장의 제약을 우선해서 알고리즘을 구성했다. 38.1 최적화 목표 총 운행 거리 최소화 지각(ETA 초과) 최소화 트럭 당 적재율(CBM/중량) 최대화 AI 배차 실패율 최소화 38.2 강제 제약 조건 트럭 최대 CBM·중량 초과 금지 근로 시간·휴게 시간 준수 냉장/위험물/특수 화물 전용 트럭 사용 각 DO의 배송 가능 시간 윈도우(time window) ...

REINDEERS는 2026년 1월을 기점으로, 기존의 나라별 통합 B2B 무역 플랫폼을 국제 무역의 실제 실행 구조를 모두 흡수하는 서비스 플랫폼 으로 확장한다. 이번 확장의 핵심은 두 가지다. AI를 "자동화 도구"가 아닌 의사결정 보조자 로 배치하는 구조 DVRP 기반 3PL과 무역 플랫폼을 하나의 거래 흐름 으로 결합하는 구조 이 글은 REINDEERS가 왜 이 두 가지를 동시에 선택했는지, 그리고 이것이 국제 무역 플랫폼 설계에서 어떤 기술적 의미를 갖는지를 설명한다. 2015년 IMARKET Thailand 설립 이후 10년간 동남아 B2B 무역을 직접 운영하면서 축적한 경험이, 이 구조적 결정의 배경이다. 1. 국제 무역의 본질적인 문제 국제 무역은 오랫동안 다음과 같은 방식으로 운영되어 왔다. 견적: 이메일, 메신저, 엑셀 계약: PDF, 스캔 파일 생산-납품 일정: 사람의 기억과 전화 물류: 포워딩 경험 의존 정산: 사후 확인 문제는 이 모든 과정이 하나의 연속된 의사결정 흐름 임에도 불구하고, 각 단계가 서로 단절되어 있다는 점이다. $130B 이상 규모의 동남아 B2B 시장에서 이 단절은 단순한 불편이 아니라 직접적인 비용 손실로 이어진다. 견적 단계에서 합의된 조건이 물류 단계에서 다르게 해석되거나, 생산 일정 변경이 포워딩 예약에 반영되지 않아 선복을 놓치는 일이 빈번하다. REINDEERS는 이 단절의 원인을 기술적으로 다음과 같이 정의했다. 결정 기준이 데이터로 남지 않는다 이전 판단이 다음 단계로 전달되지 않는다 사람이 모든 비교-검증-정리를 직접 수행한다 이 구조에서는 AI를 단순 자동화 도구로 넣어도 근본적인 개선이 일어나지 않는다. 자동화는 이미 정리된 데이터 위에서만 작동하기 때문이다. 데이터가 단절된 상태에서 자동화를 적용하면, 잘못된 입력 위에서 더 빠르게 잘못된 결과를 만들어내는 것에 불과하다....