저희 팀에는 한동안 데이터를 전담해서 보는 사람이 없었습니다.
그렇다고 데이터를 아예 안 본 건 아닙니다. 백엔드 개발자분이 Grafana로 서비스 데이터를 시각화해서 공유해주고 있어서, DB에 쌓이는 데이터로 서비스가 실제 어떻게 돌아가는지는 볼 수 있었습니다.
다만 DB에 남는 건 결과입니다. 설문을 마쳤는지, 수업을 예약했는지처럼 무언가를 끝낸 기록은 남지만, 그 사람이 화면에서 무엇을 보고 무엇을 눌렀는지는 남지 않습니다. 그래서 가입하고 아무것도 하지 않은 사용자는 DB에서 그냥 빈칸입니다.
문제는 그 빈칸이었습니다. 어느 화면까지 갔다가 나갔는지, 버튼을 보긴 봤는지, 중간까지 하다가 그만둔 건지는 알 수 없었습니다. 과정을 보려면 이벤트를 따로 심는 수밖에 없었습니다.
이게 아쉽다고 느낀 건 사용자 피드백을 받으면서부터였습니다. 예를 들어 가입하고 나서 뭘 해야 할지 모르겠다는 이야기가 있었는데, 온보딩이 부족하다는 건 알겠어도 정확히 어디에서 막히는지는 알 수 없었습니다. "온보딩을 개선해야 할 것 같다"는 이야기는 할 수 있는데, 그래서 어느 화면부터 봐야 하는지는 애매했습니다. 결국 감으로 이야기하게 됐고요.
그때부터 사용자 행동 데이터를 GA 이벤트로 직접 붙여보기 시작했습니다. 화면에서 어떤 행동을 하는지는 결국 화면을 만드는 제가 제일 가까이에서 보고 있으니까, 이 정도는 제가 해봐도 되겠다는 생각이었습니다.
스크롤 뎁스 같은 행동 지표부터 시작하기
처음에는 정말 단순한 것부터 붙였습니다.
- 결제 페이지에서 어디까지 스크롤하는지
- CTA 버튼을 얼마나 누르는지
이벤트를 심는 것 자체는 어렵지 않았습니다. 그런데 막상 데이터를 보기 시작하니까 궁금한 게 계속 생겼습니다.
여기까지는 많이 내려오는데 왜 여기서부터 확 떨어지지?
스크롤을 20%까지 내린다고 하면, 그 안에 결제 가격 섹션이 충분히 보여지는지?
단순한 클릭 수만으로는 답이 안 나오는 경우도 많았습니다. 여러 이벤트를 이어서 퍼널로 봐야 하는 경우도 있었고, GA4의 행동 데이터와 DB에 있는 서비스 데이터를 같이 봐야 하는 경우도 있었습니다.
이때부터 AI를 같이 쓰기 시작했습니다. 원하는 데이터를 어떻게 봐야 할지 설명하고, 필요한 쿼리나 데이터를 뽑는 방법을 물어보면서 조금씩 범위를 넓혀갔습니다. 혼자 했다면 찾아보느라 오래 걸렸을 작업도 일단 시도해볼 수 있으니, 이것저것 많이 보게 됐습니다.
매주 월요일 주간 미팅에서 공유하기
그렇게 확인한 내용은 주간 미팅에서 공유하기 시작했습니다. 매주 꼭 무언가를 가져가는 건 아니고, 그 주에 볼 만한 게 있으면 가져갔습니다.
온보딩 개선이 필요하다고 생각하고, 가입하고 나서 어느 단계에서 빠지는지, 홈에 들어온 사용자는 뭘 누르는지 이벤트를 심어서 확인했습니다. 클로드 코드에 Grafana MCP를 연결하여 대시보드 만들어서 빠르게 공유했습니다.
예전에는 "온보딩이 없으니 필요하다" 정도로 이야기했다면, 데이터를 붙이고 나서는 "가입 직후 여기에서 많이 빠지고 있는데 이 부분을 한번 바꿔보면 어떨까요?"라고 이야기할 수 있게 됐습니다. 대시보드 형태로 시각화하니 기획 회의에서도 해당 데이터 지표를 토대로 팀원들이랑 기획도 정할 수 있게 되었습니다.
아무것도 안 한 사용자는 두 부류였습니다
DB만 보면 가입하고 아무것도 안 한 사용자는 전부 똑같아 보입니다. 설문도 안 했고 예약도 안 했으니 남은 기록이 없습니다. 그런데 행동 데이터를 붙여놓고 보니 그 안에 성격이 다른 두 부류가 있었습니다.
- 화면까지는 왔는데 아무것도 누르지 않은 사람
- 설문에 들어갔다가 중간에 나간 사람
둘 다 결과만 보면 미완료지만 원인도 처방도 다릅니다. 앞쪽은 화면에서 무엇을 먼저 해야 할지 안내가 없었던 쪽에 가깝습니다. 어디로 가라는 안내를 받은 적이 없으니 이탈이라고 부르기도 애매합니다. 뒤쪽은 시작은 했는데 중간에 막힌 거라 진짜 이탈이고, 화면 구성을 아무리 고쳐도 설문 자체를 손보지 않으면 움직이지 않습니다.
같은 칸에 나란히 놓인 숫자인데 뜻이 다르고, 그래서 개선 방향도 갈립니다.
SQL은 AI의 도움을 받았습니다
사실 저는 SQL을 잘하지 못합니다. 처음에는 이게 제일 큰 장벽이라고 생각했습니다. 그런데 AI의 도움을 받아 쿼리 자체는 만들 수 있었습니다.
"특정 기간에 이 이벤트를 발생시킨 사용자 수를 구해줘."
"이 조건을 만족하는 사용자만 찾아줘."
이런 식으로 원하는 결과를 설명하면 어느 정도는 만들어줍니다. 문제는 그다음이었습니다.
AI가 만들어준 숫자를 제가 믿어도 되는지는 별개의 문제였습니다.
쿼리가 어떤 데이터를 보고 있는지, 어떤 조건으로 사용자를 걸러내는지 정도는 제가 알아야 했습니다. 무엇보다 우리 서비스에서 그 데이터를 어떤 의미로 쓰고 있는지는 AI가 전부 알 수 없었습니다.
숫자의 기준에 대한 고민
예를 들어 결제 페이지 퍼널을 한번 봤습니다.
| 단계 | 사용자 수 |
|---|---|
| 구매 페이지 진입 | 300명 |
| 수강권 선택 | 180명 |
| 최종 구매 | 20명 |
처음 보면 그냥 숫자입니다. 300명 들어와서 180명이 수강권을 선택했고, 그중 20명이 구매했구나.
그런데 조금만 생각해보면 애매한 게 많았습니다.
300명은 정확히 누구지? 결제 일으킨 요인은? 상담/체험수업 여부는?
180명은 어떤 기준이지?
중복 이벤트는 빠진 건가?
페이지에 들어온 사람을 센 건가, 이벤트를 발생시킨 사람을 센 건가?
이런 걸 하나씩 확인하기 시작하면 "300명 중 180명"이라는 숫자만 보고 끝낼 수가 없었습니다.
특히 AI한테 데이터를 뽑아달라고 할 때 이걸 많이 느꼈습니다. 처음 질문할 때 제가 서비스 정책을 충분히 설명하지 않으면 AI는 제가 준 정보 안에서 알아서 기준을 만들어서 쿼리를 작성합니다. 그런데 결과를 보고 있으면 꼭 하나씩 걸리는 게 나왔습니다.
"아, 근데 우리 서비스에서는 이 경우는 제외해야 하는데."
그러면 조건을 하나 추가하고 다시 쿼리를 돌립니다. 숫자가 바뀝니다.
서비스 정책을 하나 더 설명하면 데이터를 가져오는 조건이 바뀌고, 조건이 바뀌면 대상 사용자가 달라집니다.
대상 사용자가 바뀌면 분모도 달라집니다.
"구매한 사용자를 찾아줘"와 "결제 완료 이벤트가 아니라 DB에서 실제 결제 상태가 PAID인 사용자만 포함하고 취소된 주문은 제외해줘"는 완전히 다른 질문이었습니다. 그때부터 숫자를 볼 때 숫자 자체보다 그 숫자를 어떻게 만들었는지를 먼저 보게 됐습니다.
질문이 달라지면 숫자가 달라진다
AI를 쓰면 데이터를 굉장히 빨리 볼 수 있습니다.
그런데 질문을 잘못하면 잘못된 데이터를 굉장히 빨리 볼 수도 있습니다.
AI가 일부러 잘못된 답을 주는 게 아니라, 제가 알려준 정보 안에서는 나름 맞는 답을 만들어주는 겁니다. 결국 제가 서비스 정책을 얼마나 잘 알고 있느냐가 중요했습니다. "이 사용자는 왜 제외해야 하는지", "이 상태는 실제 구매로 봐도 되는지", "이 이벤트는 중복될 수 있는지" 같은 건 AI가 알아서 알 수 있는 게 아니었습니다.
그래서 AI에게 질문하는 방식도 달라졌습니다. 처음에는
"이 데이터가 어떤 의미인지 알려줘."
였다면 나중에는
"나는 이러한 기준으로 정의했는데, 여기서 빠질 수 있는 경우가 있는지 봐줘."
에 가까워졌습니다. SQL을 잘 쓰는 것보다 데이터를 어떻게 정의할지를 먼저 생각하게 된 셈입니다.
이미 공유한 숫자가 바뀐다면?
혼자 데이터를 보고 있을 때는 숫자가 이상하면 다시 계산하면 됩니다. 그런데 이미 주간 미팅에서 공유한 숫자라면 이야기가 달라집니다.
제가 가져간 숫자를 보고 팀원들이 개선할 부분을 이야기하고, 제가 먼저 제안한 방향으로 작업이 들어갈 수도 있습니다. 그런데 나중에 알고 보니 계산할 때 빠진 조건이 있었습니다.
그러면 숫자가 바뀝니다.
그 숫자를 다시 보면 처음에 했던 이야기가 맞을 수도 있고, 아닐 수도 있습니다.
저는 이때부터 숫자를 가져가는 게 조금 조심스러워졌습니다. 제가 혼자 참고하려고 만든 숫자가 아니라 다른 사람이 그 숫자를 보고 판단하고 있으니까요. 특히 제가 숫자만 보여주는 게 아니라 "이 부분을 개선해보자"고 먼저 이야기하고 있었기 때문에 더 그랬습니다.
그래서 서비스 정책을 다시 찾아보고, 원본 데이터를 보고, 쿼리를 다시 돌려보고, GA4 숫자와 비교해보는 식으로 확인했습니다. 몇 번 반복하고 나니까 데이터를 본다는 게 단순히 그래프를 보는 일은 아니라는 걸 알 것 같았습니다.
이 숫자로 어디까지 이야기해도 되는지까지 같이 봐야 했습니다.
그럼 이 숫자를 믿어도 될까
여기까지 오니까 또 다른 고민이 생겼습니다.
그럼 데이터를 어느 정도까지 확인해야 하는 걸까?
완벽하지 않은 데이터라면 공유하지 않는 게 맞나?
그런데 완벽한 데이터가 실제로 있을까?
이벤트가 빠지는 경우도 있고, 서비스 정책이 바뀌기도 합니다. 나중에 제가 몰랐던 예외를 발견하는 경우도 있습니다. 그렇다고 매번 모든 데이터를 완벽하게 검증하고 나서야 이야기하려고 하면, 작은 개선 하나 하는 데 너무 많은 시간이 들 것 같았습니다.
먼저 데이터를 팀원들에게 공유해온 백엔드 개발자분에게 저의 이런 고민을 얘기한 적이 있는데, 정확한 숫자보다 우리가 개선하고자 하는 방향만 맞으면 된다고 하셔서 조금 안심이 되긴 했습니다.
아직 이 부분에 대해서는 저도 명확한 답이 없습니다. 지금은 숫자를 공유할 때 기준을 같이 문서화해서 남기고 있습니다. 어떤 사용자를 대상으로 계산했는지, 어떤 경우는 빠져 있는지 등입니다.
마치며
프론트엔드 개발자가 데이터를 어디까지 봐야 하는지는 아직 잘 모르겠습니다. 분석가처럼 통계나 방법론을 깊게 공부해야 한다고 생각하지도 않습니다. 그렇지만 화면을 만들면서 사용자 행동 데이터를 직접 심고 있다면, 그 데이터가 실제로 어떻게 쓰이는지도 어느 정도는 알아야 하지 않을까 싶습니다.
AI 덕분에 예전보다 훨씬 쉽게 데이터를 볼 수 있게 됐지만, 결과를 그냥 받아서 쓰는 것과 실제 서비스에서 맞는 이야기인지 확인하는 건 다른 문제였습니다.
아직도 데이터를 볼 때마다 헷갈리는 부분이 많습니다. 어디까지 확인해야 충분한지도 모르겠고, 어떤 숫자까지 팀에 가져가도 되는지도 아직 명확하지 않습니다.
그래도 프로덕트를 개선하려면 결국 행동 데이터가 필요하니까, 지금 할 수 있는 만큼은 모아두려고 하는 편입니다.
빠르게 개발하느라 이벤트를 나중에 붙인 적이 있는데, 막상 데이터를 보려고 하니 그 기간이 통째로 비어 있었습니다. 기능은 이미 나가 있는데 초기에 사용자가 어떻게 반응했는지는 확인할 방법이 없었습니다. 그게 좀 아까웠습니다.
그래서 요즘은 새 기능을 개발할 때 화면을 어떻게 만들지와 함께, 어떤 이벤트를 붙일지도 같이 기획하고 있습니다.