brunch

You can make anything
by writing

C.S.Lewis

by 재주아빠 Oct 27. 2021

진짜 데이터 플레이를 하려면

일곱 단계로 풀어보는 논픽션 같은 픽션

*그동안 여러 회사를 다니며 겪었던 몇몇 경험들을 모아 각색하고 좀 '오바'해서 압축했습니다. 이 모든 문제를 한꺼번에 다 겪는 조직은 드물겠지만, 이 중 하나라도 겪지 않는 조직 또한 하나도 없을 거라 상상하며... 




1. 기초

우리 회사는 드디어 데이터를 수집하고 활용하는 기초 공사를 끝냈습니다. 개발 팀은 서버와 클라이언트로부터 유용할 것이라 기대되는 각종 로그를 수집하고, 데이터 엔지니어링 팀은 매일 추적해야 하는 지표들을 BI 툴에 얹어 대시보드를 구현했습니다. 


분석팀은 주요 지표를 골라 KPI 메일 발송 준비를 하고, 매월 리포팅할 분석 주제들을 골랐습니다. 머신러닝팀은 개인화 추천 모델까지 만들어냈습니다. 마케팅팀은 메시지를 세분화해서 발송할 수 있는 툴을 구매했습니다. 


이렇게 개발팀, 데이터 엔지니어링 팀, 비즈니스 분석팀, 머신러닝팀, 마케팅팀 모두 각자의 임무를 멋지게 해낼 수 있게 파이프라인을 디자인하고 구축했습니다. 


이제 컴퓨터가 매일 같은 시간에 일해주기만 하면 됩니다. 마케팅 팀은 필요한 지표를 골라보며 어떤 활동을 할지 고민할 수 있을 것이라 기대하고, 중요한 안건은 분석팀의 빠르고 명료한 보고서를 통해 의사결정을 내릴 수 있으리라 희망을 갖게 되었습니다. 


글로벌 테크 기업 엔지니어링 블로그에서 한 번쯤 읽었던 '데이터 플레이'를 우리도 해낼 수 있는 모든 준비가 완료되었습니다. 경영진은 이미 데이터 플레이에 꽂혀 있기 때문에 이걸 왜 해야 하는지 설득할 필요도 없습니다.



2. 정체

하지만 생각보다 그 '플레이'가 잘 되지 않습니다. 마케팅 팀은 대시보드를 참조하여 새로운 제품 출시일에 맞춰 캠페인을 기획을 해보려 합니다. 그런데 대시보드에서 볼 수 있는 지표는 사실 사업 목표나 기획 방향과 크게 상관없는 것들이 나열되어 있습니다. 


분석팀은 급한 대로 보고서를 쓰든, 대시보드를 업데이트하든 (암튼 뭐든) 데이터에서 실마리를 찾아야 합니다. 그런데 수집된 로그와 유저 DB를 살펴보니 막상 캠페인에 필요한 항목은 수집되지 않고 있었습니다. 추천 시스템이 만들어낸 결과는 캠페인 활동에 어떻게 써야 할지 아직은 잘 모르겠습니다.


갓 만들어진 데이터와 시스템과 툴을 헤매다가, 다시 마케팅 팀은 레거시 툴과 방식으로 돌아왔습니다. 보고를 받은 경영진은 데이터 기반의 의사결정을 하고 싶다고 다시 강조합니다. '지금 보여주신 것은 다소 정성적인 의견이 아닐까요', 라며 우회적으로 반려합니다. 그동안 돈도 시간도 꽤 많이 썼는데, 뭘 더 해야 할지 잘 모르겠습니다.



3. 병목

도대체 무슨 문제가 있는지 조사했습니다. 서로의 규격이나 맥락을 고려하지 않고 각자 설계한 것이 문제가 되었습니다. 


최초의 로그 설계는 기능이 작동하는 위치를 고려하지 않은 채 수집했습니다. 처음에는 유저들이 게시물에 '좋아요'를 누를 수 있는 경로는 하나뿐이었습니다. 하지만 서비스가 커지면서 '좋아요'를 누를 수 있는 경로가 여기저기 늘어났습니다. 


