견적·주문 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) : 공급사에 전달되는 요청 단위(분기 가능)
QB (Quote Response) : 공급사의 응답 단위(복수 가능)

핵심은 이름이 아니라 책임 분리다. PQ는 “의사결정의 출발점”, QA는 “요청의 실행 단위”, QB는 “조건 제안 단위”로 역할이 다르다. 이렇게 분리되면 UI는 자연스럽게 한 번의 요청에서 여러 응답이 나오는 구조를 ‘목록’이 아니라 ‘분기’로 보여줄 수 있다.

그리고 이 분기 구조가 생기면, UX의 핵심은 “비교”가 아니라 “선택”이 된다. QB는 여러 개가 존재할 수 있지만, 주문 생성의 기준이 되는 것은 확정된 단 하나의 QB다. 그래서 UI는 확정된 QB를 명확히 고정하고, 사용자가 “지금 결정이 끝났는지/아직 진행 중인지”를 화면만 보고 파악할 수 있도록 바뀌었다.

3) 주문 흐름 정렬: PO 중심, DO 분기, 포워딩 선택, 결제 연결

견적이 ‘결정’을 담는다면, 주문은 ‘실행’을 담는다. REINDEERS에서 주문 구조는 다음과 같이 정리되어 있다.

PO : 주문의 기준 문서이자 실행의 루트
DO : 실행 단위(해상/항공/트럭/직배송 등으로 분기 가능)
FWD : DO 단위로 연결되는 포워딩 견적/선택
Pay : 확정된 실행 결과를 기준으로 발생하는 결제

이번 개편에서는 이 구조를 “표”가 아니라 “흐름”으로 표현하는 데 집중했다. 결과적으로 사용자는 다음을 즉시 이해할 수 있다.

이 주문은 하나의 PO에서 시작했고
실행 방식에 따라 여러 DO로 분기되었으며
각 DO에는 포워딩 선택이 붙을 수 있고
결제는 ‘선택된 실행 결과’를 기준으로 발생한다

이 흐름 표현은 단지 UX를 좋아지게 하는 정도가 아니라, 다음 단계(자동화/최적화/스케줄링)를 위한 “정합성 있는 구조”를 화면에서 고정하는 효과가 있다.

4) 기술 구현 에피소드 1: “확정”은 버튼 이벤트가 아니라 ‘결정 트랜잭션’이다

UI를 흐름으로 바꾸는 순간, 가장 먼저 터지는 문제는 “동시성”이다. 특히 ‘QB 확정’은 단순 클릭 이벤트처럼 보이지만, 사실상 시스템의 결정 지점이다.

가장 위험한 케이스는 이렇다.

사용자가 확정 버튼을 두 번 누르거나
네트워크 지연으로 동일 요청이 재전송되거나
여러 담당자가 동시에 같은 QA를 처리하는 경우

이 상황에서 확정 로직이 idempotent 하지 않으면, 동일 QB가 중복 확정되거나, 심지어 PO가 중복 생성될 수도 있다. 그래서 확정 처리는 UI가 아니라 서버에서 결정 트랜잭션으로 다뤘다.

확정 API는 idempotency key 기반으로 중복 요청을 무시
확정 상태는 단일 소스 오브 트루스로 고정(단일 QB만 확정 가능)
확정 성공 이후에만 후속 작업(PO 생성/DO 생성) 이벤트가 발생
UI는 “성공 응답”이 아닌 “상태 재조회” 기반으로 화면을 갱신

이 작업을 거치고 나서야, UI는 “분기 → 선택 → 확정”을 안정적으로 보여줄 수 있었다. 흐름 UI는 그림이 아니라 원자적 결정 처리 위에서만 성립한다.

5) 기술 구현 에피소드 2: 분기 흐름 렌더링을 위한 ‘그래프 모델’

이번 UI의 가장 큰 변화는 “선”이다. 그 선은 단순 SVG 장식이 아니라, 사용자가 흐름을 이해하기 위한 핵심 정보다. 하지만 데이터가 단순 리스트라면 선을 그릴 수 없다. 그래서 화면 렌더링을 위해 내부적으로는 흐름을 그래프 모델로 변환했다.

