이벤트 수집

제품을 만드는 쪽이 오래 손에 쥐고 있던 숫자는 둘뿐이었습니다. 몇 명이 가입했는지, 돈이 얼마나 들어왔는지. 그 둘 사이에서 벌어진 일은 통째로 비어 있었습니다. 가입한 사람이 들어와서 무엇을 먼저 눌렀는지, 어느 화면에서 손을 놓고 나갔는지, 지난주에 새로 낸 기능을 실제로 연 사람이 몇 명인지는 아무 데도 적혀 있지 않았습니다.

그래서 회의는 늘 같은 자리에서 멈췄습니다. "지난달에 낸 공유 기능, 사람들이 쓰고 있나요" 라는 물음에 돌아오는 답은 "체감상 좀 늘어난 것 같아요" 였습니다. 서버에 쌓인 기록을 뒤져 봐도 어느 주소로 요청이 몇 번 들어왔는지만 남아 있어서, 그중 어느 것이 공유 버튼을 누른 사람이고 어느 것이 그냥 화면을 다시 불러온 사람인지 갈라낼 수 없었습니다. 판단은 결국 회의실에서 목소리가 큰 쪽으로 기울었습니다.

이벤트 수집은 이 빈칸을 그 순간에 메워 두자는 방식입니다. 나중에 뒤져서 복원하는 대신, 사용자가 버튼을 누르는 바로 그때 "누가 언제 무엇을 했다" 를 한 줄로 적어 보냅니다. 기록을 만드는 시점을 분석하는 시점에서 행동하는 시점으로 앞당긴 것입니다.

한 줄에 담기는 것은 시각과 사람과 행동, 그리고 그 행동의 내용 몇 칸입니다. 서버 기록이 "어느 주소로 요청이 들어와 40밀리초 만에 처리됐다" 를 남긴다면, 이벤트 수집은 "오후 2시 13분에 이 사람이 폴더 하나를 링크로 공유했다" 를 남깁니다. 앞의 줄로는 제품을 고치지 못하고 뒤의 줄로는 고칩니다.

이 방식의 성격은 되돌릴 수 없다는 데서 나옵니다. 지난달에 공유 버튼을 누른 사람이 몇 명인지 알고 싶다면, 지난달에 이미 그 한 줄이 남고 있었어야 합니다. 오늘 심으면 오늘부터 쌓입니다. 3월에 낸 기능의 첫 달 반응을 4월에 궁금해하면 그 답은 영영 나오지 않습니다. 그래서 이 일은 분석팀이 나중에 챙기는 뒷일이 아니라 기능을 만들 때 함께 정해 두는 앞일이 되었고, 무엇을 남길지 미리 적어 두는 문서와 이름 짓는 규칙이 그 주위에 붙어 한 분야를 이뤘습니다.

이벤트 수집 아래 묶인 용어 열 개는 다섯 갈래로 나뉩니다. 갈래를 가르는 기준은 기록 한 줄이 만들어져 자리를 잡기까지의 순서입니다. 무엇을 한 줄로 남기는지(단위), 무엇을 남길지 미리 정해 두는지(설계), 그 줄을 어디서 보내는지(방식), 그 줄을 누구의 것으로 묶는지(식별), 그 과정에서 무엇이 빠지는지(위험)입니다.

단위는 기록의 생김새를 가르는 갈래이고 셋으로 나뉩니다.

1. 이벤트 — 행동 하나를 적은 기록 한 줄입니다. 3월 4일 오후 2시 13분에 사용자 A가 문서를 공유했다, 정도의 내용이 한 줄에 담깁니다. 이 줄이 쌓여야 세는 일도 나누는 일도 시작됩니다.
2. 이벤트 속성 — 그 한 줄에 딸려 붙는 부가 정보입니다. 공유했다는 사실만으로는 링크를 복사한 것인지 이메일로 초대한 것인지 알 수 없으니, 공유 방식과 문서 종류 같은 칸을 함께 붙여 둡니다. 속성이 없는 이벤트는 몇 번 일어났는지만 셀 수 있고 어떤 경우에 더 많이 일어나는지는 못 봅니다.
3. 유저 속성 — 행동이 아니라 사람에게 붙어 유지되는 값입니다. 요금제, 가입한 날짜, 회사 규모 같은 것들입니다. 이벤트 속성과 갈리는 지점은 시점입니다. 이벤트 속성은 그 순간에 일어난 일의 내용이라 나중에 바뀌지 않고, 유저 속성은 지금 상태라서 무료에서 유료로 옮기면 값이 덮어씌워집니다.

