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테스트, 데이터 기반 의사결정을 이야기할 때, 정말 지겹도록 많이 듣는 단어입니다.

그런데 이 흔하디 흔한 A/B 테스트가 정작 제대로 수행되는 경우는 생각보다 드뭅니다.

A/B 테스트는 실험이 제대로 설계되지 않으면 이 테스트의 도입 취지에 맞춰 더 좋은 의사결정을 하는데에 도움이 되기는 커녕, 리소스만 낭비하고 오히려 잘못된 정보로 사람들을 잘못된 판단으로 이끌 수 있기 때문입니다.

그래서 앞으로 몇 번의 시리즈를 통해 이 A/B 테스트를 이루는 중요한 개념들을 설명하려고 합니다.

A/B 테스트가 뭔데??

A/B 테스트는 무작위 대조 실험(RCT: Randomized Controlled Trial)이라는 응용통계 기법을 제품 개발 등에 적용할 수 있게 간소화한 버전으로, 일종의 실험 방법론입니다.

이 ‘무작위’ ‘대조(통제된)’ ‘실험’ 이라는 각각의 단어가 A/B 테스트의 핵심 키워드입니다.

오늘은 이 중 쉽지만 가장 중요한 실험이라는 단어의 의미를 설명해보려 합니다.

여러분, 혹시 학교 다닐 때 과학시간에 실험 했던 것 생각 나시나요?

이런 실험을 왜 했을까요? 특정한 화합물 A와 B를 조합했을 때 어떤 결과가 나오는지를 배우기 위함이었을까요?

실험을 직접 해보는 근본적인 목적은 사건을 발생시키는데 필요한 조건이 갖춰져 있을 때 매번 같은 결과가 나온다는 것을 배우기 위해서입니다.

즉, 물을 가열하면 빨리 증발한다는 가설을 반복해서 확인해보면서, ‘Y라는 결과의 원인은 X’라는 답을 얻으면, X를 반복함으로써 Y역시 재현될 수 있다(젖은 옷에 열을 가하면 빨리 마른다)는 지식을 얻는 것이죠.

즉 실험의 핵심은

• X가 Y를 일으킨다는 가정을 확인하여
• (X가 정말 Y의 원인이라면) X의 반복으로 Y도 재현될 수 있다는 지식

을 얻는 것입니다.

A/B 테스트가 ‘지식’이 아니라 ‘실험’인 이유는, 우리가 바꾸는 어떤 조건이 결과에 영향을 미친다는 인과성에 대한 가설을 확인하는 과정이기 대문입니다.

이 ‘실험’이 의미하는 바가 좀 감이 오시나요?

성공적인 실험조직의 사례

A/B 테스트의 가장 유명한 사례는 bing의 검색엔진 결과 화면입니다.

검색결과의 길이를 조금 늘린 버전을 보여주자는 굉장히 사소해보이는 아이디어는 너무 사소해보여 우선순위가 몇 달이나 밀리고 있었습니다.

그러나 그 아이디어를 빠르게 실험하려고 나선 한 엔지니어 덕분에 실험이 이루어졌고, 실험의 분석결과 핵심적인 사용자 경험을 손상 시키지 않고도 매출을 12%나 증가시킨다는 것을 알게 되었습니다. 이는 빙 전체 제품에 적용되었고 빙 역사상 최고의 매출을 창출하는 아이디어가 되었습니다.

검색결과를 이러저러하게 바꿔 보여준다(X)가 사용자의 전환율을 높인다(Y)는 결과를 가져온다는 것을 실험을 통해 검증하고, 아이디어의 임팩트를 정량화하여 제품과 비즈니스를 성장시킬 수 있었던 것이죠.

하지만!!

현실에서는 우리가 지금 임팩트를 측정하고 싶은 X 말고도, Y에 영향을 줄 수 있는 요인이 너무나 많습니다. 정말 아무 이유 없이 지표가 개선되거나, 악화되는 경우도 생각보다 정~말 많은데, 그럴때조차도 의사결정을 위한 실험은 실험결과가 우연이나 다른 요인 때문이 아니라 X 때문이라는, Y에 대한 ‘인과성’을 보장해줄 수 있어야 합니다. 그러기 위해서는 충분한 샘플수, Bias가 최소화될 수 있는 실험 설계, 실험 결과에 대한 통계적 검증과 같은 것들이 필요합니다. 

