Skip to main content

레인디어스 플랫폼 구조 전환과 AI 기반 물류 생태계 확장

레인디어스 플랫폼은 초기 단계에서 구매자(Buyer) - 레인디어스 - 공급사(Supplier)를 연결하는 구조로 출발했다. 이 구조에서 레인디어스는 단순 중개를 넘어, 선사 스케줄 정보를 수집-표준화하고 이를 기반으로 포워딩 업무를 자동화하여 "정보 비대칭을 줄이고 의사결정 속도를 높이는" 방향을 목표로 했다.

그러나 실 운영 단계에서 현실의 견적 형성 구조와 플랫폼의 자동화 방식 사이에 괴리가 발생했고, 이는 비용 구조 및 운영 안정성 측면에서 개선이 필요한 지점으로 드러났다. 레인디어스는 이 문제를 해결하기 위해 플랫폼 구조를 재정의하고, 포워딩 업체가 직접 참여하는 확장형 플랫폼으로 전환했다.

1) 기존 구조의 한계: 스케줄 기반 자동화의 현실 괴리

포워딩 견적은 단순히 선사 스케줄만으로 결정되지 않는다. 견적은 다양한 변수를 통해 시장 참여자에 의해 실시간으로 형성된다. 예를 들어 다음과 같은 요소가 견적에 직접적인 영향을 준다.

  • 선복(스페이스) 수급 상황과 노선별 수요 변화
  • 시기별 계약 단가, 단기 스팟 운임 변동
  • 포워딩 업체별 확보한 스페이스/네트워크/운영 전략
  • 긴급 출항, 지연, 환적 조건 등 일정 리스크

레인디어스는 이 데이터를 확보하기 위해 NCP Cloud Functions 기반의 스크래퍼를 운영하여 HMM, KMTC, SM Line 등 주요 선사의 스케줄 정보를 자동 수집해왔다. 각 선사별 크롤러는 10분 타임아웃으로 실행되며, 수집된 데이터는 Reindeers API로 전송되어 노선별 스케줄 DB를 구성한다. 그러나 이렇게 수집된 스케줄 데이터만으로는 실제 운임을 산정할 수 없었다.

결과적으로, 플랫폼 내부에서 스케줄 기반으로 자동 산출한 견적과 실제 포워딩 업체의 견적 간 차이가 반복적으로 발생했고, 이는 운영 측면에서 다음과 같은 문제로 이어졌다.

  • 실제 비용과 불일치하는 견적으로 인한 의사결정 왜곡
  • 수동 보정 업무 증가 및 운영 리소스 소모
  • 포워딩 견적의 동적 변화를 플랫폼이 "계산"하기 어려운 구조

25,000건 이상의 거래 데이터를 분석한 결과, 스케줄 기반 자동 견적과 실제 포워딩 견적 사이의 괴리가 특히 성수기와 긴급 출항 시에 크게 벌어지는 패턴을 확인했다. 이 문제를 보정하기 위한 수동 작업이 운영팀의 주요 업무가 되어버린 상황이었다.

2) 플랫폼 재정의: 포워딩 참여형 견적 경쟁 구조로 전환

레인디어스는 "견적을 계산하는 플랫폼"에서 "견적이 형성되는 시장을 제공하는 플랫폼"으로 방향을 전환했다. 새로운 구조의 핵심은 구매자-공급사 간 거래 조건이 먼저 확정된 뒤, 물류 견적을 포워딩 업체가 경쟁적으로 제안하는 방식이다.

새로운 주문-견적 흐름
  1. 구매자-공급사 간 상품/조건 견적 및 계약(거래 조건) 확정
  2. 확정된 조건을 기준으로 주문(Order) 생성
  3. 주문을 기준으로 포워딩 업체 견적 경쟁 참여
  4. 구매자는 제안된 조건을 비교 후 포워딩 업체 선택
  5. 선정된 조건으로 이후 생산-납품-FOB-선사/스페이스-통관-물류 프로세스 진행

