지표로 제품을 개선하는 반복 루프

출시 후에는 질문이 바뀐다

출시 전에는 "이 기능을 만들 수 있는가?"가 중요했다. 출시 후에는 질문이 바뀐다.

"사용자가 어디서 멈추는가?"

"돈을 낸 고객은 무엇을 보고 결제했는가?"

"리포트를 받은 사장님은 실제로 행동했는가?"

1인 창업가가 출시 후 흔히 하는 실수는 반응이 애매할 때 기능을 더 붙이는 것이다. 대시보드를 예쁘게 만들고, 자동 답글 게시를 추가하고, 업종별 템플릿을 늘린다. 하지만 사용자가 첫 리뷰 업로드에서 멈추고 있다면 새 기능은 문제를 해결하지 못한다. 결제 직전 가격 문구에서 이탈한다면 AI 분석 품질을 더 고도화하기 전에 가격표와 유료 전환 문맥부터 실험해야 할 수도 있다.

출시 후의 실력은 더 많은 기능이 아니라 올바른 반복 속도에서 드러난다. 반복 속도란 아무거나 빨리 바꾸는 속도가 아니다. 데이터를 보고, 고객의 말을 듣고, 가장 중요한 병목을 하나 고른 뒤, 작게 수정하고 다시 확인하는 속도다.

이번 장에서는 우리가 만든 소상공인 리뷰 분석 AI SaaS를 기준으로 지표를 설계한다. 목표는 거창한 데이터 조직을 만드는 것이 아니다. 혼자 운영하면서도 감이 아니라 근거로 다음 작업을 고르는 체계를 만드는 것이다.

AI 생성 이미지

단계별로 하나씩만 핵심 지표를 잡는다

처음부터 지표를 많이 보면 오히려 판단이 흐려진다. 방문자 수, 가입자 수, 업로드 수, 결제 수, 이메일 오픈율, 리포트 조회 수를 모두 같은 무게로 보면 무엇을 고쳐야 할지 모른다.

먼저 고객 여정을 다섯 단계로 나눈다.

핵심 지표는 단계별로 하나만 고른다. 보조 지표를 아예 보지 말라는 뜻은 아니다. 다만 이번 주에 무엇을 고칠지 결정할 때는 "지금 가장 중요한 숫자 하나"가 있어야 한다. 그래야 기능 추가, 문구 수정, 가격 실험 사이에서 우선순위를 정할 수 있다.

획득 단계에서는 전체 방문자 수보다 "맞는 고객이 왔는지"가 중요하다. 음식점·카페 사장님을 위한 서비스인데 AI 도구에 관심 있는 개발자만 방문한다면 방문자 수가 많아도 의미가 작다. 그래서 채널별로 봐야 한다. 네이버 카페 글에서 온 방문자, 콜드 DM에서 온 방문자, 블로그 검색에서 온 방문자는 의도가 다르다. 목표 고객 비율은 가입 폼의 업종 선택, 신청 설문, 문의 내용, 유입 채널을 함께 보며 대략적으로 판단할 수 있다.

활성화 단계에서는 가입 자체를 성공으로 보지 않는다. 이 서비스의 첫 가치는 리뷰를 업로드하고 분석 결과를 보는 순간에 발생한다. 따라서 signup_completed보다 first_report_completed가 더 중요하다. 가입자는 많은데 첫 리포트 생성이 적다면 제품 설명, 온보딩, 업로드 화면, 분석 비용 안내 중 어딘가에서 막히고 있다는 뜻이다.

전환 단계에서는 결제율만 보지 않는다. 어떤 리포트를 본 사람이 결제했는지를 봐야 한다. 반복 불만 TOP 5를 본 뒤 결제했는지, 답글 초안을 복사한 뒤 결제했는지, 가격표만 보고 나갔는지에 따라 다음 개선 방향이 달라진다.

