이커머스 도메인을 설계하면서 나는 어떤 고민을 했을까

이커머스 도메인을 설계하면서 요구사항 문서, 유스케이스, 다이어 그램, erd 부분은 AI가 만들어 주면서 개발하기가 상당히 쉬워진 것을 느끼고 있다.

 

하지만 AI는 시키는 대로 만들어 줄 뿐 결국 고민해서 결과를 내는 건 개발자의 몫이다.

여기서 AI와 설계를 같이 하면서 고민한 내용을 작성하고자 한다. 

이커먼스 트레이드 오프 챗 GPT 생성형 이미지

 

상품 삭제는 소프트 삭제인가 하드 삭제인가

소프트 삭제는 디비 이력이 남기 때문에 잘못된 데이터 추적이 가능하고 필요시 데이터를 복구할 수 있다는 점이 장점이다. 이러한 이유로 처음에는 소프트 삭제가 하드 삭제보다 좋은 선택으로 보이지만, 데이터가 계속 존재하기 때문에 삭제된 인덱스도 계속 남아 있게 된다. 이로 인해 1000만 건의 데이터 중에 900만 건이 삭제 데이터라고 한다면 옵티마이저가 Full Table Scan을 선택하여 슬로우 쿼리로 이어질 가능성이 있다.

 

하드 삭제는 디비 데이터를 완전 삭제하는 방식으로 감사 추적이 어려우며 실제 인덱스 구조에 영향과 연관된 FK 데이터들을 다 삭제해줘야 하기 때문에 소프트 삭제에 비해 비용이 더 크다. 하지만 삭제함과 동시에 공간확보를 할 수 있는 장점이 존재한다. 

 

사실 운영을 한다고 가정한다면 대부분은 소프트 삭제를 더 우선으로 선택할 것이다. 나는 시스템의 안정성과 복구 가능성을 고려해서 판매 중지라는 삭제를 대신할 비즈니스 상태를 두었고 이후 데이터가 충분이 누적돼서 슬로우 쿼리를 유발한다면 일정 기간이 지난 판매 중지 데이터는 일괄 삭제할 수 있도록 보완 정책을 정하면 양쪽 장점을 같이 가져갈 수 있을 것 같다. 

상품 수량과 가격은 상품 도메인에서 제외하고 별도로 둘 것인가

 

사실 처음 설계에선 간단하게 설계해 보자는 입장이었지만 사실 이건 별도로 빼는 것이 맞는 거 같다. 왜 별도로 둬야 할까 내가 판단한 이유는 다음과 같다.

동시성 문제와 재고 데이터의 특성 

 

재고는 주문이 발생할 때마다 변경되는 데이터로, 동일 상품에 대한 동시 주문이 발생할 경우 재고 차감 과정에서 락 경합이 발생할 수 있다. 또한 상품 정보는 조회가 주를 이루는 반면 재고 정보는 빈번한 쓰기 작업이 발생하는 데이터이므로 두 데이터의 접근 패턴이 다르다.

따라서 조회 중심의 상품 정보와 쓰기 중심의 재고 정보를 분리하여 각각의 특성에 맞게 관리하는 것이 적절하다고 판단하였다.

재고 관리의 확장성

 

대부분의 상품은 하나의 창고에서 재고를 관리하지만, 서비스가 확장되면 여러 창고에서 재고를 관리해야 하는 상황이 발생할 수 있다. 하지만 초기 단계부터 다중 창고 구조를 과하게 반영하는 것은 오버엔지니어링으로 보인다. 

현재 요구사항에 맞는 단순한 구조를 우선 가져가되 이후 창고가 추가되더라도 확장 가능한 형태로 설계하는 것이 더 적절하다고 판단했다. 

상품 옵션 확장성 

 

이커머스를 간단하게 설계를 하려고 해도 현실에서 무신사나 쿠팡 같은 쇼핑몰을 이용한다면 이 요구사항을 설계에 넣을지 고민이 되는 부분인 것  같다. 나의 판단 기준은 같은 상품에서 상품 옵션을 추가해도 동일 상품이고 가격이 변동된다고 해도 재고 테이블에 가격을 넣게 되면 옵션이 새로 생기는 경우도 적절하게 대비할 수 있을 것 같다. 

