Summary

• 세션1: 데이터와 머신러닝이 비즈니스와 만날 때 발생할 수 있는 비극들 - 하용호님 (Kakao)

  비즈니스에서 데이터 분석과 머신러닝 도입에서 장애와 성공적인 밸류를 만드는 법

• 세션2: AI 프로젝트 간지나게 잘 진행하는 법 - 백정상님 (Google)

  AI 프로젝트 셋업을 위해 필요한 것들

• 세션3: 온라인 게임 데이터 분석 사례와 향후 과제 - 이은조님 (NCSoft)

  현업에서 데이터 분석을 적용하면서 맞닥뜨리는 현실적인 문제들과 해결 아이디어

• 세션 5: 맛있는 데이터를 물어다주는 멍멍이 - 노상래님 (마켓컬리)

  엑셀 시대에서 실시간 대시보드 & 예측 시스템 시대까지 데이터 분석을 비즈니즈에 도입한 과정

• 세션 6: MOBILITY X DATA : 모빌리티 산업의 도전 과제 - 변성윤님 (쏘카)

  모빌리티 산업의 데이터와 다양한 문제들에 대해 소개

• 세션 7: 데이터가 흐르는 조직 만들기 - 양승화님 (마이리얼트립)

  데이터가 흐르는 조직을 위해 시도한 실질적인 노력들

세션1: 데이터와 머신러닝이 비즈니스와 만날 때 발생할 수 있는 비극들 - 하용호님

데이터에서 패턴을 찾아내어 비지니스 기회로

많은 회사들이 업무에 데이터와 머신러닝을 도입하고 싶어하지만 잘 안됨.

왜 -> 많은 사람들이 데이터로 일을 해본 적이 없기 때문

대표적인 잘못된 회사의 데이터 사업 계획 데이터를 모아서 추천도하고 프로파일링도하고.. 유저의 성향을 파악하고 인사이트를 도출 후, 마법의 뿅

구슬이 서말이어도 꿰어야 보배

• 일단 서말이 안된다 (데이터가 없다)
• 꿰는 기술이 없다 (관련 전문가가 없다)
• 보배 (뭐가 보배인지 모른다)

구슬이 서말이어도 꿰어야 보배 -> 가능하려면

-> 엄청난 데이터 필요 -> 엄청난 서버 -> 엄청난 엔지니어 —-> 다없다

1. 일단 서말이 없다.

데이터로 뭐하지 > 추천이나 광고에 쓸거에요 -> 사실 엄청난 데이터가 필요하다

• 기업의 데이터는 2가지 폼으로 존재 -> 없거나, 쓸 수 없거나 ex) 사장님: 우리 회사 데이터 진짜 많다 오면 뭐든지 할 수 있다. ~다 거짓말이다…~

• 추천으로 의미가 있기 위해서는 MAU 20만은 필요 (다운로드 기준 100만)
• 광고기준으로는 적어도 MAU 200민 (다운로드 기준 1000만)
• 유저마다 수십 수백건 서비스 사용기록이 필요

추천, 광고 등으로 재미보는 회사는 정해져있다

• 재미보는 회사 -> 커머스: 아마존, 쿠팡
• 광고로 재미보는 회사 -> 구글, 페이스북, 네이버, 카카오
• 본업이 추천, 광고를 하는 회사임

회사는 노력을 본질에 집중해야 한다.

• 초기라면 그냥 인기 순위로도 충분하다.
• 더 쉽고 빠르고 편한 유저 플로우를 만드는 것이 좋다.

2. 꿰는 기술이 없다.

인력 -> 일단 비싸고 구하기 힘듦

• 머신러닝 엔지니어 6천
• 좋은 엔지니어 1억
• 훌륭한 엔지니어 싯가 -> 일반 대기업은 매력적인 직장이 아님

데이터도 없고 회사의 핵심이 다른 곳에 있기때문에 가지 않음.

선호도: 카카오 > 네이버 > 스타트업 > 통신사들 > 전자회사들 > 그외…

3. 보배: 비지니스와 만남 기술은 이익을 만들어내야함

실패하는 환상적인 만남

• 뭔가 새로운 것을 도전하고 싶은 상위권자
• 빅데이터와 머신러닝도 쓰는 간지나는 서비스를 꿈구는 기획자
• 데이터와 머신러닝을 공부했지만 현업적용은 못해본 열정적인 엔지니어

