요약

자체 쇼핑몰을 운영하면서 ERP·WMS와 실시간 연동을 시도했지만, 재고 불일치나 주문 누락이 반복된다면 연동 방식 자체를 의심해야 합니다. 문제의 근본 원인은 대부분 배치(Batch) 방식이나 DB 직접 연동이라는 구조적 취약점에 있습니다. 이 글에서는 동기화 오류가 왜 발생하는지, 그리고 CDC와 Kafka를 결합한 DB 파이프라인으로 어떻게 해결하는지를 실무 관점에서 설명합니다.

왜 실시간 연동인데 재고가 안 맞을까?

쇼핑몰 홈페이지 제작을 의뢰하는 중견 이커머스 기업 중 상당수가 공통된 고민을 안고 옵니다. "분명히 연동되어 있다고 했는데, 피크 타임만 되면 오버셀링이 발생한다"는 것입니다.

이 문제의 정체를 이해하려면 먼저 연동 방식의 차이를 알아야 합니다.

실시간 연동처럼 보여도, 데이터가 실제로 전달되는 방식이 '배치(일괄 처리)'라면 그건 실시간이 아닙니다.

배치 방식의 구조적 한계

배치 방식은 일정 시간 간격(예: 5분, 10분)마다 데이터를 모아서 전송합니다. 평상시엔 괜찮아 보이지만, 세일 기간처럼 수천 건의 주문이 1분 안에 몰리면 치명적입니다.

• 오버셀링 발생: 쇼핑몰에서 재고 100개가 팔렸지만, ERP에는 아직 반영이 안 된 사이 추가 주문이 들어옵니다.
• 메시지 유실: 네트워크 타임아웃 발생 시 재전송 로직이 없으면 주문 데이터 자체가 사라집니다.
• 중복 차감: 재전송 로직이 있어도 멱등성 처리가 없으면 재고가 두 번 차감됩니다.

DB 직접 연동의 위험성

레거시 WMS 벤더사 중에는 아직도 DB 직접 연동(Direct DB Link) 방식을 권장하는 곳이 있습니다. 테이블에 직접 SELECT 쿼리를 날려 데이터를 가져오는 방식입니다.

문제는 벤더사가 WMS 업데이트를 하면서 테이블 구조(스키마)를 바꾸는 순간, 연동 파이프라인 전체가 즉각 중단된다는 점입니다. 물류가 통째로 멈추는 상황이 벌어집니다.

핵심 개념: CDC와 Kafka, 초보자도 이해하는 설명

이 문제를 근본적으로 해결하는 아키텍처가 CDC + Kafka 기반 이벤트 스트리밍 파이프라인입니다. 용어가 낯설어도 개념은 단순합니다.

CDC (Change Data Capture)

CDC는 데이터베이스의 변경 내역을 실시간으로 감지하는 기술입니다. DB에 직접 쿼리를 날리는 게 아니라, DB가 자체적으로 기록하는 '트랜잭션 로그'를 읽어냅니다.

비유하자면, 매장 직원에게 계속 "뭐 바뀌었어요?"라고 묻는 대신, 매장의 CCTV 녹화 로그를 조용히 열람하는 것과 같습니다.

이렇게 하면 원천 DB에 아무런 부하도 주지 않으면서 변경 사항을 포착할 수 있습니다. 대표적인 오픈소스 도구로는 Debezium이 있으며, MySQL의 Binlog, PostgreSQL의 WAL 등 트랜잭션 로그를 읽어 커밋이 완료된 데이터만 캡처합니다.

Apache Kafka (메시지 버스)

Kafka는 중앙 우체국 같은 역할을 하는 분산 메시지 시스템입니다. CDC가 포착한 변경 데이터를 각 시스템(ERP, WMS, 검색 엔진 등)에 직접 보내는 게 아니라, Kafka라는 중앙 허브에 먼저 저장합니다.

수신 시스템(컨슈머)이 일시적으로 다운되어도 Kafka에 데이터가 보관되어 있으므로, 시스템이 복구되면 밀린 메시지를 순서대로 처리할 수 있습니다. 이것이 Fault Tolerance(결함 내성)입니다.

단계별 DB 파이프라인 설계 가이드

1단계: 데이터 소유권(System of Record) 먼저 확정하라

연동 오류의 상당수는 "어느 시스템의 데이터가 기준인가?"를 정하지 않아서 발생합니다. 설계 전 반드시 다음을 합의해야 합니다.

• 가용 재고 및 로케이션 정보 → WMS가 마스터
• 주문 및 결제 상태 → 쇼핑몰(OMS)이 마스터
• 마스터 품목(SKU), 거래처 정보, 재무 마감 → ERP가 마스터

예를 들어, "출고 완료" 시점을 WMS 출하 완료 기준으로 볼지, 택배사 집하 기준으로 볼지도 명확히 문서화해야 합니다. 이 합의 없이 개발을 시작하면 나중에 상태값이 시스템마다 달라지는 Split-brain 문제가 발생합니다.

