[TIL] 멋쟁이사자처럼 AI PM 부트캠프 수강생 후기 - MVP 측정 인프라 먼저 구축한 이유

[멋쟁이사자처럼이 전하는 말]

"KPI를 뭐로 정할까요?" 제품을 처음 만들 때 가장 먼저 나오는 질문 중 하나예요. 그런데 유저가 단 한 명도 없는 MVP 단계에서 KPI를 정하는 게 과연 의미가 있을까요? 기준이 되지 못할 수치를 억지로 채우는 것보다, '무엇을 볼 수 있는 상태인가'를 먼저 갖추는 게 더 중요할 수 있어요.

멋쟁이사자처럼 부트캠프는 단순히 배우는 것에 그치지 않고, 배운 내용을 실제 프로젝트에 적용하고 기록하는 것까지 함께 고민하고 있어요. 수강생들이 TIL(Today I Learned) 블로그 챌린지로 학습과 실전 경험을 기록하는 것도 그 일환이에요.

오늘 소개할 TIL의 주제는 유저 0명 MVP에서 측정 인프라를 먼저 구축한 경험이에요. KPI를 임의로 정하지 않고 visitor_id 식별·퍼널 이벤트 보강·16개 지표 스펙 문서화까지 '측정 가능한 상태'를 직접 만들어간 과정이에요. AI·PM·Data 3가지 관점의 회고까지 담긴 멋쟁이사자처럼 AI PM 부트캠프 수강생의 기록을 지금 확인해 보세요!

"관찰이 목적인데 KPI를 쓰라니, 지표만 쓰면 되나요?"

MVP 출시 직전, 유저 0명 상태에서 PRD 양식의 "KPI" 칸을 보며 팀 논의에서 내가 꺼낸 말이다. 임의 수치를 적어봐야 무엇을 개선할지 기준이 되지 못하고, 그렇다고 비워두면 출시 후 무엇을 볼지 팀 내 합의가 없다.

상황

버짓로드(Budget Road)는 결혼 예산을 간이 시뮬레이션해주는 MVP다. 1차 사이클은 "우리가 정한 문제가 진짜 문제인지"를 확인하는 단계라, 출시 전에는 유저 데이터도 비교 대상도 없다. 그런데 PRD에는 KPI와 성공 지표를 써야 했다.

과제

선택지는 세 가지였다.

1. 임의로 KPI를 정한다 — 기준이 없으니 달성/미달성 판단이 성립하지 않는다.

2. KPI 칸을 비운다 — 출시 후 무엇을 봐야 할지 합의가 없다.

3. 측정 가능한 상태를 먼저 만든다 — "이 행동을 이 기준으로 본다"까지 구체화한 뒤, 수치는 관찰로 결정한다.

팀 논의 끝에 3번으로 갔다.

행동

임의 지표를 세우는 대신, 우리가 의도한 사용자 행동을 관찰할 수 있는 인프라를 먼저 짓는다.

이 결정 이후 나흘 동안 네 가지를 했다.

1. 비로그인 방문자 식별 — src/lib/visitor.ts에 crypto.randomUUID() 기반 visitor_id를 localStorage에 저장. 로그인 없이도 재방문자를 구분할 수 있는 최소 인프라. 브라우저/기기 변경 시 다른 사용자로 잡히는 한계는 받아들이고, MVP 단계에 맞는 트레이드오프로 기록했다.

2. 퍼널 이벤트 자동 보강 — 모든 trackEvent() 호출에 visitor_id와 is_returning: "yes"/"no"를 자동으로 끼워 넣도록 gtag.ts를 수정. 이벤트를 보낼 때마다 "누가 보냈고 첫 방문인지"가 함께 찍힌다.

3. 어떤 행동을 볼 건지 스펙 문서화 — /prd-onepager 원페이저 PRD 스킬을 만들어 대시보드 스펙을 5질문(목적/요구사항/성공지표/기술방향/제외범위)으로 정리. 전환 3개, 리텐션 3개, 공유 의도 2개, 행동 패턴 4개, 효율 2개, 분포 2개 — 총 16개 지표를 "이 행동 → 이 식"으로 적었다.

4. 로드맵 구조 재정리 — ROADMAP에 "운영/도구 레이어" 섹션을 신설해서, 측정이 사용자 경험과 별개의 축임을 명시. 제품 경험 레이어 안에 섞어두면 측정은 항상 후순위로 밀린다.

다른 선택지로 GA4만 쓰기도 고려했다. 자체 이벤트 수집 인프라를 짓지 않고 GA4의 기본 지표 + 커스텀 이벤트로 끝내는 길. 포기하지는 않았다. GA4가 "우리가 원하는 사용자 행동 단위"로 쪼개서 보여줄 수 있는지 아직 확신이 없어서, 일단 자체 이벤트를 쌓을 수 있는 구조부터 세워두고 GA4의 한계가 어디까지인지 관찰하며 결정하기로 했다.

