토스의 Carrying Capacity를 곱씹어봤습니다
PM이라면 고민해볼 만한 Carrying Capacity에 대한 생각들-
최근 PM 커뮤니티에서 (아니면 제 페북 뉴스피드에서) 한참 유행했던 토스의 Carrying Capacity라는 영상을 봤어요.
https://www.youtube.com/watch?v=tcrr2QiXt9M
Carrying Capacity가 어떤 개념인지는 영상에서도 친절하게 잘 나와있고, 문서화를 하여 풀어낸 다양한 포스팅들도 있는 것 같아서 그 내용들에 대한 부분은 귀찮으니 스킵하고...
저는 오늘 토스의 C.C(Carrying Capacity)를 보면서 '우리도 저걸 적용해보자!'라고 생각하는 PM이나 혹은 Data/Product Analyst 분들이 참고하면 좋을만한 포인트들을 몇 가지 공유해보고자 합니다. 오늘 포스팅은 토스의 Carrying Capacity에서 소개되는 개념들에 대한 이야기들이기 때문에 혹시 Carrying Capacity가 무엇인지 모르시는 분들은 위 영상을 먼저 꼭 보시고 포스팅을 읽으시는 것을 추천합니다.
Carrying Capacity를 구성하는 inflow와 Churn을 도출하는 것이 생각보다 쉽지는 않을 겁니다.
상대적으로 inflow는 간단할 수 있지만 churn은 훨씬 난이도가 높을 겁니다. ‘이탈‘이라는 행동의 정의부터 해야 하기 때문이죠.
예를 들어 inflow는 '신규 유저'라고 하는 정의의 개념으로 봤을 때 회원가입 유저로 볼 수도 있고, 첫 구매 유저일 수도 있고, 첫 로그인이나 혹은 특정 이벤트(행동 패턴)를 처음으로 발생시킨 시점으로 정의하여 계산할 수 있습니다.
그에 비해 Churn의 경우는 '이탈'을 정의해야 하는데, 이 '이탈'을 정의하는 기준은 특정 '이벤트'를 기준으로 설정하기가 어렵습니다. ('회원 탈퇴'라는 이벤트 정도를 제외한다면요. 하지만 현실적인 churn을 계산하기 위해서는 '회원 탈퇴'라는 이벤트는 확실히 적절하지 않습니다. 서비스를 이탈하는 고객이 무조건 '탈퇴'를 하는 게 아니니까요) 결국 특정 이벤트(혹은 아무 이벤트)가 발생하지 않은 유저 군을 추려내야 하는 segmentation작업이 추가적으로 필요합니다. 그리고 '서비스를 이용하지 않는다'는 기준점을 정의해 내기 위해서는 서비스를 이용하는지를 볼 수 있는 대부분의 이벤트들이 트래킹이 되고 있어야 한다는 전제가 되어야 하기 때문에 이런 부분들에서 inflow를 측정하는 것보다는 상대적으로 측정하고 계산하는 로직이 복잡하다고 볼 수 있습니다.
추가적으로 ‘이탈‘이라고 하는 변수는 현실적으로 시간 변수를 가져갈 수밖에 없는데 (예: xx일 내 재방문/혹은 로그인/구매를 하지 않은 유저) 그렇게 된다면 결과적으로 carrying capacity를 계산하는 데에는 많은 딜레이 타임이 발생하게 됩니다(예: 'xx일 내 재방문하지 않은 유저'를 기준점으로 잡는다고 하면 퍼포먼스를 측정하고 싶은 일자부터 최소한 xx일이 지나간 다음에 결과 지표를 볼 수 있으니까요). 그리고 여기서 발생하는 딜레이 때문에 Carrying capacity를 실시간 대시보드 형태로 가져가는 것보다는 주기적으로 체크하는 (최소 일주일에서 보름~ 한 달 정도?) 하는 결과 지표로 관리해야 할 겁니다. 참고로 데이터를 보고 해석하여 추가적인 action을 도출하는데 딜레이가 발생한다고 해서 C.C가 의미가 없다는 것은 절대 아닙니다.
컬리에서는 C.C 를 계산할 수 있는 정도의 데이터 트래킹 인프라 및 데이터 파이프라인을 구축하는데 6개월이 걸렸습니다. (다만 컬리는 데이터 양이 너무 많아서 그런 부분이라 대부분의 초기 서비스에서는 고객 행동 트래킹에 관심을 가지기만 한다면 훨씬 간단하기는 할 겁니다. 그래도 세팅이 시간 투자가 많이 필요하다는 점은 강조하고 싶습니다. 의식적인 backlog, 프로젝트 진행이 있어야지만 가능한 환경 구축입니다)
근본적으로 C.C를 늘리는 것과 inflow와 churn를 개선하는 것은 다른 개념으로 바라보고 접근해야 합니다.
저는 inflow와 churn을 개선하는 영역을 ‘최적화‘의 개념으로 봅니다. 여러분들이 잘 알고 계시는 A/B testing이나 소위 전환율을 높이는 여러 작업들을 통해서 점진적으로 프로덕트를 개선하는 접근방식으로 생각해볼 수 있을 것 같습니다.
반면에 C.C를 늘린다고 하는 것은 ‘새로운 가치제안을 통한 서비스의 개선’의 개념으로 바라봐야 합니다. 토스에서 신용조회 서비스를 제공한 것도 비슷한 개념으로 볼 수 있을 것 같고, 멋쟁이 사자처럼 B2C 서비스인 projectlion 플랫폼을 기준으로 생각해본다면 기존의 개발 콘텐츠에서 ‘IT 교양과 디자인 카테고리를 추가적으로 론칭’하여 새로운 유저의 풀을 만들어내는 스케일의 변화들이 C.C를 늘리는 대표적인 예시가 될 수 있을 것 같습니다.
그리고 C.C를 늘리는 개선작업을 하게 된다면 그에 따라 반응하는 유저풀에 의해 inflow와 churn이 달라지게 됩니다(고객이 긍정적으로 평가하는 좋은 경험이라면요). 그렇기 때문에 서비스의 차원에서의 새로운 경험재를 제공하지 않는상황에서 inflow/churn을 개선하는 작업을 하는것을 점진적이고 '최적화'의 영역으로 바라보는것이고, 서비스 차원에서 새로운 경험재를 제공하는것을 C.C를 늘리는 개선작업이라고 볼 수 있을것 같습니다.
참고로 토스에서는 위의 점진적인 경험 개선을 하는 스케일의 업무는 PM들의 역할이고, C.C를 늘리는 역할을 하는 부분은 PO의 R&R이라고 정의를 하고 업무를 진행하는 것 같더라고요 (아래 링크를 보고 그렇게 파악했습니다).
(위의 링크 관련하여서는) 개인적으로는 PO/PM의 정의를 저는 마티 케이건의 인스파이어드에서 정의하는 기준으로 바라보고 있기 때문에, 정확히 반대로 타이틀을 스위칭해서 바라보고 있습니다. PO/PM의 정의가 아직까지도 시장에서 자리를 잡아가지 못하고 있는 상황이 매우 안타깝고 이렇게 영향력 있는 기업에서 기존 용어의 R&R을 자체적으로 정의하는 것이 시장에 많은 오해와 혼란을 가져오는 것 같아 많이 아쉽기는 하지만... 이번 포스팅의 주제와는 다른 부분이니, 이 주제는 저보다 훨씬 더 친절하고 디테일하게 생각을 공유해주신 도그냥님의 포스팅을 공유하는 것으로 갈음하겠습니다.
https://brunch.co.kr/@windydog/592
