PO는 꼭 데이터 분석을 잘 해야 할까

• 이 글은 2017년 12월에 작성되었습니다.

3년 전 국내 모 대기업을 그만두고 한창 떠오르던 이커머스 업체 C사에 Product owner라는 직무로 일을 시작했을 때, 그 방대한 고객(user)/상품(C사가 판매하는 상품)/제품(우리가 개발/서비스하는 제품) 관련 데이터은 나에게 신세계였다. 비록 그 전 회사가 글로벌 스마트폰 제조사였지만 직원들이 접근할 수 있는 데이터는 굉장히 제한적이었다. 시스템적으로 다른 부서(개발팀)의 데이터에 접근을 해서 분석을 한다는 건 상상도 해본 적 없고, 아마 인프라적으로도 불가능했을 것이다.

하지만 시스템적인 이유보다는 1) Android라는 타사 OS를 기반으로 스마트폰을 제조/판매하는 한계, 2) 판매 물량 대부분 B2B(통신사나 도매/소매 업체)로 제품을 판매하다보니 시장분석 및 이를 base로 한 제품 기획에 필요한 ‘고객’ 데이터가 없었다는 게 더 큰 이유일 것 같다. 당시 주로 하던 데이터 분석은 모 시장조사 업체에서 주기적으로 받은 글로벌 휴대폰 판매 raw 데이터를 기반으로 지역/국가별로 가격대별 제조사별 Market share를 확인하거나, 모델별 판매량을 기반으로 자사 모델의 경쟁력을 평가하고 타사 주력모델을 대비하기 위한 분석들이었다. 분석을 위한 도구는 거의 Microsoft Excel 이었다. 이미 3~6년 전 일이지만, 워낙 다양한 신제품이 출시되고 환경이 빨리 바뀌는 산업이기에 당시 ‘제품 경쟁력’을 고민하면서 실시간 데이터에 대해 목 말라했던 기억이 있다. (대부분 시장조사 데이터나 리서치들은 몇 달 지난 데이터들이었다)

이직 후 C사에서의 환경은 전혀 달랐다. 직접 회사 데이터베이스에 접근해 SQL query로 데이터를 추출/가공/분석하거나, 고객 이슈를 실시간으로 데이터를 확인해서 대응하던 모습은 완전히 새로운 환경이었다. Web base로 사업을 하는 회사라면 당연할 수 있겠지만, 8년 동안 제조사에서만 일하다 온 나에게는 신세계였다. 그렇지만 항상 좋을 순 없는 법. 향상된 데이터에 대한 접근성이 또 다른 고민을 가져오기도 했다. 오늘은 이 글을 통해 아래 몇 가지 주제에 대한 내 생각을 적어보자 한다.

1. 업무 환경에서 향상된 데이터의 접근성이 가져오는 긍정적인 / 부정적인 부분
2. Product owner가 데이터 분석을 어느 정도까지 해야 할까?
3. 데이터 과학이란 또 다른 세계에 대해

무한한 데이터. 어떤 가치를 찾을 수 있을까? 무작정 좋을 뿐인가?

더 많은 고객 프로필/행동 데이터를 접할 수 있고, 이에 따라 내가 모르던 세계가 펼쳐진 것은 분명했다. 무한한 가능성인 것 같았다. 하지만 데이터베이스 여기저기 돌아다니며 데이터 까보는 것도 잠깐일 뿐, 너무 많은 데이터에 실시간으로 접근할 수 있다보니, 이에 따라 부작용이 생기기도 했다. 향상된 데이터 접근성이 가져온 긍정적인 부분과 부정적인 부분을 개인적인 경험을 토대로 적어보겠다. 기술적/사업적인 기준보다는 Product owner인 내 개인적인 기준이다.

긍정적인 결과

