1. 지표란 무엇이고, 왜 지표가 필요한가요?

지표란 달성하고자 하는 목표 또는 현재 수준이나 진행 과정 등을 정량적으로 나타낸 것입니다.

지표란 대상을 양적으로 ‘측정’한 값을 의미합니다. 매출액이 되었건, 프로젝트 진행율이 되었건, 상품 반품률이 되었건 무언가를 측정하는 이유는 측정을 통해 대상을 더 체계적으로 이해하고 효율적으로 관리하기 위해서 입니다.

즉 측정은 그 자체로 목표가 아니라 관리라는 목표를 달성하는 수단이라는 의미입니다. 현재 상태, 진행 정도, 목표 수준 등을 수치로 나타내면 일이 계획대로 되고 있는지, 효율적으로 진행되고 있는지, 우리가 잘 하고 있는지 못하고 있는지를 쉽게 파악할 수 있습니다. 하지만 세상에 공짜가 없듯 측정도 비용이 들기 때문에, 측정의 목적에 맞추어 적절한 방식을 선택하는 것도 중요합니다.

 

예를 들어, 100대의 기계가 돌아가는 공장에서 기계마다 가동효율을 평가하여 성능이 떨어지는 기계를 사전에 파악하기 위해 처음으로 모니터링을 한다고 가정해보겠습니다.

아직 아무것도 없는 상태인데, 만약 실시간으로 데이터를 기록하려고 한다면, 기계마다 측정하는 사람이나 모니터링 시스템이 붙어서 어떤 주기로 제품을 완성시키는지 기록해야 합니다. 기록된 자료가 오류없이 정확한지 확인도 필요하겠죠. 그렇게 기록된 100대의 기계에 대한 각각의 자료를 계속 수합하는 과정도 필요하구요. 이 모든 과정을 실시간으로 업데이트 해주려고 하면, 관리를 통한 효용보다 관리 비용이 더 커질지도 모릅니다.

하지만 몇 시간 또는 하루 단위로 각 기계가 몇 개씩 완성품을 만들었는지 파악하는 것으로도 모니터링하기에 충분하다면, 훨씬 적은 비용으로 기계별 성능 모니터링 데이터를 수집할 수 있습니다.

그런데 만약 기계의 성능을 모니터링하는 것만으로는 충분하지 않고, 그 기계가 언제 도입되었고 실제로 얼마나 가동되었는지, 생산성이 낮아지는 요인은 무엇인지, 가동률에 영향을 미치는 요인은 무엇인지와 같은 정보가 필요하다면, (기계의 최근 생산성을 더 잦은 빈도로 측정하는 것은 중요하지 않지만) 그 정보 이외에도 도입시기나 과거의 가동 기록 등에 대해 일정 기간 이상의 관찰 데이터도 수집되고 관리되어야 합니다. 

이처럼 지표를 수립하기 위해서는 일단 우리가 ‘무엇을’ 알아야 하고, ‘얼마나 정확하게’ 또는 ‘얼마나 신속하게’ 알아야하는지, 이 정보를 가지고 무엇을 하려고 하는지가 함께 정의되어야 합니다.

 

2. 지표는 언제 수립하나요? 

제품의 기능을 개발한다면, 제품의 상세한 스펙이나 기능을 기획하기 전에 ‘고객이 겪고 있는 불편이 무엇인가?’, '어떤 고객이 그런 문제를 겪고 있는가?', ‘그 불편을 어떻게 해결해야 하는가?’, '그 문제를 해결하는 것이 우리의 비즈니스에 어떤 가치가 있는가?' 를 정의하는 단계에서부터 어떤 지표를 수립할 지 고민해야 합니다.

지표는 우리가 지금 하고 있는 일의 목표가 무엇인지 길을 잃지 않도록 도와주는 수단이기도 합니다.

여럿이 함께 협업하는 과정에서 궁극적으로 무엇을 달성하기 위해 이 일을 하고 있는지 공동의 목표를 선명하게 해주죠.

(사족이지만 이런저런거 개발이고 뭐고 다 하고 나서, 뭔가 성과를 보여줘야 하니 이런저런 지표 좀 주세요~ 하는 상황에 던져질 때, 심지어 그 지표가 죄다 vacant metric같을 때....DA로 일하면서 그만큼 현타가 오는 순간도 없는 거 같습니다....)

 

3. 좋은 지표는 어떻게 세우나요? 

좋은 지표란 상황, 제품 특성, 비즈니스 모델 등에 따라 다릅니다. 비즈니스 지표인지, 프로덕트 지표인지에 따라서도 상당히 크게 달라지고, 이미 존재하는 프레임워크도 너무 많죠. 어디에선 답이었던 것이 어디에선 전혀 쌩뚱맞은 지표가 되기도 합니다. 

