출시일이 안 맞을 때, MVP 범위는 무엇부터 자를까요 | 기준 4가지

먼저 짧게 답부터 드릴게요. 출시일이 정해져 있는데 견적 일정이 넘친다면, 기간을 늘리기 전에 첫 출시 범위를 다시 그리는 게 먼저예요. 기준은 “사용자가 처음부터 끝까지 한 바퀴를 돌 수 있나”예요. 그 한 바퀴에 필요 없는 기능은 다음 출시로 넘겨요. 다만 기능을 40% 덜어도 일정은 40% 줄지 않아요. 스토어 심사나 테스트처럼 범위와 상관없이 남는 기간이 있어서예요. 직접 만들고 운영해본 개발사 기준으로 정리했어요.

“투자 설명회가 12주 뒤인데, 개발사에서는 16주가 걸린다고 해요.”

초기 스타트업 대표님께 자주 듣는 말이에요. 이때 선택지는 셋 정도예요. 사람을 더 넣거나, 출시일을 미루거나, 첫 출시에 들어갈 기능을 줄이거나. 사람을 더 넣으면 개발외주비용이 오르고 속도는 생각만큼 안 붙어요. 출시일은 대개 못 움직이고요. 그래서 현실적인 답은 세 번째인 경우가 많아요. 문제는 무엇을 어떤 기준으로 빼느냐예요.

---

1. 출시일이 먼저 정해졌다면, 범위는 어떻게 다시 그려야 할까요

보통 견적은 “이 기능들을 만들면 몇 주”로 계산해요. 범위가 먼저고 기간이 뒤따르죠. 출시일이 못 움직이는 날짜라면 순서를 거꾸로 해야 해요. “12주 안에 무엇까지 만들 수 있나” 로 질문을 바꾸는 거예요.

이렇게 뒤집으면 대화가 달라져요. 기능 목록을 두고 “이것도 되나요?”를 묻는 대신, 정해진 12주라는 상자에 무엇을 먼저 담을지를 고르게 돼요. 애자일 방법론 DSDM(유럽의 애자일 프레임워크)을 관리하는 Agile Business Consortium은 이 상자를 타임박스라고 부르고, 상자 안의 필수 항목이 전체 공수의 60%를 넘지 않게 잡으라고 권해요. 나머지 40%는 예상 못 한 일이 생겼을 때 버틸 여유예요.

즉 12주 출시라면 필수 기능은 7주 남짓 분량이어야 안전해요. 12주를 꽉 채운 계획은 누가 한 주만 아파도 출시일이 밀려요. 일정을 계산하는 기본 방식은 개발 기간은 어떻게 계산하고 왜 자꾸 밀릴까요에서 따로 다뤘어요.

2. 첫 출시에 반드시 남겨야 하는 것은 무엇일까요

남길 것은 크게 두 덩어리예요.

첫째, 한 바퀴 흐름. 사용자가 들어와서 이 서비스로 하려던 일을 끝내고 나가는 경로예요. 중개 서비스라면 “등록 → 신청 → 연결”이 끊기지 않아야 해요. 이 경로 중간이 비면 출시가 아니라 시연이 돼요. 저희가 대한건설기계 협동조합 인력 매칭 플랫폼을 기획 1·디자인 1·개발 1로 3개월에 만들 때도, 화면 입구는 좁혔지만 이 흐름만큼은 끝까지 이었어요. 그 판단 과정은 건설인력 매칭 사례에 정리돼 있어요.

둘째, 빼면 출시 자체가 막히는 것. 기능이라기보다 조건에 가까워요.

• 회원 탈퇴 기능. 애플은 2022년 6월 30일부터 가입 기능이 있는 앱이면 앱 안에서 계정 삭제를 할 수 있어야 한다고 심사 지침(5.1.1(v))에 못 박았어요. “고객센터로 메일 주세요”로는 통과가 안 돼요.
• 개인정보 처리방침과 약관. 스토어 등록 화면에서 링크를 요구해요.
• 결제가 있다면 취소·환불 흐름. 결제만 붙이고 취소를 빼면 첫 주에 사람이 손으로 처리할 일이 쏟아져요.

이 셋은 “다음 출시로” 칸에 들어가면 안 돼요. 들어가 있는 계획이면 일정이 짧아 보이는 대신 출시일에 멈춰요.

3. 다음 출시로 넘겨도 되는 기능은 어떻게 가려낼까요

