6년차 개발자의 MVP 앱 개발 망해본 경험담
지금은 프로 개발자이지만, 나도 한때는 보기좋게 망해버린 시절이 있었다
안녕하세요!!!
오늘도 찾아온 6년차 개발자 개발빔입니다~ㅎㅎ
오늘은 MVP 개발을 하다가 한 번 제대로 말아먹었던 경험을... 얘기해보려고 합니다...하핫
MVP 개발이 왜 망하는지, MVP 실패를 어떻게 막을 수 있을지
제 경험을 토대로 말씀드리겠습니닷 :)
MVP 개발 이렇게 시작했습니다.
저는 저의 개인적인 사이드 프로젝트를 위해서 MVP를 만들기로 했었는데요,
그때의 목표는 단순했습니다.
빠르게 MVP를 만들고, 실제 사용 반응을 보고, 다음 버전을 결정하자!
그래서 기능 범위를 최대한 줄였습니다.
로그인, 핵심 기능 1개, 간단한 관리 기능 정도로 끝내자고 합의했습니다...!!
개발 일정도 짧게 잡혔고, 저도 익숙한 스택이라
MVP 개발 속도는 꽤 잘 나오는 편이었습니다.
문제는 여기서부터였습니다.
기능을 줄였다는 이유로, 구조까지 줄여도 된다고 착각했습니다ㅎㅎ
전 정말 바보였나봅니다. ^^;
MVP 기획 단계에서 상태값, 권한, 운영 흐름을 최소한으로라도 확정하지도 않고
일단 개발을 시작했습니다~!!!
그렇게 겪게 된 MVP 실패...
배포 직후부터 조~용 했습니다.
사용자가 적고, 데이터도 전혀 쌓이지 않았기 때문이죠.
그런데 첫 사용자 피드백이 들어오자마자 운영 요청이 터지기 시작했습니다...!!
어떤 요청이었냐면, 아주 사소한 것들이었습니다.
특정 사용자의 상태만 바꾸고 싶다, 특정 데이터만 숨기고 싶다,
실수로 등록된 값을 되돌리고 싶다 같은 간단한 것들이었습니다.
그런데 관리자 화면이 없었습니다.
운영자가 직접 바꿀 수 있는 영역이 없었고,
결국 개발자가 DB를 만지거나 코드 수정으로 모든 걸 해결해야 했습니다.
상태값도 애매했습니다.
진행 중인지, 완료인지, 보류인지가 코드 곳곳에 흩어져 있었고,
케이스가 늘수록 분기만 늘었습니다 ㅠㅠ
이때부터 MVP 개발 비용이 빠르게 증가했습니다.
기능 추가가 아니라, 수정과 운영 대응이 비용을 키웠습니닷 하하
MVP 실패 신호 이렇게 다가온다.
망하기 시작하면 공통적으로 보이는 신호가 있습니다ㅎㅎ
특히 MVP 개발 일정이 촉박할수록, 아래 신호가 더 빨리 나타납니다 ㅠㅠ
저는 그때 이 신호를 무시했고, 그게 아주 치명적이었습니다...
운영 요청이 기능 추가보다 더 자주 들어오는 상황
같은 버그가 상태 케이스만 바꿔서 계속 반복되는 상황
작은 수정이 배포와 데이터 수정까지 항상 동반되는 상황
이 세 신호가 동시에 보이면,
이때부터는 MVP 개발 견적이든 내부 리소스든, 예상보다 훨씬 빠르게 소진됩니다.
MVP 앱 개발 망했던 이유는?
MVP 기능이 적었던 건 전혀 문제가 되지 않습니다.
문제는 MVP 개발 구조가 운영을 버티지 못하도록 설계되어 있었다는 점입니다 ㅠㅠ
정확히는 세 가지가 동시에 비어 있었습니다.
첫째, 데이터 구조 기준이 없었습니다.
필드 추가와 변경이 잦아지면서 화면과 API가 같이 바뀌었습니다...
둘째, 상태값 정의가 없었습니다.
화면은 같아 보이는데 처리 규칙이 매번 달라져서 버그가 반복됐습니다 ㅠㅠ
셋째, 운영 권한과 책임이 없었습니다.
운영자가 할 일을 개발자가 대신하면서, MVP는 검증이 아니라 유지보수 중심으로 바뀌었습니다,,,
이 조합이 만들어내는 결과는 단순합니다.
MVP가 성장하는 속도보다, 수정 비용이 커지는 속도가 더 빨라집니다 ㅠㅠ
그리고 어느 순간 팀은 기능 실험을 못 하고, 급한 수정만 하게 됩니다.
MVP 실패, 피할 수 있는 방법은?
MVP를 실패 없이 제대로 개발하기 위해서 필요한 준비를 모두! 알려드리겠습니다...
망하는 건 저만으로도 충분하니까요~^^
1. 상태값 정의 최소화
상태값은 많을수록 어렵고, 없을수록 더 위험합니다 ㅠㅠ
최소한 진행, 완료, 중단 같은 단계는 확정하고,
화면과 API에서 같은 이름으로 쓰는 것부터 시작합니다.
2. 운영 화면 최소 구성
운영 화면은 크게 만들 필요가 없습니다ㅎㅎ
다만 운영자가 자주 요청할 것 같은 변경 2~3개는 화면으로 빼야 합니다.
이게 없으면 MVP 외주개발이든 내부 개발이든, 운영 요청이 전부 개발 티켓으로 쌓입니다 ㅠㅠ
3. 권한과 책임 분리
누가 무엇을 바꾸는지 정해두면, MVP 개발 속도가 오히려 안정됩니다ㅎㅎ
운영이 바꾸는 영역, 개발이 바꾸는 영역을 분리해두면 긴급 대응이 줄어듭니다!
4. 버릴 MVP와 이어갈 MVP 구분
이 MVP를 다음 버전으로 이어갈 건지, 검증 후 폐기할 건지부터 정해야 합니다 ㅠㅠ
이어갈 가능성이 있다면 데이터 구조와 상태값은 처음부터 더 신경 써야 합니다 :)
MVP 개발에도 파트너가 필요합니다.
제가 직접 경험해 본 결과 MVP 개발, 정말 쉬워보이지만
개발자 혼자서는 말도 안되게 어렵다는 걸 알게됐습니다.
(왜 저는 이걸 해보고 나서야 알았을까요?)
일정은 촉박하고, 내부 리소스는 부족하니까!
저같은 사이드 프로젝트를 하시는 분들이 아니라면
외주개발을 통해서 MVP를 만드시는 경우도 있을텐데요,
외주개발사 선택... 정말 중요합니다 ^^
개발자를 뽑는 것보다는 간단해서 MVP 제작에는 당연히 훨씬 잘 맞습니다만,
외주개발로 MVP 제작을 진행해도 저랑 같은 이유로 망하는 분들도 많습니다.
이렇게 망하지 않기 위해서는
제 경험상 이걸 꼭 확인하셔야 합니다.
"운영"을 고려해 MVP를 개발하는가?
"운영"까지 제대로 책임져 줄 수 있는 외주개발사인가?
개발만 해주는 곳이 아니라, MVP 개발 구조와 운영 기준을 같이 잡아주는 곳이어야 합니다!(반.드.시)
외주개발사 똑똑한개발자를 추천드립니다.
외주개발사 똑똑한개발자는 기획부터 디자인, 개발, 운영까지 책임지는 턴키형인데요,
기획 단계부터 운영을 고려하는 곳이기 때문에 제가 말씀드렸던
MVP 실패의 리스크가 굉장히 적습니다...
저도 사내 프로젝트를 진행할 때 한 번 똑똑한개발자와 협업했던 경험이 있습니다.
(물론 이 프로젝트는 MVP를 만드는 프로젝트는 아니었지만...)
제가 개인적으로 매우 인상 깊었던 것은 커뮤니케이션이었는데요,
그냥 무작정 기능을 추가하는 방향보다는
정말 필요하고 필요하지 않은 기능을 현실적으로 분류해주셨습니다.
무작정 기능을 추가하기보단, 기획 단에서 기준을 세워서 정리해주시더라고요...
그리고 그 과정에서 비개발자도 이해하기 쉽게 설명해주셨는데요,
애초에 기획이랑 개발이 같은 그림을 보게 만드는 방식이었다고 생각합니다!
(MVP개발 성공적으로 하시길 원하신다면 아래 링크로 똑똑한개발자를 한 번 찾아보시길...)
그래서 저도 뭔가 만들 일이 있다면
무작정 혼자 만들어서 망하기보단...ㅋㅋ
'이렇게 경험이 많은 개발 파트너가 있어야 하는구나', 뼈저리게 느꼈답니다 ㅠㅠ
결국 만들고 끝이 아니라, 배포 이후부터가 시작이니까요!!
물론 보기좋게 망했던 경험이라
당시에는 꽤 크게 절망했었지만,...
지금 돌이켜보면 정말 저에게 뼈가 되고 살이 된 경험이었습니다 ^^!
앞으로 다시는 망하지 않으리라 다짐하면서 마무리하겠습니다.
댓글과 공감도 부탁드립니다~
감사합니다!
