[스터디파이] 데이터분석 3주차

0. 3주차 커리큘럼

 

1. WEEK 3 / DAY 1

카카오 AI 리포트 머신러닝의 적용 실제

[카카오AI리포트]머신러닝 적용의 실제

0. 인트로

안녕하세요. 책만 보면 심심하니까 오늘은 가벼운 아티클을 하나 공유드립니다.

'머신러닝 적용의 실제'라는 글이고, 제가 카카오에서 머신 인텔리전스 파트를 맡았을 때 작성했던 글입니다.

머신러닝이 굉장히 멋져 보이지만, 실제로 적용하려다보면 여러 문제와 마주하게 됩니다.

이 글은 현업에 머신러닝을 적용하게 되면서 제가 깨닫게 되었던 글들을 정리한 것입니다. 당시에 카카오 AI 리포트 6호에도 게재되었던 글입니다.현업에서 머신러닝을 적용하고 있거나, 계획하고 계신 분들에게 도움이 되면 좋겠습니다. 그리고 언제든 질문은 환영! 글에 스레드로 달아주시면 대답드릴게요~

 

2. WEEK 3 / DAY 2

깔끔한 데이터(Tidy data) 블로그 글

 

0. 인트로

안녕하세요 하용호입니다.

오늘 읽어보실 주제는 Tidy Data 입니다. https://partrita.github.io/posts/tidy-data/  발음은 '타이디 데이터' 더군요. tidy가 발음이 혼란스럽죵. 원래 tidy data의 경우는 R의 대부이신 Hadley Wickham 아저씨가 쓰신 https://vita.had.co.nz/papers/tidy-data.pdf (영어) 로 아주 유명해졌습니다.

 

우리가 데이터 분석을 위해서 임의의 자료를 접하게 되면, 다들 정말 자기 맘대로의 모습으로 정리되어 있습니다. 여기는 이런 값을 컬럼에 넣고, 여기는 이런 값을 레코드에 넣고. 다들 기준이 없이 정리가 되어 있거든요. 근데 이게 문제입니다.데이터 분석은 대체로 차트를 그리는 비주얼라이제이션 과정을 통해서 많이 하게 됩니다. 인간은 시각을 통해서 분석을 하는 생물이거든요. 그런데 이런 시각화 프로그램은 받아들이는 데이터 형태가 정해져 있습니다.

 

이 때 고생이 시작되는데, 주어진 '엉망엉망 자료구조' -> '시각화 라이브러리가 알아보는 자료구조' 로 바꾸는 일이, 매번 할 때 마치 새로운 문제를 푸는 것처럼, 시간이 많이 소요되고 굉장히 번거롭고 머리를 많이 써야 하는 작업이라는 겁니다. (이 필드를 이렇게 저기에 넣고, 요걸 이렇게 옮겨야 하나? 이런류 고민)

 

Hadley Wickham 아저씨는 이 때 이렇게 말합니다. "너가 한방에 그리 가려고 하니까 문제인거야. 모든 데이터를 한방에 목적하는 모양까지 만들려고 하기보다, 일단 데이터를 tidy data라고 부르는 형태로 한번 고치고, 그 다음에 원하는 형태로 변환하게 된다면, (그렇게 중간 지점을 하나 두게 된다면) 너는 어떤 데이터를 만나더라도 당황하지 않게 될거야. 일단 tidy 형태로 고치는 작업은 기계적으로 진행하면 되고, tidy형태는 이제 많이 접해보게 될테니 그 다음 어떻게 하는지도 잘 알게 될테니까."

 

그래서 tidy data는 '사람이 보기 쉬운' 형태라기보다는 '나중에 기계가 읽기 쉬운' 형태를 지향해서 만들어집니다.그래서 Hadley Wickham 아저씨가 주창한, 어떤 형태의 임의 데이터를 만나더라도, 일단 하는 데이터 모양 변환 작업이 tidy data 입니다. 원문은 영어 논문과 비슷한 형태로 되어 있고, 장수도 많아서, 자료를 찾아보니  https://partrita.github.io/posts/tidy-data/ 가 있었습니다. 임의의 데이터를 파이썬으로 tidy화 시켜나가는 과정이 잘 표현되어 있는데, python을 쓰시는 분이라면 중간에 코드까지 읽으시면 좋겠지만, 코딩이 익숙치 않으신 분들은 코드 부분은 건너뛰고 읽으셔도 충분합니다. "아 이런 원칙으로 이렇게 데이터 모양을 변환시켜 나가는구나" 만 잘 캐치해내시면 됩니다.

