[PM 회고록] 48시간 만에 만든 MVP를 내 손으로 폐기(Kill)한 이유

PM 포트폴리오를 준비하며 가장 경계해야 할 것은 "모든 프로젝트는 지표 우상향으로 끝난다"는 착각입니다. 현업에서 우리가 던지는 가설의 8할은 실패합니다. 중요한 것은 '얼마나 빠르고 싸게 실패하여 레슨런을 얻었는가'입니다.

최근 진행했던 부트캠프 수강생 이탈 방지 프로젝트인 'FlowCheck'를 통해 저는 이 뼈아픈 진리를 배웠습니다. 단 48시간 만에 배포한 MVP를 왜 제 손으로 직접 셧다운(Kill)했는지, 그 실패의 기록을 남깁니다.

1. 문제 정의: "지표는 좋은데 고객은 왜 떠나는가?"

팀스파르타 APM으로 활동하며 모순적인 데이터 패턴을 발견했습니다. 기수가 지날수록 수강생들의 NPS(순수고객추천지수)와 만족도는 평균 4.5점 이상으로 치솟았지만, 이탈률은 그에 비례해서 떨어지지 않고 18~20%대에서 정체되어 있었습니다.

데이터를 뜯어보고 이탈 수강생을 인터뷰하며 내린 결론은 명확했습니다.

• 후행 지표의 함정: 만족도와 NPS는 '이미 끝난 결과'를 보여주는 지표일 뿐, 진행 중인 이탈을 방어할 수 없었습니다.
• 조용한 이탈 : 이탈자들은 불만이 있어서 떠난 게 아니라, "평가받는 것 같아서", "나만 뒤처지는 것 같아서" 조용히 손을 놓고 있었습니다.

"수강생이 먼저 손을 들기 전에, PM이 선행 신호를 포착할 구조가 필요하다." 이것이 FlowCheck 기획의 시작이었습니다.

2. 가설과 실행: 개발 리소스 Zero, 48시간의 MVP

문제는 제게 타 부서의 개발 리소스를 끌어올 권한이 없다는 것이었습니다. 완벽한 시스템을 기다리다간 가설 검증 타이밍을 놓칠 것이 뻔했습니다.

그래서 AI(바이브 코딩)를 레버리지하여 직접 MVP를 띄우는 우회 전략을 택했습니다.

• Action: Spring Boot와 AWS 인프라를 활용, '수강생 학습 현황 자기보고 폼'과 'PM용 위험도 대시보드'를 단 48시간 만에 구축했습니다.
• 가설: "수강생이 매주 체감 난이도를 폼으로 제출하게 하면, PM이 이탈 고위험군을 3일 이내에 조기 발견하여 선제적 면담을 진행할 수 있을 것이다."

완성된 MVP를 즉시 현업 PM 10명에게 배포하며 가설 검증 사이클을 돌렸습니다.

3. 현실의 벽: 프로덕트의 치명적 맹점 2가지

하지만 실제 운영 데이터가 쌓이면서, 제 기획의 치명적인 구멍들이 드러났습니다.

① '자기보고' 데이터의 오염 가장 큰 문제는 '진짜 위험한 수강생은 폼에 진실을 적지 않는다'는 점이었습니다. 폼에 "어렵다"고 적는 수강생은 이미 살려달라고 신호를 보내는 관리 가능군이었습니다. 정작 '조용한 이탈군'은 폼을 아예 제출하지 않거나 "문제없음"으로 응답했습니다. 고객의 '말'보다 숨길 수 없는 '로그'를 신뢰해야 한다는 원칙을 간과한 결과였습니다.

② 스위블 체어 업무가 낳은 운영 병목 FlowCheck 대시보드는 사내 백오피스(LMS)와 연동되지 않은 독립된 MVP였습니다. 현업 PM들이 진짜 위험군을 찾으려면, 한 모니터에는 백오피스의 '과제 제출 현황'을 띄우고 다른 모니터에는 제가 만든 'FlowCheck 폼 응답'을 띄워 눈으로 VLOOKUP 하듯 대조해야 했습니다. 실무자에게 이런 인지적 부하를 강요하는 시스템은 지속 가능하지 않았습니다.

4. PM의 의사결정: 매몰 비용을 끊어내고 Kill을 선언하다

문제 해결을 위한 넥스트 스텝은 명확했습니다. 사내 백오피스의 정량 데이터(과제 지연)와 FlowCheck의 정성 데이터를 백엔드에서 통합해, 불일치가 발생할 때 슬랙 봇으로 자동 알럿을 쏘는 구조를 만들어야 했습니다.

하지만 여기서 PM으로서 스스로에게 질문을 던졌습니다. "부정확한 정성 데이터를 살리기 위해, 비싼 사내 개발팀의 귀중한 리소스를 투입해달라고 설득할 비즈니스적 타당성(ROI)이 있는가?"

제 결론은 'No'였습니다. 본질적으로 폼 응답의 신뢰도가 떨어지는 상황에서 시스템 연동은 '밑 빠진 독에 물 붓기'였습니다. 결국 저는 해당 MVP 프로젝트의 운영 중단을 결정했습니다.

5. Lesson Learned: 안 되는 걸 버리는 것도 기획이다

비록 FlowCheck는 극적인 이탈률 감소라는 성공 지표를 쓰진 못했지만, 제게 '진짜 PM의 시야'를 안겨주었습니다.

1. 가설 검증은 최대한 빠르고 싸게 할 것: 코딩이나 완벽한 앱에 집착하지 않고, AI를 툴로 활용해 48시간 만에 실무 테스트를 진행한 것은 가장 잘한 결정이었습니다. 덕분에 더 큰 리소스 낭비를 막았습니다.
2. 데이터는 '행동'이 우선이다: 고객의 의도를 파악할 때는 설문조사(정성)보다 고객이 직접 남긴 발자취(정량적 행동 로그)가 압도적으로 정확합니다.
3. 의도적인 실패도 역량이다: 매몰 비용의 오류에 빠지지 않고, 비즈니스 임팩트가 부족하다고 판단될 때 과감히 프로젝트를 셧다운 할 줄 아는 결단력이 필요합니다.

앞으로 어떤 프로덕트를 맡게 되더라도, 화려한 기능 추가보다 '우리가 이 문제를 풀기 위해 이 리소스를 쓰는 것이 맞는가?'를 가장 먼저 묻는 PM이 되겠습니다.