／블로그

서비스를 출시한 다음에는 무엇을 확인해야 할까요?

서비스 출시 뒤에는 방문자 수보다 사용자가 약속한 결과를 얻는 성공 행동을 먼저 정하세요. 유입부터 활성화·전환·유지까지 흐름을 보고 오류·최종 DB 결과·고객 피드백을 연결하면 다음에 고칠 한 지점을 선택할 수 있습니다.

핵심 요약

슬라이드 1
슬라이드 2
슬라이드 3
슬라이드 4
슬라이드 5
슬라이드 6
슬라이드 7
슬라이드 8

웹 애플리케이션을 배포하고 주소를 공유하면 방문자가 들어오기 시작합니다.

분석 화면에는 숫자가 쌓여요.

방문자 328명
페이지 조회 741회
평균 체류 시간 1분 42초

숫자가 늘어나는 모습은 반갑지만 이것만으로 서비스가 잘되고 있는지는 알기 어렵습니다.

예약 서비스라면 방문보다 실제 예약이 중요하고, 업무 도구라면 가입보다 사용자가 첫 업무를 끝냈는지가 중요합니다. 출시 뒤 확인할 지표는 서비스가 사용자에게 약속한 결과에서 시작해야 해요.

방문자 수보다 먼저 성공 행동을 정해요

서비스마다 사용자가 얻으려는 결과가 다릅니다.

예약 서비스
→ 예약 완료

온라인 강의
→ 첫 강의 재생 또는 수강 완료

업무 자동화 도구
→ 첫 문서 생성

커뮤니티
→ 첫 글 작성 또는 답변 받기

랜딩페이지
→ 문의 제출 또는 상담 예약

이 행동을 핵심 행동 또는 전환이라고 부를 수 있어요.

한 번에 완벽한 지표를 찾을 필요는 없습니다. 먼저 이런 문장을 완성해보세요.

우리 서비스에서 사용자가 처음 가치를 얻었다고 볼 수 있는 순간은
[                              ]이다.

이 문장이 없으면 방문, 클릭과 체류 시간처럼 쉽게 보이는 숫자만 쫓게 됩니다.

출시 뒤에는 하나의 숫자가 아니라 흐름을 봐요

사용자가 핵심 행동에 도달하기까지 여러 단계를 거칩니다.

신청 서비스를 예로 들어볼게요.

랜딩페이지 방문
→ 프로그램 상세 확인
→ 신청 시작
→ 정보 입력
→ 결제창 열기
→ 결제 완료

각 단계에 도착한 사람 수를 비교하는 흐름을 퍼널(funnel)이라고 합니다.

단계 사용자 수 이전 단계 대비
랜딩페이지 방문 1,000명 -
상세 확인 500명 50%
신청 시작 200명 40%
결제창 열기 150명 75%
결제 완료 120명 80%

이 표를 보면 “전환율이 낮다”에서 끝나지 않고 어느 단계부터 조사할지 정할 수 있습니다.

상세 확인 전 이탈이 크다면 첫 화면의 메시지와 고객의 기대가 맞지 않을 수 있어요. 결제창에서 많이 멈춘다면 결제수단, 오류와 모바일 화면을 확인할 수 있습니다.

광고와 랜딩페이지의 약속을 연결하는 방법은 메시지 매칭 글에서 확인할 수 있어요.

1. 유입: 사람들이 어디에서 왔나요?

먼저 사용자가 서비스를 어떻게 발견했는지 봅니다.

유입 수만 비교하면 판단을 잘못할 수 있습니다.

채널 A
→ 방문 1,000명
→ 신청 10명

채널 B
→ 방문 200명
→ 신청 20명

채널 A가 방문은 많지만 실제 고객을 더 많이 만든 것은 채널 B입니다. 그래서 유입 경로마다 핵심 행동까지 이어지는 비율을 함께 봐야 해요.

광고 링크에 UTM 값을 붙이면 캠페인과 소재를 구분할 수 있습니다. 다만 같은 채널의 이름을 instagram, Instagram, ig처럼 제각각 사용하면 데이터가 나뉘므로 작성 규칙을 정하세요.

검색 유입은 분석 도구의 방문 기록뿐 아니라 Google Search Console과 네이버 서치어드바이저에서 노출, 클릭과 검색어를 함께 확인하는 것이 좋습니다. 사이트 등록 방법은 구글·네이버 검색에 등록하는 가이드에 정리되어 있습니다.

2. 활성화: 처음 가치를 경험했나요?

가입은 서비스 이용의 시작일 뿐입니다.

회원가입 완료
→ 계정은 생김

첫 예약 완료
→ 서비스의 가치를 경험

가입한 사용자가 첫 핵심 행동까지 도달했는지를 활성화 지표로 볼 수 있습니다.

서비스별 예시는 다음과 같아요.

