brunch

매거진 회사일지

You can make anything
by writing

C.S.Lewis

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들을 사용하게 될 것이라는 것을 고려하지 않는다


분석용 데이터는 그 데이터가 실제로 사용될 때 의미가 있다. 이는 반대로 데이터가 어떻게 사용될지에 따라 데이터가 형식과 구조를 바꿔야 할 때도 있다는 것이다. 만약에 분석용 데이터를 사용하는 사람이 Metabase 나 Redash 같은 sql 쿼리를 직접 날려 시각화하는 도구를 사용한다면 데이터 엔지니어의 많은 업무가 덜어진다.

하지만 서비스가 커가면 커갈수록 모든 사람들이 sql을 사용하는 것도 아니지만 데이터를 활용하려는 사람들은 늘어나기에 Amplitude 같은 sql 작성 없이 쉽게 데이터를 활용할 수 있는 BI 도구들을 도입하게 된다.


문제는 이때 각각의 BI 도구들이 요구하는 데이터 형식이 있다는 것이다. 그래서 데이터 엔지니어는 핵심적인 분석용 데이터 DB 구조를 가지는 DB대로 가지고 있으면서, 그 DB를 사용해 각각의 BI에 맞는 데이터를 다시 생산해야 할 때가 있다.


이때, 많은 엔지니어들이 이 핵심이 되는 분석용 데이터 DB 구조를 설계하지 않은 상태에서 그때 사용하기로 결정한 BI 툴에 최적화된 데이터 파이프라인을 만든다.


뭐, 초기에는 괜찮다. 분석용 데이터 DB 설계할 시간이 없을 수도 있으니까. 그런데 결국에 회사가 커지면 커질수록 다양한 BI 툴을 사용하게 될 것인데, 그때마다 각 BI 툴에 치적회 된 데이터 파이프라인 만들 것인가? 그러면 업무의 복잡도는 둘째 치더라도 분석용 데이터 자체가 개판이 되어버린다!


그래서 나는 데이터 엔지니어들 또한 서비스 전략에 발맞춘 데이터 전략을 만들어야 한다고 생각한다. 꼭 지켜야 하는 것은 무엇이고, 서비스 단계에 따라 해야 하는 것은 무엇인지 데이터 엔지니어 팀 또한 가지고 있어야 데이터 또한 정합성을 가진다고 생각한다. 그렇지 않으면 그냥 분석가가 "너 죽고 나 죽자! 데이터 왜 이래! 왜 이래!" 이런 상황이 오는 것이다


따라서 나는 데이터 엔지니어가 아래와 같은 것들을 고려하며 업무를 해주면 어떨까 하는 개인적 바람이 있다.

1. 분석용 데이터는 서비스 구조를 반영해야 한다

2. 분석용 데이터는 이해하기 쉽고 분석하기 쉬운 구조를 가져야 한다 (당신이 ETL 하기 쉬운 구조가 아니라)

3. 서비스 성장에 따라 데이터에 대한 요구가 어떻게 변할 것이고, 그에 따라 대응하기 위해서 데이터가 어떤 구조를 되어야 하는지 전략을 만들어야 한다


매거진의 이전글 데이터 분석가 킹 받아 기획 공부하는 이유 A-Z
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari