2-1. 1단계: MVP 기능 다시 정의하기

먼저, "지금 당장 살아남기 위해 필요한 최소 기능"만 추려서 1차 오픈 스펙(MVP) 을 정의한다.

논의 결과, 다음과 같은 결론에 도달한다고 가정한다.

• 외부 판매자 기능:
  • 지금 당장은 사용하지 않는다.
  • 외부 판매자를 모집하려면 사업 전략, 홍보, 영업 준비 등 시간이 많이 든다.
  • 쇼핑몰이 안정적으로 자리 잡은 이후, 빠르면 1~2년 뒤에 진행하기로 한다.
• 쿠폰, 리뷰, 복잡한 카테고리:
  • 있으면 좋지만, 없어도 주문 자체는 가능하다.
  • 2차, 3차 고도화 기능으로 미룬다.
• 장바구니 기능:
  • 사용자 경험에서 매우 중요하다.
  • 다만, 초기에 한정된 자원으로 DB 설계에 꼭 넣어야 하는지는 별도 고민이 필요하다.
  • 예를 들어 1차에서는 클라이언트(브라우저)나 애플리케이션 메모리에만 장바구니를 저장하도록 구현하고, DB 반영은 후속 단계로 미룰 수도 있다.

이렇게 과감한 선택과 집중 끝에, 다음과 같은 MVP 기능 명세서로 압축한다.

[쇼핑몰 MVP 기능 명세서]
1. 회원: 고객이 가입하고 자신의 정보를 관리할 수 있어야 한다.
2. 상품: 우리가 판매할 상품을 등록하고 관리할 수 있어야 한다.
3. 주문: 회원이 상품을 구매할 수 있어야 한다.
4. 결제: 주문에 대한 결제 정보를 기록하고 관리할 수 있어야 한다.
5. 배송: 결제가 완료된 주문의 배송 상태를 관리할 수 있어야 한다.

이 정도만 해도 온라인 쇼핑몰의 최소 기능은 충족할 수 있다. 이제 이 기능 명세를 기반으로 개념적 모델링을 시작한다.

2-2. 2단계: 핵심 엔티티 도출

MVP 요구 사항에서 데이터의 뼈대가 되는 엔티티를 뽑는다. 자연스럽게 다음과 같은 엔티티들이 떠오른다.

• 회원(Member) : 서비스를 사용하는 고객
• 상품(Product) : 판매의 대상이 되는 물건
• 주문(Order) : 회원의 구매 행위 결과
• 결제(Payment) : 주문에 대한 지불 정보
• 배송(Delivery) : 주문된 상품의 물리적 이동 정보

정리하면, 핵심 엔티티는 다음 다섯 개가 된다.

회원(Member)
상품(Product)
주문(Order)
결제(Payment)
배송(Delivery)

여기서 특히 중요한 점은 주문과 배송을 분리했다는 것이다.

• 주문은 비즈니스 트랜잭션의 단위이다. (무엇을, 언제, 얼마에 샀는가)