실패하는 이유

머신러닝을 쓰고 싶다 -> 우리 문제에 어떻게 구겨넣지 (x)

잘못된 곳에 적용하거나 필요하지 않은 상황에 적용

핵심: 메인 비즈니스의 밸류 체인에서 비효율 구간을 찾아야 한다

비지니스 밸류 체인

• 회사의 메인비지니스 ———————–>
• 뭔가 멋진것 (새롭게 데이터로 하는 비지니스) —>
• 새로운 비지니스는 시간이 걸리고 파급이 적다

회사에서 데이터로 밸류를 만들 수 있는 부분: 메인 비지니스 밸류 체인에서 비효율 적인 부분을 효율적으로 하는 것

• 사람이 감으로 하거나
• 사람이 하기에 느려지는 부분 (병목인 부분) -> 머신러닝과 데이터를 이용해, 대체하여 자동화 하거나, 판단을 보조하여 빠르게 한다.

복잡해 보인다고 답은 아니다.

예제: 매출을 올리기 위해, 메인 상품 진열 순서는 어떻게 하는게 좋을까? 간단한 데이터 활용 멋있고 간지나는 머신러닝: 유저마다 프로파일하여, 최적을 추천

세상 모든 것은 ROI

1) 룰 베이스 접근으로 60짜리를 빠르게 10개 만들 수 있음 > 600개 2) 머신러닝 접근으로 80짜리를 1개 만들 수 있음 > 80개

기회비용 일단 가장 심플한 방법을 방치하고 말고 빨리 하는 것 심플에서 충분히 뽑아내고 있을 때 머신러닝을 시도하는 것이 좋음

그럼 언제,왜 머신러닝 하는가? 규모가 커지면서, 심플한 방법을 도저히 매니지할 수 없을 때

카카오에서 한 것: 플러스 친구 메시지 최적화

카카오는 뭐로 돈 벌지? 광고(이미 잘하고 있음), 메시지(돈버는 것 -> 플러스 친구 메시지)

플러스 친구 메시지 > 본질과 밸류 체인이 뭐지?

• 무엇을 보낼 것인가: 컨텐츠 셀렉터
• 누구에게 보낼 것인가: 반을 잘 할 유저를 선택
• 효과는 어땠나: 사람이 일일히 분석하지 않도록 로봇 분석가를 개발

세션2: AI 프로젝트 간지나게 잘 진행하는 법 - 백정상님

1. 성공 & 실패하는 머신러닝 프로젝트

멋지고 분위기 좋은 팀(like Brain팀)의 성공조건

• 세계 최고 수준의 팀을 기반으로
• 해결하고자 하는 비즈니스 문제가 굉장ㅎ ㅣ크고 아름답고
• 그 문제를 해결하면 생기는 비즈니스 임팩트가 커야 함
• 무조건 성공한다는 확신이 있어야함
• 실패 가능성을 최소화 해야함

실패하는 머신러닝 프로젝트의 이유들

• 비즈니스에 대한 이해 부족
• 낮은 데이터 품질 (로그를 쌓는 시간은 전체 개발 시간에 비해 턱없이 부족)
• 잘못된 머신러닝 사용
• 편견 또는 확증편향
• 부족한 인프라 지원
• 부실한 계획과 거버넌스 부재

머신러닝 프로젝트를 실패하지 않으려면

• 풀어야 하는 비즈니스의 임팩트가 충분히 크고
• 비즈니스 도메인 지식이 충분해야 하고
• 높은 품질의 데이터를 쉽게 획득할 수 있어야 하며
• 머신러닝이 실제 프로젝트에 도움이 되어야하고
• 편견이 생기지 않도록 중심을 잡아줄 데이터 사이언티스트가 필요하며
• 비용 효율적이며 충분한 인프라를 확보하고
• 충분한 프로젝트 여정에 대한 계획을 기반으로
• 최고 의사 결정자의 서포트를 충분히 받아 진행해야하며, 그로 인해 충분히 일정이 쪼야여 됨 (기본 유지비가 꽤 큼)

2. AI 프로젝트 셋업

비즈니스 케이스 탐색

• 크게 생각해야함. Think x 10
• 팀 유지비 배비 최소 10배를 더 벌어주는 프로젝트여야 함

최초 머신러닝 팀 빌딩