유지 단계에서는 매일 접속률 같은 일반 SaaS 지표를 그대로 가져오면 안 된다. 음식점 사장님은 리뷰 분석 서비스를 매일 쓸 필요가 없을 수 있다. 이 서비스의 자연스러운 반복 주기는 주간 또는 월간이다. 그러므로 "7일 재방문"보다 "30일 내 새 리뷰 묶음 업로드"나 "두 번째 리포트 생성"이 더 맞는 지표다.

추천 단계에서는 공유가 중요하다. 사장님이 리포트를 직원, 공동대표, 마케팅 대행사에 공유한다면 그 리포트는 업무 자료가 된 것이다. 공유 링크를 만들고, 받은 사람이 실제로 열어보고, 그중 일부가 새 가입으로 이어지는지 확인한다.

도구는 역할을 나눠 쓴다

분석 도구 하나로 모든 문제를 해결하려고 하면 오히려 복잡해진다. 1인 창업가에게는 역할을 나누는 편이 낫다.

Google Analytics는 유입과 마케팅 성과를 보는 데 적합하다. 어떤 검색어, 콘텐츠, 캠페인, 외부 링크가 랜딩페이지 방문과 신청으로 이어지는지 확인한다. PostHog는 제품 안에서 사용자가 어떤 행동을 했는지 보는 데 더 적합하다. 이벤트 기반 분석, 퍼널, 리텐션, 세션 리플레이 같은 기능을 통해 가입 이후의 행동을 추적할 수 있다.¹ PostHog의 비교 글에서도 Google Analytics는 웹·마케팅 분석에 강하고, PostHog는 제품 행동 분석과 실험에 강하다는 식으로 두 도구의 역할 차이를 설명한다.²

Supabase는 실제 데이터의 기준이다. 결제가 성공했는지, 리포트가 생성됐는지, 사용권이 차감됐는지, 고객 피드백이 저장됐는지는 결국 데이터베이스에 남는다. 분석 도구의 이벤트 수치와 Supabase의 실제 레코드 수가 다르면, 먼저 Supabase를 기준으로 실제 상태를 확인하고 이벤트 기록이 빠졌는지 살펴보는 편이 안전하다.

이 서비스에서는 다음처럼 나눌 수 있다.

중요한 것은 도구를 많이 붙이는 게 아니다. 같은 질문에 답하도록 연결하는 것이다.

예를 들어 "블로그 글에서 온 사장님이 결제까지 가는가?"라는 질문을 보자. Google Analytics는 어떤 글에서 방문했는지 알려준다. PostHog는 그 방문자가 가입하고 업로드했는지 보여준다. Supabase는 실제 결제와 사용권 부여가 됐는지 확인해 준다. 세 도구의 숫자를 완벽하게 맞출 필요는 없다. 다만 같은 흐름 안에서 어디가 줄어드는지는 볼 수 있어야 한다.

이를 위해 최소한 유입 채널과 캠페인 정보는 가입 이후에도 이어지게 해두는 것이 좋다. 예를 들어 UTM 파라미터를 저장하거나, 가입 시점에 최초 유입 채널을 사용자 프로필에 남겨두면 나중에 "어떤 콘텐츠가 결제 고객을 데려왔는지"를 훨씬 쉽게 볼 수 있다.

이벤트 이름은 제품의 문장으로 정한다

분석은 이벤트 이름에서 시작한다. 이벤트란 사용자가 한 행동을 기록한 것이다. 버튼 클릭, 업로드 완료, 리포트 생성, 결제 성공이 모두 이벤트가 될 수 있다.

처음에는 다음 정도면 충분하다.

이벤트 이름은 개발자가 보기 좋은 말보다 제품의 흐름이 보이는 말로 정한다. button_click_1은 나중에 아무 의미가 없다. 반면 review_batch_uploaded는 사용자가 첫 번째 중요한 행동을 끝냈다는 뜻이 분명하다.

각 이벤트에는 속성을 함께 넣는다. 예를 들어 review_batch_uploaded에는 업종, 리뷰 수, 업로드 방식, 리뷰 출처를 넣을 수 있다. 단, 개인정보나 리뷰 원문 전체를 분석 도구에 보내면 안 된다. 원문은 Supabase에 권한을 걸어 저장하고, 분석 도구에는 숫자와 분류값만 보내는 편이 안전하다.

또 하나 기억할 점이 있다. 결제 완료, 리포트 생성 완료처럼 중요한 이벤트는 가능하면 서버 기준으로 기록해야 한다. 사용자가 버튼을 눌렀다는 사실과 실제 결제가 성공했다는 사실은 다르다. 버튼 클릭은 PostHog 이벤트로 남길 수 있지만, 최종 성공 여부는 결제 웹훅과 데이터베이스 상태까지 확인해야 한다.

사용자가 멈추는 곳을 먼저 찾는다

이제 퍼널을 만든다. 퍼널은 사용자가 목표 행동까지 가는 단계별 흐름이다. 우리의 첫 퍼널은 이렇게 잡을 수 있다.

랜딩페이지 방문 → CTA 클릭 → 가입 완료 → 온보딩 완료 → 리뷰 업로드 완료 → 분석 시작 → 리포트 완료 → 결제 완료

여기서 가장 많이 줄어드는 구간을 찾는다. 이탈 구간에 따라 해야 할 일이 달라진다.

가입 전 CTA 클릭이 낮다면 첫 화면의 약속이 약한 것이다. "AI로 리뷰를 분석합니다"보다 "리뷰 50개에서 이번 주 바꿀 문제 3가지를 찾아드립니다"가 더 나을 수 있다.

가입 후 온보딩 완료가 낮다면 입력 항목이 많거나 불안한 것이다. 사업자등록번호, 매출, 직원 수 같은 정보는 첫 분석에 필요하지 않다면 빼야 한다.

리뷰 업로드 완료가 낮다면 업로드 방식이 어렵거나 데이터 사용 불안이 큰 것이다. 붙여넣기 예시를 보여주고, 원문 저장 방식과 삭제 방법을 더 명확히 안내해야 한다.

분석 시작은 많은데 리포트 완료가 낮다면 기술 문제다. AI API 실패, JSON 검증 실패, 서버 타임아웃, 사용권 차감 오류를 확인해야 한다.

리포트 조회는 많은데 결제가 낮다면 가치 전달 또는 가격 문제다. 이때는 가격을 낮추기 전에 리포트의 유료 전환 문맥을 본다. 무료 샘플이 충분히 구체적인지, 유료 리포트에서 무엇이 추가되는지, 사장님이 결제 전에 불안해하는 질문이 해결됐는지 확인한다.

처음부터 통계적으로 완벽한 결론을 내리려고 할 필요는 없다. 초기에는 표본이 작다. 그래도 같은 기준으로 매주 보면 흐름이 보인다. 숫자가 적을수록 고객 인터뷰와 세션 리플레이를 함께 봐야 한다. "10명 중 3명이 이탈했다"는 숫자만으로는 부족하지만, 그 3명이 같은 화면에서 멈췄다면 고칠 이유가 충분하다.

제품 고유의 품질 지표를 만든다

일반 지표만으로는 AI 제품의 품질을 판단하기 어렵다. 리뷰 분석 서비스에는 이 제품만의 품질 지표가 필요하다.

첫 번째는 AI 분석 결과 만족도다. 리포트 하단에 간단히 묻는다.

"이 리포트가 매장 개선에 도움이 되었나요?"

선택지는 5점 척도보다 처음에는 세 가지가 낫다.

• 도움이 됐다

• 애매하다

• 도움이 안 됐다

그리고 한 줄 이유를 받는다. "이미 아는 내용이었다", "리뷰 근거가 있어서 좋았다", "실행 방법이 더 구체적이면 좋겠다" 같은 문장이 다음 개선의 재료가 된다.

