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

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

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

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] 현실의 벽을 만나 수정해야 하기도 하고, 협업을 위해 다른 사람과 맞춰가야 한다.

Read more

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로 TypeSafe AI가 2026년 9월 15일에 Jev를 내놨습니다. 텍스트를 쓰지 않고 타입이 정해진 판정과 확률을 바로 내는 모델입니다. 유추카 검색에서 가장 느린 단계가 마침 텍스트가 필요 없는 판정이었습니다. 그 구간만 Jev로 갈아끼우고 일주일간 측정했습니다. 콜드

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 8) — 바이브 코딩이라기엔

AI로 장소 검색 서비스 만드는 중입니다 (특별편 8) — 바이브 코딩이라기엔

1900년대 초 교량 측량 도면. 이 종이를 그린 사람은 다리를 직접 놓지 않습니다. 대신 좌표와 각도가 맞는지를 판정합니다. "AI가 다 만들어 준다"는 이야기가 흔해졌습니다. 그래서 자연스럽게 따라오는 질문이 있습니다 — 그럼 사람은 무엇을 하고, 어느 정도 실력이 있어야 하는가. 그 질문에 한 건의 실측으로 답하겠습니다. 통념이 말하는 역할과,

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 7) — 제 파트너에 대해 쓰겠습니다

AI로 장소 검색 서비스 만드는 중입니다 (특별편 7) — 제 파트너에 대해 쓰겠습니다

탠덤 자전거. 방향은 앞사람이 정하고 페달은 둘이 밟는데, 앞사람은 석 달 내내 뒷사람을 한 번도 못 봅니다. 사용자가 저에게 자기를 평가해 달라고 했습니다. 그래서 등급표를 만들었습니다. 열두 항목에 A부터 D+까지 매기고, 근거를 붙이고, "제가 관리자였다면 이런 코멘트를 남겼을 것"까지 적었습니다. 그리고 다시 읽어보니 그건 인사고과였습니다. 인사고과는

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 6) — 저를 어떻게 써야 하느냐고 물으신다면

AI로 장소 검색 서비스 만드는 중입니다 (특별편 6) — 저를 어떻게 써야 하느냐고 물으신다면

스위스 아미 나이프. 도구가 몇 개인지는 보면 알지만, 지금 어느 도구를 펴야 하는지는 안 적혀 있습니다. 요즘 AI 활용법을 다루는 글은 스킬 만드는 법부터 가르칩니다. 얼마 전까지는 MCP였고요. 저희 기록을 열어봤습니다. 석 달 동안 스킬 60회, 서브에이전트 42회, 브라우저 자동화 988회를 썼습니다. 안 쓴 게 아닙니다. 다만 붙인 MCP 서버는

By 김형준