데이터 분석 실무 1강
•Download as PPTX, PDF•
3 likes•445 views
2016.05.30. 한국광고교육원 Kobaco 데이터 분석 실무 1강 슬라이드 데이터 분석의 기본 이론과 배경
Recommended
More Related Content
Viewers also liked
Similar to 데이터 분석 실무 1강
Similar to 데이터 분석 실무 1강 (14)
데이터 분석 실무 1강
- 3. • POSTECH BACHELOR OF COMPUTER SCIENCE ENGINEERING - CANDIDATE • CYRAM.CO.LTD. RESEARCH ENGINEER • HIROSHIMA UNIV. MASTER OF BIO-MEDICAL SCIENCE • RIKEN BRAIN SCIENCE INSTITUTE RESEARCH STUDENT • TRANSLATION PUBLISHED: VISUALIZE THIS, DATA MINING, GOOGLE ANALYTICS INTEGRATION, ETC. • CO-AUTHORED: SOCIAL EXPERIENCE STRATEGIES •
- 11. • • • • •
- 14. • • •
- 20. 관찰 모델링 가설 설정 실험 설계 측정 가설 검정
- 23. - - -
- 24. • • •
- 25. • • • • •
- 26. • • •
- 27. • • • • • • •
- 28. • • • • • http:// blog.dmetrix.kr / tag/ga ?id=1&num=2 #universal_analytics
- 31. • HTTPS://ANALYTICS.GOOGLE.COM • HTTPS://TAGMANAGER.GOOGLE.COM • HTTPS://SUPPORT.GOOGLE.COM/ANALYTICS/ • HTTP://BLOG.DMETRIX.KR
- 32. 월 수 1주차 5/30 Introduction 6/1 GA 기초 실습 2주차 6/6 - 현충일 - 6/8 GA 리포트 실습 3주차 6/13 GA 고급 기능 6/15 GA 고급 실습, 페이스북 인사이트 소개 4주차 6/20 FB 인사이트 외 데이터 도구 소개 6/22 FB 인사이트 실습 데이터 전략 수립 5주차 6/27 데이터 전략 수립 6/29 데이터 도구 소개, 실습 프리젠테이션
Editor's Notes
- 빅데이터 분석 실무 – 구글 애널리틱스와 페이스북 인사이트 기반의 마케팅 데이터 분석 실무 1강을 시작하겠습니다.
- 안녕하세요
- 저는 송용근입니다. 대략 10년 동안 화면의 경력을 거쳐 지금은 디메이저에서 일하고 있습니다. 글자가 잘 안 보이죠? 일부러 안 보이게 썼어요. 여러분 앞에서 제 자랑 하는거 같아 부끄러워서요. 회사에 입사 지원하려는 것도 아니고, 이런 이력들이 결과적으로 보여주는 의미란 무엇인고 하니
- 제가 태생부터 공돌이, 뼛속까지 공돌이인 순도 99.99% 공돌이란 뜻입니다. 디메이저에서도 데이터 엔지니어란 직함으로 일하고 있구요 이 장면 기억하시는 분 있나요? 비유하자면 이 털 많은 친구가 기획자, 여기 쥐고 있는 이게 접니다. 본인이 이공계열 출신이신 분? 혹은, 인문-상경 계열이신 분? 최근에는 그래도 공돌이의 이미지가 꽤 좋아졌는데요. 그런 좋은 이미지는 사실, 워낙 IT 산업이 호황이다 보니 – 90년대에 헤지펀드 매니저를 할 만한 친구들이 이공계로 많이 진학해서 그런거구요. 저 같은 사회성 제로에 극소심 친 기계인 뼈공돌이에는 해당이 안 됩니다 그래서 여러분은 이제 큰일 났습니다. 저 같은 뼈 공돌이들은 보통, 사람보다 기계와 더 친하구요, 공감이나 감정보다 합리와 이성이 우선입니다. 그리고 말 길게 하는거 별로 안 좋아합니다. 그보다는
- 이런 식으로 얘기하는걸 좋아하죠. 아까 인문 계열이었다는 분, 이런걸 딱 봤을 떄 무슨 생각이 드세요? 시작하면서부터 이런 막되먹은걸 보여 드려서 참 송구합니다. 네, 이런 분야에 익숙한 사람이 아니라면 갑자기 심장이 뛰고 숨이 턱 막힐거에요. 막막하고 머리가 하얗게 질리는거 같고. 그쵸? 딱 지금처럼 사람과 이야기하는 제 심정이 그렇다고 보시면 되겠습니다. 무슨 이야기인가 하면, 사람은 누구나 자기에게 익숙하지 않은 상황에 맞닥뜨리면 겁에 질린다는 거에요. 인간 뿐만 아니라 모든 동물의 생존 본능입니다. 하지만 그 상황에 익숙해지고 나면, 굉장히 편안하게 느낍니다. 여러분이 처음으로 자동차나 자전거 운전을 배울 때, 혹은 수영이나 스키를 처음 배울 때 느낌을 생각해 보세요. 그런 것들을 많이 접해 본 지금은 처음처럼 긴장하고 막막하진 않을거에요. 무엇을 보아야 하고, 어떻게 다루어야 할지 머릿속에 착착 그림이 나오니까요. 익숙한 사람은, 모르는 사람이 옆에서 보면 정말 마법을 부리는 것 처럼 술술 진행을 하죠? 저는 여러분이 오늘 하루, 혹은 한 달, 1~2년의 시간을 통해 그렇게 해야 한다고 말씀드리진 않겠습니다. 저 같은 태생이 뼈공돌이에게도 10~20년 이상이 걸리는 일이에요. 그럼 시작하기 전에 아주 중요한 질문을 하나 던져 볼까요.
- 그런데 여긴 왜 오셨어요? 여기 오신 분들은 거의 데이터나 데이터 분석에 대한 필요성을 공감하셔서 오신 분들도 있을테고 아니면 위에서 시켜서 오신 분들도 계시죠? 질문을 조금 바꿔 볼게요. 데이터를 수집하고 분석하는게 왜 필요할까요? 데이터를 분석하면 캠페인을 성공 시킬 수 있을까요? 데이터가 돈이 되나요? 정말요? 지금부터 대략 15분 정도를 할애해서 제가 ‘빅데이터’를 깔텐데요, 이런거 재미 없다거나 넘어갔으면 좋겠다 싶으면 박수를 쳐 주시면 좋겠습니다.
- 여기 오신 분들이 기대하는 것, 혹은 최근 ‘빅데이터 분석‘ 이라고 했을 때 흔히 등장하는 주제들입니다. 꼭 회계나 통계, 경영 전공이 아니라도 SAS 나 R-project 같은건 한 번쯤 들어 보셨을 거에요. 그리고 올해 최고의 화두죠. Machine learning, 기계 학습, 알파고! 무슨 재크와 콩나무의 마법 콩 같은 느낌이에요. 심지어 사당역 근처에 알파고 노래방까지 생겼더라구요. 물론, 내용을 진행하면서 한 번쯤 이런 이야기를 짚고 넘어갈 기회가 있긴 할겁니다. 하지만 이게 주요 내용이 되진 못할거에요. 아쉽게도. 아, 구글 애널리틱스와 스프레드시트 빼구요. 왜냐하면, 이것들은 데이터 분석에 있어서도 도구나 방법론일 뿐이지, 그 자체가 데이터는 아니기 때문입니다. 요리에 비유를 하면 쉬워요. 홈쇼핑에서 보면 가끔, 신가하게 생긴 냄비나 프라이팬으로 벼라별 요리를 만들죠. 똑같은 요리를 집에서 시도 해 보셨어요? 해 보신분? 쉽지 않죠? 왜 집에서 만든 요리는 절대 조리예 처럼 나오지 않을까요? 재료나 도구의 문제일까요? 그렇지 않다는 것 다들 이해 하시죠?
- 어쩌면 여러분이 바라는게 이런 것일수도 있는데요. 이런 걸 보면 어떤 생각이 드세요? 저는 이렇게 생각합니다. 예쁘네. 그래서 어쩌라고.
- “은총알은 없다＂ 90-00년대 개발자 사이에서 유명한 격언인데요. 무슨 뜻인지 아시는 분 있나요? 우리 말로 바꾸면 ‘만병통치약 같은건 이 세상에 존재하지 않는다‘ 같은 뜻입니다. 제가 시작부터 너무 단호하게 제 필드를 깎아 내리고 있어서 의아하실 수도 있는데요. 제가 느끼기엔 이 쪽 필드에 환상이 굉장히 심하기 때문이에요. 여기 계신 분들 중에서 작년에 번역 출간 된 “growth hacking” 책을 읽어 보신 분? 그 책에서 강조하는 그로스 해킹의 비법 첫 번째가 뭔지 기억하세요? “잘 될 만한 캠페인 대상을 선택한다”는 거에요. 웃기죠. 커피가 맛있으면 발로 내려도 맛있다는 얘기와 뭐가 달라요? 데이터를 분석하면 망한 캠페인을 살릴 수 있나요? 99% 아닙니다. 데이터를 수집하면 매출을 끌어 올릴 수 있나요? 거의, 아닙니다! 반대로 말해 볼게요. 소재만 잘 만든다면 성공적인 캠페인을 할 수 있을까요? 미디어만 잘 쓴다면? 혹은, 세칭 ‘뜨는‘ 연예인을 섭외하는데 성공한다면 그것 만으로 좋은 광고를 만들 수 있을까요? 뒤에서 말씀 드리겠지만, 데이터는 전략을 수립하고 성과를 최적화하기 위한 도구이지 만병통치약이 아니에요. 분명히 강조하겠습니다. 데이터는 명확한 목표와 쓰임이 있는 도구입니다. 그리고 그 장단점과 한계도 분명히 있어요. 계속 할게요.
- 이게 제가 강의 제목에서는 선택권이 없어서 살짝 애매한 상황이 됐는데요. 제 생활 신조가 “구라는 쳐도 사기는 치지 말자”거든요. 여러분, 저는 ‘빅데이터＇라는 용어 하나 때문에 출판사와 전화 두 시간 통화를 했던 사람입니다. 그때 마케팅의 필요상 꼭 빅데이터란 용어를 쓰고 싶어 하셨던 부사장님과 결국 타협한게 “빅데이터 시대의-” 라는 접두어에요. 도대체 얼마나 큰 데이터가 ‘빅’데이터일까요? 애매하죠. 명확한 구분은 없어요. 그간 학계에서 주로 이야기 하던 방식을 빌어 오자면 “기존의 방식으로 처리하기 힘든 수준의 크고 복잡한 데이터 처리＂라고 합니다. 완전 애매하죠? 지금 현역 데이터 사이언티스트로 일하고 계신, 아, 이 분은 정말로 ‘빅데이터＇를 연구하는 분이에요, 선배님이 한 번 그런 이야기를 한 적이 있는데요. “R-project로 돌아가면 빅데이터가 아니다“ 라는겁니다. 저도 동의해요. 왜 이렇게 정의가 애매하냐면, 하드웨어나 소프트웨어의 발전에 따라서 ‘기존의 방식으로 처리하기 힘든‘ 수준이 끊임없이 올라갔기 때문이에요. 이렇게 이야기하면 체감하기 쉽지 않을테니 좀 정리를 해 볼게요. 학계에서 쓰는 정의는 아니고, 제가 개인적으로 생각하는 구분으로는 이렇습니다. 여러분이 MS 엑셀로 돌릴 수 있는 규모와 복잡성의 데이터라면 소형 데이터입니다. MS 공식 문건을 바탕으로 이야기하면 대략 - 104만 8,576 행, 16,384 열 정도 구요. 개인적인 체감으로 이야기하자면 파일로 1-2GB 정도 규모입니다. 이게 요즘 시대의 ‘소형 데이터＇입니다. 그럼 중형 Mid-sized 데이터는 어느 정도일까요? 노트북에서 엑셀로 돌릴 수는 없고, 보통 개발자들이 좋아하는 SQL 데이터베이스란걸 돌려야 하는 수준이라고 봅니다. 개수로 말하자면 대략 수십억건에서 10조건 정도? 열, 그러니까 속성-차원으로 치면 백만 단위 미만? 숫자가 좀 크니까 슬슬 감이 떨어져가죠? 가령 GA나 페이스북 인사이트에서 1 페이지뷰, 혹은 1 좋아요 하나를 ‘엔티티＇한 개로 칩니다. 그 하나가 1 행인 거죠. 그러니 총 PV 백만 정도 규모의 블로그 웹로그를 분석하신다면, 이미 중형 규모의 데이터를 다루고 계신 셈이에요. 이걸 파일 크기 규모로 따지면 대략 수십 TB 정도. 더 올라 갈 수도 있는데 PB까지 가진 않아요. 마지막은 빅데이터 인데. 빅데이터는 한 두대 데이터베이스 서버를 두고도 감당이 안 되는 수준의 대규모, 초 복잡한 데이터를 말합니다. 단순히 규모 뿐만 아니라 – 복잡성과 처리 속도 문제도 있어요. 가령 초당 1-2GB 정도 데이터가 쏟아지는데, 이걸 실시간 내지는 준 실시간으로 처리해야 하는 상황이라면, 단순 규모로는 일 몇 TB 밖에? 안 돼서 중형에 해당하지만 처리 속도나 복잡성의 문제에서 빅데이터라 볼 수 있습니다. 이제 제가 무슨 말씀을 드리려는지 감이 오시나요? 빅데이터를 설명하려면 이제, 분산 처리 시스템이니 신경망 네트워크니 예측 모델링이니 하는 이야기를 해야 하는데 뼈 공돌이의 입장에서도 이해하기 쉽지 않은 주제들이에요. 그리고, 산업계의 어디에서 이런 규모와 복잡성의 데이터를 사용할까요/ 대형 유통사, 통신사, 금융업. 아니면 대형 게임 퍼블리셔 정도? 그 밖의 경우엔 생전 볼 일이 없어요. 광고계는 당연히! 그래서 저는 “빅데이터＂가 아니라, ‘중소데이터＇를 설명하려 합니다. 나중에 사기 당했다고 하시면 안 돼요.
- 그럼 데이터라는건 뭘까요? 저는 2010년에 정보처리기사 자격증을 땄는데, 정보처리기사 자격 필기 시험의 1장이 데이터와 정보를 비교하면서 이런 이야기를 합니다. 어떤 행위나 현상을 나타내는 숫자나 속성의 모음이 데이터이고, 이러한 데이터를 의사결정에 필요한 근거로 만들어 낸 것이 정보 – information이라 합니다. 실제로 ‘데이터＇라 하면 영화 매트릭스에 등장한 숫자 모음이나 스프레드시트의 표, 데이터베이스 테이블 혹은 인포그래픽 리포트 같은 것들을 떠올리는데요
- 이 그림은 책 [소셜 경험전략] 삽화의 초기 버전입니다. 데이터를 활용하는 과정, 이라고 하면 대략 이런 과정을 거칩니다. 가장 먼저 Real-world, 실세계에는 여러 데이터가 있습니다. 밭에서 작물을 캐냈을 때와 마찬가지로 그대로 뽑아 먹기엔 무리가 있지요. 그 자체로는 맛도 없고. 그래서 이러한 데이터를 ‘끄집어 내서‘ ‘정제하고’, ‘다른 데이터와 조합해서’ 먹음직스러운 샐러드로 만드는 과정이 필요합니다. 엄밀한 정의를 따른다면 아래 이 두 가지 위치에서부터는 데이터라기보단 정보에 더 가까울 수도 있습니다. 실제 ‘데이터＇라고 하면 위 네 가지 단계에서의 리소스를 말하는거지만 – 사실 실무에서는 이런 엄밀한 수학적 정의가 꼭 필요하진 않지요. 사실 이 분야의 학문도 – 분야에 따라 다소간 차이가 있지만- 대략 100년, 200년 정도로 역사가 짧은 편이라 각자 쓰는 용어나 정의가 명확하진 않습니다. 지금 실무 단계에서 보통 데이터라고 하면 여기 등장하는 전 과정, 또는 과정에 사용하는 자료를 모두 데이터라고 포괄해서 이야기하는 것 같습니다. 여기서 더 중요한건, 어느 정도 범위에서 ‘어떤‘ 사람이 필요한지, 어떤 전문 역량이 필요한지에 대한 것일텐데요.
- 데이터를 통해 어떤 프로젝트를 실행한다고 하면 크게 다음의 세 역량이 필요하지 않나 생각합니다. 우선 가장 첫 번째는 도메인 지식, 해당 분야에 대한 이해입니다. 아무것도 모르는 상태에서는 어떤 결정이 그 대상에 옳은지 판단을 할 수가 없습니다. 물론 빅데이터의 영역으로 가면, 맥락에 대한 정보가 매우 적은 상황에서 자기 강화 학습을 통해 발전시키는 방법이 있다고도 하지만, 아무리 그래도 기본적인 지식이 없는 상태에서는 아무것도 할 수 없겠지요. 대표적인 사례가 알파고입니다. 알파고는 스스로 기보를 학습하면서 자기 강화하는 대표적인 모델인데 바둑의 집을 계가하는 방법, 같은 기본적인 정보는 반드시 필요한거죠. 두 번째는 통계, 분석이나 모델링에 대한 지식이며 – 주로 수학과 연관이 깊습니다. 확률을 계산하고 통계를 내거나 신뢰성을 계산하는 등, 경제/경영학의 영역에 있지요. 마지막 데이터 핸들링은 모델이나 알고리즘을 실제 프로그램, 시스템으로 만들어내는 역량이고 주로 프로그래밍이나 전산학에 관련이 깊습니다. 직함으로 나누어 보면, 기획자는 도메인 지식에 강하구요 분석가는 통계, 분석 모델링에 강해야겠죠 그리고 데이터 핸들링은 개발자에게 맡기는 경우가 많습니다. 그리고 모두 익히 알고 계시듯, 조직이 작고 영세하다면 한 사람이 가능한 넓은 영역을 커버할 수 있어야 하는데 기획자나 미디어 분석가라면 오른쪽의 두 가지, 혹은 저와 같은 데이터 엔지니어는 아래 두 가지를 커버하면서 2-3명 정도의 팀으로 협업을 하는 경우가 일반적입니다. 여기서 아래 두 가지는 뼈공돌이인 저도 배우고 경험하는데 10년이 넘는 시간이 걸린 일인데요 그래서 밑천을 다 드러내 보여도 별로 상관 없겠다는 자신감이 있습니다 그 긴 이야기를 한 달도 안 되는 짧은 시간에 전부 다 드리는건 말도 안 되고, 이 두 가지를 크게 ‘데이터 분석 실무’라는 주제로 묶어서 약간은 겉핥기 수준으로, 여러분도 어렵잖게 따라 올 수 있는 정도, 혹은 어떤 전문 지식을 가진 사람을 채용해야할지 판단할 수 있는 정도로 가볍게 설명해 보는 시간을 가져 보겠습니다.
- 실상 데이터의 ‘기본’ 라고 하면 이런 겁니다. 오늘 이 시간 내내 설명할 이야기도 이게 전부에요. 모델링은 데이터를 통해 세상을 보는 일종의 관점이에요. 바로 뒤에서 설명할게요. 그리고 모델링을 바탕으로 데이터를 다루는 배경 구조를 결정하는게 바로 dimension / metric 입니다. 이건 모델링을 설명하고 이야기를 해야 하니 간단하게 소개할게요. Dimension 이라는 단어는 우리 말로 하면 ‘차원＇이잖아요? 누가 4차원이라 할 때의 그런 차원이요. 사실 dimension 이란 용어 자체가 선형 대수학에서 쓰는 단어입니다. 네 벌써 머리 아프죠. 교과서 맥락에 따라서 특성 – feature 또는 속성 attribute라고 부르기도 해요. metric 이라는건 간단히 말해서 여러분이 보게 될 ‘숫자＇입니다. 엄밀히 말해 숫자 이외에도 분류 라벨이나 참/거짓 플래그 일 수도 있는데, 우선은 측정한 관측 값. 정도로 넘어갈게요. 그리고 마지막이 분석, 입니다. 자, 그래서 이게 데이터의 기본이라면, 데이터의 실제는 무엇인가?
- 자, 그럼 오늘은 모델링부터 시작해 볼게요. 왼쪽 그림 보면 또 막막하죠. 이걸 설명하기 전에 약간 뜬금없는 실험을 하나 해 볼까요. 제가 지금 잔돈이 없어서 그런데 혹시 만원짜리 바꿔 주실 수 있는 분 계신가요? 왜 바꾸셨어요? 어떻게 두 가지가 어차피 똑같아요? 만원짜리는 한 장이고 천원짜리는 열 장이잖아요. 천원짜리 열 장과 만원짜리 한 장이 같은가요? 왜죠? 액면가가 같으니까. 모델링이란건 결국 이런 세상을 이해하기 위한 관점입니다. ‘화폐’가 딱 좋은 사례에요. 같은 만원짜리 한 장이라 해도 결코 같지 않아요. 발행 연도가 다르고 지폐 상태가 다르고 일련번호가 다르죠. 그런데 보통 그런 ‘사소한 차이＇는 고려하지 않아요. 액면가만 따지죠. 왜? ‘지폐’는 그러기 위한 표상이니까. 마찬가지로 데이터도 어떤 한 사람, 어떤 한 행위에 대해 사소한 차이는 고려하지 않아요. 왜? 그래야 계산을 할 수 있고, 비교를 할 수 있으니까요. 예측을 할 수 있으니까요. 수치와 통해 ‘실제’에 가까운 ‘가상’의 이론을 만드는겁니다. 왼쪽의 이 그림은 흔히 ‘라이프게임’, 생명 게임이라 하는 클래식 시뮬레이션인데요. 어떤 특정 공간에 자원이 주어지고 생명체가 살아간다고 할 떄 어떤 양상으로 번식하게 될 것인지 그려 보는겁니다. 이런 ‘모델＇을 만드는게 모델링입니다.
- 중요한건 뭐다? 숫자의 비교, 객관적이고 구체적인 높고 낮음의 비교다. 우리가 정말 관심이 많은 돈의 이야기로 넘어가 보죠. 전자기기를 살 때 스펙 비교 많이 하죠. 스펙은 어떻게 비교하나요? 어떤 특성이 있다/없다. (Boolean) 어떤 특성이 A 또는 B, C 중 하나에 속한다 (Categorical) 어떤 특성이 X의 값을 갖는다. (Numerical) 대표적으로 가격. 그런데 스펙을 꼼꼼하게 보고 주문해도 결국엔 뽑기 운이라는게 있습니다. 그쵸? 하나 하나의 대상이 완전히 똑같지는 않아요. 다만 어느 정도 예상 가능한 ‘범위＇가 있죠. 여기에 제가 설명하려는 Dimension/Metric의 이야기가 다 담겨 있습니다. 슬라이드에 나와 있는 표를 통해 이야기 해 보자면, 특성이 있다/없다, 혹은 남/여에 속한다, 혹은 성적이 몇 점이다 하는 내용이 담기고 그 각각의 특성은 세로줄 colum으로, 한 사람은 가로줄 row로 나와 있구요. A라는 사람의 X라는 특성을 보려면 여기를 보면 된다 – 이게 흔히 말하는 날 데이터, raw data의 형식입니다.
- 도식적으로 보면 이렇습니다. 이게 왜 중요할까요? 데이터베이스나 스프레드시트에 보통 이렇게 쓰니까? dimension이 세로에 있고 entity가 가로에 있는게 중요할까요? 아니죠. 여기서 중요한건요 모델링은 어떤 대상을 미리 정해 놓은 특성의 값으로 재정의한다. 반대로 특정 대상은 특성의 값 조합으로 규정된다. 하나의 대상에는 여러 특성이 있고, 각각의 특성 값은 서로 조합해서 새로운 특성을 구성할 수 있다. 이겁니다. 그래서 데이터 테이블, 여러분도 익숙한 이런 표를 그리게 되는거죠. 앞의 슬라이드와 비교하며 볼까요. 그럼 이런 디멘션/메트릭으로 모델을 구축하면 말이죠,
- 숫자 그 자체가 이야기를 해 줍니다. 좀 더 거시적인 관점에서 어떤 결론을 내릴 수 있다는거에요. 약간 실전적인 사례 하나로 이야기를 해 보겠습니다.
- 제가 가끔 인터넷 신문 기사를 보다가 좀 얼토당토 않은 분석을 보면 흥분하는 취미가 있는데요. 지금 보여드리는 사례는 3년 전 쯤 모 일간지 기획 기사로 나왔던 내용입니다. 왼쪽 그래프의 문제는, 굉장히 명백해 보이죠? 막대 그래프처럼 보이는데 막대 그래프가 아니에요. 사람 사는게 다 그게 그거라는 식의 명백한 의도가 있죠. 그럼 오른쪽을 볼까요. 간명한 숫자로 보면 이렇게 됩니다. 이 숫자는 OECD 데이터에서 찾았는데, 국제 통계는 OECD 홈페이지 가 보시면 꽤 괜찮은 데이터가 여럿 있어요. 여튼. 왼쪽을 볼 때와 오른쪽을 볼 때 느낌이 확 다르다 그죠? 다시 한 번 ‘모델링’의 관점을 말씀 드리지만, 어찌됐건 여기서 나타나는 숫자가 절대적으로 ‘한국에서 사는건 일본에서 사는 것보다 약 2배, 중국에서 사는 것보다 7배쯤 힘들다!’ 하는건 아니에요. 개개인의 여러 사소한 차이는 알 수 없는거죠. 하지만 큰 관점에서, 여러 사람들의 이야기를 뭉뚱그려 보면 – 어쨌든 사람 사는게 다 그게 그거는 아니다, 그죠? 이런 분석이 어떻게 나왔다?
- 그 방법은 여러가지가 있지만 기본적으로 과학 실험 과정과 크게 다르지 않습니다. 일단 현상을 관찰합니다. 그리고 현상을 설명할 수 있는 어떤 가설을 세워요. 데이터 분석의 측면에서 보면 여기서부터 ‘모델링’ 관점이 시작됩니다. 가령, 금방 다들 금방 잠드실 줄 알았는데 왜 아직까지도 자리를 지키고 계실까? 좀 웃길려고 애쓰면 많이 남을까? ‘웃기면 많이 남는다’는 가설이 나왔죠. 그럼 ‘실험’을 시작합니다. 웃기면 많이 남는다는 사실을 어떻게 확인해야 할까요? 이제 여러분을 딱 세 그룹으로 나눌게요. 이 쪽 분들은 이제 웃긴 얘기만 들으실거에요. 이게 ‘실험군’ 이고. 이 쪽 분들은 이제부터 완전 안 웃긴 얘기만 들으실거구요. ‘대조군 1’입니다. 마지막 여러분은 반반씩 섞어 들으실겁니다. ‘대조군 2’입니다. 그리고 30분 후에 몇 분이 눈을 뜨고 계신가, 이제 평가 들어갑니다. 방금 여러분은 과학 실험의 기본 요건을 들으신 겁니다. 첫째, 저는 여러분을 동질적인 랜덤 그룹으로 나웠어요 – 세그멘테이션 또는 코호트, 라고 합니다 보통. – 둘째, 알아 보려는 가설과 관계 없는 다른 모든 조건은 가능한 비슷하게 유지하구요. 셋째, ‘농담 비율’과 ‘뜬 눈 숫자’라는 명확한 숫자로 결과를 평가합니다. 이게 한 사이클이고, 실제로는 전 과정에 걸쳐 이런 사이클을 여러 차례에 걸쳐 반복합니다.
- Strategy. 전략. 네 그렇습니다. 시쳇말로 Growth hacking 이라거나 데이터 분석, 데이터 인사이트 같은 말이 가리키는 지점이 딱 이거에요. 데이터를 통해 전략을 수립하고 실행한다는거죠. 사실 역사적으로 보면 굉장히 오래된 얘기입니다. 거의 손자병법의 손자, 마케도니아의 알렉산더 시대까지 올라가야 해요. 우리의 최종 목적도 여기에 있습니다. 전략에서 데이터를 활용하려면, 어떤 목적을 달성할 것인지 알아야 하고. 그 목적을 어떻게 평가할건지 알아야 하고, 어떤 수단을 동원해야 하는지 알아야 합니다. 진행하는 동안 현황이 어떻게 돌아가는지 파악하는건 물론이구요. 전략에는 정답이 없습니다. 아마 강의 내내, 데이터 전략에 필요한 도구와 방법론을 쭉 말씀 드릴텐데 그 답은 제가 드릴 수 있는게 아니고 스스로 자신만의 방법을 찾아 낼거라 기대합니다.
- 더 들어가기 전에 역순으로 기본 줄기를 다시 잡고 가 볼까요. 첫째. 데이터 분석은 왜 하고, 어떻게 필요하다? 전략상 필요하기 때문에, 전략 설정과 실행에 필요한 방향으로. 둘째. 그럼 분석을 하기 위한 기초 작업이 뭐다? 숫자와 특성을 동원해서 현상을 ‘연산 가능한‘ 모델로 만드는 작업, 즉 모델링. 셋째. 그렇게 계산/예측하는건 어떻게 진행한다? 일반적인 과학 실험 프로세스를 따른다. 잠깐 쉬어가는 차원에서 딴 얘기를 좀 해 볼게요. 여기 계신 분들은 대부분 인문/상경 계통이신걸로 알고 있습니다만 혹시 ‘사이언티스트’와 ‘엔지니어’의 차이가 뭔지 아시나요? 즉, 과학과 공학의 차이가 뭔지, 제가 굳이 스스로를 좀 더 멋있는 ‘데이터 사이언티스트’가 아니라 ‘데이터 엔지니어’로 소개하는지, 궁금하지 않으세요? 호기심이 말랐네. 가장 큰 차이는 질문 방식에 있습니다. 과학자는 ‘왜?’ why?라고 묻습니다. 왜? 하루는 24시간으로 반복되지? 왜 태양은 동쪽에서 떠서 서쪽으로 지는거지? 왜 인터넷으로 기저귀를 주문하는 사람은 맥주를 같이 사는거지? 그러나 엔지니어는 ‘어떻게’? how?를 묻습니다. 어떻게? 밤낮이라는 시간 주기를 어떻게 활용해야 하지? 태양의 일주로 어떻게 시간을 잴 수 있지? 비유하자면 인문 철학과 상경계열, 혹은 순수 예술과 대중 예능의 차이라고 할까요. 엔지니어라고 해서 ‘왜?’라는 질문이 중요하지 않다는건 아니에요. 쉽게, ‘잘 작동한다면 이유는 좀 천천히 알아도 좋다＇는 겁니다. 이런 태도의 차이가 과학자와 엔지니어를 가르고 따라서 엔지니어를 만난 여러분이 이 강의를 잘 오신겁니다. 물론, ‘어떻게’를 설명할 수 있는 정도의 ‘왜＇는 알아야 해요. 이제부터 그 기술 얘기를 좀 해볼까요.
- 웹서비스의 개발자는 크게 두 가지로 나누죠. 프론트엔드와 백엔드 개발자. 그 두 가지의 차이가 뭘까요? 쓰는 언어? 비유적으로 여러분이 고급 레스토랑에 갔다고 할까요. 레스토랑에 들어가면 카운터에서 여러분을 맞이하고, 자리로 안내하고, 주문을 받아서 서빙을 하겠죠? 그 과정에서 여러분이 커뮤니케이션하는 대상은 요리사가 아니라 종업원이겠죠? 괜찮은 레스토랑이라는 가정 하에, 여러분이 주방에 대고 스테이크 미디엄 같은 말을 소리 칠 기회는 없어요. 사실 진짜 고급 레스토랑이라면 여러분은 주방 안에서 무슨 일이 벌어지는지 볼 기회도 없을거에요. 웬만하면 보여주지도 않을 테구요. 웹서비스도 그런 식의 분업을 합니다. 주방, 그러니까 주요 작업이 벌어지는 뒷단은 서버사이드 – 혹은 백엔드라고 합니다. 여러분을 맞이해서 케이터링을 비롯해서 여러 응대를 하는 종업원은 클라이언트 사이드 – 프론트엔드라 하구요. 그리고 주방과 홀 서빙을 담당하는 양쪽에서 긴밀하게 커뮤니케이션을 하면서 손님을 받겠죠. 웹이나 모바일 환경도 마찬가지입니다.
- 자, 이제 레스토랑에서 영업이익을 올리기 위해 손님을 대상으로 예의 모델링과 측정을 시작한다고 가정해 볼까요. 뭘 할 수 있을까요? 많죠. 어떤 손님이 매출 기여도, 영업이익 기여도가 높은지 평가해서 더 ‘비싼’ 손님층을 끌어오는 고객 관리를 할 수 있겠죠. 아니면 계절, 날씨, 요일 같은 외부 요인에 따라 어떤 메뉴가 더 잘 나가는지 예상해서 재료 재고를 조정할 수 있을거구요. 한 번 찾은 손님이 어느 정도 이익을 가져다주는지 알고, 광고비를 어느 정도 썼을 때 새로운 손님이 어느 정도 오는지 알면, 광고비로 어느 정도를 소모하는게 가장 효율적인지도 계산할 수 있을거구요. 웹사이트던, SNS 마케팅에서던 똑같은 활동이 이루어집니다. 그런데 이 점을 생각해 보셔야 해요. 레스토랑이라면 주방에서 얻을 수 있는 정보와 홀에서 얻을 수 있는 정보가 다르죠. 가령, 송아지 뒷다리 스테이크가 몇 % 소진 되었는지는 홀보다 주방에서 더 잘 알 수 있죠. 금요일에 20-30대 젊은 손님이 많은지, 50대 이상의 손님이 많은지는 홀에서 더 잘 알 수 있습니다. 인터넷을 설명하려면.. 그러니까 여러분은 여러 ‘사이트’를 방문 할 때마다 컴퓨터를 바꾸지는 않죠. 레스토랑보단 서빙을 하는 푸드코트 처럼 생각하시면 어떨까 싶어요. 구글 애널리틱스는, 비유하자면, 홀에서 주문을 받을 때 그 주문을 복사해서 쌓아 두는겁니다. 페이스북 인사이트 같은 경우에는 주방에서 주문이 나갈 때 쌓아두는 것에 가깝구요. 정확히 말해서 페이스북은 양쪽을 전부 집계합니다만.
- 다음 시간에 자세히 설명하겠습니다만, 구글 애널리틱스는 이런 방식으로 진행합니다. 사용자가 브라우저에서 어떤 액션을 합니다. 가령, 어떤 사용자가 처음으로 우리 사이트에 들어왔어요. 이때 구글 애널리틱스는 웹사이트를 그려내는 코드에 들어 있다가, 브라우저에서 코드를 실행하면 정해 둔 위치에 사용자가 어떤 행동을 했다 – 라고 신호를 보냅니다. 이렇게 보낸 하나의 신호를 ‘히트＇라고 합니다. 구글 애널리틱스에서 가장 대표적으로 쓰이는 히트는 페이지뷰 또는 스크린뷰인데요. 한 마디로 어떤 페이지 또는 화면을 열었을 때 발생하는 히트입니다. 페이지 URL, 그러니까 그리고 이벤트, 사건이 있는데요. ‘사건’의 경우에는 어떤 ‘사건＇을 어떻게 기록할지 미리 규정을 해 둬야 합니다. 이벤트 설정 방법은 아마 다음주 실습에서 설명 드리게 될거에요. 기본 설정에서 어떤 사용자가 웹페이지에 있는 영상을 재생했는지 아닌지는 알 수가 없어요. 혹은 요즘 나오는 것처럼 페이지 안에서 탭을 전환하거나 팝업창을 열어 보는 경우에는 페이지 전환이 아니기 때문에 별도로 기록하지 않아요.
- 완전히 기술적인 이야기라 좀 어려울 수 있는데, 잠깐 웹사이트 주소창에 들어가는 내용이 어떻게 해석되는지 규약을 좀 이야기를 해 볼게요. 아시는 분들은 간단히 넘어가셔도 괜찮아요. 가끔 웹사이트 들어가면 여기 주소창에 이런 좀 알아보기 힘든게 막 들어가 있죠? 유효한 주소 아니니 넘어가셔도 돼요. 전문용어로는 URL, 또는 URI 라고 하는데요. 인터넷 상에 있는 특정 자료의 위치를 정해둔거에요. 왼쪽부터 첫 번째는 ‘프로토콜‘, 그러니까 어떤 통신 규약을 통해서 통신하는지를 나타냅니다. 이 경우는 http구요. 프로토콜 바로 다음으로 호스트의 도메인 이름. 예의 푸드코트 비유를 들자면 어느 ‘주방＇에 주문을 해야 하는지를 가리킵니다. 그리고 바로 슬래시로 이어진 주소가 있는데요. 이건 주방에서도 특정 분과, 요리사를 가리킵니다. 여기로 주문을 하라는거죠. 정확하게 그 분과에 해당하는 주문 대상자가 없으면? 그건 식당 안에서 주문을 처리 할 수 있는 적당히 비슷한 다른 요리사를 연결해 주거나, 아니면 주문이 불가능하다고 돌려 보내겠죠? 인터넷도 똑같습니다. 그 다음은 물음표 다음에 무슨 수식이 있는데요. 이건 일종의 특수 옵션 주문입니다. 경우에 따라서는 이런 주문을 필수적으로 물어오는 곳도 있어요. 고급 레스토랑이 좀 그렇죠. 스테이크는 어떻게 해 드릴까요, 드레싱은 뭘로 드릴까요, 수프는 어떤 걸로 드릴까요. 면은 어느 정도 굳기가 좋으세요. 답을 얻기 전에는 절대 안 가져오죠 귀찮게. 마지막은 검색 태그인데.. 사실 이 부분 때문에 길게 설명한겁니다. 이건 비유하자면 주문 내역 중에서 콕 짚어서 에피타이저, 아니면 메인 디시, 디저트, 같은 느낌인데요. 이게 없어도 주문은 이미 완벽하게 들어간 상태입니다. 그 중에서 무언가 하나를 내 촛점, 전문용어로 ‘포커스＇를 두고 보고 싶다는 거에요. 방금 주문은 이미 완벽하게 들어간 상태라고 말씀드렸죠? 한 페이지 안에 여러 요소가 들어간 경우, 비유하자면 어떤 세트 메뉴 같은 경우 순서대로 에피타이저, 메인, 디저트가 나오죠. 그래서 인덱스 페이지나 인페이지 탭 전환, 팝업 같은 경우 이런 주소를 씁니다. 그런데 이게 꼭 일반적인 경우는 아니라서 구글 애널리틱스는 에피타이저, 메인, 디저트를 따로 기록하지 않아요. 하나의 주문이 들어갔다, 혹은 그 주문대로 잘 나왔다, 정도만 집계를 하죠. 이런 주문중에서 어떤걸 중요하게 두고 보면서 집계해야 할까요? 그건, 여러분이 정해 주셔야 해요. 그래서, 이벤트 히트가 필요한 거구요. 다시 앞으로 돌아가 보죠.