E 커머스에서 가장 중요한 Object중에 하나인 주문서.

유저의 많은 행동이 주문서를 중심으로 일어납니다.

반대로 회사 입장에서도 주문서는 정말 중요한 객체입니다.

왜냐하면 모든, 혹은 대부분의 수익이 주문서로부터 획득되기 때문이죠.

노코드 SaaS툴로서의 커머스 기능을 개발하면서 “주문서”를 만들어가는 방식에 대해 경험하고 생각했던 부분을 정리해보고자 합니다.

(설계에 대한 정답을 전달하고자 하는 것은 아닙니다. 단지 한 사람의 의견으로 봐주시면 감사드리겠습니다.)

기본 설계

주문서를 설계하기 전에 우선 어떤 거래방식을 취하는지 정리해봅니다.

구매 방식

우선 구매라는 행위에 대해서는

• 팀으로 다수가 함께 결제할 수도 있고
• 중고거래와 같이 구매자와 1대1 거래가 될 수도 있고
• 브랜드를 운영하는 홈페이지에서의 상품 판매가 될 수도 있고
• 쿠팡과 같이 여러 판매자를 거느린 오픈 플랫폼일 수도 있습니다.

구매 방식에 따라 데이터의 depth는 달라집니다.

중고거래

가장 간단한 구조입니다.

복잡한 상품별 배송사에 대해서도 생각하지 않아도 됩니다.

하나의 주문서에 하나의 셀러, 하나의 상품 정보만 담겨있으면 됩니다.

중고거래 혹은 1대1 거래라는 핵심 비즈니스가 변하지 않는 이상 주문서의 변동성 또한 낮습니다.

전문몰

모든 상품이 동일한 배송회사를 이용한다면 위와 같은 구조에 상품들이 추가되는 형식이겠지만 서로 다른 배송회사 혹은 배송방식이 택해지는 경우가 있습니다. 배송 방식의 경우 아래 후술하겠지만 온라인 상품 + 실물 상품을 섞어 주문하는 경우까지 고려해야합니다.

따라서 구조는 이전과 동일하게 Seller기반으로 묶여있되 배송을 기준으로 한 번 더 그룹핑 해주어야 합니다.

오픈 마켓

가장 복잡한 구조를 가진 오픈 마켓입니다.

다수의 셀러를 거느리고 있으며 셀러별로 배송사나 배송방식이 달라질 가능성이 있습니다.

1차적으로 그룹핑되는 대상은 Seller이며 그 다음 Delivery 그 다음 개별 상품들이 위치하게 됩니다.

3단 구조를 지니게 되어 복잡성이 굉장히 높아집니다.

그 외

펀딩, 팀구매 → 펀딩의 경우 구매 프로세스에서 결제 시점과 목표에 대한 정책을 정의해야합니다. 목표에는 수량일 수도 있고 금액일 수도 있고 플랫폼 내부의 특정 포인트일수도 있습니다. 목표가 달성되었을 때 전후로 결제, 취소, 환불, 교환에 대한 정책을 정의해야 합니다.

구독 → 정기 배송의 경우는 아니지만 구독은 결제수단 등록등의 절차가 있어 대체로 단일 상품을 거래하게됩니다. 따라서 중고거래와 비슷한 형태가 되죠. 경우에 따라서는 중고거래와 마찬가지로 장바구니 기능이 필요없을 수도 있습니다.

상품 종류와 배송

상품의 종류를 여러가지 기준으로 나눌 수 있겠지만 프로세스적으로 가장 중요하게 생각해야하는 부분은 배송 여부입니다.

즉,

• 실물 상품
• 온라인 상품

2가지로 분류해봅니다.

실물이라고 모두 배송하는 것은 아닙니다.

픽업이라는 수단이 등장합니다.

픽업과 배송이 공존한다면 위에서 소개한대로 배송사별로 나눌 때 픽업이라는 옵션을 같은 위계에 추가하면 됩니다.

다만 픽업만이 유일한 수단이라면 단일 셀러에 여러 상품을 담게 만들기만 하면 됩니다.

상품 옵션에 관해

모든 주문서에는 상품과 관련된 정보가 들어갑니다.

그 중에서 Frontend로서 구현하기 까다로웠던 것이 상품 옵션입니다.

상품이 빨간색인지 S인지 M인지만 구분하면 되는거 아니야? 라고 하실 수 있지만

