2019년 10월 19일 (토) 광화문 MS 사옥에서 진행된 데이터야놀자에서 듣고 메모한 내용을 적어 보았습니다.

1. Serverless에서 유저 컨텐츠 추천 서비스 in 빙글

  • 추천 시스템의 정의? -> 좋아할 만한, 관심 있을 만한 아이템 자동 제공
  • ‘읽지 않았던’ 컨텐츠를 자동으로 제공해 주는 것. 컨텐츠 간의 유사도를 매겨야 함
    • Euclidean, Jaccard, cosine similarity(여기서 많이 사용. 크기가 아닌 각도 사용)
  • 유저 추천: user-based vs contents-based
    • user-based
      • 유저들이 좋아하는 항목(예: [1,1,0,0,1])들의 코사인 거리 계산
    • contents-based
      • 컨텐츠 특성들의 코사인 거리 계산
  • 빙글의 Serverless Architecture
    • AWS S3, Athena 등 사용
    • id별 similarity 데이터를 json 형태로 저장하여 SQL 쿼리만 날리면 가져올 수 있게 함
  • 인스타그램 Tag 이용!
  • K-means 클러스터링 문제: random centroid(centroid들이 너무 밀집될 가능성이 있음), unbalanced input(DBSCAN 써야하는 인풋 데이터)
    • K-means++: 너무 가깝게 centroid가 지정될 확률이 작아짐.
    • Spherical K-means: 거리 계산을 Euclidean 말고 cosine으로 바꿈 -> 거리가 아닌 각도를 계산하여 더 비슷한 것들을 추천할 수 있게 함
  • 개발상 문제: 유저가 api call 할 때만 추천 시스템을 새롭게 생성해야 함. 불필요할 경우에도 추천하면 메모리 낭비
    • sql 쿼리는 상관 없는데, sklearn 갔다 오는게 오래 걸림. 이 과정을 최적화하여 소요 시간 줄임
    • python model(sklearn) 말고 Typescript로 직접 만듦 -> 유지보수를 계속 할 수 있게
  • 추천 시스템: 검증이 어려움. 시스템을 만들었는데 유저 만족도가 좋지 않을 수 있음.
    • ex) input data가 적을 경우
  • Q&A
    • 데이터가 많아질 경우 matrix 계산 등 어려운데, 어떻게 했는지?
      • 이전의 모든 컨텐츠를 가져온 것이 아니라, 날짜 등으로 필터링하여 조건에 맞는 데이터만 가져왔음. 데이터가 엄청 많은 heavy user도 별로 없었음
    • K-means의 K는 어떻게 정했는지?
      • 유저들에게 추천되는 컨텐츠 수를 보고 결정
    • Light user들은 input data가 적어 추천이 잘 되지 않음. 어떻게 해결했는지?
      • Guest(로그인 안한 유저)들이 본 컨텐츠 등 이용하여, 기존에 있었던 컨텐츠 보여줌(추천 시스템은 아님)

2. 나의 리터러시 != 너의 리터러시: 잘 전달하기 위해 데이터 시각화할 때 고려하는 것들

  • 언론사 디자이너 관점에서 시각화 경험(인포그래픽 등) 공유
  • 사용자 중심의 디자인(리터러시)
  • 네이버 뉴스: 80% 이상 모바일로 접속
  • 같은 데이터를 가지고 다양한 시각화 (사람마다 다르게)
    • DVL(Data visualization & Literacy) 연구 중
  • KBS 디지털뉴스: 데이터룸 있음. 취재기자, 개발자, 데이터분석가, 디자이너 등으로 구성
  • 2019.10.17 기사: 프로야구 전력차 ~년만에 최대
    • 기사 원고와 데이터를 가지고 스케치(구단별 승률, 전력 분포도)
    • 카테고리별 산점도 보기, 연도별 구단 전력 표준편차 등 막대그래프로
      • 근데 산점도, 표준편차 이런 개념들도 설명하기 어려울 수 있음
    • 박스플롯 등 의미를 잘 모르면 전달 어려움
      • 대신 한 선에 야구공 위치 그린 그림 좋은 듯
  • 분석가가 R로 시각화하는 경우: 거의 없음
    • R to illustrator 이용하기도 함
    • 데이터를 받아서 다시 시각화함
  • 보통 스압 있는 건 잘 넣지 않지만, 한국이 행복지수 최하위인 데이터는 되게 긴 그림을 넣어서 모바일에서 스크롤 쭉 내리면서 체감할 수 있도록 하기도 함
  • 모바일용, 데스크탑용 따로 제작
  • 개발자가 사용하는 색, 디자이너가 사용하는 색이 다름
    • 색각이상자 고려. 총 인구의 3% 정도 되기 때문
    • 적록색맹이 가장 많기 때문에 적/록 배색은 잘 하지 않음
  • 매직넘버 4: 작업 기억 한계 용량. 그래서 색상을 3~5개로 사용 제한하기도 함
    • 일반인에게 보이는 색 / 적록색맹에게 보이는 색 고려하여 색상 조합 선택
  • 보통 원/꺾은선/막대로 거의 표현하는데, 이걸로 나타내기 어려운 경우 다른 시도 하기도 함 (정당 지지율 그래프인 듯)
  • 스크랩 많이 하심. 토픽별, 목적별로 시각화가 다름
  • 데이터 속성을 고려하여 모양, 문자, 방향, 여백 등 고려함 (일종의 시각화 번역 작업)
  • 컬러 툴 활용. 포토샵, 구글 spectrum, 구글 colorpick ~, chroma.js 등
  • 색상들의 느낌 고려

3. 한글 검색, 고민해야 할게 많아요

  • 슬라이드
  • 대기업, 스타트업 등 일 하시다가 엘라스틱에 푹 빠져서 여기서 일하시는 중
  • Elastic
    • 검색 엔진. 꼭 텍스트, 숫자를 치지 않더라도 지도 앱에서 손가락 줌인, 줌아웃 하는 것도 검색 행위. 조건(좌표)에 맞는 데이터를 찾아주는 것
    • 윈도우 탐색기에서 파일 찾을 때 등 사용
    • 시계열 데이터를 가지고 로그 분석하는 기능도 있음. 전세계 배틀넷 서버도 분석
    • 검색엔진 1위, 전체 DB에선 7위. DB 순위에도 들어가는 게 흥미로웠음
  • ELK 스택 (엘크): Beats가 추가됨
  • IT 기업의 딜레마: 회사 제품 등 홍보하는 건 발표가 잘 허용되지 않음. 다만 서비스 운영사 등에서 ‘Elastic을 이용하여’ 발표하는 내용 등이 있음
  • Elastic Stack을 이용한 지하철~~: 발표 데모 자료로 많이 쓰였음
  • Kibana: ELK 스택 중 시각화 도구. 한 번 써보기
  • 유튜브 Elastic Stack 활용 데모 -> 봐 보기. 연습하는 데 좋음
  • 오늘 발표 내용: 제작 과정 중에 한글 검색을 구현하면서 발생한 에피소드
    • 과거에는 한글 검색 전혀 고려하지 않았음. 역검색이 한글로 가능하도록 함
  • 검색 엔진: 기본적으로 Full Text 검색이 가능해야 함
    • DB는 인덱스별 단어를 저장
      • 키워드가 늘어나면 데이터가 많아짐
    • ES는 단어들의 위치(색인)를 저장 -> 그래서 테이블의 형태가 다름
      • 데이터가 늘어나도 키워드의 수가 많아지는 경우가 적음. 다만 인덱스의 개수가 많아질 뿐(예: 1,2p -> 1,2,5p)
    • 대소문자 편집, 관사 삭제, 영어는 s(복수형)를 원문으로 저장. jumps 검색해도 jump 나올 수 있도록
    • 동의어 검색도 가능하게 함. fast - quick
  • 한글 검색은 좀 다름
    • 무작정 띄어쓰기로 구분하면 안 됨. 동해물과 백두산이: 동해+물 / 백두+산
  • 한글 형태소 분석기: 은전한닢, Nori 등
  • 지하철 역 정보 데이터셋 + 다국어(한/일/영) 데이터셋
    • 모든 역에 역 code가 있지는 않았음. 역명은 데이터셋마다 다르기도 함.
    • Nori: 일반 텍스트(영어). standard analyzer
    • Nori-only:
  • 홍대입구 역
    • 스탠다드 애널라이저는 “홍대입구”로만 저장. 홍대로 검색하면 안 나옴
    • nori_only: 필드 만들어 입력 텍스트, 저장되는 텍스트가 모두 한글 형태소 분석기 통해 처리
    • 이러면 홍대+입구 분리되어 ‘입구’에 해당하는 역도 모두 나옴. 서울대입구 등
    • 관련된 최대한 많은 결과 보여줄 건지(쇼핑몰 추천), 가장 정확한 거만 보여줄 건지는 서비스의 형태에 따라 결정
    • station.name.nori 필드
      • 저장은 홍대, 입구, 홍대입구 모두 저장
      • shingle 토큰 필터로 가공 처리: Ngram 토큰 필터와 비슷함.
        • Ngram: house가 있으면 h, ho, hou, hous 모두 저장
          • 원문이 짧아도 저장 용량이 매우 많음
          • 다만 세세한 검색 필요한 경우(알파벳 하나만 쳐도 나올 수 있게) 좋음. 자동완성 기능 사용시
        • Shingle: this is my sweet home 있으면 this is, is my 등을 저장. 구문 검색시 유용
      • 검색은 스탠다드 애널라이저로 함. 그래서 홍대, 입구 등으로 검색해도 홍대입구가 나옴
  • 게스트 계정 데모 가능: https://ela.st/cloud-kr
  • ES: 쿼리도 json 형식으로 되어 있음. 위 사이트 들어가서 requests 보면 json 형태로 나옴
  • 텍스트 뿐만 아니라 위치 정보도 담고 있기 때문에, 우버나 가까운 호텔 찾기 등에도 사용
    • 우버 경우 같은 경로를 가더라도 실시간 정보에 따라 수요, 공급이 바뀌면서 가격이 바뀜
  • 페이스북 그룹 elasticsearch.kr도 있음
  • 책 정보, 블로그

IGNITE: 식습관 스몰데이터 분석을 통한 장트러블 극복기

  • 장 트러블에 영향 있는 음식군
  • 쾌변에는 생활 습관, 운동 등 여러 영향 있지만 경험적인 근거를 통해 식사 데이터 수집
  • 메뉴들의 맵기, 차가운 것, 커피 등
  • 쾌변한 정도, 화장실 간 시간/횟수
  • 설명변수: 알코올, 우유 등. 변수 backward 제거
  • 그래서 앞으로 화장실에서 보낼 시간 예측

4. 카트라이더 TMI 포스트모템

  • tmi.nexon.com: 카트라이더 전적검색
  • 넥슨에서 데이터로 하는 일들
    • 대규모 작업장 제재
    • 유저 이탈 예측
    • 플레이스타일에 맞는 아이템 추천
  • 발굴하기 어려운 패턴 찾아내기
    • 당연한 패턴을 증명하는 것이 아니라 이게 어려운 것 같음(개인적으로)
  • 성공하기 어려운 지름길 가는 방법 -> 데이터 분석
    • 폭포에 걸치지 않아야 통과한다!
  • 이런 인사이트들을 모아서 전달해주면 재밌지 않을까?
    • 그래서 TMI 서비스 기획
    • e스포츠 대중화, op.gg 같은 것들 이용
  • 게임 생태계가 과거보다 복잡해짐
    • 단순히 서비스 제공/사용(단방향 패턴)이 아니라 데이터 제공, 유저 커뮤니티 형성, 맞춤형 전략 등
  • 넥슨 게임은 이보다는 덜 복잡
    • 단방향 패턴 + 게임 공식 카페, 나무위키로 정보 공유
  • 카트 유저스탯 프로젝트
    • 어떤 카트바디가 좋을지, 내가 레이스를 얼마나 잘했는지 전달
    • 이 트랙에서는 어디를 조심해야 하는지, 다음에는 어떤 트랙 타볼지 추천까지!
    • Q: 플레이어별 경기 기여도도? 야구의 WAR 같이
  • op.gg같은 플랫폼은 넥슨엔 왜 없나? 라는 의문에 전적검색 데이터 플랫폼 개발
    • 기존 데이터 외의 새로운 로그를 남겨야 하는데, 이 자체가 게임 서버에 부담이 됨.
    • 실시간 데이터를 안정적 으로 보여줘야 함
    • 높은 불확실성 + 긴 파이프라인(데이터) -> '해 보고 안 되면 빨리 접자'
    • 9개월간 실 서비스 운영까지 개발
  • 뭘 만들까?
    • 우선 개발 구성원들이 유저로서 뭘 보면 좋을지 구상
  • 보통 데이터분석은 서비스가 나온 이후에 함
    • 이거는 처음부터 데이터 분석 통한 서비스!!
  • 유저의 x,y 좌표 찍힌거 모으면 트랙이 나옴!! 흥미로웠던 시각화
  • 사고다발 구역, 주행 경로 gif로 보여주기 되게 재밌어 보임
  • 고수들의 주행경로: 부딪히지 않고 가는 궤적
  • 초반 데모 만들어 보고 정말 재밌어 보이는지 확인
  • 베타 개발(POC) 착수 단계(실제 서비스): 팀 규모 확장
    • 이 단계에서도 모두 개발하지 말고, 가장 dependency가 적은 것부터 개발해서 간을 보자! 복잡한 api 필요 없는 부분부터.
    • 카트라이더 겨울 리그 활성화로 인해, 선수들의 주행 경로 파악. 경로는 더 길어도 더 빠르게 타는 법 볼 수 있음
    • 베타 출시 후 회고
      • 주 단위로 목표 명확히 하여 개발한 후 평가하는 방식으로
  • 하지만 오픈하고 잠깐 잘 되다가 사용자 수 급감..(GA 데이터)
    • 평균 주행 속도 -> 이런 것들은 사용자들이 크게 관심 가지지 않음
    • 이제 어떤 서비스가 더 필요한지 고민.. 설문조사 등 생각함
    • 근데 전적 사이트는 전적이 핵심!! 내가 잘 탔는지를 보고자 하는 것
    • 최근 500판을 모드에 따라 데이터 보여주기. DC 카갤, 네이버 블로그 등 바이럴 타기 시작함
    • 사용자 수 안정화됨(감소 추세 보이지 않음)
  • 정식 출시 및 대규모 업데이트
    • 주간별 가장 잘 탄 경로 보여주기 등
    • 근데 결국 내가 탄 정보 를 보고자 하는 건데, 이러면 데이터가 너무 많아 aws 비용 많이 나옴
    • 가장 좋은 경로 보여주기 통해, 내가 그거 참고해서 주행할 수 있도록 함
  • 정리
    • 유저 전적 업데이트 후 사용자 수 대폭 증가
    • 실패한 기능도 있음. ex) 카트바디 비교
      • 그럴듯 해 보이는데, 순정 카트바디보단 업그레이드 부품 통한 강화가 많아서 실용성 없음
    • 채널 파워의 중요성!!
      • 배너 위치를 게임시작 옆에 두었더니, 이용자 수 30% 증가
      • 컨텐츠 만들어 놓으면 알아서 들어오는 것이 아니라, 이런 비즈니스적인 영역도 중요
    • 배너 종류 A/B 테스트
    • 유튜버/파워 크리에이터의 힘: 컨텐츠 사용한 영상 남기면 넥슨 측에서 피드백하는 쌍방향 소통
    • 짭방봇: TMI 사이트 크롤링하여 어느 선수가 잘하는지 시각화하여 보여줌
    • 전적 서비스의 단점
      • 메타 데이터를 관리해야 하는 인프라 비용이 많이 들게 됨
      • 서비스 유지보수도 해야 함
      • 게임 수명이 짧기 때문에, 이런 데이터 나오기 전에 서비스 종료되는 게임도 있음
  • 넥슨 오픈 API도 있음!!
    • 피파는 운영 중. 카트는 예정

5. 헬스케어 데이터 실습

  • 헬스케어 전문 스타트업 라인웍스
  • 작년 발표 이후 진전상황 보고
  • 애플: 병원 갔다오면 진단 결과 보여주는 서비스
    • 이런 관련 정보는 블로그에 있음
  • 실습 내용: 집에 가서 할 수 있게 설명
  • MIMIC-III 데이터: EMR 데이터
    • 전자 메디컬 레코드. 구글 검색하면 논문, 블로그 등 많이 나옴.
    • 공식 문서의 퀄리티가 굉장히 좋음
    • 교육 + 테스트 이수해야 2,3일 후 데이터 다운 가능. 남용 막기 위해
  • 타겟 정의 및 라벨링: 도메인 지식 필요한 부분
    • 보통 사망. or 조건의 조합(응급입원 후 수술)
    • 퇴원 후 30일 내 재입원: 이럴 경우 병원에 페널티 있음.
      • 농담으로 퇴원 후 31일에 오는 환자 예측하기도 함
    • 사망 후 재방문하는 경우 있음 -> 이상한게 아니고 장기이식하는 경우.
    • ‘한 번의 방문’ 안에 여러 데이터가 있음. 검사, 투약 등
  • 사용할 변수 선택 -> 임베딩을 통한 코드 변환 방법이 있음 (Skip-gram)
    • 단어(변수들)을 합쳐서 문장으로? 더 알아보기
  • 의료 데이터의 경우 데이터 quality 문제 때문에 모델에 따라 성능에 월등한 차이가 나지 않음
    • 그래서 Linear Regression, LightGBM 부터 시작
  • 다른 데이터와 똑같이 프로세스 진행!
    • 퇴원후 30일 이내 재입원을 예측했을 때, AUROC가 65~70정도면 준수함. <60이거나 >80이면 뭔가 문제가 있거나 의심해 보야아 함
  • Q&A
    • 데이터 퀄리티 문제는 어떻게 해결했는지?
      • 병원마다, 간호사마다 쓰는 코드나 적는 내용이 많이 다름. 자기들끼리만 알아먹을 수 있게 쓰기도 함
      • 그래서 애플에서 하고 있는 것: 병원 레코드 표준화 가이드라인
        • 의료 코드 등을 병원마다 달리 하지 않고 공통화할 수 있도록
        • 병원에서 환자에게 데이터 주고 싶다면, 데이터 형식도 HL7 FHIR에 맞게 요청
        • 구글에서는 fake data 만들기도 함

6. 데이터 분석팀과 이스포츠 선수단의 신뢰 쌓기 프로세스

  • 23개국 4,500만명이 이용하고 있는 서비스
  • 데이터 분석가와 현업 전문가의 컴케
    • 서로 알고 있는 것과 원하는 방향(싱크 라고 표현)이 다르기 때문에, 업무에 대한 신뢰관계 형성이 어려움
  • 스포츠 분야에서의 데이터 분석가
    • 사무국 소속. 코칭스태프와 컴케
    • 코칭스태프는 선수 출신이기 때문에, 자료 해석을 직관적으로 이해하는 데 어려움 느끼는 사람이 있음
    • 하지만 최근 세이버매트릭스 활용으로 보편화되고 있음
  • e스포츠 분야에서는?
    • 대부분 게임은 생긴 지 5년 이내. 선수와 코칭스태프의 경험 차이가 크지 않음
    • 주기가 매우 빠름
    • 이스포츠 분석 방법론이 많이 존재하지 않음. 공신력 있는 지표의 부재 -> 신뢰관계 쌓기가 어려움

1단계: 친해지기

  • 물리적인 시간 줄이기
    • 처음에는 경기 결과 데이터 및 로그, 자기장 이동 경로, 선수 기록 EDA 등 코칭스탭에 제공
    • 도움이 되지 않음!! 오늘 경기 질 거다라고 예측할 수는 없으니까.
  • PUBG 경기
    • 16팀까지 참여
    • 팀별로 암묵적인 랜드마크(떨어지는 위치)가 있음. 이걸 활용하여 게임 진행
  • 팀 선수들의 이동 경로를 코칭스탭이 수기로 그림
    • 이 사실을 알게 된 것도 몇 달이 걸림
    • 하루에 8경기 정도 하면 리뷰 영상 보고 기록하는 데 4시간이 걸림
    • -> 지도 그림을 팀마다 색 다르게 하여 자동으로 표시하는 작업 해줌!
  • 그럼 코칭스탭은 이 사람이 뭘 하는지 알아감
    • C(코치): 자기장 바뀌는 것도 그려 주세요!
    • 이걸 넘어서 경기 상황 파악할 수 있는 대쉬보드 제공

2단계: 게임 내 현상을 잘 표현하는 분석 자료 만들기

  • 주당 12라운드 경기. 40번 연습경기
  • 국내 팀들은 서로 스타일 알 알지만, 국제대회에서는 전혀 모르는 스타일의 팀을 상대해야 함. 영상으로만 접하던 팀
  • C: 국제대회에서 상대팀 특징 빠르게 알 수 있는 법?
    • 한 시즌 동안 각 팀들의 동선을 한 화면에 뿌려서 확인
    • 팀별로 동선 특징이 있음. 가운데 선호 or 구석 선호
    • 각 팀들의 랜드마크와 이동 방식 찾아냄!
      • 외곽 도는 플레이(장거리 사격 선호) or 중앙에 떨어져서 자기장 이동 방향대로 이동. 경로에 있는 적들 죽임
      • 교전 거리 분포를 통해 다시 확인. 18m vs 10m
      • 근데 이런 건 코칭스탭도 영상 분석하면서 확인할 수 있지만, 분석가가 게임 잘 알고 있다는 신뢰관계 형성

3단계: 데이터 분석으로만 얻을 수 있는 분석 자료 만들기 -> 분석다운 분석! C가 할 수 없는 일들

  • C: 사격 능력 향상시킬 수 있는 자료?
    • 맞는 부위에(총 5가지) 따라 데미지가 다름.
    • 선수들 반응 속도는 5초 이내. 그래서 5초 안에 상대방 사살해야 함
    • 선수들의 피격 정보를 봄
      • A 선수는 헤드나 torso 주로 맞힘 or B 선수는 몸통
      • 좌우 반동에 신경 쓰라는 코칭!
      • B 선수가 다음 시즌에 MVP 탐. 이 분석 때문인가?
  • 선수 퍼포먼스 측정 자료
    • K/D, Damage 등
    • 평가 기준, 선수들 포지션(ex: 엄호사격 하는 서포트)에 따라 이 기록이 아주 불리할 수 있음
    • 더 세밀하게: 총알/유효 총알 1발 사용당 피해량, 피해 발생 확률
      • 이걸 업그레이드 할 수 있는 코칭
    • 평균 명중 횟수를 바탕으로 선수들이 자기가 어디에 위치하고 있는지 분포를 보여줌
      • 자극제는 되지만, 독이 될 수 있음.
      • 적절한 컴케 방식을 통해 전달해야 함

4단계: 하고 싶은 거 다 해!!

  • 소통, 피드백 원활해진 상태
  • 선수들 평가하는 자료 구체화
    • 삼각형/사각형 가치 평가
    • 팀 리빌딩 시 어느 부분을 더 채워야 하는지. 선수 영입에 참고
  • 맵의 어느 위치에서 어느 무기가 잘 나오는지 분석
    • 첫 출발 시간이 5분인데, 이 전에 교전 준비를 마쳐야 함
    • 무기 안 나오는 곳은 죽어도 안 나옴!!
    • 안 나오는 집은 버리고 가능한 범위 내에서 동선 짜도록 함

여담

  • 팀 결과: OP GAMING 세계대회 우승
  • 나 덕분에 우승한 것인가?
  • 반대로 팀 성적이 좋지 않을 경우, 분석 quality가 좋지 않아서인가?
  • 큰 규모의 팀에서 전통적인 코칭 하다가, 데이터분석 프로세스 도입할 경우 어려움이 많음
    • 기존 규모에서 데이터분석가 1명 채용할 여력이 되는지?

7. 심슨의 역설

  • 심슨의 역설을 표, 벡터, 2차원 산점도 등 다양한 방법으로 소개
  • 데이터 분석시 ‘혹시 여기에도 심슨이!’ 하고 데이터를 쪼개보도록 하기
  • Pearl, Judea. Statistician -> 심슨의 역설 논문
  • 예시 2가지로 심슨의 역설 소개
    1. 신장결석 치료법 비교
    2. 야구 타율 데이터
  • 두 변수의 상관관계에서도 나타남
    • 회귀계수의 부호까지 바꿔버리기도 함
  • 수능점수와 학점의 관계
    • 전체 산점도에서는 별 상관관계가 없거나 음의 상관관계
    • 근데 이걸 과별로 쪼개 보면, 강한 양의 상관관계
  • 1인당 GDP와 삶의 만족도
    • 일단 x,y 데이터부터 ‘1인당 GDP’(즉 평균)이고 ‘평균’삶의 만족도임
    • 행복을 국가가 매기나? 행복은 개인이 느끼는 것
    • 그래서 아무 인사이트가 없다고 할 수도 있음
  • 정리
    • 내가 분석한 모든 데이터에 심슨의 역설이 있을 수 있다!!
  • Q&A
    • 단계마다 결과가 다른데, 어디까지 파고들어야 되는가?
      • 도메인 지식이 있는 상태에서 파고들어야 한다!
      • 해석이 가능한 수준 에서 파는 것이 좋다

8. 데이터 + 야놀자 = 야놀자에서 데이터를 더하는 법

  • 데이터 엔지니어링 관련
  • 신사업 확장 -> 새로운 데이터가 들어오는 것
  • 연관된 호텔을 추천했었다면, 항공권과 관련하여 여행지의 호텔을 추천해주는 것
  • 구글 빅쿼리, aws 아테나 등 적절한 쿼리 엔진 사용
  • 저장소 다양화, 배치/스트림(실시간) 데이터 이용
  • 피드백 루프(서비스 운영하고 다시 로그 수집하여 개선하는 시스템)
  • 지금은 사람보다 머신이 더 싼 시대!!
    • 머신 대신 사람이 더 필요할 경우
    • 아마존 같은 클라우드 머신 사용하면 운영, 유지보수에 필요한 작업 해결
  • 데이터 서비스를 할 때 고민해야 할 점
  • 머신러닝 엔지니어 vs 러닝머신 엔지니어
    • 전문가가 아닌 이상 러닝머신 엔지니어로 정의
  • 서비스의 데이터
    • product 기준 profile(좋아요 수, CTR, View 등)
    • user 기준 profile
  • 머신러닝 엔지니어가 없는 상태에선, 파이프라인을 연결하는 것만으로 의미가 있음
    • score 80% 모델을 이 파이프라인을 형성하여 만든 후에 숙련도를 쌓거나 머신러닝 엔지니어를 채용하는 방식으로
  • 초기에는 블랙박스 모델보다는 설명할 수 있는 투명한 모델을 쓴 후 블랙박스 모델을 쓰는 것이 적절
  • 에어비앤비: dynamic pricing. 수요자(싼 가격)와 공급자(비싼 가격)에 모두 맞게 책정
  • 부킹닷컴: 수수료율을 높이는 대신 리스트 랭킹 높여 노출 더 많게 할 수 있음

