이커머스

이커머스 소프트웨어 — 상품, 가격, 재고 데이터를 보관하고 인터넷으로 주문을 받아 결제를 처리한 뒤 주문을 실행 단계로 넘기는 시스템입니다: 창고로, 배송으로, 회계로.

일반 웹사이트와 다른 점은 페이지가 아니라 회계 객체를 다룬다는 것입니다: 상품, 가격, 재고, 주문, 결제, 출고, 반품 — 저마다 상태와 이력을 가진 레코드입니다. 같은 주문이 앱에서도, 자판기에서도, 매니저에게서도, 마켓플레이스에서도 들어올 수 있습니다.

이것은 쇼윈도 자체가 아니라 쇼윈도 위에 놓인 회계 회로입니다. 회계를 다시 쓰지 않고도 쇼윈도를 바꾸거나 하나 더 추가할 수 있습니다.

시스템을 이루는 요소

• 스토어프론트 — 구매자 인터페이스: 웹사이트, 모바일 앱, 자판기 화면, 셀프서비스 키오스크
• 데이터 코어 — 상품, 카테고리, 속성, 가격, 재고, 고객, 주문
• 비즈니스 로직 — 가격, 할인, 상품 판매 가능 여부, 배송비와 세금 계산 규칙
• 프로세스 계층 — 주문 상태, 재고 예약, 결제 처리, 출고, 반품
• 연동 계층 — CRM, ERP, 창고, POS, 결제·물류 서비스와의 데이터 교환
• 관리자 패널 — 콘텐츠 매니저, 주문 담당자, 카테고리 매니저의 업무 공간
• 분석 — 매출, 퍼널, 재고, 반품에 대한 데이터 마트

자동화는 «판매원 대신 로봇»이 아니라, 반복되는 작업을 시스템이 스스로 적용하고 그 결과를 이력에 기록하는 규칙으로 옮기는 일입니다.

규칙은 조건이 바뀌기 전까지 계속 작동합니다. 통제는 그대로 남습니다: 모든 자동 동작에는 작성자, 시각, 이전 값이 로그에 남습니다.

자동 모드로 넘어가는 것:

• 상품 게시와 판매 중지
• 규칙과 마크업에 따른 가격 재계산
• 일정에 따른 프로모션 시작과 종료
• 프로모션 코드 검증과 사용 처리
• 주문에 대한 재고 예약
• 주문 상태 변경
• 대금 청구와 환불
• 배송비 계산
• 출고 서류 생성
• 배송 업체로 주문 전달
• 단계마다 고객에게 알림
• 취소 후 상품의 재고 복원
• CRM과 ERP로 데이터 전송
• POS에서 영수증 세무 처리
• 리포트와 데이터 마트 갱신
• 재고 부족 알림

가격 — 상품 카드의 필드가 아니라 요청 시점에 규칙으로 계산한 결과입니다. 한 상품에 여러 가격이 동시에 존재하고, 시스템이 적용할 가격을 고릅니다.

그래서 수천 개의 상품 카드에서 가격을 고칠 필요가 없습니다: 규칙이나 기본 가격표를 바꾸면 됩니다.

가격 책정의 계층:

• 기본 가격 — 회계 시스템에서 가져오거나 수동으로 지정한 가격
• 가격표 — 소매, 도매, 파트너, 지역별
• 마크업 규칙 — 매입가 대비 비율이나 금액, 카테고리나 공급처 단위로
• 개별 가격 — 고객 세그먼트나 특정 계약에 따라
• 수량 구간 — 주문 수량에 따라 가격이 달라짐
• 통화와 반올림 — 환율 환산과 «보기 좋은» 단위로의 조정
• 세금 — 품목별 세율, 세금 포함가와 미포함가

모든 가격 변경은 이력에 기록됩니다: 누가, 언제, 어떤 규칙으로 바꿨고 이전 값은 얼마였는지. 마진 리포트와 다툼이 있는 주문의 분석이 이 이력에 기댑니다.

적용 순서

규칙은 우선순위에 따라 풀리며 무작정 합산되지 않습니다. 품목 가격의 일반적인 계산 순서는 이렇습니다:

• 구매자의 가격표를 확인
• 그 가격표에서 품목의 기본 가격을 가져옴
• 수량에 따른 구간 가격 적용
• 계약의 개별 조건 반영
• 우선순위가 가장 높은 프로모션 적용
• 프로모션과 병행 가능하면 프로모션 코드 적용
• 적립금 적립과 사용 처리
• 세금과 품목 합계 계산