그럼 오늘도 재미나게 공부하세요

 

2-1. 내용

Tidy Data ( 깔끔한 데이터 )

-" 밑바닥부터 시작할 필요 없는 데이터" : 데이터 전처리의 표준화

 

1. Col : 변수 / Row : 관측치(값)로 구성

2-1. Col명이 변수가 아니고 값인 경우

Tidy Data 위해서는 melt 를 이용 (Pivot의 반대 개념)

formatted_df = pd.melt(df,["religion"], var_name="income", value_name="freq")

 

2. 데이터가 반복 되는 문제

- 테이블을 나눔

 

3. 다양한 변수가 하나의 열에 있는 경우

- 열을 나눔

 

 

3. WEEK 3 / DAY 3

구글의 데이터 비주얼라이제이션 가이드 훑어보기

[차트 유형]

- 시간 경과에 따른 유형

- 범주에 따른 유형

- 순위에 따른 유형

- 부분 vs 전체

- 상관관계

- 분포

- 유동, 흐름

- 관계

 

 

4. WEEK 3 / DAY 4

부교재 : 빅데이터를 활용한 예측 마케팅 전략’ 10장

추천엔진에 대한 생각 : https://youtu.be/LNZPgxkTxFg

안녕하세요 하용호입니다. 어제 자료에 대한 추가 설명을 드리려고 이렇게 글을 씁니다.

일전에 tidy data를 통해, 어떻게 하면 만지기 좋은 중간 데이터를 만들 수 있는지에 대해 말씀드렸습니다.

그러고나면 대부분 하게 되는 일은 차트를 그리는 일입니다.

 

데이터를 정리하는데도 원칙이 있었으니, 데이터를 그리는데도 원칙이 있겠죠? 그 와 관련한 데이터 비주얼라이제이션 가이드 라인이 좋은게 많이 있는데,

 

개인적으로 최고봉으로 꼽는 것은 바로 이책입니다.

http://www.yes24.com/Product/Goods/12292773출판된지는 좀 되었지만, 여전히 시대를 관통하는 훌륭한 원리들에 대해서 소개하고 있습니다. 하지만 저작권 때문에, 저 내용들을 소개하진 못하였고, 다른 좋은 대안을 찾아보다가 발견한 것이 구글의 데이터 비주얼라이즈 가이드라인입니다.영어로 되어 있지만, 간단한 영여인데다가, Do/Don't로 예시를 잘 보여주고 있어서 빠지기 쉬운 함정을 잘 보여주어서 아주 좋아합니다.좀 더 영문글에 익숙하신 분들에게는 https://towardsdatascience.com/the-art-and-science-of-data-visualization-6f9d706d673e 이 글도 추천 드립니다.그러면 재미나게 공부하세요

월스트리트저널 인포그래픽 가이드

 

 

5. WEEK 3 / DAY 5

QnA 시간

