런칭 데이의 스파이크 뒤에 D2 급락, D30 소멸. 초기 스타트업에서 이 패턴은 “유저가 부족해서”가 아니라 “유저가 돌아올 이유가 없어서” 생깁니다. dev.to의 ‘첫 1,000명 리텐션’ 글이 말하듯, 코드가 동작하는 것과 습관이 형성되는 건 완전히 다른 게임입니다. CAC는 돈으로 버틸 수 있지만, 초기 리텐션 붕괴는 퍼널 전체를 무너뜨립니다.
핵심은 문제를 ‘기능 부족’으로 오진하지 않는 겁니다. 이탈은 대개 네 갈래로 갈립니다: (1) 가치를 못 찾음(온보딩), (2) 한 번 쓰고 끝(리텐션 루프), (3) 느림/버그/혼란(품질), (4) 기대와 다름(포지셔닝). 서로 다른 처방전이 필요한데도, 많은 팀이 기능을 더 얹다가 실험 속도만 잃습니다.
초기 리텐션 루프의 첫 단추는 ‘Aha까지의 시간’을 10분 안에 가두는 것입니다. 가입 60초, 셋업 5분, 첫 가치 10분 같은 기준은 단순하지만 강력합니다(출처: dev_to). 빈 대시보드와 과도한 입력 폼은 곧바로 이탈로 이어지니, 샘플 데이터/템플릿/단일 CTA로 사용자를 “핀(가치)”까지 굴려 보내야 합니다. 온보딩은 설명이 아니라 ‘진행’이 목적입니다.
하지만 Aha만으로는 재방문이 안 됩니다. 그래서 훅(Trigger–Action–Variable Reward–Investment) 루프를 의도적으로 설계해야 합니다. 외부 트리거(메일/푸시)로 시작하되, 궁극적으로는 사용자의 일상 상황이 내부 트리거가 되어야 합니다. 액션은 1클릭이어야 하고, 보상은 ‘매번 조금 달라야’ 합니다(정보/사회적 반응/진척감). 마지막으로 투자(데이터, 설정, 연결, 평판)가 쌓여야 다음 트리거가 더 강해집니다. 이 네 조각 중 두 개만 비어도 D7은 버티기 어렵습니다.
여기서 AI 시대의 변수가 하나 더 들어옵니다. velog 글이 지적하듯, 실행은 빨라졌는데 의사결정이 느리면 실험 throughput이 막힙니다. 리텐션은 ‘주 단위 개선’이 아니라 ‘일 단위 루프’로 겨뤄야 하는데, 승인 대기와 보고 직렬화가 남아 있으면 온보딩/트리거/보상 같은 작은 레버가 제때 못 돌아갑니다. 결국 리텐션 설계는 제품 문제이면서, 동시에 조직 구조 문제입니다.
시사점은 명확합니다. 첫째, 리텐션 진단을 인터뷰와 데이터로 분리해 잡으세요: 이탈 유저 5~10명에게 “가입 후 무슨 일이 있었는지”를 재생시키고(dev_to의 Mom Test식 질문), 세션 리플레이/에러 로그/로딩 지표로 ‘품질 이탈’을 걸러냅니다. 둘째, 북극성 지표를 D1/D7과 ‘Time-to-Aha’로 고정하고, 온보딩/훅 루프를 A/B 가능한 모듈로 쪼개세요. 셋째, 조직은 ‘임무형’으로 바꿔야 합니다: 리텐션 개선 미션(예: D7 +5pp)과 가드레일(브랜드/법무/비용 한도)만 주고, 실행 셀은 승인 없이 실험을 병렬로 돌리게 해야 합니다(출처: velog).
전망은 더 냉정합니다. 빌드는 계속 싸지고 빨라져 MVP는 넘쳐날 겁니다. 차이는 ‘재방문을 만드는 루프를 얼마나 빨리 설계·학습하느냐’에서 벌어집니다. 초기 1,000명은 마케팅 자산이 아니라 실험용 센서입니다. D2에서 죽는 제품을 살리는 팀은, 훅 루프를 그릴 줄 아는 팀이 아니라 그 루프를 매일 업데이트할 수 있는 의사결정 구조를 가진 팀입니다.