1. 고객의 데이터(개인정보 말고 행동 패턴)를 실시간으로 확인할 수 있기에 사용자들이 내가 기획/개발한 제품을 내가 의도한 대로 사용하고 있는지 바로 확인할 수 있다. 그리고 여기서 배운 것을 통해 제품을 지속 개선할 수 있다. 이직 후 내가 가장 만족해했던 부분이다.
2. 뻔한 얘기지만, 이 방대한 데이터 속에서 Insight를 찾거나 미래 트렌드를 prediction 할 수 있다(고 믿는다)
3. 위 1번의 연장선일 수 있지만, 내가 기여한 제품의 performance를 쉽게 확인할 수 있다는 부분은 나중에 인사 ‘평가’ 프로세스를 조금은 더 수월하게 할 수 있지 않을까 한다. 적어도 ‘우리 부장님 잘 모셔서’ 고과 잘 받는 모습은 피할 수 있고, (다른 팀/팀원들도 데이터를 확인 할 수 있기 때문에) 성과에 대해 조금은 더 투명해질 수 있다고 생각한다.

부정적인 영향

1. 데이터가 의사결정의 기반이 되는 것은 좋으나, 간혹가다 데이터를 핑계로 의사결정을 미루는 경우가 생긴다. 의사결정을 해야 하는데, 어느 쪽도 뚜렷하지 않은 경우 ‘이 부분 더 데이터를 파보자’라고 하는 경우가 간혹 있다. 나도 안 해본 것 아니다. 하지만 impact가 클 데이터 분석이 아닐 경우, 일단 결정을 하고 테스트를 빨리 해서 결과를 빨리 확인해보는 게 나을 수 있다.
2. 데이터 분석을 하다보면 궁금증에 궁금증이 꼬리를 물어 너무 디테일한 부분까지 내려가는 경우도 있다. 위 1번과 비슷한 얘기일수도 있으나, 만약 제품이나 팀의 direction을 결정하기 위한 데이터 분석이 너무 디테일한 부분까지 touch하려다 보면 ‘디테일에서 길을 잃는 경우’를 만날 수 있다. 큰 트렌드를 통해 방향을 잡고, 세부적인 내용은 개발팀과 함께 하나하나 파악해 나가면 되는데, ‘데이터 분석을 위한 분석’이 되어 버리게 되면 본래의 의도(전략 방향 설정을 위한 트렌드 분석)가 distort된다. 이 역시 내 경험에서 나온 의견이다. (쓰다보니 자괴감이....)
3. 고객님들이 사용하는 제품/서비스의 경우 ‘실시간 대응’이 가능하다는 장점이 있지만, ‘내 일이 5시에 안 끝날 수 있다’는 부정적인 부분도 있다. 이것은 회사 업무문화와도 밀접한 관계가 있겠지만, 고객 이슈가 급히 생길 경우 밤에 노트북 열어서 데이터 확인해보게 되는 경우도 종종 생긴다. 이것은 사실 부정적인 부분이라기 보단 비즈니스 성격과 팀/Role에 따라 다를 수 있는 부분이지만 한 가지 확실한 건 집에까지 와서 일하던 내 모습을 내 아내는 싫어했다.

다른 글에서 다뤘다시피 PO(Product Owner)는 Web 기반 서비스를 직접 개발하여 운영하는 IT 업체에 있는 Role이다. 이에 PO와 데이터는 뗄레야 뗄 수 없는 관계이다. 이에 PO가 데이터를 파보는 것은 어찌보면 문제점 파악 및 의사결정을 위해 당연히 해야 할 일이나, 너무 데이터에 몰입하다보면 정작 PO가 해야 할 중요한 일을 간과하거나 더 나아가 나무에 빠져 숲을 못보는 경우가 생길 수도 있다.

Product owner(혹은 Product manager)는 어느 정도까지 데이터 분석을 해야 할까?

당연하겠지만 "잘 하면 잘 할수록 좋다”. 본인의 Product을 전담할 데이터 분석 담당자가 없는 경우(대부분이 그럴 것 같다), 외부 분석 담당팀이나 개발팀 내 Back-end 개발자(서버 개발자)에게 데이터 분석 요청을 해야 하는데, 상대방 업무의 우선순위에 따라 분석에 걸리는 시간이 오래 걸릴 수도 있고, 정확히 내 입맛에 원하는 결과를 얻기 쉽지 않을 수도 있다. 이럴 경우 PO가 직접 DB에 접근하여 데이터를 추출/분석/시각화 할 수 있다면 상당히 생산적일 것이고, 덤으로 본인이 담당하는 제품(Product)의 내부 데이터 구조도 파악할 수 있다. (생각보다 중요하다)