• 프러덕트 -> 프로덕트 매니저 (1)
• 비즈니스 -> 비즈니스 분석가 (1)
• 데이터 사이언스 -> 데이터 사이언티스트 (1)
• 머신러닝 -> 머신러닝 엔지니어 (1)

프로젝트 예산 => 8억 (투자비용)

• 팀 인건비 -> 4명 월급 4000만원
• 인프라 비용 -> 3억 (하둡 클러스터 온프레미스)
• 소프트웨어 구입 및 구독 (1000만원)
• 예상 개발 기간 (1년) => 8억 ==> 80억을 버는 프로젝트를 찾아야함

프로덕트 디자인 및 마일스톤 플래닝

• 쉽게 말하면 제품 기획
• 풀어야 할 비즈니스 문제를 명확하게 정의
• 프로적트를 통해 얻는 비즈니스 임팩트를 계측 가능하도록 정의

데이터 디자인

• 데이터 = 돈
• 프로턱트에서 필요로 하는 모든 데이터는 수집할 수 있어야 함
• 비교적 유연하게 변경 가능한 JSON으로 디자인 하는 경우가 많음

밸류 임팩트가 큰 데이터

• 구조화된 데이터
• 시계열
• 이미지
• 비디오
• 텍스트
• 오디오

데이터 파이프라인 구축

• 데이터의 유실이 없어야 함
• 중복된 데이터 허용 및 dedup
• 가급적이면 매니지드 서비스 혹은 ETL플랫폼을 활용

데이터 분석

• EDA
• 데이터 상관관계 분석
• 통계적 검증: 빈도검증, 타당도 검증, z 스코어 검증, t 스코어 검증
• 고전적 머신러닝 회귀모형 클러스터링
• 데이터의 품질과 특징을 분석해야 한다
• 데이터 분석만으로도 문제를 해결하는 경우가 많음. 이 경우에는 바로 비즈니스 임팩트를 만들고 다음 프로젝트를 간지나게 시작한다.
• 통계나 머신러닝으로 threshold를 구할 수 있다면 룰 베이스 모델 구현

머신러닝 시작

• 분석 결과에 따른 최적의 모델 선택
• AI툴셋 - AI hub
• 모델 개발: 텐서플로, pytorch

모델 학습 및 평가

• 피쳐 셀렉션의 두 가지 전략: 다 넣자 vs 상관관계에 따라 선택하자
• 절충안: 다 넣고 상관관계가 높은 피쳐에 웨잇을 더 가하자
• 피쳐 엔지니어링 & 셀렉션 작업 시작 (data prep등 활용)

• 모델 배포 > 아무거나 써도 됨

비즈니스 임팩트 실현

데이터 QA의 경우 예전에는 QA 엔지니어가 하다가 최근에는 데이터 엔지니어가 데이터 검증 레이어를 만들어서 ETL툴에서 Validation를 자동화 하는 경우가 많음.

세션 3: 온라인 게임 데이터 분석 사례와 향후 과제 - 이은조님

1. 온라인 게임 데이터의 특징

현실세계와 매우 유사한 환경과 경험 제공

• 성장 활동: 퀘스트, 레벨얼, …
• 경제 활동: 사냥/채집, 거래, 경매, …
• 사회 관계: 친구, 파티, 길드/혈맹, …

거의 모든 종류의 데이터 분석 가능

• 소셜 네트워크 분석
• 텍스트 분석
• 이미지 및 동영상 분석

데이터 활용 사례

• 게임 현황 지표 및 심화 분석
  • 주요 업데이트 전/후 효과 및 동향파악
  • 매출, 게임 활동 관련 지표
• 기계 학습 및 통계 모델링
  • 재화 이상 탐지
  • 작업장 탐지
  • 모바일 광고 어뷰징 탐지

2. 불쾌한 골짜기 (Uncanny valley) - Robotics

• Uncanny valley: 로봇 외형을 점점 인간과 비슷하게 만들다 보면 오히려 이질감이 커지는 지점이 발생함.
• 데이터 분석 기법을 고도화 하다 보면 오히려 활용성이 떨어지는 순간이 발생함 (처음에는 현황 지표만 볼 수 있게 되어도 성과가 있지만, 고도화된 기법을 도입하다 보니 성과가 떨어지게되었음)

무엇이 불쾌한 골짜기를 만드는가?

• 데이터
  • 부정확한 레이블
  • Concep drift
