데이터 이벤트 로그 설계 과정
스타트업 내 1인 데이터 분석가의 고군분투 이야기
오늘은 전직장의 1인 데이터 분석가(a.k.a One & only 데이터 분석가)로 근무할 때 가장 많은 시간을 쏟았고, 지금까지도 제일 잘했던, 뿌듯함이 제일 큰 프로젝트라고 생각하는 '데이터 이벤트 로그 설계 과정'에 대해서 이야기해보려고 합니다.
현재 회사 내에서
1. 데이터 이벤트 로그 컨벤션이 정해져 있지 않다거나,
2. 데이터 이벤트 로그가 제대로 설계되어 있지 않다거나, 혹은
3. 데이터 분석 툴인 Amplitude를 사용하는데 여기에 알맞은 Data Taxonomy를 어떻게 짜야하는지 고민
하고 있는 분들에게는 조금이나마 도움 되는 글이 되었으면 좋겠습니다.
전 직장은 제가 입사하기 전부터 데이터의 중요성에 대해서 인지하고 있던 분들이 많았기 때문에 데이터 분석 툴인 'Amplitude'를 사용하고 있었습니다. 그리고 모든 pageview, click등 유저가 웹 내에서 행동할 수 있는 모든 이벤트에 대해서 데이터를 로깅하고 있었습니다.
하지만, 제가 입사하기 전에는 데이터분석가가 없었기 때문에 이벤트 로그 이름의 경우에는 각 프로덕트를 담당하는 Product Designer분들이 이벤트 로그 네이밍을 설계했는데요. 슬프게도 정해져 있는 이벤트 로그 네이밍 컨벤션이 없어서 각 프로덕트를 담당하고 계신 PD분들 마다 다르게 이벤트 로그를 작성하고 있었습니다.
이렇게 모든 데이터를 로깅하고 데이터 이벤트의 네이밍 기준이 정해져 있지 않은 경우에는 워낙 많은 데이터가 로깅되고 있기 때문에
1. 본인이 보고자 하는 데이터가 어떤 이름을 가지고 있는지 모르기 때문에 찾는 과정도 번거롭기도 하고,
2. 데이터 이름이 바뀐 히스토리가 제대로 문서화가 안되어있다면 그 히스토리를 찾아다니느라 정작 보고자 하는 데이터를 빠르게 보지 못하기도 하고,
3. 만약 Cross-product적으로 서비스를 분석하고자 할 때, 이름이 동일하게 맞춰져있지 않기 때문에 이를 찾아다니는 데에도 또 많은 시간을 써야 한다는 단점이 있었죠.
그래서 데이터를 보고자 하는 팀원분 들이 항상 저를 찾아와서 '이 데이터 이름이 뭐예요?' '이 데이터는 어디에 있나요?' 등등을 많이 물어보셨던 것 같습니다.
(모든 데이터 이벤트를 로깅한다 vs 필요한 것만 로깅한다. 에 대해서도 의견이 분분하지만 저는 '혹시나'를 입에 달고 사는 걱정 인형이기 때문에 전자 의견에 좀 더 동의하는 편입니다.)
그리고 Amplitude를 쓰는 곳이라면 아실 테지만, 로깅되는 데이터 이벤트의 이름이 일정 개수가 넘어가게 되면 툴 사용 요금이 더 올라가기 때문에 저는 이걸 방지하기 위해서 한 달에 한번 정도는 Amplitude를 내에서
1. 잘못 들어간 데이터 지우기(오타 등으로 인해서 찍혔던 데이터 이벤트),
2. 프로덕트 개선으로 인해서 더 이상 사용되지 않는 데이터 지우기(삭제된 버튼 등) 등을 진행하며
Amplitude 내 이벤트 볼륨을 줄이고자 주기적으로 항상 신경을 썼습니다.
이렇게 계속 확인을 하면서 이벤트 정리를 해왔지만 이 방법은 얼레벌레 임시방편 방법이라는 생각이 드는 건 어쩔 수 없었습니다.
그냥.. 이런 느낌... 있잖아요... 그리고 제 예감은 틀리지 않았습니다. 전략상 완전하게 새로운 프로덕트를 만들어야 해서 해당 프로덕트의 배포일에 맞게 데이터 이벤트를 설계하는데 이걸 다 넣는 경우에는 Amplitude 데이터 이벤트 개수의 제한을 넘기도 하고 새로운 프로덕트다 보니 또다시 나타날 데이터 이벤트 이름의 파편화가 두려워졌습니다.
그래서!!! 이 모든 문제를 해결해보자 싶어 해당 프로덕트를 배포하기 전 관련 팀원분들을 설득시켜 데이터 이벤트 갈아엎기 프로젝트를 한번 진행해 봤습니다.
프로젝트를 진행하기 전 이 프로젝트의 필요성이 무엇인지, 어떤 게 과연 문제였는지 문제 정의를 시작했습니다. 정리해 보니 두 개의 큰 문제로 정의가 되었습니다.
1. 사내에 데이터 이벤트와 관련된 정책이 없다.
사내에 데이터 이벤트 네이밍과 관련된 정책이 없다. (그냥 없어요).
그래서 같은 버튼이더라도 각각의 프로덕트 내에서 다른 이름으로 부르는 경우가 있다.
snake case, camel case 등 어떤 부분은 snake_case로, 어떤 부분은 camelCase로 들어가 있어서 이 두 개의 차이가 뭔지 모르겠다.
데이터와 관련된 파라미터(혹은 정보)가 많은 경우에는 이게 이벤트 이름으로 다 들어가 네이밍 자체가 너무 길어진다.
버튼의 이름이 들어가 있는 경우, 이게 어느 페이지, 어느 부분에 있는 버튼인지 정확하게 명시되어야 하는데 정확하게 명시되어있지 않은 경우가 있다. 그래서 제대로 확인하기 위해서는 직접 눌러보고 로그 테스트를 해봐야 한다.
이렇게 여러가지의 상황이 있기 때문에 데이터 이벤트를 로깅하는 개발자 분들이 어려워한다.
2. 사내에 어떤 데이터 이벤트가 기록되고 있는지 정리되는 문서가 없다.
데이터 이벤트의 기록이 시작된 날이나 혹은 데이터 이벤트가 삭제된 날에 대해서 정리된 문서가 없어서 Amplitude로 해당 이벤트를 찾아봤을 때 없으면 '왜 없지!?!??!?!'부터 나온다
데이터 이름이 바뀐 경우 히스토리가 작성된 곳이 없어 이 전 데이터가 있음에도 불구하고 트래킹 하지 못한다.
PM, PD분 들 외 데이터를 보고자하는 팀원들이 데이터 이벤트를 찾기 어려워한다.
이왕 시작한 프로젝트니 문제라고 생각했던걸 다 해결해 보자! 싶어 시간은 좀 더 걸릴 순 있겠지만 차근차근 진행해보고자 했고, 이 프로젝트를 끝냈을 때는
1. 누구나 알아보기 쉬운 데이터 이벤트 네이밍 설계하기.
2. 누구나, 언제든, 원할 때 찾아볼 수 있는 데이터 이벤트 리스트 문서화하기.
가 남았으면 좋겠다.라는 큰 목표를 가지고 프로젝트를 진행했습니다.
제일 처음 진행했던 일은 현재 사용되고 있는 데이터 이벤트 다 한 곳에 모으기였습니다. Amplitude에 찍힌 이벤트 로그를 한 곳에 리스트업 하고 오랜 기간 동안 사용되지 않은 이벤트들의 경우
1. 현재 없는 데이터 이벤트이기 때문에 사용이 되지 않는 건지
2. 오타이기 때문에 사용되지 않은 건지 확인을 해본 후, 분류해 보았습니다.
분류를 진행하고 나니 현재 Amplitude 내에 기록된 데이터 중 약 30%의 데이터이벤트가 사용되고 있지 않은 걸 알 수 있었습니다. 그중에서도 약 80%의 이벤트는 프로덕트 개선이 진행되어서 삭제된 버튼, 혹은 페이지인 경우가 대다수였습니다.
정리를 한번 진행하고 나니 누구나 알아보기 쉬운 데이터 이벤트 네이밍을 설계할 때 어떤 식으로 설계해야 할지도 머릿속에 정리가 되기 시작했습니다. 누구나 알아보기 쉬운 데이터 이벤트 네이밍뿐만 아니라, 재사용성이 가능할 수 있도록 데이터 이벤트 네이밍이 설계가 되어야겠다는 생각을 했죠.
데이터 이벤트 네이밍 컨벤션 설계를 위해 제일 먼저 했던 일은 현재 프로덕트를 지칭하는 서비스 이름, 서비스 내 area 이름, 서비스 내 버튼의 이름 통일하기. 였습니다. 이 이름을 전사적으로, 의심 없이, 누구나 동의할 수 있도록 통일하기 위해서 어떻게 해야 하지?라고 고민을 꽤나 오래 진행했습니다. 그런데 생각해 보니 이전에 디자이너분 들이 디자인 시스템을 구축할 때 네이밍의 부분도 함께 진행했던걸 기억했고, 이 디자인 시스템의 네이밍을 통해 프론트엔드 분들과 소통을 어렵지 않게 했던걸 보았기 때문에 디자인적인 요소가 들어가는 부분은 '디자인 시스템 네이밍'을 활용해 보기로 했습니다. 이를 위해 현재 사용하고 있는 버튼과 이름을 리스트업 해보고, 디자인 시스템에서 사용하는 네이밍 중 데이터 이벤트 네이밍으로 사용될 수 있는 부분이 있는지 1차적으로 디자이너 분들과 협업을 진행하며 데이터 이벤트 네이밍을 추려보았습니다.
서비스 이름, 버튼 이름 등 전사적으로 누구나 이해할 수 있는 네이밍에 대해서는 어느정도 통일은 진행이 된 후,
1. 데이터를 보고자 하는 사람들이 누구나 쉽게 데이터를 찾을 수 있는,
2. 삭제되는 데이터 이벤트가 있어도 우리가 딱히 지우지 않아도 되는 데이터 이벤트 이름
이 어떤 이름일지에 대해 고민을 진행했습니다.
이 두 부분을 고려하며 저 혼자 이리저리 데이터 이벤트 네이밍의 후보군을 몇 개 만들어 보았습니다. 유저의 행동이 - 어느 서비스 페이지에서 - 어느 부분에 있는 - 어떤 버튼을 통해서 (혹은 어떤 부분을 통해서) 일어난 행동인지 최대한 잘 보여줘야 한다.라는 것에 가장 많은 중점을 두며 네이밍을 진행하고자 했습니다.
이전에 정리해 두었던 후보군을 각색하여 만든 예시입니다.이렇게 몇 가지의 후보군을 가지고 가서 이 데이터 이벤트 설계 프로젝트에 대한 컨텍스트가 없는, 그리고 한 번도 이 프로젝트를 같이 해보지 않았던 다른 사업팀분들, PM분들, 개발자 팀원분들에게 "이 데이터 이벤트 이름은 무슨 버튼을 의미하는 것 같아요?" 등의 질문을 진행했습니다.
그리고 그중에서 가장 많은 사람들이 한 번에 맞춘 혹은 이 버전이 정말 쉽네요!라고 했던 버전으로 이벤트 네이밍을 설계하기 시작했습니다. 또한, Amplitude가 제공하는 장점 중 하나인 Event Property의 사용성을 생각해보면서 property가 들어가는 기준과 데이터이벤트의 재사용성에 대해서도 고려하며 이벤트 네이밍 설계를 진행했습니다. (그때 도와주신 모든 팀원들에게 다시 한번 더 감사인사 드려요.)
데이터를 보고자 하는 분들의 여러 의견을 수집하는 과정을 거치면서 '누구나' '알아보기 쉽게'의 부분은 거의 다 진행되었다고 생각했습니다. (반은 왔다.) 하지만 정작 '데이터 이벤트를 직접 로깅'하는 팀원들의 효율성을 챙기지 못했다는 걸 네이밍 설계 중간에 알아챘습니다.
사실 데이터 이벤트 설계를 진행해도, 프론트엔드 개발자 팀원분들이 하기 힘든 형태이거나,혹은 효율적이지 않은 형태인 경우에는 데이터 이벤트 로깅에 대해서 어려워하실 수 있고 한두개씩 놓칠 수 있는 가능성이 있기 때문에 프론트엔드 개발자 분들과도 이야기를 해봐야 했었습니다.
프론트엔드 개발을 담당하는 팀원 분 중에서 데이터에 가장 관심 있기도 했고, 로깅을 가장 많이 진행해보았던 팀원과 함께 데이터 이벤트 네이밍을 다시 한번 확인하며 피드백을 받아보았습니다.
받았던 피드백 중에서 가장 기억에 남는 피드백으로는
1. 이대로 데이터이벤트 네이밍을 진행하게 된다면 개발에는 큰 어려움은 없고 이전보다 효율성도 올라가긴 하지만 더 개선해 볼 수 있을 것 같다.
2. '_' 가 버튼을 나타낼 때도 있고, area, service를 나눌 때도 사용되고 있어서 이 부분이 너무 헷갈릴 것 같다. 그러니 snake_case가 아닌 camelCase도 활용하여 구분이 쉽도록 하는건 어떤가?
3. 재사용성 부분을 충분히 고려하지 못한 것 같다. Event Property가 붙여질 수 있는 경우에는 이를 좀 더 활용하여 데이터 이벤트 네이밍을 짜보는 게 좋을 듯 하다. 그렇다면 개발할 때도 좀 더 효율적으로 개발이 가능할 것 같다.
등 의 피드백이 있었습니다.
이러한 피드백을 고려하여 다시 한번 더 이벤트 네이밍 컨벤션을 정리하기 시작했습니다.
정리된 이벤트 네이밍을 각색하여 만든 예시입니다.이런 식으로 다른 서비스로 전환되는 이벤트여도 서비스 내 동일한 곳에서 일어나는 유저의 행동 일 경우에는 이벤트 이름을 최대한 똑같이 가져가고 Event Property를 통해서 구분하는 방식을 사용하면서 데이터 이벤트 네이밍의 기준을 잡아갔습니다. 또한, 개발자분의 피드백을 반영하여 버튼, 혹은 위치를 구분할 때는 '_' 를, 버튼의 이름을 구분할 때는 camel case를 사용하면서 구분이 좀 더 용이하도록 컨벤션을 만들어보았습니다.
이런 식으로 데이터 이벤트 네이밍을 설계하고 나서 이전에 존재했던 데이터 이벤트 이름을, 새로운 데이터 이벤트 네이밍을 기준으로 다시 바꾼 후 구글 스프레드 시트에 리스트업을 진행했고,
스프린트 배포날짜/가설 번호/이벤트 요청 사항/행동/요청이벤트 명/Event Property/값/QA/HISTORY 등
의 칼럼을 만들어 문서 관리가 용이하도록 하였습니다.
또한, 저 이외에도 PM, PD, 혹은 개발자 분들이 데이터 이벤트를 쉽게 설계할 수 있도록 데이터 이벤트 네이밍의 정책을 정리하여 누구나 확인할 수 있도록 데이터 이벤트 구글 스프레드 시트에 작성해두었습니다.
이 또한 각색한 내용입니다. 정책 정리 및 공유를 끝으로 프로젝트가 마무리가 되었습니다.
이 프로젝트는 약 3-4개월이 걸린 프로젝트로 생각보다 오래 걸렸던 프로젝트 중 하나였던 것 같습니다. 그래도 여러 팀원들과 다 같이 협업을 진행할 수 있었고, 이 프로젝트를 진행한 후
1. '이 부분의 데이터 이벤트 이름은 뭐예요?'라고 묻는 빈도 수가 상당히 많이 줄어들었고,
2. 프론트엔드 분들이 데이터 로깅 너무 오래 걸린다는 이야기를 하지 않았고(혹은 나중에 해도 되나요?라는 이야기를 하지 않으셨다는거..),
3. 데이터 QA를 진행할 때도 QA티켓 자체의 수가 많이 줄어들었고,
4. 더 이상 Amplitude 내 데이터 이벤트를 주기적으로 삭제하지 않아도 된다는 점이
가장 큰 성과가 아니었나 싶습니다.
그리고 이렇게 여러 후보군을 가지고 많은 사람들에게 물어보는 작업을 해봤기 때문에 어떤 네이밍이 '처음 데이터를 보고자하는 사람들에게'도 쉬운 네이밍인지 알 수 있었습니다. 이런 경험 덕분에 현재 재직하고 있는 회사에서도 '이벤트 네이밍 컨벤션'을 진행할 때, 섹션 구분에 있어서 snake case가 아닌 camelCase에 대해서 의견을 냈었고 제 의견이 반영되어 camelCase가 전사 데이터 이벤트 네이밍 컨벤션으로 사용되고 있기도 합니다.
데이터 이벤트 로그 및 네이밍을 설계하는 과정은 쉽지 않습니다. 하지만 데이터 분석가라면 한번쯤은 꼭 해보고 싶은, 혹은 해야하는 업무가 아닌가 싶습니다. (아닐수도 있습니다)
로그 설계에는 답은 없습니다. 다만 아무런 배경지식 없이 '오늘 이 데이터 이벤트 이름을 처음 본 사람도 해석이 가능한 이벤트 네이밍'을 설계한다면 '가장 최고의 답'은 아닐테지만 'Best Example'이 될 수 있을 가능성은 있지 않을까? 라는 생각을 한번 해봅니다.