기능 하나하나에 아래 네 가지를 물어요. 두 개 이상 “예”면 다음 출시로 넘겨도 되는 후보예요.

1. “출시 첫 2주 안에 이 기능을 쓸 사람이 있나요?” — 통계, 등급제, 추천처럼 사용자가 쌓여야 의미가 생기는 기능은 첫 주에 쓸 일이 없어요.
2. “사람이 손으로 대신할 수 있나요?” — 정산, 승인, 공지 발송은 초기 사용자 수십 명 규모라면 운영자가 엑셀과 메일로 버틸 수 있어요.
3. “나중에 붙여도 기존 데이터를 안 건드리나요?” — 알림, 검색 필터, 공유 버튼은 나중에 얹기 쉬워요. 반대로 회원 유형이나 권한 구조는 나중에 바꾸면 쌓인 데이터를 옮겨야 해요.
4. “외부 회사의 승인이나 연동을 기다려야 하나요?” — PG사 심사, 본인인증 계약, 외부 API 발급처럼 상대방 일정에 묶인 기능은 일정표에서 가장 먼저 밀려요.

예산이 모자랄 때 무엇부터 덜어낼지는 개발 예산이 부족할 때 무엇부터 덜어낼까요에서 비용 관점으로 다뤘어요. 이 글의 네 질문은 날짜를 지키는 쪽에 맞춘 기준이라 순서가 조금 달라요. 4번처럼 돈은 얼마 안 드는데 기다리는 시간이 긴 기능이 여기선 먼저 빠져요.

4. 기능을 줄이면 일정은 실제로 얼마나 줄어들까요

여기서 많이 오해해요. 기능을 절반 빼도 일정은 절반이 되지 않아요. 일정 안에는 기능 수에 비례하는 몫과, 기능 수와 거의 상관없는 몫이 섞여 있어서예요.

16주짜리 계획을 예로 계산해 볼게요. (설명을 위한 예시 계산이에요. 실제 비율은 프로젝트마다 달라요.)

구간	원래 계획	기능 40% 덜어낸 뒤	줄어드는 이유
기획·설계 확정	3주	3주	화면 수가 줄어도 서비스 정의와 데이터 구조는 똑같이 정해야 해요
기능 개발	8주	약 5주	기능 수에 거의 비례해요
통합 테스트·수정	3주	약 2.5주	조합이 줄지만 핵심 흐름 검증은 그대로예요
출시 준비·스토어 심사	2주	2주	범위와 상관없어요
합계	16주	약 12.5주(약 22% 단축)

기능을 40% 덜었는데 일정은 22% 정도 줄었어요. 그래서 “기능 절반만 하면 8주면 되죠?”라는 계산은 맞지 않아요. 반대로 기획·설계와 출시 준비를 앞뒤로 겹쳐 진행하면 몇 주를 더 벌 수 있어요. 스토어 개발자 계정 만들기와 심사용 자료 준비는 개발 중반부터 해 둘 수 있거든요.

자사 실무 기준 — 덜어낼 때 일정에 효과가 컸던 자리 (저희 경험 기준이고 통계가 아니에요)

덜어낸 것	일정 효과	이유
지원 환경(기기·OS·브라우저) 축소	큼	개발보다 검증 조합이 줄어요
외부 연동 1건 이월	큼	상대방 승인 대기가 통째로 빠져요
관리자 화면 → 직접 조회로 대체	중간	화면 수는 줄지만 데이터 설계는 그대로예요
디자인 커스텀 화면 수 축소	중간	수정 왕복 횟수가 줄어요
핵심 흐름 안의 단계 생략	작거나 역효과	출시 뒤 문의·수작업으로 되돌아와요

첫 줄은 실제 경험에서 나왔어요. 캐논코리아 펌웨어 업데이트 유틸리티는 Windows와 Mac을 함께 지원하는 게 목표였는데, 다양한 펌웨어 버전과 장치 조합을 시험하는 일이 가장 큰 부담이었어요. 지원 환경 하나가 늘 때마다 시험할 조합은 곱절로 늘어요. 뒤집어 말하면 첫 출시에서 지원 환경을 좁히는 게 일정에는 가장 확실한 카드예요.

공식·외부 기준 — 범위를 줄여도 그대로 남는 기간

항목	기준	출처
앱스토어 심사	제출 건의 90%를 24시간 안에 심사(평균)	애플 공식 안내
구글 플레이 신규 개인 개발자 계정	테스터 12명 이상, 14일 연속 비공개 테스트 후 프로덕션 신청	구글 플레이 고객센터
앱 내 계정 삭제	2022년 6월 30일부터 필수	애플 심사 지침 5.1.1(v)
필수 기능 비중	타임박스 공수의 60% 이하 권장	Agile Business Consortium(DSDM)

