기능 성공 지표, 정말로 측정하고 있나요?

본문은 요즘 IT와 번역가 Yuna가 함께한 아비 시겔(Avi Siegel)의 글 <Your Feature Success Metrics Are Worthless>을 번역한 글입니다. 필자인 아비 시겔은 엔지니어로 경력을 시작해 19년 이상 IT 분야에서 일하며 제품 관리까지 경험한 베테랑이자, Momentum의 공동 창립자입니다. 이 글에서는 가치 있는 성공 지표를 설정하는 방법과 이를 효과적으로 모니터링하는 방법을 설명합니다.

필자에게 허락을 받고 번역했으며, 글에 포함된 링크는 원문에 따라 표시했습니다.

수요일 오전 10시 16분. VP(Vice President)가 슬랙으로 메시지를 보냈습니다.

“안녕하세요. 지난달에 출시한 새로운 협업 기능의 성과는 어떤가요? 슬라이드 업데이트해야 해서요.”

순간 속이 철렁 내려앉았습니다. 기능 성과가 나쁜 건 아니었습니다. 아니, 사실 그 성과가 어떤지 전혀 모르고 있었기 때문이었습니다. 마지막으로 해당 기능의 지표를 본 게 출시 회고 때였습니다. 그때도 겨우 몇 차례의 사용자 인터뷰에서 나온 “사용자들이 좋아하는 것 같아요.” 정도의 피드백이 전부였습니다.

급히 기능 기획서에 정의해 둔 성공 지표가 뭐였는지 떠올려 봅니다. 뭐였더라, 도입률? 그리고 아마도 시간 절약? 그렇다고 해도 그 숫자를 어디서 확인해야 할까요? 누군가 추적하고 있기는 한 걸까요? 아니, 애초에 이걸 책임지고 있는 사람이 누구였죠? 결과는 뻔했습니다. VP와의 대화는 전혀 잘 풀리지 않았습니다.

사실 대부분의 팀은 기능의 성공 지표를 단순한 형식적 절차로 취급합니다. 측정 방식을 논의하고 마지못해 기획서에 몇 가지 지표를 적어 두지만, 결국 실제 데이터는 한 번도 들여다보지 않죠. 우리는 보여주기식 성과 측정에 갇혀 있습니다. 성공을 측정하는 척하지만, 실제로는 그저 형식적인 절차를 밟을 뿐입니다. 그러나 우리는 이 악순환에서 벗어날 수 있습니다.

보여주기식 성과 측정

이 모든 것이 낯설지 않다면, 당신만 그런 게 아닙니다. 기술 산업은 지표와 특이한 관계를 맺고 있습니다. 지표를 마치 절대적인 기준처럼 떠받들다가도, 정작 신경 쓰지 않는 것이죠.

우리는 특정 기능이 사용자의 실제 문제를 해결할 거라고 떠들어댑니다. (그리고 절대 미리 솔루션을 만들고 나서 문제를 끼워 맞춘 건 아니라고 강하게 부정하죠!)
우리는 굿하트의 법칙(Goodhart’s Law) 같은 개념을 잘 알고 있다고 자랑하면서도, 결국 조작하기 쉬운 지표를 선택하고, 직접 그 지표를 조작하기도 합니다.
핵심 지표(가치 중심)와 보조 지표(활용 중심)의 차이를 이해하지 못하며, 심지어 가드레일 지표(제품의 다른 부분을 망치지 않도록 확인하는 지표)에 대해서는 아예 고려조차 하지 않습니다.
의미 있는 측정이 과연 가능한지에 대한 논쟁을 벌이다가, 결국 "추가적인 작업 없이는 어렵다"라는 결론을 내리고, 자연스럽게 범위 밖으로 밀어버립니다.
마지못해 제품 기획서에 몇 가지 지표를 적어 넣고, 형식적인 절차만 밟습니다.
그리고 다시는 그 지표를 돌아보지 않죠.

결국 우리는 데이터 중심적인 접근이 중요하다고 떠들지만, 실제로는 전혀 그렇게 행동하지 않습니다. 참고로 여기서 이야기하는 성공 지표는 기능 단위에서의 지표입니다. 상위 수준의 성공 지표는 보통 OKR(이것도 제대로 하고 있지 않을 가능성이 높습니다), KPI 또는 북극성 지표와 같은 개념으로 다뤄집니다.

