> 이 글은 예측 모델링을 주 업무로 하는 데이터 과학자가 아닌 일반 IT 조직에서 데이터 인프라 적용을 고민하고 있거나 데이터 분석을 한다는데 어떻게 해야할지 모르는 엔지니어 또는 해당 조직의 구성원들을 대상으로 쓴 글입니다. ## 들어가며 최근에 데이터 분야가 인기가 많아지면서 인공지능, 딥러닝, 머신러닝을 학습하거나 입문하는 사람들이 많아졌다. Kaggle에서 다양한 데이터를 가지고 Python 또는 R 에서 제공하는 데이터프레임 라이브러리를 바탕으로 데이터를 분석하고 그래프를 그려보고 Scikit-learn 이나 Tensorflow 를 사용하여 복잡한 원리나 수학적 이론이 부족하더라도 간단한 코딩만으로 예측 모델링을 할수도 있다. 데이터 분야에 관심이 많고 앞으로 계속 이 분야에서 공부하길 원한다면 이러한 학습 방법은 입문자에게 아주 유용하다. 하지만, 대부분의 스타트업 또는 IT 인프라가 부족한 사내 조직에서 당장의 이러한 기술은 쓸모가 없어진다. (인공지능 스타트업이나 데이터 전문 스타트업은 당연히 제외한다.) 원인은 다양한데, 먼저 대부분의 조직에서 데이터가 없다. 데이터가 없다고 하면 대부분 개발자들이 이렇게 말할 것이다. “우리는 DB도 가지고 있고, 로그도 잘 쌓고 있고, 데이터가 아주 많습니다.” 정말 그럴까? <br /> ## 데이터가 없다. IT 인프라를 운영하면서 쌓이는 데이터의 종류는 다양하다. 어떤 커머스 서비스가 있다고 할때, 상품의 내용이 저장되어있고 상품을 구매하거나 후기를 남기는 등의 데이터는 분명 DB에 저장되어 있을 것이다. 그리고 백엔드 개발자가 있다면 기본적으로 어떠한 요청을 주고 받았는지에 대해서 따로 로깅을 하고 있을 수도 있다. 다만, 이러한 데이터는 우리가 앞에서 배운 예측 모델링에 활용되기에 적합하지 않은 데이터일 가능성이 크다. 현대 머신러닝(또는 딥러닝)으로 문제를 풀기 위해서는 대부분 지도 학습, 즉 기계에게 라벨링된 데이터를 주고 학습 시켜서 모델을 만드는 방식인데, 머신러닝에 대한 백그라운드 없이 어떠한 데이터에 대해서 무언가 라벨링이 되는 데이터 형태에 대해서 이해하고 있거나 준비되어 있지 않을 가능성이 크다. (물론 기존의 DB/로그 데이터를 활용해 빡센 전처리 과정을 통해서 그러한 데이터 포맷을 만드는 것이 불가능한 건 아니다.) 즉, 우리가 타이타닉 생존 문제를 예측하기 위해서 어떠한 속성의 사람이 죽었다/살았다 라는 데이터가 있어야 하는데, 이게 참 도메인마다, 즉, 서비스마다 케바케라서 쉽지 않은 경우가 대부분이다. 또한 기술적인 논의나 데이터 이전에 우리가 예측 모형으로 풀어야하는 문제에 대해 정의하기가 쉽지 않은 경우도 많다. <br /> ## 예측 이전에 현황 파악 그리고 예측 모델링 이전에 현재 운영되는 제품의 데이터 현황 자체도 파악이 안되는 경우가 대부분이다. 단순히 트래픽이나 다운로드 숫자가 아니라 사용자가 우리 제품에서 어떻게 행동하는지, 전환율은 어떤지, Retention은 어떤지 같은 것들 말이다. 웹/앱 서비스를 하고 있다면, 비지니스 가치를 이끌어내기 위해 우리는 사용자의 행동 로그를 가지고 있을 필요가 있다. (맞다, 당신이 생각하는 Google Analytics 같은 것으로 그것을 할 수 있다. Mixpanel 이나 최근에는 Amplitude 도 많이 활용하는 것 같다.) 단순히 트래픽을 확인하는 용도가 아니라 사용자가 어떤 페이지에서 어떤 버튼을 언제 누르고 얼마나 머무는지 등에 대한 데이터이다. 그런데 이러한 데이터는 일반 애플리케이션 데이터와 달리 짧은 시간에 굉장히 많은 데이터가 발생하게 된다. 사용자가 많으면 많을수록 해당 데이터는 기하급수적으로 늘어나고 사용자의 행동을 구체적으로 정의하고 트래킹하면 할수록 더욱더 늘어날 것이다. 이러한 데이터는 일반 RDBMS에서 감당하기 힘든 트래픽이 발생한다. 이때 데이터 웨어하우스가 필요하다. 이번 시리즈에서 소개할 구글의 BigQuery가 대표적이고 AWS의 Redshift 나 Snowflake 등도 있다. 그리고 이러한 웨어하우스들은 SQL로 데이터를 가져온다. 즉, 초기에 데이터를 만지면 뭔가 Sexy(?)해보이는 머신러닝 같은 예측 모델링을 생각하겠지만 지금 우리에게 필요한 건 어떤 데이터를 쌓는지 정의하고 그 데이터를 잘 쌓고 우리의 데이터를 잘 들여다보는 것이 먼저이다. SQL로 raw 데이터도 뽑아보고 계속 데이터를 뒤져보는 작업은 상대적으로 덜 Sexy(?) 하지만, 비지니스/도메인에서는 그저 현재 우리 사용자가 무엇을 많이 하는 지 아는 것만으로도 큰 의사 결정을 도울 수도 있다. <br /> ## 그래서.. 그래서 현재 초기 스타트업이고 데이터를 도입하고 싶은 현직자들은 머신러닝 책을 펼칠게 아니라 먼저 어떤 데이터를 쌓아야하는지 정의하고 (비지니스/도메인 레벨에서), 기술적으로 SQL과 데이터웨어하우스에 대한 공부를 하는게 더 바람직한 방향이다. 은근히 Python, R에 대한 학습 콘텐츠가 일반화되면서 해당 언어로 데이터프레임을 다루는 건 할줄 아는데 SQL을 못짜는 사람들이 많다. 하지만 SQL이 모든 데이터 분석 단계의 최소 지식이며 모든 RDB 또는 데이터웨어하우스를 관통하는 언어이므로 혹시나 본인이 데이터 분야에 입문했는데 SQL을 할 줄 모른다면 깊이 반성하고 당장 SQL 부터 공부를 하길 바란다. <br /> ## 요약 서론이 길었다. 장황한 내 비문을 참지 못해 스킵한 분들을 위해 요약을 하면, - 대부분 조직은 예측 모델링(머신러닝)을 충분히 할만한 데이터가 잘 없거니와 도메인에서 문제에 대한 정의도 안되어있다. - 앱/웹 서비스에서는 사용자의 행동 로그를 잘 쌓아서 그것만 분석해도 좋다. - 데이터를 쌓기위한 데이터 웨어하우스부터 구축해야 한다. - 일단 SQL부터 공부하라. <br /> > 이 시리즈(?)의 목적은 초기 개발 조직에서 데이터 리드를 하면서 데이터 엔지니어링 백그라운드가 없는 엔지니어들과 함께 손쉽게 데이터 웨어하우스를 도입하고 데이터 분석 을 위한 환경을 구축한 경험을 얘기하는 글이다.