27. Carrying Capacity를 실무에 적용해보고 느낀 점

[월간 글쓰기] 한 달에 한 편, 글을 씁니다. 기획자로 커리어를 밟아가며 느낀 점들을 가감없이 풀고, 기록합니다. [1. 일단 따라해보자] 토스팀의 리더인 이승건 대표님의 PO SESSION 영상으로 C.C라는 개념을 접했다. 당시에 정말 충격이었고, 몇 번을 되돌려봤다. 영상으로 볼 때는 직관적이고 이해하기 쉬웠는데, 막상 실무에 적용해 보려고 하니까 생각보다 어려운 점들이 있었다. 디테일한 부분들은 스스로 채워나갔다. 그러다가 진짜 중요한 부분들이 있어서 다시 보면 '토스에 입사하시면 알 수 있을 것 같습니다'하고 안 알려주시더라. 개념을 체득해야 성장한다고 믿기 때문에 실제로 적용해 보면서 깨달은 바를 적어보려고 한다. ​ [2. 신규 유저수(New Customer)와 이탈률(Churn rate)은 정말 상수인가?] C.C의 계산법은 '신규 유저수/이탈률'이다. 여기서 대표님이 두 값은 변수가 아니라 상수라고 하셨다. 그래서 실제로 해봤다. 변수던데요. 매일 다르게 찍히던데요. 그런데, 추이로 보면 '같다'라고 해도 될 만큼 비슷했다. 신규 유저수가 튀는 날이 있고, 이탈률이 튀는 날이 있다. 그럼에도 월단위로 몇 개월 동안 지표를 보면, 그 서비스의 신규 유저수와 이탈률은 일정하더라. 한 가지 주의해야 할 점은 서비스 크기가 10만 명이 안 될 정도로 작으니 C.C가 너무 달라져 신뢰할 수 없었다. 내가 적용해 본 서비스는 앱 내 MAU 1만 명 정도 찍히는 작은 서비스였다. 영상에선 C.C만큼 MAU가 늘어난다고 되어 있었는데, 신규 유저수의 모수가 너무 적어서(비율로만 따지면 10% 이상 차이가 났음) C.C를 확정하기 어려웠다. C.C는 MAX MAU인데, 그게 계속 달라졌다. 그러다 보니 실제 MAU와 C.C 간의 갭도 컸다. (참고로 영상에서 신규 유저 수와 이탈률을 매일 계산한다고 해서 C.C를 매일 계산했다) C.C가 어떤 날은 5만이었다가, 8만이었다가, 10만까지 갔다가, 2천이 되는 날도 있고... 그래도 MAU는 일정했다. 더 정확히 말하면, 일정하다고 해도 될 만큼 편차가 크지 않았으며, 신규 유저수와 이탈률도 마찬가지였다. 내가 데이터를 제대로 클렌징하지 못한 것도 있을 것이고, 여러 원인들이 있었을 것이다. 결론은, 신규 유저수와 이탈률은 상수라고 해도 될만큼 크게 변하지 않았다. 나의 경우 모수가 너무 적어서 C.C가 튀었을 뿐, 값 자체는 고만고만했다. [3. C.C보다 어려웠던 AU(Active User) 정의하기] C.C 자체는 어렵지 않았다. 공식이 어려운 편도 아니고. 그런데 AU(Active User)를 정의하는 게 어려웠다. C.C의 공식을 한번 뜯어보자. C.C = 신규 유저수/이탈률 신규 유저수 = 서비스에 새로 인입된 유저 이탈률(%) = 이탈유저/전체유저 C.C를 계산하기 위해서는 전체유저, 신규유저, 이탈유저를 알아야 하는데, 그러기 위해선 AU(Active User)를 정의해야 했다. 그래야 전체유저와 신규유저, 이탈유저를 정의할 수 있기 때문이다. 이게,, 생각보다 빡셌다.​ AU를 정의하는 것 자체는 그럭저럭 할 수 있다. 그리고 신규유저도 쉽다. 넘어가도록 하자. 그렇다면 전체유저는 무엇인가? 전체유저 = 신규유저 + 기존유저 - 이탈유저라고 정의했다. 그럼 기존유저와 이탈유저를 정의해야 하는데, 이건 어떻게 계산하냐. 무엇이 기존유저이고, 무엇이 이탈유저인 것이지? 이탈했다가 돌아온 유저는 신규유저인가, 기존유저인가? 영상을 다시 봤더니 이탈유저를 정의하는 게 매우 중요하고, 한번 정의하면 절대! 바꾸면 안 된다고 하면서 슥 넘어갔다. '토스에 입사하시면 알려드릴 거예요' 토스 입사하는 거 엄청 빡세던데요 대표님... 추가 영상에선 대략 3개월이면 떠난다고는 하셨지만, 산업이나 서비스 성격에 따라 천차만별이니 각자만의 정의가 필요하다. 그래서 단순히 이탈률 = (1-retention) (영상에서는 1/retention이라고 하셨는데,, 잘못 작성하신 게 아닐까) 으로 계산할 수 없다. 무엇을 이탈로 정의할 것인지에 따라 이탈유저가 달라지고, 전체유저가 달라지기 때문이다. 내가 적용했을 때 C.C와 MAU가 달랐던 이유는 이 부분에서 뭔가 놓쳤을 것 같다. 개인적으로 이탈유저를 정의하는 게 쉽지 않았다. [4. C.C는 꼭 필요한가?] 우리 회사에서 C.C 개념을 도입해보려고 여러 노력들을 해봤지만, 결론적으로 우리 회사에서 C.C는 사용하지 않는다. 본질로 돌아가보자. 우리 회사에는 C.C가 필요한가? 그렇다면, 왜 필요한가? C.C는 무슨 역할을 하는가? 개인적으로 아래 조건들을 모두 만족했을 때 C.C가 중요한 역할을 할 수 있다고 생각했다. 1) 독립적인 서비스를 제공하는 플랫폼 형태의 제품인 경우 2) 성장지표를 전사적으로 중요한 지표로 보는 경우 3) 사내 이해관계자들 간에 C.C를 중요한 지표라고 합의 가능할 경우 1번은 토스가 유행시킨 '슈퍼앱'을 재해석한 말이다. 요즘 대부분의 대표님들이 ~~카테고리의 슈퍼앱이 될 거라고 하시는데,, 정작 플랫폼이 아닌 제품인데도 그렇게 얘기를 하시는 분들도 봤다. 다들 슈퍼앱에 꽂히신 것 같다. 토스는 금융 관련된 모든 서비스를 제공하고, 각각의 서비스는 독립적으로 운영할 수 있다. 그에 반해 다른 형태의 제품(ex 커머스, SaaS, B2B 등)들은 C.C로 못할 건 없지만, 더 적합한 그로스 프레임워크가 있을 것이라고 생각한다. 신규 서비스나 기능 하나 런칭했다고 C.C만큼 MAU가 늘어날까? 그럴 수도 있지만, 그렇지 않을 수도 있다. SaaS에서 '신규 서비스 런칭했어요!' 한다고 그만큼 사용자수가 확 늘어나나? 그렇지 않다. 게다가, 2번과 연결 지어서 성장지표보다 더 중요한 비즈니스 지표(매출, 이익, 비용 등)들을 복합적으로 고려해야 할 수 있다. 전 회사는 커머스였는데, 신규 서비스를 런칭할 때 중요 지표는 비즈니스 지표였다. 결과적으로 서비스 런칭 후 MAU가 20% 증가했다. 신규 서비스의 C.C가 전체 MAU에 얹힌 것이었다. 그렇다고 해서 C.C를 중요하게 생각했나? 그러지 않았다. 그럴 필요도 없었을까? C.C로 일해보지 않아서 잘 모르겠다. 3번도 커머스인 경우인데, 시나리오를 그려봤다. 제품팀) 매출이 아닌 C.C를 늘려야 합니다! 영업팀) 너네 매출 안 나오면 책임질꺼야? C.C 늘리면 매출 올린다고 확신할 수 있어? 제품팀) 네, C.C는 제품의 본질적인 체력이므로 C.C를 올리면 매출이 늘어납니다. 영업팀) 어차피 매출 늘어나는 건 매한가진데, 왜 C.C를 봐야해? 그냥 매출 보면 안돼? 그리고 신규 서비스 만들면 비용도 생각해야 하는데, 그거 계산 안 할 거야? 제품팀) 아니 그것도 볼 건데요.... 반면, 저 3가지를 충족한 토스에선 이런 대화들을 하지 않을까 상상해 봤다. PO) 유저가 이런 페인포인트를 느끼고 있어서 이런 서비스를 제공하면 C.C 40만 규모의 서비스가 될 것으로 보입니다. 초기 마케팅 비용 100만원 태우면 2달 내 C.C 도달시킬 수 있습니다. 동료) 두달에 C.C 40만,, 전에 했던 거는 20만이었는데 이번엔 규모가 꽤 크네요. 한번 해보죠. 비용은요? PO) API 연동하면 건당 1,000원이 발생해서 추정 C.C까지 도달할 경우 월 100만원 정도 발생합니다. 내 생각에 C.C가 필요한 이유는 그로스 임팩트를 공유할 수 있는 직관적이고 확실한 지표이기 때문이다. 전사 구성원이 C.C를 알고 있고, 중요하다고 인지하고 있다면 C.C만으로 커뮤니케이션하는 게 명확할 것이다. [5. C.C보다 중요한 게 있다면] 어떤 프레임워크(AARRR, Unit Economics, KPI, OKR, ...)든 그 자체만으로는 큰 의미가 없다. 목표가 무엇이고, 문제가 무엇인지, 어떻게 해결할 수 있는지, 기대효과가 무엇인지를 정의하는 게 더 중요하다고 생각한다. 그것을 설명하기 위한 수단이 프레임워크인 것이다. 유행하는 프레임워크를 배우는 것보다 지금 주어진 업무를 어떻게든 해결하고, 목표를 달성해나가는 경험을 만들어 내야 하지 않을까 싶다. 그럼에도 명확한 모델링으로 멋진 프로덕트를 만들어 낸 이승건 대표님이 정말 대단하다고 생각한다. 내가 경험한 C레벨 분들은 C.C는 몰라도 그 개념 자체는 경험적으로 알고 있었다. 딥다이브를 하다보면 풀리지 않는 깜깜이 지점들이 있는데, 이승건 대표님은 그 지점을 이론적으로 잘 풀어냈고, 전사 구성원이 그 논리로 커뮤니케이션할 수 있도록 체계를 잡으신 것 같다.

