*물류 SaaS 와 이커머스 SaaS 는 *겉으로는 같은 SaaS — 안쪽 도메인의 *시간축·정합성·외부 N면 연동* 이 *완전히 다른 시스템* 을 강제하는 이유 *7 가지*
이 글은 두 SaaS 도메인의 *내부 구조 차이 를 직접 시스템을 설계해 본 경험 으로 풀어쓴 비교 노트다. 물류 SaaS (WMS/OMS/TMS/LMS) 와 이커머스 SaaS (Shopify, Cafe24, NHN Commerce 류) 는 멀리서 보면 같은 *클라우드 형 B2B 도구 처럼 보이지만, 안쪽으로 들어가면 *데이터 모델·트랜잭션 패턴·SLA 정의·정합성 정의·외부 연동 구조 가 서로 다른 시스템 을 강요한다.
이 글은 7 가지 축 으로 두 도메인을 비교한다:
- 도메인 정의 와 대표 제품
- 주 사용자 페르소나 — 내부 운영자 vs 외부 고객
- 시간 축 의 본질 — 물리적 흐름 vs 결제 트랜잭션
- 데이터 정합성 의 치명 지점
- 외부 시스템 연동 수 — N면 분기 의 형태
- SLA / 무중단 의 의미
- 기술 스택 의 자연스러운 선택
마무리는 둘을 *같이 설계할 때 (예: 이커머스 + 풀필먼트 통합) 의 경계 설계 까지.
TL;DR
한 줄 요약
물류 SaaS 는 *물리적 시간/공간의 *상태머신 위에 N면 외부 연동 을 묶는 시스템. *이커머스 SaaS 는 *주문/결제 *피크 트랜잭션 위에 고객 경험 최적화 와 정산 정확성 을 묶는 시스템. 두 도메인은 *겉으로 같은 SaaS 지만 안쪽 *정합성의 정의 가 다르다 — 물류는 재고 = 실물 이 정의, 이커머스는 주문 = 결제 = 정산 이 정의.
3 줄 비교
| 축 | 물류 SaaS | 이커머스 SaaS |
|---|---|---|
| 치명 정합성 | 재고 - 실물 | 주문 - 결제 - 정산 |
| 시간축 | 물리적 24/7 흐름 | 결제 피크 + 마케팅 이벤트 |
| 외부 연동 수 | 수십~수백 면 (택배사·창고·차량·세관·EDI) | 수~수십 면 (PG·배송·SMS·마케팅) |
1. 도메인 정의 — 대표 4종 vs 대표 3종
1.1 물류 SaaS — 4 단 분업
물류 도메인의 4 SaaS 축
├─ WMS (Warehouse Management System) 창고 관리
├─ OMS (Order Management System) 주문 처리
├─ TMS (Transportation Management) 운송 관리
└─ LMS (Logistics Management System) 통합 물류 운영
각 SaaS 는 서로 다른 *시간 단위 와 물리적 객체 를 관리:
| SaaS | 시간 단위 | 핵심 객체 | 예시 제품 |
|---|---|---|---|
| WMS | 분~시 단위 | Bin / SKU / Pick 작업 | Manhattan WMS, SAP EWM, 한진 WMS |
| OMS | 시 단위 | Order / Fulfillment 라우팅 | NetSuite OMS, Tecsys OMS |
| TMS | 시~일 단위 | Shipment / Route / Carrier | Oracle TMS, MercuryGate |
| LMS | 일~월 단위 | Lane / SLA / 정산 | Project44, Transporeon |
핵심 — 각 SaaS 는 *서로 다른 *시간축 위에 있고 서로 다른 *사용자가 *동시에 본다. WMS 사용자(창고 작업자) 가 *분 단위 로 Pick 하는 사이, TMS 사용자(디스패처) 는 시 단위 로 차량 배차 하고, LMS 사용자(운영 매니저) 는 주 단위 로 Lane 수익률 분석. 데이터 모델이 세 시간축 을 동시 표현 해야 한다.
1.2 이커머스 SaaS — 3 단 분업
이커머스 도메인의 3 SaaS 축
├─ Storefront (B2C 쇼핑몰) 상품/주문/결제/배송 채널
├─ Backoffice (운영 관리자) 상품 관리/주문 처리/CS/정산
└─ Marketing (CRM·CDP) 프로모션/회원/리타게팅
| SaaS | 시간 단위 | 핵심 객체 | 예시 제품 |
|---|---|---|---|
| Storefront | 밀리초 (페이지 로드) | Product / Cart / Order | Shopify, Cafe24, Magento |
| Backoffice | 시 단위 | Order / Refund / 정산 | 자체 또는 위 제품의 Admin |
| Marketing | 일 단위 (캠페인) | Segment / Touchpoint | Klaviyo, Braze |
이커머스의 시간축 은 훨씬 압축 — 상품 페이지 0.5초, 주문 결제 5초, 정산 1일. 사용자가 얼마나 빨리 이 흐름을 통과 하느냐가 전환율 과 직결.
1.3 겉으로 같은 SaaS 지만 다른 게 시작되는 곳
둘 다 *클라우드 + 멀티테넌트 + 구독 이지만, 멀티테넌트의 *격리 수준 이 다르다. 물류는 *Lane / Warehouse / Fleet 격리 가 물리적 한계 와 직결 — 한 테넌트의 재고 데이터가 다른 테넌트로 새면 *재무 사고. 이커머스는 테넌트 격리가 주로 *논리적 — 데이터 누출은 재무 사고 보다는 *고객 사고. 둘 다 위험하지만 물류의 격리 위반 이 복구 더 어려움 (실물 이동까지 이미 일어남).
2. 주 사용자 페르소나 — 내부 운영자 vs 외부 고객
2.1 물류 SaaS = *B2B의 *내부 운영자**
| 페르소나 | 작업 빈도 | 디바이스 |
|---|---|---|
| 창고 작업자 (Picker) | 분 단위 | 모바일 RF 스캐너 + 터미널 |
| 디스패처 (배차 담당) | 시 단위 | 듀얼 모니터 데스크탑 |
| 운영 매니저 | 주~월 단위 | 대시보드 + BI |
| 회계 (정산) | 월 단위 | 엑셀 다운로드 + ERP |
→ 모든 사용자가 자기 회사 직원. 모바일 UX 가 *데스크 PC UX 보다 더 중요* 할 수도 있음 (창고는 손에 디바이스 들고 다님). 접근성·러닝 커브 가 훈련 가능 (인하우스 트레이닝).
2.2 이커머스 SaaS 의 *두 종류 사용자**
1차 사용자 (B2B) 쇼핑몰 운영자 (셀러, 브랜드, MD)
└─ 상품/주문/CS/정산
└─ Backoffice UX 가 중요
2차 사용자 (B2C) 실제 *구매 고객*
└─ Storefront 의 *0.5초 로딩 / 5초 결제*
└─ 절대다수가 *모바일 웹/앱*
└─ 실패하면 *경쟁몰로 이탈*
→ 이커머스 SaaS 는 B2B 고객의 *B2C 고객 을 행복하게 해줘야 함 — 간접 사용자 (구매 고객) 의 경험이 *직접 사용자 (셀러) 의 매출 = 우리 매출 에 직결.
2.3 UX 우선순위가 *완전히 다름**
물류 SaaS 는 효율 — 1초라도 Pick 시간 단축, 오류 0.1% 감소 가 연간 수억원. 예쁘기보다 *키보드 단축키와 *벨소리 가 중요. 이커머스 SaaS 는 *전환 — 0.5초 로딩 지연이 *전환율 7% 감소 (Amazon 의 유명 측정). 디자인의 *0.1초의 효과 가 연간 수십억 매출 차이.
3. 시간 축 의 본질 — 물리적 흐름 vs 결제 트랜잭션
3.1 물류 — 물리적 24/7 흐름
00:00 ──────────────── 06:00 ────────────── 12:00 ──────── 18:00 ──── 24:00
│ 야간 자동분류 │ 새벽배송 출고 │ 주문수집 │ 차량회수 │
│ (택배사 허브) │ 최종 배송 │ 배차 결정 │ 입고 정리 │
│ │
└─ *어느 시점에 *시스템이 꺼지면 *그 시간의 *물리적 작업이 *멈춤*
예: 새벽 5시 *WMS 다운* → 출고 못 함 → 그 날 *전 고객 배송 지연*
→ 시간이 *비가역적. 물리적 객체가 *지금 *움직이는 중. 시스템 다운 = 물류 정체.
3.2 이커머스 — 결제 트랜잭션 의 피크
평소 트래픽: 10 RPS
오픈마켓 평일: 100 RPS (낮 1시 ~ 밤 11시 분산)
타임딜: 5,000 RPS (오픈 후 *3분 안에 *완판* 까지 폭주)
블랙프라이데이: 50,000 RPS (3시간 동안 *연간 매출의 *10%*)
→ 피크 와 평소의 *수천 배 차이. 피크 대응 = 자원 모델링 + 백프레셔 + Queue + DB sharding. 피크 외 시간엔 *대부분 idle.
3.3 완전히 다른 가동률 패턴
| 시간대 | 물류 SaaS | 이커머스 SaaS |
|---|---|---|
| 새벽 02:00 | 허브 자동분류 진행 중 — 풀 가동 | idle — 트래픽 거의 0 |
| 평일 14:00 | 주문 수집 + 배차 — 절반 가동 | 낮 트래픽 — 중간 |
| 타임딜 시작 직후 | 영향 없음 (물류 후속) | 5,000 RPS 폭주 |
| 일요일 23:00 | 주말 정산 + 다음주 차량 계획 | 주말 마지막 결제 |
→ 물류는 *항상 일정 부하 + 24/7, 이커머스는 *spike + idle 의 반복*.
자원 설계가 반대 방향. 물류는 평균 부하 기준 *상시 자원. 이커머스는 피크 기준 *Auto-Scaling + 큰 idle 자원 낭비 허용. 클라우드 인프라 청구서 패턴이 *완전히 다름.
4. 데이터 정합성 의 치명 지점
4.1 물류 — 재고 = 실물 이 치명 정합성
시스템의 *재고 = 100 SKU*
창고의 *실물 = 99 SKU*
↑
*1 개 차이* 가 *연쇄 사고*:
1. 주문 받음 → 시스템 OK → 실물 없음 → 출고 실패
2. 고객 환불 + 신뢰 손실 + CS 비용
3. 회계 결산 시 *재고 차이 액*
4. 분기 결산이 *틀린 숫자로 보고* → 감사 문제
→ 재고와 실물의 *동기화가 *시스템의 *생명선. 재고 추적은 *SKU 단위 + Bin 단위 + 배치 단위 + 만료일 단위 의 4 차원 큐브.
4.2 이커머스 — 주문 ↔ 결제 ↔ 정산 의 체인 정합성
주문(Order) 결제(Payment) 정산(Settlement)
│ │ │
│ 주문 1건 = 1만원 │ PG 승인 1만원 │ 매출 1만원
│ │ │ - 수수료 3% (300원)
│ │ │ - VAT 등
│ │ │ = 셀러 정산 9,700원
│ │ │
└─ 어디서 *깨지면* — 1) 매출 - 결제 차이 / 2) 정산 누락
*결산 사고 + 셀러 클레임 + 회계 감사*
→ 주문/결제/정산 3 도메인이 *바운디드 컨텍스트 로 분리되되 최종 일관성 (eventual consistency) 으로 체인 정합성 보장. Outbox + Idempotent Consumer + Settlement Verification Job.
4.3 정합성의 *Source of Truth 가 다름*
| 도메인 | Source of Truth | 검증 방식 |
|---|---|---|
| 물류 | 실물 = 진실, 시스템은 반영 | 사이클 카운트 + RFID 스캔 + 실사 정합 |
| 이커머스 | 결제 = 진실, 정산은 재현 | PG 거래 원장 vs 자체 결제 ledger 매일 대사 |
물류는 물리적 진실 에 시스템이 종속. 이커머스는 금융 (결제) 진실 에 시스템이 종속. 둘 다 외부의 진실에 *시스템이 따라가는 *책임 을 진다.
5. 외부 시스템 연동 수 — N면 분기 의 형태
5.1 물류 SaaS 의 *외부 연동 *N 면 분기**
물류 SaaS 의 외부 연동 카드 :
├─ 택배사 (CJ대한통운, 한진, 롯데, 우체국, FedEx, DHL, UPS … 수십 개)
├─ 창고 (3PL 자체창고, 협력사 창고, 임대창고 … 회사마다 다른 *WMS 인터페이스*)
├─ 운송 (TMS) (자가차량, 위탁차량, 컨테이너 선사, 항공사 … 운송수단 마다 다른 *EDI*)
├─ 통관/세관 (국가별 EDI : Kr Customs UNI-PASS, US CBP, EU AES …)
├─ 공급사 ERP (SAP, Oracle EBS, NetSuite … 수십 개 ERP 통합)
├─ 회계 / 정산 (자체 ERP 또는 SAP)
├─ IoT / 센서 (RF 스캐너, RFID gate, 온도센서, GPS tracker …)
└─ 표준 (GS1 GTIN/SSCC, EDI X12/EDIFACT/UN-CEFACT)
연동 면 수가 *수십 ~ 수백. 각 연동이 *서로 다른 프로토콜·인코딩·인증 방식. 전통 EDI 가 *AS2 + SOAP + 텍스트 파일 (FTP) + SFTP 의 4 세대 동거. 통합 어댑터 레이어 가 시스템 무게의 *상당 부분.
5.2 이커머스 SaaS 의 *외부 연동 *N 면 분기**
이커머스 SaaS 의 외부 연동 :
├─ PG (KCP, INICIS, NHN Pay, 토스페이먼츠, PayPal, Stripe …)
├─ 배송사 (CJ, 한진, 로젠, 한국우편 + 해외용 …) — 운송장 발급 + 추적
├─ SMS / 이메일 (NHN Toast, 알리고, AWS SES, SendGrid …)
├─ 광고 / 마케팅 (Facebook Pixel, GA, Naver Premium Log, Kakao Pixel …)
├─ 검색 (Naver Shopping, Google Shopping, Coupang …)
├─ 고객지원 (채널톡, Intercom, Zendesk …)
└─ ERP / 회계 (자체 또는 SAP 등)
연동 면 수가 *수 ~ 수십. 대부분 *현대적 REST API + Webhook. 연동 자체보다 *피크 부하 시의 *동기 호출 risk 가 더 큰 문제*.
5.3 연동 수의 *수십 배 차이 + 연동 *깊이** 의 차이
물류 SaaS 의 외부 연동 어댑터 코드 가 전체 코드의 *30~50% 일 수 있음. 이커머스 SaaS 는 PG + 배송 + 마케팅 정도가 10~20%. 나머지는 상품/주문/UI. 시스템 무게중심이 *연동 vs 도메인 으로 다르다*.
6. SLA / 무중단의 의미
6.1 물류 — 24/7 무중단 의 *진짜 의미**
물류 SaaS 의 SLA 99.9% 는 연간 *8.76 시간 다운 허용* 인데:
- 어느 시간이 다운인지 가 모두 중요. 새벽 4시 다운도 새벽 배송 작업 중 이라 모두가 *peak hour.
- 다운 시간이 재시작으로 회복 안 됨 — 그 시간에 *놓친 *물리적 작업이 *지연되어 *후속 작업까지 *연쇄.
→ 물류의 *SLA 99.99% (53 분/년) 이 현실적인 최소 기준 일 수도. 유지보수 윈도우 자체가 *없음.
6.2 이커머스 — *피크 시간의 *무중단 + idle 시간의 *유연성**
이커머스 SaaS 의 SLA 99.9% 는:
- 피크 (블랙프라이데이, 11.11, 12.12, 명절) 시간엔 반드시 *살아있어야 함. 그 시간 다운 = 연간 매출의 *수%.
- idle 시간 (새벽) 의 다운은 허용. 유지보수 윈도우 03:00~05:00 가능.
→ 이커머스의 *시간대별 *차등 SLA 가 기술적으로 가능 + 비용 절감.
6.3 SLA 의 *현실적인 의미 가 다름*
| 항목 | 물류 SaaS | 이커머스 SaaS |
|---|---|---|
| 전 시간 *동등 중요도 | ✅ | ❌ (피크가 압도) |
| 유지보수 윈도우 가능 | ❌ | ✅ |
| 다운 시 *후속 연쇄 | ✅ (배송 지연 수일 *까지) | ❌ (다음 사용자가 재시도 가능) |
| 복구 후 *catch-up | 물리적 처리 *불가 | 결제 재시도 *가능 |
물류는 시간이 *진짜 *비가역. 이커머스는 시간이 *상대적 비가역 (피크 외엔 catch-up).
7. 기술 스택의 자연스러운 선택
7.1 물류 SaaS 의 자연스러운 스택
도메인 모델: *상태머신 + Event Sourcing*
(각 객체가 *수십 가지 상태 *전이*, *왜 그 상태인지* 추적 필수)
→ Akka, Spring State Machine, AxonFramework
데이터: *시계열 + 위치 정보*
Postgres + PostGIS, TimescaleDB, ElasticSearch (위치/시간 검색)
연동: *통합 어댑터 *레이어 헤비*
Apache Camel, MuleSoft, Spring Integration
UI: *데스크탑 헤비 (BackOffice) + 모바일 (Picker)*
React + Electron 데스크탑, React Native / Flutter (RF 스캐너)
배포: *온프레미스 + 클라우드 하이브리드*
일부 *3PL 회사가 *온프렘 강제* — 컨테이너 + Kubernetes
7.2 이커머스 SaaS 의 자연스러운 스택
도메인 모델: *Bounded Context (Order / Payment / Catalog) + Outbox*
→ Spring Boot 모듈러 또는 MSA
데이터: *고성능 트랜잭션 + 검색*
PostgreSQL + Redis 캐시 + ElasticSearch (상품 검색)
연동: *현대적 REST API + Webhook*
Spring WebClient / Feign + Resilience4j
UI: *모바일 우선 (B2C) + 데스크탑 (B2B)*
Next.js + React, SSR + ISR
배포: *클라우드 네이티브 + Auto-Scaling*
Kubernetes + HPA + Cloudflare CDN
7.3 왜 *다른 스택 이 자연스럽나*
물류는 상태머신 + 외부 연동의 *복잡도 가 도메인의 주된 무게. 이커머스는 고가용 + 피크 부하의 *처리량 이 도메인의 주된 무게. 도메인의 주된 무게가 *서로 다른 곳에 있기 때문에 *스택의 *최적 선택도 다름. 한 스택으로 둘 다 처리 하려 하면 둘 다 평범하게 됨.
8. 둘을 같이 설계할 때 — 경계 설계의 *함정**
이커머스가 자체 풀필먼트 (3PL 보유) 를 가지면 둘이 한 시스템 안에 같이 산다. 예: Coupang, Amazon, 새벽배송.
8.1 흔한 함정 — 한 시스템에 다 묶기
[잘못된 *통합 모델*]
모든 *Order* 가 *Order 테이블* 1 개에 살고,
물류 상태 (PICKING / PACKED / SHIPPED / DELIVERED) 도
*같은 테이블의 *status 컬럼* 에 *enum 추가*
문제:
- Order 도메인이 *물류 상태머신 까지 책임 짐 → 결합도 폭발
- 물류 상태 변경 이 Order 트랜잭션 을 건드림 → 피크 시 *블로킹
- 결제 정정 과 재고 정정 이 같은 트랜잭션 으로 묶임 → 어느 한 쪽이 *밀리면 *다른 쪽도 멈춤
8.2 권장 — Bounded Context 분리 + 이벤트 동기
[권장 *분리 모델*]
이커머스 BC: Order, Payment, Catalog
물류 BC: Fulfillment, Inventory, Shipment
OrderPaid 이벤트 ───→ Fulfillment 가 *수신* → *FulfillmentTask 생성*
↓
ShipmentCreated 이벤트
↓
이커머스 BC 가 *수신* → *Order 상태 *Shipped 갱신*
두 BC 가 *서로의 *내부 모델을 모름. 오직 비즈니스 이벤트 로만 통신. 시간 축이 다른 두 시스템이 각자의 속도 로 진행. 한 쪽이 막혀도 *다른 쪽 계속 진행. 이게 *MSA 의 *진짜 가치 가 발휘되는 구조.
8.3 경계의 *정합성 보장 방법*
Outbox 패턴:
주문 결제 트랜잭션 안에서 *Outbox 이벤트* 도 INSERT
↓
Poller (or CDC):
Outbox → Kafka 전달 (at-least-once)
↓
물류 BC 의 Consumer:
processed_events (group, event_id) PK 으로 *멱등 수신*
→ Fulfillment 처리
정합성 검증 Job (일별):
이커머스 BC 의 *결제 완료 주문 수* vs 물류 BC 의 *FulfillmentTask 수*
차이 발견 시 *Slack/SMS 알람* + *수동 복구 도구*
9. 끝맺음 — 겉은 SaaS, 안은 *서로 다른 시스템**
| 결론 | 물류 SaaS | 이커머스 SaaS |
|---|---|---|
| 시간 축 | 24/7 균등 | 피크 + idle 양극 |
| 정합성 | 재고 = 실물 | 주문 = 결제 = 정산 |
| 사용자 | 내부 운영자 | 외부 고객 + 내부 셀러 |
| 연동 면 | 수십~수백 | 수~수십 |
| SLA | 전 시간 동등 | 피크 우선 |
| 무중단 의미 | 연쇄 후속 작업 중단 | 직접 매출 손실 |
| 자연스러운 스택 | 상태머신 + 통합 어댑터 | 고가용 트랜잭션 + 검색 |
겉으로 *클라우드 + 멀티테넌트 + 구독 + B2B 라는 공통점 은 얇은 표면. 그 아래의 *도메인 모델 / 시간축 / 정합성 정의 / 외부 연동 / SLA 의미 가 완전히 다른 두 시스템 을 강요한다.
설계할 때 둘 다 만들려는 유혹 에 두 번 빠지지 말 것:
- 한 도메인 안에 두 시스템 을 섞지 말 것 — Bounded Context 분리
- 한 스택으로 두 도메인 다 처리하려 하지 말 것 — 각 도메인의 *주된 무게 에 맞는 스택을 선택
경계가 분명할 때 *두 시스템 다 *각자 더 강해진다*. 이게 *도메인 설계의 *제 1 원칙.
다음 글: 물류 SaaS 의 *상태머신 설계 — 30+ 상태 전이를 Akka FSM / Spring State Machine / Saga 패턴 중 어디로 가야 하나.