병행 가능 여부는 명시적으로 정합니다: 어떤 할인이 합산되고, 어떤 할인이 서로 배타적이며, 허용되는 최저 가격은 얼마인지. 최저 가격 제한이 있어 올바른 할인이 여럿 겹쳐도 품목이 손해로 넘어가지 않습니다.

장바구니 — 주문 초안입니다: 구매자에게도 상점에게도 아직 의무를 만들지 않은 품목 묶음. 담긴 상품은 예약되지 않고 가격도 확정되지 않아, 열 때마다 다시 계산됩니다.

재계산은 네 가지를 확인합니다: 상품이 판매 중인지, 창고에 넉넉한지, 가격이 바뀌지 않았는지, 할인이 유효한지. 바뀐 점은 돈이 빠져나간 뒤가 아니라 결제 전에 구매자에게 보입니다.

장바구니가 갖춰야 할 것:

• 기기 사이를 넘나들기 — 브라우저에서 담은 장바구니가 로그인 후 앱에서 열립니다
• 계정 없이 쓰이기 — 비회원도 바로 담고, 로그인은 주문서 작성에서만 필요합니다
• 로그인할 때 합쳐지기 — 비회원 장바구니는 저장된 장바구니를 덮어쓰지 않고 합쳐집니다
• 제한 지키기 — 최소 금액, 포장 단위 배수, 고객당 수량 제한
• 살 수 없는 것 나누기 — 판매 중지되었거나 품절된 품목은 따로 빼서 보여 줍니다
• 계산 과정 드러내기 — 합계가 품목 금액, 할인, 배송비, 세금으로 나뉘어 보입니다

주문 — 구매 구성, 작성 시점의 가격, 구매자, 배송과 결제 조건을 확정하는 문서입니다. 이후 주문은 정해진 상태 집합을 따라 움직이고, 모든 전환이 기록됩니다.

가격과 할인은 주문서 작성 때 확정됩니다: 가격 변경이나 프로모션 종료는 이미 만들어진 주문에 영향을 주지 않습니다 — 그러지 않으면 결제 금액과 영수증 금액이 어긋납니다.

단계별 주문서 작성:

• 장바구니: 가격 재계산, 구매 가능 여부와 제한 확인
• 구매자 확인: 로그인, 회원 가입 또는 계정 없이 주문
• 배송 선택: 주소, 수령 장소, 시간대, 요금 계산
• 결제 수단 선택과 프로모션 코드 적용
• 주문 품목에 대한 재고 예약
• 주문과 주문 번호 생성, 확인 안내 발송
• 결제 또는 수령 시 결제의 확인
• 실행으로 전달: 피킹, 출고, 배송

재고 — 지금 바로 판매할 수 있는 상품의 수량입니다. 창고에 있는 물리적 수량과는 다릅니다: 일부는 주문에 예약되어 있고, 일부는 이동 중이며, 일부는 불량으로 묶여 있습니다.

판매 가능 수량 = 실물 재고 − 예약 − 묶임 + 확정된 입고 예정분(선주문이 허용된 경우).

창고와 매장이 여럿이면 재고는 창고별로 따로 계산하고, 스토어프론트에는 선택한 지역으로 배송이 가능한 창고들의 합이 보입니다.

데이터 교환의 구조:

• 전체 전송 — 재고 목록 전체를 일정에 따라, 보통 야간에
• 증분 교환 — 지난 동기화 이후의 변경분만, 몇 분 간격으로
• 이벤트 — 회계 시스템이 변경이 일어난 그 순간에 스스로 알림
• 메시지 큐 — 창고나 사이트가 잠시 멈춰도 교환이 사라지지 않음
• 충돌 해결 — 값이 어긋날 때 누구의 값을 맞다고 볼지 미리 정해 둠

예약에는 언제나 유효 기간이 있습니다: 제때 결제되지 않은 주문은 상품을 다시 판매로 풀어 줍니다 — 그러지 않으면 버려진 장바구니가 판매 가능한 재고를 «먹어» 버립니다.

재고를 정확히 관리하면 얻는 것

• 구매자가 없는 상품을 주문하지 않습니다
• 상담원이 취소 전화에 시간을 쓰지 않습니다
• 상점 잘못으로 생기는 환불 결제가 없습니다
• 구매 담당이 품목별 실제 소진 속도를 봅니다
• 선주문과 재입고 알림이 정직한 기한으로 작동합니다
• 재고 회전 리포트가 믿을 수 있는 데이터에 기댑니다

불일치가 자주 생기는 곳

• 오프라인 매장의 판매가 제때 교환에 들어오지 않은 경우
• 버려진 장바구니에서 남은, 유효 기간 없는 예약
• 실제 입고보다 늦게 창고에 등록된 반품
• 예약을 다시 계산하지 않은 회계 시스템의 수동 수정
• 구성품 차감이 잘못 설정된 세트 상품

창고 담당자 — 상품을 실제로 옮기는 직원입니다: 입고를 받고, 셀에 넣고, 주문에 맞춰 품목을 꺼내고, 포장한 상자를 배송기사에게 넘깁니다. 시스템은 이 동작을 직원의 말로 아는 것이 아닙니다: 모든 작업이 바코드 스캔으로 확인됩니다.

차이는 근본적입니다. 목록의 «완료» 표시는 의도를 확인해 주지만, 스캔은 사실을 확인해 줍니다: 어느 품번을, 어느 셀에서, 어느 직원이, 초 단위 시각에. 품번의 오타는 한 달 뒤 재고 조사에서야 드러나지만, 잘못된 바코드는 앱이 아예 받지 않습니다.

창고 담당자가 한 근무조에 하는 일:

• 입고 검수 — 입고를 거래명세서와 품목 하나하나 대조합니다. 부족, 오배송, 불량은 입고 시점에 기록되어 공급처 클레임으로 넘어가고, 주문 피킹 중에 발견되지 않습니다
• 라벨 부착 — 읽을 수 있는 바코드가 없는 상품에는 내부 라벨을 출력합니다. 라벨이 없는 품목은 창고에 받지 않습니다
• 적치 — 상품 스캔과 셀 스캔이 둘을 연결합니다: 시스템은 낱개 하나하나가 어디에 있는지 기억합니다
• 피킹 — 앱이 셀을 도는 경로를 만들어 안내합니다; 셀마다 스캔으로 필요한 품목을 필요한 수량만큼 집었는지 확인합니다
• 포장 — 상자의 구성은 스캔으로 모입니다: 스캔되지 않은 것은 상자에 들어가지 않은 것입니다
• 출고 — 상자는 스캔으로 배송기사에게 넘어가고, 책임도 그 스캔과 함께 옮겨 갑니다
• 이동과 보충 — 셀 사이, 그리고 보관 구역에서 피킹 구역으로 옮겨 잘 나가는 상품을 더 가까이 둡니다
• 재고 조사 — 창고를 세우지 않고 셀 단위로 다시 셉니다: 셀은 자기 차례를 세는 동안에만 잠깁니다
• 청구 — 불량, 파손, 유통기한 경과: 사유, 사진, 담당자와 함께

개인 계정 — 구매자가 상담원을 거치지 않고 자기 데이터에 접근하는 곳입니다: 주문, 문서, 주소, 결제 수단, 반품. 계정에서 풀린 질문 하나하나가 고객지원에 걸려 오지 않은 전화입니다.

계정은 자기만의 데이터를 따로 보관하지 않습니다: 상담원이 관리자 패널에서 보는 것과 같은 객체를, 다만 이 고객의 기록만, 그리고 그에게 허용된 작업만 보여 줍니다.

안에 무엇이 있는가:

• 주문 이력 — 주문마다 구성, 금액, 상태, 문서와 영수증
• 배송 추적 — 현재 실행 단계와 운송사의 운송장 번호
• 주문 다시 담기 — 지난 구성이 가격과 재고 확인을 거쳐 장바구니로 옮겨집니다
• 반품 — 품목과 사유를 적어 내는 신청과 처리 진행 상황 확인
• 주소와 수령인 — 저장된 배송 주소, 연락처, 수령 장소
• 결제 수단 — 번호를 저장하지 않고 토큰으로 연결해 둔 카드
• 적립금과 등급 — 적립 잔액, 소멸 기한, 받을 수 있는 제안
• 구독과 동의 — 알림 채널과 개인정보 처리 동의, 클릭 한 번으로 철회 가능

법인 계정

B2B에서는 계정이 더 복잡합니다: 한 조직에 권한이 다른 직원이 여럿 있습니다. 구매 담당이 주문을 만들고, 책임자가 승인하고, 회계 담당이 증빙 서류를 받아 갑니다. 주문은 하나이고 동작은 나뉩니다.

• 한 조직 계정 안의 여러 사용자
• 계약 가격과 개별 결제 유예 조건
• 실행으로 넘기기 전의 주문 승인
• 문서 영역의 청구서, 확인서, 거래명세서
• 품번 목록과 파일 업로드로 하는 주문

