커머스 플랫폼은 어떻게 정의내려야할까?

---

플랫폼이란?

 

내가 정의하는 플랫폼 기획은
1) 단순한 소비자 (수요자) 가 아닌, 여러 player (공급자) 들이 포함되는 생태계
2) 오프라인이 아닌 온라인에서 일어나는 거래(결제액션)를 포함해야한다. 
 
패션 커머스에서는 상품을 구매하는 유저(앱사용자) & 오픈마켓까지 포함하고 있다면 셀러(판매자), 사입하는 패션 MD 등 다양하다. 
배민과 같은 커머스는 배달을 시키는 사람(앱사용자), 라이더 (배달하는자), 음식을 만드는 사람(자영업자) 등 기획할 때 각각의 이해관계자를 고려해야한다. 
 

 
 
 
 
 

커머스 생태계

 

무신사, 29cm, g마켓 등 이머커스 생태계는 지는 산업으로 알고 있지만, 서비스 기획자들은 꼭 알아야할 도메인이랄까?
꼭 알아야 좋다. 서비스 growth 의 고객 여정을 짤때도 결제 앞뒤로 이커머스 프레임워크를 많이 사용하기 때문이다.

 

서비스 기획자를 뽑을 때도 각 도메인이 깊이가 너무 깊다보니, 이커머스 중에서도 전문성을 가진 기획자를 채용한다. 
하지만 커머스는 깊이 만큼 넓기도 넓어서 교집합되는 영역이 많다. 나조차도 지엽적으로 마케팅 도메인만 직접적으로 기능을 만들어봤다. 나머지는 운영으로 간접적인 경험이 있다. 


[회원] 구매자/판매자
[상품]
(전시, 탐색 - 옵션 & 필터 & 정보추천, 판매자정보, 상품등록 프로세스 - 판매자 입점)
[조건/가격]
(당일배송, 익일배송, 적립, 할인, 상품조건)
[주문] (교환/반품/재배송) - 신속한 교환 처리, 주문 상태값이 굉장히 많이 바뀐다
[포인트/쿠폰]
[광고/이벤트/추천/푸시]
(마케팅 도메인)

회원(Member) 도메인을 정의내려보자.

[개요] 회원가입 처리를 한 사용자로 로그인 (ID, Password)정보를 서비스에게 제공하는데 동의한 사용자들 칭한다.
해당 서비스에서 제공하는 혜택, 결제 이용가능하다.
회원 정보 기반으로 맞춤 서비스를 제공한다.

[회원가입]
회원가입 = 계정 생성과 같다. 회원 기본정보 DB 에서 각각의 정보가 생성된다.
sign-up rates 을 올리는 것은 유입 전략에서 가장 고려해야하는 지점이기에 UX적으로는 가장 최소한의 정보로 가입을 시키기위해 간편 로그인으로 회원가입을 유도한다. 

[인증 서비스]
요즘 인증 방법은 굉장히 다양한데, 보통 휴대폰 점유인증을 많이들 사용한다. 

휴대폰 본인 인증
이메일 점유 인증
공인인증서
생체인증
카드인증 (온라인 결제할 때 카드 정보 입력할 때)


[단일, 복수 계정 정책]
사용자 1 : 계정 1
(CI 인증 = 고객을 식별, 사용자 신원을 입증하기 위해 암호화 시키는 것이다. 이커머스에서 주민등록번호(개인을 식별하기 위한) 의 역할을 하는 값으로, 한 사람당 1개의 고유한 CI 를 제공한다)
사용자 1 : 계정 n
(DI 인증할 수 있는 계정)

회원 도메인을 어떻게 접근할 수 있을까? 

 
G마켓를 통해 DB 스킴을 대략 유추해보려했다. 
기본적인 회원가입 절차가 있지만 간편로그인 (카카오, 애플, 등) 으로 회원가입처리를 할 수 있고, 대략 아래와 같은 flow 를 가졌다. 

[FLOW]

 
 

[Validation check]

고려한 사항은 기존 회원정보가 있을 때 서버까지 가서 validation check 할 것인지, 클라이언트에서 화면상으로 에러노출을 할 것인지이다. 

 

 
 

[정책서]

 

데이터 타입까지 일일이 정하는 것을 위험하지만, 대략 DB Scheme 을 백엔드 개발자에게 hand-off 할 때 정해준다.
이때 Not Null, CHAR, VARCHAR의 개념만 정리하면 아래와 같다.
 

CHAR: 고정 길이 문자열입니다. 설정된 길이보다 짧은 문자열을 저장할 경우, 남는 공간은 공백으로 채워집니다. 예를 들어, CHAR(5)에 "ABC"를 저장하면 "ABC " (2개의 공백 포함)로 저장됩니다. (ex. 국가 코드, 성별 코드)

VARCHAR: 가변 길이 문자열입니다. 입력된 문자열의 실제 길이에 따라 저장 공간이 결정되며, 필요한 만큼만 공간을 차지합니다. 예를 들어, VARCHAR(20)에 "Hello"를 저장하면 실제로는 5바이트만 사용합니다.

Not null = 필수입력 이라는 뜻으로 반드시 사용자가 값을 입력해야한다는 의미다. NULL 값이 저장될 수 없다. (이때, 공백 ‘ ’은 값으로 취급되므로 NOT NULL 하고는 다른 개념이다. )

해당 데이터 모델링은 1) 일반 회원가입 2) 카카오 간편 로그인 만 있다는 전제하에 작성했다.

 
 

추가로 카카오로 로그인했을 때 파싱하는 데이터가 신규 가입처리 & 기존에 있는 회원 정보 연동시 어떻게 각 데이터가 처리되는지 구분이 필요하다. 다음 게시글에서는 회원 등급 테이블 등 회원기본정보 외에 얽혀있는 테이블들을 유추해볼 예정이다.

---

참고

https://junibugi.tistory.com/entry/%EC%9D%B4%EC%BB%A4%EB%A8%B8%EC%8A%A4e-commerce-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8%EC%9D%98-%EC%A3%BC%EB%AC%B8-%EA%B4%80%EB%A6%ACOMS-%EC%97%85%EB%AC%B4-%EA%B0%9C%EC%9D%B8%EC%A0%81%EC%9D%B8-%EC%A0%95%EB%A6%AC


https://yozm.wishket.com/magazine/detail/1660/

내 서비스에는 어떤 인증이 필요할까? | 요즘IT

https://hyeyun133.tistory.com/m/7

01. 회원 데이터 설계

이커머스(e-commerce) 프로젝트의 주문 관리(OMS) 업무 개인적인 정리..