• 모델링
  • 비용을 고려하지 않은 예측 분석
  • 잘못된 테스트 셋 선정
  • 모델의 복잡함
• 서비스 구현
  • 테스팅 및 디버깅의 어려움

3. 어떻게 불쾌한 골짜기를 해결할 것인가?

데이터

오류의 원인

• 주관적 편향
• 불일치
• 사소한 실수

레이블 오류는 모델의 신뢰도에 직접적인 영향을 끼침

• 학습할 레이블 양이 많지 않다면?
• 오탐이 있으면 안되는 민감한 분야라면? (ex. 리니지 일부 영구정지자들 소송 사례)

엄밀한 레이블링 프로세스 구축하기

• 2인 이상의 운영자가 같은 데이터에 대해 독립적인 판단 후 레이블 결과가 같은 데이터만 학습에 활용
• 판정 사유 기입 후 누적된 판정 사유를 정형화 및 목록화 하여 활용
• Leave One Out Cross Validation 사용 -> 99개의 데이터로 모델을 만들고 1개를 판정 -> 데이터가 이상하거나 잘못 레이블링 된 데이터

Weak supervision

낮은 신뢰도를 갖는 레이블로 어떻게 하면 높은 신뢰도의 모델을 만들 수 있을까?

Snorkel: labeling runction과 generative model로 이루어진 기계학습 시스템

• 레이블에 신뢰도를 부여하여 신뢰도가 높은 데이터는 높은 학습 가중치를 부여하고, 신뢰도가 낮은 데이터는 낮은 학습 가중치를 부여함

불명확한 레이블 문제 -> 확률로 표현

애초에 레이블 기준이 모호한 경우도 있음

• 이탈 예측: 가입/탈퇴가 불명확한 상황
• 이탈을 확률로 표현 -> Pareto/NBD model

Concep drift: 시간이 지남에 따라 대상 데이터의 통계적 특성이 변하는 상황

왜 Concept drift 문제가 많이 논의되지 않을까?

• 학계의 경우 지속성에 대해 고민할 필요가 없음
• 분야에 따라 데이터의 특성이 변하지 않을 경우: 개와 사람 이미지를 구분하는 모델

온라인 게임의 경우 콘텐츠의 소비속도가 어마어마하게 빠름

• 빈번한 게임 업데이트 및 이벤트
  • 게임 밸런스의 변화
  • 주요 컨텐츠 삭제 및 추가
  • 비즈니스 모델 변경

어떻게 대처해야 하나?

• Robust modeling
  • 시간에 영향을 받지 않는 피처로만 모델 구축 (정교함이 떨어짐)
• Change detection
  • 예측 성능을 지속적으로 모니터링하다가 성능이 떨어지는 시점에 재학습
• Online learning
  • 학습 / 적용 과정을 분리하지 않고 라이브 환경에서 지속적으로 모델 개선 (추천 분야)
• Citizen data scientist > 도메인 전문가들이 직접 데이터 분석에 참여 (분석도구, 인프라 제공)

2. 모델링

비용을 고려하지 않은 예측 분석

• 구매예측 ex. A 상품을 구매할 고객 > 마케팅과 상관없이 구매 (불필요한 마케팅 비용 발생)
• 이탈예측: 악성 고객이나 잔존 가치가 낮은 고객을 예측 대상에 포함해야 할까? 잔존 가치가 높은 고객에 대한 이탈을 잘 맞추는 것이 중요

사례: 전체 고객을 예측 대상에 포함 vs 충성 고객만 예측 대상에 포함

• 예측 성능: 1 > 2
• 기대 이익: 1 « 2

아이디어: 애초에 목적에 맞는 비용함수를 사용할 수는 없을까?

잘못된 테스트 셋 선정

• 모델 성능 측정에 사용해야 하는 테스트 데이터는 가장 최근 시점의 데이터

모델이 복잡할수록 유관 부서에서 사용할 가능성은 떨어짐

• 고객 세그멘테이션할때 k-means clustergin을 많이씀 (설명하기 쉬움)

3. 서비스 구현: 테스팅과 디버깅의 어려움

• 문명 6 AI오류 사건: 산출량(Yield) 관련 설정치 이름 오타

심지어 오류가 있어도 결과가 나온다..(심지어 잘..)

• word2vec 윈도우 사이즈 사례

세션 5: 맛있는 데이터를 물어다주는 멍멍이 - 노상래님

