Showing Posts From

마디로

MVP 한 마디로 프로젝트가 살아난다

MVP 한 마디로 프로젝트가 살아난다

MVP 한 마디로 프로젝트가 살아난다 대표님의 10개 피처 월요일 오전 10시. 기획 검토 미팅. 대표님이 말했다. "이번 릴리즈에 이거 다 넣으면 좋겠는데." 화면을 보니 피처가 10개다.소셜 로그인 3종 추가 알림 설정 상세화 프로필 편집 고도화 추천 알고리즘 개선 채팅 기능 결제 수단 추가 다크모드 언어 설정 튜토리얼 리뉴얼 통계 대시보드개발 기간은 6주. 나는 계산했다. 이거 다 하려면 최소 4개월이다.첫 반응 "네, 검토해보겠습니다." 회의실 나왔다. 개발팀장한테 슬랙 보냈다. "10개 피처, 6주. 가능?" 답장은 5초 만에 왔다. "ㅋㅋㅋㅋㅋ 농담이죠?" 디자이너한테도 물었다. "UI 작업만 2개월이요." 예상했다. 이제 대표님을 설득해야 한다. 어떻게? "안 됩니다" 는 답이 아니다. 대안을 줘야 한다. 그게 MVP다. MVP가 뭔데 Minimum Viable Product. 최소 기능 제품. 핵심만 남긴 버전이다. 10개 피처 중에서 진짜 필요한 거. 유저가 당장 써야 하는 거. 나머지는 다음 스프린트. 이게 스코프 관리의 핵심이다. 나는 회의록을 다시 봤다. 10개 피처의 목적을 정리했다.소셜 로그인: 가입률 올리기 (중요도 상) 알림 설정: 이탈 방지 (중) 프로필 편집: 사용성 개선 (중) 추천 알고리즘: 체류시간 증가 (상) 채팅: 커뮤니티 활성화 (하, 아직 유저 적음) 결제 수단: 매출 (상) 다크모드: 요청 많음 (하, 급하진 않음) 언어 설정: 해외 진출 (하, 올해 계획 없음) 튜토리얼: 신규 유저 온보딩 (중) 통계 대시보드: 내부 운영용 (하)가입률, 매출, 추천. 이 3개가 핵심이다. 나머지는 좋으면 좋은 거다. 없어도 서비스는 돌아간다.대표님 설득법 다음날 미팅을 다시 잡았다. 준비물:우선순위 매트릭스 개발 공수 추정 릴리즈 로드맵 (3개 버전)"대표님, 검토했습니다." 화이트보드에 표를 그렸다. 중요도 vs 긴급도[높음/높음] [높음/낮음] 소셜로그인 알림설정 결제수단 프로필편집 추천알고리즘 튜토리얼[낮음/높음] [낮음/낮음] (없음) 채팅 다크모드 언어설정 통계대시보드"10개 다 하면 4개월입니다. 6주 안에 하려면 3개만 가능합니다." 대표님 표정이 굳었다. "그럼 나머지는 언제?" "일단 MVP로 가시죠. 소셜로그인, 결제수단, 추천 알고리즘. 이 3개만 6주 안에 릴리즈합니다." "나머지 7개는?" "버전을 나눕니다. v1.1에 중요도 중간인 것들, v1.2에 나머지." 화이트보드에 타임라인을 그렸다.v1.0 (6주): 소셜로그인 + 결제 + 추천 v1.1 (8주 후): 알림 + 프로필 + 튜토리얼 v1.2 (12주 후): 채팅 + 다크모드 + 언어 + 통계"이렇게 하면 6주 안에 핵심 기능은 나갑니다. 매출도 올리고, 가입률도 높이고." 대표님이 잠시 생각했다. "채팅은 왜 나중에?" "지금 DAU가 500명입니다. 채팅 쓸 사람이 없어요. v1.1로 유저 늘리고 나서 넣는 게 맞습니다." "다크모드는?" "요청이 30건이에요. 전체 유저 5000명 중 0.6%. 우선순위가 낮습니다." 숫자로 말하니까 설득이 됐다. "알겠어. MVP로 가자." MVP의 힘 이 한 마디가 프로젝트를 살렸다. 10개 피처를 6주에 하면 어떻게 됐을까?개발팀 번아웃 QA 시간 부족 버그 투성이 릴리즈 유저 불만 폭증 결국 핫픽스 지옥실제로 전 회사에서 겪었다. 대표님이 "다 넣어" 해서 다 넣었다. 릴리즈 당일 서버가 터졌다. 앱스토어 리뷰 평점이 4.2에서 2.8로 떨어졌다. 복구하는 데 3개월 걸렸다. 그때 배웠다. 스코프 관리는 협상이 아니다. 생존이다.MVP 정하는 법목적을 먼저 정한다피처가 아니라 목표다. "채팅 기능을 넣는다" (X) "유저 체류시간을 20% 늘린다" (O) 목표가 명확하면 피처는 자동으로 정해진다. 채팅이 정말 체류시간을 늘릴까? 데이터는? 가설은? 이렇게 물으면 우선순위가 보인다.임팩트 vs 공수가로축: 비즈니스 임팩트 세로축: 개발 공수 [높은 임팩트 / 낮은 공수] → 당장 해라 [높은 임팩트 / 높은 공수] → MVP로 쪼개라 [낮은 임팩트 / 낮은 공수] → 시간 나면 해라 [낮은 임팩트 / 높은 공수] → 하지 마라 소셜 로그인: 높은 임팩트 / 중간 공수 → MVP 포함 다크모드: 낮은 임팩트 / 중간 공수 → 제외 이게 합리적 판단이다.유저 관점에서 생각한다내가 유저라면 뭐가 제일 필요할까? 이번 프로젝트의 타겟 유저는 "처음 가입하는 사람"이었다. 그럼 소셜 로그인은 필수다. 회원가입 장벽을 낮춰야 한다. 채팅? 친구도 없는데 누구랑 채팅해? 다크모드? 일단 가입부터 하고 나서 생각할 문제다. 유저 여정을 그려보면 답이 나온다.데이터로 검증한다감이 아니라 숫자다. "다크모드 요청이 많아요" → 몇 건? "채팅이 필요해요" → 사용률 예측은? "추천 알고리즘이 중요해요" → 현재 클릭률은? 구글 애널리틱스, 믹스패널, 앰플리튜드. 데이터를 보면 우선순위는 명확해진다. 실제로 알림 설정은 데이터 보고 v1.1로 밀었다. 현재 알림 수신율이 72%였다. 충분히 높았다. "알림 상세 설정"은 급한 게 아니었다. 개발팀 반응 개발팀장이 말했다. "10개에서 3개로 줄여줘서 고맙습니다." 진심이었다. 개발자는 완성도를 원한다. 대충 10개보다 제대로 3개가 낫다. 프론트엔드 개발자도 좋아했다. "소셜 로그인 3종만 하면 되니까 OAuth 제대로 구현할게요." 백엔드 개발자는 이렇게 말했다. "추천 알고리즘에 집중할 수 있어서 좋네요. A/B 테스트도 붙일게요." QA 담당자도 만족했다. "3개면 테스트 케이스 제대로 짤 수 있어요." 모두가 행복한 스코프. 이게 MVP의 힘이다. 디자이너 입장 디자이너도 스코프가 줄어서 좋아했다. "10개 화면 러프하게 그리는 것보다, 3개 화면 디테일 잡는 게 낫죠." 실제로 소셜 로그인 화면은 A안, B안, C안까지 뽑았다. 유저 테스트도 했다. 결제 화면은 UX 라이팅까지 신경 썼다. "결제하기" 대신 "3,000원 결제하기". 전환율이 8% 올랐다. 10개 피처를 급하게 했으면 이런 디테일은 불가능했다. MVP는 퀄리티를 보장한다. 릴리즈 결과 6주 후. v1.0이 나갔다. 3개 피처만 들어갔지만 반응은 좋았다.소셜 로그인: 가입률 32% 상승 결제 수단: 첫 주 매출 47% 증가 추천 알고리즘: 평균 체류시간 6분 → 9분앱스토어 리뷰에 이런 댓글이 달렸다. "업데이트 후 진짜 편해졌어요. 카카오로 바로 가입했습니다." "결제가 이제 되네요. 기다렸어요." "추천이 정확해요. 계속 보게 되네요." 3개만 했는데 만족도는 높았다. 왜? 제대로 했으니까. 대표님도 만족했다. "다음은 v1.1 준비하자. 잘했어." MVP로 일하는 법 이제 나는 모든 프로젝트에 MVP를 적용한다.피처 리스트를 받으면 일단 질문한다"이 기능의 목적이 뭐죠?" "유저가 정말 원하나요?" "데이터 있나요?" "안 하면 어떻게 되죠?" 질문하면 절반은 우선순위에서 빠진다.Must Have / Should Have / Nice to Have피처를 3단계로 나눈다. Must: 없으면 서비스가 안 됨 Should: 있으면 좋음 Nice: 나중에 해도 됨 Must만 MVP에 넣는다.로드맵을 그린다v1.0, v1.1, v1.2. 이렇게 버전을 나누면 대표님도 이해한다. "일단 v1.0 나가고, 다음 거는 8주 후에요." 시간 축이 명확하면 협상이 쉽다.개발팀과 미리 소통한다기획서 쓰기 전에 개발팀장한테 물어본다. "이거 공수 얼마나 나올 것 같아요?" 대략적인 추정치를 받는다. 그걸 기반으로 스코프를 조정한다. 나중에 "이거 안 돼요" 듣는 것보다 훨씬 낫다.데이터를 모은다구글 애널리틱스, 유저 인터뷰, CS 문의 내역. "요청이 많아요" 말고 "246건 요청 들어왔어요" 라고 말한다. 숫자가 있으면 설득력이 생긴다. 실패 사례 물론 실패도 있었다. 작년에 채팅 기능을 MVP에 넣었다. 대표님이 강하게 원했다. "경쟁사는 다 있어." 나는 밀어붙였다. MVP에 포함시켰다. 결과? 개발 기간 8주 → 12주로 늘어남. 릴리즈 후 채팅 사용률 3%. 유저들은 채팅을 안 썼다. 왜? 우리 서비스는 커뮤니티가 아니었다. 정보 검색 앱이었다. 채팅이 필요 없었던 거다. 나는 데이터를 무시하고 대표님 의견을 따랐다. 실수였다. 그 이후로 나는 더 단호해졌다. "근거가 없으면 MVP에 안 넣습니다." MVP는 타협이 아니다 처음엔 생각했다. MVP는 어쩔 수 없이 줄이는 거라고. 아니다. MVP는 전략이다. 핵심에 집중하는 전략. 10개를 대충 하는 것보다, 3개를 제대로 하는 게 낫다. 유저도 그걸 안다. "이것저것 다 있는데 다 별로" 보다 "기능은 적은데 하나하나 완벽해" 가 낫다. 애플이 그렇게 일한다. 아이폰 첫 버전에는 복붙도 없었다. MMS도 안 됐다. 하지만 터치 인터페이스는 완벽했다. 그래서 성공했다. 지금도 오늘도 대표님이 말했다. "이번 분기에 이거 5개 넣을 수 있지?" 나는 웃으며 말했다. "일단 MVP로 가시죠. 2개만 제대로 합시다." 대표님도 이제 안다. 내가 왜 이러는지. "알았어. 네 말대로 하자."MVP 한 마디로 프로젝트가 산다. 스코프 관리는 협상이 아니라 생존이다.