Blog of Reindeers

UI/UX 개편 기술 에피소드 — 화면을 바꾼 것이 아니라, 구조를 바꾸었다 플랫폼의 UI/UX를 개편했다고 하면 흔히 디자인 변경이나 사용성 개선을 떠올린다. 하지만 이번 레인디어스 플랫폼의 UI/UX 개편은 그런 종류의 작업이 아니었다. 화면은 결과였고, 실제 변경의 중심은 주문과 견적을 해석하는 내부 구조 였다. 고객사, 공급사, 포워딩이 동시에 사용하는 플랫폼에서 UI는 단순한 인터페이스가 아니라 각 주체가 현재 상황을 어떻게 인식하는지 를 결정한다. 이 인식이 어긋나면, 기술적으로는 정상이어도 운영은 항상 충돌한다. 문제의 시작: 상태는 같았지만, 의미는 달랐다 기존 UI에서 가장 심각했던 문제는 같은 주문을 보고 있음에도 각 사용자가 전혀 다른 단계라고 인식 한다는 점이었다. 고객사 화면에서는 “주문 완료” 공급사 화면에서는 “확정 전” 포워딩 화면에서는 “조건 미정” 데이터상 상태 값은 일치했지만, 그 상태가 의미하는 바는 사용자 역할마다 달랐다. 이는 단순한 UI 문제처럼 보였지만, 실제로는 주문 흐름 자체가 단선 구조로 설계되어 있었기 때문 이었다. UI 개편의 전제 조건: Draft 개념의 도입 UI를 바꾸기 전에 먼저 한 일은, 주문과 물류 흐름을 다시 정의하는 것이었다. 모든 프로세스의 중심에 Draft 개념을 두었다. 확정되지 않은 것은 확정되지 않은 상태로 명확히 표현하도록 했다. Draft Purchase Order Draft Delivery Order Draft Forwarding Quote 이 구조가 만들어진 이후에야 “지금 이 화면에서 사용자가 무엇을 결정할 수 있는가”를 UI로 정확히 표현할 수 있게 되었다. UI/UX 개편의 핵심 원칙 이번 개편에서 지킨 원칙은 단순했다. 입력이 아니라 의사결정 중심 의 화면 상태 값이 아니라 의미가 보이는 상태 표현 다음 액션이 없는 버튼은 존재하지 않음 ...

고객·공급사·포워딩이 ‘같은 화면’을 보게 되기까지 플랫폼을 오래 운영하다 보면, 기술보다 더 복잡해지는 것이 있다. 그것은 기능도 아니고, 트래픽도 아니다. 관계 다. REINDEERS 플랫폼 역시 마찬가지였다. 고객사, 공급사, 포워딩. 각각은 분명 자신의 역할을 충실히 수행하고 있었지만, 플랫폼 안에서는 항상 어딘가 어긋나 있었다. 고객사는 “견적을 요청했다”고 생각했고, 공급사는 “주문이 확정되지 않았다”고 말했으며, 포워딩은 “물류 조건이 확정되지 않았다”고 답했다. 문제는 누구의 잘못도 아니었다. 문제는 각자가 서로 다른 기준점에서 같은 주문을 바라보고 있었다는 것 이었다. 같은 주문, 다른 해석 초기의 구조에서 가장 큰 문제는 견적 → 주문 → 물류 가 단선적인 흐름 으로 설계되어 있었다는 점이다. 현실의 무역에서는 이 세 단계가 결코 직선으로 이어지지 않는다. 견적은 여러 번 바뀌고 주문은 조건부로 확정되며 물류는 생산과 일정에 따라 다시 재조정된다 하지만 시스템은 이를 “한 번 정해지면 끝나는 단계”로 취급했다. 그 결과, 주문 하나를 두고 상태 값은 맞는데 의미는 다른 상황 이 반복해서 발생했다. 이 문제를 해결하기 위해, 우리는 기능을 추가하는 대신 구조를 다시 정의하기로 했다. Draft라는 개념을 중심에 두다 재설계의 출발점은 단순했다. “확정되지 않은 것은, 확정되지 않았다고 명확하게 표현하자.” 그래서 모든 흐름의 중심에 Draft 개념 을 두었다. 고객사의 요청은 Draft Purchase Order Draft PO를 기반으로 Draft Delivery Order Draft DO를 기준으로 포워딩의 물류 견적 발행 이 구조에서 중요한 점은 누구도 ‘확정된 것처럼 행동하지 않아도 된다는 것 이다. 고객사는 여러 시나리오를 비교할 수 있고 공급사는 생산 가능 범위 안에서 조건을 제시하며 포워딩은 실제 실행 가능한 물...

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

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