요즘 유저 수도 꽤 늘었고 리텐션도 증가했는데, 그게 왠지 '좋아요' 때문인 것 같습니다. 그래서 분석팀은 유저가 '어느 단계, 어느 위치'에서 게시물에 반응하는지 확인하려 했지만, 로그에 그 정보는 없었습니다.


머신러닝 팀은 유저를 100개 그룹으로 세분화하여 문자 메시지 문구를 변형할 수 있는 모델을 만들었습니다. 이제 이 모델을 서버에 띄워서 전환율의 극적인 변화를 이끌어낼 수 있다고 장담합니다. 하지만 마케팅 팀은 난처한 표정을 지으며 사용할 수 없다고 답했습니다. 왜냐면 타기팅 메시지를 보내려고 도입한 새로운 플랫폼은 최대 12개 유저 세그먼트를 지원하기 때문입니다. 


게다가 이 모델은 서버 개발팀도 수용하지 못합니다. 최신 딥러닝 기법을 적용한 모델을 전체 유저에게 모두 작동하게 하려면 미리 GPU 서버를 증설했어야 했기 때문입니다. (아니면 유저 세그먼트를 갱신할 때마다 이틀을 기다리든지...)


신제품 출시에 맞춰 마케팅 팀이 노린 핵심 타깃은 '대학교에 갓 입학한 스무 살 여대생'입니다. 그런데 대시보드는 10세 단위로 구분해서 보여주고 있습니다(20대, 30대). 심지어 성별은 구분되어 있지도 않습니다. 


대시보드에 없으니 분석팀에 요청합니다. 분석팀은 KPI 테이블에 요약된 항목 정보가 없으니 다시 유저 데이터베이스를 샅샅이 살핍니다. 그런데 근본적인 문제가 있습니다. 사실 우리 서비스는 가입 단계에서 '귀하의 연령'을 10세 단위로 수집해왔습니다.



4. 파이프

개발, 데이터엔지니어링팀, 분석팀, 머신러닝팀, 마케팅팀 각자의 역할에 충실하게 (심지어 완벽하게) 준비했지만, 파이프라인을 만든 게 아니라 각자의 견고한 '파이프 쇳덩이'를 예쁘게 만든 것이 되고 말았습니다. 데이터 플레이를 하려면 형식적인 주간 미팅만 챙겨서는 안 된다는 것을 조금 뒤늦게 깨달았습니다. 생각했던 것보다 좀 더 많이 밀착해서 이야기하는 것이 필요했습니다.


이제 모든 팀이 다시 테이블에 모여 앉아, 각 팀이 생각한 데이터 플레이가 가능하도록 만들 방법을 논의하기 시작했습니다. 그런데 하나를 풀면 다른 하나가 문제가 되고, 그걸 풀기 위해서는 좀 더 근본적인 방식으로 접근해야 한다는 것에 공감하기 시작했습니다.


딱 이 시점에 누군가 이 모든 것을 가능하도록 최대한 상세하고 많이 데이터를 수집해서 각종 방식으로 쓸 수 있게 미리 가공해두면 되겠다는 쉽고 비싼 아이디어를 내기 시작합니다. 하지만 곧바로 모든 걸 가능하게 미리 준비하는 것이 효과적인가? 정말 맞나? 말은 되는 얘긴가? 아무튼 '플레이'만 되게 하면 사업 성과도 나는가? 하는 당연한 문제에 봉착했습니다.



5. 커플링

서로의 요구를 맞출 수 있는 솔루션을 찾는 것으로 논의가 이어졌습니다. 각자 팀이 내부적으로 완성한 각자의 파이프들을 어떻게 '커플링'할 것인지가 핵심 주제입니다.


(마케팅) 10세 단위 대신 1세 단위로 모아야 합니다 -> (기획) 가입할 때 '생년'을 받는 것으로 하시죠. 기존 유저들은 어쩔 수 없겠죠? -> (머신러닝) 신규 가입자 데이터 좀 쌓이고 나면, 기존 유저들 연령대를 5세 단위로 추정할 수 있을지 테스트는 해볼 수 있겠네요. 근데 그게 우선순위가 높을까요? (사업) 저희 앞으로 커머스 확대할 건데, 성연령 없으면 안 될 거 같아요. 과제 진행될지 검토해주세요