하지만 이 데이터를 다루는데 쓰는 시간은 잘 관리해야 한다. 위에서 얘기한 대로 PO로서의 업무 우선순위를 잊지 말아야 한다. PO는 사용자의 요구사항/문제점을 파악하여, 제품/팀의 방향을 정하고, 개발할 업무의 우선순위를 정하는 것이 Main role이다. 데이터 분석은 이 과정에서 고객의 행동 패턴을 파악하거나, 문제점을 파악하거나, 개발팀이 개발한 제품/기능이 제 역할을 하고 있는지 등을 파악하여 PO가 의사결정을 할 때 참고하려고 하는 것이 주요 목적이다. 절대 ‘데이터’가 가장 우선이 되어야 하는 경우는 없어야 한다. "데이터 분석을 위한 데이터 분석”은 지양해야 하겠다는 얘기다.

개인적으로는 기술적인 부분에도 관심이 많아 C사 입사 후 SQL query를 배워 상용 데이터에 종종 접근하여 필요한 데이터를 확인하곤 했다. (실제 Raw data는 아니었고, 분석을 위해 Raw data를 복사해놓은 분석용 DB 데이터였다.) DB에서 '데이터를 추출'한 후 필요한 경우 Microsoft Excel의 일부 유용한 함수(vlookup, countif  등)/피벗 테이블을 사용해서 '데이터를 가공'하여 분석에 활용하곤 했다. 개인용으로 사용할 경우 ‘데이터 가공’에서 끝내기도 했지만, 공유나 보고용으로 데이터를 가공한 경우에는 Excel 내장 그래프/차트 기능으로 ‘시각화’까지 신경써서 했다.참고로, 아래 정도가 내가 데이터를 직접 추출/분석한 케이스(목적)였다. 솔직히 좀 더 복잡한 지표를 분석(장문의 query를 작성)하거나, Tableau 등의 전문화된 시각화툴을 사용하여 Dashboard를 만드는 케이스 등은 직접 하지 못하고 데이터 분석 담당자(C사에서는 Business Analyst라 불렀다)께 요청을 하여 처리하곤 했다.