기능 기획서와 현실 회피하기

모든 제품 팀에는 버려진 기능 기획서들이 쌓여 있습니다. 여기서 “버려졌다”라는 표현을 쓴 이유는 두 가지입니다.

1) 기능이 개발되지 않았습니다

사실 이 경우는 오히려 좋은 일일 수 있습니다. 기능을 기획했다고 해서 반드시 개발까지 해야 하는 것은 아니죠. 기획 과정에서는 초기 가설을 검증해야 하는데, 그 결과 필요 없다고 판단되었다면 중단하는 것도 올바른 선택입니다. 그러니 이 부분은 넘어가겠습니다.

2) 아무도 해당 기능이 성공했는지를 확인하지 않았습니다

여러분은 고객이 필요로 하는 것이 무엇인지 조사하고, 이를 어떻게 제공할지 고민했으며, 그 기능이 실제로 고객에게 도움이 되었는지를 평가하는 기준까지 설정했죠. 그런데 정작 그 기준을 바탕으로 확인하는 과정은 전혀 이루어지지 않았습니다.

만약 과거의 결정을 되돌아보며 실제로 올바른 선택이었는지를 검증하지 않는다면, 어떻게 우리가 올바른 결정을 내리고 있다고 확신할 수 있을까요? 우리가 했던 작업이 충분한 효과를 냈는지, 추가 작업이 필요한지는 어떻게 알 수 있을까요? 어떤 부분을 개선해야 할지조차 모른다면, 우리의 방식은 어떻게 발전할 수 있을까요?

더 이상 타조처럼 머리를 모래 속에 파묻고 현실을 외면하지 마세요. 측정하기로 했던 것은 반드시 측정하세요. 필요한 것을 반복적으로 개선하세요. 비즈니스와 제품이 앞으로 나아갈 수 있도록 진화해야 합니다.

성공 지표의 세 가지 유형

모든 팀이 성공 지표를 정의하고 추적해야 한다는 것은 알고 있습니다. 하지만 실제로 이를 제대로 실행하는 팀은 많지 않습니다. 대부분은 측정하기 쉬운 지표에만 집중하고, 정작 실제로 중요한 것은 놓쳐버립니다. 더 심각한 경우, 완벽하고 정밀한 측정을 목표로 하다가 결국 측정 자체가 불가능한 상황에 빠지기도 합니다.

이제 우리가 기능을 평가할 때 반드시 추적해야 하는 세 가지 유형의 지표를 살펴보겠습니다. 이 지표들을 “세 개의 다리를 가진 의자”라고 생각해 보세요. 하나라도 빠지면, 측정 전략 전체가 무너집니다. 세 가지 모두 있어야, 우리가 만든 기능이 정말 가치가 있었는지 완전한 그림을 볼 수 있습니다.

1) 핵심 지표(가치 중심)

핵심 지표는 해당 기능이 실제로 해결하려던 문제를 해결했는지를 측정합니다. 예를 들면 다음과 같습니다.

온보딩 과정을 개선하여 사용자들이 더 빠르게 가치를 얻도록 만들었다면, 사용자가 실제로 더 빠르게 가치를 얻고 있나요? (단순히 온보딩 과정을 더 빨리 완료하는 것이 아니라, 실제로 핵심 기능을 더 빨리 활용하는지를 확인해야 합니다.)
일괄 편집 기능을 추가하여 시간을 절약하도록 만들었다면, 사용자가 실제로 시간을 절약하고 있나요? (단순히 일괄 편집 기능을 사용하는 것이 아니라, 해당 기능 덕분에 업무 시간이 줄어들었는지를 봐야 합니다.)
데이터 내보내기 기능을 출시하여 사용자가 원하는 방식으로 데이터를 분석할 수 있도록 했다면, 사용자가 실제로 데이터를 활용해 원하는 답을 얻고 있나요? (단순히 데이터를 내보내는 것이 아니라, 데이터를 다른 도구로 옮겨서 실질적인 분석이 이루어지는지 확인해야 합니다. 또한, 사용자가 정말로 내보내기 기능이 필요했던 건지, 아니면 기존 대시보드에 새로운 지표나 필터가 필요했던 건지도 고려해야 합니다.)

