본문 바로가기

블로그/생각거리

데이터 분석가의 일

Data Analyst(DA)로 약 1년간 일하면서 느낀 데이터 분석가의 주요 업무를 정리해보았다. 회사에서 정의하고 있는 분석가의 역할에 따라서 달라질 수 있는 내용이다. 따라서 지극적으로 개인적인 의견임을 밝힌다. 모든 업무가 똑같겠지만, 비즈니스 임팩트를 내지 못하는 분석가의 업무는 지루하며 의미가 없다고 생각한다. 분석가는 모든 업무를 비즈니스 목표와 일치시켜야 한다.

 

지금 회사에서는 DA 업무보다는 ML 엔지니어(ML Engineer)의 역할을 수행하고 있는데, 비즈니스 난제 해결을 위해 ML/AI 기술을 활용하고, 비즈니스 목표를 달성하기 위한 프로덕션 레벨의 ML 개발을 목표로 하고 있다. 개인적으로 머신러닝 엔지니어가 조금 더 적성에 맞는것 같다. 다음에는 ML 엔지니어의 일에 대해서 작성해보도록 하겠다.

 


목록

  1. 데이터 추출/분석 업무 진행
  2. 가설에 기반한 데이터 분석
  3. 서비스 개선을 위한 제품/사업 분석
  4. 대시보드 생성 및 관리
  5. 데이터 파이프라인 구축 및 정책 관리

(1) 타 부서에서의 데이터 추출/분석

What?

데이터를 쿼리를 이용하여 내부DB에서 추출하여, 타 부서에 전달하는 업무

When?

사내에서 사용하는 분석 툴 (믹스패널, 앰플리튜드, GA 등) 에서 확인할 수 없는 데이터의 경우

How? 

(1) 데이터 분석가는 이슈의 결과물이 요청자의 의도를 만족할 수 있는지, 요청한 데이터 외에 의사결정에 도움이 될만한 추가 데이터나 과거 인사이트는 어떤것이 있는지 검토를 진행한다.

그리고 데이터를 전달하면서 인사이트를 도출하기 어렵다고 판단이 들면 이슈제공자와 중간 공유를 하면서 필요시 추가분석을 진행한다.

(2) 데이터를 넘겨줬을 때, 의사결정자가 제공된 데이터를 바탕으로 논리적인 인사이트를 도출하고 있는지 Follow up을 지속적으로 한다.

 

이렇게 제공된 데이터와 인사이트로 의사결정을 하기 충분하다고 판단이 들면 해당 이슈를 종료가 되고, 추가 분석이 필요하면 위 업무를 계속 진행한다.

개인적인 TIP:

  • 해당 데이터 추출 이슈가 계속 최신화를 해야하고, 특정 카테고리로 나누어 꾸준히 관찰하고자 한다면, 이를 편리하게 볼 수 있도록 SQL 쿼리를 효율화 하여 전달 or 분석가의 판단하에, 자동화하여 타 팀에서 데이터를 쉽게 이용할 수 있게 제공
  • 그럼 단순히 데이터 추출 업무만 하는가? 타 팀에서 데이터 분석 요청이 들어온다면, 왜 이 데이터가 필요한지 그 이유에 대해 첨부 요청. 그렇다면 담당자가 해당 이슈를 보았을 때, 어떻게 앞으로 이 데이터 추출 및 분석 결과물이 각 팀에서 활용 수 있을지 이해할 수 있다.

(2) 가설에 기반한 데이터 분석 / 서비스 개선을 위한 제품 및 사업 분석

What?

서비스에 새로운 기능을 추가하거나 기존의 기능을 개선하여 서비스에 적용할 때, 핵심 지표 분석 및 데이터 분석 업무

how?

새로운 기능이 배포가 되면, 배포 전후에 서비스의 어떤 변화가 있었는지 분석하고, 이 변화가 서비스 또는 사업에 긍정적인지 아닌지 판단한다.

Example

기업에서 개발 프로세스를 개발 전, 개발, 개발 후 배포로 3가지로 나눴을 때,

첫 번째, 기획 단계(개발 전)에서 분석가는 프로젝트의 key result가 알맞게 설정되었는지 검토한다.

 

예를들어 네이버, 페이스북, 카카오 간편 가입하기 기능을 서비스에 추가하는 기획이 있다. 이때 지표를 **회원가입 수**로 측정하는 것 보다 회원가입 전환율 로 측정하는 것이 해당 서비스 성과를 측정하는 데 도움이 될 것이다.

 

Why? 회원가입 수는 굉장히 광범위하고 마케팅적인 액션이나, 유저가 그날 얼마나 예약을 했는지에 따라 변할 수 있기 때문에 해당 프로젝트의 영향을 정확히 측정하는데 어려울 수 있다.

 

이렇게 key result를 정했다면, 이 요소외에 추가로 측정하고 싶은 부분은 없는지 PO와 검토를 하고, 해당 스쿼드의 KPI와 잘 부합하는지 확인한다.

또 서비스 기획 전, 해당 프로젝트의 가치가 얼마나 되는지 시뮬레이션을 진행하여, 행동에 대한 가치를 추정할 수 있다면 프로젝트에 우선순위를 판단할 수 있을 것이다.

 