Q. 데이터 사이언스라는 용어와 목표해야하는 방향성에 대해서 과제를 많이 내셨는데 해당 용어가 많이 중요할까요? 잡에 대한 개념을 나누셨다기 보단 데이터 사이언스라는 분야를 이해해보자라는 관점인것 같기도 한데 실제로 회사 내에서는 business intelligence/data analyst/머신러닝 엔지니어/ 데이터사이언티스트/ 데이터엔지니어 등의 다양한 직군을 어떻게 뽑고 팀은 어떻게 구성(배치)해서 운영하는 게 좋다고 생각하시는지 개인적인 관점을 공유해주시면 좋을것 같습니다! A. 점차 성장하는 과정을 기준으로 말씀드리도록 할게요. 보통 회사가 처음 만들어지고 나면 개별 기능을 개발하기도 바쁘기 때문에 데이터까지 챙기기 힘듭니다. 따라서 로깅과 분석등은 외부의 좋은 툴들, Google Analytics나 Amplitude등을 통해서 수집, 분석하게 됩니다. 이 때에는 개별 서비스에 로그를 남기는 코드를 장착할 개발자 한사람, 그리고 GA나 앰플리튜드 데이터를 볼 마케터, 또는 마케팅에 특화된 분석가 한명만 있으면 됩니다.하지만 서비스가 점점 커져감에 따라서, 웹으로만 구성되었던 서비스가 별도의 앱을 만들게 되거나, 개별 유저 기반의 기능을 제공해주기 위해서, 별도의 로그 시스템을 꾸리고 싶어지게 됩니다. 보통 이때에 데이터팀을 꾸리게 됩니다. 이 초기 데이터 팀의 가장 큰 아젠다는 ‘로그를 남게' 만드는 것이기 때문에, 백엔드 엔지니어 한명으로 시작하고, 그가 직접하거나, 또는 데이터 엔지니어를 채용하여 백단을 만들기 시작합니다. 이 수준에서는 결과는 엑셀 또는 구글 스프레드시트 정도 수준으로 최종 정리되어. 1차적으로는 아까의 그 마케터가 숫자를 보게 됩니다. 더 고급진 분석이 가능하게 하기 위해서 이 다음 수준에서 데이터 분석가를 채용하게 됩니다. 자사의 백엔드 시스템에 남아있는 raw수준의 데이터를 (적어도 SQL정도는 자유롭게 쓸 수 있는) 데이터 분석가가 나타나, 기존에 살피지 못했던 축과 해상도로 제품의 세부 액션들을 분석하며 살피게 됩니다. 이때 까딱 잘못하면, 데이터팀의 사내 외주팀 구조가 만들어지게 됩니다. 운영이나, 마케팅에서 필요한 숫자를 분석 부서에 요청하고, 이들은 이것을 끊임없이 뽑아주는 사내 하청에 시달리게 됩니다. 이를 타파하기위해서, 백엔드팀은 사내에 누구든 억세스 가능한 데이터 조작 시스템을 도입하게 됩니다. tableau등의 비주얼라이제이션 툴, 또는 좀 더 격화된 회사에는 SQL등을 직접 날리고 바로 차트를 그려볼 수 있는 시스템을 꾸리곤 합니다.  그리고 사내에 이 시스템에 대한 교육을 진행하며, 많은 사람들이 데이터를 보게 만드는 데이터의 일상화 스테이지로 가게 됩니다.이 때쯤에 머신러닝 엔지니어도 같이 충원되곤 합니다. 추천이라던가, 고객군 탐색이라던가, 이탈예측등등 조금 더 다양한 응용을 위해서 활동합니다. 이때쯤이 되게 되면 데이터팀은 어느정도 완성되는데 백엔드, 데이터 엔지니어, 데이터 분석가, 머신러닝 엔지니어, 여기에 이 데이터팀이 해줄 비즈니스 니즈를 수집해오고 진행하는 데이터PM또는 비즈니스 분석가가 붙기도 합니다.

Q.데이터 분석가는 대용량분산처리도 다 할 줄알아야 하나요? A. 초창기 데이터 사이언티스트가 분화되기 전에는 데이터 전처리 작업도 사이언티스트의 역할이었습니다. 하지만 현재는 좀 큰 곳이라면, 데이터 엔지니어와 데이터 분석가가 2개의 직업으로 분화되는 추세에 있습니다. 특히 예전에 데이터 엔지니어의 큰 역할이었던 분산처리의 경우, AWS등에서 제공하는 다양한 대용량 데이터 플랫폼 제품들이 그 역할을 충분히 캡슐라이제이션해서 제품화되어버렸기 때문에 상당 부분, 돈만 내면 쓸 수 있는 체계가 되었습니다. 결론만 말하면, 사내에 AWS, 구글 cloud등의 스택으로 꾸려지는 현재의 특성상, 분석가가 분산처리 기술을 알 필요성은 거의 없어졌습니다. (물론 데이터 엔지니어라면 여전히 알아야 합니다)

Q.최근 데이터 사이언스트를 하지 말라, CS 역량이 훨씬 더 중요하다 라는 의견을 자주 보곤 합니다. (모델이 복잡해지면 어차피 못알아 듣고 안쓴다., 회사는 연구하는 곳이 아니니 서비스/프로덕트화 가 중요하다. 등의 이유..)  그래서 앞으로의 커리어에 있어 데이터 엔지니어링 등 개발 역량 강화에 더 힘을 많이 쏟아야 할 지 고민이 많이 되는데요. 이러한 비판적 시선에 대해서 용호 님의 생각은 어떠신지 궁금합니다. A. 데이터 사이언티스트라는 직업의 발전을 이해해봐야 할 것 같습니다. 원래 초기의 데이터 사이언티스트는 모든 일을 다해야 했습니다. 엔지니어링, 전처리, 분석, 자동화된 시스템 구축까지요. 그러다보니 모든 역량이 필요했었습니다.시간이 지나서 직업이 많이 분화되었습니다. 위의 "데이터 분석가도 분산처리를 알아야 되나요?" 대답에서도 언급하였지만, 최근의 많은 회사들은 기저 플랫폼을 AWS라 Google Cloud의 백엔드 제품을 쓰고 있어서 SQL정도만 알아도 큰 무리없이 분석을 할 수 있습니다.하지만 더 큰 함정은, AWS나 GCloud를 쓰지 않고, 그 지점까지 못간 회사가 훨씬 더 많다는 것에 있는 것 같습니다. 대부분의 회사에 가면 데이터를 "있게" 만드는 작업을 해야하는 스테이지인 경우가 많고, 이때는 분석만 할 줄아는 분석가는 거의 쓸모가 없기는 합니다. (손가락만 빨게 됩니다) 때문에, 자신의 운신의 폭을 넓히고, 필요한 데이터를 직접 공수할 수 있게 하기 위해서라도 적절한 수준의 CS역량은 꼭 필요하다고 봅니다.이 부분을 다룬 제 친한 친구인 송호연님의 답변이 있는데요, 저도 꽤 동의합니다. 링크를 겁니다. 제목은 어그로를 끌려고 조금 자극적으로 짓기는 했지만, (정말 하지 말란 내용은 아니라고 봅니다 ㅎㅎㅎ) 내용은 옳습니다  https://youtu.be/8mjeJpHtLVQ.

Q. 문제를 정의하고 분석 목적에 딱 맞는 지표가 없을 시 지표 개발을 하게 될 텐데 만들어진 지표가 유의한 지 측정하는 방법같은 것이 있을지 궁금합니다. A. 모든 지표는 기본적으로 운영단에서, 사업단에서 보는 지표를 잡아야 합니다. 때문에 가장 좋은 지표는 '매출' 이겠으나, 매출을 직접 잡을 수 없으므로 우리는 점차 간접적인 대리지표들로 바꾸어 나가게 됩니다. 예를 들어서 카카오 이모티콘에 관련된 기능이라고 해봅시다. 가상의 기능으로 친구에게 이모티콘을 보내면, 그 "이모티콘의 이름이 잠시 팝업되는 기능"이라고 해보겠습니다.이 기능 자체는 매출을 일으키지 않습니다. 설사 일으킨다 하더라도, 유저가 이 기능을 느끼는 시점과 매출사이에는 여러 강이 있으므로 직접적이지 않겠죠. 그럴 때 우리는 이미 검증된 가설등을 이용하게 됩니다. (아래 내용은 실제가 아니라 가상의 예입니다) 유저가 이모티콘 장터에 들어오는 횟수가 많아질 수록 매출이 는다. (검증된 가설) 유저가 카카오 통합검색에서 이모티콘 이름을 검색을 자주할 수록, 이모티콘 장터에 자주 들어온다. (검증된 가설) 우리가 A/B테스트 기능으로 팝업을 띄우게 했던 이름이 검색량이 늘어나는가? 그러면 우리는 이번 기능의 KPI를 검색량으로 하자. 위와 같이 최종 비즈니스 목표를 측정하고 싶지만, 그러기 힘드므로, 그와 연관되어 있고, 비례관계에 있으면서 더 빠르게, 더 직접적으로, 즉각(즉각이 중요합니다) 측정할 수 있는 지표를 대리지표로 목표로 둔다. 의 과정을 거칩니다. Q.답변을 보고 또 궁금한게 생겼습니다. 최종 목적과 상관관계가 있는 대리 지표가 여러개 있을때ex) 댓글을 많이 다는 사람이 돈을 많이 내더라. 좋아요를 많이 누르는 사람이 돈을 많이 내더라. 등등연관관계가 강할 지표를 예상하는 방법 같은게 있을까요?ex) 댓글을 많이 달게 유도 해볼까? vs 좋아요를 많이 누르도록 유도해볼까? vs 둘 다 효과 없을것이다. 등등 A.말씀하신 것과 같은 상황일 때는 (예를 들어 둘 다의 상관관계가 비슷하다면), 발생건수가 많은 것을 선택하게 됩니다. 예를 들어 게임의 활동성을 측정하기 위해서 1) 하루당 로그인 수와 2) 아이템구매 수 가 있다고 한다면, 둘다 활동성을 잘 나타내어주는 지표지만, 1번인 하루당 로그인수가 훨씬 더 자주 발생하고 count수가 많은 지표입니다. 이쪽이 분석이 훨씬 유의미하게 나올 수 있기 때문에 이 쪽을 택합니다.

Q. 실제로 현업에서 데이터를 다루는 사람은 소수 이고  개발자나 마케터나 영업직군은 데이터를 잘 모릅니다.  더욱이 마케터나 영업직군은 데이터 구조 조차 잘 모르고 SQL은 듣도 보도 못한 경우가 많습니다. 혹시 이런 직군들을 대상으로 교육이나 강의같은 것을 토대로 잘 된 케이스가 있으면 어떤 방법을 쓰셨는지 알려주시면 감사하겠습니다. A. 사실 영업직군이나 마케터 같은 경우 데이터를 직접 다루거나 SQL을 다루기를 기대하기는 힘듭니다. 그거 아니어도 다들 엄청 바쁘시기 때문이죠. 사실 이들에게 필요한 것은 간단한 데이터를 빠르게 브라우징할 수 있는 툴입니다. 이들에게 직접적으로 필요한 데이터가 잘 정리된 대시보드로 존재하고, 이 대시보드는 자신들의 행동이 즉각 (또는 가능한 빠르게) 반영되어서, 마치 어릴 때 달리기할 때, 선생님의 초시계 같은 역할을 해주는게 옳습니다. 일차로는 대시보드 대시보드만으로 니즈를 다 채울 수 없는 영업과 마케터를 위한 redash나 superser, 또는 tableau 등의 마우스 클릭으로 좀 더 자유롭게 볼 수 있는 플랫폼 그리고 SQL 교육과 보급 순으로 점차, 얻는데 노력이 적은 것에서 점점 많은 것 수준으로 확산시켜 나가야 합니다.

Q. 그로스해킹의 프로세스 중 '우선 순위 결정' 부분에 있어서 영향, 신뢰도, 용이성 부분에 대해서 점수를 주고 총합하여 결정한다는 내용이 있었는데요. 점수를 주려면 명확한 데이터가 근거로 제시 되어야 할 것 같은데 실제론 과거에 진행한 이력이 없는 경우도 있고 있더라도 정확한 수치 없이 대략적인 느낌만 있는 경우가 많았습니다. 이런 경우에 어떤 식으로 점수를 주어 결정을 해나가는 것이 좋은지 궁금합니다. A. ICE로 측정할 때, I인 파급력의 경우 이 기능을 쓰거나 쓸거 같은 사람 수이니, 그 기능이 노출되는 페이지에 접속하는 사람의 수로 모사할 수 있고, E인 용이성의 경우, 이 기능 개발하는데 얼마 걸려요? 라고 물으면 개발부서에서는 그래도 거의 정확하게 답이 옵니다. 문제는 C 얼마나 확실한가? 인데, 이건 솔직히 발안한 사람의 배짱에 따르게 되어 있는거 같습니다. 근데 몇번 하다보면, 진짜 확실히 될거 같은 일 (낮게 달린 사과 low hanging fruit : 금방 수확가능)이 아닌 이상, 다들 무리 하지 않습니다 ㅎㅎㅎ 그래서 C가 핵심 팩터가 될 공산은 적어서 큰 무리가 없는거 같습니다.

