PM의 입장에서 바라본 데이터 분석 업무
PM인데요, 분석도 합니다 (1)
PM인데요, 분석도 합니다
작은 스타트업에서 프로덕트 매니저이자 (자처해서) 데이터 분석가로 일하고 있다. 첫 스타트업에선 데이터라고 부를 만한 것도 없어 운영상 필요한 데이터를 수집 및 관리하는 체계를 마련해 교육하는 작업부터, 대시보드를 세팅 및 유지보수와 ad-hoc 성격 분석업무를 병행했고, 현재 일하는 곳에선 프로덕트 분석과 A/B 테스트의 설계를 병행하고 있다. (이 밖의 관련된 자잘한 문서 관리는 덤이다.)
이는 '데이터 분석가'라는 직무를 따로 상시 보유할 만큼의 필요가 없는 작은 팀이기 때문이고, 조금 더 자세히 말하자면 기획을 위한 방향 또는 타당성 검토나 실험을 통한 가설의 검증, 프로덕트의 현황 확인, '인사이트'의 발견을 위한 데이터 분석을 다른 누군가가 대신해 줄 수도 없고, 대신하는 게 아직은 비효율적이기 때문이다.
그러다 보니 연말 종무식에서 '취미는 쿼리감'상을 받았다.이처럼 지난 3년간 두 개의 직무 또는 역할을 혼자서 병행하다 보니, 각 직무의 전문성(또는 하드스킬)은 하나에만 집중한 이들보다 상대적으로 부족할 수 있겠지만, 한편으로는 PM의 입장에서 프로덕트 팀의 분석가의 업무를 바라볼 수 있는 동시에 분석가의 입장에서 PM의 업무를 바라보는 기회를 얻을 수 있었다.
분석가의 입장에서 바라본 PM
PM의 입장에서 바라본 분석가
분석가 당사자의 입장
PM 당사자의 입장
물론 위의 네 가지 시나리오에서 이야기하는 PM과 분석가가 모두 결국 '나'라는 동일 인물이지만, 혼자서 두 개의 직무를 병행하며 품은 소회가, 각각의 역할을 담당하는 두 사람이 서로에게 느끼는 것과 크게 다르지 않을 것만 같다.
그래서 이번 글에서는 cross-functional 하게 일하는 프로덕트 팀에서 PM으로서의 내가 분석가로서의 나를 제3자의 관점에서 바라보며 느낀 점과 프로덕트 팀에서의 분석 업무에 대해 적어보고자 한다.
1. 숫자나 쿼리에 탐닉하지 말자
제너럴리스트인 PM은-그게 프로덕트 매니저든, 프로젝트 매니저든- 하나의 업무 task 또는 사항에 오래 몰두할 시간이 없다. 기획을 하다가 분석을 하고, 프로젝트 설계를 하다가, 다른 프로젝트의 막바지 QA에 참여하고, 고객 인터뷰를 하다가 VoC에 급히 대응한다. 그게 PM의 기쁨이자 슬픔, 묘미이자 한계다. 그래서 PM으로서의 나는 최대한 필요한 때에, 필요한 만큼만 생각하거나 정리하려고 노력한다.
반면 분석가로서의 나는 종종 숫자와 쿼리 그 자체에 빠져든다. 분명 문제를 정의하고, 이슈트리를 그려 세부적으로 살펴봐야 할 가설과 이에 따른 지표, 방법들을 설계하지만 어느새 처음의 계획과는 다른 숫자를 들여다보고 있거나, 대뜸 충동적으로 쿼리를 작성하고 있다.
분석을 하다 보면 어느새 처음의 예상과 다른 숫자, 쿼리 속에서 헤매는 자신을 발견하게 된다. (이미지 출처 : https://www.meme-arsenal.com/)또는 짧고 간단한 쿼리를 통해 빠르게 설계해서 조회할 수 있음에도 불구하고, 멋들어지고 보기에 좋은 쿼리를 고집하며 쿼리 작성과 조회에 시간을 들이게 되는 경우도 종종 발생한다.
물론 대시보드 등의 형태로 내/외부 고객에게 일종의 제품으로서 제공되어야 하는 쿼리라면 재사용성과 가독성, 조회 속도 등이 중요하겠지만 프로덕트와 사용자에 대한 가설을 검증하기 위한 분석은 대부분 ad-hoc 성격의 분석이다. 그럼에도 불구하고 더 좋은 쿼리, 더 그럴싸한 쿼리의 구조를 고민하고 있는 스스로를 발견하곤 한다.
만약 내가 PM이 아니었더라면, 혹은 업무의 목적과 배경, 들이는 노력 대비 발생하는 효과에 대한 감을 잡지 않았다면 혹시 너무 애먼 곳으로 향하고 있진 않았을까? 분석의 배경과 목적을 잊고 숫자나 쿼리 그 자체에 흠뻑 빠져들어 머나먼 바다를 항해하고 있진 않았을까?
프로덕트 팀에서 이제 막 분석 업무를 시작한 신입 분석가라면, 새로 배운 쿼리나 새로 접근하게 된 DB, 아름답고 멋진 쿼리 그 자체에 빠져있기보단 분석의 배경과 목적, 다시 말해 애초에 이 분석을 통해 확인해야 할 사항과 답을 구해야 할 질문이 무엇인지를 잊지 않는 게 중요할 것 같다.
(그런데 역설적이게도 이렇게 두서없이 놀아보며 논리를 설계하고 엑셀의 함수든 SQL의 쿼리를 짜보는 시간이 장기적으로는 숫자를 해석하는 감각과, 쿼리를 작성하는 실력을 키우는 것 같다...ㅎㅎ)
2. 어쩌면 분석가의 퍼포먼스는 기술이 아니라 속도
애초에 프로덕트 팀에 분석가가 함께 하는 이유는 무엇일까? 숫자를 보기 위해서? GA, Amplitude 등의 툴로 슥슥 보기에 어려운 DB 속 데이터를 SQL을 활용해 대신 뽑아줄 사람이 필요해서? 그럼 DB에서 데이터를 뽑아 이를 숫자로 바꾸는 일은 애초에 왜 하는 걸까?
데이터(또는 숫자)를 보는 이유는 기획 또는 의사결정의 불확실성을 조금이나마 줄이기 위함이다. 가설 혹은 속된 표현으로 '뇌피셜'이라고 부르는 영역을 실제 고객이 남긴 행동 데이터와 각종 데이터를 통해 근거를 더하고, 내 의사결정의 확신의 정도 level of confidence를 높이기 위함이다. 그리고 스타트업 또는 프로덕트 팀의 의사결정의 상당수는 제법 빠른 탬포로 이루어진다.
그렇다면 이런 의사결정을 지원하기 위한 분석은 어디에 방점이 찍혀야 할까? 쿼리의 정확성 또는 안정성? 숫자를 도출하기까지 고려한 수많은 논리적 조건과 전제들의 정합성? 수학적 사고와 최신의 통계적 방법론? 물론 분석가의 하드스킬과 지식, 회사의 데이터 자원에 대한 신뢰는 당연히 필요하지만, '팀의 분석가'로서는 결국 팀의 의사결정에 영향을 줄 수 있을 만큼의 속도가 중요하지 않을까? 즉, 분석가의 퍼포먼스는 적시에 PM을 비롯한 이해관계자들의 의사결정을 지원할 수 있는 역량에 달려있는 것 아닐까?
현재 있는 회사의 대표님과의 논의 때마다 종종 놀라곤 한다. PM인 동시에 분석가로서 업무 하는 나는 제법 숫자에 기민하고 분석 업무를 좋아한다고 생각하지만, 주요 지표의 현황을 보기 위해선 때로 분석 툴을 다시 열거나, 기존 자료를 다시 열어봐야만 한다. 그러나 대표님은 머뭇거림도 없이 얼추 근사치에 해당하는 숫자를 떠올리고는 이를 바탕으로 논의를 이어간다. 숫자를 다 외우고 계시냐는 나의 물음에, 대표님의 답변은 간단했다. "그래야 의사결정이 빨라지니까."
그래야 의사결정이 빨라지니까
물론 어떤 의사결정은 그런 기억 속 근사치를 토대로 이어가기엔 부적절할지도 모른다. 그러나 최소한 '얼추 이 정도다'라는 걸 기억하는 사람과, 백지에서 시작해야 하는 사람 사이의 의사결정의 속도는 다를 수밖에 없다.
그래서 프로덕트 팀에서 바라보는 좋은 분석가란, 숫자와 쿼리에 빠져있는 대신 적시에 팀의 의사결정을 지원하고 질문에 답을 줄 수 있을 정도로 자신의 업무 흐름을 따라가고, 어쩌면 분석 없이도 바로 주요 숫자를 상기시켜 줄 수 있는 '책사'에 가까운 사람은 아닐까?
(물론 이러기 위해선 결국 평소에 숫자를 탐닉하고 쿼리 등 분석 기술을 손에 익혀둬야 한다ㅎㅎ....)
특히 PM이 분석을 겸하는 때에는 자신이 궁금한 걸 자신이 직접 찾아보면 되지만, PM과 분석가의 업무가 나뉘게 되는 시점에는, 분서가가 팀의 템포를 따라가지 못해 병목이 되는 경우가 생길 수 있다고 생각한다. (이 관점에서 느낀 것들은 분석가로서 바라본 PM에 대한 글에서 적어보고자 한다.)
3. 100%란 없다. 우리는 우주항공 과학자가 아니다.
빅테크의 데이터 엔지니어링이나 사이언스, 또는 로켓을 쏘아 올리는 우주항공과학이나 한 나라의 정책의 방향을 판단하는 영역에선 분명 데이터와 분석의 정합성은 매우 중요할 것이다. 그러나 일반적인 수준에서라면, 혹은 이제 막 시작한 단계에서라면, 분석가의 업무에 이 정도의 수준이 필요할까?
애초에 기획의 확신의 정도 level of confidence를 높임으로써 의사결정을 지원하기 위한 분석이라면, 100%란 없지 않을까. 기술적인 차원을 제외하고서라도, 100% 확신할 만큼 분석을 했다고 생각했을 때엔 이미 내외부의 상황이 모두 바뀌고, 데이터는 시효성을 잃었을 테니까.
우리의 업무는 파레토의 법칙을 따른다고 생각한다. 80% 수준의 완성도를 갖추기 위해 필요한 자원과, 나머지 20%를 마저 채우기 위해 필요한 자원의 양과 질은 분명 다르다. 80% 수준의 완성도를 갖추기 위해서는 전체 자원의 20%만 필요한 반면, 나머지 20%의 완성도를 채우기 위해 나머지 80%의 자원이 필요하다.
초반 80%의 완성도에는 20%의 노력만 필요하다. 그런데 나머지 20%의 완성도를 채우려면 나머지 80%의 노력이 필요하다. (이미지 출처: 본인)따라서 100% 정확한 데이터를 바탕으로 모든 변수와 전제를 고려한 100% 완벽한 분석을 하기 위해 기술 자원과 스스로의 자원을 사용하는 대신, 과연 이 의사결정을 위해서는 어느 정도 수준의 그림이 필요할까? 를 먼저 생각해 보는 게 필요하다고 생각한다.
실제로 사업개발, 운영, 리더십 등에서 요청하는 분석 가운데에는 파고들기 시작하면 한없이 까다로워지는 요청이 있다. 예컨대 지난 한 해 유저들의 관심사 순위 변동을 요청받은 적이 있는데, 서비스에 유저들이 남기는 관심사는 모두 주관식 데이터다. 누구에겐 마케팅이고 누구에겐 퍼포먼스 마케팅이고, 누구에겐 마케터고, 누구에겐 마켓팅 또는 marketing인 식이다. 수십, 수백만 유저가 남긴 이러한 데이터를 모두 전처리하고 분류해서 순위가 어떻게 변동되는지 알 수 있을까? 적어도 그건 나의 능력 밖이다. 그런데, 정말 그게 필요할까?
요청한 이가 정말로 필요로 한 데이터는 제안서를 작성하는데 '적당히 감을 잡을 수 있을 정도'였다. 즉, 깔끔히 분류되지 않는 소수의 데이터는 과감히 포기하거나, 몇 가지 전제나 추정을 더해 눙쳐도 되는 수준이었다.
물론 팀이 커질수록, 리스크가 커질수록 데이터의 정합성은 중요해지고, 필요한 만큼의 기술과 자원을 할당해야 할 것이다. 그러나 이러한 조직에서도, 분석가가 하는 모든 분석이 매번 100%를 지향해야 할까? 질문에 답이 될 만큼, 문제를 해결할 만큼, 팀의 의사결정을 적시에 지원할 수 있을 만큼이 필요한 건 아닐까? 만약 매 순간 100%를 지향한다면, 그건 과대적합 overfitting은 아닐까?
4. 분석가의 커뮤니케이션이 개발자처럼 어려워선 안된다
우선 소제목에 편견에 가까운 전제가 섞여 있다는 점에 양해를 구한다. '개발자의 이야기는 어렵다'라는 전제인데, 그렇지만 IT 조직에서 개발자들과 긴밀히 일하는 주니어 기획자/PM 또는 기타 이해관계자라면 '개발자의 이야기는 어렵다'라는 어떤 느낌인지 와닿을 것이라 생각한다.
스크럼 scrum에서 일이 안 되는 이유, 일이 예상과 다르게 흘러가는 이유에 대해서 공유하다 보면 운영, 마케팅, 기획, 사업개발의 이야기는 해당 직무를 수행하지 않는 다른 이들도 대부분 이해할 수 있는 반면, 어떤 개발자의 이야기는 도저히 이해가 되지 않는 경우가 있다. 이는 자신의 일을 타인의 관점에서 추상화 또는 관념화하여 설명하지 못하고 기술 용어 그 자체를 이용해 설명하기 때문인데, 이 경우 개발자 본인은 팀원들이 자신의 업무를 이해하지 못하고, 이해하려는 노력을 하지 않는다며 서운해하고, 나머지 팀원은 해당 개발자가 커뮤니케이션을 잘하지 못한다고 생각하게 된다.
그런데 기술이야 어느 정도 '그런가 보다' 또는 '그런 게 있나 보다'하고 넘어갈 수 있는 지점이 있지만, PM과 리더십, 기타 이해관계자의 의사결정을 지원하고 설득하기 위한 분석가의 이야기가 개발자의 이야기처럼 어렵다면 어떨까? 과연 의사결정에 도움이 될까?
나는 개발을 모른다. 그러나 분석을 하고 있는 입장에서, 데이터에 관한 이야기도 한없이 어려워질 수 있는 가능성이 있다는 건 알고 있다. 하나의 숫자를 도출하는 데에는 수많은 전제가 필요하기 때문이다. 가령 '신규 고객의 리텐션이 궁금해요'라는 질문에는, '신규'에 대한 정의와(예: 22년 4분기) '고객'에 대한 정의와(예: A상품을 N회 이상 구매 후 환불하지 않은 사용자) '리텐션'에 대한 정의가 숨어있다.(예: A상품 구매 후 B페이지에 방문한 행위를 기준으로 주 week 단위로 계산)
이뿐만이 아니다. 이러한 데이터가 실질적으로 DB에 쌓이는 시점은 어떻고, 이 시점에 어떤 오류가 있어 실제로 데이터가 실수로 반대로 쌓인 이슈도 있고, 우리 고객 세그먼트를 저렇게 정의한 이유는 어떻고 등등... 하나의 숫자를 뽑아내기 위해 필요한 모든 정의와 조건이 메시지 뒤에 숨은 전제다. 그 숫자가 의미하는 바는 그 전제를 무시하고서는 성립하지 않는다.
그러나 분석의 결과를 전달받는 동료와 리더십이 과연 이러한 복합다단한 전제에 대한 정보를 필요로 할까? 이러한 전제에 대한 설명이 항상 의사결정을 도울까?
분석가의 사수 역할을 해주거나 품의 데이터에 대해 충분한 이해나 경험이 있는 PM이나 리더십이라면, '어떤 조건으로 뽑았는지?'같은 질문을 때로 할 수도 있다. 분석가가 본인만큼 충분히 다양한 전제와 조건을 살펴보지 못했을 수도 있고, 혹은 분석을 보고받는 입장에서 필요한 전제 조건이 분석가가 생각한 것과 다를 수도 있으니까. 그러나 이 역시 어디까지나 한정적이다.
논리의 영역일 다루는 이들에겐 명확한 정의와 전제가 필수적이다. 그건 좋은 분석과 추론을 하기 위한 필수 조건이다. 그러나 커뮤니케이션의 장에서 그 모든 정의와 전제를 모두 깔아놓는 것은 별개의 이야기다. 좋은 개발자가 PM에게 모든 기술 이슈를 일일이 설명하지 않거나, 혹여 설명하더라도 PM이 이해할 수 있는 방식으로 비유하려 하듯이, 분석가 역시 정의와 전제에 대한 설명은 필요한 때에, 필요한 수준에서 해야 한다고 생각한다. 그렇지 않으면 분석가의 이야기가 개발자의 이야기만큼이나 어려워질 테니까.
5. 개떡 같아도 찰떡같이 해석해야 한다
분석을 하는 당사자 입장에선 가장 서글픈(또는 분노가 치밀어 오르는) 주장이 아닐까 싶다. 종종 이런 일로 분개하는 분석가분들의 한탄 섞인 글 또는 에피소드를 듣기도 한다. 애초에 개떡같이 말한 놈이 잘못이지, 개떡같이 말해도 찰떡같이 해석해줘야 한다니.
그런데 PM이자 분석가로서 데이터를 요청하는 입장이자 요청받는 입장으로서 3년 정도 일을 해보니, 어째서 리더십과 다른 동료들이 이른바 '개떡같이' 요청을 하는지 그 맥락과 배경을 비로소 이해하게 되었다.
사내 세션에서 공유한 자료 중 일부. 개떡같이 줘도 찰떡같이 해주겠다고 공표한 셈이다(ㅎㅎ...) (이미지 출처: 본인)1) 대부분의 경우 요청하는 사람도 자기가 정말로 궁금한 게 무엇인지 잘 모른다
연차와 직무, 직급을 막론하고 사람이라면 누구나 처음에 떠올리는 생각이나 질문은 다소 두리뭉실하다. 정의되지 않은 용어, 이곳저곳으로 이동하는 사고의 흐름을 정리하는 데에는 시간이 필요하다. 또는 주니어 레벨에서는 자신의 질문과 생각을 정리하는 일이 필요하다는 사실조차 모르는 경우도 상당수다. 그리고 이런 모든 이들이 분석가에게 데이터와 관련된 질문(요청)을 던진다.
2) 우리 제품/서비스에 어떤 데이터가 있는지 모른다
그런데 자신의 질문과 생각을 정의하는 일이 순도 100% 연역적으로 가능한 일일까? 제품과 서비스에서 대략적으로나마 어떤 데이터를 취급하는지 모르는 상황에서 던지는 질문은 아무리 잘 정의되어 있다 하더라도 '그런 데이터는 없는데요'같은 답변을 듣게 될지도 모른다. 그리고 분석가나 데이터 엔지니어가 아닌 이상, 제품과 서비스에 어떤 데이터가 존재하는지, 어떤 데이터를 들여다볼 수 있는지를 아는 사람은 드물다.
3) 우리 제품/서비스의 데이터가 어떤 조건으로, 언제, 어떻게 수집되는지 모른다
대략 어떤 데이터가 있는지를 안다고 가정해 보자. 그런데 분석가의 입장에서는 분석을 위해 데이터가 쌓이는 조건까지 신경 쓰지만, 데이터와 관련된 직무가 아닌 이상 과연 그런 걸 알 수 있을까? 알아야 할까? 결국 분석에 필요한 명확한 조건과 정의, 전제는 다른 사람이 아무리 잘한다고 할지라도 분석가가 하는 만큼은 되지 못한다.
4) 다 아는데 너무 바쁘다. 그리고 당신을 그만큼 믿고 있다
만약 분석가가 PM 또는 리더가 되었다고 생각해 보자. 그는 분명 제품과 서비스에 어떤 데이터가 있고, 이것이 언제 어떻게 쌓이는지도 알고 있을 것이다. 그런데도 그의 질문과 요청은 두리뭉실하다. 왜냐하면 그런 걸 신경 쓰는 건 더 이상 그의 역할이 아니니까. 그에게 깊이 고민할 시간이 있다면 그 시간은 제품과 비즈니스의 방향에 쓰여야 하지, 분석가를 하던 시절처럼 쿼리 작성을 위해 자세한 정의와 조건을 정리해 요청하는 데 쓰여서는 안 된다. 그리고 한때 자신이 하던 그 역할을 믿고 맡길 분석가를 찾은 것이다.
결국 이런 맥락과 배경에서, 분석가가 아닌 사람의 분석 요청은 늘 분석가 자신의 기대치에 비해 상대적으로 '개떡 같을' 수밖에 없다.
그런데 애초에 그 개떡 같은 질문을 찰떡같은 질문으로 재정의해 결과를 가져다주는 것이 분석가의 역할이자 가치 value인건 아닐까? 기획자의 설계가 엉성해도 디자이너의 손에서 더욱 발전된 UX가 설계되는 것처럼, PM이 고려하지 않은 엣지 케이스 edge case 에 대해서도 개발자가 찰떡같이 고려한 것처럼, 때로 개발자의 커뮤니케이션이 복잡하고 어려워도 PM이 찰떡같이 해석하고 이해하는 것처럼.
사실 우리는 모두 서로의 개떡을 찰떡으로 빚어내며 자신의 역할을 다하고, 팀과 제품에 가치 value를 더하고 있는 건 아닐까? 그렇다면 개떡 같은 질문을 찰떡가이 해석하는 건 분석가의 슬프지만 당연한 업무 task 중 하나라고 볼 순 없을까?
이렇게 PM이자 분석가로서 일하며 나 스스로의 분석 업무를 PM의 입장에서 바라보며 느낀 소회를 적어보았다. 결국 프로덕트팀과 PM의 입장에서 필요한 분석가 또는 분석이란 무엇인가, 혹은 어떠해야 하는가, 에 대한 이야기인데, 이어지는 글에서는 공평하게(?) 분석가의 입장에서 PM 또는 프로덕트팀을 바라보며 느낀 점을 적어보고자 한다.
