데이터를 조지는 101가지 삽질 전 물어볼 질문들

경험담

모든 것이 빠르게 변하는 이 시대에 "데이터 드리븐 결정"이라고 하는 멋있어 보이는 말을 기획서에 넣지 않으면 뭔가 2% 빠진 느낌이 든다. 하지만 이런 "데이터 드리븐"이라는 말에는 멋짐 보다 고통이 더 많이 스며들어 있다. 빨리 데이터를 사용하라는 사장님의 푸시, 데이터를 사용한 인공지능 사용 및 분석을 하고 싶어 들어오는 신입들, 그 중간에 그래서 뭘 어쩌고 싶은지 모르겠다는 눈으로 우리를 바라보는 개발자들, 마지막으로 나도 모르는데 권한은 없고 책임만 주어지는 기획자들. 이 모든 사람들이 엮이고 엮여서 만들어지는 현상을 아래와 같이 설명할 수 있다.

데이터 ㅈㄲ

나는 이러한 현상, 즉 데이터라는 이름 아래 자행해지는 고문에 가까운 푸시와 압박감을 120% 공감한다. 그리고 많은 문제들이 그렇듯 그 문제와 연관된 사람들을 욕을 하기는 쉬워도 막상 풀어보려고 하면 쉽지 않다. 나 또한 전 직장에서 "데이터의 수집, 정제 및 가공, 사용"이라는 완벽한 사이클을 만들기 위해 얼마나 고민했던가. 물론 그 결과가 오로지 성공적이었다고 할 수는 없다.  나름 주어진 한계 내에서 열심히 구상하고 적용시키고 퇴사했지만, 남들이 보기에는 커다란 똥 덩어리를 남기고 튀었다고 인식하는 것이 인생사 아니겠는가.

물론, 몇 년이 지난 후 지금 다시 돌이켜 보니 똥 까지는 아니지만 얼기설기 치장된 쓰레기 현대미술 작품을 남기고 온 것 같기는 하다. 후에 올 후임자가 연금술사처럼 그 쓰레기를 황금으로 바꿀 여지는 남겨두고 왔지만, 그렇다고 쓰레기가 황금으로 저절로 되는 것은 아니니.. 뭐, 알아서 하겠지

근래에는 단순히 데이터를 사용하는 것에서 확장하여 데이터를 수집하고 정제하는 과정까지 분야를 넓히기 위해 여러 가지 것들을 배우고 있다. 축약해보자면 데이터 엔지니어링과 관련된 여러 강의들을 들어보고 있는 중이다. 내 시야가 분석에서 벗어나 데이터의 완전한 사이클(수집, 정제, 사용)에 대해 점차 이해해 나아가다 보니 왜 전 직장에서 그렇게 데이터를 사용하기 어렵고 불편했는지 알 수 있었다. 데이터는 있지만 그 누구도 회사에서 사용되는 데이터의 전체적인 그림에 대해서 이해를 하지 못하는 상황이었기 때문이다. 여기에 더해서 개인에서 개인에게 구전으로 내려오는 데이터 엔지니어링 구조 및 지식이 상황을 더욱 악화시키고 있었다 (개발자들 이어, 제발 문서를 써라. 적어도 퇴사하기 전까지)

따라서 데이터 드리븐 의사결정을 통해 서비스를 키워 나아가고자 하는 스타트업이라면 애초에 데이터에 대해서 잘 아는 사람이 리더 PM으로 있으면 서비스의 많은 것을 빠르고 효과적으로 개선할 수 있는 능력을 키울 가능성을 회사에게 줄 수 있다고 생각한다. 물론 초기에 투자받고 성장하느라 데이터에 대해서 깊게 생각해보는 것 자체가 과도한 부담이라는 말 또한 동의한다. 그렇기 때문에 PM의 역할이 더욱 중요하다고 생각한다.

단순히 서비스를 만들어 나아가는 것을 뛰어넘어 해당 서비스를 이해하고 분석하고 개선하기 위해서는 초기에 서비스 구현에 많은 권한을 가진 PM이 어떤 구조의 데이터 수집, 정제, 사용 사이클이 만들어져야 하는지, 그리고 이를 위해서는 어떤 인프라 구조가 만들어져야 하는지 대략적으로나마 알고 있어야 한다고 생각한다. 세부적인 개발 지식은 개발자들이 한다고 쳐도, 일단 데이터를 사용할 수 있는 환경을 만드는 프로젝트 자체는 PM이 킥오프를 해야 할 것이 아닌가.

