MVP 개발 기간, 4주와 12주의 차이

MVP 개발 업체를 알아보면 같은 아이디어인데도 일정 차이가 크게 나는 경우가 있습니다.

어떤 업체는 4주 안에 가능하다고 하고, 다른 업체는 12주 이상이 필요하다고 설명할 수 있습니다.

둘 중 하나가 반드시 틀렸다고 볼 수는 없습니다.

같은 MVP라는 표현을 사용해도 다음 범위가 다를 수 있기 때문입니다.

• 기획이 준비되어 있는가?
• 디자인이 있는가?
• 실제 데이터가 저장되는가?
• 회원과 결제가 있는가?
• 관리자 페이지가 필요한가?
• 외부 API를 연결하는가?
• 운영 서버까지 배포하는가?
• 실제 고객에게 공개하는가?

4주 일정은 범위가 작고 준비가 잘되어 있을 때 가능할 수 있습니다.

12주 일정은 요구사항 정리, 디자인, 관리자, 결제와 충분한 검수까지 포함한 결과일 수 있습니다.

따라서 기간 숫자만 비교하기보다 각 일정 안에 무엇이 포함되는지를 확인해야 합니다.

4주 MVP가 가능할 수 있는 조건

1. 검증 목표가 하나로 명확합니다

예를 들면 다음과 같습니다.

• 고객이 상담을 신청하는가?
• 사용자가 파일을 올리고 결과를 확인하는가?
• 특정 콘텐츠 생성 기능을 반복해서 사용하는가?
• 유료 결제를 시도하는가?

검증 목표가 여러 개이면 필요한 기능도 늘어납니다.

2. 필수 기능이 적습니다

예시:

• 이메일 로그인
• 핵심 기능 1개
• 결과 확인
• 최소 관리자
• 운영 서버 배포

소셜 로그인, 통계, 자동화, 다국어 등은 이후로 미룹니다.

3. 기획과 디자인이 준비되어 있습니다

다음 자료가 있다면 개발을 빠르게 시작할 수 있습니다.

• 사용자 흐름
• 화면 목록
• Figma
• 기능 정의
• 입력 항목
• 관리자 범위
• 완료 기준

개발 중 구조와 디자인을 다시 정하면 4주 일정이 어려워질 수 있습니다.

4. 외부 서비스가 단순합니다

• API 문서가 명확함
• 테스트 계정이 준비됨
• 별도 심사가 없음
• 데이터 변환이 단순함

외부 업체의 심사와 계정 발급이 늦어지면 개발 속도와 무관하게 일정이 지연될 수 있습니다.

5. 의사결정이 빠릅니다

• 담당자 한 명
• 최종 승인자 명확
• 피드백 기한 준수
• 자료 즉시 제공
• 큰 범위 변경 없음

개발 업체가 하루 만에 작업해도 의뢰사의 승인이 일주일씩 늦으면 전체 일정은 늘어납니다.

6. 수동 운영을 허용합니다

처음부터 모든 업무를 자동화하지 않고 운영자가 일부 처리할 수 있습니다.

• 결과 수동 검수
• 이메일 수동 발송
• 신청 상태 수동 변경
• 간단한 엑셀 관리
• 수동 환불

실제 수요가 확인된 뒤 자동화할 수 있습니다.

12주가 필요할 수 있는 조건

1. 요구사항부터 함께 정리합니다

아이디어만 있고 기획이 없는 경우 다음 작업이 필요합니다.

• 문제와 목적 정리
• 사용자 정의
• 기능 우선순위
• 화면 설계
• 관리자 업무
• 예외 상황
• 완료 기준

복잡한 서비스는 이 단계에만 수주가 필요할 수 있습니다.

2. 맞춤 디자인이 필요합니다

• 브랜드 방향
• UX 설계
• 전체 화면 디자인
• 모바일 화면
• 피드백
• 상태별 디자인
• 디자인 시스템

주요 디자인이 확정되어야 개발을 안정적으로 진행할 수 있습니다.

3. 사용자 유형과 권한이 많습니다

