by
Apr 10. 2022
데이터 분석가 킹 받는 데이터 엔지니어링 A-Z
데이터 분석을 하다 보면 킹 받을 때가 한두 번이 아니가. 그래서 추가로 내 분야도 아닌 것을 공부한 적도 한두 번이 아니다!
기획에 관해서 킹 받는 부분들은 이전 "데이터 분석가 킹 받는 질문 A-Z"와 "데이터 분석가 킹 받아 기획 공부하는 이유 A-Z"에서 다루었으니(이하 킹받 시리즈) 요번에는 개발에 관해 글을 써보겠다.
데이터 분석을 하다 보면 기획에서 데이터를 설계하는 것을 떠나, "데이터가 왜 이따구로 쌓이고 있는가"라는 생각이 든다. 내가 데이터 엔지니어도, 서버 개발자가 아님에도 불구하고 데이터가 개판 나기 일보 직전이라는 느낌을 받은 것이 한두 번이 아니다. 문제는 그래서 도대체 무엇이 문제인지 명확히 정의하기 힘들다는 것이다. 데이터를 사용하기 굉장히 불편하고 짜증이 나는데, 데이터 엔지니어링 관련하여 기반 지식이 없기 때문에 도대체 무엇이 문제인지 알기 어려운 것이다. 그래서 데이터 분석가들은(특히 나) 데이터 엔지니어링 및 서비스 백엔드에 관해 하나하나 공부하고 파보기 시작한다. 그 결과, 내돈내산 개발 강의 단계까지 나를 몰아가는 킹 받 포인트를 몇 개 정의해보았다.
1. 데이터 엔지니어들이 서비스 구조를 모른다
내가 읽어본 데이터 엔지니링 책들에 근거하면 분석용 데이터베이스 및 테이블을 만드는 것은 단순히 데이터를 정제하고 쌓는 것이 아니다. 그들이 정제하고, 변환시키고 쌓아서 만들어진 데이터가 서비스의 전략, 우선순위, 각 부서 간의 관계, 그리고 유저를 반영해야 하기 때문에 데이터 엔지니어들의 서비스 구조에 대한 이해는 필수이다. 예를 들어, E-Commerce 업체가 다른 모든 데이터는 다 남기는데, 유저의 장바구니 담기 데이터를 다 누락했다고 해보자. 무슨 일이 일어나겠는가. 그리고 이런 데이터 엔지니어의 서비스에 대한 이해가 Dimensional Model이 적용된 분석용 테이블들이라는 결과로 나타나야 한다.
문제는 많은 데이터 엔지니어들이 주어진 ETL(extract, transform, load) 관련 특정 업무만 하지 왜 그 데이터가 어떻게 설계되어 이렇게 적제 되아야 하는지, 그리고 이 데이터가 서비스 전체에서 어떤 부분을 차지하는지 고민을 하지 않는다는 것이다. 왜냐하면 그러한 이해 및 설계가 그들의 R&R이 아니라고 생각하기 때문이다!(정말로?)
그렇기 때문에 분석용 데이터라고 하는 데이터들을 보면 데이터들이 서비스의 구조 및 연결성을 고려하지 않고 굉장히 파편화되어 적제 되고 있는 것을 볼 수 있다. 달리 말하면, 뭐 데이터 하나 보려면 데이터 필터링과 데이터 조합을 굉장히 많이 해야 하는 경우가 많다. 그리고 그 와중에 데이터의 무결성도 내가 알아서 검증해야 하고.
나는 데이터 엔지니어들에게 반대로 물어보고 싶다. 그냥 ETL만 할 거면 내가 해도 되는데 왜 데이터 엔지니어란 직업이 필요하냐고. 단순히 Airflow, EC2, Hadoop 같은 도구들을 쓰는 것이 그들의 존재 목적인가?
물론, 그렇게 서비스를 고려해야 하는 것은 기획자가 해야 할 일이 아닌가 반문할 수도 있다. 이에 대한 내 답으로는 슈퍼 데이터 기획자가 있으면 이런 고민은 다 쓸모없지만 그런 사람이 한국에 몇 명이나 있겠는가? 그 문제에 가장 밀첩 한 포지션의 사람이 알아서 해야지.
2. Dimensional Model을 사용하지 않는다
Ralph Kimball의 데이터 웨어하우스 관련된 책을 본 적이 있다(거의 10년 전에 쓰인). 그리고 나는 굉장한 충격을 받았다. 왜냐하면 그가 제안하는 Dimensional Model이라는 형태를 지닌 데이터 분석용 데이터 테이블들이 데이터 분석가들이 그렇게 바라던 형태의 테이블이기 때문이다!
데이터 레이크도 좋고, 클라우드 DB 도 좋고 다 좋다 이 말이다. 그런데 그런 힙함에 취하기 전에 데이터가 데이터의 사용 목적에 맞는 구조를 취해하도록 설계해야 할 것이 아닌가?
많은 사람들이 분석용 데이터와 관련하여 데이터 조회 속도, 형식의 자율성, 인프라 관리 리스크 등을 걱정하는데 개인적으로는 반절 정도는 현실이랑 조금 맞지 않다고 생각한다. 그런 것들을 말하기 전에 그래서 분석용 데이터 테이블이 사람이 보기에 이해하고 분석하기 쉬운 형태인지 먼저 고려해야 하는 것이 아닐까?
Dimensional Model이라는 분석용 데이터베이스 설계 구조를 보기 전에는 그냥 데이터 쌓는 게 원래 이렇게 개판이려니 생각했다. 그런데 공부해보니 어떻게 보면 데이터 분석용 DB 구조에 대한 정석은 10년도 더 전에 책으로 이미 나와 있었다. 그냥 안 쓰고 있었을 뿐!
Ralph Kimball의 책에서 내가 데이터 분석용 DB구조에 대한 핵심은 아래와 같다(틀리수도 있고!)
1. 서비스의 핵심이 되는 활동을 정의한다 (해당 활동을 Fact table이라는 곳에 적제, 예: "구매")
2. 위의 Fact table을 기준으로 해당 활동에 추가적인 정보를 제공할 수 있는 정보그룹을 정의한다 (이러한 정보들을 그룹 지어 각각의 Dimension Table에 적제 한다. 예: "유저 정보")
3. 위의 Fact table과 Dimension Table은 비즈니스적 요구사항 및 서비스의 구조를 반영해야 한다
4. 각각의 테이블은 정보가 "변경" 될 때 해당 "변경"을 어떤 형식으로 할지 서비스를 고려해야 한다 (예: 유저의 집 주소가 변경되면 그냥 덮어쓸 것인가, 아니면 새로운 유저 데이터를 만들 것인가 등등)
요약해보면 매우 간단해 보인다. 문제는 이런 간단한 사항들을 고려하지 않고 데이터를 하나의 테이블에 다 때려 넣거나, 아니면 그냥 서버 데이터를 통째로 저장하는 것이 문제이다.
사실 그렇게 어려운 방법도, 책도 아닌데 왜 이와 관련돼 주제들이 내가 주변에서 보는 데이터 엔지니어들의 핵심 대화 내용이 아닌지 매우 의문이다. 이해하기 쉽고 분석하기 쉬운 분석용 데이터베이스 설계에 대해 진진하게 접근하는 데이터 엔지니어들이 내주면에 없는 것은 내가 모르는 것인가 아니면 정말로 없는 것인가?
3. 다양한 BI들을 사용하게 될 것이라는 것을 고려하지 않는다