(분석) 모든 기능 버튼마다 위치 값이 있어야 분석이 가능해요 -> (개발) 위치 별로 통계를 보게 되면 어떤 의사결정을 더 할 수 있죠? -> (분석) 사실 업데이트 시점마다 '좋아요' 버튼의 유저 반응이 궁금한 것도 있는데, 반대로 생각해보면 어떤 버전에서 반영되었는지 메타 정보가 더 중요하겠네요. (기획) 위치도 필요하고 메타도 필요할 것 같아요.


(머신러닝) 100가지 유저 그룹으로 세분화하면 좋겠어요 -> (마케팅) 진짜 100개 다 필요한가요? 그 안에서 비슷하거나 거의 같은 고객군으로 묶이는 그룹이 있지 않나요? -> (머신러닝) 한 번 실험해볼 필요가 있겠네요, 12개로 압축했을 때 전환율이 별로 떨어지지 않는지 볼 필요가 있겠어요 -> (사업) 만약 20개 이상 그룹이 효과적이라면 솔루션 회사에 추가로 커스텀 개발이 가능할지 요청해보겠습니다.


(개발) 데이터 수집 요건이든 머신러닝 모델의 크기든, 이걸 다 수용하려면 스토리지 확장도 많이 필요하고 GPU도 더 사야 하는데 좀 오래 기다려야 해요. 당장 반영할 수 있는 방법은 없을까요? -> (머신러닝) 딥러닝 빼고 단순한 모델로도 성능이 나오는지 한번 볼게요. 성능 괜찮으면 첫 번째 모델은 그걸로 가도 될 거 같아요.


(사업) 지금 대시보드에서 볼 수 있는 지표는 30갠데.. 서비스 확장할 때마다 지표도 바로 반영되나요? (데이터 엔지니어링) 어느 정도 가능하긴 한데, 말 그대로 '스케일링' 하려면 KPI 집계 테이블 설계를 한번 손봐야 할 거 같아요 (분석) 손보신 후에 커버하는 지표 리스트를 알려주시면, 저희가 직접 분석해서 리포팅할 주제가 달라질 수 있겠네요. 공유 부탁드립니다.



6. 측정

파이프라인 커플링에 필요한 우선순위 높은 과제들을 모두 완료한 뒤, 다시 캠페인을 기획했습니다. 물론 삐그덕거리는 부분이 있긴 했지만, 기대했던 것보다는 훨씬 매끄럽게 기획과 실행, 분석과 보고가 이루어졌습니다. 여러 팀이 긴밀히 붙어야 하는 데이터 플레이 구조가 제법 물 흐르듯 만들어진 것입니다. 


캠페인 말고 또 어떤 플레이를 할 수 있는지 찾아봤습니다. 새로운 릴리즈 버전마다 컨셉을 잡고 각 기능이 얼마나 유효했는지 측정해보기로 했습니다. 고질적인 버그로 인식되었던 전환 구간마다 앱 또는 시스템 오류로 인한 이탈도 확인하기로 했습니다. 이러한 버그들은 빠르게 대응할 수 있도록 우선순위를 높였습니다. 이외에도 A/B 테스트, 결제화면 이탈 요인, 리뷰영역 노출 순서 조정 등 많은 아이디어가 쏟아졌습니다.


그리고 이 아이디어 회의는 시간이 흐를수록 하나의 질문으로 수렴되었습니다. 


데이터 파이프라인의 성과 기준이 무엇이고 어떻게 측정할 수 있나요? 


이 질문은 결코 대답하기 쉽지 않았습니다. 우리도 OMTM(One Metric That Matter)을 찾아야 한다는 주장, 그런 지표는 환상이라는 반론, 결국 최종 지표는 매출 아니겠냐, 그보다는 순이익이 중요하지 않나요, 글쎄요 유저 트래픽이 제일 중요해 보입니다, 트래픽만 높으면 전부인가, 리텐션이 아무래도 중요하지 등등...


우리 서비스의 시기를 따져봤습니다. 막 창업을 하고 유저를 끌어모으는 시기는 조금 넘긴 상태입니다. 제법 많은 유저들을 모으긴 했지만, K메신저처럼 끌어모은 유저들을 수성할 만큼 안정화된 상태는 아닙니다. 


