서비스 데이터와 로그는 어떻게 분석할까? PM,마케터를 위한 트래킹 기초
서비스를 운영하다 보면 “데이터 좀 뽑아 주세요”, “이번 달 전환율이 어떻게 되나요” 같은 말이 자주 오갑니다. PM이나 마케터라면 매일 마주하는 표현입니다. 그런데 그 데이터가 어디서 나오고, 로그나 지표와는 어떻게 다른지는 의외로 흐릿하게 넘어가기 쉽습니다.
이번 글에서는 서비스가 남기는 데이터와 로그가 어떻게 쌓이고, 그것이 어떻게 지표와 분석으로 이어지는지를 코드 없이 풀어 보겠습니다.
로그는 서비스가 남기는 일기입니다 #
서비스는 동작하는 동안 끊임없이 기록을 남깁니다. 누가 언제 접속했는지, 어떤 요청이 들어왔는지, 어디서 오류가 났는지를 시간 순서대로 적어 둡니다. 이것이 로그입니다. 서비스가 스스로 써 내려가는 일기에 가깝습니다.
로그는 문제가 생겼을 때 가장 먼저 들여다보는 기록입니다. 장애가 났을 때 몇 시 몇 분에 어떤 오류가 났는지를 로그에서 되짚어 원인을 찾습니다. 평소에는 눈에 띄지 않지만, 무슨 일이 실제로 일어났는지를 담은 가장 날것의 데이터입니다.
이벤트는 사용자가 무엇을 했는지 기록합니다 #
로그가 시스템이 자동으로 남기는 기록이라면, 사용자의 행동을 일부러 골라 기록한 것이 이벤트입니다. 버튼을 눌렀다, 가입을 마쳤다, 상품을 장바구니에 담았다 같은 행동 하나하나를 데이터로 남기는 것입니다.
이런 기록은 저절로 쌓이지 않습니다. 이 버튼을 누르면 기록을 남기라고 미리 심어 두어야 모입니다. 흔히 쓰는 구글 애널리틱스 같은 도구가 이 일을 돕습니다. 그래서 마케터가 이 버튼에 이벤트를 심어 달라고 요청하면, 그 행동을 앞으로 셀 수 있게 준비해 달라는 뜻입니다. 심어 두지 않은 행동은 나중에 거슬러 셀 수 없다는 점이 중요합니다.
지표는 데이터를 요약한 숫자입니다 #
로그와 이벤트가 낱낱의 기록이라면, 그것을 모아 한 숫자로 줄인 것이 지표입니다. 하루 동안 가입한 사람 수, 방문자 중 실제로 구매한 비율인 전환율, 한 달에 한 번이라도 들른 사용자 수처럼, 흩어진 기록을 합쳐 의미 있는 숫자로 만든 것입니다.
지표가 필요한 이유는 분명합니다. 수백만 줄의 기록을 그대로 들여다볼 수는 없기 때문입니다. 키와 몸무게로 건강을 가늠하듯, 몇 개의 지표로 서비스의 상태를 빠르게 읽는 것입니다. 전환율, 재방문율 같은 지표가 마케팅과 기획에서 매일 입에 오르는 이유입니다.
분석은 질문에서 시작합니다 #
지표를 많이 쌓는다고 곧 분석이 되는 것은 아닙니다. 분석은 대개 질문에서 출발합니다. 가입까지 갔다가 왜 중간에 떠나는가 같은 물음이 먼저 있고, 그 답을 찾기 위해 데이터를 들여다보는 것입니다.
예를 들어 가입 과정을 단계별로 나눠, 어느 단계에서 사람들이 가장 많이 빠져나가는지 살펴봅니다. 흔히 깔때기에 빗대 퍼널이라고 부릅니다. 이렇게 찾은 단계를 고치고 다시 지표를 보며 나아졌는지 확인하는 흐름이 분석입니다. 대시보드는 이런 지표들을 한눈에 보도록 모아 둔 화면입니다.
숫자를 믿기 전에 한 번 의심합니다 #
데이터는 강력하지만 늘 옳지는 않습니다. 이벤트를 잘못 심으면 엉뚱한 숫자가 쌓이고, 그 위에서 내린 판단도 함께 어긋납니다. 그래서 숫자가 이상할 때는 결론을 바꾸기 전에, 이 데이터가 제대로 모인 게 맞는지부터 확인하는 편이 안전합니다.
보기에는 그럴듯하지만 실제 성과와 이어지지 않는 숫자도 있습니다. 가령 전체 방문자 수가 크게 늘어도 구매로 이어지지 않으면 큰 의미가 없습니다. 이런 숫자를 흔히 허영 지표라고 부릅니다. 어떤 숫자가 정말 중요한지를 먼저 정해 두는 것이 분석의 출발입니다.
왜 비개발자가 알면 일이 편해지는가 #
- 요청을 정확히 합니다. 데이터를 뽑아 달라는 막연한 부탁 대신, 어떤 이벤트가 심겨 있어야 그 숫자를 낼 수 있는지 알고 요청하면 개발자와 대화가 빨라집니다.
- 지표를 제대로 읽습니다. 전환율이나 재방문율이 무엇을 합친 숫자인지 알면, 숫자 하나에 휘둘리지 않고 맥락을 함께 봅니다.
- 미리 준비합니다. 지금 심어 두지 않은 행동은 나중에 셀 수 없다는 점을 알면, 기능을 만들 때 측정도 함께 챙길 수 있습니다.
마무리 #
오늘은 서비스가 남기는 로그와 이벤트가 어떻게 지표로 요약되고, 질문에서 시작하는 분석으로 이어지는지를 살펴봤습니다. 로그는 시스템이 남기는 일기, 이벤트는 골라 기록한 사용자 행동, 지표는 그것을 요약한 숫자라는 구분이 큰 그림입니다.
로그가 장애 대응에서 어떻게 쓰이는지 궁금하다면 버그, 핫픽스, 롤백을, 지표로 가설을 검증하며 작게 출시하는 방식이 궁금하다면 애자일,스프린트,MVP를 함께 읽어 보시길 권합니다.