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