장바구니, 구매요청, 구매내역

개발자들에게 중요한 것은 기술 스택이다. 하지만, 무조건 기술 스택만 중요한 건 아니다. 커머스에서 일한 개발자라면, 다음 직장 역시 커머스일 때, 당장의 기술 스택이 다르더라도 일단 와서 배우라고 말할 수 있다. 기술 스택 말고도 분야에 대한 이해도가 있는지, 시리즈 ( 투자 라운드 ) 에 따라 자신이 수행해야 할 역할을 이해하고 있는지, 창업가 정신을 가지고 있는지, 조직을 리드해본 경험이나 인간관계에 대해 깊이 고찰해본 경험이 있는지도 고려할 부분이다.

 

똑같은 기술 스택을 가진 사람이라고 하더라도, 커머스 개발자는 커머스 개발자고, 게임 서버 개발자는 게임 서버 개발자가 될 것이다. 또 제너럴리스트가 있다면 스폐셜리스트가 있을 것이고, 경력이 쌓여가면서 기술 스택으로 구분되는 일이 점차 적어질 것이다. 그러니 더 이상 자신을 호칭할 때, 개발자 라는 단어 앞에 어떤 기술이 붙지 않게 조심해야 한다.

 

아래는 커머스에서 볼 수 있는 구조 일부분이다. 

 

장바구니의 구조

장바구니에 상품을 담는다. 장바구니에 담긴 상품은, 브랜드 별로 묶인다. 그래서 구조 상, 장바구니, 브랜드 묶음, 상품의 하위 구조를 가지게 된다. 상품은 다시 상품 옵션을 가진다. 상품 옵션은 두 종류로, 하나는 필수 옵션이고, 다른 하나는 선택 옵션이다. 여기까지는, 각각의 primary key를 참조해야 한다. 상품의 값, 또는 상품 옵션의 값은 시시각각 바뀌고, 배송비 역시 마찬가지다. 변동이 있을 때, 미리 장바구니에 담긴 상품이라고 하더라도 값이 추적될 수 있어야 한다.

 

여담으로, 장바구니의 상품이 생성된 후, 삭제될 때까지 ( 결제로 넘어가는 시점을 삭제라고 한다면 ) 의 시간을 보면, 그 물건을 사용자가 얼마나 고심했는지를 알 수 있다. 장바구니를, 일종의 즐겨찾기나 찜목록처럼 활용하는 고객들이 있기 마련이다.

구매요청의 구조

구매 요청이 있을 수도 있다. 품의를 올려야 하는 기업 구조 상, 구매 요청이 있을 수 있다. 여기도 각각의 데이터에, primary key를 참조한다. 구매 요청 단계에서도 결제할 대금이 바뀔 수 있기 때문이다. 다만, 요청서를 올릴 당시의 금액이 변동된다면, 그 여부를 체크해주는 정도가 있으면 좋겠다. 회사에서는 각 개인에게 할당된 예산이 있어, 그 예산 내에서 비품을 구매해야 할 수도 있기 때문이다. 이런 것은 각 회사마다 다른 부분이니, 그저 있으면 좋다는 정도면 된다. 재밌는 점은, 후술하겠지만, 구매 요청과 구매 내역 역시 장바구니와 동일한 구조라는 점이다. 그래서 entity를 설계할 때 최대한 동일한 파라미터 이름을 가지게끔 만들 필요가 있다. 이렇게 설계할 경우, 세 데이터의 객체를 전개 연산자만 가지고도 쉽게, 다른 객체로 변경할 수 있게 된다.

구매 요청의 경우, 담당자에 의해 거절될 수 있고, 일부분만 반려될 수도 있다.

 

구매내역의 구조

구매 내역은 실제로 결제가 이루어진 구간이다. 여기서부터는 값이 변동되더라도, 값 변동 이전에 결제한 것이기 때문에 값이 바뀌어서는 안 된다. 그래서 id를 참조할지라도, 물건의 금액을 따로 저장해둘 필요가 생긴다. 구매 내역에서는 이제, 취소나 반품, 환불, 배송 상태 등 구매 내역을 설명하기 위한 온갖 relation들이 추가된다. 이를 relation들에 join한 객체가, 실제로 그 값을 가지는지를 가지고서 구매 내역의 상태를 표현할 수 있다. 장바구니는 구매 후에 삭제해도 되는, 휘발성 데이터에 가깝다. 하지만 구매 내역은 결코 삭제해서는 안 된다. 이 데이터들은 일종의 log 역할로, 사용자들이 언제든 조회할 수 있다.

 

구매 내역은 삭제된 데이터와 연관 관계를 가질 경우, 삭제되었다고 하더라도 그 데이터를 불러올 수 있게 해야 한다. 가령, 상품이 더 이상 판매되지 않는다고 하더라도, 구매 내역을 조회할 때에는 DB 상에서 가져와 줘야 한다. 현재 판매하지 않는 상품이라고 해도, 과거의 기록까지 사라진 것은 아니기 때문이다. 구매 기록은 엄연히 고객의 개인 정보다.