ERP 데이터 동기화 미들웨어
eCount ERP Connector
이카운트 ERP와 자체 커머스 플랫폼 간 양방향 동기화 미들웨어. 이카운트 REST API는 웹훅 미지원으로 커스텀 폴링 + SHA-256 변경 감지 레이어를 구현해 불필요한 API 호출을 90% 절감. 품목·거래처·발주·판매전표 4개 엔티티를 MySQL 스테이징 DB를 통해 충돌 없이 양방향 동기화하며 실패 시 자동 재시도 큐 탑재.
Architecture Overview
Node.js 미들웨어가 이카운트 ERP와 커머스 플랫폼 사이에 위치. 폴링 크론 → SHA-256 비교 → 변경 분만 MySQL 스테이징 버퍼 → 양방향 동기화 → 충돌 해결 순으로 처리.
SHA-256 변경 감지 · API 호출 90% 절감 · MySQL 스테이징 충돌 해결 · 지수 백오프 재시도 큐
Technical Problems
이카운트 ERP 웹훅 미지원 — 변경 감지 불가
이카운트는 데이터 변경 시 외부 시스템 알림이 없다. 전체 데이터를 주기 폴링하면 API 호출 횟수가 폭증하고 속도 제한에 도달해 서비스 중단이 발생한다.
양방향 충돌: 커머스→ERP, ERP→커머스 동시 쓰기
커머스 주문은 ERP 판매전표를 생성하고, ERP 재고·단가 변경은 커머스에 반영해야 한다. 양쪽이 같은 엔티티를 동시 수정하면 LWW(Last Write Wins) 충돌로 데이터 유실이 발생한다.
네트워크 일시 장애 시 동기화 작업 유실
ERP API 또는 커머스 DB가 일시 응답 불가일 때 동기화 작업을 유실 없이 재처리해야 한다. 무한 재시도는 API 속도 제한을 악화시킨다.
Engineering Approach
SHA-256 해시 비교로 변경 분만 추출
품목·거래처·발주·판매전표 4개 엔티티를 JSON 직렬화 후 SHA-256 해시. 이전 해시와 비교해 변경된 레코드만 추출해 동기화. 1만 건 기준 전체 동기화 대비 API 호출 90% 절감.
MySQL 스테이징 테이블 + synced_at 충돌 해결
`sync_staging(entity_type, entity_id, payload, source, synced_at, checksum)` 중간 테이블로 양방향 쓰기 버퍼링. 동일 entity_id에 양쪽 변경이 들어오면 synced_at 최신 레코드를 승자로 채택. 충돌 이력을 sync_conflicts 테이블에 보관해 감사 추적.
지수 백오프 재시도 큐 + 최대 5회 알림
실패 작업을 `retry_queue(job_id, attempt, next_retry_at)` 테이블에 저장. 크론이 `next_retry_at <= NOW()` 조건으로 재처리. 재시도 간격 2ⁿ × 30초로 지수 증가. 5회 실패 시 슬랙 알림 발송.
Measurable Outcomes
−90%
API 호출
SHA-256 변경 감지 도입 후
0건
동기화 충돌
6개월 운영, 스테이징 버퍼
< 3분
평균 지연
ERP → 커머스 반영 주기
99.4%
재시도 성공률
지수 백오프 5회 이내
Tech Stack
Visual Architecture
Sync Architecture
Bidirectional Sync Pipeline
Unchanged records skipped · API calls −90% vs full-sync · 변경 분만 업서트
Entity Coverage
Conflict Resolution — Bidirectional Writes
Same entity_id conflict → latest synced_at wins · logged to sync_conflicts
Resilience — Retry Queue
6개월 운영 · 동기화 충돌 0건 · 재시도 성공률 99.4%
Project Specs
Year
2025
Duration
2개월
Capability
Commerce & Platforms
Status
DeliveredTechnologies