brunch

라이킷 10 댓글 2

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 라프 Oct 03. 2022

사회초년생은 좌절할 시간이 없어요 EP2-2

'CC, 운영체제/유입채널 별 삭제율을 분석하느라'

팀에 합류한 지 약 2,3 주가 지났을 때, 대표님께서 기획 챕터 팀원과 함께 분석을 하나 요청하셨다.

바로 최근 PM/PO 사이에서 큰 화제가 되었던 토스 이승건 대표의 Carrying Capacity(이하 CC)에 대한 것이었다.

https://www.youtube.com/watch?v=tcrr2QiXt9M

토스 이승건 대표의 PO 세션 유튜브

간단하게 CC는 '한계 수용력'이라고 말할 수 있다.

출처: https://www.neenopal.com/Understanding-Customer-churn.html

위의 사진과 같이 양동이 안 물의 양은 수도꼭지에서 흘러나오는 물의 양과 나가는 물의 양에 따라 결정된다. 이 물의 양이 Carrying Capacity이자 한계 수용 능력이다.

양동이 안 물 양 = 월 활성 사용자 (MAU)

수도꼭지에서 흘러나오는 물의 양 (Inflow) = 새로 유입되는 유저 수 (기간은 자율적으로 설정 가능)

흘러 나가는 물의 양 (Churn) = MAU 중 나가는 비율

결국 CC는 현재 서비스가 현재 유입과 유출을 유지할 때 도달할 수 있는 사용자 수의 최대치이다.

