유저를 이해하는 단서, 이벤트 로그
이벤트 로그에 대한 기억
이벤트 로그(Event Log)란 앱에서의 유저의 행동 기록을 의미한다. 앱에서는 클릭, 화면 노출, 스크롤, 이탈 등 다양한 유저의 행동을 기록한다.
이벤트 로그를 접하게 된 계기
뱅크샐러드에서 처음 맡았던 일이 이벤트 로그 관련 작업이었다. 이벤트 로그를 쉽게 남길 수 있는 라이브러리를 만들어야 했다. 웹뷰에서 로그 함수를 호출하면 네이티브에 값이 전달되고 이를 다시 각 분석 서비스에 적재하는 흐름이었다. 라이브러리를 사용하는 입장에선 OS에 상관없이 동일한 함수 하나로 네이티브에 값을 전달할 수 있도록 만드는 단순한 라이브러리였다. 이 단순한 라이브러리를 만들면서 이벤트 로그의 중요성과 어려움을 이해할 수 있었다.
이벤트 로그가 필요한 이유
당시에는 그로스 해킹을 전담하는 팀이 있었다. 매일 같이 데이터를 보고 유저가 우리 앱에서 하는 행동을 분석해 서비스를 개선하는 일을 하는 팀이었다. 여기서 매일 같이 보는 데이터가 이벤트 로그로 쌓인 데이터였다. 나 역시 이 팀에서 일했고 그 일을 계기로 이벤트 로그가 실제 제품 개선에 어떤 영향을 주는지 직접 느낄 수 있었다. 해적 지표(AARRR)를 이해하기 시작한 것도 이때였다. 퍼널의 개념을 이해할 수 있었고 지표를 개선하기 위해 다양한 실험을 경험했다.
실수를 통해 배운 것
결국 정확한 지표 측정을 위해 이벤트 로그가 필요했는데 개발자가 실수해서 지표가 잘못 측정되는 경우도 있었다. 때문에 이벤트 로그만을 집중적으로 QA 하는 프로세스도 생겼다. 때론 운영체제마다 다르게 집계되는 경우도 있었다. 또 잘 집계되던 게 어느 날 갑자기 집계가 되지 않는 날도 있었다. 머리를 끙끙 싸매고 원인을 찾다 보면 정말 어이없는 이유로 로그가 누락되는 경우가 대부분이었다. 덕분에 나중에 비슷한 일이 생기면 대수롭지 않게 원인을 찾아내는 능력도 생겼다.
어이없는 실수를 반복하지 않기 위해 이벤트 로그 관련된 코드는 최대한 비즈니스 로직과 엉키지 않도록 작업하려고 애쓰게 됐다. 정밀한 분석에서는 데이터를 취하기 위해 어쩔 수 없이 엉키는 경우가 생기는데 주석을 명시하는 등으로 실수를 줄이기 위해 최대한 노력하고 있다.
이름 짓기의 어려움
개발자로서 힘든 지점 중 하나는 이벤트 로그에서 사용하는 이름이 실제 코드의 이름과 같지 않은 경우가 생길 때다. 이벤트 로그를 설계하는 사람은 보통 PM이나 데이터 분석가인데 개발자가 쓰는 용어와 다른 용어를 쓰는 경우가 있다. 예를 들자면 코드 상에선 단순한 버튼인데 UI 상으로 스위치라서 같은 버튼을 클릭하는 이벤트를 개발자는 clickButton이라 정의하고 이벤트 로그 상으로는 click switch로 정의하게 될 수도 있다. 이런 경우에는 디자이너와 컴포넌트의 이름을 사전에 정의해두고 이를 기반으로 로그를 작성할 수 있도록 이벤트 로그 설계 담당자에게 제시하면 좋다.
만일 용어의 차이가 도메인에 따라 달라지는 경우라면 어떨까. 예를 들자면 제1금융권, 제2금융권 은행을 부르는 명칭을 'First bank', 'Second bank'라고 부르고 어디선 'Prime bank', 'Subprime bank'이라고 부른다면 굉장히 혼란스러워진다. 이런 경우에 모두가 참고할 수 있는 용어집(Glossary)을 하나 만들어두면 편하다. 그 용어집을 기준으로 함수명, 컴포넌트명 나아가 이벤트 로그까지 정의하면 이해하기 쉬운 코드를 작성할 수 있다.
이벤트 로그가 중요한 이유
이벤트 로그가 놓쳐지는 경우에는 사실 제대로 된 분석이 어렵다. 이 말은 유저를 이해하기 어려워진다는 의미다. 우리 서비스를 어떻게 사용하고 있는지 알 수가 없으니 유저의 마음을 알 수가 있나. 유저를 제대로 이해하지 못한 서비스는 사랑받기 어렵다. 결국 이벤트 로그를 놓치면 사랑받기 어려워진다. 그러니 꼼꼼하게 챙겨보자.