Q. 제조업체로서 유통사를 통해 엔드유저에게 판매가 되어 엔드유저에 대한 데이터가 전무한 상황입니다. 이에 대해 하용호님께서는 이렇게 코멘트를 해주셨었는데요 ""회사는 본질에 노력을 집중해야 한다. 예를 들어, 녹즙을 배달하는 회사는, 유저 데이터를 수집하여 고객 프로파일링을 통한 녹즙 추천 등을 하는 서비스보다는 녹즙을 더 잘 만들고, 더 쉽고 편하게 주문되게 하고, 더 빠르게 먹어볼 수 있게 하는 전체적인 녹즙 경험의 flow를 더 잘 만드는게 더 중요하다"" 하지만 회사의 본질 서비스를 더 잘 하기 위해 유저 데이터가 필요할 것이라고 생각되는데, 그렇다면 지금부터라도 이 데이터를 쌓아나가는게 좋을까요? 아니면 쌓기 힘든 유저 데이터 보다는 회사 내부의 필요한 데이터를 쌓아 나가는게 좋을까요? A. 사실 말씀하신 부분은 굉장히 데이터의 문제를 넘어서서 심지어 사회적 문제로까지 엮어지는 부분이긴 합니다. 아마존, 우버, 에어비앤비등 플랫폼 회사의 발전으로, 유저에 대한 정보가 해당 플랫폼회사가 중간에서 독점하고 그들이 풀어주는 정보만을 서비스 생산자가 받는 문제가 상당합니다. 물건을 유통사에 직접 납품하는 제조사라면 더욱더 크겠네요. 정보의 채널이 단절되어 있으니까요.이 부분 부터는 옳다 그르다의 관점이라기보다는, 제가 만약 제조사의 대표라면 할 거 같다 싶은 일입니다. 사실 유통사는 여러의미에서 깡패입니다. 백화점의 경우는 50%, 좀 다른 유통회사도 30%를 요구하는 경우가 비일비재합니다. 예전과 같이 제조사가 소비자를 만날 방법이 유통사 말고 전무하던 시절이라면 모를까, 지금같이 직접 채널이 가능한시대라면, 자사몰을 운영해나갈 것 같습니다. 설사 돈을 많이 못벌더라도, 제품을 구매하는 고객들의 컨택라인을 확보하고, 새로 구입하는 유저들에게 샘플로 설문조사등을 하여, 그들의 총체적 만족도나, 일부에겐 전화로 자세히 사용소감을 물어서 제품의 개선 방향을 찾는데에 그친다하더라도 그것만으로도 큰 의미가 있을 것이란 생각이 듭니다. 그 소수의 실제 테스트 베드에, 새로 만든 제품의 테스트를 의뢰해본다던가 하는 회사 분질을 개선할 방안이 나오리라 생각합니다.

