콘텐츠로 건너뛰기

의사결정 당 회의 비율, 런칭 당 PPT 작성 수 등등 재미있고 중요한 비즈니스 지표들

저와 저녁 식사를 함께 해본 분들이라면 아시겠지만, 저는 ‘micromort(마이크로모트)’라는 개념을 자주 언급하며 여러 위험한 활동들을 위험도 순으로 나열하는 걸 즐깁니다. 이제 글로도 이 이야기를 할 수 있게 되었네요. 자, 그럼 마이크로모트가 무엇일까요?

마이크로모트(Micromort): 백만 분의 1 확률로 죽음에 이를 위험.

이 측정법을 사용하면 어떤 활동이든 위험도를 비교하거나 순위를 매길 수 있습니다. 사실, 여러분이 좋아하는 최신 대형 언어 모델(LLM)은 활동별 마이크로모트 수치를 테이블로 만들기에 아주 능숙하죠. 심지어 “교외나 시골 지역에서 낮 동안 자전거 타기의 마이크로모트 수치를 알려줘” 같은 구체적인 조건을 넣어 검색할 수도 있습니다.

아래는 다양한 활동별 마이크로모트를 한눈에 보여주는 유용한 그래픽입니다. (요약하자면, 등산이나 베이스 점핑(base jump), 그리고 나이 들기는 피하는 게 좋다는 뜻이네요.)

의사결정 당 회의 비율, 런칭 당 PPT 작성 수 등등 재미있고 중요한 비즈니스 지표들

이 지표는 굉장히 흥미로운 개념입니다. 여러분도 스스로 “이게 결국 노출도의 문제 아닌가?”라고 생각할 수 있을 텐데요. 예를 들어, 일주일에 10시간 자전거를 타는 것과 평생 한 번 스카이다이빙을 하는 걸 어떻게 비교할 수 있을까요? 물론 시간당 마이크로모트를 추정해야 하고 — 최신 대형 언어 모델(LLM)이 이 부분을 잘 해낼 수 있죠 — 그 노출 시간을 기준으로 정규화(normalize)해야 합니다.

또 다른 재미있는 시도는 “나에 대해 알고 있는 걸 바탕으로, 내가 가장 위험한 마이크로모트 활동은 무엇일까?”라고 LLM에 물어보는 겁니다. 끝없는 재미가 되죠. 이 부분은 독자 여러분에게 맡기겠습니다.

제가 좋아하는 다른 지표들도 소개할게요:

  • 시간당 행복 비용(Cost per hour of pleasure, CPHP): 콘서트나 농구 경기를 관람하는 것은 CPHP가 높은 편입니다. 반면, 주 3회 사용하는 아주 괜찮은 러닝머신을 사는 건 CPHP가 낮죠. 기본적으로 자주, 거의 매일 사용하는 물건일수록 CPHP가 낮은 편입니다. 물론 자신을 속여서 ‘이건 평생 쓸 거야’라며 실제로는 옷장에 먼지만 쌓이는 제품일 경우는 예외입니다(네, 저도 그런 적 많습니다).
  • 시간당 불평 횟수(Complaints per Hour, CPH): 이건 여러분이 친한 친구들과 대화할 때도 마찬가지입니다. 불평을 많이 하면 CPH가 높아져 결국 부정적인 분위기가 커지게 되죠. 아마도 줄여야 할 지표일 가능성이 큽니다. 하지만 불평하는 게 정말 재미있을 때도 있잖아요? 그런 경우는 비용이 들지 않는, 즉 사실상 CPHP가 0에 가깝다고 볼 수 있어서 결국 서로 상쇄가 될지도 모릅니다.
  • 시간당 휴대폰 확인 횟수(Phone Pickups per Hour): 재미없거나 지루한 사람들과 있거나, 심심한 장소에 있을 때 휴대폰을 들여다보는 횟수가 매우 많아집니다. 아시겠지만, 제가 몇 년 전에 책을 쓸 때 과정이 너무 힘들고 때때로 매우 지루해서 휴대폰을 계속 확인했던 적이 많았습니다. 결국 저는 타이머가 달린 금고에 휴대폰을 넣어 잠가버렸죠. 진짜로요!
  • 자동 모드 대화 비중(% Conversational Autopilot): 누구나 재미없는 대화는 싫어하지만, 정작 그런 대화에서도 쉽게 벗어나지 못하죠. 단체 모임에서 어쩔 수 없이 대화해야 하거나, 1:1 미팅이 예상치 못하게 따분해질 때가 생각보다 많습니다. 형식적으로 자기소개를 하고, 무슨 일 하는지 이야기하고, 여행지는 어디 다녀왔냐고 묻고… 이런 건 서로 이미 수십 번씩 해 본, 자동모드로 떠드는 대화입니다. 대화의 몇 퍼센트 정도가 이런 자동운전 상태일까요? 제 경험상, 정말 좋은 대화는 이런 구간이 20~30%쯤인 것 같습니다. 어느 정도 익숙한 소재로 편안함을 공유하고, 그 다음엔 새로운 주제로 넘어가야 나중에 기억에 남죠. 반대로 자동운전 구간이 75%를 넘는다 싶으면, 그 자리를 빨리 뜨고 싶어집니다.

