주니어 입장에서 본 데이터 분석 컨설턴트 vs 프로덕트 데이터 분석가

퇴사 후 모니터 앞에 앉아 주저리주저리 쓰는 글 -

 

단일 전공 문과 출신인 나는 2020년부터 데이터 공부를 시작했고, 2021년부터 데이터 분석 커리어를 쌓아왔다. 첫 커리어는 인턴을 하던 스타트업에서 정규직으로 전환이 되며 시작되었는데, 당시에는 데이터 분석가로서 내가 원하는 방향이 무엇인지 구체적으로 알지 못한 채 컨설팅을 하는 회사에서 무작정 일을 시작했다. 어떤 일이든 실무에서 데이터 분석을 하고 싶다는 욕망이 컸다.

1년간 컨설팅 업무를 하다 보니 이게 정말 내가 하고 싶은 분석인지 의문이 들기 시작했다. 이를 계기로 내가 어떤 분석을 하고 싶은지 구체화시켰고, ‘다른 회사’를 컨설팅하는 업무가 아닌, 프로덕트에 관련된 모든 데이터를 분석해 ‘우리’ 프로덕트를 개선하고 싶다는 생각이 들었다. 고민 끝에, 기존 정규직 포지션에서 대기업 계열사의 프로덕트 데이터 분석가 인턴으로 이직을 했고 관련 경험을 쌓았다. 아직 경력이 짧은 주니어 중의 주니어지만, 약 2년간 데이터 분석 컨설턴트(1년 4개월)와 프로덕트 데이터 분석가(6개월)가 어떻게 다른지 경험했다.
둘의 차이점과 더불어, 경험을 통해 배운 점들을 데이터 분석 업무 5단계*(문제 정의 - 데이터 수집 - 데이터 전처리 - 데이터 분석 - 데이터 시각화 및 리포팅)에 따라 작성해보고자 한다. 단순히 내 경험에만 의존한 글이기 때문에 회사마다, 도메인마다 다를 수 있으며 주니어의 입장에서 작성한 글이라는 점을 염두에 두고 읽어주셨으면 좋겠다 :)

(*출처 : [데이터 분석 업무 6단계], Data Richard)

 

 

 

1. 문제 정의

데이터 분석 컨설팅은 대체로 고객사에서 풀어야 할 문제를 가져온다. 예를 들면, ‘소비자들의 니즈를 바탕으로 상품을 리포지셔닝하고 싶어요’, ‘000 데이터가 있는데 효율적으로 정리하고 모니터링하고 싶어요’, ‘000 수치를 예측해 비즈니스에 활용하고 싶어요’ 등이 있다. 하지만 고객사 내에서도 어떤 문제를 풀어야 할지 명확하게 알지 못해 문제 정의 자체를 컨설턴트가 고민해야 하는 경우도 종종 있다. 문제를 정의한 후에는 이를 해결하기 위해 어떤 데이터를, 어디서 수집해, 어떻게 활용할지 결정하고 고객사에 제안한다.

프로덕트 데이터 분석은 내부에서 문제를 발견한다. 유저들의 퍼널 완수를 방해하는 bottleneck이 있는지, 이번 달 매출 혹은 피처 사용률이 00% 줄었는데 그 이유가 무엇인지, 신규 유저의 리텐션을 높이기 위해서는 어떻게 해야 하는지 등이 그 예다. 혹은 PM분들이 ‘~~한 문제가 있는데 데이터를 뽑아달라’고 요청하시면, 이에 맞는 데이터를 추출해 원인을 분석해보곤 한다.

 

2. 데이터 수집

데이터 분석 컨설팅은 필요한 데이터를 정의한 후 목적에 맞게 데이터를 수집한다. 데이터 수집은 크게 3가지로 나눌 수 있다.

• 웹상에 산재되어 있는 데이터를 직접 크롤링한다. 브랜드에 대한 소비자의 인식을 분석하고 이들의 니즈를 파악하기 위해 장문의 텍스트 데이터를 수집한다. 혹은, 상품명/가격/종류/카테고리 등 일종의 정형화 된 데이터를 수집하기도 한다. 개발팀에 크롤링을 요청하는 경우가 많지만, 내가 근무했을 당시에는 과중한 업무로 인해 개발팀이 마감 기한 내에 크롤링해주기 어려운 경우가 많았다. 다행히 팀 내 유일하게 내가 크롤링 코드를 짤 수 있었고, 다이나믹하게 어려운 경우가 아니라면 웬만해서 직접 파이썬 크롤링 코드를 작성해 데이터를 수집했다. 이 시기에 파이썬 실력을 많이 향상할 수 있었기에 좋은 기회이자 경험이었다고 생각한다.