기능이 실제 문제를 해결하도록 만들었다면, 그것이 실제로 문제를 해결했는지 반드시 입증해야 합니다.

2) 보조 지표(활용 중심)

보조 지표는 기능이 얼마나 도입되었는지를 측정합니다. 도입은 중요한 요소인데요. 결국 아무도 사용하지 않는 기능이라면 의미가 없겠죠. 하지만 도입만으로는 충분하지 않습니다. 누군가 기능을 사용한다고 해서 반드시 가치를 얻는 것은 아닙니다.

많은 팀이 이런 사용량 지표를 핵심 지표처럼 다루는데요. 그 이유는 사용량을 측정하는 것이 가장 쉽기 때문입니다. 하지만 사용량이 기능의 유용성을 판단하는 올바른 방법이 아니죠. 더 나아가 굿하트의 법칙(Goodhart’s Law) 때문에 문제가 더 심각해지는데요. 만약 도입률 자체를 성과 지표로 삼는다면, 해결책은 단순히 기능에 더 많은 관심을 끌도록 유도하거나, 사용자의 워크플로우에 강제로 포함시키는 방식으로 변질될 가능성이 높습니다. 이렇게 되면 기능이 자연스럽지 않거나 불편한 방식으로 사용될 위험이 있습니다.

또한 많은 팀이 사용 지표를 더 깊이 분석하지 않고 표면적인 수치에서 멈춥니다. 단순히 “이 기능을 몇 명이 사용했는가?” 정도만 보고, 다음과 같은 질문을 하지 않는 경우가 많습니다.

세분화: 대상 사용자 중 몇 퍼센트가 실제로 이 기능을 사용했나요?
발견 가능성: 기능이 제공된 후 평균 첫 사용까지 걸리는 시간은 얼마인가요? 사용자는 메뉴를 통해 기능을 찾는가 아니면 특정 작업 중에 기능을 접하나요?
참여도: 사용자는 이 기능을 평균적으로 얼마나 오래 사용하나요? 기대했던 사용 패턴과 비교했을 때 어떤 차이가 있나요?
활용 깊이: 전체 사용자 중 고급 기능을 활용하는 비율과 기본 기능만 사용하는 비율은 어떻게 되나요?
재사용률: 사용자가 기능을 한 번 사용한 후 다시 사용하는 비율은 얼마인가요? 일별, 주별, 월 재사용 패턴은 어떻게 되나요?

사용량을 깊이 분석하는 방법은 다양합니다. 그리고 올바른 핵심 지표와 함께 분석한다면 충분히 가치 있는 작업이 될 수 있죠.

따라서 사용자가 해당 기능을 사용하고 있는지, 그리고 어떻게 사용하는지는 반드시 측정해야 합니다. 하지만 그렇다고 해서 사용자가 기능을 원했다거나, 기능을 통해 가치를 얻고 있다는 증거가 되지는 않습니다.

3. 가드레일 지표(문제 예방 지표)

가드레일 지표는 문제가 발생했을 때 가장 먼저 신호를 보내주는 탄광 속 카나리아와 같습니다. 우리가 좋은 결과를 내는 동안, 그 과정에서 다른 문제를 일으키고 있지는 않은지 확인하는 역할을 합니다. 하지만 많은 팀은 이러한 지표를 간과합니다. 왜냐하면 성공을 입증하는 데만 집중하고, 실패를 방지하는 것에는 신경을 덜 쓰기 때문입니다. 그런 팀이 되지 않도록 다음과 같은 질문을 던져보세요.

간소화된 결제 프로세스가 오히려 전환율을 떨어뜨리지는 않았나요?
새로운 공유 기능이 페이지 로딩 속도를 크게 저하한 것은 아닌가요?
더 직관적인 대시보드가 오히려 CS 문의를 증가시키지는 않았나요?
자동 저장 기능이 AWS 월별 저장 비용을 세 배로 늘리지는 않았나요?

가장 효과적인 가드레일 지표는 대부분 지루하고 당연해 보이는 기본적인 것들입니다. 팀은 대개 이 기능이 영향을 미칠 것이라 생각조차 하지 않았던 지표들이 예상치 못한 문제를 일으키곤 합니다. 이 지표들을 제품의 건강 상태를 확인하는 기본 생체 신호라고 생각해 봅시다. 이 지표들에 집착할 필요는 없지만, 제품이 여전히 정상적으로 작동하고 있는지 확인할 필요는 있습니다.