똑같은 쇼핑검색 서비스의 개선이라도, 유저가 더 많은 몰랐던 물건을 발견하게 해주고 더 오랫동안 체류하게 만드는 것이 목표인지, 아니면 찾는 물건에 도달하는 시간을 줄여 궁극적으로 구매전환까지의 퍼널을 개선하는 것이 목표인지에 따라서 동일한 기능이어도 서로 전혀 다른 데이터를 전혀 다른 관점으로 보게 됩니다.

비즈니스의 특성이나 성장모델에 따라서 무료유저가 가치인 경우도 있지만, 단순한 비용인 경우도 있구요. 

그래서 결국 지표란 우리가 해결하고 싶은 문제의 상태를 포착하고 측정하기 위한 것이라는 점을 이해해야 합니다. 

우리가 해결하고 싶은 문제가 무엇인지 문제정의가 명확해야, 우리가 무엇을 측정하고 싶은지, 그걸 알기 위해 어떤 숫자를 어떻게 봐야하는지를 구체화할 수 있으니까요. 

그런 맥락에서, 다음과 같은 질문에 답하지 못할때는 좋은 지표를 설정하기 어려웠던 것 같습니다. 

  • 지금 하는 그 일을 통해 해결하려고 하는 문제가 무엇인가요? 
  • 그게 해결되면 누가 어떤 베네핏을 느끼게 되나요? 
  • 그 문제를 겪고 있는 사람은 얼마나 되나요? 
  • 그 문제가 해결되면 우리의 비즈니스에는 어떤 임팩트가 있나요?

이런 질문들에 답할 수 있는 여러가지 가설들을 고려하면서, 그 과정에서 필요한 기초 데이터도 보게 됩니다. 그 과정에서 문제정의를 뾰족하게 하면서 기대하는 임팩트가 무엇인지를 합의할 수 있고, 그 임팩트를 측정할 수 있는 가장 적절한 데이터가 무엇이고 그 데이터를 보는 가장 적합한 관점이 무엇인지를 반영하여 지표를 수립하게 됩니다. 

 

4. 좋은 지표의 공통 요건

좋은 지표는 우리가 해결하고 싶은 문제의 status를 잘 포착해주고, 그 문제를 해결하기 위해 우리가 하는 일들(input)과 실제로 문제에 미치는 영향(output)의 흐름을 잘 보여주는 지표입니다. 즉 문제정의를 기반으로 문제와 해결책들의 임팩트를 잘 보여주는(=목적과 성과를 드러내는) 지표입니다. 

저는 그 이외에 가장 중요한 것으로 다음 두 가지를 고려합니다.

  • Measurable : 측정가능한가? 측정이 지나치게 어렵거나 비용이 많이 들지 않는가? accuracy는 얼마나 높아야 하는가? proxy로 고려할 수 있는 대안이 있는가?  

아마 이 부분은 환경과 상황에 따라 매우 다를 것 같은데, 리소스가 제한된 스타트업 환경에서는 정확도와 비용, 그리고 속도 간의 트레이드 오프를 인지해야하기 때문에, 측정가능성에 대한 판단이 중요하다고 생각하게 되었는데요, 아무래도 충분한 인프라가 갖춰진 환경이라면 훨씬 덜 신경써도 되는 부분이겠죠. 

  • Sepcific : entity 레벨에서 대상/기간/속성/범위 등이 구체적으로 정의되어 있는가? 

똑같은 지표를 보고도 서로 다른 정의를 염두에 두고 있어서 완전히 미스커뮤니케이션하는 경우가 제법 생깁니다. 특히 비율 등을 많이 사용하게 되는데, 같아 보여도 사실 분모 자체가 다르거나, 시간축의 기준의 완전히 다르다거나 하는 경우도 흔하고, 때로는 a가 하던 데이터 작업을 b가 하면 전혀 다른 결과가 나오는 경우도 있는데, 이런 문제는 대부분 충분히 구체적이지 않은 데이터 정의에서 나옵니다. 

 

5. 사족

  • 좋은 지표는 우리가 더 잘 할 수 있도록 도와주지만, 좋은 문제정의 없이 좋은 지표는 나올 수 없습니다.
  • 경영학의 왕 피터 드러커가 했다고 회자되는 말 중에 “측정할 수 없다면 관리할 수 없다”는 말이 있는데, 사실 피터 드러커는 그렇게 말한적 없다고 합니다ㅋㅋ 정량화할 수 없다고 해서 중요하지 않다거나 관리할 필요가 없다는 뜻은 아니니까요. 눈에 보이지 않고 지표로 드러나지 않더라도 주목해야 하는 것들이 있다는 점도 간과하지 않아야 겠습니다. 

 


 

  • 원문 작성일 : 23년05월30일
  • 사내에 발행했던 데이터레터 중 한 편으로, 공개를 위해 내용을 약간 수정하였다. 사내에 발행한 버전에는 실제로 회사 프로덕트를 가지고 만든 예제와 여러가지 지표 프레임워크에 대한 구체적인 소개도 들어갔음. 

'테크회사직장인 > 데이터어쩌구' 카테고리의 다른 글

A/B 테스트의 기초 1. ‘실험’  (0) 2023.08.13
Posted by SashaLee
,