설계는 기록을 심기 전에 약속을 맞추는 갈래이고 둘로 나뉩니다.

4. 트래킹 플랜 — 어떤 행동을 어떤 이름과 어떤 속성으로 남길지 미리 적어 둔 문서입니다. 이 문서가 없으면 기능마다 담당 개발자가 그 자리에서 이름을 지어 심게 되고, 반년 뒤에는 어느 이름이 무엇을 세고 있는지 물어볼 사람이 회사에 없습니다.
5. 네이밍 컨벤션 — 이름을 짓는 방식 자체를 통일해 둔 규칙입니다. 같은 행동이 웹에서는 doc_shared, 앱에서는 shareDocument, 확장 프로그램에서는 Document Shared 로 심기면 공유 횟수가 세 조각으로 갈라져 어느 것도 전체를 보여 주지 못합니다. 규칙은 대개 소문자와 밑줄, 대상과 동작의 순서, 과거형 통일 같은 몇 줄로 끝납니다.

방식은 그 줄을 어디서 보내는지를 가르는 갈래이고 둘로 나뉩니다.

6. 클라이언트 수집 — 사용자의 브라우저나 앱에서 직접 보냅니다. 화면 안에서만 일어난 일, 이를테면 어느 버튼 위에 마우스를 올렸다가 누르지 않고 지나갔는지까지 잡을 수 있습니다. 대신 광고 차단 프로그램이나 끊긴 네트워크에 막혀 일부가 도착하지 않습니다.
7. 서버 수집 — 요청을 처리한 서버 쪽에서 기록해 보냅니다. 결제가 실제로 승인됐는지처럼 돈이 걸린 사실은 이쪽에 맡깁니다. 차단에 막히지 않고 값을 사용자가 고칠 수도 없기 때문입니다. 대신 서버까지 오지 않는 화면 안의 움직임은 잡지 못합니다. 그래서 실무에서는 둘 중 하나를 고르지 않고, 돈과 관련된 것은 서버에서 화면에서만 일어나는 것은 클라이언트에서 보내도록 나눠 씁니다.

식별은 흩어진 줄을 한 사람 것으로 묶는 갈래이고 둘로 나뉩니다.

8. 사용자 식별자 — 같은 사람이 남긴 줄을 이어 보려고 붙이는 고유한 값입니다. 로그인한 뒤에는 계정 번호를 쓰고, 로그인 전에는 기기에 임시로 심어 둔 값을 씁니다.
9. 아이덴티티 병합 — 그 두 값을 한 사람으로 잇는 처리입니다. 광고를 눌러 들어와 20분 둘러보고 가입한 사람은 앞의 20분과 가입 이후가 서로 다른 값으로 남습니다. 이어 주지 않으면 가입자 한 명이 낯선 방문자 하나와 새 회원 하나로 세어지고, 어느 광고가 이 가입을 만들었는지도 알 수 없습니다.

위험은 이 과정에서 새는 몫을 다루는 갈래입니다.

10. 수집 유실 — 차단이나 오류로 이벤트가 도착하지 못하는 문제입니다. 곤란한 점은 줄어든다는 사실 자체가 아니라 고르게 줄지 않는다는 데 있습니다. 차단 프로그램을 깔아 두는 쪽이 특정 사용자층에 몰려 있으면, 그 무리의 행동만 통째로 옅어진 그림을 보고 판단하게 됩니다.

다섯 갈래는 앞뒤로 물려 있습니다. 설계에서 이름을 맞추고, 방식에서 어디서 보낼지 나누고, 단위에서 무엇을 함께 담을지 정하고, 식별에서 사람으로 묶고, 위험에서 새는 몫을 감안해 읽습니다. 이 순서를 누가 챙기느냐는 회사마다 다릅니다. 데이터를 다루는 사람이 여럿이면 전담 담당자가 트래킹 플랜을 지키지만, 열댓 명 규모에서는 기능을 맡은 기획자가 자기 기능의 기록까지 함께 정하는 편이 보통입니다. 어느 쪽이든 심는 손은 개발자라서, 무엇을 남길지는 기능 개발이 시작되기 전에 합의가 끝나 있어야 합니다.

