상품은 한 곳에서만
관리한다 — 허브앤스포크 MDM

DB를 합치는 게 아니라, 한 번만 관리한다

진짜 문제는 “같은 상품이 여러 곳에서 관리돼 어긋난다”입니다. 이는 마스터 데이터(MDM) 문제이지, 세 DB를 하나로 융합하는 문제가 아닙니다. 그래서 회사 카탈로그의 단일 작성 지점(상품 마스터 어드민)을 두고, Foodil·Quoteapp은 그 투영을 받습니다. 각 앱의 DB·인증·주문/견적은 그대로 두고, 상품 데이터만 마스터로 모읍니다.

세 시스템 — 새 구조에서의 역할

색으로 시스템을 구분합니다. 새 구조에서 누가 소비자(투영)이고 누가 문서 서비스인지를 함께 표시했습니다.

핵심 범위: “3중 관리”의 실체는 회사 카탈로그가 Foodil과 Quoteapp에 중복된다는 것입니다. 마스터는 회사 상품만 다스리고, Foodil의 다른 셀러 상품은 그대로 둡니다. CIPL은 이미 Quoteapp이 문서 시점에 데이터를 밀어주므로 별도 동기화 대상이 아닙니다.

왜 MDM인가 — 세 가지 방안 비교

이 선택은 기술 취향이 아니라 전략 문제입니다. 두 가지가 답을 결정합니다 — (1) 세 앱이 하나의 플랫폼으로 수렴하는가, (2) 드리프트가 실제로 얼마나 큰가(공유 상품 수 × 변경 빈도 × 오류 비용). 아래는 두 극단(전체 통합 · 분리 유지)과 그 사이의 MDM을 정직하게 비교한 것입니다.

합의된 전제 — 자체 평가 후 방향 전환

초기엔 “단일 DB 통합”을 검토했으나, 목표가 “상품 3중 관리 제거”(마스터 데이터 문제)로 확정되면서 더 안전하고 점진적인 허브앤스포크 MDM으로 전환했습니다.

단일 마스터 · 두 투영 · 한 문서 서비스

회사 상품 필드 → 상품 마스터(core)

일회성 정합 시 각 시스템의 필드가 마스터의 어디로 가는지입니다. 검토에서 검증된 충돌(단위 vs 카톤 중량, 통화 부재, 바코드 유형, 규격 원문)은 모두 해소했습니다. 동기화 시 마스터 소유 필드만 소비자로 갱신됩니다.

전체 계획 — 검증에서 정착까지

한 번에 전부 만들지 않습니다. 검증(P0)으로 시작해 마스터+thin slice(P1)로 루프를 증명하고, Foodil 소비자(P2), 전체 확장+강화(P3)를 거쳐 정착·거버넌스(P4)에서 “3중 관리”를 완전히 종료합니다. 각 단계는 완료 기준을 통과해야 다음으로 넘어갑니다.

기존 앱이 마스터에 붙는 방식, 그리고 그 다음