2단계: Debezium으로 무부하 CDC 구성

Debezium을 원천 DB(MySQL, PostgreSQL 등)에 연결하면, INSERT·UPDATE·DELETE가 발생할 때마다 트랜잭션 로그에서 해당 변경 이벤트를 실시간으로 캡처합니다.

중요한 점은 커밋이 완료된 데이터만 캡처한다는 것입니다. 트랜잭션이 중간에 실패하면 자동으로 걸러지므로, 불완전한 데이터가 파이프라인으로 흘러 들어가는 것을 원천 차단합니다.

3단계: Kafka 토픽으로 이벤트 발행

CDC가 포착한 이벤트는 Kafka의 전용 토픽(Topic)으로 발행됩니다. 예를 들어 order.created, inventory.updated, shipment.completed 같은 토픽을 분리해 운영합니다.

올리브영은 이 구조를 AWS MSK(관리형 Kafka 서비스) 기반으로 구축하면서 약 30개의 Kafka 토픽을 운영했습니다. 그 결과 기존 레거시 EAI 대비 데이터 처리 속도가 최소 3배에서 최대 45배까지 향상되었고, 대형 세일 기간에도 메시지 유실 없는 실시간 물류 정합성을 확보했습니다.

4단계: 중복 방지와 유실 방지 설계 (가장 중요)

파이프라인에서 가장 까다로운 부분입니다. 두 가지 메커니즘을 반드시 구현해야 합니다.

① 멱등성 컨슈머(Idempotent Consumer)

네트워크 타임아웃으로 메시지가 재전송될 때, 재고가 두 번 차감되는 것을 막는 로직입니다. 각 이벤트에 주문ID + 트랜잭션UUID 같은 고유 키를 부여하고, 이미 처리된 이벤트인지 먼저 확인한 뒤 처리합니다.

② DLQ(Dead Letter Queue)

처리에 실패한 메시지를 메인 파이프라인에서 즉시 분리해 별도 큐에 보관하는 안전망입니다. 타깃 시스템 장애나 데이터 포맷 오류가 생겨도 전체 파이프라인이 멈추지 않으며, 담당자에게 즉각 알림을 보내 수동 또는 자동 재처리가 가능하게 합니다.

5단계: 표준 데이터 모델로 변환 후 적재

ERP, WMS, 검색 엔진(Elasticsearch)은 각자 다른 데이터 포맷을 요구합니다. Kafka Connect나 가벼운 변환 애플리케이션을 거쳐 Canonical Data Model(표준 데이터 모델) 레이어에서 각 시스템 규격에 맞게 파싱·변환 후 최종 적재합니다.

이 레이어를 두면, 특정 WMS 벤더가 API 스펙을 바꾸더라도 변환 로직만 수정하면 되고 전체 파이프라인을 재설계할 필요가 없습니다.

실무 점검 항목

현재 연동 구조를 진단할 때 확인해야 할 항목들입니다.

• [ ] 데이터 소유권(마스터 시스템)이 문서화되어 있는가?
• [ ] 배치 방식이나 DB 직접 연동을 사용하고 있지는 않은가?
• [ ] 메시지 재전송 시 중복 처리를 막는 멱등성 로직이 있는가?
• [ ] 처리 실패 메시지를 격리하는 DLQ가 운영 중인가?
• [ ] 분산 락(Redis 등)으로 동시 결제 시 재고 레이스 컨디션을 제어하고 있는가?
• [ ] 매일 ERP-WMS-쇼핑몰 간 재고 수치를 자동 대조하는 보정 배치가 있는가?

자주 묻는 질문 (FAQ)

Q1. 소규모 쇼핑몰도 Kafka가 필요한가요?

일 주문량이 수백 건 이하라면 Kafka 도입 비용이 과도할 수 있습니다. 이 경우 AWS SQS나 RabbitMQ 같은 경량 메시지 큐로 시작하되, 멱등성 처리와 DLQ 개념은 반드시 적용해야 합니다. 규모가 커지면 Kafka로 마이그레이션하기 쉬운 구조로 설계하는 것이 중요합니다.

Q2. WMS 벤더가 DB 직접 연동만 지원한다고 하면 어떻게 해야 하나요?

벤더사 DB에 직접 접근하는 대신, 중간에 API 게이트웨이 레이어를 두는 방식을 권장합니다. 벤더 DB를 읽는 전용 어댑터 서비스를 별도로 구성하고, 이 서비스가 표준 REST API나 Kafka 이벤트로 데이터를 재발행하도록 설계하면 스키마 변경 리스크를 격리할 수 있습니다.

Q3. 실시간 파이프라인을 구축해도 재고 불일치가 완전히 사라지나요?