실무에서 자주 건너뛰는 자리는 앞의 설계입니다. 급한 기능부터 심어 놓고 이름은 나중에 정리하자고 미루면, 정리할 때쯤에는 이미 쌓인 기록이 옛 이름으로 남아 있어 새 이름으로 바꾸는 순간 과거와 현재를 이어 볼 수 없게 됩니다.

"그 버튼 이벤트 심겨 있나요? 지금 심으면 숫자는 다음 주부터예요."

기록이 없으면 과거를 되살릴 방법이 없고 오늘 심어도 오늘부터 쌓인다는 뜻입니다.

"이거 클라이언트에서 보내는 거라 실제보다 20퍼센트쯤 적게 잡혀 있어요."

차단이나 네트워크로 빠진 몫이 있으니 절대값을 그대로 믿지 말고 추세로 읽으라는 말입니다.

"웹이랑 앱이 이름이 달라서 두 개를 합쳐서 봐야 합니다."

같은 행동이 서로 다른 이벤트 이름으로 심겨 셈이 갈라져 있다는 뜻입니다.

페이지덱에서는 새 기능의 기획 문서를 쓸 때 마지막 장에 무엇을 남길지 적는 칸이 있습니다. 문서 템플릿 기능을 준비하던 주에 지현이 그 칸에 두 줄을 적었습니다. 템플릿 목록을 열었다, 템플릿을 골라 문서를 만들었다. 태오가 되물은 것은 둘을 왜 따로 남기냐는 점이었고, 지현은 목록만 열어 보고 그냥 나가는 사람의 비율을 알아야 목록에 무엇을 더 놓을지 정할 수 있다고 답했습니다. 어떤 템플릿을 골랐는지는 속성으로 붙이기로 하고, 이름은 사내 규칙대로 소문자와 밑줄로 맞췄습니다.

3주 뒤 숫자를 볼 때 문제가 한 번 났습니다. 웹에서 만든 문서는 잡혔는데 앱에서 만든 문서가 통째로 빠져 있었습니다. 앱 쪽 담당자가 같은 행동을 다른 이름으로 심었기 때문이었습니다. 빠진 3주치는 되살리지 못해서, 그달의 앱 사용 비율은 끝내 빈칸으로 남았습니다. 그 뒤로 기획 문서의 그 칸은 개발이 시작되기 전에 양쪽 담당자가 함께 확인하는 항목이 되었습니다.

필요해지면 그때 뽑으면 된다고 여기는 경우가 가장 많습니다. 서비스가 돌아가는 동안 서버에 로그가 계속 쌓이는 것을 알고 있으니, 데이터는 이미 어딘가에 다 들어 있고 꺼내는 일만 남았다고 생각하기 쉽습니다. 실제로 그 로그는 어떤 요청이 들어와 몇 밀리초 만에 처리됐는지를 적어 둔 기술 기록이라, 그 줄에서 어느 사람이 무엇을 하려던 참이었는지를 되살리기는 어렵습니다. 게다가 대부분의 회사는 용량 때문에 이 로그를 한 달이나 석 달만 보관합니다. 그대로 두면 분기 회고에서 지난 분기와 견주자는 말이 나올 때마다 비교할 앞쪽 숫자가 없어서, 매번 오늘부터 다시 쌓기로 하고 회의가 끝납니다.

많이 심어 둘수록 안전하다고 여기는 것도 자주 어긋납니다. 나중에 아쉬운 것보다는 낫다는 판단이라 말리기 어렵습니다. 하지만 이름만 있고 아무도 열어 보지 않는 이벤트가 300개 쌓이면, 새로 들어온 사람이 공유 횟수를 세려 할 때 비슷한 이름 다섯 개 중 어느 것이 지금도 제대로 들어오는 것인지 알아낼 방법이 없습니다. 그러면 같은 질문에 두 사람이 서로 다른 이벤트를 골라 서로 다른 답을 들고 회의에 들어옵니다. 숫자가 둘로 갈리는 순간 회의는 결정하는 자리가 아니라 어느 숫자가 맞는지 따지는 자리가 됩니다. 처음부터 적게 심고 필요할 때 늘리는 쪽이 대개 더 오래갑니다. 기준을 하나 두면 고르기 쉬워집니다. 이 기록을 보고 나서 바뀔 결정이 무엇인지 한 문장으로 적을 수 없다면 그 이벤트는 아직 심을 때가 아닙니다. 심어 두면 언젠가 쓰겠지 하는 마음으로 늘린 목록이 나중에 가장 먼저 걷어 내야 할 짐이 됩니다.