• 개인 회원
• 기업 회원
• 기업 관리자
• 기업 직원
• 운영 관리자

권한에 따라 화면과 데이터가 달라지면 설계와 테스트 시간이 증가합니다.

4. 결제와 구독이 있습니다

결제에는 다음 흐름이 포함될 수 있습니다.

• 주문
• 성공
• 실패
• 취소
• 환불
• 권한 지급
• 정기결제
• 해지
• 관리자

운영 정책과 예외 처리를 정해야 합니다.

5. 관리자 기능이 복잡합니다

• 검색과 필터
• 승인·반려
• 권한
• 통계
• 엑셀
• 대량 처리
• 수정 이력
• 자동화
• 오류 재처리

관리자는 사용자 화면과 별도의 서비스에 가깝습니다.

6. 데이터 이전이 필요합니다

기존 엑셀이나 서비스에서 회원, 콘텐츠와 파일을 옮겨야 한다면 다음 과정이 필요합니다.

• 원본 분석
• 데이터 정제
• 구조 변환
• 테스트 이전
• 검증
• 최종 이전

7. 실제 유료 고객을 받아야 합니다

내부 데모가 아니라 공개 서비스라면 다음 범위를 줄이기 어렵습니다.

• 보안
• 개인정보
• 약관
• 백업
• 로그
• 실패 처리
• 운영 관리자
• 모니터링

4주 MVP 일정 예시

아래는 요구사항과 디자인이 비교적 준비된 작은 웹 MVP의 예시입니다.

1주 차

• 개발 환경
• 데이터베이스
• 공통 UI
• 회원가입·로그인
• 핵심 화면 구조

2주 차

• 핵심 기능
• 데이터 저장
• 결과 화면
• 기본 관리자

3주 차

• 모바일 대응
• 이메일·외부 API
• 오류 처리
• 운영 서버 준비

4주 차

• 전체 검수
• 수정
• 배포
• 관리자·계정 인계

이 일정은 중간에 큰 기능 변경이 없고 자료와 피드백이 빠르게 제공된다는 전제가 필요합니다.

12주 MVP 일정 예시

1~2주 차: 요구사항 정의

• 목적과 사용자
• 기능 우선순위
• 사용자 흐름
• 관리자 업무
• 외부 API
• 완료 기준

3~4주 차: UX·UI 디자인

• 와이어프레임
• 주요 화면
• 모바일
• 피드백
• 디자인 확정

5~8주 차: 핵심 개발

• 회원
• 권한
• 핵심 기능
• 데이터
• 관리자
• 외부 API

9~10주 차: 운영 기능

• 결제
• 알림
• 통계
• 예외 처리
• 서버
• 로그

11주 차: 전체 검수

• 사용자 흐름
• 관리자
• 모바일
• 브라우저
• 결제
• 데이터

12주 차: 수정과 배포

• 오류 수정
• 운영 배포
• 계정 인계
• 사용 방법
• 최종 확인

개발 기간에 큰 영향을 주는 요소

1. 요구사항 확정 속도

회원 관리처럼 추상적인 기능을 개발 중에 구체화하면 변경이 반복될 수 있습니다.

2. 콘텐츠 준비

• 문구
• 이미지
• 상품 정보
• 포트폴리오
• 이메일 템플릿
• 약관

실제 콘텐츠가 늦게 들어오면 레이아웃과 검수도 늦어집니다.

3. 피드백 속도

디자인과 기능을 확인한 뒤 며칠 안에 답을 줄 수 있는지 중요합니다.

4. 외부 심사와 계정

• PG 결제 심사
• 알림톡 템플릿 승인
• 소셜 로그인 비즈니스 인증
• 외부 API 계정
• 도메인 이전

개발 업체가 통제하기 어려운 일정입니다.

5. 변경 요청

기능 추가뿐 아니라 사용자 유형과 데이터 구조 변경은 전체 일정에 큰 영향을 줍니다.

6. 검수 인원

검수 부서가 많고 승인자가 여러 명이면 피드백 취합에 시간이 필요합니다.

7. 데이터와 파일