이 방식은 실제 시장 가격을 그대로 반영할 수 있으며, 견적 형성과 선택 과정이 투명해진다. 동시에 포워딩 업체는 새로운 참여 채널을 얻고, 플랫폼은 참여자 확장과 네트워크 효과를 확보할 수 있는 구조가 된다. 현재 30곳 이상의 포워딩 업체가 레인디어스 플랫폼에 참여하고 있으며, 이 업체들이 실시간으로 견적을 제출하면 구매자는 운임, 리드타임, 선사, 환적 조건 등을 한 화면에서 비교할 수 있다.

3) 내부 운영의 변화: 리소스를 AI 중심으로 전환

구조 전환 이후 레인디어스 내부의 역할도 달라졌다. 레인디어스는 특정 견적의 산출자라기보다, 견적 확정과 전 과정 연결을 관리하는 중립적 오케스트레이터로 이동했다. 운영 리소스는 반복적-규칙 기반 업무에서 벗어나 AI 기반 자동화 로직으로 전환되었다.

구체적으로, 환율 조회는 4개국(태국, 한국, 중국, 말레이시아) 은행 사이트에서 자동 수집되어 API로 전송된다. 방콕은행, 하나은행, 중국은행, 메이뱅크 등의 환율 데이터가 매일 자동으로 갱신되고, 포워딩 견적 비교 시 환율 변동 리스크까지 함께 표시된다. 선사 스케줄 역시 자동 크롤링을 통해 수집되며, AI는 이 데이터를 기반으로 포워딩 업체들이 제출한 견적의 일정 정합성을 자동으로 검증한다.

플랫폼은 단절된 기능들의 묶음이 아니라, 전체 흐름을 상태(State) 기반으로 연속 관리한다. 이를 통해 예외 발생 시에도 단계별 책임과 처리 경로가 명확해지고, 자동화-예측 적용이 가능한 기반이 된다. 각 상태 전이는 이벤트로 기록되며, Telegram 알림 시스템을 통해 운영팀에 실시간으로 전달된다. 정상 흐름에서는 알림이 발생하지 않고, 예외가 감지될 때만 운영팀에 통보되는 구조다.

4) 연결형 프로세스 구축: 견적부터 통관-물류까지

현재 레인디어스는 다음과 같은 전 과정을 "끊김 없이" 연결하는 플랫폼을 지향한다. 각 단계는 독립된 이벤트처럼 보이지만, 플랫폼 내부에서는 데이터-상태가 이어지며 하나의 흐름으로 관리된다.

  1. 상품 및 거래 조건 견적 확정
  2. 주문(Order) 생성
  3. 생산 진행 및 납품 일정 관리
  4. 인계(FOB) 처리
  5. 선사 및 스페이스 확정
  6. 포워딩 및 국제 물류 진행
  7. 통관
  8. 국내 물류 및 최종 배송

이 8단계가 기존에는 이메일, 엑셀, 전화로 단절된 채 처리되었다. 레인디어스는 각 단계를 PO(Purchase Order)라는 단일 기준 객체에 연결하여, 1번 단계의 견적 조건이 8번 단계의 배송 조건까지 데이터로 이어지도록 설계했다. 기술적으로는 Turso(LibSQL) 기반의 데이터베이스에서 PO를 중심으로 관계형 데이터가 연결되고, Cloudflare Workers가 각 단계 전이 시 후속 액션을 트리거하는 구조다. 각 단계의 상태 전이는 이벤트로 기록되며, 이 이벤트 로그가 곧 거래의 감사 추적(audit trail) 역할을 한다. 한국, 태국, 말레이시아, 중국 4개국에 걸친 크로스보더 거래에서는 각 국가의 통관 요건과 서류 형식이 다르기 때문에, 단계별 데이터 연결이 특히 중요하다. 예를 들어 3번 단계(생산 진행)에서 확정된 제품 규격과 수량이 7번 단계(통관)의 인보이스와 패킹리스트에 자동으로 반영되어야 한다. 이 연결이 끊어지면 통관 지연이 발생하고, 이는 곧 비용 손실로 이어진다.