때로는 실험을 할 수 없는 경우도 있습니다. 어떨때는 실험을 통해 기대할 수 있는 최고의 결과나 최악의 결과에 비해 실험 자체에 드는 비용이 너무 클 때도 있구요. 특히나, 조직적인 차원에서 실험을 통해 제품을 개선하는 문화를 만들어가려면 가장 중요한 것이 실험 결과 효과가 없는 것으로 밝혀졌을 때 그 아이디어를 폐기할 수 있느냐 인데, 실험을 해보면 거의 대부분의 아이디어가 임팩트가 없다는 것을 알게 되기 때문에 실험 역시 시스템적으로 효율화해야 합니다. 

아마존, 마이크로소프트, 우버, 에어비앤비와 같은 내노라하는 세계적인 팀에서도 실험을 통해 정말 효과를 검증하는데에 성공하는 아이디어는 20%도 되지 않는다고 합니다. 하지만 이미 어느정도 규모의 경제를 달성한 상태라면, 정말 작은 지표의 개선도 큰 임팩트가 되기 때문에 정교한 A/B 테스트 역시 훨씬 더 그 가치가 큽니다. 

반면 리소스가 제한된 스타트업 환경에서 백로그에 할 일이 쌓여있지 않은 팀은 정말 드물텐데요, 그때 A/B 테스트의 가치는 '임팩트가 더 큰 일을 찾기 위해서' 입니다. 그런데 테스트 결과를 보고 100개 중에 80개를 버리는데, 매번 개발을 다 하고 결과를 보고나서 개발 다 한 피처를 버린다? 이건 린스타트업이 A/B 테스트를 제대로 최적화한 상태는 아닌 것 같습니다.

이터레이션을 반복하면서 실험에 드는 비용을 점점 줄이고, 점점 더 적은 리소스로 의미있는 데이터를 얻을 수 있는 방법 등에 대한 개선된 학습이 이루어지지 않으면, A/B 테스트는 구성원들에게 쓸데없는 일만 늘리고 태클만 거는 거추장스러운 무언가가 될지도 모릅니다. 그래서 실험은 최소한의 비용을 들여 빠르게 실행해야 하고, 꼭 개발을 하지 않더라도 임팩트를 측정할 수 있는 더 작고 날렵한 방법들을 찾아내야 합니다. 또 UX가 중요한 B2C 프로덕트인지, 아니면 확장성과 유연함이 중요한 B2B 프로덕트인지에 따라서도 A/B 테스트의 목표와 가치 역시 달라진다는 것 또한 생각해봐야할 것 같습니다. 

관련해서 더 많은 내용을 알고 싶으시다면 다음의 컨텐츠를 추천합니다. 

• 론 코하비, 다이앤 탕의 <A/B 테스트>
• A/B 테스트를 하지 않아 유저를 잃었던 당근마켓의 사례 직관만 믿고 까불었다가 망한 PM의 사연
• 증거기반 아이디어 검증을 위한 A/B 테스트 심화 Idea Validation — Much More Than Just A/B Experiments - Itamar Gilad

• 원문 작성일 : 23년02월21일
• 사내에 발행했던 데이터레터 중 한 편으로, 공개를 위해 내용을 약간 수정했다. 사실 테스트 드리븐이 가능하려면 우선 데이터를 보고 의사결정하는 문화가 이미 어느정도 만들어져 있어야 한다. 어떤 지표를 어떻게 볼 것인지와 같은 리터러시가 어느정도 올라와있어야하고, 인과성에 대한 개념이 잡힌 뒤에야 의미있는 테스트가 가능하다. 막말로 vacant metric 놓고 A/B 테스트 백날 해봐야 의미 개뿔 없음.
• 회사에서 왜 비즈니스 지표 뿐 아니라 제품 engagement 지표를 봐야하는지 설명하고 주장하면서 C팀 설득하는 단계를 증말 힘겹게 겨우겨우 넘어서, 이제 조금씩 PO들이나 PD들이 봐야하는 지표들을 구체적으로 잡아가는 단계를 헤쳐나가고 있는 주제에 내가 이런 글을 공유하는거 너무 민망한 일이지만...애초에 이 글은 데이터로 일하는 경험이 전혀 없는 비데이터 직군 분들에게, A/B 테스트의 파운데이션에 해당하는 개념들을 설명하기 위해 쓴 입문용이니 그냥 철판 깔고 퍼블리시 한다. ㅎㅎ