Blog

레인디어스 플랫폼은 처음부터 단순한 B2B 거래 플랫폼을 목표로 설계된 것은 아니었다. 글로벌 유통, 제조, 생산, 물류를 연결하는 플랫폼을 만들다 보니 자연스럽게 하나의 질문에 도달하게 되었다. "기업의 실제 업무는 어디에서 이루어지고 있는가?" 견적 요청, 공급사 커뮤니케이션, 생산 일정 조정, 물류 일정 관리, 그리고 제안서나 사업계획서 같은 문서 작성까지. 기업의 대부분의 업무는 결국 데이터와 문서, 그리고 반복적인 프로세스 안에서 이루어진다. 4,300개 이상의 파트너사가 레인디어스 플랫폼에서 거래를 진행하면서, 거래 이외의 업무 영역에서도 동일한 수준의 자동화를 요청하는 경우가 늘어났다. 이 과정에서 우리는 한 가지 명확한 사실을 발견했다. 거래 플랫폼만으로는 기업의 업무를 충분히 지원할 수 없다는 것 이다. 그래서 레인디어스는 거래 플랫폼을 넘어 AI 기반 업무 플랫폼 으로 확장하기 시작했다. 이 확장의 첫 번째 결과물이 Document AI와 Workflow AI다. Document AI - 문서를 작성하는 방식을 바꾸다 기업 내부에서 가장 많은 시간을 소비하는 업무 중 하나는 문서 작성이다. 제안서 사업계획서 IR 자료 기술 문서 보고서 정책 문서 이러한 문서들은 대부분 일정한 구조와 패턴을 가지고 있지만, 매번 사람이 처음부터 작성해야 하는 경우가 많다. 특히 B2B 무역 업종에서는 국가별로 요구되는 서류 양식이 다르고, 언어도 한국어, 태국어, 영어, 중국어가 혼재되어 있어 문서 작성의 난이도가 높다. 레인디어스는 이 문제를 해결하기 위해 Document AI Agent 를 개발했다. Document AI는 단순히 텍스트를 생성하는 도구가 아니라 기업 내부에서 발생하는 다양한 문서를 자동으로 작성할 수 있는 문서 생산 시스템 이다. doc.reindeers.ai에서 운영되고 있는 이 시스템은 다음과 같은 기술 구조로 동작한다. LLM 기반...

플랫폼에 AI를 도입한다고 하면 흔히 "자동화"나 "대체"를 떠올린다. 하지만 레인디어스에서의 AI는 애초부터 사람을 대신하는 존재로 설계되지 않았다. 우리가 정의한 AI의 역할은 명확하다. 결정을 내리는 주체가 아니라, 결정을 가능하게 만드는 보조자 다. 왜 '결정형 AI'를 선택하지 않았는가 국제 무역과 물류 영역에서 완전 자동 의사결정은 기술적 문제 이전에 책임 구조의 붕괴 를 가져온다. 견적이 잘못되었을 때 책임은 누구에게 있는가 포워딩 선택이 실패했을 때 수정 권한은 누구에게 있는가 납기 지연이 발생했을 때 AI의 판단을 되돌릴 수 있는가 이 질문들에 명확히 답할 수 없다면, AI는 자동화 도구가 아니라 리스크 증폭기가 된다. 그래서 레인디어스는 AI를 "결정 엔진"으로 두지 않았다. 여기에는 규제적 현실도 크게 작용한다. 국제 무역은 국가별 수출입 규제, 관세율, 인증 요건이 얽혀있다. 태국의 TISI 인증, 한국의 KC 마크, 중국의 CCC 인증 등 각 국가의 규제 기관은 "누가 이 결정을 내렸는가"에 대해 명확한 책임 소재를 요구한다. AI가 자동으로 통관 서류를 작성하거나 인증 요건을 판단했을 때, 오류가 발생하면 규제 기관은 해당 결정의 책임자를 추적한다. "알고리즘이 판단했다"는 답변은 어느 나라의 관세청에서도 통하지 않는다. 신뢰 측면도 있다. 4,300개 이상의 파트너사가 연결된 B2B 플랫폼에서, AI가 견적 금액을 자동 결정하거나 공급사를 자동 선택했다면, 그 판단에 대한 불신은 곧 플랫폼 자체에 대한 불신으로 이어진다. B2B 거래에서 신뢰는 한 번 무너지면 복구하기 어렵다. 특히 $130B 규모의 시장에서 거래 한 건의 금액이 수만 달러에 달할 때, "AI가 알아서 처리합니다"라는 메시지는 안심이 아니라 불안의 원인이 된다. AI 개입의 기준: '...