두 번째는 리포트 복사율이다. 사장님이 답글 초안, 개선 액션, 홍보 문구를 복사했다면 실제 업무에 쓰려는 신호다. 단순 조회보다 강한 행동이다. 특히 어떤 영역이 많이 복사되는지 봐야 한다. 답글 초안만 많이 복사된다면 서비스의 핵심 가치를 "리뷰 분석"보다 "답글과 홍보 문구 자동 작성" 쪽으로 조정할 수도 있다.

세 번째는 공유 링크 클릭률이다. 공유 링크를 만들었는지, 만든 링크가 실제로 열렸는지, 누가 어떤 섹션을 봤는지 확인한다. 직원에게 공유된 리포트가 자주 열리면 팀 실행용 기능을 나중에 고려할 수 있다. 반대로 공유 링크 생성은 많은데 클릭이 없다면 공유 문구나 전달 방식이 약할 수 있다.

네 번째는 근거 리뷰 열람률이다. AI의 결론을 바로 믿지 않는 고객은 근거를 확인한다. 문제 TOP 5에서 대표 리뷰를 펼쳐보는 행동은 신뢰 형성 과정이다. 근거 리뷰를 본 사용자의 결제율이 높다면, 다음 버전에서는 근거 표시를 더 눈에 띄게 배치해야 한다.

이런 품질 지표는 매출 지표보다 앞에서 신호를 준다. 결제는 아직 적어도 복사율과 공유율이 높다면 제품 가치가 살아 있을 수 있다. 반대로 방문자와 가입자는 늘어나는데 리포트 만족도가 낮다면 마케팅을 늘리기 전에 제품 품질을 고쳐야 한다.

고객 요청을 그대로 만들지 않는다

출시 후 고객은 다양한 요청을 한다.

"네이버 리뷰를 자동으로 가져오게 해주세요."

"직원별로 계정을 나눠 주세요."

"인스타그램 게시물까지 만들어 주세요."

"악성 리뷰 신고 가능성도 판단해 주세요."

모두 그럴듯하다. 하지만 요청을 들은 순서대로 만들면 제품은 금방 무거워진다. 1인 창업가는 고객 요청을 기능 목록이 아니라 우선순위 후보로 다뤄야 한다.

간단한 기준 세 가지를 쓴다.

개발 난이도는 점수가 높을수록 쉬운 것으로 둔다. 세 점수를 더해 높은 것부터 검토한다. 단순 합계가 완벽한 답은 아니지만, 감정적인 결정을 줄여준다.

예를 들어 "리포트 문구 직접 수정 후 저장"은 매출 영향 4, 반복 빈도 4, 개발 난이도 4일 수 있다. 사장님이 AI 문구를 그대로 쓰기보다 살짝 고쳐 쓰고 싶어 하며, 구현도 비교적 작다. 우선순위가 높다.

반면 "모든 리뷰 플랫폼 자동 연동"은 매출 영향 5, 반복 빈도 4일 수 있지만 개발 난이도 1이다. API 제약, 크롤링 위험, 유지보수 부담이 크다. 지금 당장 만들기보다 CSV·붙여넣기 개선으로 같은 문제를 얼마나 줄일 수 있는지 먼저 본다.

"팀 권한 관리"는 일부 고객에게 중요해 보일 수 있다. 하지만 초기 고객 대부분이 1인 사장님이라면 반복 빈도는 낮다. 공유 링크와 읽기 전용 페이지로 버티는 편이 낫다.

고객 요청을 거절하라는 뜻은 아니다. 바로 만들지 않더라도 기록은 남겨야 한다. 누가 요청했는지, 어떤 상황에서 필요했는지, 돈을 더 낼 의사가 있었는지를 함께 적어둔다. 시간이 지나 같은 요청이 반복되면 그때는 단순한 의견이 아니라 시장 신호가 된다.

주간 개선 회의를 혼자서 한다

혼자 일해도 회의는 필요하다. 다만 참석자는 한 명이면 된다. 매주 같은 시간에 30분만 지표를 본다.

