MVP 개발 기간은 어디서 늘어나나

기간을 묻기 전에 정할 한 가지

MVP 개발을 문의하면 기간부터 궁금한 게 당연하다. 그런데 같은 기능 목록을 여러 곳에 보내도 돌아오는 예상 기간은 제각각이다. 기능 개수만으로는 기간이 정해지지 않는다. MVP는 정식 서비스를 작게 줄인 판이 아니라 가설을 확인하는 도구다. “이 서비스에 돈을 낼 사람이 있는가”를 알아보는 최소한의 제품과 “정식으로 공개해도 부끄럽지 않은 첫 버전” 사이에는 작업량 차이가 크다.

정할 것은 하나다. 이번 버전으로 무엇을 확인하려는가. 확인할 대상이 분명하면 만드는 쪽도 “그 목적이라면 이 화면과 기능만 있으면 된다”고 범위를 좁힌다. 가설이 비어 있으면 기능 목록은 계속 늘어나고, 기간은 그 목록을 따라간다.

첫 버전에서 뺄 것을 먼저 고른다

목록을 다시 보면 지금 안 만들어도 되는 항목이 꽤 나온다. 관리자 화면이 대표적이다. 초기에는 주문이나 신청을 스프레드시트로 받아 사람이 직접 처리해도 굴러간다. 소셜 로그인 세 종류를 붙이는 대신 이메일 로그인 하나로 시작해도 되고, 다국어와 알림·정산 자동화는 사용자가 늘기 전까지 사람이 대신 맡으면 된다.

기능을 뺀다고 대충 만든다는 뜻은 아니다. 사용자가 직접 겪는 화면과 흐름이 엉성하면 가설 검증 자체가 안 된다. 줄일 대상은 운영 편의를 위한 기능과 만일에 대비한 기능이다. 사람 손으로 처리할 수 있는 일은 자동화를 미루고, 아낀 시간을 사용자가 만나는 앞면에 쓴다.

일이 시작되면 답장 속도가 일정을 만든다

작업이 굴러가기 시작하면 일정을 밀어내는 건 대개 코드가 아니다. 시안을 보내고 확인을 기다리는 며칠, 문구를 확정받기까지 걸리는 며칠이 쌓이면 일정은 주 단위로 밀린다. 만드는 쪽은 결정이 오지 않으면 다음 화면으로 넘어갈 수 없다. 그 대기 시간은 고스란히 개발 기간에 붙는다.

확인 주기를 미리 정하고 결정할 사람을 한 명으로 좁히면 이 지연은 크게 줄어든다. 매주 같은 요일에 그 주에 만든 결과를 보고 그 자리에서 결정하면 피드백이 밀리지 않는다. 결정권자가 여럿이면 서로 다른 의견을 맞추는 데 시간이 더 든다. 이 단계에서는 완벽한 결정보다 빠른 결정이 일정에 더 크게 작용한다.

스토어 심사와 결제 계약은 남의 달력이다

개발이 끝났는데도 서비스를 열지 못하는 일이 생긴다. 앱은 스토어 심사를 통과해야 하고, 반려되면 고쳐서 다시 줄을 선다. 결제를 받으려면 결제대행사 계약과 심사를 따로 거치고 사업자 서류도 갖춰야 한다.

이 일정은 만드는 쪽이 당길 수 없다. 개발 기간 안에 들어 있다고 계산하면 실제 공개 날짜가 어긋날 수 있다.

그래서 이런 절차는 개발 첫 주에 같이 걸어 둔다. 결제대행사 신청, 스토어 계정 개설, 필요한 서류 준비를 화면 작업과 나란히 굴리는 식이다. 외부 서비스 연동도 마찬가지다. 붙일 서비스가 정해져 있다면 견적 단계에서 이름을 함께 적어 보내면 된다. 연동 문서가 부실하거나 별도 승인 절차를 요구하는 서비스는 그 자체로 일정 변수가 된다.

공개 날짜가 먼저 정해져 있다면

열고 싶은 날짜가 이미 잡혀 있다면 그 날짜부터 알려주셔도 됩니다. 확인하려는 가설이 아직 한 문장으로 안 잡혔어도 괜찮습니다. 위플의 MVP 개발은 이번 버전으로 확인할 것을 먼저 맞춘 뒤, 기간을 고정해 두고 그 안에 들어갈 범위를 짜는 순서로 진행합니다. 만들 기능 목록이 이미 있다면 첫 버전에서 뺄 항목을 함께 골라 봅니다. 금액이 어떤 기준으로 매겨지는지는 가격 안내에 적어 두었고, 스토어 심사나 결제 계약처럼 밖에서 도는 일정까지 넣어 첫 일정표를 같이 그립니다.