'데이터 분석가'는 언제 필요할까
PM인데요, 분석도 합니다 (2)
Previously...
앞선 글 <PM의 입장에서 바라본 데이터 분석 업무>에서는 작은 팀에서 PM인 동시에 프로덕트 팀의 데이터 분석 업무를 병행하며 PM의 입장에서 바라본 데이터 분석가의 업무에 대해 느낀 점을 적어보았다.
1. 숫자나 쿼리에 탐닉하지 말자
2. 어쩌면 분석가의 퍼포먼스는 기술이 아니라 속도
3. 100%란 없다. 우리는 우주항공 과학자가 아니다
4. 분석가의 커뮤니케이션이 개발자처럼 어려워선 안된다
5. 개떡 같아도 찰떡같이 해석해야 한다
그간 50명 내외의 시리즈A 이후 시리즈 B 이전의 조직에서 운영관리, 데이터분석, 기획, 프로덕트 매니징 등의 역할을 해왔지만, 데이터 팀이 따로 구성된 조직에서 업무를 한 경험은 없다. 그래서 데이터 엔지니어를 비롯해 '데이터 팀'이 꾸려지는 계기나 이에 대한 경험, 효율적인 방법 등은 알지 못한다.
그러나 부동산 개발, 운영을 바탕으로 한 오프라인 비즈니스와 온라인 비즈니스, 10명 남짓했던 조직이 50명으로 성장하던 시기와, 이미 50명 정도의 구성원이 갖춰진 팀으로의 합류 경험, 그리고 각각의 조직에서 데이터 분석 업무를 한 경험을 돌이켜보고 또 비교해 보니, 조직에 '데이터 분석가'가 필요해지는 시점에 대한 나름의 경험과 견해를 갖게 되었다.
따라서 이번 글에서는 별도의 '데이터 분서가'가 존재하지 않는 작은 조직에서, '데이터 분석가'가 별도로 필요해지는 시기에 대한 나름의 생각을 정리해 공유하고자 한다. 그리고 이를 바탕으로 이어지는 다음 글에서는 그러한 팀의 데이터 분석가로서 바라보는 분석 업무와, 프로덕트 팀과 조직의 데이터 문화에 대한 생각을 정리하고자 한다.
조직이 성장하며 직무는 세분화된다
애초부터 직무가 모두 세분화되어 있을 만큼의 규모의 조직에 합류했거나, 뭐가 되었든 조직이 양과 질적으로 성장하며 조직 구성원의 직무나 역할이 바뀌는 모습을 바라본 경험이 없는 이들에게는 다소 낯선 이야기가 될 것 같다. 가령 직무 변화를 퇴사의 시그널로 바라보는 곳이 있는가 하면, 직무나 역할의 변화를 팀장과 인사팀과의 여러 차례 면담을 통해서만 진행할 수 있는 곳이 있으니까.
반면 창업자와 그 주변인에서 시작해 10명 남짓, 50명 남짓, 100명 남짓한 규모로 성장해 나가며 조직 구성원의 확장과 변화를 경험하는 스타트업에선 구성원들의 직무 변화나 역할 변화는 상대적으로 흔하고 또 자연스러운 일이다.
일반적인 웹/앱을 통해 서비스를 제공하는 IT 스타트업이라고 가정해 보자. 팀에 PM 또는 PO는 언제 생겨날까? PM 또는 PO는 팀의 시작과 함께 생겨난다. 왜냐하면 창업자 본인 또는 창업자와 공동창업자 모두가 제품의 A-Z에 관여하니까. 제품과 조직의 초기엔 창업자가 대표인 동시에 PM/PO로서 제품의 Why와 How 그리고 What을 의논하고, 구상하고, 계획하여 제작 및 제공한다.
그러나 조직이 커지면서 하나의 조직에 2개 이상의 제품이 생겨나게 된다. 외관상 제품은 하나일지라도, 세부적으로는 각기 다른 여러 개의 제품이라 부를만한 규모나 복잡도를 갖추게 되기도 한다. 이 즈음 대표가 각각의 제품보다는 조직으로서의 사업 전략 또는 투자를 비롯한 대외업무에 더욱 집중하게 됨에 따라, 개개별 제품의 성장을 책임지는 역할을 PM 또는 PO가 나눠갖는다.
서비스 기획자라 부르든, 프로덕트 매니저라 부르든, 프로덕트 오너라 부르든, 이들은 이제 일정 수준 갖춰진 제품의 이후 방향부터 상세 구현과 계획수립까지를 책임진다.
그렇게 직무는 세분화되고, 이에 맞춰 각각의 직무의 역할과 본질은 재정의된다.
조직이 성장함에 따라 한 명의 업무를 양적으로, 질적으로 나눠가지며 직무는 세분화되고 재정의된다. (이미지 출처: 본인)분석은 누구나 할 수 있다
PM/PO를 예시로 조직의 성장에 따른 직무 세분화를 생각해 보았다. 그렇다면 '데이터 분석가'는 언제 세분화되는 걸까? 조직의 핵심 역량과 비즈니스 모델, 기타 여러 가지 요인에 따라 다를 수 있겠지만 아무리 데이터를 중요시한다고 이야기하는 조직이라 할지라도, 데이터 분석가는 PM/PO에 후행한다. 왜냐하면 어떤 의미에서 '분석'은 '누구나 할 수 있는' 업무이기 때문이다.
만약 이 글을 읽는 현업 데이터 분석가분들이 있다면, 이러한 이야기를 당돌하다고 생각할지도 모르겠다. 그러나 데이터 솔루션을 제작 및 제공하는 조직이라거나, 데이터에 관련된 기술이 조직의 핵심 기술이 아니라면, '데이터를 통해 제품과 비즈니스에 관한 질문에 답을 구하는 행위'로서의 분석은 나는 누구나 할 수 있다고 생각한다.
몇 가지 예를 들어보자. 프랜차이즈 지점 몇 곳을 동시에 보유 및 운영하는 사장님의 매출 분석은 데이터 분석인가 아닌가? 엑셀(Excel)로 정리된 지난 3년 치의 월별 매출 추이와 매장별 재고 관리에 관한 숫자는 데이터인가 아닌가? Index와 Match 함수를 활용해 몇 가지 지표를 조합하고, 엑셀이 제공하는 차트를 통한 대시보드 제작은 데이터 분석인가 아닌가? '데이터 분석'을 특정 규모나 유형의 데이터 또는 특정 종류의 기술과 스택에 한정 짓는 게 아니라면야, 데이터를 분석하는 툴과 기술은 늘 있었고, 누군가는 늘 데이터를 분석하고 있었다.
마찬가지로 이제 막 프로덕트 매니저, 마케터, CS 담당자 등으로 세분화된 IT 조직에도 '데이터'는 존재한다. 그리고 이들 대부분이 데이터를 '분석'하고 있다. Google Analytics와 Amplitdue 등에 쌓인 사용자의 로그 데이터를 클릭 몇 번을 통해 분석하고, 광고 성과를 살펴보고, 솔루션에 쌓인 숫자를 추출해 엑셀을 통해 전처리하여 추이를 살펴본다. 간단한 대시보드를 세팅하여 보고에 첨부하고, 기획과 의사결정의 근거로 삼는다.
따라서 조직이 "우리는 데이터를 기반으로 의사결정을 합니다. 우리 조직에는 데이터가 흐릅니다."라고 주장하더라도 (그리고 실제로 그러하더라도), 이것이 곧 팀에 별도의 데이터 분석가가 있다는 의미는 아니다. 왜냐하면 PM/PO를 비롯해 모두가 곧 분석가니까. 분석 업무가 상시로 필요하지 않거나, 제품과 비즈니스의 성장에 필요한 답이 대부분 외부 솔루션을 통해 클릭 몇 번으로 얻을 수 있는 수준일 때엔 '분석가'라는 동료가 따로 상주할 필요가 없으니까.
별도의 데이터 전담 팀이 없더라도 누구나 데이터를 수집/측정하여 분석하고 이를 비즈니스에 활용할 수 있다. 일정 수준까지는.그럼에도 데이터 분석가가 필요할 때
그런데 조직이 커질수록, 더 이상 외부 BI 솔루션이나 프로덕트 분석 툴에서의 클릭 몇 번으로 얻을 수 없는 깊이나 범위의 질문이 생겨나기도 한다. 더 이상 페이지 전환율, ROAS, 매출액과 순이익 등의 지표만이 데이터 분석의 전부가 아니게 되는 시점이 생겨난다. DB의 조회 권한을 가진 이들이 SELECT와 WHERE 몇 줄을 이용한 간단한 SQL 쿼리로는 보고 싶은 숫자를 뽑아내기 어려운 순간을 맞닥뜨린다.
혹은 리더십과 기획자/PM/PO 외에도 데이터를 요청하는 이들이 많아진다. 사업개발을 담당하는 이들이 고객사에 전달한 제안서나 결과보고에 필요한 데이터가 수시로 생겨난다. CS부서에서는 데이터의 문의 내역 너머 문의를 남긴 이들에 대한 부가적인 정보를 요구한다.
또는 데이터의 정합성과 활용에 관한 이슈가 생겨난다. 마케터가 우후죽순으로 심어놓은 각종 추적 코드의 관리가 되지 않는다. 백엔드 개발자가 설계해 둔 데이터베이스에 대해 조직의 누구도 제대로 이해하고 있지 못하다. 이것저것 Ad-hoc 성격으로 추출된 숫자나 설계된 실험을 제대로 관리해 줄 사람이 필요해진다.
대략 이 즈음에 조직은 '데이터 분석가'를 필요로 한다.
그런데 만약 이러한 시기에 자연스럽게 분석가의 포지션을 겸하거나 분석가로서 전업 또는 직무전환을 하게 된다면, 조직은 이들은 어떤 계기로 '데이터 분석가'라고 인식하게 될까? 또는 당사자 본인은 언제부터 스스로를 조직의 '데이터 분석가'라고 생각하게 될까? 다시 말해, 조직에서 데이터 분석가는 언제 탄생하는가?
제품과 비즈니스의 유형, 팀의 규모에 따라 천차만별이겠지만, 작은 팀에서 하나의 엄연한 '데이터 분석가'가 탄생하는 시점은 아마도 아래와 같은 때가 아닐까? 혹은 아래의 일들이 자주 생겨난다면 팀에 어느새 '데이터 분석가'가 생겨났다고 생각해도 되지 않을까?
- (범위) 조직의 누군가에게 전에 없던 범위의 분석을 요청하고 그 결과를 받아보았을 때
- (유형) 조직의 누군가에게 전에 없던 유형의 분석을 요청하고 그 결과를 받아보았을 때
- (정합성) 조직의 누군가가 데이터의 정합성에 대해 신경 쓰고 이를 챙기고 있을 때 (문서화 등)
- (스킬) 조직의 누군가가 다른 구성원의 분석 과정 또는 결과물에 대해 피드백을 해줄 때
- (고객) 조직의 누군가가 동료를 위해 수시로 다양한 데이터를 제공할 때 (대시보드, 정기 리포트 등)
- (비즈니스) 조직의 누군가와 제품의 데이터를 이용한 비즈니스 기회를 논의하거나 실행에 옮길 때
데이터 옹호자 data advocate로서의 분석가
그런데 자세히 살펴보면 위의 시나리오 또는 업무들은 사실 '분석'이 아니라 '데이터'에 방점이 찍혀있다. 혹은 이전의 '분석'의 정의를 더욱 확장한 경우다. 다시 말해, 이제 막 데이터 분석가를 필요로 하게 된 조직에서 필요로 하는 '데이터 분석' 업무란 사실은 이전의 분석 너머 더 넓고 다양한 의미의 분석인 동시에 분석 너머 데이터의 수집과 설계, 관리 등 '데이터 그 자체'에 방점이 찍힌 업무들이다.
대개의 경우 작은 조직에선 기획자 또는 PM/PO가 분석을 겸한다. 그러나 기획자, PM/PO의 데이터 업무는 자신의 가설을 검증하기 위한 데에 방점이 찍혀있다. 가설을 세우기 위해 분석하고, 검증하기 위해 실험을 설계하고, 검증 여부를 확인하기 위해 숫자를 해석한다. 그래서 아무리 PM/PO가 데이터 업무를 병행한다고 할지라도, 그 실력이 어떠할지라도, 그 범위 현재 자신이 다루는 제품에 그쳐있고, 추이와 현황을 확인하거나 A/B 테스트가 대부분이다. 엄밀하게는 그들의 데이터 분석은 이미 있는 수준에서의 데이터를 활용한 '분석'에 방점이 있지, '데이터'의 범위나 깊이를 확장하거나, 새로운 가치를 창출하거나, 활용도를 높이는 것과 같은 일에는 역량과 손길이 가닿지 못한다. 기획자나 PM/PO도, 마케터도, 또는 다른 누구도 일정 수준의 리터러시를 바탕으로 쿼리와 코드를 작성할 수 있지만, 데이터 그 자체에 대해 신경 쓰진 않는다.
바꿔 말해 이 시기의 데이터 분석가에게 요구되는 역할의 본질은, 조직에서 '데이터'가 적재적소에 더욱 잘 활용되고, 더욱 쉽게 설명되고, 다양한 이해관계자들에게 유연하게 흐르고, 결과적으로 더 많은 가치를 창출할 수 있게끔 책임지고 신경 쓰는 데이터 옹호자 data advocate 로서의 역할인 것이다. 단순히 쿼리를 더 빠르게 작성하고, 보고서를 작성하고, 숫자를 해석해 주는 사람이 아닌 것이다.
데이터 옹호자 data advocate 로서의 데이터 분석가
(물론 실제 업무에는 여러 하드 스킬이 필요하겠지만, 하드스킬만을 자신의 역할로 기대하고 합류한 분석가라면, 동료 기획자와 마케터, 운영 담당자들이 이미 쿼리를 작성하거나 코드를 통해 전처리와 간단한 모델링을 하는 모습에 놀라며 자신이 해야 하는 일이 무엇인지 몰라 방황할지도 모르겠다.)
이어서...
이번 글에서는 작은 조직이 성장하는 과정에서 직무가 세분화되고, 그 맥락에서 별도의 '데이터 분석가'가 필요해지게 되는 맥락과 시점, 그리고 그 시점에서 데이터 분석가에게 실제로 요구되는 데이터 옹호자 data advocate로서의 역할 또는 역량에 대해 간단히 살펴보았다.
이어지는 다음 글에서는 이러한 데이터 옹호자로서의 데이터 분석가를 전제로, 프로덕트 팀의 분석가가 바라보는 분석 업무와 프로덕트 팀과 조직의 데이터 문화(또는 활용)에 대한 소회를 공유하고자 한다.