사실 이런 수치들, 찬찬히 읽으시다 보면 결국 사람이나 상황에 대한 ‘너드스러운 불평’이라는 걸 눈치채시겠죠. 인정합니다. 저는 평소에는 Complaints Per Hour(시간당 불평 횟수)가 낮은 작가라고 생각했는데, 오늘은 제 내면의 민낯을 좀 더 들려드린 셈이네요.

자, 이제 비즈니스 지표(Business Metrics) 얘기로 넘어가 볼까요?

이 글의 제목에서도 암시했듯이, micromort나 휴대폰 확인 횟수만 이야기할 생각은 아니었습니다. 새로운 비즈니스 지표들도 소개하기로 했죠! 실제로 내가 듣기도 했고, 직접 활용하는 진짜 지표들을 이제부터 공유해볼게요.

  • 초당 거짓말 속도(Lies per Second): 스타트업 세계에서는 ‘프레젠테이션’과 ‘과장’, 그 경계가 정말 얇습니다. 물론 진실을 매력적으로 포장하는 정도라면 괜찮겠지만, 때로는 숫자를 꾸며내거나, 실질적 고객은 아닌데도 마치 고객인 것처럼 말하거나, 그래프에서 축이나 범례를 빼버리기도 하죠. 이런 프레젠테이션에선 초당 거짓말 속도가 점점 높아지다 못해 엄청나게 치솟기도 합니다. 만약 회의에서 LPS(초당 거짓말 속도)가 심각하게 높아진다 싶으면, 그 회의는 그냥 일찍 끝내는 게 답일지도 모릅니다.
  • 의사결정 당 회의 비율(Meetings per Decision Ratio): 어떤 결정은 크고, 어떤 건 작죠. 그런데 그 결정을 내리기까지 회의가 몇 번이나 필요했나요? 예를 들어, 누군가를 채용할지 정하는 아주 단순한 일도 어떤 회사는 3~5번의 일관된 인터뷰와 프레젠테이션으로 깔끔하게 결론을 냅니다. 반대로, 어떤 곳은 처음엔 3번, 그다음엔 5번, 또다시 1~2번 더 하고, 다시 3번… 끝이 없는 경우도 있죠. 도대체 왜 이렇게 회의가 많은 걸까요? 보통 이런 경우엔 그 결정을 진짜로 책임지고 내릴 ‘오너’가 없어서, 누구의 승인이 필요한지조차 애매합니다. 목표나 프로세스가 불분명한 경우, 혹은 상황과 기준이 계속 바뀔 때도 이렇습니다. 어쨌든 의사결정 당 회의 비율(MPDR)이 높게 나온다는 건 뭔가 시스템에 문제가 있단 신호이고, 이런 땐 책임 있는 의사결정권자를 찾아서 과정을 단순화해야 할 때입니다.
  • 최초 변명까지 걸리는 시간(Time to First Excuse, TFE): 안 좋은 한 달을 맞이했습니다. 이유가 뭘까요? “계절 탓이야.” 고객들은 당신의 신제품을 별로 좋아하지 않습니다. 이유는? “우리 마케팅이 부족했어.” 리뷰 미팅에 앉아 있으면, 형편없는 결과가 발표되기 전까지 몇 분 만에 변명이 쏟아지는지 셀 수 있죠. (참고로, 문제는 절대 팀 탓이 아닙니다.) 최초 변명까지 걸리는 시간이 짧으면, 다음 변명까지 걸리는 시간(Time to Next Excuse, TNE)도 짧아지는 경향이 있습니다. TFE가 거의 0에 가까워질 때면, 그 팀은 교체하거나 재편이 필요하다는 신호일 가능성이 큽니다.
  • 숫자와 텍스트의 비율(Numbers vs Text Ratio): 스타트업 초기, 제가 가장 좋아하는 단계 중 하나는 아이디어가 막 만들어지는 아주 초창기입니다. 그때는 온통 이야기(스토리)와 글(텍스트/내러티브)뿐이죠. 수치가 전혀 없는 이유는 매출도, 고객도, 제품도 없기 때문입니다. 하지만 몇 년이 지나 시리즈 B 단계에 이르면 발표 자료 곳곳에 수치가 가득해야 합니다. 리텐션 곡선, 재무 지표 등 숫자 중심의 자료로 꽉 채워져야 하는 거죠. 그래서 ‘숫자와 텍스트의 비중’에서 숫자의 비중이 크게 높아져야 합니다. 안타깝게도 실제로는 그렇지 않은 경우가 많습니다. 때로는 5,000만 달러 이상을 투자받은 스타트업이 숫자는 거의 없고 텍스트 중심 자료만 내놓기도 합니다. 때로는 5천만 달러 이상 투자받은 스타트업이 숫자는 부족하고 텍스트 중심으로만 발표 자료를 내놓기도 합니다. 만약 숫자에 비해 이야기 위주의 텍스트 비중이 너무 높다면, 의사 결정 하나를 내리기까지 회의만 잔뜩 늘어나게 됩니다. 반대로 너무 숫자가 부족하면 투자자들이 신뢰하지 않아 투자 유치가 어렵게 되겠죠.
  • 출시 당 파워포인트 작성 수(PowerPoints per Launch, PPPL): 실리콘밸리의 각 제품팀마다 고유한 문화가 있습니다. 많은 스타트업은 ‘출시하며 배우기(ship and learn)’ 방식을 택하죠. 기능을 출시하고, 사용자 반응을 본 뒤, 다시 기능을 추가하는 식입니다. 이런 경우 출시 건당 파워포인트 작성 수는 거의 0에 가깝습니다. 그런데 어느 순간 모든 스타트업은 대기업으로 변해 가고, 그에 따라 조율 비용이 커집니다. ‘파워포인트로 인한 죽음(Death by PowerPoint)’이라는 말처럼, 수많은 보고서와 프레젠테이션 때문에 신제품이나 신규 업무를 출시하기도 어려워지죠. 새로운 아이디어를 내고 싶나요? 그러려면 파워포인트를 만들어야 합니다. 그걸 여러 곳에 돌려가며 발표해야 하고, 시장조사가 왜 이 아이디어가 괜찮은지 증명해야 하죠. 경쟁사가 뭐하는지도 조사하면서, 핵심성과지표(KPI)는 무엇인지도 정리해야 합니다. 자연스럽게 파워포인트가 더 늘어납니다. 이런 ‘출시당 파워포인트 작성 수’를 줄이려면, 사업 추진 의지가 확고한 고위 임원이 직접 나서서 밀고 가야 합니다. 그렇지 않으면 합의 형성 과정에 빠져 ‘회의와 보고서 지옥’에서 헤어나오기 어렵습니다.
  • IQ 당 인건비(Dollar per IQ Point): 만약 스탠퍼드 컴퓨터공학과 상위 1% 학생을 채용한다면, 믿기 어렵겠지만 IQ 점수 한 단위당 지출하는 인건비는 적당한 수준일 가능성이 큽니다. 즉, 똑똑한 인재의 능력 대비 투자 비용이 크게 부담스럽지 않다는 의미입니다. 반면, 주립대 상위 1% 학생을 뽑으면 IQ 점수는 조금 낮을 수 있지만, 요구하는 연봉도 더 합리적이어서 ‘IQ 당 인건비’가 더 저렴해질 수도 있죠. 그렇다면 세상에서 가장 비싼 ‘IQ 당 인건비’를 지불하는 방법은 무엇일까요? 아마도 스탠퍼드 하위 10% 학생을 뽑는 경우일 겁니다. IQ 점수 대비 요구되는 급여가 높아, 비용 효율이 가장 떨어지는 셈이죠 🙂
  • 결정 대비 고민 비율(Decision to Rumination Ratio): 큰 결정도 있고 작은 결정도 있습니다. 어떤 때는 어떤 일을 몇 주씩 깊이 고민하는 반면, 또 어떤 결정은 찰나에 내리기도 하죠. 이상하게도 이 두 가지가 꼭 비례하지는 않습니다. 예를 들어, 새 차를 고르려면 몇 달씩 조사하고 시승도 하며 신중을 기울이지만, 예상치 못한 새로운 기회에는 단 일주일만 생각하고 바로 뛰어들기도 합니다. 이상적으로는 이런 비율을 최대한 일정하게 맞추고 싶겠죠. 즉, 큰 결정엔 충분한 시간을 들이고, 작은 결정엔 최소한의 시간만 쓰는 것이 좋습니다. 하지만 솔직히 우리 모두 이 부분은 서툽니다. 한 가지 중요한 질문이 있습니다. 인생에서 가장 중요한 결정은 무엇일까요? 아마 ‘누구와 결혼할지’, ‘어떤 도시에 살지’, ‘어떤 커리어를 가질지’가 아닐까요? 그런데 이 중요한 문제를 몇 달, 몇 년 동안 집중적으로 고민하고, 전문가 상담도 받아가며 신중하게 결정하는 사람이 얼마나 될까요? 대부분은 그냥 ‘내 느낌’대로 결정하고, 때론 잘 되고 때론 그렇지 않은 경험을 하죠. 그래서 나타나는 현상들이 바로 급하게 결혼하거나(shotgun weddings), 충동적으로 도시를 옮기거나, 갑자기 일을 그만두거나(ragequitting), 충동적으로 헤어지거나, 휴가 중에 문신을 하거나, 충동적으로 반려동물을 사는 등등 다양합니다.

이 지표들은 분명 재미있고 개념적인 아이디어들이지만, 언젠가는 우리가 AI 기반 회의록 작성 앱을 통해 모든 회의를 기록하고 분석하게 되면 실제로 측정할 수 있을 것이라 확신합니다. 심지어 화상회의에서 나오는 모든 문장을 자동으로 팩트 체크해서, ‘초당 거짓말 속도(Lies Per Second)’가 일정 기준을 넘으면 자동으로 알림이 뜨는 기능도 가능해질지도 모르죠.


원문: Lies per Second, Meetings per Decision Ratio, and other important biz metrics


blog by ash에서 더 알아보기

구독을 신청하면 최신 게시물을 이메일로 받아볼 수 있습니다.

댓글 남기기

57.의사결정 당 회의 비율, 런칭 당 PPT 작성 수 등등 재미있고 중요한 비즈니스 지표들

blog by ash에서 더 알아보기

지금 구독하여 계속 읽고 전체 아카이브에 액세스하세요.

계속 읽기