상품 정보 관리 라이브사이클 정의

커머스 혹은 유통 도메인 설계에 대한 연작 (지난 글)

1편. 커머스 혹은 유통 도메인 설계에 대한 연작

오랫동안 추적한 일이다. 생각으로는 금방 정리할 수 있는 내용이지만, 실제로 구현할 수 있도록 정의하는 일은 그와는 다른 일^[4]이다. 여튼 또 기회가 왔다. 시작은 한 개발자가 엑셀 업로드 기능을 만들었는데, 동료 기획자가 마음에 들지 않는다고 했다. 아이디어를 구하기에 당장 목표로 삼을만한 범위를 그림으로 그렸다.

단기간 구현할 수 있는 상품 관리 라이프사이클 제시

일단 CRUD!!?

그랬더니 기획자가 기획 범위를 아래와 같이 요약했다.

• 상품등록(갱신)
• 재고등록(갱신)
• 가격등록(갱신)

잘못했다고 할 수는 없지만, 정보를 관리하는 업의 입장에서 의미가 훼손될 우려가 느껴졌다. 그래서, 필자가 피드백을 주면서 이 글을 쓰기 시작한다.

정보에 층을 두기

그럼 어떻게 하느냐? 일단 후보로 생각나는대로 써보자.

• 어떤 상품을 팔 것인지 정보 기록
• 특정 기간 혹은 시점 이후에 가격을 바꾸고 싶은 내용을 반영
• 특정 시점 기준으로 재고 현황을 갱신

일단, 이정도로 쓰고 함께 자라기^[1] 위해서 기획자에게 피드백^[2]을 준다.

두레이를 이용한 기획 내용 소통

CRUD의 함정

아래는 기획자의 대답 중 일부를 발췌한 것이다. 복잡한 업무 규칙을 생략하고 독자들에게 얘기하고 싶은 부분은 CRUD 틀로 바라 보면 상품 정보의 층위가 사라져버렸다는 점이다. 필자의 피드백에서 분명 상품, 재고와 가격이라는 세 가지 정보층을 제시했는데 동료 기획자는 전체 상품 정보를 한 통으로 보는 관점을 유지하며 CRUD를 유지했다.

• Create: 신규 상품 등록
  • 'Excel Upload Template' 를 제공해야 한다.
  • 중복, 변경, 신규 데이터에 대한 반영
    • 중복 데이터는 제외하고,
    • 변경된 데이터는 반영하고,
    • 신규 데이터는 추가한다
• Read: 이미 등록되어 있는 상품 확인
• Update: 이미 등록되어 있는 상품 정보 변경
  • 정보 변경 이력은 별도 관리해야 한다.
    • 'Excel Upload'를 통한 변경 데이터 이력 관리할 수 있는가?
  • 정보 변경도 'Excel Upload' 를 통해 이루어지는가?
  • 시스템의 UI를 통해서 상품 정보를 수정할 수 있는가?
  • 시스템의 UI를 통한 정보 변경 시, 상품의 최신 정보 'Excel Download' 기능이 필요하다.
    • 최신 상품 정보 데이터를 어떻게 유지할 수 있는가?
• Delete: 이미 등록되어 있는 상품 삭제 또는 미사용
  • 상품 삭제가 의미하는 것은?
  • 주문 또는 장바구니에 사용된 상품 데이터는 삭제해서는 안 된다.
  • 지금 상품 구조는 판매 가격의 변경에 따라 상품코드 및 SKU코드가 삭제될 수 도 있는데 어떻게 생각하는가?
    • Product(가격: List Price, Sale Price)
      • SKU(데이터는 SKU를 기준으로 가격이 다른데, 현재 가격은 Product에 종속되어 있다.)

필자는 이러한 습성이 엑셀 레코드 한 줄을 그대로 받아들여 형태 위주로 데이터를 취급하는 사고에 기인한다고 믿는다. 행위의 업무적 의미가 사라지고 단순히 데이터 CRUD로 치환하는 순간 벌어지는 식이다. 이 방법의 단점은 무얼까?

어떤 업무든지 복잡한 SQL 속에 녹여 버린다는 점이다. 그렇게 되면 조직에서 함께 일한다고 해도 실제로는 해당 개발자가 외롭게 그 행위 구현에 대해 책임을 지는 단절이 발생한다.

함께 자라기

위의 피드백과 함께 필자는 아래 그림을 기획자에게 던졌다. 앞서 인용한 내용과 달리^[3] 실제로 동료 기획자는 필자가 제시한 상품 정보 계층에 입각해 고려할 항목을 왕창 기록했다. 그리고 우리는 시너지를 낼 수 있었다. 계층화 하여 '양산을 전제로 한 설계를 해야겠다'는 필자의 욕구와 오류없이 정교하게 비즈니스 규칙을 정의하려는 기획자의 욕구를 절충해서 시스템도 조직도 우리들 각자도 함께 자란다.

상품 정보의 계층화 시도

결과는 더 가봐야 해서 아직 모르겠다.

그리고...

삶은 이어지고, 또 단편적으로 나눠지지는 않는다. 이 글을 쓸 즈음에 데이터 분석을 하던 북경잠자리님이 스트림 이야기를 하는데... 관련이 있어 보여 관련한 담소를 나누고 자리에 오니 이번에는 관련 기능을 개발하는 또 다른 동료가 개발 방법에 대한 자기 아이디어를 쓰고 의견을 물었다. 그래서 아래와 같이 답하면서, 어쩌면 이 글의 후속 이야기가 펼쳐질 수 있겠구나 싶었다.

단계적 개발 방식에 대한 소통

주석

[1] 최근에 구매한 김창준님의 책 이름인데, 너무 마음에 들어서 책도 읽기 전에 인용한다. 더불어 책을 두권 구매하여 한권은 동료 기획자에게 주었다. 읽으려나?

[2] 필자 업무 환경에서 이러한 피드백은 두레이라는 툴을 이용한다.

[3] 이 글에서 윗 부분만 인용하는 이유는 단지 CRUD의 함정을 설명하기 위해서다.

[4] 현실의 벽을 만나 수정해야 하기도 하고, 협업을 위해 다른 사람과 맞춰가야 한다.