외주 계약서에 사인을 하고 나면 이상하게 불안해집니다. 비용과 기간은 합의했는데, 그 기간 동안 실제로 어떤 일이 벌어지는지는 아무도 상세히 알려주지 않습니다. "3개월 안에 출시합니다"라는 말 뒤에 숨어 있는 주차별 흐름을 모르면, 진척이 느린 건지 빠른 건지도 판단할 수 없습니다.
이 글은 그 불안을 없애기 위해 씁니다. MVP 프로젝트가 실제로 어떤 순서로 진행되는지, 각 단계에서 개발사는 무엇을 하고 창업자는 무엇을 준비해야 하는지 주차 단위로 정리했습니다.
주차별 분해 개요
린 MVP는 크게 네 단계로 구성됩니다. 기획·설계 → 핵심 개발 → 통합·테스트 → 출시 입니다. 규모에 따라 8~12주 사이에 이 사이클이 한 번 돌아가는 게 이상적입니다.
단, 실제 프로젝트는 요구사항 복잡도, 외부 API 연동 여부, 피드백 반영 속도에 따라 기간이 늘어날 수 있습니다. "N주면 충분하다"는 말보다 "현재 스코프라면 N주가 현실적이다"는 판단이 더 정확합니다.
아래 분해는 약 10~12주 규모의 Lean MVP를 기준으로 설명합니다.
1~2주차: 기획과 설계
이 구간에서 코드는 한 줄도 작성되지 않습니다. 대신 나중에 결정을 번복하지 않기 위한 기반을 쌓습니다.
요구사항 정의
창업자와 개발사가 함께 "무엇을 만들 것인가"를 명문화합니다. 여기서 중요한 건 기능 목록이 아니라 핵심 사용자 플로우입니다. 사용자가 앱에 들어와서 가장 먼저 해야 하는 행동이 무엇이고, 그 행동이 완료됐을 때 어떤 결과가 나와야 하는지를 1~3개 시나리오로 압축합니다.
이 단계에서 "나이스투해브" 기능을 과감히 쳐냅니다. MVP에서 빠지는 기능 목록을 명시하는 게 포함되는 기능 목록만큼 중요합니다.
화면 흐름과 데이터 구조
와이어프레임 수준의 화면 흐름을 확정합니다. 완성된 디자인이 아니어도 됩니다. 핵심은 "이 버튼을 누르면 어느 화면으로 이동하는가"를 개발자와 창업자 모두가 동일하게 이해하는 것입니다.
데이터 구조도 이 시점에 초안을 잡습니다. "사용자", "예약", "매장" 같은 주요 개체가 어떤 정보를 담고 서로 어떻게 연결되는지를 정합니다. 나중에 구조를 바꾸면 개발된 기능을 상당 부분 다시 짜야 하기 때문에, 이 결정은 빠를수록 좋습니다.
창업자가 이 기간에 해야 할 일: 피드백 속도입니다. 개발사에서 공유하는 화면 흐름안에 하루 이틀 안에 반응해야 합니다. 이 구간의 지연이 전체 일정을 가장 많이 밀어냅니다.
핵심 개발 단계
기획이 확정된 후 가장 긴 구간입니다. 전체 일정의 절반 이상을 차지합니다.
3~4주차: 기반 세팅과 핵심 플로우 시작
개발 환경 구성, 배포 파이프라인 세팅, 인증 시스템 구현이 먼저 이루어집니다. 눈에 잘 보이지 않는 작업이지만, 이후 모든 개발의 토대입니다.
인증이 완료되면 핵심 플로우의 첫 번째 화면부터 순서대로 구현을 시작합니다. 이 단계의 코드는 아직 투박합니다. UI 완성도보다 로직이 작동하는지를 우선 검증합니다.
5~7주차: 핵심 기능 완성
MVP의 핵심이 되는 기능들이 이 기간 안에 작동하는 상태가 되어야 합니다. 관리자 화면, 핵심 데이터 처리, 외부 서비스 연동(결제, 알림, 지도 등)이 이 구간에 포함됩니다.
스프린트 방식으로 운영하는 경우, 매주 또는 격주로 중간 시연이 진행됩니다. 시연에서 보이는 화면이 완성품처럼 보이지 않아도 괜찮습니다. 실제로 데이터가 저장되고 화면 간 이동이 되는지를 확인하는 게 목적입니다.
창업자가 이 기간에 해야 할 일: 중간 시연에 빠지지 않는 것, 그리고 피드백을 "이것도 추가해주세요"가 아니라 "이 기능이 없으면 출시 자체가 안 됩니다"와 "출시 후에 추가해도 됩니다" 두 가지로 구분해서 주는 것입니다. 이 구분이 일정을 지킵니다.
통합과 테스트
개발이 어느 정도 완성된 후, 각 기능들이 함께 제대로 작동하는지를 검증하는 구간입니다.
8~9주차: 기능 통합과 버그 수정
개별 기능이 합쳐졌을 때 생기는 문제를 이 시점에 잡습니다. 예를 들어 "예약 완료 후 알림이 발송되고, 관리자 화면에 실시간으로 반영되는가"처럼 여러 기능이 엮인 시나리오를 처음으로 통으로 테스트합니다.
이 구간에서 예상보다 많은 버그가 나오는 것은 정상입니다. 당황하지 않아도 됩니다. 오히려 이 시점에 버그가 나오는 게 출시 후에 나오는 것보다 훨씬 낫습니다.
크리티컬 버그(앱이 멈추거나 데이터가 잘못 저장되는 수준)는 즉시 수정합니다. UI가 살짝 어긋나거나 특정 엣지케이스에서만 발생하는 문제는 출시 후 패치로 넘기는 판단도 필요합니다.
성능 최적화, 보안 점검도 이 구간에 이루어집니다.
출시 주차
10~12주차: 최종 점검과 배포
실제 운영 환경(프로덕션 서버)에 배포합니다. 스테이징 환경에서 잘 작동하던 것이 실제 서버에서 다르게 동작하는 경우가 있기 때문에, 배포 직후 전체 플로우를 다시 한 번 직접 점검합니다.
iOS 또는 Android 앱이 포함된 경우 이 구간에 앱스토어 심사를 제출합니다. 심사 기간은 Apple 기준 평균 1~3일이지만 경우에 따라 더 걸릴 수 있습니다. 이 변수를 일정에 반영해야 합니다.
출시 직전 체크리스트:
- 이용약관·개인정보처리방침 페이지 존재 여부
- 오류 발생 시 대응 가능한 모니터링 설정
- 초기 사용자를 어떻게 유입시킬지 채널 준비
출시는 끝이 아닙니다. 실제 사용자가 들어오면서 예상치 못한 문제가 생기고, 그 피드백을 반영하는 다음 이터레이션이 시작됩니다.
패턴으로 보기
F&B 프랜차이즈의 실시간 예약·웨이팅 솔루션 (약 12주)
멀티 매장을 운영하는 F&B 프랜차이즈에서 이런 흐름이 자주 반복됩니다. 전화 예약과 수기 장부로 운영하다 보니 중복 예약과 누락이 쌓이고, 본사는 가맹점 전체 현황을 실시간으로 파악할 방법이 없습니다.
이때 목표는 대개 모바일 예약, 실시간 대기 순번 확인, 그리고 본사-가맹점 통합 대시보드 세 가지로 좁혀집니다.
진행 흐름:
- 1~2주차: 예약 플로우 정의. 고객 앱, 매장 앱, 관리자 대시보드라는 세 개 화면군을 확정. 데이터 구조(예약, 매장, 대기번호)를 이 시점에 설계.
- 3~6주차: 모바일 예약 UI, 대기 순번 실시간 업데이트 로직, 알림톡 연동 구현. 매장 앱의 예약 확인·처리 화면.
- 7~9주차: 본사 대시보드 통합. 전체 매장 예약 현황의 실시간 집계. 멀티 매장 환경에서의 데이터 동기화 검증.
- 10~12주차: 매장 파일럿 테스트, 운영 환경 배포, 초기 트러블슈팅.
이런 프로젝트가 대개 10~12주 안팎으로 걸리는 이유는 고객용·매장용·본사용, 세 개의 독립적인 화면군을 동시에 다루기 때문입니다. 화면군이 하나였다면 기간은 그만큼 줄어듭니다. 결과적으로 예약 처리 시간이 크게 줄고 중복·누락 예약이 거의 사라지는 것이 이 구조의 공통된 성과입니다.
무엇이 빠지는가
린 MVP 범위에서 의도적으로 제외되는 항목들이 있습니다. 이것들이 빠진다고 해서 출시가 불가능한 건 아닙니다.
보통 MVP 이후로 미루는 것들:
- 소셜 로그인 (카카오, 구글 등) — 이메일 로그인으로 먼저 출시 가능
- 정교한 알림·리마인더 시스템 — 기본 알림만 먼저
- 상세 통계 대시보드 — 핵심 수치만 먼저
- 다국어 지원 — 1개 언어로 먼저 검증
- 복잡한 권한 관리 (역할별 세분화) — 단순 관리자/일반 사용자 구분으로 시작
- 오프라인 모드
- 네이티브 앱 — 모바일 웹으로 먼저, 앱은 나중
이 목록에서 "하지만 우리는 이게 꼭 있어야 해요"라고 말하고 싶은 항목이 있을 겁니다. 그럴 때는 이 질문을 해보세요: "이게 없으면 첫 번째 고객이 돈을 내지 않을까?" 대답이 "아마 낼 것 같다"면, MVP 이후로 넘기는 게 맞습니다.
비용과 기간에 대한 더 자세한 내용은 앱 개발 비용 완전 정리를, MVP 외주 전반에 대한 가이드는 스타트업 MVP 외주 완전 가이드를 참고하세요.
우리 MVP는 몇 주가 걸릴까요? 스코프와 요구사항에 따라 달라지기 때문에 숫자 하나로 답하기는 어렵습니다. 30분 무료 상담에서 현재 아이디어를 가지고 오시면, 실제 일정을 함께 그려볼 수 있습니다.