결과

• visitor_id + is_returning 측정 로직 배포 완료 → 재방문율을 셀 수 있는 상태

• 16개 지표 스펙 + 이벤트 스키마 3안 비교 문서(플랫 JSON / 정규화 / 하이브리드) 완료, 옵션 A(플랫 JSON 단일 테이블) 잠정 채택

• 자체 대시보드의 실제 구축 여부는 아직 판단 중 — GA4로 어디까지 가능한지 먼저 검증한 뒤 gap을 채울 예정

회고

지표는 "뭘로 정할지"가 아니라 "뭘 볼 수 있는 상태인지"가 먼저다. 지표 정하기 전에 측정 인프라가 있어야 그 지표가 의미를 갖는다는 것을 이번 사이클에서 배웠다.

다시 한다면 GA4 커스텀 차원으로 어디까지 할 수 있는지부터 확인했을 것 같다. 자체 수집 레이어를 처음부터 짓지 않고, GA4로 커버되는 구간과 안 되는 구간을 먼저 나눈 뒤 gap만 자체로 채우는 순서. 지금은 "GA4도 쓰고 자체도 짓는" 중복이 있어서, 이게 MVP 단계에서 낭비인지 보험인지 2차 사이클에 판단할 지점이다.

지표가 안 잡힐 때는, 지표가 아니라 "측정 가능한 상태"를 먼저 의심해보자.

AI 피드백 (3렌즈 역량 리뷰)

이 글을 Claude가 PM·AI PM·Data PM 역량 관점에서 검토한 리뷰입니다.

공개된 피드백 루프로 성장 과정을 함께 기록합니다.

PM 렌즈

• 강점 [역량 6 · 시스템설계역량]: 추상 원칙("측정은 경험과 별개 레이어")을 말·글로 두지 않고 ROADMAP의 "운영/도구 레이어" 섹션으로 조직 구조에 반영한 것. 생각을 구조에 새겨넣는 움직임은 주니어 PM이 자주 놓치는 지점이다.

• 성장 포인트 [역량 5 · 실행력역량]: "GA4 한계부터 먼저 확인했어야" 회고는 맞지만 검증 순서의 실행 계획이 빠져 있다. 다음 글에선 "GA4 커스텀 이벤트 3개 이번 주 내 생성 → 4월 말까지 데이터 수집 → 자체 대시보드 구축 여부 결정"처럼 시간·액션 묶음으로 회고를 내려놓는 연습.

AI PM 렌즈

• [역량 1 · AI네이티브업무역량]: /prd-onepager 스킬 직접 제작 → AI를 "글 써주는 도구"가 아닌 "PRD 생산 레이어"로 제품화한 움직임. 다만 글에선 "스킬을 만들었다"로 얕게 지나갔다. "왜 one-pager에 '성공지표' 섹션을 추가했는지"(실리콘밸리 사례들이 빠뜨린 지점 보완) 같은 설계 의도를 드러내면 "스킬 사용자"가 아니라 "스킬 설계자"로 읽힌다.

• [역량 4 · AI측정역량]: 16개 지표엔 현재 AI 기능이 없지만, 다음 사이클에 AI 기능(추천·개인화) 붙일 때를 대비해 이벤트 스키마에 source: "ai" | "rule" 류 필드를 미리 넣어두면 나중에 리팩토링 없이 AI 효과 측정 가능.

Data PM 렌즈

• [역량 6 · 지표분류역량]: 16개 지표를 나열했지만 "가설 검증용 vs 운영 모니터링용" 구분이 없다. MVP 단계에선 두 종류의 우선순위·해석이 다르다. "전환 3개 = PDD 가설 검증 / 리텐션 3개 = 운영 모니터링"으로 분류해두면 다음 사이클 의사결정 속도가 올라간다.

• [역량 4 · 데이터해석역량]: visitor_id의 "기기 변경 시 다른 유저" 한계를 받아들인다고 썼는데, 이 노이즈가 재방문율에 얼마나 영향을 주는지 상한치를 추정(예: "국내 예비부부 1인 평균 2기기 → 재방문율 최대 50% 과소 추정 가능")해두면 숫자 해석 왜곡 방지.

"지표는 뭘로 정할지가 아니라, 뭘 볼 수 있는 상태인지가 먼저예요." 오늘 소개한 수강생이 직접 얻은 교훈이에요.

완벽한 KPI를 정하려다 아무것도 못 보는 것보다, 측정할 수 있는 상태를 먼저 만드는 것 — 이게 데이터 기반으로 제품을 키우는 첫걸음이에요.

이론이 아닌 실제 프로젝트로 이 과정을 직접 밟아볼 수 있는 곳, 멋쟁이사자처럼 AI PM 부트캠프가 함께할게요.