플랫폼의 UI/UX를 개편했다고 하면 흔히 디자인 변경이나 사용성 개선을 떠올린다. 하지만 이번 레인디어스 플랫폼의 UI/UX 개편은 그런 종류의 작업이 아니었다. 화면은 결과였고, 실제 변경의 중심은 주문과 견적을 해석하는 내부 구조 였다. 고객사, 공급사, 포워딩이 동시에 사용하는 플랫폼에서 UI는 단순한 인터페이스가 아니라 각 주체가 현재 상황을 어떻게 인식하는지 를 결정한다. 이 인식이 어긋나면, 기술적으로는 정상이어도 운영은 항상 충돌한다. 레인디어스에는 바이어 2,500곳 이상과 공급사 1,800곳 이상, 포워딩 업체 30곳 이상이 참여하고 있다. 이 4,300개 이상의 파트너가 동일한 주문을 서로 다른 관점에서 바라본다는 것은, 화면 하나의 문제가 곧 운영 전체의 문제가 된다는 뜻이다. 문제의 시작: 상태는 같았지만, 의미는 달랐다 기존 UI에서 가장 심각했던 문제는 같은 주문을 보고 있음에도 각 사용자가 전혀 다른 단계라고 인식 한다는 점이었다. 고객사 화면에서는 "주문 완료" 공급사 화면에서는 "확정 전" 포워딩 화면에서는 "조건 미정" 데이터상 상태 값은 일치했지만, 그 상태가 의미하는 바는 사용자 역할마다 달랐다. 이는 단순한 UI 문제처럼 보였지만, 실제로는 주문 흐름 자체가 단선 구조로 설계되어 있었기 때문 이었다. 기존에는 하나의 상태 필드가 모든 역할에 동일하게 노출되었다. ORDER_PLACED 라는 상태가 구매자에게는 "주문을 넣었으니 기다리면 된다"였지만, 공급사에게는 "아직 내가 수락하지 않은 요청"이었고, 포워딩 업체에게는 "물류 조건이 아직 정의되지 않은 건"이었다. 하나의 상태 값이 세 가지 해석을 만들어내고 있었다. UI 개편의 전제 조건: Draft 개념의 도입 UI를 바꾸기 전에 먼저 한 일은, 주문과 물류 흐름을 다시 정의하는 것이었다. 모든 프로세...

고객·공급사·포워딩이 '같은 화면'을 보게 되기까지 플랫폼을 오래 운영하다 보면, 기술보다 더 복잡해지는 것이 있다. 그것은 기능도 아니고, 트래픽도 아니다. 관계 다. REINDEERS 플랫폼 역시 마찬가지였다. 고객사, 공급사, 포워딩. 각각은 분명 자신의 역할을 충실히 수행하고 있었지만, 플랫폼 안에서는 항상 어딘가 어긋나 있었다. 고객사는 "견적을 요청했다"고 생각했고, 공급사는 "주문이 확정되지 않았다"고 말했으며, 포워딩은 "물류 조건이 확정되지 않았다"고 답했다. 문제는 누구의 잘못도 아니었다. 문제는 각자가 서로 다른 기준점에서 같은 주문을 바라보고 있었다는 것 이었다. 같은 주문, 다른 해석 -- 기존 데이터 모델의 한계 초기의 구조에서 가장 큰 문제는 견적 - 주문 - 물류가 단선적인 흐름 으로 설계되어 있었다는 점이다. 현실의 무역에서는 이 세 단계가 결코 직선으로 이어지지 않는다. 견적은 여러 번 바뀌고 주문은 조건부로 확정되며 물류는 생산과 일정에 따라 다시 재조정된다 하지만 시스템은 이를 "한 번 정해지면 끝나는 단계"로 취급했다. 그 결과, 주문 하나를 두고 상태 값은 맞는데 의미는 다른 상황 이 반복해서 발생했다. 기존 데이터 모델을 구체적으로 보면 이렇다. Order라는 단일 엔티티가 견적부터 배송 완료까지의 모든 상태를 관리했다. status 필드 하나가 quoted , confirmed , in_production , shipped , delivered 를 순차적으로 거치는 구조였다. 문제는 현실에서 하나의 PO에 대해 여러 번의 배송이 발생할 수 있다는 점이었다. 공급사가 생산 완료된 물량부터 분할 배송하는 경우, 기존 모델에서는 Order의 status를 shipped 로 바꿔야 하는데, 아직 생산 중인 물량도 남아있었다. partially_shipped 같은 중간 상...

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를 구성한다. 그러나 이렇게 수집된 스케줄 데이터만으로는 실제 운임을 산정할 수 없었다. 결과적으로, 플랫폼 내부에서 스케줄 기반으로 자동 산출한 견적과 실제 포워딩 업체의 견적 간 차이가 반복적으로 발생했고, 이는 운영 측면에서 다음과 같은 문제로 이어졌다. 실제 비용과 불일치하는 견적으로 인한 의사결정 왜곡 수동 보정 업무 증가 및 운영 리소스 소모 ...