파이프라인 오류로 인한 불일치는 대폭 줄일 수 있지만, 물리적 창고에서 발생하는 파손·도난·입고 오류는 별개입니다. 따라서 매일 밤 ERP-WMS-쇼핑몰 간 재고를 전수 대조하고 차이를 자동 리포팅하는 보정 배치(Reconciliation)를 함께 운영해야 완전한 정합성을 확보할 수 있습니다.

Q4. 쇼핑몰 홈페이지 제작 시 이런 연동 아키텍처까지 고려해야 하나요?

초기부터 고려하는 것이 훨씬 유리합니다. 나중에 레거시 구조 위에 연동을 얹으면 기술 부채가 쌓이고 리팩토링 비용이 기하급수적으로 증가합니다. 쇼핑몰 홈페이지 제작 단계에서 OMS 데이터 모델과 API 설계를 연동 아키텍처에 맞게 처음부터 설계하는 것이 장기적으로 훨씬 경제적입니다.

Q5. CDC 도입 시 기존 운영 중인 DB에 영향이 없나요?

Debezium 기반 CDC는 트랜잭션 로그를 읽기만 하므로 원천 DB 성능에 거의 영향을 주지 않습니다. 다만 MySQL의 경우 binlog_format=ROW 설정이 필요하고, PostgreSQL은 wal_level=logical 설정이 필요합니다. 기존 DB 설정 변경 전 DBA와 사전 검토가 필요합니다.

용어 설명 (Glossary)

• CDC (Change Data Capture): DB의 트랜잭션 로그를 읽어 데이터 변경 사항을 실시간으로 감지하는 기술. DB에 직접 쿼리를 날리지 않아 성능 부하가 없습니다.
• Apache Kafka: 대용량 실시간 데이터 스트리밍을 위한 분산 메시지 브로커. 발행(Publish)된 메시지를 영속적으로 저장하고 구독자(Consumer)에게 안정적으로 전달합니다.
• 멱등성(Idempotency): 동일한 연산을 여러 번 수행해도 결과가 변하지 않는 성질. 메시지가 중복 전송되어도 재고가 한 번만 차감되도록 보장합니다.
• DLQ (Dead Letter Queue): 처리에 실패한 메시지를 메인 파이프라인에서 격리해 보관하는 별도 큐. 전체 시스템 장애를 방지하는 안전망 역할을 합니다.
• Split-brain: 동일한 데이터에 대해 여러 시스템이 서로 다른 상태를 마스터로 인식하는 충돌 상황. 데이터 소유권을 명확히 정하지 않으면 발생합니다.
• Canonical Data Model (표준 데이터 모델): 서로 다른 시스템의 API 스펙 차이를 흡수하기 위해 미들웨어 레이어에 두는 공통 데이터 규격.
• Debezium: MySQL, PostgreSQL 등 주요 DB의 트랜잭션 로그를 읽어 CDC를 구현하는 오픈소스 도구. Kafka와 함께 많이 사용됩니다.
• 보정 배치 (Reconciliation): 실시간 파이프라인과 별개로, 정기적으로 여러 시스템의 데이터를 전수 대조해 불일치를 자동 감지하고 수정하는 검증 프로세스.

마무리: 연동 오류는 기술 문제가 아니라 설계 문제입니다

자체 쇼핑몰과 ERP·WMS 간 동기화 오류는 대부분 처음 설계 단계에서 구조적 결함을 안고 시작한 결과입니다. 배치 방식이나 DB 직접 연동은 단기적으로 빠르게 구축할 수 있지만, 트래픽이 늘어날수록 오류가 기하급수적으로 증가합니다.

CDC + Kafka 기반 이벤트 드리븐 아키텍처는 초기 설계 비용이 다소 들지만, 오버셀링 방지, 메시지 유실 제거, 스키마 변경 내성이라는 세 가지 핵심 문제를 동시에 해결합니다. 2026년 현재 AWS MSK, 카카오클라우드 CDC 파이프라인 같은 관리형 서비스의 대중화로 인프라 구축 난이도도 크게 낮아졌습니다.

쇼핑몰 홈페이지 제작을 준비 중이라면, 프론트엔드 디자인과 함께 백엔드 연동 아키텍처를 처음부터 함께 설계하는 파트너를 선택하는 것이 장기적으로 훨씬 현명한 투자입니다.

에이달(ADALL) 은 쇼핑몰 홈페이지 제작 단계부터 ERP·WMS 연동 아키텍처 설계까지 함께 검토하고 구조를 잡아드립니다. 현재 연동 방식에 대한 진단이 필요하거나, 새로운 쇼핑몰 구축을 계획 중이시라면 부담 없이 문의해 주세요.

📞 02-2664-8631 | ✉️ master@adall.co.kr

지금 바로 프로젝트 문의를 남겨주시면, 현재 시스템 구조를 함께 검토하고 최적의 설계 방향을 안내해 드립니다.