• 고객사 내부 데이터를 제공받는다. 고객사 나름의 방식으로 축적해온 데이터를 전달받아 분석에 활용한다. 이 경우 데이터 양이 적거나, 데이터 양이 방대하더라도 정제되어 있지 않거나, 데이터의 양만 방대할 뿐 쓸 수 있는 데이터가 없기도 하다. 정제되어 있지 않은 데이터가 많다면, 데이터 전처리 단계에서 상당한 시간이 소요된다.

• 외부 데이터를 구매한다. 고객사에서 제공 받은 데이터의 양이 적다면, 추가로 외부 데이터를 구매해 데이터의 양을 보완한다. 하지만, 경험상 이러한 경우가 많지는 않고 최대한 내부 데이터로 해결하는 것 같다.

프로덕트 데이터 분석은 외부(웹)에서 데이터를 수집하는 경우는 거의 없고, 대부분 내부 DB에 적재된 데이터를 쿼리를 통해 추출하거나 앰플리튜드와 같은 퍼스트파티 데이터 툴을 활용한다(물론, 앰플리튜드 외에도 회사마다 사용하는 툴은 다양하다). 그렇다면 이러한 데이터를 어떤 과정을 통해 적재하는지에 대한 의문이 들 수 있는데, 사실 이 부분은 내가 직접 관여한 부분이 아니라 명확하게 설명은 할 수 없을 것 같다. 데이터 엔지니어분께 요청을 드리면, 앱 버전이 업데이트될 때마다 새로운 이벤트를 심어주시고 이를 통해 데이터가 수집되는 것으로 보인다. 다만, 사전에 해당 이벤트의 필요성에 대해 PM분들과 논의하는 과정을 거친다.

3. 데이터 전처리

이전에 함께 일했던 시니어분께서 ‘데이터 분석은 전처리가 90% 이상이다’라고 말씀하셨을 정도로 데이터 전처리는 매우 중요한 과정이다. 그만큼 시간이 매우 오래 소요되고, 전처리에 따라 분석 결과가 달라질 수 있다고 생각한다.

앞서 데이터 수집을 통해 데이터가 준비되었으면, 분석 목적에 맞게 데이터를 전처리한다. 데이터 분석 컨설팅 업무를 했을 당시에는 파이썬 80%, 엑셀 15%, SQL 5% 정도 사용해 전처리를 진행했다. 사내에 SQL을 사용할 수 있는 환경이 구축되어 있지 않았으며, 프로젝트에 따라 외부 DB를 사용할 수 있는 경우에만 SQL을 사용했다. EDA를 통해 데이터를 다양한 각도에서 관찰하며 어떻게 전처리하면 좋을지 결정하기도 한다. 프로젝트마다 데이터를 전처리하는 방법은 매우 다르기 때문에 정형화된 방법은 없다. 박스플롯을 통해 몇 %까지 이상치로 볼 것인지 결정한 후 이상치를 제거하기도 하고, 변수의 범위가 다양하다면 표준화(Standardization)와 정규화(Normalization)를 통해 피처 스케일링을 해주기도 한다. 텍스트 데이터라면 명사와 형용사와 같은 형태소 단위로 쪼개보기도 하고, 온전하지 않은 텍스트를 온전한 형태로 매칭시켜주기도 한다. 간단한 작업은 엑셀 피벗 테이블, 차트, 파워쿼리 등의 기능을 활용하며 종종 파이썬보다 엑셀 작업이 훨씬 효율적일 때도 있다.

 

 

프로덕트 데이터 분석은 데이터 수집과 가공이 동시에 일어나기 때문에 2번과 3번을 따로 작성하는 것이 사실 큰 의미는 없을 것 같다. 프로덕트 데이터 분석 업무를 했을 당시에는 SQL 60%, 엑셀(구글 스프레드시트) 30%, 파이썬 10% 정도 사용했다. 대부분의 전처리는 SQL을 통해 진행했고, 간단한 전처리는 엑셀을 활용했다. 대부분 정형 데이터라 크게 애먹을 일은 없었지만, 내가 원하는 조건의 유저를 추출하기 위해 머리를 싸매고 쿼리를 작성했다(ex. 가입한 지 7일 이내에 피드 좋아요를 받은 유저 등)

이 시기에 SQL 실력이 많이 늘었는데, 쿼리 처리 속도가 느려 속 터진 적이 많았기 때문에(...) 어떻게 하면 빠르게 결과를 볼 수 있을지 고민하게 되면서 자연스럽게 효율적으로 쿼리 짜는 법을 공부할 수 있었다. 예를 들면, 혼자 SQL을 공부할 때는 내가 원하는 결과를 내기 위해 서브쿼리를 무분별하게 썼었는데, 회사에서는 마구잡이로 쿼리를 작성했다가 밤새도록 실행시켜도 결과물을 볼 수 없는 낭패를 겪었다. 내 정신 건강을 위해서라도 성능 저하를 일으키는 쿼리 작성은 지양하고, 최대한 서브쿼리를 쓰지 않고 같은 결과물을 낼 수 있도록 노력했다. 특히 WITH 구문을 많이 활용했다.

SQL 못지않게 엑셀 실력도 굉장히 많이 늘었다. 특히, 엑셀 VBA를 사용해 자동화한 것이 인상 깊었다. 이전에 컴활 공부를 할 때 '이런 것이 있구나~' 정도로만 알고 있었는데, 이걸 실무에 사용해보니 신기했다. ‘와 이게 엑셀로 된다고?’의 연속이었다.
파이썬은 좀 더 복잡한 전처리를 하거나 리텐션을 계산할 때 사용했다. 개인적인 경험으로는, SQL로 굉장히 오래 걸리는 작업이 파이썬으로는 매우 간단하게 진행되는 경우가 꽤 있었다. 리텐션은 SQL로 계산하는 것도 가능하긴 하지만, 나에게는 파이썬이 좀 더 편했다.

 

 

4. 데이터 분석

“ 데이터(Data)를 통해 인사이트(Insight)를 도출하기 위해서는 분석(Analysis)이 필수이다. 그리고 데이터를 통해 찾아낸 인사이트로 가치(Value)를 만드는 것이 중요한데 이는 실행(Action)이 뒷받침되어야 한다. 즉 실제 업무에 변화를 만들고 실행이 이뤄져야 이 모든 일들의 가치가 부여 된다. 이를 도식화한다면, Data + Analysis = Insight이고 Insight + Action = Value 로 나타낼 수 있겠다.”
(출처 : 데이터 분석을 통한 인사이트 도출이 오래 걸리는 이유, 정순호)

컨설팅 회사에서의 분석 업무는 크게 인사이트 도출과 모델링으로 나뉘어 진행되었다.

앞서 전처리한 데이터를 다양한 방식으로 시각화해보며, 고객사의 문제를 해결할 수 있는, 즉 Value로 연결될 수 있는 인사이트를 찾았다. 이때 어려운 점은 고객사마다 도메인이 다른데, 이에 대한 지식이 얕기 때문에 ‘과연 내가 도출한 인사이트가 얼마나 Value가 있을지’ 감을 잡기 힘들다는 것이다. 입사 초기에 어느 건설 회사 프로젝트를 맡은 적이 있었는데, 아파트 청약에 대한 지식이 전무해 어려움을 겪었다. 가치 있는 인사이트를 도출하기 위해 도메인 지식을 익히는 데 따로 시간과 노력을 많이 들여야 했다. 그만큼 다양한 데이터를 보고 다양한 도메인에 대해 공부하다 보니 지루할 틈이 없다. 새로운 프로젝트를 맡을 때마다 항상 배울 것이 넘쳐났기 때문에 흥미로웠다.

간단한 머신러닝 모델링 업무는 내가 담당하기도 했었지만, 대부분의 심화 모델링은 데이터 사이언티스트분이 담당하셨다. 모델링에 더 관여하고 싶어 관련 역량을 키우기 위해 사내 데이터 사이언티스트 분들이 진행하시는 AI 학회에 참석하기도 했다. 매달 특정 주제에 대해 공부한 내용이나 한 달 동안 진행한 토이 프로젝트를 발표하면서 많이 성장할 수 있었다. 혼자서 한 달에 한 주제씩 토이 프로젝트를 진행하는 것이 쉽지 않은 일인데, 학회를 통해서 반강제로(?) 하다 보니 많은 공부가 되었다.

 

 