레인디어스 플랫폼 구조 전환과 AI 기반 물류 생태계 확장 Buyer–Supplier–Forwarder 견적 경쟁 + DVRP(WMS·배차관제)로 연결되는 End-to-End 플랫폼으로의 진화 레인디어스 플랫폼은 초기 단계에서 구매자(Buyer) – 레인디어스 – 공급사(Supplier) 를 연결하는 구조로 출발했습니다. 이 구조에서 레인디어스는 단순 중개를 넘어, 선사 스케줄 정보를 수집·표준화하고 이를 기반으로 포워딩 업무를 자동화하여 “정보 비대칭을 줄이고 의사결정 속도를 높이는” 방향을 목표로 했습니다. 그러나 실 운영 단계에서 현실의 견적 형성 구조 와 플랫폼의 자동화 방식 사이에 괴리가 발생했고, 이는 비용 구조 및 운영 안정성 측면에서 개선이 필요한 지점으로 드러났습니다. 레인디어스는 이 문제를 해결하기 위해 플랫폼 구조를 재정의하고, 포워딩 업체가 직접 참여하는 확장형 플랫폼 으로 전환했습니다. 1) 기존 구조의 한계: 스케줄 기반 자동화의 현실 괴리 포워딩 견적은 단순히 선사 스케줄만으로 결정되지 않습니다. 견적은 다양한 변수를 통해 시장 참여자에 의해 실시간으로 형성 됩니다. 예를 들어 다음과 같은 요소가 견적에 직접적인 영향을 줍니다. 선복(스페이스) 수급 상황과 노선별 수요 변화 시기별 계약 단가, 단기 스팟 운임 변동 포워딩 업체별 확보한 스페이스/네트워크/운영 전략 긴급 출항, 지연, 환적 조건 등 일정 리스크 결과적으로, 플랫폼 내부에서 스케줄 기반으로 자동 산출한 견적과 실제 포워딩 업체의 견적 간 차이가 반복적으로 발생했고, 이는 운영 측면에서 다음과 같은 문제로 이어졌습니다. 실제 비...

REINDEERS CORE ENGINE DEEP DIVE — PART 8 이번 파트는 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 ...

REINDEERS CORE ENGINE DEEP DIVE — PART 7 REINDEERS 플랫폼은 단순히 WMS와 DVRP를 연결하는 시스템이 아니다. 산업형 3PL · Trading · Fulfillment 환경에서는 “비용 구조의 정확성”이 서비스 품질만큼이나 중요한 요소다. 특히 동남아 지역의 산업 물류 특성상 고객사는 단순 배송비가 아니라 보관료 · 패키지 사용료 · 수입·통관 비용 · 외주 차량 비용 · 반품/폐기 비용 까지 모두 포함된 총 비용 관리를 요구한다. 이에 REINDEERS는 데이터를 기반으로 자동 계산되고 예측되는 AI Cost Optimization Engine 을 구축했다. 46. 비용 엔진이 필요한 근본 이유 산업 물류에서 비용은 단순 계산이 아니다. 보관료는 CBM 기준일 수도 있고, SKU 기준일 수도 있다. 출고비는 피킹 난이도·로케이션·Zone 혼잡도에 따라 달라진다. 배송료는 CBM·중량·거리·시간·차종에 따라 달라진다. 외주 차량 비용은 업체별로 상이하며, 고정 단가가 아니다. 반품/폐기 비용은 유통기한·로트별 재고 흐름과 연동된다. 이런 복잡성을 단순 규칙으로 처리하면 고객사마다 다른 정책을 적용할 수 없고, 실수·과금 누락·중복 청구가 빈번해진다. 따라서 비용 계산 역시 데이터 기반의 엔진 으로 구현해야 한다. 47. 비용 엔진의 핵심 아키텍처 47.1 구조 개요 Cost Engine Core ├─ Storage Fee Module (보관료) ├─ Handling Fee Module (입출고 작업비) ├─ Delivery Fee Module (배송료) ├─ External Carrier Fee (외주 트럭) ├─...

REINDEERS CORE ENGINE DEEP DIVE — PART 6 이번 파트에서는 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·중량 초과 금지 근로 시간·휴게 시간 준수 냉장/위험물/특수 화물...