5) DVRP 오픈: 창고-배차 관제를 통한 End-to-End 확장

레인디어스는 국제 물류 이후의 국내 운영 영역까지 자연스럽게 연결하기 위해, DVRP(Dynamic Vehicle Routing & Planning) 기반의 창고 및 배차 관제 AI 플랫폼을 오픈하고 제공한다. DVRP는 창고 운영(WMS)과 운송(배차)을 하나의 의사결정 체계로 묶어, 물류의 마지막 구간까지 플랫폼 안에서 연결되도록 설계되었다.

DVRP의 핵심은 GPS 기반 실시간 트럭 위치와 교통 트래픽 정보를 반영한 AI 자동 배차 및 동적 경로 최적화다. 단순히 "가까운 차량"을 배정하는 것이 아니라, 운행 조건과 제약을 종합해 최적의 결정을 자동으로 제안한다.

  • 실시간 GPS 기반 위치 파악 및 운행 상태 추적
  • 교통 정체/우회 정보 반영 경로 재계산
  • 적재 용량, 시간 제약, 근무 시간 등 운영 제약 반영
  • 지연/고장 발생 시 재배차(대체 차량) 의사결정 지원
  • 창고 작업(입출고)과 배차 결과를 연계해 흐름 최적화

DVRP는 2026년 3월 베타 서비스를 시작했다. 레인디어스의 기존 거래 데이터와 연결되어, 국제 물류가 완료된 화물이 국내 창고에 입고되는 시점부터 DVRP가 자동으로 배송 계획을 수립한다. 이 과정에서 별도의 데이터 입력이 필요하지 않다. PO에 이미 기록된 수량, 중량, 배송지 정보가 그대로 활용되기 때문이다.

결과적으로 레인디어스는 수출입 및 견적 - 발주 - 생산 - 납품 - 포워딩 - 통관 - 물류(배차-창고)까지 연결되는 연결형 플랫폼으로 진화하고 있다. 4,300개 이상의 파트너가 이 흐름 안에서 각자의 역할을 수행하며, 4개국(한국, 태국, 말레이시아, 중국)에 걸친 크로스보더 거래가 하나의 플랫폼에서 처리된다.

6) 일정: 단계별 시장 참여 및 서비스 오픈

  • 1월 중순: 포워딩 업체의 시장 참여 시작
  • 3월: DVRP 베타 서비스 시작
  • 4~5월: POP 플랫폼 베타 오픈

마무리

이번 구조 전환은 단순한 기능 추가가 아니라, 레인디어스가 실제 시장 구조를 그대로 수용하면서도 이를 기술로 연결해 운영 효율을 만드는 방향으로 진화하는 과정이다. 2015년 IMARKET Thailand 설립 이후 10년간의 운영 경험이, "시장을 계산하려 하지 말고 시장이 작동하는 구조를 만들라"는 교훈으로 이어졌다. AI는 운영을 대체하는 도구가 아니라, 복잡한 현실의 변수를 감당하고 최적의 흐름을 만들기 위한 핵심 인프라로 자리 잡고 있다.

관련 글

Labels:

Popular posts from this blog

11년의 무역 데이터가 AI를 만든다 , RAG 지식 베이스 구축 과정

