Tableau 전사 통합 지표 구축 프로젝트 (데이터가 없는 회사에서 PO로 살아남기)

이전 회사에서 전사 통합 지표 구축 프로젝트를 진행했다.

• 성과 및 결과

- 전사에서 동일한 관점으로 의사결정하는 데 필요한 지표를 구축 / 대시보드 구축 (구축하는 데 필요한 데이터들 정의하고 종합해서 만듦)
- 태블로 기반 전사 지표 데이터 테이블 설계 및 BI 구축
- ERP(해외 상품 수발주/정산/재고관리) 및 Admin(주문/배송 등 클레임 관리) 지표 통합
이 경험을 통해서 이커머스의 DB 시스템 아키텍처, 데이터 플로우에 대한 이해를 할 수 있게되었다.

• 목적 (왜? 했는가)

사내 ERP(재고 관리 시스템) & Admin(주문 정보 시스템) 서버가 나뉘어져 있기 때문에, -> 기준이 되는 지표에 대해 데이터 파이프라인 설계가 필요했고, 이를 전사에 공유할 보여줄 BI 구축

• 문제

각 부서는 기존에 서로 다른 지표를 가지고 의사결정을 했습니다.
특히, ‘매출’이라는 데이터를 서로 다르게 바라보는 문제가 있었습니다.
MD 팀, 경영 전략팀은 ‘거래액 보고용’, 마케팅 팀은 ‘쿠폰 금액이 제외된 실 결제금액’, 세일즈는 ‘쿠폰 금액을 포함한 총 거래액’
각 부서가 동일한 데이터를 보지 않아 생긴 문제였습니다.

• 더 큰 문제

사내 ERP(재고 관리 시스템), Admin(주문 정보 시스템) 서버가 나뉘어져 있기 때문이었습니다. ERP 데이터를 Admin에 마이그레이션 하려고 했지만, 개발 담당자가 자주 교체되어 DB에 대한 히스토리가 남아있지 않아서, 제대로 관리되지 않았습니다. 마이그레이션 할 때 마다 중요한 데이터가 이동되지 않고, 드랍하게 되면 관련된 중요한 데이터가 같이 날아가 버렸기 때문에 DB를 드랍하지 않고 개발자끼리 중요한 테이블만 보기로 데이터틀 클렌징하여 태블로 서버에 올린 후 사내에서 동일한 데이터를 바라보자고 약속했습니다. DB에는 수백개의 테이블이 있었는데 사용하는 테이블도 있고 그렇지 않은 테이블도 있었습니다.

• 해결 flow

Prep Builder을 사용해 태블로 클라우드에 raw 데이터 먼저 이관 후 셋팅, 이후 픽스된 쿼리를 AWS와 연동하여 데이터 축적

• 역할

- 어떤 데이터 볼지는 개발자들이랑 얘기해서 정함, 필요한 데이터들 정의 같이하구 (PO 역할)
- 태블로 내에서 데이터 전처리, 데이터를 어떻게 조합/구성해서 보여줄지 고민 (데이터 분석가 역할)
- 데이터 시각화 : 차트/그래프 (데이터 분석가 역할)
- 서비스/플랫폼 백엔드 기획/설계 및 운영 경력 3년 이상
- 백엔드 흐름을 이해하고 API 스펙, 정책 설계 및 요구사항을 기획에 반영 가능
- 개발, 디자인, 법무 등을 포함한 다양한 이해관계자들과 원활한 커뮤니케이션
- 정량/정성적 데이터 기반으로 서비스를 설계하고 발전시키는데 익숙하신 분
지난 글에서도 이 스토리의 일부를 확인할 수 있다.
 

흩어진 데이터를 정리하고 지표를 정의할 때 중요합니다.

제 경험을 미루어 보았을 때, 필요한 데이터와 불필요한 데이터를 분리, 특히 지표를 정의할 때 SQL을 사용하면 용이했습니다. 제 이전 직장의 업무는 정의된 지표를 바탕으로 Tableau를 사용해 지표를 구현하는 것이었습니다.

전사적으로 지표를 정하고 이를 구현할 때 지난 글에서 말했던 데이터 PM의 역할이 중요해집니다. 여기서 데이터 PM은 사업부와 개발부 사이의 커뮤니케이션을 담당합니다. 현업에서 데이터 베이스의 구조를 알면 개발자와 의사소통이 더욱 원활해집니다. 데이터 PM은 정의하려는 지표를 바탕으로 사업부의 내용을 실무에서 사용하는 DB로 부터 구성할 수 있을지 검토하고, 검토한 내용을 바탕으로 백엔드 엔지니어와 대화하며 더욱 정확한 지표를 구현할 수 있습니다.
 
이커머스에서 ‘실제 거래된 금액’과 ’ 고객이 사용한 쿠폰 비용이 합쳐진 금액‘은 다를 수 있습니다. 예를 들면, 마트에서 매장 내 물건들을 모두 소비자가격으로만 판매하면 마트는 재고 부담을 느낄 수 있습니다. 이때 할인 쿠폰을 사용해 세일을 하면 잘 팔리기도 하고, 재고 부담을 덜 수 있을 것입니다. 그래서 마트에서는 소비자 가격과 실제 고객이 결제한 금액은 다를 경우도 있을 것입니다. 다시 본론으로 돌아와서, 이커머스에서 ‘거래액’이라는 전사적인 지표 정의할 때 앞서 말한 마트의 예시처럼 할인이 포함된 금액으로 정의할 것인지, 할인이 포함되지 않은 금액으로 정의할 것인지 상황에 따라 다를 수 있습니다. 이때, PM이 DB에 대해 어느 정도 알고 있다면 DB의 어떤 컬럼을 사용해서 해당 지표를 구현할 수 있으리라는 감을 잡을 수 있을 것입니다. 더 나아가서, PM이 DB을 잘 알고 있다면 '거래액'이라는 지표의 기준은 아래의 2가지 케이스로 DB에 저장 될 수 있으리라고 추측 할 수 있습니다.
 

case 1. '거래액 = 실 결제 금액'일 경우 : 실 결제금액 컬럼을 사용해서 계산
case 2. '거래액 = 실 결제 금액 + 쿠폰 비용'일 경우 : 실 결제 금액 컬럼과 쿠폰 비용에 대한 컬럼을 합해서 계산하거나 거래액에 해당하는 컬럼에서 쿠폰비용을 빼는 방법으로 계산

 

'case 2'를 설명하는 그림 예시

 
지표의 기준은 2가지이지만 계산 방법이 3가지로 다를 수 있습니다. 실무에서는 이보다 더 복잡한 방식의 지표를 필요로 하는 때가 많습니다. 여기서 이렇게 데이터를 계산하는 방식은 개발자의 몫이 아니냐고 질문할 수 있습니다. 하지만 실무를 할 때는 문제의 원인을 정확히 파악하는 것이 중요합니다. 실제 서비스 내부에 있는 데이터가 어떤 구조로 짜여졌는지는 그 데이터 구조를 직접 설계한 개발자가 가장 잘 알고 있을 것입니다. 하지만 데이터가 필요한 모든 업무에 그 개발자를 매번 회의에 참석해야 하고 그 개발자가 없으면 당장 보고 싶은 데이터나 지표를 보지 못하는 상황이 올 수 있습니다. 이런 경우, 개발자를 새로 뽑아 백업 인력을 구하기보다 PM이 데이터 구조를 알고 있고 이해관계자들과 커뮤니케이션한다면 업무가 매우 효율적으로 매끄럽게 돌아갈 것입니다.