성공 지표를 더 잘 활용하는 방법

지금까지 당신의 성공 지표 관리 방식이 단순한 보여주기식이었다는 사실을 인정했다면, 잘하고 있는 겁니다. 그리고 이제 다양한 유형의 지표에 대해 더 잘 이해하게 됐죠. 좋습니다. 이제 이를 어떻게 제대로 실행할 것인지 이야기해 보겠습니다.

이 과정은 복잡한 로켓 공학이 아닙니다. 데이터 과학 학위가 필요한 것도 아닙니다. 단지 자신이 성공을 제대로 측정하고 있는지, 혹은 전혀 측정하지 않고 있는지를 스스로 속이지 않는 것이 중요합니다. 그리고 기능 개발의 첫 단계부터 측정 계획을 포함하는 습관을 들이면 됩니다.

다음은 보여주기식 체크리스트를 넘어, 지표를 실제 의사결정 도구로 만드는 8가지 방법입니다.

1) 최소한 세 가지 지표는 설정하세요.

모든 기능에는 반드시 세 가지 유형의 지표가 포함되어야 합니다.

기능이 실제 가치를 창출했는지 측정하는 핵심 지표
기능이 얼마나 자주 사용되는지 측정하는 보조 지표
기능이 다른 요소를 망가뜨리지 않았는지 확인하는 가드레일 지표

반복해서 말하지만 이 세 가지 지표가 모두 있어야 기능의 성과를 올바르게 평가할 수 있습니다.

2) 대시보드 우선 개발

기능을 위한 코드를 한 줄이라도 작성하기 전에, 그 기능의 성공을 측정할 대시보드를 먼저 만들어야 합니다. 이렇게 하면 다음과 같은 이점이 있습니다.

무엇을 측정할 것인지 정확히 정의할 수 있습니다.
실제로 측정이 가능한지 미리 검토할 수 있습니다.
측정할 수 있는 환경을 미리 구축할 수 있습니다.
비교할 수 있는 기준선을 확보할 수 있습니다.

이렇게 해야 필요할 때마다 쉽게 결과를 확인할 수 있습니다.

3) 매주 수요일 아침 규칙

각 지표에 대해 스스로에게 이렇게 물어보세요. “CEO가 지금 당장 이 지표를 확인하고 싶다고 하면, 바로 볼 수 있는가?” 만약 답이 “아니오”라면, 다른 지표를 설정하거나, 측정 방식을 변경해야 합니다. 완벽한 지표를 찾는 것도 중요하지만, 필요할 때 실제로 확인할 수 있는 지표를 설정하는 것이 더욱 중요합니다.

4) 지표 확인 일정

출시 후에야 비로소 언제 성공을 측정할지 고민하는 실수를 하지 마세요. 앞서 설명한 원칙에 따라, 언제든지 성과를 확인할 수 있어야 하는데요. 그렇다고 해서 시간 단위나 일 단위로 변화에 집착할 필요는 없습니다. 중요한 것은 필요할 때 지표를 확인할 수 있는 환경을 갖추는 것입니다.

따라서 미리 언제 어떤 지표를 확인할 것인지 정해야 합니다.

출시 전 : 비교를 위한 기준선 지표를 수집
1주 차 : 가드레일 지표를 매일 확인하여 작은 문제가 커지기 전에 해결
2~4주 차 : 초기 가치 및 실사용률에 대한 주간 심층 분석
2~3개월 차 : 지속적인 가치 및 실사용률에 대한 월별 점검
분기 말 : 초기 목표 대비 전체적인 영향 분석

이 일정은 팀의 업무 방식에 맞게 조정하면 됩니다. 하지만 지표를 확인하지 않고 넘어가서는 안 됩니다.

5) 책임자 지정

이 지표들을 책임지고 관리할 사람이 필요합니다. 즉, 누군가가 직접 담당하여 지속적으로 확인하는 역할을 맡아야 하죠. 명확한 책임자를 지정하세요. 보통 다음과 같은 팀 내 리더가 담당하게 됩니다.

