상품 관리 — 직접 짤까, 맡길까?

핵심 요약

• 상품 카탈로그는 커머스의 모든 흐름이 시작되는 기준점​​이에요. SKU·옵션·가격·재고·판매 상태가 카탈로그에 고정돼야 체크아웃과 주문이 안정적으로 연결돼요.
• 자체 DB로 짤지 커머스 API에 위임할지는 상품 복잡도 · 운영자 편집 빈도 · 기존 시스템 존재 여부 세 축으로 판단해요.
• 자체 DB가 유리한 경우: 상품이 많고 복잡한 옵션·재고 로직이 있거나, 기존 ERP·PIM 시스템이 이미 있는 경우​.
• 커머스 API가 유리한 경우: 상품 수가 제한적이고, 운영자가 관리자 페이지에서 직접 상품을 추가/수정하는 빈도가 높은 경우​.
• 혼합 모델: 원장은 자체 DB, 판매 가능 상품만 커머스 API에 동기화​​하는 방식이 중간 규모 팀에서 가장 많이 쓰여요.

이런 상황이라면

D2C 브랜드를 운영하는 기획자가 있어요. 상품이 50개 정도이고 시즌마다 30개씩 추가돼요. 옵션은 색상·사이즈 2축이고, 재고는 옵션 단위로 관리해요. 지금까지는 엑셀로 상품 관리를 해왔는데, 커머스 API를 도입하려고 해요.

개발자분이 물어요. "상품을 커머스 API 쪽에 전부 올릴까요, 아니면 우리 DB에 상품 테이블을 만들고 일부만 동기화할까요?" 전자는 관리자 페이지에서 바로 편집하는 게 편하지만 기존 엑셀 관리 흐름이 깨져요. 후자는 기존 흐름을 유지할 수 있지만 동기화 로직을 직접 짜야 해요. 중간 규모 팀에서 뭐가 더 현실적인지 판단이 안 돼요.

이 글은 상품 카탈로그의 단일 소스를 어디에 두고, 어떤 기준으로 직접 관리와 위임을 결정할지 정리해요.

1카탈로그는 단순 등록 화면이 아니라 "판매 기준점"

많은 팀이 "상품 테이블 = 상품 목록 화면용 데이터"로 생각하고 시작해요. 그러나 실제로는 다음 전부의 기준점이에요.

• 체크아웃​: 상품 ID·가격·옵션·수량을 체크아웃 SDK에 넘겨요
• 주문 생성​: 주문에 어떤 상품이 몇 개 담겼는지 저장해요
• 결제 검증​: 서버가 받은 주문 금액이 실제 상품 가격과 일치하는지 대조해요
• 취소·환불​: 부분 취소 시 어떤 상품·수량이 취소됐는지 추적해요
• 재고 관리​: 주문 시 차감, 취소 시 복구
• 관리자 운영​: 품절·판매중지·숨김 상태를 자주 바꿔요
• 프로모션​: 할인·쿠폰 적용 대상을 상품 ID로 지정해요

이 전부가 하나의 상품 원장​​을 기반으로 해요. 원장이 둘로 갈리면 가격·상태 불일치가 즉시 나타나요.

2자체 DB vs 커머스 API — 책임 분할 비교

3판단 기준 3가지

① 상품 복잡도와 옵션 구조

단순 (옵션 없음, 단일 가격): 커머스 API로 충분. 중간 (옵션 2~3축, 옵션별 가격): 커머스 API 지원 범위 확인. 대부분 지원해요. 복잡 (옵션 4축+, 번들·세트·구독형·커스터마이징 상품): 자체 DB가 필요할 수 있어요. 커머스 API 스키마에 억지로 매핑하면 유지 비용이 급증해요.

② 운영자 편집 빈도

자주​: 관리자 페이지에서 바로 편집이 필요. 커머스 API 관리자 페이지​​를 그대로 쓰면 자체 관리자 UI 개발을 생략할 수 있어요. 드물게 (월 1~2회): 자체 DB + 간단한 편집 스크립트로도 충분.

③ 기존 시스템 (ERP·PIM·WMS) 존재

이미 있어요​: 자체 DB로 통합. 커머스 API에 중복 등록하면 동기화 문제가 생겨요. 없어요​: 커머스 API가 그 자체로 상품 원장 역할을 해요.