그 뒷단에는 많은 고뇌가 들어가 있습니다.

모든 옵션의 경우의 수를 동일한 상품으로 취급하면 안 됩니다.

실제로 SKU (Stock Keeping Unit) 은 모든 상품 유닛에 대해 기록됩니다.

즉 옵션의 경우의 수 만큼 서로 다른 데이터로서 취급해주어야 한다는 뜻 입니다.

커튼을 주문한다고 했을 때 색상, 가로, 세로에 대한 옵션이 각각, 10가지, 10가지, 10가지라면

1000개의 상품 옵션 경우의 수가 존재하게 됩니다.

사용자에게 보여주는 쪽이라면 비교적 간단합니다. 옵션 박스를 모두 선택했을 때 어떤 상품 옵션인지 결정하면 되니깐요.

다만 Validation에 유의해야합니다. 옵션을 위에서부터 고르는 것을 강제할수도 있고 아래에서부터 고르는 것까지 허용해줄 수도 있습니다. 다만 마지막 옵션을 선택할 때 재고가 없는 것은 확실하게 표시를 해 주어야 합니다.

관리자가 상품의 가격을 설정하는 어드민 화면은 상당히 많은 정책들을 고려해야 합니다.

정말 많은 것들을 고려해야 하기에 그 중에 몇 가지만 알려드리고 넘어가도록 하겠습니다.

• 새로운 옵션의 추가 / 삭제

→ 예를들어 기존에 옵션이 아래와 같이 하나의 옵션 2가지 선택지만 있었다고 해봅시다.

Color: Red / Yellow

그렇다면 상품의 경우의 수는 2가지입니다.

각각 Product Red, Product Yello라고 해봅시다.

그런 경우가 드물지만 각각 가격이 다르다고 가정해봅시다.

여기서 Size : S / M 을 추가하면 경우의 수가 2가지 늘어 4가지가 됩니다.

경우의 수가 2개 증가했다고 볼 수 있겠지만 사실 새로운 SKU를 가진 상품 4개가 생긴샘입니다.

Product Red S , Product Yellow S

Product Red M, Product Yellow M

새롭게 생겨난 4개의 Product의 가격은 어떻게 해야 할까요?

초기화를 하는 방법이 있을 수 있습니다.

확실히 고객들에게 고지를 한다면 유지보수 측면에서 뒷탈이 없는 가장 깔끔한 방법일 수 있습니다.

다만 옵션에 추가에 따라 모든 경우의 수에 대해 가격을 다시 채워넣어야 되는 귀찮음이 생기죠.

다른 방법도 있습니다.
기존 Product Red의 가격을 따라가게,
Product Yellow의 가격을 따라가게
새로운 옵션은 결국 이전 옵션들의 확장이기 때문에 가격을 그대로 채워주는 방법도 있습니다.

어디가 정답인지는 정해져있지 않은 것 같습니다.
어드민의 경우 지속적으로 어드민ㄷ 행동패턴을 파악하고 어떤 변화가 빈번하게 일어나는지를 체크해보는 것이 유효합니다.

번외: Snap!

주문서에는 크게 구매했던 상품에 대한 상세한 정보와 결제에 관련된 정보 그리고 판매자에 대한 정보들이 담깁니다.

여기서 저장되어있는 데이터가 시간에 따라 변하는 것들이 있는데 그중에 가장 빈번하게 변하는 것은 상품의 가격입니다.

상품은 유행이 지나서 가격이 떨어질수도 있고 타임세일이나 블랙프라이데이라서 가격이 할인되었을 수도 있습니다.

상품에는 소비자가, 공급가, 판매가, 할인가, 인하가 등등 여러가지 가격들이 있는데 종단에 판매되는 판매가는 빈번하게 바뀔 수 있습니다.

또한 세세하게는 브랜드의 로고 이미지, 이름, 상품 이름등등 많은 것들이 미묘하게 달라지는데

이럴때마다 새 상품을 만들 수는 없습니다.

왜냐하면 유의미한 데이터들과 소비자들로 하여금 구미가 당기는 리뷰들을 옮기기 까다롭기 때문입니다.

그래서 주문서에 당시에 데이터들중에 변동성이 크지만 UI적으로 소비자에게 알려야하는 항목들을 당시 기준의 정보들로 Snap샷을 함께 담습니다.

그렇게해야 소비자들은 혼동없이 당시 구매했던 이력을 정확하게 조회할 수 있을 것 입니다.