REINDEERS 플랫폼 확장 아키텍처 — AI 의사결정 보조와 DVRP 기반 3PL의 결합 REINDEERS는 2026년 1월을 기점으로, 기존의 나라별 통합 B2B 무역 플랫폼을 국제 무역의 실제 실행 구조를 모두 흡수하는 서비스 플랫폼 으로 확장한다. 이번 확장의 핵심은 두 가지다. AI를 “자동화 도구”가 아닌 의사결정 보조자 로 배치하는 구조 DVRP 기반 3PL과 무역 플랫폼을 하나의 거래 흐름 로 결합하는 구조 이 글은 REINDEERS가 왜 이 두 가지를 동시에 선택했는지, 그리고 이것이 국제 무역 플랫폼 설계에서 어떤 기술적 의미를 갖는지를 설명한다. 1. 국제 무역의 본질적인 문제 국제 무역은 오랫동안 다음과 같은 방식으로 운영되어 왔다. 견적: 이메일, 메신저, 엑셀 계약: PDF, 스캔 파일 생산·납품 일정: 사람의 기억과 전화 물류: 포워딩 경험 의존 정산: 사후 확인 문제는 이 모든 과정이 하나의 연속된 의사결정 흐름 임에도 불구하고, 각 단계가 서로 단절되어 있다는 점이다. REINDEERS는 이 단절의 원인을 기술적으로 다음과 같이 정의했다. 결정 기준이 데이터로 남지 않는다 이전 판단이 다음 단계로 전달되지 않는다 사람이 모든 비교·검증·정리를 직접 수행한다 이 구조에서는 AI를 단순 자동화 도구로 넣어도 근본적인 개선이 일어나지 않는다. 2. AI를 ‘의사결정 보조자’로 설계한다는 의미 REINDEERS에서 AI는 “대신 결정하는 존재”가 아니다. AI의 역할은 다음과 같이 정의된다. 사람이 결정을 내릴 수 있도록, 모든 선택지를 구조화하고 비교 가능하게 만드는 역할 이를 위해 REINDEERS는 AI를 다음 위치에 배치했다. 견적 요청 구조화 견적서 발행 검증 상품 정보 정규화 포워딩 조건 비교 물류·시공 일정 정합성 검증 즉, AI는 “...

REINDEERS CORE ENGINE DEEP DIVE — PART 5 창고(WMS)와 운송(DVRP) 운영에서 가장 변수가 많은 영역은 사람이다. 출퇴근 패턴, 지각·결근, 갑작스러운 물량 폭주, 고객사의 긴급 출고 요청, 운전기사의 장거리 운행 등 사람 기반 요소는 단순 규칙으로 제어하기 어렵다. REINDEERS는 이 문제를 해결하기 위해 AI 기반 Dynamic Workforce Scheduling Engine 을 구축했다. 이 엔진은 작업량 예측부터 인력 배분, 실시간 스케줄 조정까지 물류 현장에서 발생하는 모든 변수를 계산하여 작업자를 최적의 위치에 배치한다. 28. Dynamic Workforce Scheduling: 기본 개념 Workforce 엔진은 다음 두 가지 핵심 목표를 가진다. ① 물류 작업량의 예측(Predictive Workload Calculation) ② 작업자 자동 배치(Automated Workforce Assignment) 즉, “내일 필요한 인력이 몇 명인지?”를 미리 계산하고, “누가 어떤 업무를 맡아야 하는지?”를 시스템이 자동으로 결정한다. 29. Workload Estimation Engine (작업량 예측 엔진) 작업량 예측은 단순 통계가 아니라 실제 DO/ASN/OSN/재고 이동/반품/폐기/실사 데이터 전체를 이용한 예측 모델 이다. 29.1 예측 모델 입력값 지난 30/60/90일간의 출고량 패턴 고객사별 출고 스케줄(정기출고 / 월말 피크) 유통기한 임박 SKU 증가량 (FEFO 기반) 입고 예약량(ASN 기반) 반품 증가 패턴 직원 휴가/결근율 패턴 차량 가용성(DVRP 연동) Zone별 혼잡도(피킹 동선 분석)...

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 이벤트 전송, 증빙...