4시나리오별 권장 모델

신규 D2C 브랜드 (상품 50개, 기존 시스템 없음)

커머스 API 단독. 관리자 페이지를 바로 쓰고, 결제·주문도 커머스 쪽에서 처리해요. 운영자가 직접 상품을 추가해요.

기존 쇼핑몰 (이미 상품 DB와 관리자 UI 있음)

자체 DB 유지 + 결제 API. 상품 원장은 기존 DB에 두고 결제만 붙여요. 커머스 API로 이관은 별도 프로젝트로 분리.

ERP·PIM 통합 운영 (대형 브랜드)

자체 DB (ERP 연동) + 혼합 동기화. 원장은 ERP, 커머스 API에는 판매 중인 상품만 동기화해서 관리자 페이지 편집 기능을 일부 활용.

B2B 마켓플레이스 (셀러가 상품 등록)

커머스 API + 셀러 그룹별 권한. 셀러가 직접 관리자에서 상품을 등록하도록 권한을 분리. 자체 구축보다 개발 비용이 훨씬 낮아요.

구독형 서비스 (플랜 5개 이하)

커머스 구독 API. 플랜 자체가 상품 역할. 별도 카탈로그 설계가 거의 불필요.

맞춤 제작·견적 기반 서비스

자체 DB + 결제링크. 매번 가격이 달라서 표준 카탈로그 구조가 맞지 않아요. 주문마다 자체 DB에 기록하고 결제만 링크로 받아요.

5혼합 모델 — 원장은 자체, 판매 상품만 동기화

중간 규모 팀에서 가장 많이 쓰는 패턴이에요.

구조​:

1. 자체 DB에 상품 원장 (기존 엑셀·ERP 연동)
2. 판매 가능 상품만 커머스 API에 동기화 (API 배치 또는 이벤트 트리거)
3. 체크아웃·주문·결제는 커머스 API 쪽에서 처리
4. 정산·매출 분석은 자체 DB에서

장점​:

• 기존 상품 관리 흐름 유지
• 관리자 페이지는 커머스 쪽 것을 운영자가 바로 사용
• 커머스 API의 결제·주문·취소 로직 활용

주의점​:

• 동기화 실패 시 어느 쪽을 믿을지 정책을 정해둬야 한다 (보통 자체 DB 우선)
• 가격 변경 시점에 체크아웃 중 주문이 있는지 확인하는 안전장치 필요
• 재고는 한쪽에서만 차감​​해야 한다 (둘 다 차감하면 중복 차감)

6자주 놓치는 지점 3가지

"처음엔 커머스 API만으로 충분, 나중에 확장" 함정

소규모 시작 시 커머스 API에 상품을 직접 등록하기 쉬워요. 그런데 1년 뒤 ERP 도입이나 대량 마이그레이션 상황이 오면 커머스 API → 자체 DB로 원장을 옮기는 게 쉽지 않아요. 초기부터 "원장이 어디에 있을지" 미리 정해두는 편이 나아요.

가격 이력 관리 누락

상품 가격이 바뀌면 과거 주문의 가격​​이 어떻게 남는지 확인해요. 커머스 API는 대부분 주문 시점 가격을 주문에 저장하지만, 자체 DB 구현은 이 점을 놓치기 쉬워요. 3개월 뒤 CS에서 "그때 가격으로 환불"이 안 되는 사고가 발생해요.

재고 이중 관리

자체 DB와 커머스 API 양쪽에 재고 필드를 두면 동기화 실패 시 판매 허용 여부가 어긋나요​. 재고는 한쪽에만 두고, 다른 쪽은 참조만 해요. 보통 자체 DB가 단일 소스예요.

다음 단계

상품 관리 범위가 정해졌다면 다음은 회원 관리와 체크아웃 설계예요.

추천 콘텐츠

주문 상태는 어디까지 우리가 관리해야 하나요? 주문 테이블을 자체 관리할지 커머스에 위임할지 판단.

회원 관리 — 결제에 필요한 최소 회원 모델은? 회원 식별과 결제의 경계.

체크아웃 플로우 설계 장바구니 → 주문 → 결제 흐름 분기점.

바로 참고할 문서

• 개발 문서​: 카탈로그 이해하기 — 상품 CRUD·상태·SKU
• 도입 문의​: 도입 문의