재고 수량 테이블 별도 분리

 

 

테이블 분리로 인해 기능 확장이나 조회 부분에서 많은 이점을 가져갈 수 있을 거 같다. 

상품 주문에서 결제는 언제 진행되어야 할까 

주문할 때 재고 차감도 동시성 문제를 고려해야 하는데 어떻게 하면 사용자 경험과 운영 안정성을 동시에 가져갈 수 있을지가 가장 큰 고민이었다. 또한 결제를 넣는다고 한다면 외부 API를 호출하는 상황에서 이커머스 디비와 정합성을 어떻게 하면 최선으로 맞출 수 있을까 

결제 결과에 따른 설계 

 

결제가 앞에 먼저 이루어지고 주문요청을 하며 재고를 차감하는 로직이라면 결제 이후에 재고 문제를 해결해야 한다. 동일 상품을 구매하는 유저가 재고가 1개인데 2명이 동시에 결제 진행을 한다면 한 명만이 결제가 성공한 후에 주문이 정상적으로 완료될 것이다. 다른 유저는 결제가 성공했음에도 주문을 하지 못하는 상황이 생기고 재고가 부족하다면 환불을 즉시 해주는 보상 트랜잭션 구조가 나와야 한다.

 

선 결제 구조 생성형 AI 이미지

 

결국 재고를 결제 후에 뒤에서 차감하는 경우는 사용자 경험에 맞지 않게 된다. 

 

그러면 앞에서 주문을 예약하듯이 하고 재고를 차감하는 것은 적절한지를 판단해야 한다. 먼저 동시에 주문을 한다고 한다면 재고 경합이 발생하게 되고 한 명만이 주문을 완료할 수 있다. 이러면 어느 정도 해결된 게 보이지만 주문만 하고 결제를 하지 않는다면 요청 상태의 데이터만 남아있게 되고 재고만 차감된 상태로 변한다.

주문은 예약하는 구조로, 결제는 정해진 시간 내에 진행

 

나는 전자의 보상 트랜잭션 로직까지 고려한다면 후자를 선택하는 쪽이 나은 선택이라고 판단했다. 

그러면 재고만 차감되고 결제가 이루어지지 않은 상황을 어떻게 해결할까 고민을 하게 되는데 이 문제를 해결하기 위해 적절한 결제 시간을 두는 것을 선택했다.

 

15분 동안 주문이 유효하고 그 시간 내에 결제를 진행해야 정상 주문이 되는 구조로 선택했고 이렇게 된다면 주기적인 배치 스케줄러가 필요할 것이다.  

주문 흐름도

문제가 없을까 

 

결제가 실패할 경우 재고를 원복 하면 만약 시스템 에러로 인해 결제 시도한 대상도 재고가 원복이 되며 주문이 실패하게 되고 잔액이 없어 실패하는 경우에도 재고를 돌려줘야 하는 상황이 발생한다.

 

만약 BTS 콘서트 같은 인기 많은 티켓팅 문제라면 결제 실패 시 사용자의 불만이 커지게 될 것이다.  

 

결제는 실패할 수 있다 생각하자

 

내가 생각한 방법은 주문 요청 상태에선 결제 시도에 제한을 두지 않는 것 입니다.

결제를 실패해도 재시도할 수 있게 주문 상태를 변경하지 않고 결제 실패 이력만 관리하면 사용자 경험을 최대한 갖추고 운영 안정성을 높일 수 있다 생각하여 1:N의 관계를 가지게 설계를 진행했다. 

 

주문과 결제 1:N 관계

 

AI가 다이어그램과 코드, 설계 초안을 빠르게 만들어주는 시대가 되었지만, 실제 설계의 차별점은 결국 개발자의 판단에서 나온다는 것을 알게 되었다.