두 번째, 개발 단계에서 '사내에서 성과 측정을 위한 데이터를 기록하는가?'를 판단하고, 성과 측정을 위한 데이터를 마련한다. 데이터를 분석할 때, 개발자가 DB에 적재된 데이터를 활용하기도 하지만 상황에 따라서 분석을 위한 데이터를 따로 요청해야한다.

따라서 프론트와 앱팀 서버팀과 긴밀이 논의하여 데이터를 심고 성과를 측정할 수 있도록 준비한다.

 

세 번째, 개발 후 배포 전에 비해 배포 후 유저의 경험이 얼마나 개선되었는가 측정을 한다.

가장 중요한것은 유의미한 결과, 즉 유의미한 개선인지가 가장 중요하다.

 

→ 1%가 올라도 유의미할 수도 있으며, 5%이지만 유의미하지 않을 수도 있다 (엄밀한 방법의 인과추론 접근 필요)

또한 유의미하게 경험이 개선되었어도, 기획 단계에서 미처 발견하지 못한 외부 요소가 있으면 이를 염두해 분석과 측정을 진행해야 한다.

 

>> 과학적인 방법을 통한 인과 추론이 중요

 

-> 인과 추론 관련 글 

https://fenzhan.tistory.com/31

 

Example 2

상술한 회원가입 서비스를 배포 → 기대한 성과  회원가입률이 나오지 않음

→ 유저 퍼널별 데이터 분석 → 유저를 플랫폼/ 가입 페이지 등 다양한 그룹으로 나눠 추적

→ 예를 들어, 유독 IOS에서만 해당 버튼의 클릭률이 낮음

→ 데이터 분석가는 가설을 세워 문제를 해결

가설1. IOS에서 가입하는 유저들은 특정 소셜플랫폼에 대한 사용이 낮아 회원가입시 간편함을 못느꼈을 수도 있으며

가설2. IOS 기기에서 요구하는 추가적인 단계가 발생하여 유저가 중간에 이탈했다는 이슈가 발생할 수도 있다.


세운 가설을 데이터 분석가는 검증을 진행하고, 해당 이슈를 발생하는 원인을 찾아 어떻게 해당 이슈사항을 개선해야 할지 결과와 함께 제언을 PO 및 담당자에 공유한다.

(3) 대시보드 생성 및 관리

What?

전사적인 대시보드 생성 및 관리(유지 보수)

  • Redash / Tableau 등

When?

각 팀이나 스쿼드에서 여러 내부 이해관계자가 목표하고 있는 KPI를 꾸준히 추적하고 싶다면, 데이터 팀에게 대시보드를 요청할 수도 있다.

How?

앞서 (2) 제품 및 사업 분석에서 프로젝트의 key result가 얼마나 성과를 설명할 수 있는지 검토를 하였다면, 대시보드를 만들때는 요청자가 원하는 내용이 대시보드가 설명할 수 있는지 검토를 한다.

세세하게 지표를 파악하면서, 대시보드 요청자가 파악하고자 하는 내용을 바탕으로 대시보드를 제작하고 있는지 확인하고, 대시보드의 주제에 부합하지 않는 지표가 포함되어있는지 확인한다.

대시보드를 완성하였을 때, 바로 전달하는 것이 아니라 대시보드가 이러한 형태가 맞는지에 대해서 커뮤니케이션을 진행해야 한다(필수)

왜냐하면, 본인이 요청하기는 했지만 실 데이터를 보는 것은 처음이고 데이터의 양상에 따라서 제외 및 추가하고 싶은 것이 존재하기 때문이다.

 

따라서 커뮤니케이션 → 제작 → 초안 제작 공유 →대시보드의 활용자 피드백 수집 → 삭제/추가/ 개선 사항 적용 → 요청자 및 팀이 활용하는데 무리가 없는지 파악 이라는 프로세스를 거쳐서 대시보드를 제작한다.

이후 서비스 확장에 따른 추가 요청 및 각종 운영 이슈를(메모리 관리, 원천 데이터 변화로 인한 오류) 관리한다.

 

(4) 데이터 파이프라인 구축 및 정책 관리 / 로깅

What?

DW(데이터 웨어하우스) 가 없으면 데이터 로깅을 하여 데이터 파이프라인을 구축 필요

- 어떻게 DM(데이터 마트)를 만들고, 일배치? 주단위? 다양한 기준 설정 필요

DW가 구축함과 동시에 다양한 데이터를 어떻게 관리할 건지에 대한 정책 필요

 

When?

초기 데이터 팀 / 한 번 구축 후 계속 팔로우업을 하여 업데이트에 대한 기록을 남겨야함 (기록을 남기지 않으면 나중에 커뮤니케이션 오류가 생김)

 

How?

- 로깅은 웹과 앱의 툴과 방법 다르기 때문에 상황에 맞는 로깅 전략이 필요하다.

- 로깅 QA는 필수로 진행해야하며, 한 번 잘못 쌓인 데이터는 쓸 수 없다는 것을 유의해야한다.

- 정책은 모두가 볼 수 있게 설정하며, 업데이트가 된다면 버전별로 설정해야함. 이때, 데이터 정책이라는 것은 테이블 명명법, 지표 정의 등을 모두 포함하기 때문에 필요한 것을 하나하나 만들어가보자.

- DW를 구축하는 것은 쉽지 않기 때문에, 클라우드 플랫폼을 활용해보자 (Bigquery, AWS)