Blog

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