REINDEERS CORE ENGINE DEEP DIVE — PART 4 이번 Part 4에서는 REINDEERS WMS의 핵심인 AI 재배치 엔진(AI Relocation Engine) 과 Dynamic Warehouse Optimization(동적 창고 최적화) 의 기술 구조를 다룬다. 이 기능은 실제 운영 현장에서 “비용을 줄이고 처리 속도를 높이며, 재고를 항상 최적 위치에 유지”하게 하는 기술적 핵심이다. 20. AI 재배치 엔진(AI Relocation Engine) AI 재배치 엔진은 매일 또는 특정 이벤트 발생 시, 창고 전체 재고의 최적의 위치를 재계산해 재배치를 제안 하는 역할을 한다. 20.1 재배치가 필요한 이유 재고 회전율 변화 출고 트래픽 증가 또는 감소 신규 고객사 입고 증가 유통기한 임박 SKU 증가 Zone 과부하(피킹 동선 비효율) 이러한 변화는 사람보다 AI가 더 빠르게 감지하고 계산할 수 있다. 20.2 AI 재배치 판단 로직 1. SKU별 회전율 계산 2. 현재 Zone/Bin 점유율 분석 3. 피킹 동선 시뮬레이션 4. FEFO / LOTT(로트) / CBM 제약 적용 5. Zone별 트래픽 분산 계산 6. "재배치 필요 점수" 계산 7. 재배치 작업 자동 생성 20.3 재배치 점수 공식(예시) 모든 점수는 실시간 데이터 기반이다. relocation_score = (turnover_weight * turnover_change_pct) + (distance_weight * avg_picking_distance) + (expiry_weight * expiry_risk_factor) + (traffic_weight * zone_traffic_congestion) ...

REINDEERS CORE ENGINE DEEP DIVE — PART 3 이번 Part 3에서는 REINDEERS 플랫폼의 고급 엔진 아키텍처를 다룬다. 실제 운영에서 필요한 AI 예측 엔진, 트럭 디지털 트윈, 고급 캐시 계층, CDC 기반 실시간 데이터 스트림 등 플랫폼의 “지능화·자동화 기반 기술”을 상세하게 설명한다. 14. AI 예측 엔진(Forecasting Engine) — 출고량·재고회전·배송량 예측 물류 데이터가 누적되기 시작하면 가장 먼저 도입되는 기능이 예측이다. REINDEERS의 예측 엔진은 다음 3가지를 핵심 목표로 둔다. 출고량 예측(Outbound Volume Forecast) 재고 회전율 예측(Inventory Turnover Forecast) 배송량·트럭 수요 예측(Delivery Volume Forecast) 14.1 예측에 사용하는 주요 피쳐(Features) 출고/입고(OSN/ASN) 발행량 고객사별 SKU 사용 패턴 요일·월별 계절성(Seasonality) 리드타임(생산 → 픽업 → 입고 → 출고) 도착지 클러스터(지역 단위 볼륨) 차량 가동률 AI가 수행한 배차 결과(성공/실패/대안 배차) 이렇게 수집된 피쳐는 “전통적 ML 모델”과 “대규모 언어모델 기반 Feature Reasoning”을 결합한 하이브리드 방식으로 처리된다. 14.2 하이브리드 예측 프로세스 Raw Data → Feature Extraction → ML Forecast ↘ LLM Reasoner → Confidence 수정 ML Forecast: LightGBM / CatBoost 기반 시계열 예측 ...