방향도 잡고! 어!
막 데이터 구조도 예시 보여주고! 어!
 막 개발자들에게 데이터 엔지니어링 리스크 고려 요소도 알려주고! 마!

막! 다 해야 할 거 아닙니까! 마!

이런 사람이 있었다면 얼마나 좋았을까 생각을 하며 적은 이상적인 PM이니 위의 대충 넘어가도록 합시다

그래서 나도 잘 모르지만 이런 기반 지식을 내가 이전에 알았으면 얼마나 좋았을까 느낌으로 데이터 엔지니어링 및 분석 프로세스에 대해서 조금 설명해보도록 하겠다. 수많은 가정과 오류와 무식이 들어간 글이니 귀엽게 봐주세요. 데헷

위에서 말했다시피, 데이터의 사용은 단순히 데이터를 분석하는 것이 아니다. ㅈ같은 소스 데이터에서 데이터를 모으고, 정제하고, 쌓고, 쌓은 것을 필요한 곳 혹은 사람에게 알맞은 형식으로 제공하고, 데이터를 제공받은 사람은 그 데이터를 사용하여 현상에 대해 분석하여 서비스적 가치를 제공하는 것 (및 입을 터는 것. 핵심) 모두 다 포함된다

그중 분석은 분석가가 하겠고, 그 이전의 모든 프로세스는 데이터 엔지니어가 한다. 사실 데이터를 알기 위해서는 데이터를 사용하는 시점 이전에 데이터에서 어떤 일들이 일어나는지 알고 있어야 한다. 이를 위해 데이터 엔지니어링이 무엇인지 한번 알아보도록 하자 (참조 : Foundations for Architecting Data Solutions: Managing Successful Data Projects)

일단 데이터 엔지니어링의 업무는 아래의 3가지 종류로 나눌 수 있다   

데이터 파이프라인 만들기

리포트 만들고 자동화 하기

서비스에 필요한 데이터 제공

이중에 가장 핵심적인 업무가 바로 데이터 파이프라인 만들기라고 할 수 있다. 그리고 데이터 파이프라인을 만든다는 것은 데이터를 사용한 유저(관계자, 사장님, 자본주의 노예 등등) 들의 니즈와 사용 패턴, 그리고 소스 데이터가 어떤 형식으로 되어있고 또 어떻게 수집되어야 하는지를 고려하여 인프라 구조를 만든다는 것이다. 그리고 100자 내외로 설명된 이러한 업무는 실제로 적어도 한 분기(당신이 유니콘이라면), 길면 6개월(당신이 야근을 스포츠라 생각한다면)에서 1년 이상(당신이 건실한 청년이라면)이 걸리는 일이다.

이에 더해서 굉장히 많은 세부적인 요소들이 고려되어야 하지만, 코드 PM이 짜는 거 아니잖아요? PM은 개념만 전달하고 방향만 확인할 뿐. 그래서 야근과 구체화, 그리고 실현은 프로그래머가 하도록 해요~! 저희는 입을 털 수 있을 정도의 지식에 대해서 알아보도록 합니다.

데이터 인프라는 아래와 같은 구성으로 나눌 수 있습니다   

원본 소스에서 데이터 수집

정해진 룰 및 구조에 따라 데이터 정제 및 쌓기

데이터 제공하기

쉬워 보이지만 사실 쉽지 않은 일이다. 일단은 원본 소스에서 데이터 수집을 할 때 어떤 것을 고려해야 하는지 매우 쉬운 단어로 알아보자.

데이터를 수집하는 방법 자체가 몇 개가 있다 (API, Agent, Embedded Code). 뭐 내 알바는 아니고 일단 각 수집 방법들의 작동 방식 및 수집 데이터가 고정되어 있어 영원불멸하는 것이 아니라는 것을 알아둡시다. 따라서 원본 소스의 사정에 따라, 그리고 우리 데이터를 사용하고자 하는 사람의 사정에 따라 원본 소스에서 수집되어야 하는 그리고 수집되는 데이터 형식이 조금씩 바뀔 수 있다. 혹은, 수집되는 데이터 형식을 똑같지만 내부 데이터 내용이 바뀔 수도 있고, 혹은 코드가 바뀌어서 갑자기 알 수 없는 무언가 찜찜하지만 찾을 수 없는 것이 바뀔 수 도 있다.

 이때 책임감을 가지고 열일 해야 하는 것이 바로 데이터 엔지니어다. 애초에 데이터를 수집하는 코드를 짤 때 나중에 조금 바뀌더라도 해당 데이터 형식이 유연하게 확장될 수 있고, 더 나아가 이전 버전의 데이터와 최신 버전의 데이터가 backword compatability를 유지할 수 있어야 한다.