다음 내용이 궁금하다면?

또는

이미 회원이신가요?

2023년 2월 19일 오후 3:27

 • 

저장 9조회 1,441

댓글 1

함께 읽은 게시물

Next.js 프로젝트를 AWS EKS에 배포하며 배운 것들

... 더 보기

쿠버네티스를 활용한 클라우드 네이티브 데브옵스 | 존 어런들 - 교보문고

product.kyobobook.co.kr

쿠버네티스를 활용한 클라우드 네이티브 데브옵스 | 존 어런들 - 교보문고

 • 

저장 5 • 조회 1,017


🍆컬리의 상품위원회 현장을 공개합니다

... 더 보기

- YouTube

youtu.be

 - YouTube

< 감각의 나 vs 상상의 나, 누구를 믿어야 할까? >

1. 자신을 두 존재로 생각하십시오.

... 더 보기

개발자는 개발만 잘하면 될까

최근에 친구가 추천해준 데일 카네기의 인간관계론을 읽던 중 고액 연봉을 받는 엔지니어들의 특징에 대한 흥미로운 내용이 있었다.

... 더 보기

 • 

저장 14 • 조회 2,627


‘똑부(똑똑하고 부지런하기)보다 똑게(똑똑하지만 게으른) 리더가 되라.’ 리더십 코칭에서 빠지지 않는 훈수다. 현장 리더들의 말을 들어보면 실행이 쉽지 않다.

... 더 보기

[김성회의 고사성어 리더십] `똑게 리더십` 3가지 법칙 - 매일경제

매일경제

[김성회의 고사성어 리더십] `똑게 리더십` 3가지 법칙 - 매일경제

 • 

저장 2 • 조회 669