로그인과 보호

일회용 코드나 비밀번호로 로그인하고, 돈과 연락처 변경에는 2차 인증을 걸며, 세션 로그에서 다른 기기의 연결을 끊습니다. 메일이나 전화번호 변경은 기존 주소와 새 주소 양쪽에서 확인합니다.

연동 — 외부 프로그램과 합의된 데이터 교환입니다: 무엇을, 어떤 형식으로, 얼마나 자주 주고받는지, 데이터는 누구의 것인지, 장애가 나면 어떻게 되는지.

시스템이 연결되는 곳:

• CRM — 고객, 문의, 거래, 개별 가격과 발송을 위한 세그먼트
• ERP와 회계 시스템 — 품목 마스터, 가격, 판매 문서, 채권채무
• WMS와 창고 — 창고별 재고, 예약, 피킹 지시, 반품 입고
• POS와 세금 저장 장치 — 판매와 환불 영수증, 오프라인 매장과의 교환
• 결제 대행사 — 승인, 청구, 환불, 대사를 위한 내역
• 배송 업체 — 요금, 일정, 운송 건 생성, 상태
• 마켓플레이스 — 상품 구색 전송, 주문 접수, 재고 갱신
• 마케팅 — 메일과 메신저 발송, 웹 분석 시스템, 상품 피드

판매와 돈

• 매출, 주문 수, 평균 구매액, 구매당 품목 수
• 품목과 카테고리별 원가, 매출총이익, 마진율
• 할인의 영향: 할인 총액과 할인이 있을 때와 없을 때의 매출
• 결제 수단별 구성과 실패한 결제의 비율

상품과 재고

• 판매 순위와 움직이지 않는 «죽은» 품목
• 재고 회전율과 일수로 본 수요 충족 기간
• 놓친 수요: 재고가 0인 상품에 대한 조회
• 결과가 없는 검색어 — 상품 구색에 대한 직접적인 힌트

고객과 행동

• 신규 구매자와 재구매자, 구매 빈도와 최근성
• 주문서 작성 퍼널: 어디에서 주문이 끊기는가 — 배송, 결제, 회원 가입
• 버려진 장바구니: 구성과 금액
• 사유별, 상품별, 공급처별 반품

확장성은 다시 쓰지 않고도 성장을 견디는 능력입니다. 세 가지 값이 커집니다: 카탈로그의 크기, 동시 방문자 수, 시간당 주문 수.

카탈로그는 검색과 필터링에, 최대 트래픽은 페이지 응답에, 주문 흐름은 데이터베이스와 외부 연동에 부딪힙니다. 해법도 저마다 다르고 필요해질 때 하나씩 적용합니다.

실제로 쓰이는 방법:

• 캐싱 — 카탈로그 페이지와 무거운 질의의 결과는 캐시에서 내주고, 상품이 바뀌는 사건에 맞춰 갱신합니다
• 분리된 검색 — 검색 인덱스는 따로 두어, 수십 개 속성에 대한 필터링이 메인 데이터베이스를 누르지 않습니다
• 읽기와 쓰기의 분리 — 스토어프론트는 복제본에서 읽고, 주문은 메인 데이터베이스에 씁니다
• 수평 확장 — 로드 밸런서 뒤에 애플리케이션 인스턴스를 여럿 두고, 그 수를 부하에 맞춰 바꿉니다
• 큐 — 무거운 작업은 백그라운드로 수행되고, 주문서 작성은 그것을 기다리지 않습니다
• CDN — 이미지와 정적 파일은 구매자에게 가장 가까운 노드에서 내줍니다
• 모듈성 — 검색, 추천, 결제는 서로 독립적으로 확장하고 갱신합니다

최대 부하 전에 확인하는 것

• 메인 페이지가 아니라 «카탈로그 → 장바구니 → 결제» 시나리오의 부하 테스트
• 결제 대행사와 배송 업체를 쓸 수 없을 때의 동작
• 카탈로그 전체 재색인의 속도
• 백업에서의 복구 시간
• 외부 시스템의 한계: ERP와 창고가 분당 몇 건의 요청을 견디는지

방향별 성장

• 새로운 판매 채널: 앱, 자판기, 마켓플레이스, 키오스크
• 새로운 창고와 수령 장소
• 새로운 통화, 언어, 법인
• 새로운 판매 모델: 구독, 선주문, B2B 계약