활성화까지 시간이 오래 걸리거나 중간 단계가 많다면 시작 안내를 줄이고 기본값이나 예시를 제공할 수 있습니다.

단, 사용자가 버튼을 눌렀다는 사실만으로 실제 가치를 얻었다고 단정하지 마세요. 결과가 저장됐는지, 다시 찾을 수 있는지와 사용자 피드백을 함께 확인해야 합니다.

3. 전환: 원하는 행동을 끝냈나요?

전환은 반드시 결제만 의미하지 않습니다.

하나의 서비스에도 작은 전환과 최종 전환이 함께 있을 수 있어요.

뉴스레터 신청
→ 관심 표현

상담 예약
→ 구매 검토

결제 완료
→ 매출 발생

각 행동의 의미를 구분하고 이벤트 이름도 명확하게 정하세요.

button_clicked

처럼 모호한 이름보다

application_started
application_submitted
payment_completed

처럼 무엇이 일어났는지 알 수 있는 이름이 분석하기 쉽습니다.

결제 완료 이벤트는 브라우저의 성공 화면만 보고 기록하면 실제 승인과 다를 수 있습니다. 중요한 결과는 서버와 데이터베이스의 확정 상태를 기준으로 확인해야 해요.

4. 유지: 사용자가 다시 돌아오나요?

한 번 사용하고 끝나는 서비스가 아니라면 재방문과 반복 사용을 확인해야 합니다.

이번 주 가입한 사용자 중
다음 주에도 핵심 기능을 사용한 사람은 몇 명인가?

이런 지표를 리텐션(retention)이라고 합니다.

반복 주기는 서비스 성격에 맞춰야 해요.

한 달에 한 번 쓰는 서비스를 매일 방문하지 않는다고 실패로 판단하면 안 됩니다. 사용자가 자연스럽게 다시 필요로 하는 시점을 기준으로 보세요.

반복 사용이 적다면 기능을 더 만들기 전에 처음 기대한 결과를 얻었는지 고객에게 물어보는 편이 좋습니다.

5. 수익: 매출과 실제 남는 금액을 구분해요

유료 서비스라면 결제 금액뿐 아니라 취소와 비용을 함께 봐야 합니다.

총 결제 금액
- 취소·환불
- 결제 수수료
- 광고비
- 서비스 운영비
= 실제 남는 금액

처음에는 다음 항목으로 충분할 수 있어요.

매출 숫자는 분석 이벤트보다 결제사와 데이터베이스의 주문·결제 기록을 기준으로 확인하는 편이 안전합니다.

월 운영비를 함께 계산하려면 바이브코딩 앱의 한 달 운영비를 참고하세요.

6. 오류와 성능: 사용하지 못한 사람은 없나요?

전환율이 떨어졌다고 문구와 디자인부터 바꾸면 실제 오류를 놓칠 수 있습니다.

다음 신호를 함께 확인하세요.

사용자 행동 분석은 “어디에서 멈췄는가”를 보여주고, 서버 로그는 “왜 실패했는가”를 찾는 데 도움을 줍니다.

PostHog
→ 사용자가 거친 단계와 화면 행동

Vercel 로그
→ 서버 요청과 오류

데이터베이스
→ 실제로 저장된 최종 결과

세 기록의 수가 완전히 같지 않을 수 있습니다. 광고 차단, 네트워크 실패, 중복 이벤트와 집계 기준이 다르기 때문이에요. 숫자의 차이가 허용 가능한지, 중요한 결과는 어느 시스템을 기준으로 삼을지 정해야 합니다.

로그가 필요한 이유와 로그를 추가해 버그를 찾는 과정을 함께 참고하세요.

7. 고객의 말은 숫자에 이유를 붙여줘요

분석 도구는 사용자가 어디에서 멈췄는지 보여줄 수 있지만 왜 멈췄는지 항상 알려주지는 않습니다.

가격이 예상보다 높았나요?
필요한 기능이 없었나요?
사용 방법을 이해하지 못했나요?
오류가 났나요?
지금은 구매할 때가 아니었나요?

초기 서비스에서는 숫자가 적기 때문에 고객 대화 한두 건이 큰 힌트를 줄 수 있습니다.

사용자가 한 말과 실제 행동이 다를 수도 있으므로 둘을 함께 보세요. 인터뷰에서 쉽다고 답했지만 첫 작업까지 20분이 걸렸다면 실제 사용 과정을 더 살펴볼 필요가 있습니다.

전체 평균보다 조건을 나눠서 봐요

전체 전환율 하나만 보면 중요한 차이가 숨겨질 수 있습니다.

예를 들어 전체 결제 전환율은 그대로인데 모바일만 크게 떨어졌다면 최근 화면 수정이 작은 기기에서 문제를 만든 것일 수 있어요.

