ERP, CRM 및 이커머스 통합 아키텍처: 흐름별 설계

이 가이드는 스토어, ERP, CRM이 이미 운영 중이며 이제 하나로 연동해야 하는 CTO, IT 관리자, 이커머스 담당자를 위한 것입니다. 엔터프라이즈 시스템 통합 가이드에서 일반 원칙인 레코드 소유권, 통합 패턴, 장애 설계를 설명합니다. 이 페이지에서는 해당 원칙을 커머스 트라이앵글에 흐름별로 적용하고, 토폴로지 선택과 롤아웃 계획으로 마무리합니다.

이 가이드의 목차

• 3개 시스템, 5가지 흐름
• 참조 아키텍처
• 5가지 흐름 설계
• 설계를 변경하는 B2B 규칙
• 토폴로지: 대안 및 선택 기준
• 통합 레이어의 AI
• 롤아웃 계획
• Netbase JSC 납품 사례
• 존재하는 납품 기록과 존재하지 않는 것
• 이 가이드의 한계
• 자주 묻는 질문
• 다음 단계

3개 시스템, 5가지 흐름

대부분의 커머스 환경은 중심에 동일한 3개 시스템을 두고 있습니다. 스토어는 판매와 결제를 담당합니다. ERP는 상품, 재고, 가격, 이행을 위한 주문 및 장부를 관리합니다. CRM은 계정, 연락처, 견적, 서비스 이력을 보관합니다. 그 주변에는 결제 제공업체, 창고나 운송사, 그리고 종종 상품 정보 시스템이 자리합니다.

그 트라이앵글 내의 통합 작업은 거의 대부분 5가지 흐름으로 분류됩니다:

도구를 선택하기 전에 자사 환경에 맞게 이 표를 작성하십시오. 두 시스템이 같은 행을 모두 소유하려 한다면, 소유자는 통합 담당자가 아닌 비즈니스가 결정합니다. 기본 가이드에서 레코드당 단일 소유자가 중요한 이유를 설명하며, 이 페이지의 나머지 부분에서는 소유자가 확정된 후 각 흐름에 필요한 사항을 다룹니다.

참조 아키텍처

내구성 있는 설계는 어떤 제품이 구현하더라도 동일한 레이어를 갖습니다.

• 시스템별 어댑터. 각 스토어, ERP 또는 CRM은 해당 시스템의 API와 데이터 모델을 처리하는 고유 어댑터를 갖습니다. Microsoft Architecture Center에서는 이를 안티-커럽션 레이어(anti-corruption layer)로 설명합니다: 한 시스템의 의미 체계가 다른 시스템으로 누출되지 않도록 하는 변환 레이어입니다. ERP를 교체할 때는 해당 어댑터만 변경하면 됩니다.
• 하나의 공유 데이터 모델. 어댑터는 서로 간이 아닌 상품, 고객, 주문, 청구서의 표준 모델로 변환합니다. Enterprise Integration Patterns 카탈로그에서 그 이유를 설명합니다: 공통 포맷을 사용하면 새 시스템마다 파트너당 하나씩이 아닌 하나의 변환 쌍만 필요합니다.
• 식별자 상호 참조. 소규모 스토어는 모든 시스템에서 각 레코드의 키를 매핑합니다: 스토어의 주문 번호, ERP의 판매 주문, CRM의 영업 기회 등입니다. 이름이나 이메일로 매칭하지 않습니다.
• 내구성 있는 이벤트. 변경 사항은 해당 변경을 만드는 것과 동일한 데이터베이스 트랜잭션에 기록된 후 게시됩니다. 이것이 트랜잭셔널 아웃박스 패턴으로, 충돌이 발생해도 ERP는 업데이트되고 스토어는 알지 못하는 상황을 방지합니다.
• 다단계 흐름의 오케스트레이션. 주문-현금화(order-to-cash)는 4개 시스템을 거치며, 하나의 컴포넌트가 시퀀스와 보상 작업을 소유하므로 단계가 웹훅 전반에 분산되지 않습니다.
• 모니터링 및 대조. 모든 흐름에는 대시보드, 알림, 소유자와 복사본 간의 건수 및 합계를 매일 비교하는 기능이 있습니다.

각 레이어의 장애 규칙—멱등 쓰기, 백오프를 포함한 재시도, 데드레터 큐—은 기본 가이드에 있으며 그대로 적용됩니다.

5가지 흐름 설계

카탈로그 및 가격. 가격의 누락된 이벤트는 지연된 이벤트보다 더 나쁘기 때문에, 소유자로부터 이벤트로 변경 사항을 푸시하고 야간에 전체 비교를 유지합니다. 가격에 유효 날짜를 포함하여 게시하면, 스토어가 ERP가 청구하지 않을 가격을 표시하지 않습니다.

재고. 원시 재고가 아닌 가용성을 전송합니다: 채널별로 보유량에서 예약분과 안전 재고를 뺀 수량입니다. 주문 생성 시 재고를 예약하고 취소 시 해제하여, 두 채널이 마지막 한 개를 중복 판매하지 않도록 합니다.

고객 및 계정. B2B에서는 일반적으로 CRM이 계정과 연락처를 소유하고, ERP가 신용 조건을 소유합니다. 스토어는 두 가지를 모두 수신하며, 신규 웹 고객은 먼저 소유자에게 생성된 후 복사되므로 한 사람이 세 개의 레코드가 되지 않습니다.

