UI/UX 개편 기술 에피소드 — 화면을 바꾼 것이 아니라, 구조를 바꾸었다
플랫폼의 UI/UX를 개편했다고 하면 흔히 디자인 변경이나 사용성 개선을 떠올린다. 하지만 이번 레인디어스 플랫폼의 UI/UX 개편은 그런 종류의 작업이 아니었다. 화면은 결과였고, 실제 변경의 중심은 주문과 견적을 해석하는 내부 구조였다.
고객사, 공급사, 포워딩이 동시에 사용하는 플랫폼에서 UI는 단순한 인터페이스가 아니라 각 주체가 현재 상황을 어떻게 인식하는지를 결정한다. 이 인식이 어긋나면, 기술적으로는 정상이어도 운영은 항상 충돌한다.
문제의 시작: 상태는 같았지만, 의미는 달랐다
기존 UI에서 가장 심각했던 문제는 같은 주문을 보고 있음에도 각 사용자가 전혀 다른 단계라고 인식한다는 점이었다.
- 고객사 화면에서는 “주문 완료”
- 공급사 화면에서는 “확정 전”
- 포워딩 화면에서는 “조건 미정”
데이터상 상태 값은 일치했지만, 그 상태가 의미하는 바는 사용자 역할마다 달랐다. 이는 단순한 UI 문제처럼 보였지만, 실제로는 주문 흐름 자체가 단선 구조로 설계되어 있었기 때문이었다.
UI 개편의 전제 조건: Draft 개념의 도입
UI를 바꾸기 전에 먼저 한 일은, 주문과 물류 흐름을 다시 정의하는 것이었다.
모든 프로세스의 중심에 Draft 개념을 두었다. 확정되지 않은 것은 확정되지 않은 상태로 명확히 표현하도록 했다.
- Draft Purchase Order
- Draft Delivery Order
- Draft Forwarding Quote
이 구조가 만들어진 이후에야 “지금 이 화면에서 사용자가 무엇을 결정할 수 있는가”를 UI로 정확히 표현할 수 있게 되었다.
UI/UX 개편의 핵심 원칙
이번 개편에서 지킨 원칙은 단순했다.
- 입력이 아니라 의사결정 중심의 화면
- 상태 값이 아니라 의미가 보이는 상태 표현
- 다음 액션이 없는 버튼은 존재하지 않음
예를 들어, 기존에는 “주문 수정” 버튼이 항상 활성화되어 있었지만, 개편 이후에는 현재 단계에서 수정 가능한 항목만 노출되도록 변경되었다. 기술적으로는 권한 제어보다 훨씬 복잡한 작업이었다.
기술적 난관 1: 상태 의존 UI의 폭발
Draft 구조가 도입되면서, UI는 단순한 CRUD 화면이 될 수 없었다.
하나의 주문 화면이 다음 조건에 따라 다르게 렌더링되어야 했다.
- 현재 단계 (Draft / Confirmed / Locked)
- 사용자 역할 (Customer / Vendor / Forwarder)
- 연결된 하위 객체 상태 (Delivery Order, Quote)
이를 단순 조건문으로 처리하면 유지보수가 불가능해진다. 그래서 UI 상태를 상태 머신 개념으로 재정의했고, 화면은 상태를 해석하는 역할만 가지도록 분리했다.
기술적 난관 2: “왜 버튼이 비활성화되었는지” 설명해야 했다
UI에서 가장 많이 받은 내부 피드백은 이것이었다.
“왜 이 버튼이 안 눌리는지 모르겠다.”
그래서 버튼 비활성화는 단순히 disabled 처리하지 않았다.
- 비활성 사유를 명확히 표시
- 어떤 조건이 충족되면 활성화되는지 안내
- 내가 아닌 다른 주체의 액션이 필요한 경우 명시
이로 인해 UI는 복잡해졌지만, 운영 커뮤니케이션 비용은 급격히 줄어들었다.
AI는 UI 뒤에 숨어 있다
이번 UI 개편에서 AI는 전면에 등장하지 않는다. 대신 다음과 같은 지점에서 조용히 작동한다.
- 견적 입력 시 조건 누락 감지
- 공급사 상품 정보 기반 추천 값 제안
- 포워딩 견적 비교 시 판단 보조 정보 제공
중요한 점은 AI의 결과를 그대로 UI에 강제하지 않았다는 것이다. AI는 결정을 대신하지 않고, 선택지를 정리하는 역할만 맡았다.
UI/UX 개편은 DVRP를 위한 준비였다
이번 UI/UX 개편은 단독 작업이 아니다.
2월 중순 예정된 DVRP BETA를 연결하기 위한 전제 조건이었다.
주문과 물류가 연결되기 위해서는 “이 주문이 지금 어디까지 확정되었는가”를 모든 주체가 동일하게 이해해야 한다.
UI는 그 이해를 강제하는 도구가 되었고, 그 결과 DVRP는 별도의 설명 없이도 자연스럽게 연결될 수 있는 구조가 되었다.
마무리
이번 UI/UX 개편은 보기 좋게 만드는 작업이 아니었다.
플랫폼이 성장하면서 필연적으로 발생하는 해석의 차이, 책임의 모호함, 단계 충돌을 기술적으로 정리한 과정이었다.
다음 글에서는 이 구조 위에서 작동하게 될 DVRP BETA와 실제 물류 흐름이 어떻게 연결되는지를 다룰 예정이다.
화면을 바꾼 것이 아니라, 플랫폼이 생각하는 방식을 바꾼 이야기다.
Comments
Post a Comment