(데이터 분석가 킹 받는 질문 A-Z) 기획자 | 커리어리

(데이터 분석가 킹 받는 질문 A-Z) 기획자는 유저에 대해 이해하고, 문제를 발견하고, 해결 방법에 대한 가설을 세우고 또 검증하는 사람이라는 것은 알겠다. 그렇기에 더욱더 당신도 무엇이 문제인지 모르는 상태에서 나에게 질문을 하지 말아 달라고 간곡히 부탁하고 싶다. 많은 사람들이 데이터 분석이라는 어디선가 들어본 힙에 차오를 것 같은 단어를 들어보고서 (예의 바르게 말하면 데이터 분석 R&R 은 모르지만 회사에 그 포지션이 있다는 것을 아는 상태에서) 데이터 분석가에게 찾아간다. 머리 한편에는 어떻게 풀어야 할지 모호한 서비스적 문제가 가득 들어있고, 이것을 명쾌하게 해결할 실마리가 보이지 않는다. 고객 분석을 해보자니 유저 리서치를 할 시간과 에너지는 없고, 또 안 하자니 고객에 대해 너무 모르기 때문에 어디서부터 문제를 정의하고 해결해야 할지 오리무중이다. 이때 우리 회사에 데이터를 가장 신박하게 잘 분석한다는 사람이 떠오른다. 바로 데이터 분석가이다! 그 사람이라면 서비스의 이런저런(?) 데이터를 조합해서 서비스에 대한 인사이트를 나에게 줄 수 있지 않을까? 마치 프로이트가 사름의 심리를 낱낱이 밝히듯이 나에게 고객의 심리와 행동에 대한 어떤 지혜와 답을 줄 수 있지 않을까? 제발 이런 생각으로 우리에게 다가오지 말아 달라. 서비스를 가장 오래 본 사람도 기획자이고, 가장 깊이 고민해본 사람도 기획자이고, 고객을 잘 아는 사람도 기획자인데 그냥 "인사이트를 찾아주세요!"라고 말하면 도대체 우리가 무슨 인사이트를 줄 수 있겠는가? 그래서 아래의 글을 적어봤다

데이터 분석가 킹 받는 질문 A-Z

brunch

2022년 3월 31일 오전 8:04

댓글 0

함께 보면 더 좋은