1. 소개: 마켓컬리와 데이터 농장

마켓 컬리(식료품 전문 유통업체)

최적의 서비스 제공을 위한 상품 소싱/제조, 주문처리, 재고관리, 배송, 데이터 분석, 큐레이션

데이터 농장

하는 업무

• Ad-hoc
• IR제작
• 데이터 프로덕트
• 알고리즘 프로덕트
• 대시보드
• 분석용 데이터베이스 구축

(달리는 차 위에서 바퀴를 교체하는 사진) -> 빠르게 변화하는 회사에서 데이터 시스템 구축

2. 마켓컬리 데이터 시스템의 과거와 현재

지난 4년동안 시행착오

수기로 운영하던 엑셀의 시대

• 데이터 분석 & 운영 업무에 관련된 대부분의 데이터가 엑셀 자료로 이루어진 시기
• 데이터 분석에 너무 많은 시간이 소요
• 통합이 어려움
• 데이터 수집을 위한 발품팔이

AWS 시대

• 회사의 급성장으로 인한 예측 시스템의 필요성 대두
• 인프라를 도입하며 분석용 데이터 인프라 설계
• 슬랙에서 주요 지표와 전사 공유 시스템 도입: 데멍이

문제점:

• 데이터 인프라 설계 경험과 지식 부족
• 데이터 추출이 가속화되면서 추출 업무만 하루에 20개씩 진행 -> 대시보드 개발의 필요성 대두

자체 봇 & 실시간 대시보드 시대

• 데이터 플랫폼 인프라 확대
• 주요 지표 대시보드 운영 (고객 현황, 상품 현황, 배송현황 등)
• 각 기능별 팀별 실시간 대시보드를 통한 업무 효율화
  • 30분 단위 현황 공유
  • D-1 전일 주요 현황 전사공유
  • 운영 데이터 수집 관리
  • 예상 매출액

피드백을 기다리는 야옹이 -> 데이터 운영 시스템에 대한 피드백

데이터와 비즈니스 이해 집중 -> 데이터 인프라 관리 집중 -> 데이터의 가치 활용 집중

3. 데이터를 물어다주는 멍멍이 ‘데멍이’: 데멍이의 역할과 예측 퍼포먼스

데이터 과학으로서의 가치: 예측 시스템 (매출 예측, 물류 예측)

• 주 예측(과소 예측 경향), 일 예측(과대 예측 경향) > 결합해서 사용 (페이스북 prophet 활용)

퍼포먼스 성과: 월간 예측 성과 오차율 3% (실제값-예측값/실제값) 달성

조직 문화로서의 가치: 공유 시스템: 전사 지표 공유 (담당 팀에게 실시간 지표 공유)

4. 급성장하는 회사에서 데이터는 우리 조직문화에 어떤 기여를 하였는가

데이터 업무의 효율화 > 인사이트 도출 > 같은 눈높이의 공유 문화 > 조직 문화 발전

초기에 인사이트에 집중하지 않고 운영업무 자동화를 먼저 진행했음

세션 6: MOBILITY X DATA : 모빌리티 산업의 도전 과제 - 변성윤님 (쏘카)

주제: 모빌리티에서 어떤 데이터가 있고, 어떤 문제를 풀고 있을까요?

• 모빌리티 업계 (Car sharing / Ride hailing)의 데이터
• 모빌리티 업계에서 풀고 있는 문제가 어떤 것이 있을까?

1. Mobility?

사람들의 이동을 편리하게 만드는 각종 서비스 (전통적인 교통 수단 + IT를 결합해 효율과 편의성을 높임)

CES 2019 -> 주요화두로 Concepted Car, Self Driving Car 등

• Concepted Car: 컨셉을 가지는 차량

  컨텐츠를 즐기는 차량, 회의를 위한 차량 등

• Map: 고정밀 지도 데이터

  디테일한 정보를 가진 지도데이터가 필요함. 1차선인지 2차선인지, 정보 등

• Driver Status Monitoring

  운전자가 흡연을 하는지, 졸고 있는지 등 상태를 모니터링해서 알람 및 사고 예방 (주로 컴퓨터 비전 활용)

• Car Maintenance with AI 차량 유지보수에 소요되는 다양한 것들을 자동으로 탐지하고 Report작성 (오일 누수, 부품 미스매치, 차량 스크래치 등 등)

모빌리티 회사들

서비스

• Car Sharing: 자동차 공유 비즈니스를 하는 회사
  • Station Base: 지정된 곳에 차량을 반납하는 역 기반의 카셰어링
  • Free Floating: 자동차 반납처가 지정되지 않은 유동식 카셰어링
• Ride Hailing: 이동을 원하는 소비자와 이동 서비스를 제공하는 사업자를 실시간으로 연결해주는 회사
  • 우버, 타다, 그랩 등등

차량

• 주차장
• 자율주행
• 안전 & 보안
• 센서

2. 모빌리티의 데이터

데이터의 종류

• 차량 데이터
• 좌표, 지리데이터 (GPS, 지리 데이터 등)
• 센서 데이터 (엔진 상태, 배터리 전압상태, 주유 데이터..)
• 고객 데이터 (면허 취득 날짜, 사용 이력 패턴, 앱 로그, 결제 데이터)
• 날씨 데이터 (기상청 날씨 데이터)

왜 재미있을까?

• 삶과 밀접한 데이터
• 생활 패턴 반영
• 큰 의미에서 도시계획 & 사회발전에 밀접
• 어려워서 매우 재미있음
• 다양한 데이터의 혼합

모빌리티의 데이터를 보려면

• NYC Open DATA (Taxi)
• awesome-public-datasets - transportation 데이터

3. 모빌리티의 다양한 문제들

Car Sharing

ex. 쏘카 경험 여정

• 쏘카존에서 차량 대기
• 차량 예약
• 쏘카존 방문
• 차량 탑승
• 차량 이동
• 차량 반납

데이터 기반 존 및 차량 운영 전략 수립

• 특정 존 개발 (어디에) / 차량의 가격 설정
• 어떤 존에 어떤 차량을 넣어야 할까
• 수요 예측 및 운영 전략 수립
• 차량 구매 전략 (성수기)

주로 활용하는 방법: Operation Research (수학적 모델링, 통계적 모형, 최적화 기법 등을 활용해 효율적인 의사결정을 돕는 기법)

차량 예약

• 개인화된 가격 (쿠폰 및 혜택)

차량 퀄리티 관리

• 소모품 교환 및 세차 주기 최적화
• 차량 배터리 수명 관리

차량 이용 과정에서 사고 관련

• 차량별/ 개인별 / 상황별 보험료 산정

운영 정책 효과 분석

• 신규 상품 기획 (쏘카 구독제 등)
• 운영

Ride Hailing

타다 경험 여정

• 차량 호출
• 차량 배차
• 차량 도착
• 고객 탑승
• 목적지로 출발
• 도착

차량이 언제 도착할까? (ETA)

• ETA: 도착 예정 시간 (늦는 경우 고객경험에 악 영향)
• 머신러닝을 통해 정확한 ETA값 예측

차량 수요 예측 시 탄력 요금제 적용

• 갑자기 비가 내리는 경우
• 새벽 2시에 월드컵 결승
• 불금, 연휴 전날 수요증가

우버의 Surge Pricing: 급증하는 시간대, 지역에 탄력 요금제 설정, 차량 구매 전략에 활용

알고리즘을 오프라인에 바로 적용하는데 큰 리스크 존재: 리스크를 줄이고 실험을 다양하게 하기 위해 시뮬레이션 환경을 구현

• 머신러닝 모델을 테스트하기 위해 과거 데이터를 기반으로 확률 분포를 통해 시뮬레이션 환경 생성

• 실제 환경과 비슷하게 구축하는 것이 매우 중요

(SimPY: 간단히 체험할 수 있는 라이브러리)

지도, 네비게이션 문제

• Route Planning
  • 출발지에서 목적지까지 어떤 경로로 갈 것인가 (최소 시간, 최단 시간)
  • 교통량 예측
  • Map Matching: GPS 데이터와 도로 데이터를 매칭

산업의 성숙도에 따라서 풀어야 하는 문제 단계가 다름

세션 7: 데이터가 흐르는 조직 만들기 - 양승화님 (마이리얼트립)

마이리얼트립 매출이 급성장 중이었는데 데이터에 대한 고민을 하고 있었음.

• 데이터를 기반으로 일하는 회사를 만들자
• 데이터를 바탕으로 000 문제를 해결하자

Growth팀에 기대하는 역할