Q. 전 인사담당자입니다. People Analytics에 관심이 있고 공부중입니다. 이번주에 빅데이터를 활용한 예측마케팅 전략을 읽으면서, 결국 마케팅에서의 빅데이터도 사람을 이해하는데 활용되는 도구라는 생각을 한다면 이는 사람을 이해하고자 하는 인사의 본질과도 같지 않을까 합니다. 다만 마케팅 필드에서는 다양한 트렌젝션으로 인해 데이터가 많고 쌓이는데 반해 인사 필드에서는 민감한 개인정보 이슈와 빈약한 트렌젝션/센서 들로 한계가 있지는 않은가 하는 걱정이 듭니다. 이번 과정 내에서 People Analytic에 도움을 얻기위해 어떻게 접근하면 좋을지 조언을 구하고 싶습니다. A. 많은 회사에서 인사에서 데이터를 사용하고 싶어합니다. 저도 비슷한 질문을 꽤 받았지만, 항상 문제는 말씀하신 바와 같이, 데이터의 부족이었습니다. 대부분의 회사가 사람에 대한 평가를 연말에 한번 하는 경향이 있고, 다들 느껴봤듯이 꽤 상관의 주관에 기반해서 등급으로 판단되는 경우가 많아서, 정보로서의 가치도 적습니다.이런 문제를 해결하기 위해서 구글등의 회사는 서로가 서로에게 쏘아줄 수 있는, 아주 작은 스몰인센티브를 도입했다고 들었습니다. 1년중 수시로 함께 일하며 동료에게 크게 도움을 받게 되거나 동료가 너무 잘해서 칭찬을 하고 싶다면 자기가 가진 버짓안에서 동료에게 보너스를 쏘아줍니다. https://blog.bonus.ly/a-look-at-googles-peer-to-peer-bonus-system/이 방식은 서로 실제로 일하는 동료, 주고 받는 보너스의 금액과 빈도 등으로, 팀에 기여하는 사람들에 대해서 1년 단위가 아닌 훨씬 더 짧은 단위의 작은 데이터 포인트를 쌓게 만들게 됨으로써, 인사HR에도 크게 도움이 되었다고, 전 구글 HR담당을 하셨던 분께 들었던 적이 있습니다.또 제가 있었던 K사 같은 경우, 모든 업무를 사내 페이스북같은 시스템을 통해서 작업을 하곤 했는데, 여기의 활동량으로 유저의 평가를 근사해보려는 시도도 있었습니다. 물론 일을 열심히 하는 것과 잘하는것과 아지트에 글쓰는 과정이 완전히 일치하는 것은 아니며, 또 일부 포지션은 일을 많이해도 아지트에 쓸일이 없기에 적절하지 않기는 합니다 .(그래서 연구시험 정도로 끝났습니다)어쨌거나 위와 같이 데이터를 남게 하는 여러 활동들을 도입해보는 것 (특히 peer bonus)는  꽤 유용하리라 봅니다. 데이터분석의 첫번째는 데이터를 '있게' 만든 것이니까요

Q. 학습내용과는 별개로, 일을 하시면서 가장 많은 시간을 할애하시는 것이 어떤 것인지 궁금합니다. A. 영어가 우선 순위 영단어가 대부분 쓰이고, 특이한 단어가 적게 쓰이듯이, 현업에서도 쓰이는 기술들은 조금 한정되게 되어있습니다. 하다보면 자신의 기법과 워크플로우는 반복되게 되어있죠. 때문에 이것들은 곧 숙달되어 큰 시간이 들지 않습니다.현업에서 일하면서 가장 시간을 많이 쓰게 되는 것은, "이런 것을 분석해주세요"라는 요청 이면에 어떠한 목적으로 이 질문이 시작되었는지를 추적하는 것입니다. 예를 들어서 현업이 'B가 알고 싶어요'라는 질문이 왔을 때, 그것을 뽑아주고 나면 'C가 알고 싶어요'라는 질문이 다시 또 날라오게 됩니다. 그 이유는 현업에 있는 사람들은 현업 나름대로 '만약 내가 B를 알게 된다면 내가 알고 싶은 XXX의 원인을 알 수 있을꺼야'라는 가설하에, 본인이 필요하다고 생각하는 것을 이미 어느정도 결정하고 요청을 던지기 때문입니다. 마치 우리가 약국이나 병원에 갈때, 나는 이미 감기일꺼야. 라고 단정하고 가는 느낌이랄까요? 때문에 현업과의 인터뷰를 길게 가져가게 됩니다. '왜 그것이 필요하신가요? 그걸 통해서 최종적으로 원하는 목표는 무엇인가요? 그렇다면 오히려 Z를 보는게 정확하겠네요' 같은 류의 일이 꽤 많이 반복되었습니다.그런 의미에서 기술적 측면과 더불어 적절한 소프트스킬, 특히 인터뷰 스킬이 필요한데, 저는 최근에 읽은 책 중에는 http://www.yes24.com/Product/Goods/79211945 이 책이 괜찮았습니다.

Q. 현업에서 업무를 하다보면 현업부서의 의지가 없거나 가설 또는 가설을 세우기 위한 기준의 결정자체도 결정받지 못하는 경우가 있습니다. 이런 상황이라면 어떻게 해야 하는게 좋은 방법일까요? A. 제가 다른 곳에 가서도 종종 이야기하곤 하는데. '사람들은 언제 데이터를 본다고 생각하나요?  잘 안되어가고 있을때' 라고 농담을 하곤 합니다.다른 부서 사람들은 데이터로 일해본 적이 없어서 이 방법들이 낯설고 부담스럽습니다. 특히 잘나가고 있는 부서들의 경우, 다른 도움없이도 이미 잘나가고 있고, 잘나가고 있기에 기존방식으로도 충분히 바쁩니다.제 지난 경험에서 가장 협조적인 부서는 최근에 실적이 좋지 않은 부서였습니다. 이미 상황이 좋지 않아, 지푸라기라도 잡고 싶어하는 상황이기 때문에, 도와주려고 하는 다른 부서의 이야기에도 훨씬 열려 있습니다.보통 이런 팀을 만나서, 합심하여 가장 작은 small win을 빠르게 만들어내고, 해당 성공 경험을 레버리징하여 점차 더 큰 부서로 일을 키워나갔습니다.만약 카운터파트 현업이 하나밖에 없는데 거기가 의지가 없다면, 대표를 공략하여야 합니다. 대표는 언제나 회사를 조망하는 지표를 바로 보기를 원하기 때문에, 대표를 위한 회사 전체 관련된 숫자 망라한 대시보드등을 제공하여 대표의 신임을 얻은 후, 이 힘을 바탕으로 현업에 접근하는 방식을 시도해야 합니다.

 

 

추천시스템은 어떻게 만들어지는가?

[261] 실시간 추천엔진 머신한대에 구겨넣ᄀ��

(아몰랑 .. 아직 안읽었어요)

< Modern한 엔진은 Collaborative filtering을 사용한다 >

< 오늘은 Memory-based 를 다뤄봅니다 >

 

데이터가 치우쳐 있을 때: https://imbalanced-learn.readthedocs.io/en/stable/

Welcome to imbalanced-learn documentation! — imbalanced-learn 0.5.0 documentation

다해 님이 공유해주신 AB테스트 관련 아티클: https://netflixtechblog.com/its-all-a-bout-testing-the-netflix-experimentation-platform-4e1ca458c15

It’s All A/Bout Testing

 

 7. WEEK 3/ DAY 7

 

Q.분석 역량을 키우기 위해 가장 중요한 연습 - 캐글 어떠세요(다른 참가자 분들의 조언)

A.요즘은 캐글 연습하라고 말씀 안드려요. 제가 예전에는 카카오 데이터부문 공통 면접관이었는데요.

가면갈수록 어떤 부분이 있냐면, 캐글 문제 풀어보고 인터넷 ML 코스 들어보고 , 데이터 면접 질문해서.

대답은 팀장급으로 잘하세요. 이 분들이 현업에 들어오면 캐글스러운 부분은 잘하는데, 다른것은 0으로 전처리.

그래서 점점 전처리나 CS 적인 부분을 얼마나 잘 하고 있는가로 면접 포인트가 바뀌기 시작했어요.

 

제 생각은 분석 실력(기법) 은 상향 평준화 (업무에 쓸만큼), 되셨고 이 영역 말고

앞,뒤의 영역들. 데이터를 분석하고 가공하는 일이나, 누군가에게 전달할 때 전달력 있게 전달하는지를 더 권해드립니다.

 

대부분 가면 데이터가 엉망진창이어서 엔지니어한테 부탁하는 경우가 많아요.

그래서 이런 역량들이 필요합니다. (Python, HTTP로 가져오는 방법, SQL, Script)

 

- imbalanced-learn 이라는 library 

(저는 오버샘플링보다 언더샘플링 할 때 많이써요)

 

- SHAP : 블랙박스 모델을 화이트 박스 모델로 ( 분석 결과 중 무엇이 가장 높은 영향을 미쳤는지)