프로덕트 매니저
프로덕트 오너
리드 엔지니어
프로젝트 매니저
기타 타팀 매니저

누가 맡았는지는 중요하지 않습니다. 다만 팀이 스스로에게 솔직할 수 있도록 관리할 책임자가 반드시 있어야 합니다.

6. 성공과 실패

성공 지표는 단순히 진행 상황을 추적하는 것만이 아닙니다. 언제 축하할지, 언제 경고를 울려야 할지를 아는 것이 핵심입니다. 그렇지 않으면 단순히 데이터만 모을 뿐 의미 있게 활용하지 못하게 되죠.

따라서 다음과 같은 원칙을 지켜야 합니다.

성공과 실패의 기준을 명확하게 설정하세요. 일단 지켜보면서 “이 정도면 괜찮은가?”라고 판단하는 방식은 피해야 합니다. (그렇게 하면 결국 스스로를 속이게 될 가능성이 큽니다.)
위험 신호를 감지할 수 있는 자동 알림 시스템을 구축하세요. 심각한 문제가 발생했을 때는 주간 회의 때까지 기다렸다가 보고하기엔 너무 늦을 수 있습니다.
실패 상황에 대한 대비책을 마련하세요. 예를 들어, (일부 활성 사용자가 있더라도) 해당 기능을 완전히 중단할 것인지 결정해야 합니다. 쉽지 않은 결정이겠지만, 제품이 불필요한 기능만 늘어나는 기능 공장이 되는 것을 막기 위해서는 꼭 필요한 과정입니다.
롤백을 쉽게 만들기 위해 기능 플래그를 활용하세요. (예를 들어, 개인적으로 LaunchDarkly 같은 기능 플래그 툴을 선호합니다.)

성공과 실패의 기준을 명확하게 정의하고, 각 상황에 대한 대응 전략을 미리 마련하면 즉흥적으로 대응할 필요 없습니다.

7) 제품 전략과의 연계

기능 성공 지표는 상위 지표들과 논리적으로 연결되어야 합니다. 만약 그렇지 않다면, 이는 비즈니스에 궁극적으로 중요하지 않은 문제를 해결하고 있거나, 또는 경영진이 비즈니스에 중요한 것이 무엇인지 제대로 평가하지 못하고 있다는 의미입니다. (무슨 생각을 하고 있는지 알고 있습니다. 모든 직급의 경영진들이 사용자가 진정으로 필요로 하는 것에 대해 뭘 알겠냐고 생각하겠죠. 하지만 둘 다 가능성이 있습니다.)

8) 자동화, 자동화, 자동화

수작업이 필요하다면 결국 실행되지 않을 가능성이 높습니다. 항상 해야 할 일이 너무 많기 때문이죠. 따라서 다음과 같은 작업을 자동화해야 합니다.

데이터 수집 자동화
실시간 업데이트되는 대시보드 구축
자동 알림 설정

말로만 했던 것들을 실제로 실행하세요

기능 성공 지표 점검은 실제로 이렇게 이루어져야 합니다.

“새로운 기능의 성능은 어떤가요?”
“보여드리겠습니다. (대시보드를 열며) 사용자당 주간 시간 절약이 2시간으로 안정적입니다. 목표 사용자 기반의 34%가 일주일에 최소 3번 이상 이 기능을 사용하고 있으며, 평균 사용 횟수는 주 16회입니다. 이 기능과 관련된 CS 문의가 일시적으로 증가했었지만, 이는 이미 해결된 버그 때문이었습니다. 일일 지표 요약을 받아보시겠습니까?”

이것이 형식적인 지표 관리와 실제 지표 기반 제품 개발의 차이입니다. 전자는 그럴듯한 명세서를 만들어내지만, 후자는 더 나은 제품을 만들어냅니다. 다음에 기능 명세서의 “성공 지표” 섹션을 작성할 때는 잠시 멈춰 어떤 지표가 진정으로 중요한지 생각해 보고, 그것을 실제로 측정할 수 있는 현실적인 계획을 세우세요.

지표 전략 없이 기능을 개발하는 것은 제품이 결국 성공했는지, 실패했는지 알 수 없다는 의미입니다. 그걸 깨닫기까지도 너무 오래 걸리는 일이죠.