좋은PM은 '허세 지표/메트릭'을 사용하지 않습니다.
프로젝트를 올바로 이끌기 위해서는 '허세 지표'를 사용하지 말아야 합니다
이 글에서 언급되는 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을 할때 또는 언론에 제공하는 경우에 많이 나타나지만, 엔지니어링 프로젝트 진행중 내부 회의 자료로도 많이 등장합니다. 스스로를 칭찬하고 분위기를 고무시키기 위한 가장 대표적인 허세지표는 다음과 같습니다.
웹페이지의 히트 수
앱의 다운로드 수
팔로워 수
좋아요 수
가입자 수
우리 사이트/서비스/제품이 얼마나 인기가 있고, 이 앱, 포스트, 개인이 얼마나 사랑받고 있는지를 보여줄때 빠짐없이 나오는 지표입니다. 그런데 왜 허세 vanity라고 하는지 이 숫자를 얻기 위해 내 역할이 얼마나 공헌한 것이지 명확한 구분을 할 수 있나요? 이 숫자에 따라 내가 다음달, 다음해에 무엇을 하여야 하는지, 어떤 행동을 취하여야 하는지가 명확한가요? 대부분의 경우 저 숫자만으로는 알 수도 없고, 어떻게 해야하는지도 모릅니다. 이미 여러분이 눈치 채셨겠지만, 대부분의 허세지표는 누적숫자를 이야기 합니다. (밑에서 이 허세지표가 실행가능한 지표 actionable metrics이 되려면 어떤것을 보강해야 하는지에 대해서 설명하겠습니다.)
위의 예에서 말한 '다운로드 수'는 초기 프로모션이나 광고효과로 내려받은 후, 더 이상 사용하지 않거나, 앱을 삭제한 경우에 해당이 되도 이미 숫자로 카운트가 된 상황이라 '허세'지표라 부릅니다. 같은 이유로 가입자 수 역시 가입이탈이 일어나도 그 숫자는 추적을 하지 않기 때문입니다.
허세지표가 나쁜 이유는 '노력없이 쉽게 얻어지는것'과 '지표의 명확성 부족'입니다. 그 숫자 자체의 표현 이외에는 어떠한 백그라운드 제공하고 있지 않습니다. 지표가 좋으면 모두 내 덕이라고 생각을 하고 지표가 나쁘면 그건 네 탓이라고 생각하게 되는 나쁜 문화를 생성하기도 합니다. 그런데 이 허세지표는 이렇게 바깥으로 보여지는 지표 뿐만이 아니라 기업의 내부에도 존재합니다. 그것도 훨씬 나쁜 형태로 말입니다.
B. 허세가 독으로 쓰일때 - 팀간 비교 지표
어떤 지표를 사용하여 팀을 비교하려 하면, 그 즉시 그 지표는 독이 됩니다. 팀들간의 분위기는 둘째치고, 그 지표의 타겟값에 오염이 일어나기 시작합니다. "측정치가 목표치가 되는 즉시 , 그 측정치는 지표로서의 가치를 잃는다" 라는 굿하트의 법칙이란 것이 있습니다. 다른 말로 하면, 그 목표치를 얻기위한 모든 방법을 동원하면서, 원래 측정하려던 의도가 오염이 일어난다는 뜻입니다. 예를 들어, 우리의 제품/서비스를 많은 사람들에게 노출시키기 위해서 제품품질에 역량을 다하기 보다는, 검색엔진을 위한 SEO작업을 통하여 검색랭킹을 올리는데 더욱 집중시키는 결과를 만들려는 노력을 한다는 것입니다. 영업 이익을 측정하려는데, 월말 분기말이 되면서, 영업부서는 팀간 경쟁을 위해 밀어내기를 무리하게 합니다. 즉 영업 이익 자체가 줄어드는 결과가 나타나는 상황 같은 것입니다.
또한 중요한 편향을 설명할때 나오는 호쏜 효과 라는 것도 매우 중요하게 작용합니다. "자신의 행동이 관찰되고 있음을 인지하게 될 때 그에 대한 반응으로 자신들의 행동들을 조정, 순화시킨다." 라는 행동 편향입니다. 누가 보고 있으면 내 행동은 원래와 다르게 바뀐다 라는 뜻입니다.
여러분이 매일 경험하게 되는 프로젝트 진행중의 예를 들어봅니다. 스프린트를 진행할때 속도Velocity 라는 지표를 매우 자주 사용합니다. 하나의 스프린트 동안에 '스토리'라는 개발목표 기능에 각각 포인트를 부여하고 그것을 완성하면, 부여된 그 값을 더하여 '속도'라는 지표로 사용합니다. 이 '속도 Velocity'라는 지표는 사실 팀이 지난 3개월 이상 프로젝트를 진행하면서 취합된 데이터를기반으로 평균속도를 계산하여 다음 스프린트 플래닝에 참고하려는 용도 이외에 다른 목적은 있을 수 없는데, 가끔 여러 팀을 매니지하는 PM이나 상위 매니지먼트 그룹은 팀간의 퍼포먼스를 비교하는 지표로 씁니다.
즉 좋은 플래닝툴을 퍼포먼스를 관리하는 툴로 오용한다는 뜻입니다. 백엔드팀과 프론트엔드팀간의 '속도 velocity'비교는 마치 포크레인과 엘리베이터의 속도를 비교하는 것과 같은 비합리적인것인데도 말입니다.
위와 같은 상황이 한두번 지속되면 다음과 같은 최악의 시나리오가 발생합니다.
1. 스토리는 최대한 구체화되고 세분화되도록 작게 만들어야 하는 원칙임에도 큰 포인트를 얻기 위해 스토리를 세분화하지 않습니다.
2. 스토리 포인트에 거품을 넣어 큰 포인트로 만듭니다.
3. 이번 스프린트에 스토리 포인트를 얻기 위한 개발이나 테스팅작업을 철저하게 진행하지 않고, 팀원들간의 품질 네고가 진행됩니다.
4. 제품/서비스의 전체적 품질이 한순간에 나빠지고 이러한 기술부채는 계속 다음 스프린트로 넘어가게 됩니다.
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
Agile 상황에서 좋은 지표는 수도 없이 많고, 그 상황을 지원하는 툴도 매우 많습니다.
그럼에도 어떤 상황에서 어떤 지표를 선택하는 것이 좋을지는 항상 고민이 되는데, 저는 중요지표를 셋팅할때 이 자료를 참고로 하여 가치기준을 잡습니다. 소위 AARRR 프레임워크라고 하는것인데 지금 프로젝트의 진행상황이 어느상황인지에 따라서 나의 지표를 정할 수 있습니다.
예를 들어 현재 프로젝트가 사용자들을 우리 제품/서비스에 'Retention 고객 유지'를 해야 하는 상황이라면-즉 새로운 버전 업그레이드를 계획하고 있거나 서비스릴리즈를 생각하는 경우- 위에 열거한 엔지니어링 지표외에 다음과 같은 지표 선택을 맞추어 볼 수 있습니다.
고객 이탈율
사용자로 부터 장해신고후 딜리버리까지 걸린 평균시간
(특정 기간이나 버전을 정하여) 한번이라도 접속/이용을 한 사용자
(특정 기간이나 버전을 정하여) 장바구니에 담고 결제를 하지 않은 사용자
(특정 기간이나 버전을 정하여) 평균 이용 시간
다시한번 말씀드리면 여러분이 PM의 업무를 담당하거나 꼭 PM의 위치가 아니어도 뭔가 제품/서비스의 방향을 정하는 지표를 셋팅해야 하는 위치라면, 그 지표를 보는 모든 사람들에게 어떤 일관된 행동을 일으키게 해야 한다는 점이 중요합니다. 그냥 지표를 보고 "응, 알았어, 잘하고 있네" 이런 반응이 아닌 "아 이런 상황이니, 우리 이렇게 해야 하는거 아닌가, 아니면 우리가 뭔가 잘못 하고 있다는 것 아닐까?" 라는 반응이 나와야 한다는 것입니다.
B. 허세지표에 호흡을 불어넣는 코호트 분석
이미 많은 분들이 잘 알고 계시는 방법이라고 생각하지만, 제가 가장 사랑하는 지표를 소개합니다.위에서 이야기한 허세지표의 전형적인 누적숫자 메트릭을 순식간에 좋은 지표, 실행가능한 메트릭으로 간단히 변환시켜주는 마법과 같은 기술입니다. '코호트 분석 Cohort Analysis' 라는 방법인데, 통계적으로 동일한 특색이나 행동양식을 보여주는 사용자를 집단으로 묶어서 주로 시간스케일에 넣어서 분석을 하는 방법입니다. (예를 돕기 위에, 코로나바이러스가 발생을 하면 요양원, 병원등을 '코호트 격리'를 한다는 말을 들어보셨을것입니다. 그때의 코호트 즉 집단으로 통째로 관리한다는 뜻입니다.) 아무렴 백마디 설명보다 짧은 예가 이해에 도움이 되시겠죠?
위의 표는, 2019년 7월부터 2020년 6월까지 1년간 매달 첫번째 컬럼에 코호트그룹을 만들어 그 달의 다운로드 수와, 해당월 부터의 현재까지의 구독율을 정리한 표입니다. 이렇게 코호트 표로 작성하게 되면 2개의 큰 잇점을 발견할 수 있는데,
1. 파란색 수직축으로는 매달 시간에 따른 다운로드 수를 월단위로 추적하면서 고객의 유지상황을 볼 수 있습니다.
2. 빨간색 수평축으로는 매달 시간에 따른 구독율 현황을 볼 수 있게 됩니다.
예를 들어 2019년 10월에는 그럭저럭 다운로드 숫자는 평소의 증가세를 유지하지만, 구독율은 다른 달에 비하면 급강하를 하게되는데, 이 부분은, 제품/서비스의 결함이라기 보다는, 초기 3개월 프로모션 기간이 끝나면서, 이탈율이 늘었다거나, 혹은 연휴기간이 겹치면서 구독율이 떨어진다고 예상해 볼 수 있습니다.
또한 긍정적 신호로는 2020년 1월에 급격한 다운로드수 증가와 이탈율이 거의 없는 구독율을 확인하게 되는데, 아마 이때는 제품/서비스의 품질의 향상이나 새버전이 시장에서 좋은 반응을 보이는 경우일 수 있으며, 그것이 어느정도 유지가 되다가 2020년 5월 큰 위기가 닥칩니다. 물론 새버전의 품질 결함일 가능성이 많은데, 혹은 코로나로 인한 경제가 타격을 입어서 절대 구독률이 급감했을 수도 있습니다.
이와같이 코호트 분석은 같은 허세지표가 될 수 있는 누적 데이터를 수직과 수평으로 나누어 좀더 전략적인 데이터로 활용해 볼 수 있는 실행가능한 지표로 만들어 줍니다. 여러분도 한번 사용해 보시면 좋을듯 합니다.
3. 당신의 제품/서비스를 성공으로 이끄는 지표 Metrics
여러분의 제품/서비스를 성공으로 이끄는 지표Metrics은 이미 여러분의 팀원과 여러분이 함께 갖고 있습니다. 먼저 반드시 지켜야 할 점은 허세지표에 취하지 말아야 한다는 점은 분명합니다. 또한 회사내 팀들을 비교하기 위한 지표는 건강한 지표가 될 수 없다는 것 또한 위에서 말씀드렸습니다. 여러분의 역할이 프로덕트매니저(오너)/프로그램 매니저 라면, 고객과 시장의 요구사항을 정확히 파악하고 그것의 품질을 만족하는 지속가능한 제품을 합의된 시기에 제공하는 것입니다. 그 지표를 엔지니어링 매니저가 만들어 줄것이라고 기대하지 마십시오. 인터랙티브디자이너의 업무지표는 프론트엔드 개발자가 설정할 수 없습니다. PM으로서 여러분이 해야 할 일은 모든 지표가 각각의 위치에서 한팀으로 성공적인 제품을 릴리즈 하는데 최선을 다하고 실수를 줄이기 위해 나와야 한다는 사실을 지속적으로 이야기 하는것입니다. 그 지표가 다음 프로젝트를 할때 개선이 되고, 참고가 되고, 필요하다고 모든 팀원이 느낀다면 그것은 분면 좋은 지표이고, 좋은 지표는 좋은 제품, 고객들의 애로점을 해결해 주는 성공적인 제품이 될것입니다. 오늘도 최선을 다하는 여러분을 무한 응원합니다.