9. 데이터 교육 프로덕트 매니저의 고민과 실패 그리고 성장 이야기

  • Disruptive innovation model
    • Gartner에서 제안한 키워드의 성장 곡선
    • 실리콘 밸리에서 유행하면 우리 나라에는 3-4년 정도 뒤에 유행
    • 2017년: 딥러닝 절정. 따라서 올해 지나면 관련 비즈니스가 활발해질 것

(1) 기술교육에서의 파괴적 혁신: 산업의 수요 - 교육이 필요는 적정할까?

  • 채용 상의 문제
    • 기업은 인재가 없다 하고, 개인은 들어갈 회사가 없음
    • 기업이 어떤 사람이 필요한지에 대한 정의를 명확히 하지 않고 공고를 올리기 때문
    • 교육에서 배울 수 있는 것 + 회사에서 배울수 있는 것이 합쳐져 Job Description을 작성함
  • 정보의 격차를 이용하여 필요한 모든 것을 알려주려는 교육기관들이 있음
    • 부스트캠프같이 정말 필요한 것만 선택적으로 가르치는 교육기관이 좋다고 생각

(2) 어떻게 배워야 하는가?

  • 타겟을 정하고, 이 기술을 왜 배워야 하는지에 대한 의문을 해결한 후에 배우는 것이 적합함
    • 회사에 들어가면 어차피 기술 배움. 그래서 어떤 기술을 배웠는지보다 어떤 것이든 빠르게 배우는지가 더 중요할 수 있음
  • 기술교육의 목표
    • ‘들어서 좋았다’가 아니라 ‘적용 가능하여 의미가 있다!!’

(3) 그럼 뭘 배워야 하는가

  • 데이터 시각화: 포트폴리오로는 좋지만 막상 회사에선 큰 쓸모가 없음. 디자이너에게 맡기기도 함
  • 데이터베이스: 배우기 어렵지만 회사에서 유용
  • 머신러닝/딥러닝: 이걸 쓸 만한 데이터가 있는 조직이 많지 않음. 주니어 데이터 분석가에게 유용한지는 의문
  • 결국 필요한 것
    • R/python 자체가 아니라, 라이브러리 활용 능력
    • EDA 수준의 시각화, 기초통계 역
    • 실험을 통한 계획/실행력이 중요

(4) 언제까지 배워야 하는가??

  • 계속 대학원 가고 하다 보면 평생 공부할 수도 있음
  • 목표하는 회사를 정하고, 그에 맞는 수준까지 공부하는 것이 적절
  • 교과서대로 순서대로 배우다 보면, 많이 배운 것 같은 착각이 드는데 현업에서 필요한 수준과는 차이가 있을 수 있음
  • 회사에선 그럴 여유 없으니, 필요한 부분을 배워 가면서 영역을 늘리는 것이 적절
  • 동료를 활용한 지식학습
    • 동료와 질문하면서 내가 얼마나 깊이 있게 이해하고 있는지 알아가기
    • 현업에선 깊은 수준의 이해를 하고 있는가? 적용 가능한가? 이게 중요
    • 혼자 공부하면 내가 생각한 것이 정답이라고 생각하기 쉬운데, 여러 명이서 하면 피드백 하면서 정답에 가까워질 수 있음
  • 안전한 커뮤니케이션의 연습
    • 내 의견을 전달하면서 동료의 의견까지 적용하는 것
  • 궁극적으로 필요한 것: 탐색적 학습 & 전략적 집중(필요한 것을 찾아 선택과 집중!!)
  • 가중치: 재미있는 것 < () < 가치있는 것