순서는 단순하다.

1. 이번 주 유입 채널별 방문과 신청을 본다.

2. 가입부터 리포트 완료까지 퍼널 이탈 구간을 본다.

3. 결제와 사용권 차감이 정상인지 본다.

4. 리포트 만족도, 복사율, 공유율을 본다.

5. 고객 문의와 요청을 세 가지 기준으로 점수화한다.

6. 다음 주에 바꿀 것을 하나만 정한다.

마지막이 중요하다. 한 주에 여러 가지를 바꾸면 어떤 변화가 효과를 냈는지 알기 어렵다. 가격 문구, 업로드 화면, 리포트 구성, 이메일 시퀀스를 동시에 바꾸면 숫자가 좋아져도 이유를 모른다.

예를 들어 이번 주 가장 큰 병목이 리뷰 업로드라면 다음 주 실험은 하나로 정한다.

"업로드 화면 상단에 붙여넣기 예시와 개인정보 삭제 안내를 추가한다."

성공 기준도 미리 정한다.

"가입자 중 리뷰 업로드 완료율을 35%에서 45%로 올린다."

다음 주에는 결과를 보고 유지, 수정, 되돌리기 중 하나를 선택한다. 숫자가 좋아졌고 고객 반응도 나쁘지 않다면 유지한다. 숫자는 좋아졌지만 불만이 늘었다면 수정한다. 숫자도 반응도 나빠졌다면 되돌린다. 이 작고 지루한 루프가 제품을 강하게 만든다.

좋은 반복은 제품과 마케팅을 함께 바꾼다

지표는 제품팀만의 도구가 아니다. 1인 창업가에게 제품과 마케팅은 분리되어 있지 않다.

리포트에서 "답글 초안 복사율"이 높다면 콘텐츠 주제도 바꿀 수 있다. "악성 리뷰 답글 예시", "카페 사장님이 바로 쓸 수 있는 리뷰 답변 문구" 같은 글을 만든다. 이 콘텐츠에서 들어온 고객이 실제로 답글 초안을 많이 복사하는지 다시 본다.

공유 링크 클릭률이 높다면 랜딩페이지에 "직원과 함께 보는 리뷰 개선 리포트"라는 문구를 실험할 수 있다. 반대로 공유가 거의 없다면 팀 협업 기능을 만들 이유가 약하다.

리포트 만족도에서 "이미 아는 내용"이라는 피드백이 반복된다면 AI 프롬프트와 리포트 구조를 고쳐야 한다. 단순 요약을 줄이고, 리뷰 근거가 있는 실행 액션을 더 구체화한다. "주말 저녁 웨이팅 안내 문구를 입구와 예약 문자에 추가"처럼 현장 행동으로 내려가야 한다.

이렇게 지표는 다음 기능뿐 아니라 다음 문구, 다음 콘텐츠, 다음 고객군을 정하는 재료가 된다.

이번 장의 실행 기준

이 장을 끝낸 뒤에는 최소한 다음 네 가지가 있어야 한다.

첫째, 획득·활성화·전환·유지·추천 단계별 핵심 지표가 정리되어 있어야 한다.

둘째, Google Analytics, PostHog, Supabase가 각각 어떤 질문에 답하는지 나뉘어 있어야 한다.

셋째, AI 분석 결과 만족도, 리포트 복사율, 공유 링크 클릭률 같은 제품 고유의 품질 지표가 있어야 한다.

넷째, 고객 요청을 매출 영향, 반복 빈도, 개발 난이도로 평가하는 우선순위 표가 있어야 한다.

이제 제품은 출시된 상태에서 조금씩 배운다. 중요한 것은 많이 바꾸는 것이 아니라 제대로 보고 바꾸는 것이다. 다음 장에서는 이 반복 루프를 바탕으로, 혼자서도 확장 가능한 사업 구조로 다듬는 방법을 다룬다.

참고

¹PostHog Product Analytics Documentation

²PostHog vs Google Analytics 4