주문 및 상태. 스토어는 결제가 승인될 때까지 주문을 소유합니다. 그 이후에는 ERP가 이행을 소유하며, 상태, 배송, 추적 정보가 반환됩니다. 주문은 스토어의 멱등성 키를 포함합니다. RFC 9110에서 POST를 멱등이 아닌 것으로 정의하기 때문에, 재시도된 생성이 두 번째 판매 주문이 되어서는 안 됩니다.

결제, 청구서 및 환불. 결제 제공업체가 거래를 소유하고, ERP가 청구서와 신용 메모를 소유하며, CRM은 계정 팀에게 모두 보여줍니다. 매일 수납 결제와 청구서를 대조하고, 환불은 ERP 또는 ERP의 API를 통해서만 시작하도록 합니다.

설계를 변경하는 B2B 규칙

기업 대상 판매에는 소비자 스토어에서는 볼 수 없는 규칙이 추가되며, 각 규칙은 로직이 어디에 있어야 하는지를 결정합니다:

• 고객별 가격 목록 및 계약 가격은 ERP 또는 CRM에 유지하며 계정별로 가져옵니다. 수천 개의 상품 변형으로 복사하지 않습니다.
• 신용 한도 및 결제 조건은 체크아웃 시 ERP에서 확인합니다. 한도를 초과한 주문은 실패 대신 승인 대기 상태가 됩니다.
• 견적은 CRM에서 시작하여 재입력 없이 주문으로 전환되며, 견적 참조 번호가 ERP 주문에 유지됩니다.
• 구매자 측의 구매 주문 및 승인은 주문과 함께 저장되어, 청구서가 구매자의 재무팀 기대치와 일치하도록 합니다.

토폴로지: 대안 및 선택 기준

4가지 기준이 결정을 내립니다: 데이터와 규칙이 얼마나 표준적인가, 향후 2년간 예상 시스템과 흐름의 수, 로직을 누가 소유하고 변경해야 하는가, 야간에 누가 운영할 것인가입니다. 많은 환경이 커넥터로 시작하다가 오류 처리와 가시성이 한계에 달하면 허브로 이동합니다. 통합 허브는 해당 단계의 소유 버전입니다. 멀티벤더 스토어는 판매자 정산 및 벤더 카탈로그를 추가하며, 이는 마켓플레이스 플랫폼 아키텍처에서 다룹니다. 스토어 자체를 변경할 계획이라면 먼저 커스텀 이커머스 플랫폼 가이드를 통해 그 문제를 해결하십시오.

Netbase JSC 납품 사례

• 리워드 샵 플랫폼(고객 미공개). 두바이 기반 로열티 회사를 위해 Netbase JSC는 헤들리스 Magento 2 멀티스토어 플랫폼을 고객의 포인트 미들웨어, 주문 서비스, 상품 카탈로그에 연결했습니다. 고객의 시스템이 포인트와 주문을 소유하며, 웹훅이 변경 사항을 전달하고 예약 동기화가 장애 조치 역할을 합니다. 리워드 샵 기록을 참조하십시오.
• 미국 고객의 클라우드 ERP(미공개). 2020년부터 오프쇼어 개발 및 관리 파트너로서 Netbase JSC는 첫 번째 단계에 테넌트가 이미 사용 중인 시스템에 대한 CRM 및 API 통합이 포함된 멀티테넌트 클라우드 ERP를 구축하고 있습니다. 클라우드 ERP 기록을 참조하십시오.
• Cloodo Workspace. CRM, HRM, 클라우드 ERP, AI 모듈을 하나의 제품으로 결합한 Netbase JSC 비즈니스 디비전으로, 레코드가 동기화되는 대신 하나의 시스템에 존재합니다. Cloodo 기록을 참조하십시오.

Netbase JSC는 또한 카탈로그, 재고, 주문 및 고객의 API 동기화를 통해 고객 스토어를 ERP에 연결했습니다. 해당 고객들은 공개되지 않습니다.

존재하는 납품 기록과 존재하지 않는 것

• 존재하는 것. 위의 기록은 범위와 설계를 설명합니다: 어떤 시스템이 연결되었는지, 어떤 시스템이 어떤 데이터를 소유하는지, 변경 사항이 어떻게 이동하는지. Netbase JSC의 제품화된 모듈에는 CRM 및 B2B 영업 엔진, 워크플로우 자동화 툴킷, Smart ERP Light가 포함되며, 납품된 플랫폼에는 WooCommerce, Magento 2, Laravel, 헤들리스 커머스가 포함됩니다.
• 존재하지 않는 것. 이러한 기록 중 어느 것도 통합의 기간, 메시지 볼륨, 오류율, 비즈니스 결과를 공개하지 않으며, 수치의 증거로 제시되지 않습니다. ERP 통합 고객은 공개되지 않습니다.

이 가이드의 한계

• 흐름 표는 B2C 및 B2B 커머스의 기본값입니다. 마켓플레이스, 구독, 제조업은 자체 흐름을 추가합니다.
• 패턴은 공개적인 설명에서 인용되었습니다. 적용한다고 해서 실제 데이터 테스트 없이 통합이 올바른 것은 아닙니다.
• 최소 권한 키, 전송 중 TLS, AES 저장 암호화, 관리자 액세스를 위한 MFA 같은 보안 관행은 위험을 줄여줍니다. 이는 보장이 아닙니다.

다음 단계

귀사의 스토어, ERP, CRM과 가장 자주 문제가 발생하는 흐름 및 일정을 공유해 주시면, 솔루션 리뷰를 예약하여 소유자, 흐름 및 토폴로지를 매핑해 드리겠습니다. 시스템 및 API 통합, ERP 및 CRM 개발 또는 더 많은 Netbase JSC 인사이트도 확인하실 수 있습니다.

관련 서비스 및 솔루션