REINDEERS CORE ENGINE DEEP DIVE — PART 2 전 편에서는 재고 할당·직배송 경로 설계·AI Action Schema·RAG 구조 등 물류 시스템의 핵심 알고리즘을 설명했다. 이번 Part 2에서는 REINDEERS 플랫폼의 근본을 지탱하는 배차 엔진, ETA 계산, 이벤트 소싱, 모바일 오프라인 엔진, 멀티테넌시 보안 을 기술적 관점에서 심층적으로 다룬다. 7. AI 배차 엔진(Dispatch Engine) — 비용·시간·적재율을 동시에 계산하는 멀티 목표 알고리즘 배차 엔진은 “배송 DO 생성 후” 자동으로 작동한다. 단일 목적 최적화가 아니라, 아래 4개의 목적을 동시에 평가하는 Multi-Objective Optimization 구조를 갖는다. 7.1 평가 지표(Score Model) score = (w1 * distance_score) + (w2 * eta_score) + (w3 * cbm_score) + (w4 * cost_score) distance_score : 기존 경로에 삽입했을 때 증가하는 총 주행거리 eta_score : 도착 예정시간(ETA) 지연 정도 cbm_score : 적재 가능한지, 적재율이 적절한지 cost_score : 연료 + 인건비 + 트럭 가동 비용 가중치 w1~w4는 회사 정책에 따라 동적으로 변경 가능하다. 7.2 경로 삽입 알고리즘(Route Insertion) 배차 엔진의 핵심은 “진행 중인 트럭의 현재 경로”에 새로운 DO를 삽입할 수 있는지 계산하는 것이다. 기존 경로: [A → B → C] 신규 DO: D 후보: 1) A → D → B → C 2) A → B → D → C 3) A → B → C → D 각 삽입 케이스의 ETA/거리...

  🎉 REINDEERS 공식 오픈 — 2025년 12월 1일 동남아 산업무역·3PL·AI 자동화 플랫폼의 새로운 시작 오늘, 저희 REINDEERS는 4년간의 준비를 마치고 드디어 첫 베타 오픈을 맞이했습니다. 이 플랫폼은 단순한 쇼핑몰이나 물류 솔루션이 아닙니다. “무역의 시작부터 공장 생산, 인증, 운송, 창고, 배송, 정산까지” 동남아 제조·유통 산업 전반을 하나의 기술로 연결하는 차세대 산업 플랫폼 입니다. REINDEERS는 지난 4년 동안 4번의 팀 재구성, 수십 차례의 구조 변경, 8번에 걸친 주문 엔진 재개발, 한국·태국·중국 개발팀의 공동 설계, AI RAG·MQ·MCP 등 최신 기술의 직접 구현 이라는 쉽지 않은 여정을 지나 오늘에 이르렀습니다. 이 영상은 “우리가 어떤 길을 걸어왔고, 무엇을 해결하고자 했는지” 그리고 “동남아 제조업이 앞으로 어떻게 변화할지” 그 출발점을 담아 제작했습니다. 🔥 이번 오픈의 의미 이제 REINDEERS는 단순한 베타 테스트가 아니라 실제로 산업의 문제를 해결하기 위한 첫걸음 을 내딛습니다. ✔ 태국·말레이시아·한국·중국을 연결하는 B2B 무역 자동화 ✔ WMS + DVRP + Trading이 단일 구조로 작동하는 최초의 플랫폼 ✔ AI 기반 카테고리 자동 분류, 견적 정규화, 업무 자동 생성 ✔ 물류·무역 운영팀이 실제 업무에 바로 사용할 수 있는 SaaS 서비스 오늘의 오픈은 “완성”이 아니라, 아시아 산업 디지털 전환의 출발점 입니다. 🚀 Next Step (2026년 3월 1일) REINDEERS는 2026년 3월, 또 하나의 혁신인 DVRP 경로 최적화 물류 플랫폼 을 정식 오픈합니다. AI 기반 실시간 배차, 공장–창고–배송까지 이어지는 완전 자동화 물류 엔진이 추가됩니다. 🌏 마지막으로 REINDEERS는 “산업 인프라를 다시 설계한다”는 목표로 시작되었습니다. 오늘의 오픈은 그...

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

REINDEERS CORE ENGINE DEEP DIVE — 재고할당·직배송·AI 지시엔진·RAG 인덱싱까지 REINDEERS 플랫폼의 핵심은 단순한 화면이나 기능의 집합이 아니라, “입고 → 재고 → 출고 → 배차 → 배송 → 정산” 전체를 하나의 상태머신 위에서 자동으로 운용하는 Core Logistics Engine 이다. 이 문서는 그 중에서도 가장 중요한 4개의 심층 기술 요소, 즉 재고 할당 알고리즘 · 직배송(Direct DO) 고급 라우팅 · AI Orchestrator Action Schema · RAG 벡터 인덱싱 전략 을 개발자 기준으로 상세히 기록한 기술 문서이다. 1. 재고 할당 엔진의 알고리즘 상세 출고 ASN(OSN)이 승인되면, 시스템은 자동으로 재고를 분석하여 창고별 DO를 생성한다. 이 과정은 다음 4개의 핵심 알고리즘을 기반으로 한다. 1.1 FEFO(유통기한 우선) 알고리즘 재고 할당의 최우선 규칙은 FEFO이다. 1. SKU별로 모든 로트 수집 2. 유통기한 오름차순으로 정렬 3. 출고 요청 수량을 상위 로트부터 채움 4. 유통기한 임박 로트는 경고 플래그 기록 FEFO 적용 예시 출고 요청: 120개 재고: LOT-A(2025-03-01): 50개 LOT-B(2025-04-01): 70개 LOT-C(2025-06-01): 100개 → A 50 + B 70 = 120 (C는 미사용) 1.2 거리 우선 알고리즘 (Warehouse Distance Ordering) 출고지(창고)와 고객 배송지 간의 거리 차이는 DO 생성에서 중요한 요소다. 거리 계산은 Haversine Formula 를 기반으로 한다. // Haversine Distance d = 2r * arcsin( sqrt( sin²((lat2-lat1...