기획
좋은 PM은 '허세 지표/메트릭'을 사용하지 않습니다.
12분
2021.01.08.4.5K
이 글에서 언급되는 PM은 소프트웨어 서비스기업의 프로덕트매니저(오너)/프로그램매니저/프로젝트매니저를 모두 지칭하고, 허세지표, 허영지표* 라는 말은 Eric Ries 의 저서 'The Lean Startup'에 나온 단어 Vanity Metrics으로부터 차용했습니다.
-1. 셜록홈즈 가라사대
많은 분들의 어린 시절을 풍요롭게 해 주었던 셜록 홈즈 시리즈 중 '네 개의 서명 The Sign of the Four'이란 작품에 이런 유명한 말이 나옵니다.
"개개인은 풀기 어려운 하나의 퍼즐이지만 전체가 맞추어 진 상황에서의 그 사람은 수학적 확실성이 된다." While the individual man is an insoluble puzzle, in the aggregate he becomes a mathematical certainty.
이 말을 요즘 많이 회자되는 데이터기반 Data-Driven개념으로 다시 해석하면, "조각 조각의 데이터는 미완성의 정보이지만, 많은 데이터가 모여서 패턴이 되고 정보가 되면, 원래의 그 조각데이터는 큰 그림을 이루는 완벽한 공식속에 존재를 한다"고 해석해 볼 수도 있을 듯합니다. 이해되기 어려운 작은 데이터가 큰 가치를 제공하기 위한 하나의 방법으로 우리는 많은 곳에서 자주 한눈에 이해되고, 쉽게 파악될 수 있는 지표 Metrics를 사용하여 변환하여 보고 그 표현된 정보를 믿고 나눕니다. 그런데, 이 지표를 만들어 내는 과정에서 필요 없는 허영과 허세가 가득 들어가 있다면 어떨까요? 이때 말하는 허영과 허세는 통계자료를 특정한 관점을 주장하기 위해 왜곡, 과장을 하는 것을 말하지는 않습니다. 오히려 정확한 데이터를 왜곡없이 표현하지만, 그것이 보여주는 사람이나 보는 사람에게 좋은 느낌을 전달할 뿐 그 이상의 정보, 인사이트, 지혜 등을 전달하지 못하는 지표를 말합니다. 좋은 느낌에서 그치는 그런 지표는 상황을 정확하게 전달하지 못하기에 건강하지 못한 지표가 되고 결국은 프로젝트, 상품, 서비스의 성공을 보장하기 어려워지는 결정에 기여하게 될 것입니다. 지표를 만들 때 그 허영과 허세라는 것은 무엇이고, 그것을 방지하려면 어떻게 하는 것인지를 예를 들어 이야기해 볼까 합니다.
0. 데이터 스스로는 아무것도 해결할 수 없다.
요즘의 어디를 가도 쉽고 흔하게 듣는 말이 데이터기반 Data-Driven이란 말입니다. 데이터기반 의사결정 Data-Driven Decisions, 데이터 기반 개발, 데이터 기반 디자인 등, 데이터의 중요성이 그 후의 품질을 결정한다 라는 뜻을 함축하고 통용되고 있습니다. 인터넷 데이터 조사 사이트인 DOMO Report에 따르면 2020년 지구상에 있는 모든 개개인은 1초당 1.7메가 바이트의 데이터를 자동으로 생성시키고 있다고 합니다. 이 양은 사실 우리 머리로 생각할 수 있는 한계를 넘어서고 있습니다. ( 왓츠앱메신저는 4천2백만개/1분당 의 메시지를 날리고, 넷플릭스는 40만4천시간/1분당 의 영상을 스트리밍합니다. 링크 참조 ) 이 수많은 데이터가 모여 정보 information이 되고, 개개의 정보가 지식 knowledge과 인사이트 insight, 지혜 wisdom으로 발전을 하면서 그 부가가치가 올라가게 됩니다. 그 부가가치를 쉽고 이해도 높게 전달하기 위해 우리는 지표 Metrics이란것을 자주 사용합니다. 지표를 정의해 봅시다. 메트릭/지표란 현재 진행중인 사업/프로젝트의 성과나 상태를 측정 measure해서 수량화/수치화 quantify/qualify를 한 결과물을 통칭합니다. 보여주고자 하는 것들을 여러가지 형태의 그래프나, 장표, 강조된 숫자들을 이용하게 표현하는 방법이죠. 경영의 신이라 불렸던 피터 드러커의 한 마디 말 "측정할 수 없는 것은 관리할 수 없다" 이 금언처럼 인용이 됩니다. 측정을 하려면 기준을 만들어야 하고, 그 기준은 수치/수량으로 설정하게 될 테이고, 그것을 잘 보여주는 것이 지표/메트릭이 되어야 한다는 뜻이고요. 하지만 데이터기반이라고 외치면서, 그 사용 특히나 경영의 중요한 결정이나 프로젝트의 중요상황을 나타내는 지표로서 이용될 때는 '허세/허영 지표'를 경계하자에만 포커스를 맞추려 합니다.
최첨단 데이터기반, 사용자 경험 기반의 기술의 아주 재미있는 부족한 점을 예로 들어 보겠습니다.
인터넷 쇼핑몰에 들러 청바지를 구매하려 합니다. 여기저기 사이트를 보고, 모델의 핏도 보고, 청바지 세탁상태와 컬러도 확인을 하고 마음에 드는 상품을 바구니에 담아 결제까지 모두 마쳤습니다. 이후부터 어떤 상황이 발생하나요? 내가 방문하는 페이지, 앱에 많은 수의 청바지 광고가 쇄도를 합니다. 어디선가 메일도 오고, 매우 귀찮고, 짜증이 나는 일이기도 합니다. 데이터 기반 시스템은 내가 잠시전에 방문하여 발자국 데이터를 남긴 걸 기가 막히게 알아차리고서 '이 사람은 청바지가 관심이 있구나' 라는 과거 사실 데이터에 근거하여 광고를 쏟아 붓습니다. 여기서 중요한 사항은 모든 사이트가 '중요 정보'라고 생각하는 그 데이터는 '매우 불확실한 과거' 데이터이고, 그것에 따른 페이지 광고 결정은 매우 잘못되었을 가능성이 많다는 것입니다. '쇼핑몰에서 청바지를 구경/쇼핑 했다'라는 데이터는 '청바지를 구매하고 결제를 완성하였다'라는 사실까지는 알려주지 않습니다. 청바지를 이미 구매했는데, 그 사용자에게 지속적으로 청바지 광고 노출을 하는 것은 합리적이지도, 지능적이지도, 비즈니스에도 도움도 되지 않습니다. 이 데이터기반 시스템이 실생활에 도움이 되려면, 오히려, 청바지와 매칭할 만한 티셔츠나, 선글라스, 핸드백 등을 광고에 노출시키는 것이 훨씬 효과적일 수 있기 때문입니다.
제가 말씀드리려는 사실은 "데이터에 집중하는 것은 무의미한 일이다"가 아닙니다. 오히려 반대입니다. 시간이 지나고, 전문기술이 발전함에 따라 그 가치는 증가하고, 빛이 날 겁니다. 그러나 그 데이터를 지표로 보여주고, 그것에 따른 결정을 할 때는 좀 더 신중하고 의미 있는 데이터의 해석이 필요합니다. 그 이야기를 해 볼까 합니다.
1. 허세, 허영, 허풍, 허무 지표 Vanity Metrics
A. 허세의 전형- 누적 지표
허세/허영 지표의 정의는 "데이터를 얻는데 큰 노력이 필요 없으며, 보는 이의 기분을 좋게 할 수는 있지만, 이것을 보고 난 후 무엇을 하면 되는지 프로젝트/비즈니스 인사이트를 제공 하지 못하는 지표"입니다. 그 반대의 개념으로도 설명이 쉽게 되는데 허세 지표의 반대는 Actionable실행이 가능한 지표입니다. 허세 지표는 주로 프로덕트/서비스 홍보나 마케팅 쪽에서 투자자나, 비전문가들을 대상으로 하는 PR을 할 때 또는 언론에 제공하는 경우에 많이 나타나지만, 엔지니어링 프로젝트 진행중 내부 회의 자료로도 많이 등장합니다. 스스로를 칭찬하고 분위기를 고무시키기 위한 가장 대표적인 허세지표는 다음과 같습니다.- 웹페이지의 히트 수
- 앱의 다운로드 수
- 팔로워 수
- 좋아요 수
- 가입자 수
B. 허세가 독으로 쓰일 때 - 팀간 비교 지표
어떤 지표를 사용하여 팀을 비교하려 하면, 그 즉시 그 지표는 독이 됩니다. 팀들 간의 분위기는 둘째 치고, 그 지표의 타겟 값에 오염이 일어나기 시작합니다. "측정치가 목표치가 되는 즉시, 그 측정치는 지표 로서의 가치를 잃는다" 라는 굿하트의 법칙이란 것이 있습니다. 다른 말로 하면, 그 목표치를 얻기 위한 모든 방법을 동원하면서, 원래 측정하려던 의도가 오염이 일어난다는 뜻입니다. 예를 들어, 우리의 제품/서비스를 많은 사람들에게 노출시키기 위해서 제품품질에 역량을 다하기 보다는, 검색엔진을 위한 SEO작업을 통하여 검색랭킹을 올리는데 더욱 집중시키는 결과를 만들려는 노력을 한다는 것입니다. 영업 이익을 측정하려는 데, 월말 분기말이 되면서, 영업부서는 팀간 경쟁을 위해 밀어내기를 무리하게 합니다. 즉 영업 이익 자체가 줄어드는 결과가 나타나는 상황 같은 것입니다. 또한 중요한 편향을 설명할 때 나오는 호쏜 효과 라는 것도 매우 중요하게 작용합니다. "자신의 행동이 관찰되고 있음을 인지하게 될 때 그에 대한 반응으로 자신들의 행동들을 조정, 순화시킨다." 라는 행동 편향입니다. 누가 보고 있으면 내 행동은 원래와 다르게 바뀐다 라는 뜻입니다. 여러분이 매일 경험하게 되는 프로젝트 진행중의 예를 들어봅니다. 스프린트를 진행할 때 속도Velocity 라는 지표를 매우 자주 사용합니다. 하나의 스프린트 동안에 '스토리'라는 개발목표 기능에 각각 포인트를 부여하고 그것을 완성하면, 부여된 그 값을 더하여 '속도'라는 지표로 사용합니다. 이 '속도 Velocity'라는 지표는 사실 팀이 지난 3개월 이상 프로젝트를 진행하면서 취합된 데이터를 기반으로 평균속도를 계산하여 다음 스프린트 플래닝에 참고하려는 용도 이외에 다른 목적은 있을 수 없는데, 가끔 여러 팀을 매니지하는 PM이나 상위 매니지먼트 그룹은 팀 간의 퍼포먼스를 비교하는 지표로 씁니다. 즉 좋은 플래닝툴을 퍼포먼스를 관리하는 툴로 오용한다는 뜻입니다. 백엔드팀과 프론트엔드팀간의 '속도 velocity'비교는 마치 포크레인과 엘리베이터의 속도를 비교하는 것과 같은 비합리적인 것인 데도 말입니다. 위와 같은 상황이 한두 번 지속되면 다음과 같은 최악의 시나리오가 발생합니다.- 스토리는 최대한 구체화되고 세분화되도록 작게 만들어야 하는 원칙임에도 큰 포인트를 얻기 위해 스토리를 세분화하지 않습니다.
- 스토리 포인트에 거품을 넣어 큰 포인트로 만듭니다.
- 이번 스프린트에 스토리 포인트를 얻기 위한 개발이나 테스팅 작업을 철저하게 진행하지 않고, 팀원들 간의 품질 네고가 진행됩니다.
- 제품/서비스의 전체적 품질이 한순간에 나빠지고 이러한 기술부채는 계속 다음 스프린트로 넘어가게 됩니다.
2. 어떤 지표가 실행가능한 Actionable Metrics 인가?
A. One-Size-Fits-All은 없다.
위에서 허세지표에 대한 설명을 드렸으니 어떤 것이 좋은 지표인지를 설명해야 하는데, 이 부분은 솔직히 쉽지 않습니다. 비즈니스와 프로젝트 형태에 따라 각기 너무나 다른 상황이고, 그 시기에 따른 영향도 있기 때문입니다. 모든 사업과 프로젝트에 공통적으로 적용되는 절대적인 one-size-fits-all 같은 지표는 없습니다. 하지만 프로젝트 진행중에 사용할 수 있는 좋은 지표는 수도 없이 많습니다. 예를 들어,- User adoption by feature: 기능별 사용자 선호도
- User loss over time: 시간이 지남에 따라 사용자 이탈정도
- New users by region: 지역별 신규 사용자
- Average velocity over time: 스프린트당 평균 속도
- Cumulative flow
- Mean backlog item age
- Sprint burn-down
- Release burn-up
- Mean time to recover
- Escaped defect rate
- Percent code coverage for unit tests
예를 들어 현재 프로젝트가 사용자들을 우리 제품/서비스에 'Retention 고객 유지'를 해야 하는 상황이라면-즉 새로운 버전 업그레이드를 계획하고 있거나 서비스 릴리즈를 생각하는 경우- 위에 열거한 엔지니어링 지표 외에 다음과 같은 지표 선택을 맞추어 볼 수 있습니다.
- 고객 이탈율
- 사용자로 부터 장해신고후 딜리버리까지 걸린 평균시간
- (특정 기간이나 버전을 정하여) 한번이라도 접속/이용을 한 사용자
- (특정 기간이나 버전을 정하여) 장바구니에 담고 결제를 하지 않은 사용자
- (특정 기간이나 버전을 정하여) 평균 이용 시간
B. 허세지표에 호흡을 불어넣는 코호트 분석
이미 많은 분들이 잘 알고 계시는 방법이라고 생각하지만, 제가 가장 사랑하는 지표를 소개합니다. 위에서 이야기한 허세지표의 전형적인 누적숫자 메트릭을 순식간에 좋은 지표, 실행가능한 메트릭으로 간단히 변환시켜주는 마법과 같은 기술입니다. '코호트 분석 Cohort Analysis' 라는 방법인데, 통계적으로 동일한 특색이나 행동양식을 보여주는 사용자를 집단으로 묶어서 주로 시간 스케일에 넣어서 분석을 하는 방법입니다. (예를 돕기 위에, 코로나바이러스가 발생을 하면 요양원, 병원 등을 '코호트 격리'를 한다는 말을 들어 보셨을 것입니다. 그때의 코호트 즉 집단으로 통째로 관리한다는 뜻입니다.) 아무렴 백 마디 설명보다 짧은 예가 이해에 도움이 되시겠죠?
위의 표는, 2019년 7월부터 2020년 6월까지 1년간 매달 첫번째 컬럼에 코호트 그룹을 만들어 그 달의 다운로드 수와, 해당월 부터의 현재까지의 구독율을 정리한 표입니다. 이렇게 코호트 표로 작성하게 되면 2개의 큰 이점을 발견할 수 있는데,
- 파란색 수직축으로는 매달 시간에 따른 다운로드 수를 월단위로 추적하면서 고객의 유지상황을 볼 수 있습니다.
- 빨간색 수평축으로는 매달 시간에 따른 구독률 현황을 볼 수 있게 됩니다.
3. 당신의 제품/서비스를 성공으로 이끄는 지표 Metrics
여러분의 제품/서비스를 성공으로 이끄는 지표Metrics은 이미 여러분의 팀원과 여러분이 함께 갖고 있습니다. 먼저 반드시 지켜야 할 점은 허세지표에 취하지 말아야 한다는 점은 분명합니다. 또한 회사내 팀들을 비교하기 위한 지표는 건강한 지표가 될 수 없다는 것 또한 위에서 말씀드렸습니다. 여러분의 역할이 프로덕트매니저(오너)/프로그램 매니저 라면, 고객과 시장의 요구사항을 정확히 파악하고 그것의 품질을 만족하는 지속가능한 제품을 합의된 시기에 제공하는 것입니다. 그 지표를 엔지니어링 매니저가 만들어 줄 것이라고 기대하지 마십시오. 인터랙티브 디자이너의 업무지표는 프론트 엔드 개발자가 설정할 수 없습니다. PM으로서 여러분이 해야 할 일은 모든 지표가 각각의 위치에서 한팀으로 성공적인 제품을 릴리즈 하는데 최선을 다하고 실수를 줄이기 위해 나와야 한다는 사실을 지속적으로 이야기하는 것입니다. 그 지표가 다음 프로젝트를 할 때 개선이 되고, 참고가 되고, 필요하다고 모든 팀원이 느낀다면 그것은 분면 좋은 지표이고, 좋은 지표는 좋은 제품, 고객들의 애로점을 해결해 주는 성공적인 제품이 될 것입니다. 오늘도 최선을 다하는 여러분을 무한 응원합니다.로그인하고 자유롭게 의견을 남겨주세요.