개념적으로는 다음과 같은 구조다.

Node: PQ
  └─ Node: QA (1..N)
       └─ Node: QB (0..N)
            └─ (selected QB) → Node: PO
                 └─ Node: DO (1..N)
                      └─ Node: FWD (0..N)
                           └─ (selected FWD) → Node: Pay

UI는 이 그래프를 그대로 노출한다. 즉, 사용자가 보는 화면은 “문서 리스트”가 아니라, 각 객체가 어떻게 연결되고 분기되는지에 대한 관계 그래프다.

이 그래프 모델을 만들면서 추가로 필요했던 것은 “정렬 규칙”이다. 예를 들어 QB가 여러 개일 때:

최신 응답 우선인지
가격 기준 정렬인지
리드타임 기준 정렬인지
확정 후보를 상단 고정할지

우리는 “정렬 기준”을 UI 옵션이 아니라 도메인 규칙으로 두었다. 그래야 담당자마다 화면이 달라지지 않고, 의사결정 기록이 일관되게 남는다.

6) 기술 구현 에피소드 3: 상태 머신 정리 — ‘진행중’이 가장 위험하다

실무에서 가장 위험한 상태는 ‘진행중’이다. 모두가 진행중이라고 생각하지만, 실제로는 “무엇이 완료되었고 무엇이 미완료인지”가 다르기 때문이다. 그래서 이번 개편 과정에서 견적/주문 관련 상태를 다음 기준으로 정리했다.

상태는 “사람의 느낌”이 아니라 “조건”으로 정의한다
상태 전이는 단방향(되돌림은 별도 취소/재오픈 이벤트)
상태는 화면 필터가 아니라, 후속 로직 실행 조건이 된다

예를 들어 “QA 진행중”은 단지 시간이 흐른 상태가 아니다.

요청이 공급사에게 전달되었고
응답(QB)이 0개 이상 들어왔으며
확정된 QB가 아직 없는 상태

이렇게 조건을 고정하면, UI는 상태를 예쁘게 보여주는 데서 끝나지 않고, 실제 업무의 기준이 된다.

7) DVRP BETA로 이어지는 이유: 실행 레이어는 ‘흐름 정합성’ 위에 올라간다

현재는 DVRP 2월 중순 BETA를 위한 개발이 진행 중이다. DVRP는 단순히 “차량 배차”만 하는 시스템이 아니라, 주문 실행(픽업/입고/출고/직배송)의 흐름을 운영 레벨에서 안정화시키는 레이어다.

따라서 DVRP를 붙이기 전에 반드시 선행돼야 할 조건이 있다.

견적 확정의 기준 데이터가 명확해야 하고
PO에서 DO 분기가 정확히 모델링되어야 하며
포워딩 선택과 결제 기준이 일관되어야 한다

이번 UI/UX 개편은 이 조건을 “화면에서 확인 가능한 형태”로 만든 작업이다. 즉, 개발팀 입장에서는 DVRP 개발의 리스크를 줄이는 선행 안정화 단계로도 의미가 크다.

8) 다음 작업: UI/UX는 끝이 아니라 ‘운영 자동화’의 시작점

UI/UX 개편이 끝났다고 해서 일이 끝난 것은 아니다. 오히려 이제부터가 시작이다. 흐름이 화면에서 고정되면, 다음 단계는 이 흐름을 “자동화 가능한 형태”로 만드는 일이다.

확정 이후 자동 생성되는 문서/서류의 정확도
DO 분기 기준의 표준화(노선/운송수단/시간제약)
포워딩 견적 수집과 비교의 자동화(운영 정책화)
결제/정산 이벤트와 상태 머신의 결합
DVRP와의 연결을 위한 실행 이벤트 표준(픽업/입고/출고/직배송)

이 방향이 정리되어 있기 때문에, 지금 시점의 UI/UX 개편은 단순 개선이 아니다. REINDEERS가 거래 구조를 정리하고, 다음 단계인 DVRP 실행 레이어로 넘어가기 위한 기반을 화면에서 확정한 기록이다.

Blog of Reindeers

Search This Blog