AI를 제품에 넣겠다고 하면 대부분 두 가지 중 하나를 떠올린다. GPT를 fine-tuning하거나, RAG를 쓰거나. 우리는 RAG를 택했다. 이유가 있다. REINDEERS는 2015년 IMARKET Thailand 설립 이후 약 11년간 동남아시아에서 B2B 무역을 해왔다. 25,000건 이상의 거래, 4,300개 이상의 파트너, 4개국의 규제 데이터. 이 데이터가 우리의 경쟁력이다. 문제는 이 데이터를 AI가 활용할 수 있는 형태로 만드는 과정이 생각보다 훨씬 복잡했다는 거다. 이 글은 그 과정에 대한 기록이다. 한 가지를 먼저 밝히고 시작한다. 이 RAG 지식 베이스는 단순히 "챗봇이 무역 지식을 참조하는 데이터 창고"가 아니다. REINDEERS와 POP, DVRP는 지금 AI로 전환되는 구조 위에 올라서 있다. 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 수행한다. 이 Agent들 , 구매 Agent, 물류 Agent, 통관 Agent, 재무 Agent , 이 사람 대신 판단을 내릴 때 "왜 이렇게 결정했는가"를 반드시 설명할 수 있어야 한다. 그 설명의 출처가 바로 이 RAG 지식 베이스다. 11년의 무역 데이터는 Agent가 환각 없이 결정을 내릴 수 있는 유일한 근거다. RAG를 선택한 이유 먼저 RAG(Retrieval-Augmented Generation)가 뭔지를 간단히 정리하자. LLM에 질문을 던질 때, 질문만 보내는 게 아니라 관련 데이터를 함께 보내는 방식이다. "태국산 베어링 수입 단가가 얼마야?"라고 물으면, 우리 데이터베이스에서 관련 거래 이력을 찾아서 LLM에 컨텍스트로 넘긴다. LLM은 그 컨텍스트를 바탕으로 답을 생성한다. Fine-tuning을 선택하지 않은 이유는 명확하다. 무역 데이터는 계속 바뀐다. 베어링 단가는 분기마다 변동한다. 태국 FDA 규제는 수시로 개정된다. 선사 운임은 매...
Read more

B2B 견적의 AI Agent화 , 고객사·공급사·포워더가 AI로 견적을 주고받는 구조

B2B 거래에서 견적은 단순한 가격표가 아니다. 바이어의 구매 이력, 공급사의 재고 상황, 물류 비용, 인코텀즈, 납기일, 결제 조건 , 이 모든 변수가 얽힌 협상의 산물이다. 현재 이 과정은 이메일과 전화, 스프레드시트로 이루어진다. 바이어가 RFQ를 보내면 공급사가 검토하고, 포워더에게 물류 견적을 받아 합산하고, 다시 바이어에게 회신한다. 건당 수일이 걸리는 이 과정을 AI Agent가 대신할 수 있다면 어떨까. REINDEERS는 이 구조를 설계하고 있다. 먼저 이 글의 전제를 분명히 한다. REINDEERS·POP·DVRP는 지금 AI로 전환되는 구조 위에 올라서 있다. 조직도 안에서 직원을 등록할 때 '사람', 'AI Agent', '로봇' 중에서 선택할 수 있고, 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 수행한다. 이 글의 Buyer Agent / Supplier Agent / Forwarder Agent는 외부 AI 도구가 아니라, 각 회사의 조직도 안에 '구매팀 담당자', '영업팀 담당자', '물류팀 담당자'로 실제 등록되는 AI 직원이다. 사람 직원과 동일한 권한 모델, 동일한 예산 한도, 동일한 감사 로그 위에서 일한다. B2B 견적의 AI Agent 간 통신 시퀀스 # Buyer Agent → Supplier Agent → Forwarder Agent 1 RFQ 발송 → RFQ 수신 2 물류 견적 요청 → 요청 수신 3 견적 수신 ← 상품 견적 발송 4 물류 견적 수신 ← 물류 견적 발송 ★ 비교표 생성 → 담당자 승인 5 PO 발행 → 주문 확정 6 부킹 요청 → 부킹 확정 왜 견적에 AI Agent인가 견적 업무가 느린 이유는 복잡해서가 아니다. 반복적인 정보 수집과 조합이 사람의 시간을 잡아먹기 때문이다. 공급사 담당자가 바이어의 과거 주문 이력을 ...
Read more

Reindeers Workflow: B2B 파트너 업무 효율과 자동화를 위한 워크플로우 플랫폼

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