CC = Daily new customer(#) / Daily lost customer(%)

대표님은 현재 수준에서 도달 가능한 최대 수준의 사용자 풀에 대해서 대략적으로 알고 싶어 하셨고, 이에 더해서 각 운영 체제 그리고 유입 채널 별 사용자의 가치에 대해서 알아보고 싶다고 하셨다.

우선적으로 CC를 계산하기 위해선 위에서 설명한 2가지 개념에 해당하는 수치가 필요하다. 첫 번째는 유입, 그리고 두 번째는 이탈. 합류한 지 채 1달도 되지 않았기 때문에 사실 회사에서 사용하고 있는 데이터에 대한 명확한 이해가 없는 상태였다. 따라서 대표님께서 각 유입과 유출에 대한 정의를 내려주셨다. 유입은 단순하게 수집하는 수치 그 자체로 사용할 수 있었지만, 유출은 추가적인 계산이 필요했다.

유출에 대한 정의는 각 팀마다 다를 것이다. 처음으로 계산해보는 CC였기 때문에 우리는 유출을 '이탈'이라고 가장 명확하게 말할 수 있는 '앱 삭제율'로 지정했다. 문제는 앱스토어나 구글 플레이에서 제공해주는 앱 삭제율은 여기에 활용하기에 부정확하다는 점이었다.

CC를 계산하기 위해서는 당일 삭제율을 알아야 하지만 각 스토어에서 제공하는 삭제는 당일 설치 중 삭제와 이전 기간 누적 설치 중 삭제로 이루어져 있었다. 각 유저에 대한 트레킹은 불가능한 상태였기 때문에 나는 전체 삭제 건수가 당일 설치와 누적 설치 각각의 요소에 얼마 나의 영향을 받는지에 대한 파악이 먼저 필요했다. 대표님께서 제시해주신 방법은 바로 '회귀분석'이었다. (방법론적인 부분은 다음에 추가로 이야기하도록 하겠다.) 데이터 소스와 대략적인 방법에 대한 설명을 듣고 본격적으로 분석을 시작하였다.

분명 설명을 들었고, 이해가 되었고, 회귀분석도 해보았는데 자리에 앉자마자 머리가 새하얘졌다. 정말 아무것도 모르겠다는 생각만 들었다. 지금 생각해보면 그럴 수밖에 없었다. 데이터 자체에 대한 인지도 부족하지만 결국 내가 어떤 것에 대해 알고 싶은 건지에 대한 기본적인 이해도 안 되어있는 상태였기 때문이다. 이리저리 데이터만 뒤적거리다 퇴근을 했던 기억이 난다. 다음날에는 전체 삭제수와 운영체제 별 삭제 건수만 분리하여 회귀분석을 돌려보기도 했다. 하지만 당연하게도 각 운영체제 별로 삭제율에 기여하는 정도는 100%라는 말도 안 되는 (하지만 분석 자체를 잘못했기 때문에 수치는 맞은) 결과만 나왔다.

분석을 처음 시작하던 나

나는 결국 고민하다 다시 대표님에게 미팅을 요청하였고, 조금 더 많은 정보를 물어보고 알 수 있게 되었다. 처음에 내가 부족했던 부분은 당일 설치에 따른 삭제와 누적 설치에 따른 삭제에 대한 것이었다. 당일에 발생하는 삭제에는 루트가 2가지가 있다는 것을 알게 되었고, 결국 2가지 루트가 발생하는 삭제 건수에 얼마만큼의 영향력을 끼치는 지를 알아내야 했다는 것을 알게 되었다.

데이터를 1차로 정리하고, 뚝딱뚝딱 분석을 돌려보았다. 처음에는 운영체제를 분리하지 않고 분석해보았지만 각 요인에 대한 신뢰도가 낮았다. 이에서 얻을 수 있는 하나의 인사이트는 운영 체제 간 다운로드와 삭제가 타 운영 체제 다운로드 및 삭제에 영향을 주지 않는 분리된 요소라는 것이었다. 따라서 운영체제를 분리해서 추가적인 분석을 진행했다. 그리고 마침내 CC를 계산해서 분석 결과 문서를 작성하였다. 그 결과를 토대로 대표님과 한 번 더 미팅을 진행하였다.

결과는 설정의 오류로 인한 추가 분석이 필요하다는 것이었다. 일자 끝에 기록된 누적 설치수는 일자 시작 시 설치 수에 당일 다운로드가 된 숫자임으로 기본적으로 사용하는 일자 끝에 기록돼 수치는 누적과 당일 다운로드에 대한 두 가지 요소가 중복 집계된다는 문제점이 있었다. 결국 분석은 다시 진행이 되어야 했다. 이 미팅을 하면서 이 피드백을 나는 합류 후 가장 큰 좌절감을 느꼈던 것 같다.

'미리 말해주었더라면... 왜 이제야 이걸 말해주는 걸까? 내가 더 확실하게 질문을 했었더라면...' 등등 정말 많은 생각이 들었다. 엄청난 시간을 들이고 신경을 써서 진행한 분석이 쓸모가 없어진 느낌에 그 간의 나의 노력이 물거품이 되는 느낌을 받았다. 그렇지만, 제목대로 좌절할 시간이 많지 않았다. 우선은 내가 맡은 이 일을 끝까지 책임지고 해내야 한다는 생각이 들었다.

다시 정신을 차리고 분석을 진행했다. 마지막으로 데이터를 확인하고, 다시 회귀분석을 진행하고, 신뢰도를 체크하고, 결과를 작성했다. 분기별 최종 CC와 함께 마지막으로 대표님께 분석 결과를 전달해드렸다. 그리고는 비슷하지만 또 다른 분석인 유입채널 별 삭제율 분석을 요청해주셨다.

또 한 번 힘겨운 분석을 진행하고 팀원들께 공유드릴 자료를 바탕으로 정말 최종적으로 대표님께 그 간의 분석에 대해 전달해드렸다. 약 2주 정도의 기간이었고 분석에만 온전히 절반 이상의 시간을 쏟았다고 생각한다.

많은 것들을 배웠다. 데이터 자체의 이해도는 말도 할 수 없을 정도로 올라갔고, 정확하지는 않지만 서비스 자체의 CC나 각 요소들의 삭제율에 대한 영향력 등 이전에는 팀 차원에서 알고 있지 않았던 중요한 수치들을 하나 둘 알 수 있었다. 실제 분석 결과를 작성하면서 전달하는 내용에 대해서 잘 설명하고 풀어쓰는 방법도 학습을 했고, 이해도가 낮은 팀원에게 잘 설명할 수 있는 방법에 대해서도 고민하게 되었다.

분석을 완료하고 난 내 모습...

이런저런 이야기를 대표님과 하다가 대표님의 3가지 피드백을 마지막으로 분석은 끝이 났다. 하지만, 피드백은 참 가치 있는 이야기이기도 했지만 나에게는 다소 아픈 말들이었다.

첫 번째 피드백은 '왜?'에 대한 질문이 충분치 않다는 점이었다. 나는 당연스럽게도 이 분석을 '대표님께서 요청했으니까' 해야 한다고 생각했다. 하지만 우리 팀의 문화는 자율적으로 할 일을 찾고 실제로 그 일이 왜 실행되어야 하는지에 대한 물음을 기반으로 일을 진행했다. 온보딩 당시에는 내가 적극적으로 일을 찾아 할 수 없는 환경이었기 때문에 대표님께서 일을 요청하셨지만, 그 일에 대한 중요도를 내가 직접 물어보지 않았다. 그렇기 때문에 분석을 진행하는 데에 있어서 큰 어려움, 많은 시간과 시행착오가 있었다. 분석을 진행하기 이전에 내가 나 스스로에게 'CC가 왜 중요한 거지? CC를 알려면 어떤 게 필요하지?'라는 물음을 던질 수 있었다면 그간의 과정은 훨씬 명쾌했을 것이다.

두 번째는 'move fast'와 'deep dive'의 밸런스를 맞추지 못한다는 점이었다. 나는 완벽주의 성향이 있다. 따라서 하나를 완벽하게 마무리해야 한다는 생각 때문에 고집스럽게 하나에 매달린다. 이게 좋은 점으로 작용할 때도 있지만, 사실 그렇지 않을 때도 있다. Deep dive를 하는 건 좋지만 그게 일정 수준에서 답을 얻을 수 있다면 더 이상의 리소스 사용은 나 그리고 팀 차원에서의 낭비였다. 따라서 무작정 move fast 하기 전에 방법에 대한 고민을 추가적으로 더 하고 근본적인 원인이나 질문에 대한 답을 쉽게 찾을 수 있는 고민도 필요했다. 나는 다만 대표님께서 예시로 언급하신 회귀분석만을 사용하려고 했고, 왜? 에 대한 질문을 내가 할 수 있었다면 회귀분석이 아니라 각 삭제율을 혹은 각 운영 체제나 유입 채널 별 사용자의 가치를 알 수 있는 더욱 간단한 방법에 대한 고민을 우선 시작했을 것이다. 또한 과도한 deep dive로 인해 사실 전체 팀원들에게는 전달하기에 너무 어려운 수준의 내용이 되어버린 점도 있었다.

세 번째는 한정적인 시각을 가지고 있다는 점이었다. 앞서 말했듯이 나는 대표님이 말씀하신 그 방법과 결과에만 초점을 맞추었다. 너무 많은 시간이 사용된다 싶으면 과감하게 다른 대안에 대한 고민을 할 수 있어야 한다는 이야기도 들었다.

피드백을 듣고 난 후의 내 모습...

사실 이 뼈아픈 경험 때문에 지금의 나는 일한 지 6개월 치고는 정말 효율적으로 일을 하고 있다고 생각한다. 그러지만 이 경험 자체가 긍정적이지는 못했다. '좌절감'을 많이 맛보았다. 내가 사용했던, 투자했던, 노력했던 그 시간에 대한 긍정적인 코멘트가 없었고, 내가 그 과정을 진행하는 동안의 부족했던 점에 대한 피드백만 들었다. 물론 대표님께서 그런 과정에 대한 인지가 없는 것은 아니지만 그걸 전해 듣지 못한 나에게는 그간의 노력이 필요가 없는 것인가? 하는 그런 생각에 빠져들게 되었다. 또한 중간에 조금 더 일찍 그런 피드백을 주셨더라면,,, 하는 아쉬움도 있다. (나중에 이야기하면서 알게 된 사실이지만 이게 당시의 대표님의 커뮤니케이션 스타일이었고, 그래서 그에 대한 나의 의견과 생각도 충분히 전달드렸다. )

그래도 이렇게 한 번 기억에 남는 경험을 했기 때문에 더 빨리, 그리고 크게 성장하고 있다고 생각한다. 합류하고 처음으로 느껴본 쓰디쓴 좌절감이지만, 또 이어지는 업무들을 해야 했기 때문에 좌절감을 오래 느낀 시간이 없었다.

이 편을 마지막으로 나의 온보딩 이야기는 끝이 났다.

앞으로는 신입 서비스 기획자로서 기능을 기획하는 이야기, 그리고 쫌 쫌 따리 이것저것 일을 하며 배워본 것에 대해 말해보려고 한다!

사회초년생은 좌절할 시간이 없어요.

다음 시간에 계속!

https://www.youtube.com/watch?v=BO1XLNqz4no