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