• 핵심지표 선정 및 관리
• 데이터 파이프라인 설계 및 구축
• 주제별 데이터 분석 (차근차근 하면 되는 것)
• 데이터 추출 및 분석 요청 대응 (당장 시간을 제일 많이 쓰는 것)
• 데이터 기반으로 일하는 문화 (어떻게 해야 할 지 막막한 것)

혼자 였음.. 분석하려면 야근을 해야되…

1. 데이터 분석 팀과 실무자와의 갈등

실무자 입장

• 어떤 데이터가 있는지 모르겠음
• 간단한 요청인데 오래걸려..
• 요청하고 받았더니 단순 합계, 평균인데,..
• 업무에 쓸만한 건 없네

분석가 입장

• 여기저기서 쏟아지는 데이터 추출 요청에 정신이 없다
• 목적이 000인 것 같은데, 이 데이터를 달라고?
• 대시보드 만들면 고쳐달라고 하고 잘못했다고 하고
• 데이터 분석 좀 해보고 싶다 ㅜㅠ

2. 뭐가 문제인가?

문제가 아님

• 대시보드가 잘 되어 있는데도 계속 요청한다 > 보다보면 궁금한게 생김
• 조금씩 조건을 바꿔서 자꾸 요청한다 > 쓸만한 인사이트나 아이디어는 데이터를 다양한 각도에서 살펴봐야 답이 나옴

이건 문제

• 데이터 분석가들이 추출만 하고 있다. > 다른일 할 시간이 없다.
• 데이터 추출 요청이 명확하지 않아 추출에 시간이 오래걸린다.
• 데이터 추출 요청하는게 번거롭고 데이터팀의 눈치를 본다.
• 데이터 분석을 데이터팀에서한 한다.
• 데이터팀에서 분석한 결과가 서비스에 반영되지 않는다.

3. 지향하는 조직

프로세스와 역량을 갖춘 회사

• 복잡한 절차 없이, 필요한 데이터를 누구든 찾아볼 수 있고 가공해서 인사이트를 찾을 수 있다.
• 데이터 분석가들이 본업에 집중할 수 있다.
• 분석 결과물들이 체계적으로 쌓이고 실제 서비스에 반영된다.

요청자와 분석가의 역할이 명확하게 구분되지 않는 조직

4. 데이터가 흐르는 조직을 만들기 위한 노력

1) 사내교육: 데이터 추출과 분석을 위한 기본 지식 쌓기

데이터 분석을 위한 마인드셋

• 왜 데이터 분석이 필요하고 내 업무에 어떻게 적용할 것인가

  데이터 분석의 목표: 서비스를 운영하면서 쌓이는 유저 데이터를 바탕으로 서비스를 지속적으로 개선해 나가는 것

SQL

• 동영상 강의를 지정해서 수강하게 함 (자기주도 학습)
• 서비스 DB에 대해 설명
• 써먹을 수 있는 과제를 출제

Excel

• 실제 업무에서 필요한 문제들을 풀기 위한 스킬들

사내교육이 의미 있으려면

• 주기적으로 해야함
• 리더의 의지와 지원이 필요함
• 배운 걸 즉시 써먹을 수 있는 환경이 지원되어야 함
• 배운 걸 실제 업무에 써먹고 있는지 체크해야 함 (업무에서 잘 활용하고 있어야 함)

2) 시스템

데이터 파이프라인 만들기

• 구성원들이 자유롭게 쿼리할 수 있는 환경을 만드는 게 시작

간단한 BI툴에서부터 시작

• (추천: redash)
• (추천: Stitch > 데이터 엔지니어 없이 ETL하기)
• (추천: 빅쿼리)

3) 조직문화

업무환경

• 리더의 의지 (매우 중요함)
• 데이터에 대한 폭넓은 접근성

조직구조

• 낮은 부서간 업무 장벽
• 고립되지 않은 분석 조직 (R&R이 모호한 구조)

일하는 방식

• 지표를 명확하게 정의하고 사용해야 함 (사람마다 정의가 다름)
• 반복되는 실패, 지속적인 실험

좋은 질문을 찾는 노력

(조직구성)

• 그로스팀 > 데이터 기반 회사를 만드는 조직
• 크로스셀TF > 데이터에 기반해서 핵심지표를 개선하는 팀

(꼭 데이터가 있어야 시작할 수 있는 건 아님 > 데이터가 없어도 연역적으로 예측했던 사례도 있었음)