[데이터 분석가 킹 받는 데이터 엔지니어링 A-Z] 데이터 분석을 하다 보면 킹 받을 때가 한두 번이 아니다.  데이터 분석을 하다 보면 기획에서 데이터를 설계하는 것을 떠나, "데이터가 왜 이따구로 쌓이고 있는가"라는 생각이 든다. 내가 데이터 엔지니어가 아님에도 불구하고 데이터가 개판 나기 일보 직전이라는 느낌을 받은 것이 한두 번이 아니다. 문제는 그래서 도대체 무엇이 문제인지 명확히 정의하기 힘들다는 것이다. 그 결과, 이런저런 공부를 해보니 이 단계까지 나를 몰아간 킹 받 포인트를 몇 개 정의 할 수 있었다. 1. 데이터 엔지니어들이 서비스 구조를 모른다 분석용 데이터베이스 및 테이블을 만드는 것은 단순히 데이터를 정제하고 쌓는 것이 아니다. 그들이 정제하고, 변환시키고 쌓아서 만들어진 데이터가 서비스의 전략, 우선순위, 각 부서 간의 관계, 그리고 유저를 반영해야 하기 때문에 데이터 엔지니어들의 서비스 구조에 대한 이해는 필수이다. 예를 들어, E-Commerce 업체가 유저의 장바구니 담기 데이터를 적제하지 않는다면 어떻게 되겠는가? 문제는 많은 데이터 엔지니어들이 주어진 ETL(extract, transform, load) 관련 업무만 하지 왜 그 데이터가 서비스 전체에서 어떤 부분을 차지하는지 고민을 하지 않는다는 것이다. 왜냐하면 그러한 이해 및 설계가 그들의 R&R이 아니라고 생각하기 때문이다!(정말로?) 그렇기 때문에 분석용 데이터라고 하는 데이터들을 보면 데이터들이 서비스의 구조 및 연결성을 고려하지 않고 굉장히 파편화되어 적제 되고 있는 것을 볼 수 있다. 이런 데이터는 사용하기가 굉~장히 어렵다 물론, 그렇게 서비스를 고려해야 하는 것은 기획자가 해야 할 일이 아닌가 반문할 수도 있다. 슈퍼 데이터 기획자가 있으면 이런 고민은 다 쓸모없지만 그런 사람이 한국에 몇 명이나 있겠는가? 그 문제에 가장 밀첩 한 포지션의 사람이 알아서 해야지. 2. Dimensional Model을 사용하지 않는다 Ralph Kimball의 데이터 웨어하우스 관련된 책을 본 적이 있다. 나는 굉장히 충격을 먹었는데, 그가 제안하는 Dimensional Model 데이터베이스 구조가 바로 분석가들이 원하는 그런 것 이기 때문이다! 데이터 레이크도 좋고, 클라우드 DB 도 좋고 다 좋다 이 말이다. 그런데 그런 힙함에 취하기 전에 데이터가 데이터의 사용 목적에 맞는 구조를 취해하도록 설계해야 할 것이 아닌가?  그런 것들을 말하기 전에 그래서 분석용 데이터 테이블이 사람이 보기에 이해하고 분석하기 쉬운 형태인지 먼저 고려해야 하는 것이 아닐까? 이전에는 어쩔수 없이 데이터 쌓는 게 원래 이렇게 개판이려니 생각했다. 그런데 공부해보니 데이터 분석용 DB 구조에 대한 정석은 10년도 더 전에 책으로 이미 나와 있었다. 그냥 안 쓰고 있었을 뿐! 도대체 왜!  Ralph Kimball의 책에서 내가 데이터 분석용 DB구조에 대한 핵심은 아래와 같다(틀리수도 있고!) 1. 서비스의 핵심이 되는 활동을 정의한다 (예: "구매") 2. 위의 활동 관련 테이블을 기준으로 해당 활동에 추가적인 정보를 제공할 수 있는 정보그룹을 정의하고 테이블로 만든다 (예: "유저 정보") 3. 위 두 종류의 테이블은 비즈니스적 요구사항 및 서비스의 구조를 반영해야 한다 4. 각각의 테이블은 정보가 "변경" 될 때 해당 "변경"을 어떤 형식으로 할지 서비스를 고려해야 한다 (예: 유저의 집 주소가 변경되면 그냥 덮어쓸 것인가, 아니면 새로운 유저 데이터를 만들 것인가 등등) 요약해보면 매우 간단해 보인다. 문제는 이런 간단한 사항들을 고려하지 않고 데이터를 하나의 테이블에 다 때려 넣거나, 아니면 그냥 서버 데이터를 통째로 저장하는 것이 문제이다. 도대체 왜 Dimensional Model 구조를 사용하지 않는 것인가! 내가 모르는 다른 이유가 있는지 궁금하다 3. 다양한 BI들을 사용하게 될 것이라는 것을 고려하지 않는다 분석용 데이터는 그 데이터가 실제로 사용될 때 의미가 있다. 이는 반대로 데이터가 어떻게 사용될지에 따라 데이터가 형식과 구조를 바꿔야 할 때도 있다는 것이다. 만약 분석하는 사람이 sql을 사용 할 수 있으면 문제 없다. 그런데 서비스가 커갈수록 모든 사람들이 sql을 사용하는 것도 아니지만 데이터를 활용하려는 사람들은 늘어나기에 Amplitude 같은 sql 작성 없이 쉽게 데이터를 활용할 수 있는 BI 도구들을 도입하게 된다. 문제는 이때 각각의 BI 도구들이 요구하는 데이터 형식이 있다는 것이다. 그래서 데이터 엔지니어는 핵심적인 분석용 데이터 DB 구조를 가지는 DB대로 가지고 있으면서, 그 DB를 사용해 각각의 BI에 맞는 데이터를 다시 생산해야 할 때가 있다. 그런데 많은 엔지니어들이 이 핵심이 되는 분석용 데이터 DB 구조를 설계하지 않은 상태에서 그때 사용하기로 결정한 BI 툴에 최적화된 데이터 파이프라인을 만든다는 것이다. 뭐, 초기에는 괜찮다. 분석용 데이터 DB 설계할 시간이 없을 수도 있으니까. 그런데 결국에 회사가 커지면 커질수록 다양한 BI 툴을 사용하게 될 것인데, 그때마다 각 BI 툴에 치적회 된 데이터 파이프라인 만들 것인가? 그러면 업무의 복잡도는 둘째 치더라도 분석용 데이터 자체가 개판이 되어버린다! 그래서 나는 데이터 엔지니어들 또한 서비스 전략에 발맞춘 데이터 전략을 만들어야 한다고 생각한다. 꼭 지켜야 하는 것은 무엇이고, 서비스 단계에 따라 해야 하는 것은 무엇인지 데이터 엔지니어 팀 또한 가지고 있어야 데이터 또한 정합성을 가진다고 생각한다. 따라서 나는 데이터 엔지니어가 아래와 같은 것들을 고려하며 업무를 해주면 어떨까 하는 개인적 바람이 있다. 1. 분석용 데이터는 서비스 구조를 반영해야 한다 2. 분석용 데이터는 이해하기 쉽고 분석하기 쉬운 구조를 가져야 한다 (ETL 하기 쉬운 구조가 아니라) 3. 서비스 성장에 따라 데이터에 대한 요구가 어떻게 변할 것이고, 그에 따라 대응하기 위해서 데이터가 어떤 구조를 되어야 하는지 전략을 만들어야 한다

데이터 분석가 킹 받는 데이터 엔지니어링 A-Z

brunch

추천 프로필

현직자에게 업계 주요 소식을 받아보세요.

현직자들의 '진짜 인사이트'가 담긴 업계 주요 소식을 받아보세요.

커리어리 | 일잘러들의 커리어 SNS