컨설팅 회사에서 진행했던 분석이 전처리한 데이터를 다양하게 시각화해보는 것에 초점이 맞춰져 있었다면, 프로덕트 데이터 분석은 문제를 해결하기 위한 데이터를 올바르게 추출하는 것이 핵심인 것 같다. 예를 들어, 구독 이탈률이 증가하고 있다는 문제가 발생했을 때, 구독 목적을 3가지로 정의한 후 SQL을 통해 목적에 따른 유저 데이터를 추출했다. 그 결과, 두 개 혹은 세 개의 중복되는 목적을 가지고 구독하는 유저들보다 하나의 명확한 목적을 가지고 구독하는 유저가 대다수임을 발견했다. 이를 바탕으로 구독 목적에 따라 이탈을 방지할 수 있는 방안을 기획했고 비싼 가격에 여러 혜택을 제공하기보다, 가격은 낮추되 하나의 혜택을 선택할 수 있는 구독 방식을 제안했다. 이러한 과정에서 목적에 따른 유저 그룹을 올바르게 추출하지 못했다면 해당 인사이트를 도출할 수 없었을 것이다.

또한, 프로덕트 데이터 분석에서는 어떤 문제가 발생했을 때 데이터를 쪼개서 입체적으로 보는 것이 특히 중요하다. 내가 말하고자 하는 내용을 잘 설명해놓으신 Peter님의 글*이 있어 해당 글의 내용을 인용해보겠다. 예를 들어, 최근 3개월간 매출이 하락하고 있다는 문제가 발생했다고 가정해보자. 이때, 매출 하락에 영향을 끼치는 변수들을 여러 범주로 나누어 어떤 범주가 매출 하락에 가장 큰 영향을 끼쳤는지 살펴볼 수 있다. ‘지역’이라는 변수가 있다면, 이를 광역시도 단위나 수도권/지방, 혹은 도시와 비도시로 범주를 나누어본다. 그 결과 수도권에서 주문량이 급감하면서 매출액이 감소했다면, ‘지역’이라는 변수로 ‘매출 하락’이라는 변수를 설명할 수 있게 된 것이다. 이렇게 계속 지표로 지표를 설명하는 과정을 거치며 어떤 지표의 변화가 다른 지표의 변화를 야기하는 것을 발견할 수 있다.
(*출처 : 가설 검증을 통한 데이터 분석을 하려면, Peter)

프로덕트 데이터 분석은 앰플리튜드와 같은 퍼스트파티 데이터 툴을 활용해 자사 데이터에 매우 쉽게 접근할 수 있기 때문에 데이터를 활용할 수 있는 범위가 훨씬 넓다. 굳이 SQL로 데이터를 추출하지 않아도 마우스 클릭 몇 번만으로 퍼널 차트를 생성할 수 있고, DAU와 MAU를 확인할 수 있으며, 리텐션 분석을 할 수 있다. 그렇기 때문에 컨설팅 회사보다 데이터를 실시간으로 모니터링하기 용이하고, 더 다양한 인사이트를 도출할 수 있으며, 데이터를 더욱 입체적으로 볼 수 있다. 이것이 내가 컨설턴트가 아닌 프로덕트 데이터 분석가로 전향한 가장 큰 이유이기도 하다.

5. 데이터 시각화 및 리포팅

컨설팅 회사에서는 고객사에서 요청하거나, 혹은 굳이 요청하지 않아도 대시보드가 있는 것이 고객사에게 유용할 때 태블로 대시보드를 제공해주었다. 대시보드를 제작하기 위해서는 생각보다 많은 고민이 필요한 것 같다. 대시보드의 전달력과 디자인을 모두 신경 써야 하며, 인터랙티브 대시보드의 경우 올바른 데이터를 연결했음에도 불구하고 오류가 발생할 수 있기에 꼼꼼히 확인해야 한다.

분석이 어느 정도 마무리되면, 고객사에 전달할 리포트를 작성한다. 그렇기 때문에 컨설턴트는 PPT를 매우 잘 해야 하고, 나도 컨설팅 업무를 하며 PPT 제작 스킬을 아주 많이 레벨업 시킬 수 있었다. 대학생 때 팀플을 하면 항상 PPT를 담당할 정도로 PPT에 자신이 있었는데, 컨설팅 회사에서의 PPT는 상상 이상이었다. 아무래도 외부(고객사)에 전달해야 하는 결과물이기 때문에 특히 더 리포트에 공들일 수밖에 없는 것 같다. 장표를 한 장 한 장 구조화시키는 것이 매우 중요하며 도형 하나 허투루 그리지 않는다. 단어 하나라도 의도한 바를 제대로 전달하기 위해 끊임없이 고민하고 다듬는다. 리포트의 컬러와 폰트, 디자인 또한 빼놓을 수 없는 중요 요소다. 이렇게 리포트를 정성 들여 만들어야 하는 컨설팅 회사에서 첫 경력을 쌓다 보니, 전달력 있는 리포트를 만드는 법에 대해서 많이 배울 수 있었다. 당시에는 리포트 만드는 일이 부담이 많이 되었는데, 돌아보면 다 피와 살이 되는 값진 경험이었다.

리포트가 완성되면 이를 고객사에 전달 후, 미팅을 통해 내용을 발표한다. 외부인을 대상으로 발표하는 것이기 때문에 웬만하면 시니어분들이 하시긴 하지만, 내가 PM(Project Manager)을 맡은 프로젝트에서는 내가 발표를 맡기도 했다. 이 순간이 너무너무 긴장되고 떨리고 부담되고 도망치고 싶은 마음이 들지만.. 이 또한 좋은 밑거름이 될지어다 생각하며 어떻게든 해내야 한다🔥


프로덕트 데이터 분석 업무를 하는 동안에는 아쉽게도 시각화 툴을 사용해 대시보드를 만들어보는 경험은 하지 못했다. 회사 내에 시각화 툴이 온전하게 도입이 되지 않은 상태였기 때문에, DB와 태블로를 연동하여 자유자재로 시각화해볼 수 있는 상황이 아니었다. 하지만, 앰플리튜드가 훌륭한 시각화 기능을 제공하고 있기 때문에 큰 어려움은 없었다. 앰플리튜드를 활용해 전사적으로 모니터링할 수 있는 대륙별 KPI 대시보드를 제작하기도 했다.

컨설팅 회사와 달리 프로덕트 데이터 분석 업무를 경험했던 회사는 ‘상대적으로’ 리포트에 공을 덜 들이는 것 같다고 느꼈다. 아무래도 내부에서만 공유되는 리포트이다 보니 한 장 한 장 정성스럽고 예쁘게 만드는 데 시간을 많이 투자하기보다는 '깔끔하고 전달력 있게'가 핵심인 것 같다. 하지만, 한 회사에서의 경험만을 바탕으로 한 나의 개인적인 생각이기 때문에, 내부 리포트일지라도 오랜 시간 공을 들이는 회사도 분명 있을 것이라고 생각한다. (a.k.a 회바회)

그  외

데이터 분석 컨설팅 업무에서는 커뮤니케이션 스킬이 특히 중요하다. 프로젝트를 진행하면서 수시로 고객사와 소통해야 하고, 서로가 같은 곳을 바라보고 합의된 방향대로 움직이고 있는지 계속해서 확인해야 한다. 컨설팅 회사에서 진행하는 프로젝트는 모두 고객사와 이해관계가 얽혀 있기 때문에 실험적인 마인드보다는 모든 사항에 대해 명확하고 확실한 마인드가 중요한 것 같다.

반면, 프로덕트 데이터 분석 업무는 내부 커뮤니케이션이 대부분이기 때문에, 내부자가 이해할 정도로만 명확하게 커뮤니케이션하면 된다. 또한, 타 회사가 돈을 지불하고 진행되는 프로젝트가 아니기 때문에, 성과를 내는 것이 매우 급한 상태가 아니라면 이런저런 실험적인 프로젝트를 비교적 많이 진행해볼 수 있는 것 같다.


마감 기한에 대한 부담의 정도도 다르다. 어느 회사에서나 마감 기한을 지키는 일은 매우 중요하지만, 컨설팅 업무에서의 마감 기한은 외부 고객사와의 약속이고 내부 사정이 크게 고려되지 않기 때문에 부담의 정도가 특히 크다.

프로덕트 데이터 분석 업무에서의 마감 기한도 마찬가지로 중요하다. 내부에서 짜놓은 플랜에 따라 움직여야 하고 마냥 오랜 시간 분석만 할 수 없기 때문에 마감 기한이 정해져 있다면 잘 지켜야 한다. 하지만, 내부적으로 다른 이슈가 생기거나 기한을 지킬 수 없는 불가피한 상황에서 비교적 유동적으로 마감 기한이 조정될 수 있는 여지가 더 많은 것 같다.

 

마무리

회사를 퇴사한 시점에서 그동안의 경험을 정리해보니 짧은 시간 내에 많은 것을 배우고 성장했다는 것이 느껴졌다. 내가 감사하게 생각하는 점은, 지금까지 경험한 두 회사에서 겹치는 부분이 많이 없었기에 다양한 경험을 해볼 수 있었다는 점이다. 배우고 성장하는 것은 항상 즐거운 일이다. 재충전의 시간을 잘 마무리하고, 훗날 몸담을 회사에서도 다양한 경험을 쌓을 수 있도록 노력하고 준비해야겠다고 다시금 다짐했다.