서비스 기획자의 데이터 거버넌스
무엇을 취할 것이며, 어떻게 다룰 것인가?
요즘 퍼포먼스 마케팅 데이터를 통합하고, 담당자들의 업무를 효율화할 수 있는 사내 프로그램을 기획 중이다. 50명 남짓한 팀과 광고주 사이에서 매일 수많은 리포트가 오간다. 매체는 왜 이리 다양하고 또 리포트의 형태는 각양각색인지... 퍼포먼스 마케터의 고단함을 간접적으로나마 경험하는 중이다.
매 시간 단위의 광고 성과, 방문자의 이벤트 로그 등은 원시 데이터로 추출된다. 원시 데이터에는 거의 대부분의 정보가 담겨있다. 잘 보관하고 있다가 필요한 부분만 꺼내어 사용하면 되는데, 문제는 이 데이터의 양이 하루에도 백만 개 가까이 생성된다는 것이다. 제대로 관리하고 있지 않으면 천만, 1억은 우습다. 이른바 빅데이터가 되는 것이다.
빅데이터는 한 때 AI, 블록체인과 함께 마법의 단어였다. 전 세계 수십억 인구가 매일 같이 써 내려가는 글, 우리의 행동 하나하나가 데이터로 쌓이기 시작했다. 나의 위치가 실시간으로 구글의 서버에 저장된다. 인류는 무한히 증식하는 이 데이터들을 빅데이터라고 칭했다. 그리고 재빠른 기업가들은 빅데이터에서 돈을 보았다. 거대한 데이터가 돈이 된다는 말에 투자자들의 주머니가 열렸다.
일기예보처럼 자주 틀리긴 해도 빅데이터를 통해 미래를 예측할 수 있다. 그러나 빅데이터의 진정한 면모는 종종 틀리는 미래예측이 아니라 철저한 현황 분석에 있다. 결과를 분석해서 원인을 파악하고, 정보를 수집해서 현황을 이해하는 데에 결정적인 역할을 하고 있다.
퍼포먼스 마케터들도 실시간으로 수집되는 광고 성과와 트랙킹 데이터를 바탕으로 광고를 운영한다. 데이터는 좋은 소재를 정해주지 않지만 적어도 광고의 개선 여부를 판단할 수 있는 쓸만한 근거가 되어준다. 그러나 앞서 말했듯 너무 많다. 이제는 사공이 아니라 데이터가 많으면 산으로 간다는 신조어가 생길 판이다.
마케터에게 필요한 것은 소재와 키워드 단위의 성과다. 소재와 키워드는 광고의 가장 작은 단위라고 볼 수 있는데 이들의 노출, 클릭, 전환 값을 이용해 광고의 효율을 판단하는 식이다. 여기에 GA 혹은 앱스 플라이어 등의 어트리뷰션 분석도구와 UTM을 활용하면 광고를 클릭한 사용자의 행동에 대해 조금이나마 더 자세히 알 수 있게 된다. (개인정보 보호가 강화됨에 따라 과거에 비해 더 자세히 알기는 어려워졌다.) 모든 매체들은 사전에 정의된 보고서나 마케터들이 직접 조합한 맞춤 보고서를 엑셀이나 csv파일 형태로 내려준다. 이 안에는 소재와 키워드 단위의 원시 데이터가 들어있다.
가장 작은 단위의 데이터임에도 불구하고 안에는 꽤 많은 항목들이 따라붙는다. 이런저런 항목들을 포함해 대충 20개 이상의 항목이 달라붙어있다. 각 매체에서 내려받은 데이터의 각기 다른 항목들을 정돈하고 합치는 것이 마케팅 데이터 통합의 시작이다. 그리고 이 데이터들을 제대로 합치고 관리할수록 있도록 돕는 것이 데이터 거버넌스다.
서론이 지나치게 길었다. 정리하자면 수많은 데이터를, 특히 빅데이터를 다루는 일은 생각보다 쉽지 않은 일이기 때문에 데이터 거버넌스를 해야 한다는 것이다. 데이터 거버넌스는 데이터를 수집하는 방법, 데이터 간의 관계, 데이터 관리를 위한 규칙들과 이 모든 것에 대한 인적자원 배분 등 데이터 관리를 위한 모든 것을 망라한다.
데이터의 성질은 방향을 잘 못 잡은 치아 같다. 데이터 거버넌스는 치아 교정기다. 치아가 제자리를 찾고 잘 자랄 수 있도록 방향을 잡아주는 것인데, 교정기가 빠진 날부터 데이터는 다시 빗나간 방향으로 자라나기 시작한다. 그렇기에 데이터 거버넌스는 한 번에 끝나는 일이 아니며, 유지보수가 만만치 않은 일임에도, 데이터 관련 사업을 영위하려면 반드시 해야만 하는 일이다.
유지보수까지 책임질 수는 없지만 이 프로젝트를 위해서 데이터 거버넌스를 진행하고 있다. 서비스 기획과 유사한 부분도 많고, 데이터 구조설계 역량, 협업능력 향상에도 많은 도움이 되었기에 서비스 기획자가 데이터 거버넌스의 어떤 부분에 기여할 수 있는지 공유해보려고 한다.
1. 데이터 처리 프로세스 이해하기
수많은 데이터를 어떻게 관리해야 할까? 하루에 수백만 줄이 넘어가는 원시 데이터를 그대로 저장하고, 필요할 때 꺼내서 사용하는 게 가능한 일일까? 당장은 가능할지 모르겠지만 데이터가 쌓일수록 점점 더 처리속도가 느려질 것이다. 그렇기 때문에 원시 데이터를 데이터가 아니라 파일로 취급하여 관리할 보관소가 필요한데, 이 것이 '데이터 레이크(Data lake)'라는 개념이다.
펜타호의 CTO, 'James Dixon'에 의해 정의된 '데이터 레이크'는 말 그래도 전혀 가공되지 않은 원시 데이터로 채워진 호수다. 우리는 저장소에 가득 채워진 원시 데이터를 퍼다가 원하는 형태로 가공해서 사용하면 된다. 다만 말처럼 쉬운 건 아니지만 우리 팀에서는 AWS에서 제공하는 Athena를 활용헤 데이터 레이크를 설계하기로 했다.
사실 데이터 레이크에는 전혀 가공되어있지 않은 원시 데이터만이 저장되어야 한다. 하지만 우리는 저장소로부터 추출하는 단계에서 모든 원시 데이터를 후처리(Post Processing)할 만한 리소스가 부족하기에 저장소에 입고 전 데이터 전처리(Pre-Processing) 단계를 추가하였다. 거대한 데이터와의 첫 만남이 이렇게 정리되는 것이다.
이런 식으로 데이터 처리 프로세스를 설계하고 있다. 데이터 통제와 처리절차설계는 데이터 거버넌스에서 가장 기본적인 영역이며, 개발자의 역량이 가장 많이 요구되는 부분이다. 특히 아무리 프로세스를 잘 만들어도 성능은 DBA 역량이 매우 큰 영향을 받는다. 이는 완벽히 기술자 영역이기에 비개발자는 프로세스 수립 이후에는 더 이상 관여해서는 안된다.
2. 데이터 수집 규칙 정의
이전 직장에서는 축산 관련 서비스를 기획했었다. 이 회사는 겉으로는 수많은 데이터 수집하고 이를 통해 다양한 질병을 예측한다고 선전했으나 실상은 수 억 개의 원시 데이터에 파묻혀 원하는 데이터를 찾아낼 수도 가공할 수도 없는 상태였다. 나중에야 알게 되었지만 어떤 데이터를 어떤 형태로 수집할지 정의하지 않았기 때문이다.
12개의 속성을 가진 데이터와 18개의 속성을 가진 데이터를 한 행씩 수집했다고 치자. 이 데이터를 합쳐 18개로 만들지 30개로 만들지 아니면 별도의 규칙을 통해 13~15개 정도의 속성으로 통합할지를 정의하는 것이다. 성질이 다른 데이터를 합치기 위해 중복 값 제거, 결측 값 보정, 데이터 구조변경, 인덱싱 등이 활용된다.
프로젝트마다 다루는 데이터의 형태가 워낙 다양하기에 서비스 기획자는 실무를 먼저 정확히 이해하고, 팀의 목표에 맞는 규칙을 정의해야 한다.
3. 데이터 관리 규칙 정의
우리는 잘 까먹는다. 개발자들이라면 얼마 전에 정해둔 변수명을 까먹는 일이 비일비재할 것이고 개발자가 아니더라도 파일명 작성 규칙을 까먹고 엉뚱한 이름의 문서를 만든 경험이 적어도 한 두 번은 있을 것이다. 업무의 양이 많아지면 실수는 더 많아질 수밖에 없다.
데이터 관리 규칙은 매우 중요하다. 누군가 한 명이 데이터 값의 형태를 잘 못 정의했다면, 예를 들어 우리는 날짜를 2022/12/12와 같은 형태로 정의하기로 했는데 불명의 사용자가 2022.12.12와 같은 형태의 값을 사용했다면 인식이 불가한 경우가 생길 수 있다.
당연히 규칙은 매우 중요하기에 가이드 문서를 만들어 모든 팀원이 숙지할 수 있도록해야한다. 그러나 수많은 규칙을 모든 팀원이 지킬 수 있으리라고 이해하지 않는다. 바로 위의 경우야 단순한 예지만, 실제로는 훨씬 복잡한 규칙이 많다.
그래서 개발단에서 날짜의 형태는 자동으로 2022/12/12로 치환되게 만드는 등의 이중 장치가 필요하다. 다른 규칙들도 사용자의 실수를 만회할 수 있는 형태로 기획되어야 한다. 서비스 기획자는 규칙을 만드는 일 보단 규칙을 지킬 수 있도록 하는데 기여해야 한다.
사실 데이터 거버넌스의 핵심은 유지보수다. 지금이야 시작단계이기에 무엇이든 새롭게 정의하고 새롭게 시작할 수 있었지만, 앞으로 새로운 챌린지가 없을 리 만무하다. 분명히 문제는 발생할 것이고 이를 파악하기 위한 모니터링 및 문제 해결 프로세스 구축, 분야별 담당자 배치 등. 앞으로 해야 할 일은 참 많지만! 일단은 본업에 좀 더 집중. 해 넘어가기 전에 스토리보드까지 끝내 보기로 한다.