대량 데이터, 이미지와 파일 처리 기능은 테스트 범위가 커질 수 있습니다.

빠른 일정이 위험해지는 신호

• 기능 목록이 아직 없음
• 사용자 유형이 불명확함
• 디자인이 없는데 개발부터 시작함
• 관리자 기능을 나중에 정하려 함
• 결제 정책이 없음
• 여러 부서가 개별로 피드백함
• 기존 데이터 상태를 모름
• 외부 API 문서를 확인하지 않음
• 모든 기능을 1차에 넣으려 함

이 상태에서 4주를 확정하면 품질을 낮추거나 기능을 제외하거나 일정이 지연될 가능성이 커집니다.

12주 견적이 과도한지 확인하는 방법

기간이 길다고 무조건 불필요한 것은 아닙니다.

다음 내용을 확인하세요.

• 각 단계의 결과물이 무엇인가?
• 기획과 디자인이 포함되는가?
• 실제 개발 기간은 몇 주인가?
• 관리자와 결제가 포함되는가?
• 검수 기간이 충분한가?
• 의뢰사 피드백 대기 시간이 포함되는가?
• 다른 프로젝트 때문에 대기하는 시간은 없는가?
• 어떤 인력이 투입되는가?

일정표에 결과물과 담당자가 연결되어 있어야 합니다.

기간을 줄이는 가장 효과적인 방법

1. 핵심 가설 하나를 선택합니다

2. 필수 기능과 추후 기능을 나눕니다

1차:
이메일 가입, 핵심 기능, 최소 관리자

2차:
소셜 로그인, 자동화, 고급 통계, 앱

3. 디자인 범위를 제한합니다

핵심 화면 위주로 디자인하고 반복 화면은 공통 구조를 사용합니다.

4. 수동 운영을 허용합니다

사용자가 적은 단계에서는 일부 관리자 업무를 수동 처리할 수 있습니다.

5. 피드백 담당자를 한 명으로 정합니다

내부 의견을 취합해 한 번에 전달합니다.

6. 외부 계정을 미리 준비합니다

결제와 메시지 서비스 가입을 개발과 동시에 진행합니다.

공개일이 정해져 있다면 역산해야 합니다

예를 들어 10월 1일 공개가 필요하다면 개발 완료일을 10월 1일로 잡으면 안 됩니다.

10월 1일: 정식 공개
9월 24일: 운영 배포
9월 10~23일: 검수와 수정
8월 말: 전체 기능 완료

공개 전에 검수와 수정, 데이터 입력과 운영 준비 기간을 확보해야 합니다.

업체에 일정을 문의할 때 전달할 정보

MVP의 검증 목표:
필수 기능:
제외 가능한 기능:
기획 준비 상태:
디자인 준비 상태:
관리자 기능:
결제·외부 API:
콘텐츠 준비 상태:
기존 데이터:
검수 담당자:
공개가 필요한 날짜:
날짜가 중요한 이유:
피드백 가능 주기:

4주와 12주를 비교할 때 확인할 질문

• 최종 결과물의 차이는 무엇인가?
• 4주 안에서 제외되는 기능은 무엇인가?
• 12주 안에 기획과 디자인이 포함되는가?
• 관리자 페이지 범위는 같은가?
• 실제 운영 서버 배포가 포함되는가?
• 결제와 예외 처리는 같은가?
• 모바일 대응 수준은 같은가?
• 테스트와 검수 기간은 얼마인가?
• 추가 기능 요청 시 일정은 어떻게 바뀌는가?

마무리

MVP 개발 기간은 기능 개수만으로 결정되지 않습니다.

4주 MVP는 검증 목표와 범위가 좁고, 기획·디자인과 의사결정이 준비된 경우 가능할 수 있습니다.

12주 MVP는 요구사항 정리부터 맞춤 디자인, 결제·관리자와 충분한 검수까지 포함된 결과일 수 있습니다.

중요한 것은 가장 짧은 일정을 선택하는 것이 아니라 다음을 확인하는 것입니다.

해당 기간이 끝났을 때 누가 어떤 기능을 실제로 사용할 수 있는가?