현재 상황을 이래저래 따져보니 우리에게 당면한 과제는 '온보딩'입니다. 어렵게 데리고 온 유저들을 최소한의 기준으로 서비스에 안착시키는 것입니다. 최근 파격적인 프로모션을 건 덕분에 신규 유저가 3배 이상 늘어났지만, 대부분이 체리 피커였다는 분석이 큰 이슈가 되었기 때문입니다(할인쿠폰만 먹고 돌아오지 않는...).


구글링을 하다 우연히 페이스북의 온보딩 전략을 찾았습니다. '가입 후 7일 내에 10명의 친구를 만들면 진짜 페북 유저'라는 심플한 전략입니다. 우리만의 온보딩 행동 조건을 찾기로 의기투합하고, 총력을 다해 파이프라인을 가동하기로 했습니다. 그리고 캠페인을 하든, 앱을 뜯어고치든, 첫화면을 전면 수정하든, 각 팀의 모든 활동이 온보딩에 얼마나 기여했는지 따져보기로 했습니다.



7. 프레임워크

이제 다시 파이프라인을 점검했습니다. 우리가 애초에 생각했던 그림은 캠페인 효율을 높이는 것에 국한되었던 것 같습니다. 온보딩 전략을 수행하려면 유입되는 유저 단위로 행동을 가입 시점부터 세부 활동까지 추적할 수 있는 데이터 포맷을 새롭게 설계하는 것이 필요하다는 점을 알게 되었습니다.


그래서 모든 유저를 일일이 매일 따라다니며 딱지(태그)를 붙여놓기로 했습니다. 쉽게 풀어서 설명하면 다음과 같은 방식입니다.


'오늘 기준 유저 A는 가입한 지 7일째, 아직 구매는 없었음, 접속은 여러 번 함, 좋아요는 엄청 누르고 다님. 가끔 카톡으로 상품링크 공유도 함' 


이 포맷을 잘 활용하면 트래픽을 보든, 리텐션을 보든, 매출을 보든, 기여도를 보든, 뭐를 보든 비즈니스 분석에 필요한 지표들을 입체적으로 관찰할 수 있는 우리만의 방식을 만들 수 있겠다는 가능성을 확인했습니다. 


지금까지 만들어 온 모든 파이프라인과 데이터를 A4 용지에 간단히 그려봤습니다. 모 글로벌 테크 기업 블로그에서 읽었던 'OOO 프레임워크'와 꽤 비슷하다고 느껴집니다. 레퍼런스를 콕 집어 따라 해 온 일은 아니었는데, 우리만의 정의와 방식을 파헤치다 보니 이렇게 그들과 닮아가는구나 생각도 해봅니다.






'우리는 어떤 플레이를 할 것인지' 이해관계자들이 초기에 함께 논의해야 나중에 전부 뜯어고쳐야 하는 상황을 미리 방지할 수 있습니다. 그렇다고 고층 건물 시공하듯이 모든 설계를 제일 먼저 완료해야 한다는 뜻은 절대 아닙니다. 이를테면, 본문에 나열한 일곱 가지 단계 중 마지막 '프레임워크' 설계부터 시작한다면 서비스가 종료될 때까지 아무것도 할 수 없을지 모릅니다. 


그래서 서비스가 위치한 상황에 맞게, 현재 가능한 리소스 수준에 맞게, 우리가 나아갈 방향에 맞게 지속적인 커뮤니케이션과 단기적인 접근이 동시에 필요합니다. 이 과정에서 CDO(Chief Data Officer), DPM(Data Project Manager), Data Governance 등과 같은 직책과 조직은 이러한 범주의 업무를 고려하여 전반적인 파이프라인과 사업의 목표 사이를 오가며 코디네이션 할 수 있어야 합니다. 


그리고 이 파이프라인에 동참하는 데이터 분석가, 머신러닝 엔지니어, 데이터 엔지니어, 마케터들은 현재 주어진 과제가 어느 맥락에 있는지 잠깐만 주변을 살펴보고 가볍게 이야기를 나눈다면, 불필요한 시행착오를 줄이고 더 쉽고 빠른 방법을 찾을 수 있을거라 기대할 수 있습니다.


이 소설이 현실과 맞닿아 있는 부분도, 또는 드라마 같은 과장도 조금 있겠지만, 재밌게 읽어주셨으면 좋겠습니다 :)

매거진의 이전글 새로울 것 없는 데이터 분석
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari