1. 요구조건에서 시작한 '새 플랫폼' 선언 Quote → PO → Invoice → Delivery → Settlement 전체 흐름이 단일 데이터 체인 으로 연결될 것 국가/언어/통화/세율/물류 규칙을 데이터 레이어 에서 통합 관리할 것 데이터 변화가 이벤트(AMQP) 를 통해 실시간 전파되고 캐시와 UI가 자동 갱신될 것 사람이 문서/툴을 조작하지 않아도 AI 워크플로우 가 명세→스키마→API→배포를 자동 생성할 것 이 요구는 곧 플랫폼의 재정의 였다. "코드가 데이터를 설명"하던 과거에서, " 데이터가 코드를 지배 하는" 구조로의 전환. 이 관점에서 전 계층을 다시 설계했다. 이 요구조건이 왜 기존 시스템으로는 충족될 수 없었는지를 구체적으로 짚어보자. 기존 시스템에서 견적(Quote)과 주문(PO)은 별개의 데이터 저장소에 관리되고 있었다. 견적서에 적힌 단가와 실제 주문에 반영된 단가가 일치하는지 확인하려면 두 개의 테이블을 수동으로 조인해야 했고, 그 과정에서 환율 변환 시점이 달라 금액 불일치가 발생하는 경우가 잦았다. 4개국(태국, 한국, 중국, 말레이시아)의 거래에서 THB, KRW, CNY, MYR, USD라는 5개 통화가 오가는 환경에서 이런 불일치는 단순한 기술 버그가 아니라 비즈니스 신뢰 문제였다. 2. 기존 시스템이 막혀 있던 구체적 지점들 패치로는 해결할 수 없었던 구조적 한계를 정리하면 다음과 같다. 다국어/다통화 하드코딩: i18n 텍스트가 프런트엔드 컴포넌트에 직접 삽입되어 있었다. 새 언어를 추가하려면 수백 개 파일을 수정해야 했다. 단일 리전 종속: 모든 데이터가 싱가포르 리전에 있어서, 태국 바이어와 한국...