1. 주요 비즈니스 지표 분석 (예, 매출 성장 추이, 결제 성공율, 고객 재방문율 등)
2. 고객 이슈(CS) 직접 대응 (예, 고객센터 매니저가 급히 ‘고객 A가 할인쿠폰을 사용해서 결제했다고 하는데, 할인 적용이 안되었다고 한다. 실제 쿠폰이 적용 된 건지, 언제 된 건지, 얼마 결제가 된건지 확인을 해달라’라고 전화해서 부탁하는 경우)
3. 주요 지표는 아니지만 내 제품을 고객이 어떻게 사용하고 있는지 확인할 때 (예, '새로운 프로모션 페이지에서 실제 쿠폰을 다운받은 고객은 몇 명이고, 아무것도 안하고 바로 나가버린 고객은 몇 명인지 등을 확인하고 싶을 때’ 등)

그러나 여기서 끝이 아니었다. 얼마 전 호텔 관련 온라인 비즈니스를 하는 B사로 이직 후에는 데이터 과학자(Data scientist)과 협업을 할 일이 많아졌다. 당연히 C사에도  있는 Role이나, 나는 직접적으로 같이 일하는 경험은 거의 하지 못했었다. 이에 그들이 정확히 무엇을 하는지, 그리고 나는 그들과 어떻게 일해야 하는지, 그들을 통해 무엇을 얻어낼 수 있는지 잘 알지 못했었다. 이에 이 글 마지막에서는 'PO와 데이터 과학'에 대해 잠시 얘기해보고자 한다.

그럼 PO/PM은 데이터 과학을 공부해야 하는가?

데이터 분석의 경우와 같은 의견이다. 당연히 알면 좋고, 많이 알면 더 좋다. 하지만 이 역시 필수는 아니다.

모든 웹 기반 서비스들은 결국 데이터 기반이고, 이 안에서 가설을 세워 ‘가치’를 찾고 ‘검증'해 낼 수 있는 능력이 중요하다. 문제 해결을 위한 가설이든, 새로운 기회를 찾기 위한 가설이든, 이 ‘가설’을 기반으로 실험(experiment)를 하고 이의 결과를 데이터로 검증해야 한다. 이때 A/B 테스트와 같이 일부 트래픽만 실험에 참여한 경우, 이 실험 결과가 통계적으로 유의미한 결과인지도 확인해야 한다. (예, 전체의 10%만 신규 기능을 사용했는데 결과가 좋았다고 100%가 사용했을 때도 똑같이 결과가 좋으란 법은 없다)

이렇게 대규모 데이터로 ‘실험’을 하거나, 실험의 기반이 되는 Insight를 찾기 위해 데이터를 뒤지는 경우 데이터 과학자와 일하게 될 경우가 많다. 데이터 과학자의 정확한 Role은 이 채용 공고를 통해 확인해 볼 수 있겠지만, 짧게 얘기하자면 기존 데이터 속에서 Insight를 찾거나, 기존 데이터를 활용해서 미래를 예측(prediction)하거나, 고객에게 더 나은 검색결과를 보여주거나, 상품을 추천해주기 위한 데이터 모델링을 하는 사람들이다.

솔직히 나도 아직 이 데이터 과학자들이 어떤 방식으로 데이터를 분석하고 결과를 만들어내는지 모른다. 그러나 내가 잘 모른다고 해서 데이터 과학을 ‘활용’하지 못하는 건 아니다. 어떤 방식으로 분석할 지에 대해 고민하는 것은 데이터 과학자의 역할이다. 대신 PO는 좋은 질문을 던져야 한다고 생각한다. 좋은 질문을 던지기 위해서는 흔히 ‘도메인 지식’이라 얘기하는 인더스트리에 대한 이해가 토대가 되어야 하고 이를 기반으로 여러 각도에서 계속 질문해야 한다. 예를 들자면, “여름 휴가시즌에 호텔들은 방 가격(A)을 매일 어떻게 결정할까”와 같은 질문이 있다면, 단순히 '휴양객이 많은 8월 초(B : 수요)에 가격이 가장 높을 것이다’를 넘어서 당시 호텔들의 객실이 얼마나 차 있는지(C : 객실 예약율), 그 호텔들의 작년 휴가시즌 가격은 어땠는지(D : 작년가격) 등 여러가지 영향을 줄 수 있는 요소들을 미리 생각해놓고, 이 값(B, C, D)들의 변화에 따라 A(가격)이 어떻게 움직이는 지를 확인해 볼 수 있다. 이때 이 B, C, D를 뽑아낼 수 있는 게 결국 도메인 지식이라고 생각한다. 또한, 분석의 목적에 따라 ‘여름 휴가’를 8월로만 한정할 것인지, 7-8월 2달간 데이터를 볼 것인지, 유럽만 볼 것인지, 4성급 이상 호텔만 확인할 것인지 등 여러가지 상세한 조건들을 결정하여 분석에 적용을 해야 한다. 이를 결정하기 위한 기반도 결국 도메인 지식이라고 생각한다.

다시 한 번 정리하자면, PO는 본연의 Role을 잊지 말고 데이터 분석/예측도 결국 문제 분석과 의사 결정을 돕기 위한 과정 혹은 Tool로 생각해야 한다. PO가 슈퍼맨이 될 수는 있지만 될 필요는 없다. 오히려 본인의 제품과, 이 제품의 시장/산업에 대한 이해를 토대로 좋은 질문을 던질 수 있어야 한다. 이 좋은 질문에 좋은 답변을 해줄 수 있는 데이터 분석가/과학자가 옆에 있다면 그 PO의 제품과 팀은 좀 더 밝고 깨끗한 안경을 끼고 고객과 시장을 바라볼 수 있을 것이다.

* 참고로, ‘머신러닝’이나 ‘딥러닝’이란 얘기는 이제 많이 들어봤을텐데, 데이터 과학은 이들을 아우르는 범주이다. 실무에서는 일부 product을 제외하고 머신러닝을 사용하는 경우는 거의 보지 못했다. (내가 추천, 검색, 랭킹 등 product을 담당하지 않아봐서 그럴지도 모른다)