앱 출시 후 아무것도 안 보인다면: 외주 개발 이후 꼭 챙겨야 할 분석 셋업

한줄 요약

외주 개발 후 데이터 분석 셋업 없이 운영하면, 무엇을 고쳐야 할지 영원히 감으로만 판단하게 된다.

본문

앱 개발 외주를 맡겨 서비스를 출시한 팀 중 상당수가 같은 상황에 처한다. 배포는 됐고, 링크도 돌렸고, 첫 사용자도 들어왔는데, 정작 그 사람들이 어디서 나갔는지, 핵심 기능까지 닿았는지를 전혀 모른다. 개발사에 "분석 붙여 달라"는 요청을 따로 하지 않았거나, 했더라도 이벤트 설계 없이 기본 페이지뷰만 찍어둔 경우가 많다.

이 글은 그런 팀을 위한 가이드다. 초기 사용자 수가 두 자리, 세 자리에 머무는 단계에서 무엇을 먼저 봐야 하는지, 어떤 도구가 그 용도에 맞는지 순서대로 짚는다.

---

출시 직후, 사용자 수보다 먼저 봐야 할 것

방문자 수를 가장 먼저 확인하고 싶은 건 당연하다. 하지만 사용자가 수십 명인 단계에서 총 방문수는 큰 의미가 없다. 그보다 먼저 던져야 할 질문은 이렇다.

사람들이 어디서 이탈하는가?

100명이 들어왔는데 10명만 핵심 기능에 닿았다면, 나머지 90명을 내보낸 지점을 찾는 게 먼저다. 페이지 이동 흐름상 어떤 단계에서 빠져나가는지를 이벤트로 찍어두지 않으면, 이 질문에 영원히 답할 수 없다.

이 사람은 왜 여기서 멈췄는가?

평균 체류 시간이나 이탈률 같은 집계 숫자는 초기 단계에서 잘못된 안도감을 준다. 대신 특정 사용자의 행동을 처음부터 끝까지 따라가면 훨씬 구체적인 가설이 나온다. "빈 입력창에서 몇 초 머물다 그냥 닫았네"라는 관찰 하나가 "온보딩 문구가 없어서 이탈한다"는 가설로 이어진다.

가입한 사람이 핵심 가치에 닿았는가?

DAU, MAU는 수천 명 단위에서 쓰는 지표다. 초기에는 활성화 지표 하나만 잘 정의해도 충분하다. 가입 후 24시간 안에 핵심 액션을 완료한 비율. 이 숫자가 낮다면, 아무리 사용자를 더 끌어와도 밑 빠진 독에 물 붓기다.

한 번 쓴 사람이 다시 돌아오는가?

결제 전환보다 재방문이 더 정직한 신호다. 홍보를 멈춰도 돌아오는 사람이 있다면, 서비스가 실제 가치를 주고 있다는 의미다. 사용자가 적을 때는 그래프보다 명단으로 보는 게 낫다. 지난주 신규 가입자 중 이번 주 재방문한 사람이 누구인지 직접 확인하고, 가능하면 연락을 취하는 게 어떤 퍼널 차트보다 유용하다.

어떤 분석 도구를 선택해야 하는가

초기 서비스에 쓸 수 있는 무료 또는 저비용 분석 도구는 여러 가지다. 크게 두 가지 기준으로 나뉜다. 사용자 행동을 직접 관찰하고 싶은가, 아니면 유입 채널과 전환 흐름을 보고 싶은가.

사용자 행동 관찰이 목적이라면: PostHog가 현재 시점에서 가장 균형 잡힌 선택이다. 이벤트 분석, 세션 리플레이(사용자 화면 녹화), 피처 플래그를 하나의 무료 플랜에서 쓸 수 있다. 월 100만 이벤트, 세션 리플레이 5,000건까지 무료다. 사용자 입력과 저장이 핵심인 서비스, 즉 SaaS나 인터랙티브 앱에 잘 맞는다. Next.js 등 현대적 프론트엔드 스택과의 통합도 빠르게 처리된다.

유입 채널과 광고 ROI가 목적이라면: GA4가 맞다. 어느 채널에서 들어온 사람이 어떤 행동을 했고 결제까지 갔는지를 한 화면에서 볼 수 있다. Search Console, Google Ads와 연동되고 무료 한도도 크다. 다만 사용자 행동의 세밀한 관찰보다는 채널 성과 분석에 최적화된 구조다.

두 가지를 동시에 설치하고 싶은 팀도 있는데, 초기에는 권장하지 않는다. 대시보드 두 개를 오가며 해석하는 데 드는 시간이 실제 분석보다 길어진다.

그 외에 데이터를 외부 서버에 두기 싫다면 Umami(오픈소스 셀프 호스팅), 규제나 개인정보 이슈에 민감한 서비스라면 쿠키 없는 Plausible, 엔터프라이즈 수준의 퍼널 분석을 무료로 체험하고 싶다면 Mixpanel을 대안으로 검토할 수 있다.

외주 개발 의뢰 시 분석 셋업을 함께 요청해야 하는 이유

앱 개발 외주를 진행할 때 분석 셋업을 별도 요청 항목으로 명시하지 않으면, 대부분의 개발사는 기능 구현에만 집중한다. 결과물은 동작하지만, 이벤트는 하나도 안 찍혀 있다.

분석 셋업을 처음부터 개발 범위에 포함시키면 세 가지가 달라진다. 첫째, 어떤 액션이 핵심 이벤트인지 논의하는 과정에서 서비스의 핵심 가치가 더 명확해진다. 둘째, 출시 직후부터 데이터가 쌓이기 시작한다. 나중에 이벤트를 추가하려면 배포를 다시 해야 한다. 셋째, 이후 기능 개선 요청 시 근거 있는 우선순위 판단이 가능해진다. "이 버튼에서 이탈이 많다"는 데이터가 있으면, 다음 개발 의뢰가 훨씬 구체적이고 효율적이다.

좋은 외주 개발사라면 이 논의를 먼저 꺼낸다. 그렇지 않다면 클라이언트가 요청해야 한다.

지표보다 먼저, 가설을 세워라

도구를 설치했다고 분석이 시작되는 건 아니다. 대시보드를 열어 숫자를 보는 것과, 그 숫자로 무언가를 판단하는 것은 전혀 다른 일이다.

분석을 의미 있게 만드는 건 사전에 세운 가설이다. "가입 완료 후 핵심 기능 화면까지 도달하는 비율이 50% 이하면, 온보딩 흐름에 문제가 있다"처럼 구체적인 기준이 있어야 데이터가 판단의 재료가 된다.

도구는 좋은 질문을 떠올리게 해주는 수단이지, 답을 주지 않는다. 초기 서비스의 속도는 빠르게 만드는 데서 오는 게 아니라, 빠르게 배우는 데서 나온다. 측정은 그 배움의 시작이다.