조건을 너무 많이 나누면 몇 명의 행동을 큰 추세처럼 해석하게 됩니다. 사용자 수가 적을 때는 비율과 함께 실제 인원도 표시하세요.

전환율 50%

보다

2명 중 1명 전환, 50%

이 판단에 더 도움이 됩니다.

지표 하나만 목표로 만들면 부작용이 생겨요

가입자 수만 늘리면 가입 후 아무것도 하지 않는 계정이 많아질 수 있습니다. 결제 전환만 높이려고 환불 기준을 숨기면 단기 매출은 늘어도 문의와 환불이 함께 늘 수 있어요.

핵심 지표 옆에는 품질을 지키는 지표를 함께 두세요.

결제 완료율
+ 결제 오류율
+ 취소·환불률
+ 고객 문의

첫 결과 생성률
+ 결과 저장 성공률
+ 다음 주 재사용률

숫자를 올리는 것이 아니라 사용자에게 더 좋은 결과를 주는 것이 목표입니다.

처음에는 주간 운영판 하나면 충분해요

초기 서비스에 수십 개의 그래프가 필요하지 않습니다.

매주 같은 기준으로 다음을 확인해보세요.

영역 확인할 질문 예시 지표
유입 어디에서 왔나요? 채널별 방문과 핵심 행동
활성화 첫 가치를 경험했나요? 가입 후 첫 결과 완료율
전환 중요한 행동을 끝냈나요? 신청·결제 완료율
유지 다시 사용했나요? 서비스 주기에 맞는 재사용률
품질 막힌 사용자는 없나요? 오류율, 실패 단계, 문의
수익 실제 결과가 남았나요? 순결제액, 환불, 운영비

그리고 숫자 옆에 이번 주의 결론과 행동 하나를 적습니다.

관찰
→ 모바일 신청 시작률이 데스크톱보다 낮음

근거
→ 210명 중 18% vs 95명 중 34%

다음 행동
→ 모바일 첫 화면의 신청 버튼과 로딩 오류 확인

판단 날짜
→ 다음 주 같은 조건으로 다시 비교

분석의 결과는 그래프가 아니라 다음에 확인하거나 바꿀 행동이어야 합니다.

개인정보를 필요한 만큼만 수집해요

분석을 자세히 하고 싶다고 모든 입력값과 화면을 기록해서는 안 됩니다.

세션 리플레이를 사용한다면 입력칸이 마스킹되는지, 관리자와 결제 화면을 기록할 필요가 있는지 확인하세요. 개인정보 처리방침, 동의와 보관 기간은 실제 서비스의 국가와 대상에 맞게 검토해야 합니다.

사용자를 구분해야 할 때도 이메일을 이벤트마다 그대로 보내기보다 서비스 내부의 식별자를 사용할 수 있습니다.

AI에게 측정 계획을 먼저 만들게 해요

이 서비스를 출시한 뒤 무엇을 측정할지 설계해줘.
아직 분석 코드를 추가하지 마.

먼저 서비스가 사용자에게 주는 핵심 결과와
그 결과에 도달하는 사용자 흐름을 확인해줘.

다음 내용을 표로 정리해줘.
- 단계
- 사용자의 행동
- 성공 조건
- 이벤트 이름
- 서버·DB에서 확인할 최종 결과
- 실패 이벤트와 오류 정보
- 개인정보 위험
- 이 지표로 내릴 수 있는 결정

유입, 활성화, 전환, 유지, 오류와 수익을 구분하고
첫 버전에 꼭 필요한 이벤트만 골라줘.

페이지 조회와 버튼 클릭을 무조건 모두 수집하지 말고,
중복 이벤트가 생길 수 있는 위치와
브라우저 이벤트를 신뢰하면 안 되는 결과도 표시해줘.

PostHog, 서버 로그와 데이터베이스 중
각 지표의 기준이 되는 곳도 정리해줘.

구현한 뒤에는 실제로 한 번 흐름을 완료해 이벤트가 순서대로 한 번씩 들어오는지 확인하세요. 이벤트 이름과 속성을 바꿀 때는 이전 데이터와 비교할 수 있는지도 검토해야 합니다.

출시 첫 주 체크리스트

정리

출시 뒤 분석의 목적은 대시보드를 가득 채우는 것이 아닙니다. 사용자가 어디에서 가치를 얻고 어디에서 막히는지 찾아, 다음 한 번의 개선을 더 정확하게 선택하는 것입니다.

Vercel Analytics와 에러 모니터링을 프로젝트에 처음 연결하는 과정은 바이브코딩 가이드 15장에서 따라 할 수 있습니다.

#기초#운영#서비스 운영#제품 분석#PostHog#지표#전환#로그#바이브코딩

인스타그램 @ddukddak.build · 페이스북 뚝딱