쉽게 말하면 원래 기말고사 끝나고 A~F로 오던 학점이 갑자기 월별로 1~5 사이의 스코어로 오게 된다거나, 아니면 원래는 이메일로 오는 성적이 지금은 내가 직접 교수님에게 가서 공물을 바치고 획득해야 하는 상황이 있으면 안 된다는 것이다.

물론 이 외에도 많은 것을 고려해야 하지만, PM분들은 이것 하나는 명심하자. 질문이 답이다

원본 소스 수집에 관해 데이터 엔지니어에게 아래의 질문들을 해보자

데이터 수집 오류 나면 어떻게 해결해요? (오류 케이스는 어떤 것들이 있죠?)

데이터 형식이 나중에 바뀌면 어떻게 돼요? (내가 님보고 원본 소스에서 더 다양한 데이터를 수집해야 한다고 급 발진한다면?)

원본 소스 데이터가 바뀌면 어떻게 돼요? (백엔드에서 갑자기 서비스 구조 바꾸는 김에 데이터 구조도 바꾸면 해결 가능?)

제가 또 무엇을 알아야 할까요? (대충 고려하기 귀찮아서 밑장 깐 거 있으면 어서 알려주세요!)

그다음으로 고려할 것은 데이터의 정제 및 쌓기이다. 보통 transformation and staging이라고 하는데 그 말이 그 말이니 있어 보이고 싶을 때 써먹도록 하자. 이 단계의 아웃풋은 명확하다. 바로 우리가 입이 마르도록 말하는 데이터 웨어하우스 혹은 데이터 레이크이다. 그러면 여! 기! 서! 데이터 웨어하우스란 무엇일까?

쉽게 말하면 대학교에서 성적 받으려고 하니 각 과목의 모든 교수님을 일대일로 만나서 포켓몬 고 포켓몬 잡듯이 성적을 하나하나 캐치해야 할 필요 없이 그냥 대학교 행정실 가서 한방에 뽑을 수 있도록 하는 것, 그것이 데이터 웨어하우스가 하는 일이다. 즉, 데이터로 무언가 분석하려고 하니 이 데이터 베이스, 저 데이터 베이스 돌아다니며 데이터 수집해서 일일이 수가공해 하나의 데이터로 만들다 보니 머리가 돌아버린다. 그래서 그 데이터들을 복사하여 목적에 알맞게 가공하고 하나의 데이터 베이스(혹은 데이터를 저장하는 데이터 베이스들)에 저장해 놓은 것을 데이터 웨어하우스라고 한다.

이런 데이터 웨어하우스를 만들 때 고려해야 하는 것이 있다. 바로 수집하는 데이터의 형식이다. 데이터가 비정형적 데이터인지, 그리고 배치 형식으로 수집해도 되는지 아니면 스트리밍으로 수집해야 하는지를 고려해야 한다. 말해보자면, 테이블에 넣어서 간단히 분석할 수 없는 데이터들 (비정형적 데이터)가 있다면 이를 어떻게 저장하고 또 어떻게 사용하도록 할지 고려해야 한다. 만약 여기에 더해서 데이터를 실시간으로 분석해야 한다면 수집되는 데이터 또한 실시간으로 업데이트되어 데이터 웨어하우스에 쌓여야 한다.

말이 길었는데 PM들은 아래의 질문들을 데이터 엔지니어에게 해보자   

지표 1초 단위로 실시간으로 업데이트하고 싶은데 가능한가요? (너의 데이터 구조의 한계를 시험해보겠다)

막 한글로 되어있는 리뷰나 이런 거 검색 가능해요? (Elasticsearch 들어봤어? 모르면 야근하자)

거 막 제가 sql 쿼리로 데이터 불러올 수 있어요? (search * 하면 어떻게 돼요? 헤헷)

물론 여기까지 읽어도 아직 감이 잡히지 않을 수도 있다.

그러면 어떻게 해야 할까?

인생은 심플하다.
공부를 하도록 하자.
많이