5. 스토어 일정은 범위를 줄여도 왜 그대로일까요

앱 출시에는 우리가 통제할 수 없는 구간이 있어요. 기능을 아무리 덜어도 이 구간은 줄지 않아요.

가장 자주 놓치는 게 구글 플레이 개인 계정 조건이에요. 구글 플레이 고객센터 안내에 따르면 2023년 11월 13일 이후 만든 개인 개발자 계정은 테스터 12명 이상이 14일 연속 비공개 테스트에 참여해야 정식 출시를 신청할 수 있어요. 그 뒤에 구글 심사도 남아 있고요. 법인이라면 조직(사업자) 계정으로 만들어 이 조건을 피하는 게 일정상 유리해요. 계정 명의를 누구로 할지는 앱 출시는 외주 범위일까요에서 자세히 다뤘어요.

애플은 제출 건의 90%를 24시간 안에 심사한다고 밝히고 있어요. 다만 평균치라서 처음 내는 앱은 더 걸릴 수 있고, 한 번 반려되면 고쳐서 다시 내는 시간이 붙어요. 그래서 저희는 출시일 최소 2주 전을 첫 제출일로 잡아요. 반려 한 번을 버틸 여유예요.

용어 한 줄 풀이 MoSCoW는 기능을 Must(반드시)·Should(가능하면)·Could(여유 있으면)·Won’t(이번엔 안 함) 네 칸으로 나누는 방법이에요. 실무에선 “Won’t” 칸을 “다음 출시” 라고 이름 붙여 두면 빼는 게 아니라 미루는 거라서 합의가 훨씬 쉬워져요. 그리고 60% 기준은 기능 개수가 아니라 걸리는 시간으로 재요.

6. 운영사 Tip — 기능 목록이 아니라 기간으로 나눠 보세요

MoSCoW를 쓸 때 가장 흔한 함정은 개수로 나누는 것이에요. “필수 10개, 선택 10개로 반반 나눴어요”라고 해도, 필수 10개 안에 결제·본인인증·실시간 알림이 들어 있으면 일정의 80%가 거기 몰려 있을 수 있어요.

그래서 저희는 순서를 이렇게 가져가요.

• 기능마다 예상 일수를 먼저 붙여요. 개발사에 “기능별로 며칠인지 적어 주세요”라고 요청하면 돼요.
• Must 칸의 일수 합이 전체 기간의 60%를 넘으면 Must 안에서 다시 골라요.
• Must 안에 외부 승인을 기다리는 기능이 있으면 착수 첫 주에 신청부터 해요. 개발보다 대기가 길어요.
• “다음 출시” 칸은 날짜를 적지 않아요. 첫 출시 뒤 실제 사용 기록을 보고 정해요.

KICT 토양 특성 평가 앱은 기획 1·개발 1로 1개월 만에 출시했어요. 목적이 “현장 데이터를 정확하게 모은다” 하나로 분명했기 때문에 가능했던 일정이에요. 그 대신 한 달 가운데 가장 공을 들인 건 기능 수가 아니라 토양 사진 분석이었어요. 범위를 좁히면 남은 시간이 정말 어려운 곳으로 가요.

7. 범위를 자를 때 흔히 하는 실수는 무엇일까요

첫째, 층으로 자르는 것. “앱은 이번에, 관리자 화면은 다음에”처럼 층을 통째로 빼면 운영자가 데이터를 볼 방법이 없어져요. 관리자 화면을 빼더라도 조회만 되는 최소 화면이나 데이터를 내려받는 방법 하나는 남겨 두세요.

둘째, 착수 뒤에 자르는 것. 디자인이 끝난 뒤에 기능을 빼면 이미 만든 화면을 다시 고쳐야 해요. 범위 조정은 기획 확정 전에 할수록 일정 효과가 커요. 착수 뒤에 요구가 늘어날 때의 대응은 외주 프로젝트 요구사항이 자꾸 바뀔 때를 참고하세요.

셋째, 사람을 더 넣어 해결하려는 것. 인원을 늘리면 기능 개발 구간은 조금 줄지만 4번 표의 앞뒤 구간은 그대로예요. 오히려 인원 사이 조율 시간이 붙어요. 한국인공지능·소프트웨어산업협회(KOSA) 2026년 SW기술자 일평균임금이 41만 4,762원이라, 개발자 한 명이 두 달 더 붙으면 인건비만 약 1,660만 원이에요. 그 돈으로 줄어드는 기간이 몇 주인지 먼저 따져 보세요. 일정을 당길 때의 비용 구조는 개발 일정을 앞당기면 비용은 얼마나 늘까요에 정리했어요.

넷째, “다음 출시”를 계약서에 확정하는 것. 2차 범위까지 미리 고정하면 첫 출시에서 배운 걸 반영할 수 없어요. 1차 범위만 확정하고 2차는 “출시 후 협의” 로 두는 편이 나아요. 초기 예산을 어떻게 나눠 둘지는 스타트업 초기 예산 개발 외주에서 다뤘어요.

8. 운영까지 해본 개발사는 첫 출시 범위를 어떻게 볼까요

자체 SaaS 4종을 직접 운영하면서 배운 건, 첫 출시에서 사용자가 실제로 찾는 기능이 기획 때 예상한 목록과 꽤 다르다는 점이에요. 그래서 저희는 첫 출시를 완성본이 아니라 첫 측정 도구로 봐요. 기능을 덜어낸 자리에는 대신 사용 기록을 꼭 남겨요. 어느 화면에서 멈췄는지, 어느 버튼을 누르지 않았는지가 쌓여야 다음 출시 범위를 감이 아니라 숫자로 정할 수 있어요.

그리고 첫 출시 직후 2～4주는 문의와 수정이 가장 몰리는 시기예요. 출시일까지 일정을 꽉 채우면 이 기간을 버틸 사람이 없어요. 12주 계획이라면 마지막 한두 주는 기능이 아니라 출시 뒤 대응에 쓴다고 생각하고 범위를 잡는 게 안전해요. PoC와 MVP 가운데 무엇으로 시작할지부터 고민 중이라면 PoC와 MVP 차이를 먼저 보셔도 좋아요.

출시일은 정해졌는데 기능 목록이 그 안에 안 들어간다면, 목록을 그대로 가져오셔도 괜찮아요. 무엇을 남기고 무엇을 다음으로 넘길지 날짜 기준으로 같이 나눠 드릴게요. 첫 출시 범위, 같이 잘라 볼까요 →

저희는 10년 넘게 50개 이상의 프로젝트를 만들어 왔고, 지금도 자체 SaaS 4종을 직접 운영하고 있어요. 롯데·캐논 같은 곳과도 함께했고요. 출시일을 맞추는 일과 출시 뒤에 버티는 일을 둘 다 해 봐서, 어디를 덜어내면 나중에 비용으로 돌아오는지 알아요.

9. 자주 묻는 질문 (FAQ)

MVP 첫 출시까지 보통 몇 주를 잡아야 하나요?

유형에 따라 달라요. 공개 시장 자료 기준으로 단순 앱은 6～10주, 예약·커머스 앱은 3～5개월, 플랫폼·실시간 앱은 4～6개월 이상이 흔해요. 여기에 스토어 조건을 더해요. 구글 플레이 개인 계정이면 비공개 테스트 14일이 추가되고, 앱스토어는 반려 대비로 출시 2주 전 제출을 권해요.

개발 외주 플랫폼이나 업체 추천을 받을 때, 범위 조정 역량은 어떻게 확인하나요?

“기능별로 며칠이 드는지 나눠서 적어 줄 수 있나요?”라고 물어보세요. 개발 외주 업체 추천을 받든 개발 외주 플랫폼에서 찾든, 이 질문에 기능 단위 일수로 답하는 곳은 일정이 안 맞을 때 무엇을 덜어낼지 같이 계산할 수 있는 곳이에요. 총 기간 한 줄로만 답하면 범위를 조정할 때마다 견적을 새로 받아야 해요.

GUI 소프트웨어나 측정 프로그램 외주 개발도 같은 기준으로 범위를 줄이나요?

네, 같은 네 질문을 써요. 다만 PC 프로그램과 장비 연동은 지원 운영체제와 장비 종류를 줄이는 게 일정에 가장 크게 작용해요. 측정 프로그램 외주 개발이라면 첫 출시는 장비 한 종·운영체제 하나로 열고, 나머지는 다음 출시로 넘기는 방식이 현실적이에요. 기업을 위한 AI 개발 외주도 비슷해서 첫 출시는 데이터 한 종류·업무 하나로 좁히는 편이 일정을 지키기 쉬워요.