MVP 개발 기간·비용 추정 가이드: T-shirt sizing·스토리포인트·PERT로 개발비 낭비 줄이는 법
MVP 개발 기간·비용 추정 가이드: T-shirt sizing·스토리포인트·PERT로 개발비 낭비 줄이는 법
기능 목록만 있는 상태에서 ‘이 MVP 얼마인가요?’라고 묻는다면, 먼저 금액이 아니라 산정 구조를 만들어야 합니다. 로그인, 관리자, 결제, 알림, 대시보드 같은 단어는 견적 단위가 아닙니다. 같은 로그인도 이메일 인증만 하는지, 소셜 로그인과 권한 그룹이 있는지, 기업 고객 SSO와 감사 로그까지 필요한지에 따라 작업 범위가 완전히 달라집니다.
결론부터 말하면 MVP 개발비는 ‘작업별 예상 투입일수 × 역할별 단가 + 외부 직접비 + PM·QA·배포 비용 + 리스크 예비비’로 계산해야 합니다. 개발 기간은 ‘총 투입일수’를 달력에 그대로 붙이는 것이 아니라, 실제 병렬 처리 가능 인원, 화면·API·외부 연동 의존성, 검수와 수정 기간을 반영해 산정합니다. T-shirt sizing은 초반 범위 선별, 스토리포인트는 팀 내부 상대 규모 조정, PERT는 일정 리스크가 큰 작업의 오차 범위 계산에 쓰면 좋습니다.
이 글은 ‘MVP 평균 개발비’보다 더 실무적인 질문을 다룹니다. 정부지원사업 사업계획서에 개발비 근거를 어떻게 쓰는지, 외주사 견적이 싼지 비싼지 무엇으로 비교하는지, 초기 SaaS에서 관리자·결제·알림·대시보드를 어디까지 MVP에 넣을지 판단하는 방법입니다.
좋은 MVP 견적은 가장 낮은 금액이 아니라, 어떤 기능을 왜 만들고 어떤 리스크가 얼마의 예비비를 먹는지 설명할 수 있는 견적입니다.
1. 왜 ‘평균 개발비’ 검색만으로는 위험한가
MVP 개발비 콘텐츠를 보면 ‘웹 MVP는 얼마’, ‘앱 MVP는 얼마’처럼 평균 금액을 먼저 제시하는 경우가 많습니다. 하지만 실제 견적에서 중요한 것은 플랫폼명이 아니라 운영 조건입니다. 예를 들어 B2B SaaS라면 고객사별 권한, 데이터 분리, 결제 또는 세금계산서 처리, 관리자 승인, 사용량 로그, 장애 대응 방식이 필요할 수 있습니다. 반대로 소비자 반응을 확인하는 랜딩 기반 MVP라면 결제나 복잡한 관리자 없이 문의·대기자 등록·기초 분석만으로 충분할 수 있습니다.
외주 견적 비교에서도 총액만 보면 판단이 어렵습니다. A사는 디자인과 QA를 포함하고, B사는 개발만 포함하며, C사는 관리자와 배포를 제외했을 수 있습니다. 세 견적이 모두 ‘MVP 개발’이라는 이름을 달고 있어도 실제 산출물은 다릅니다. 따라서 첫 번째 목표는 정답 금액을 맞히는 것이 아니라, 같은 기준으로 비교 가능한 견적표를 만드는 것입니다.
2. MVP 추정에서 먼저 구분할 세 가지 숫자
대표나 PM이 가장 자주 혼동하는 값은 투입량, 기간, 비용입니다. 개발자 2명이 10일 일한다고 해서 서비스가 10일 뒤 바로 출시되는 것은 아닙니다. 화면 설계가 늦어지면 프론트엔드가 대기하고, PG 심사가 지연되면 결제 검수가 밀리며, 정부지원사업 과제에서는 검수 자료와 산출물 정리 기간도 필요합니다.
| 구분 | 의미 | 계산 기준 | 자주 생기는 오류 |
|---|---|---|---|
| 투입량 | 작업을 수행하는 데 필요한 사람의 노력 | 역할별 인일 또는 인월 | 기획·QA·배포를 개발자 코딩 시간에 묻어버림 |
| 기간 | 달력상 프로젝트가 진행되는 시간 | 의존성, 병렬 처리, 검수, 수정 기간 | 투입일수 합계를 그대로 납기로 약속함 |
| 비용 | 투입량과 외부비용을 금액으로 환산한 값 | 역할별 단가, API·클라우드·툴 비용, 예비비 | 견적 총액만 보고 포함 범위를 확인하지 않음 |
따라서 견적서에는 ‘1식’보다 기능별·역할별 산정 근거가 있어야 합니다. 내부 인력으로 개발하더라도 동일합니다. 대표가 직접 기획하고 개발자가 코딩한다는 이유로 기획비가 사라지는 것이 아니라, 누군가의 시간이 비용으로 들어갑니다.
3. 아이디어를 견적으로 바꾸는 7단계 프로세스
실무에서는 다음 순서로 산정하면 오차를 줄일 수 있습니다. 처음부터 PERT 계산식을 붙잡는 것이 아니라, 기능을 제대로 자르는 과정이 먼저입니다.
- 검증 목표를 정한다. MVP가 매출 검증인지, 사용성 검증인지, 운영 가능성 검증인지 먼저 정합니다. 목표가 다르면 필요한 기능도 달라집니다.
- 사용자 유형을 나눈다. 일반 사용자, 관리자, 입점사, 내부 운영자, 심사자, 고객사 관리자처럼 권한별 행동을 분리합니다.
- 핵심 사용자 여정을 적는다. 가입, 탐색, 신청, 결제, 결과 확인, 알림 수신, 관리자 처리처럼 순서가 있는 흐름으로 적습니다.
- 기능명을 작업 단위로 쪼갠다. 화면, API, 데이터 모델, 권한, 예외 처리, 로그, 테스트, 관리자 기능을 별도 행으로 나눕니다.
- 필수·선택·보류를 구분한다. 출시일 전 반드시 필요한 기능과 출시 후 개선할 기능을 분리합니다. 기능이 많아져 우선순위가 흔들린다면 MVP 기능 우선순위 매트릭스 설계처럼 가치와 리스크를 함께 보는 표가 필요합니다.
- 산정 방식을 고른다. 정보가 적으면 T-shirt sizing, 백로그가 정리됐으면 스토리포인트, 일정 리스크가 큰 작업은 삼점산정 또는 PERT를 씁니다.
- 가정과 제외 범위를 적는다. 견적은 약속이 아니라 가정이 붙은 추정입니다. 외부 API 승인, PG 심사, 디자인 확정, 데이터 제공 시점, 고객사 보안 요구사항을 명시해야 합니다.
이 단계의 산출물은 긴 문서일 필요가 없습니다. 하지만 기능명, 사용자, 작업 범위, 검수 기준, 제외 범위는 있어야 합니다. 아직 요구사항 문서가 없다면 요구사항 명세서 템플릿과 실전 예시를 먼저 만들어 본 뒤 견적을 요청하는 편이 안전합니다.
4. 기능 목록은 이렇게 작업 단위로 쪼갠다
견적 오차의 상당수는 ‘로그인’, ‘관리자’, ‘대시보드’처럼 큰 단어를 그대로 견적 단위로 쓰는 데서 생깁니다. MVP에서는 기능명을 더 작은 작업 패키지로 나누고, 각 패키지가 완료됐는지 확인할 검수 기준을 붙여야 합니다.
| 기능명 | 작업 단위로 나눌 때 확인할 것 | 검수 기준 예시 | 추정 전 질문 |
|---|---|---|---|
| 로그인 | 이메일 가입, 비밀번호 재설정, 소셜 로그인, 권한 그룹, 세션 유지, 약관 동의 | 신규 사용자가 가입하고 재로그인하며 권한별 메뉴가 다르게 보임 | 소셜 로그인은 MVP 필수인가, 관리자 초대 방식이 필요한가 |
| 관리자 | 회원 목록, 상세 조회, 상태 변경, 검색·필터, CSV 내보내기, 운영 로그 | 운영자가 고객 문의를 보고 상태를 변경하며 변경 이력이 남음 | 운영자가 실제로 하루에 어떤 업무를 처리하는가 |
| 결제 | 상품·요금제, PG 연동, 결제 성공·실패 처리, 영수증, 환불, 웹훅 검증 | 테스트 결제 후 서비스 권한이 자동 부여되고 실패 시 재시도 안내가 보임 | 정기결제인가 단건결제인가, 세금계산서 처리는 필요한가 |
| 알림 | 이메일, 문자, 카카오 알림톡, 앱 푸시, 발송 템플릿, 실패 재시도 | 상태 변화가 발생하면 지정 채널로 알림이 발송되고 이력이 저장됨 | 알림 실패가 비즈니스 리스크로 이어지는가 |
| 대시보드 | 지표 정의, 집계 쿼리, 차트, 기간 필터, 권한별 데이터 범위, 다운로드 | 관리자가 오늘 가입자·매출·전환 지표를 기간별로 확인함 | 실시간이 필요한가, 하루 1회 집계로 충분한가 |
이 표를 만들면 견적 대화가 바뀝니다. ‘관리자 얼마인가요?’가 아니라 ‘회원 목록, 상태 변경, CSV 내보내기, 운영 로그까지 포함한 관리자 1차 범위가 얼마인가요?’라고 물을 수 있습니다. 답변의 품질도 달라집니다.
5. T-shirt sizing, 스토리포인트, PERT는 언제 쓰나
세 방법은 경쟁 관계가 아닙니다. 프로젝트 정보가 적은 초반에는 T-shirt sizing으로 큰 덩어리를 분류하고, 백로그가 구체화되면 스토리포인트로 상대적 규모를 맞추며, 외부 연동이나 복잡한 권한처럼 리스크가 큰 작업에는 삼점산정과 PERT를 적용합니다. 스토리포인트는 절대 시간이 아니라 작업의 상대적 크기와 난이도를 표현하는 방식으로 설명되며, 애자일 추정에서는 큰 작업을 더 작은 단위로 나누고 재추정하는 과정이 중요합니다. ([agilealliance.org](https://agilealliance.org/glossary/points-estimates-in/?utm_source=openai))
| 방식 | 좋은 시점 | 산출물 | 주의점 |
|---|---|---|---|
| T-shirt sizing | 아이디어와 기능 목록만 있는 초기 | XS, S, M, L, XL 분류 | XL은 그대로 견적 내지 말고 반드시 쪼갠다 |
| 스토리포인트 | 사용자 스토리와 백로그가 정리된 후 | 1, 2, 3, 5, 8, 13 같은 상대 점수 | 팀의 실제 속도 없이 원화로 바로 환산하면 위험하다 |
| 삼점산정 | 최선·보통·최악의 편차가 큰 작업 | 낙관 O, 최빈 M, 비관 P | 비관 값이 큰 이유를 리스크 항목으로 따로 관리한다 |
| PERT | 일정 오차 범위를 설명해야 하는 작업 | 예상값 E = (O + 4M + P) / 6 | 공식보다 입력값의 근거가 더 중요하다 |
5-1. T-shirt sizing: 견적 전 ‘범위 감각’을 맞추는 도구
T-shirt sizing은 기능을 XS, S, M, L, XL처럼 상대 크기로 분류하는 방식입니다. Atlassian도 T-shirt sizing을 직관적인 상대 추정 방식 중 하나로 소개합니다. ([atlassian.com](https://www.atlassian.com/agile/project-management/fibonacci-story-points?utm_source=openai)) 초기 미팅에서는 상세 견적보다 이 방식이 더 유용할 때가 많습니다. 왜냐하면 아직 화면도, 정책도, 데이터 구조도 확정되지 않았기 때문입니다.
- XS: 문구 수정, 단순 필드 추가, 정적 페이지 추가처럼 영향 범위가 작다.
- S: 단일 화면과 단순 API로 끝나며 권한·예외가 적다.
- M: 화면, API, DB 변경, 관리자 확인이 함께 필요하다.
- L: 외부 연동, 결제, 권한, 운영 정책이 얽혀 있다.
- XL: 하나의 기능이 아니라 여러 기능 묶음이다. 분해 전에는 견적 금액으로 쓰지 않는다.
주의할 점은 사이즈를 바로 금액으로 확정하지 않는 것입니다. 같은 M이라도 팀의 기술 스택, 기존 코드, 디자인 시스템, 외부 API 경험에 따라 투입일수가 달라집니다. T-shirt sizing은 예산을 확정하는 도구가 아니라 ‘지금 이 기능을 MVP에 넣을 가치가 있는가’를 판단하는 도구입니다.
5-2. 스토리포인트: 팀 내부의 상대 규모를 맞추는 도구
스토리포인트는 기능을 시간으로 바로 약속하지 않고, 기준 작업과 비교해 상대적 규모를 정합니다. 예를 들어 ‘이메일 로그인’을 3포인트 기준 작업으로 잡았다면, ‘회원 검색과 상태 변경이 있는 관리자 목록’은 5포인트, ‘PG 결제와 웹훅 처리’는 8 또는 13포인트처럼 토론할 수 있습니다. 중요한 것은 숫자 자체가 아니라 왜 더 큰지 설명하는 과정입니다.
스토리포인트를 비용으로 바꾸려면 팀의 과거 속도가 필요합니다. 1스프린트에 평균 몇 포인트를 안정적으로 완료했는지, 완료의 정의에 QA와 배포가 포함되는지, 결함 수정 시간이 별도인지 알아야 합니다. 과거 데이터가 없는 외주 견적 단계에서는 스토리포인트를 협의 도구로 쓰되, 계약 금액은 역할별 투입일수로 다시 변환하는 편이 안전합니다.
5-3. 삼점산정과 PERT: 불확실성을 숫자로 드러내는 도구
PERT는 낙관 O, 최빈 M, 비관 P라는 세 가지 기간을 사용해 예상 기간을 계산합니다. 일반적으로 쓰는 PERT 예상값은 E = (O + 4M + P) / 6이며, 최빈 값을 더 크게 반영합니다. Praxis Framework도 PERT가 단일 기간 추정보다 불확실성을 반영하기 위해 세 가지 추정값을 사용한다고 설명합니다. ([praxisframework.org](https://www.praxisframework.org/en/library/pert-analysis?utm_source=openai))
| 작업 예시 | 낙관 O | 최빈 M | 비관 P | PERT 예상일수 | 리스크 메모 |
|---|---|---|---|---|---|
| 이메일 로그인과 비밀번호 재설정 | 3일 | 5일 | 9일 | 5.3일 | 약관, 이메일 발송, 세션 정책 확정 필요 |
| 운영자 회원 관리 | 4일 | 7일 | 12일 | 7.3일 | 검색 조건과 상태 변경 이력 범위가 변수 |
| PG 결제 1차 연동 | 5일 | 9일 | 18일 | 9.8일 | 심사, 웹훅, 환불, 정기결제 여부가 변수 |
| 관리자 지표 대시보드 | 4일 | 8일 | 16일 | 8.7일 | 지표 정의와 집계 방식이 늦어지면 증가 |
위 숫자는 시장 평균이 아니라 계산 방식 예시입니다. 실제 산정에서는 기존 코드 여부, 디자인 완성도, 사용 기술, 보안 요구, 외부 API 문서 품질, 고객사 검수 속도에 따라 달라집니다. 다만 이 표의 장점은 분명합니다. 비관 값이 큰 이유가 보이면, 예비비를 넣거나 사전 기술검증을 하거나 MVP 범위에서 제외할 수 있습니다.
6. 기간을 비용으로 바꾸는 공식
작업별 예상일수를 구했다면 다음은 비용 변환입니다. 외주 견적이든 내부 개발 계획이든 공식은 단순합니다. 다만 빠지는 항목이 많을 뿐입니다.
개발비 = 역할별 투입일수 × 역할별 기준 단가 + 외부 직접비 + 프로젝트 관리·QA·배포 비용 + 리스크 예비비
| 비용 항목 | 계산 방법 | 누락되면 생기는 문제 |
|---|---|---|
| 기획·PM | 요구사항 정리, 일정 관리, 검수 대응 투입일수 | 개발자가 정책 결정을 대신하며 일정이 밀림 |
| UX·UI | 핵심 화면 수, 반응형 범위, 디자인 시스템 재사용 여부 | 화면 해석이 달라져 재작업 발생 |
| 프론트엔드 | 화면 수, 상태 관리, 권한별 UI, 폼 검증, 차트 | 브라우저별 오류와 UX 결함이 출시 후 발견 |
| 백엔드 | API, DB 모델, 인증·권한, 외부 연동, 로그 | 운영 데이터가 쌓이지 않거나 장애 추적이 어려움 |
| QA | 기능 테스트, 시나리오 테스트, 회귀 테스트 | 납품은 됐지만 실제 사용자가 쓰기 어려운 상태가 됨 |
| 배포·운영 | 서버, 도메인, SSL, 환경변수, 백업, 모니터링 | 개발 완료 후 운영 책임이 불명확해짐 |
| 외부 직접비 | 클라우드, API, 문자, 이메일, 지도, 결제 수수료 등 | 사업비 집행 또는 월 운영비 예측이 흔들림 |
| 예비비 | 불확실성이 큰 작업과 변경 가능성에 대한 별도 버퍼 | 작은 변경도 전체 일정과 품질을 압박함 |
예산 역산도 가능합니다. 전체 개발 가능 예산을 B, 리스크 예비비 비율을 R, 외부 직접비를 C, 평균 투입 단가를 D라고 두면 순수 개발에 쓸 수 있는 인일은 대략 (B × (1 - R) - C) / D입니다. 이 값보다 기능별 PERT 예상일수 합계가 크다면 세 가지 중 하나를 해야 합니다. 범위를 줄이거나, 검증 목표를 바꾸거나, 출시 후 고도화로 넘겨야 합니다.
여기서 중요한 것은 예비비를 몰래 숨기지 않는 것입니다. 정부지원사업 사업계획서나 외주 계약에서는 ‘리스크가 있으니 넉넉히’보다 ‘외부 API 승인 지연, 결제 검수, 고객사 데이터 정리 지연 가능성이 있어 해당 범위는 예비 일정과 후속 고도화 항목으로 관리’라고 쓰는 편이 설득력이 있습니다.
7. 정부지원사업 사업계획서에는 이렇게 쓴다
정부지원사업에서 개발비는 단순 구매비가 아니라 사업화 목표를 실행하기 위한 근거 있는 예산이어야 합니다. 먼저 K-Startup 같은 공식 창업지원 포털에서 현재 공고, 신청 방식, 제출서류를 확인하고, 창업진흥원 등 주관기관의 사업 안내와 공고문을 함께 확인해야 합니다. 공고별로 사업비 비목, 외주용역 가능 범위, 증빙 방식, 협약 후 변경 절차가 다를 수 있기 때문입니다. ([k-startup.go.kr](https://www.k-startup.go.kr/web/main/index.do?utm_source=openai))
| 사업계획서 항목 | 약한 표현 | 더 나은 산정 근거 |
|---|---|---|
| 개발 필요성 | 플랫폼 구축 필요 | 고객이 견적 요청 후 승인까지 3단계를 거쳐야 하므로 신청·승인·알림 기능이 필요 |
| 개발 범위 | 웹서비스 개발 1식 | 사용자 신청 화면 4개, 관리자 승인 화면 3개, 이메일 알림, 기본 통계 대시보드 |
| 예산 근거 | 외주 개발비 2천만원 | 기능별 예상 투입일수, 역할별 단가, 외부 API 비용, QA·배포 포함 여부 제시 |
| 검수 기준 | 서비스 오픈 | 테스트 계정으로 가입·신청·승인·알림·관리자 조회가 완료되고 운영 매뉴얼 제출 |
| 고도화 계획 | 추후 기능 추가 | MVP 검증 후 결제, 자동 리포트, 고객사별 권한, AI 자동 분류를 단계별로 개발 |
심사자와 주관기관이 보고 싶은 것은 화려한 기능 목록보다 사업 목표와 예산의 연결성입니다. MVP에서 검증해야 할 핵심 행동이 무엇이고, 그 행동을 측정하기 위해 어떤 기능이 필요하며, 왜 이 금액이 필요한지 설명해야 합니다. 특정 사업의 집행 기준은 매년 또는 공고별로 달라질 수 있으므로, 최종 제출 전에는 반드시 해당 공고의 운영지침과 주관기관 안내를 확인해야 합니다.
8. 외주 견적 비교: 싼 견적과 위험한 견적을 구분하는 법
외주 견적이 낮다는 이유만으로 선택하면, 출시 직전에 관리자·QA·배포·인수인계 비용이 추가될 수 있습니다. 반대로 높은 견적이 항상 좋은 것도 아닙니다. MVP에 필요 없는 풀커스텀 기능이나 과도한 아키텍처가 포함됐을 수 있습니다. 견적을 비교할 때는 총액보다 포함 범위와 가정을 먼저 봐야 합니다. 더 넓은 외주비 구조가 궁금하다면 외주개발 비용 산정 방법도 함께 참고하면 좋습니다.
| 견적 신호 | 확인할 질문 | 판단 기준 |
|---|---|---|
| 다른 곳보다 매우 낮음 | 기획, 디자인, QA, 배포, 관리자, 인수인계가 포함됐는가 | 빠진 범위가 많으면 실제 총비용은 더 커질 수 있음 |
| 기능별 내역 없이 총액만 있음 | 작업 단위와 역할별 투입일수를 받을 수 있는가 | 변경 요청과 검수 분쟁 가능성이 큼 |
| 모든 기능을 MVP에 포함 | 필수·선택·보류 기능을 나눠 견적을 다시 낼 수 있는가 | 검증 전 과투자 위험이 있음 |
| 유지보수 조건이 모호함 | 무상 하자보수, 기능 변경, 운영 장애 대응 기준은 무엇인가 | 출시 후 비용이 예측되지 않음 |
| 소스·서버 인계가 빠짐 | 저장소, 배포 계정, 환경변수, DB, 문서 인계 범위는 무엇인가 | 사업 종료 후 운영과 고도화가 막힐 수 있음 |
견적 비교를 요청할 때는 같은 자료를 보내야 합니다. 기능 목록이 다른 상태에서 받은 세 견적은 비교표가 아니라 세 개의 다른 프로젝트입니다. 최소한 사용자 유형, 화면 목록, 관리자 범위, 외부 연동, 검수 기준, 제외 범위는 통일한 뒤 견적을 받아야 합니다.
9. 견적 요청 전 체크리스트
아래 항목을 채우면 외주사와의 첫 미팅 품질이 크게 달라집니다. 모두 완벽히 정리할 필요는 없지만, 모르는 부분은 ‘미정’이라고 표시해야 합니다. 미정을 숨기면 견적이 낮아지는 것이 아니라 프로젝트 중간에 리스크로 돌아옵니다.
- 사용자 유형이 몇 개인가: 일반 사용자, 관리자, 고객사 관리자, 입점사 등
- 사용자별 핵심 행동은 무엇인가: 가입, 신청, 결제, 승인, 조회, 다운로드 등
- 출시 전 반드시 필요한 기능과 출시 후로 미룰 기능을 나눴는가
- 관리자가 실제로 처리해야 할 운영 업무를 적었는가
- 권한과 데이터 접근 범위를 정의했는가
- 결제, 문자, 이메일, 지도, 회계, CRM 등 외부 연동이 있는가
- 외부 API 계정 발급과 심사 기간을 누가 책임지는가
- 디자인은 시안 제공인지, 외주사가 제작하는지 정했는가
- 반응형 범위와 지원 브라우저를 정했는가
- 데이터 이전 또는 초기 데이터 입력이 필요한가
- 로그, 통계, 관리자 다운로드가 필요한가
- 개인정보, 보안, 백업, 접근 로그 요구사항이 있는가
- QA 시나리오와 검수 계정을 준비할 수 있는가
- 하자보수와 기능 변경을 구분했는가
- 소스코드, 서버, 도메인, DB, 배포 문서 인계 범위를 정했는가
- 정부지원사업이라면 공고별 비목과 증빙 기준을 확인했는가
10. MVP 이후 고도화 예산을 남기는 방식
MVP 예산을 전부 초기 기능 개발에 쓰면, 출시 후 실제 고객 반응을 반영할 돈이 남지 않습니다. MVP의 목적은 완성된 제품을 한 번에 만드는 것이 아니라, 다음 개발비를 더 써도 되는지 판단할 근거를 얻는 것입니다. 따라서 예산표에는 1차 출시, 안정화, 고도화 후보를 나눠야 합니다.
| 단계 | 예산을 써야 할 대상 | 넘기면 위험한 항목 |
|---|---|---|
| 1차 MVP | 검증에 필요한 핵심 사용자 여정, 최소 관리자, 기본 로그 | 가입·신청·결제·승인 같은 핵심 흐름 |
| 출시 안정화 | 버그 수정, 성능 개선, 운영자 UX, 예외 케이스 보완 | 결제 실패, 알림 실패, 데이터 오류, 관리자 처리 누락 |
| 고도화 | 자동화, 리포트, 고객사별 권한, AI 기능, 고급 분석 | 검증 전에는 과투자 가능성이 큰 기능 |
초기 SaaS에서는 관리자 기능을 과소평가하기 쉽습니다. 하지만 운영자가 수동으로 고객을 승인하고, 환불을 처리하고, 데이터를 수정하고, 문의를 확인해야 한다면 관리자 화면은 선택 기능이 아닙니다. AgentMit이 BizMit 기반의 업무 자동화, SaaS MVP, 관리자 대시보드, AI 기능을 설계할 때도 먼저 보는 것은 멋진 화면이 아니라 운영자가 매일 반복할 작업입니다.
11. AgentMit 관점의 적정 MVP 견적
AgentMit은 처음부터 정확한 금액을 맞히는 것보다, 오차를 관리할 수 있는 견적 구조를 중요하게 봅니다. 특히 정부지원사업 MVP, 초기 SaaS, 업무 자동화, AI 기능이 들어간 서비스에서는 ‘필수 기능’과 ‘보류 기능’을 나누지 않으면 예산이 빠르게 소진됩니다.
실무적으로는 다음 네 가지 산출물이 있으면 견적 정확도가 올라갑니다. 첫째, 사용자 여정 기준 기능 목록. 둘째, 관리자 운영 시나리오. 셋째, 외부 연동과 데이터 정책. 넷째, 기능별 산정 방식과 리스크 메모입니다. 이 정도가 정리되면 외주사 견적 비교도 가능하고, 정부지원사업 사업계획서의 개발비 근거도 훨씬 구체적으로 쓸 수 있습니다.
요구사항 정리부터 MVP 구현까지 내부에서 진행하기 어렵다면, AgentMit에 바로 개발을 맡기기 전에 먼저 범위표와 산정표를 함께 정리하는 방식이 좋습니다. 구현 상담은 그다음입니다. 개발사가 기능을 줄이라고 말할 수 있어야, 예산을 지키는 MVP가 됩니다.
정리: MVP 견적은 금액이 아니라 의사결정 문서다
- 기능명은 견적 단위가 아니다. 사용자 행동, 화면, API, 데이터, 권한, 검수 기준으로 쪼개야 한다.
- T-shirt sizing은 초기 범위 감각, 스토리포인트는 팀 내부 상대 추정, PERT는 불확실성 설명에 적합하다.
- 개발비는 코딩 시간만이 아니라 기획, 디자인, QA, 배포, 운영, 외부비용, 예비비를 포함해야 한다.
- 정부지원사업 사업계획서에는 총액보다 기능별 필요성, 산출물, 검수 기준, 산정 근거가 중요하다.
- 외주 견적은 총액보다 포함 범위, 제외 범위, 산출물, 변경 요청 기준으로 비교해야 한다.
FAQ
Q1. MVP 개발 기간은 보통 몇 주로 잡아야 하나요?
범위가 정해지지 않은 상태의 평균 기간은 의사결정에 거의 도움이 되지 않습니다. 사용자 유형, 필수 기능, 관리자 기능, 외부 연동, 결제·인증·보안 수준을 작업 단위로 나눈 뒤 역할별 투입일수와 검수 기간을 합산해야 합니다. 단순 프로토타입은 짧게 끝날 수 있지만, 운영 가능한 SaaS MVP는 QA·배포·관리자·데이터 정리까지 포함해야 하므로 별도 산정이 필요합니다.
Q2. 정부지원사업 사업계획서에 개발비 산정 근거를 어떻게 써야 하나요?
기능명과 총액만 쓰기보다 기능별 필요성, 작업 범위, 산출물, 검수 기준, 예상 투입일수, 외주 견적 근거를 표로 제시하는 편이 좋습니다. 또한 공고별 사업비 비목, 외주용역 가능 범위, 증빙 서류, 선금·검수 조건이 다를 수 있으므로 최신 공고와 운영지침을 먼저 확인해야 합니다.
Q3. 스토리포인트를 바로 원화 비용으로 바꿔도 되나요?
초기에는 위험합니다. 스토리포인트는 팀 내부에서 상대적 규모를 맞추는 데 유용하지만, 팀의 실제 속도와 과거 데이터가 없으면 1포인트가 며칠인지 안정적으로 말하기 어렵습니다. 비용 산정에는 스토리포인트를 참고하되, 최종 견적은 작업별 역할 투입일수와 단가로 다시 변환하는 것이 안전합니다.
Q4. 외주사 견적이 다른 회사보다 훨씬 낮으면 좋은 건가요?
반드시 좋은 것은 아닙니다. 낮은 견적에 기획, 화면설계, QA, 관리자, 배포, 오류 수정, 소스코드 인계, 운영 문서가 빠져 있을 수 있습니다. 견적 비교 시에는 총액보다 포함 범위, 제외 범위, 산출물, 변경 요청 기준, 검수 방식, 유지보수 조건을 먼저 확인해야 합니다.
Q5. MVP 이후 고도화 예산은 어느 정도 남겨야 하나요?
고정 비율보다 출시 후 어떤 결정을 내릴지에 따라 나눠야 합니다. 가입·결제·사용률 같은 검증 지표를 본 뒤 개선할 기능, 운영 중 발견될 버그와 UX 수정, 관리자 자동화, 데이터 분석 기능을 별도 예산 항목으로 분리하세요. MVP 예산을 전부 초기 기능 개발에 쓰면 출시 후 학습한 내용을 반영할 여지가 사라집니다.
참고자료와 해석 범위
이 글의 추정 방식 설명은 Agile Alliance와 Atlassian의 스토리포인트·상대 추정 설명, Praxis Framework의 PERT 설명을 참고했습니다. 정부지원사업 관련 문장은 특정 사업의 선정·집행을 보장하는 해석이 아니라, K-Startup과 창업진흥원 안내처럼 최신 공고와 운영지침 확인이 우선이라는 실무 원칙으로 사용했습니다. ([agilealliance.org](https://agilealliance.org/glossary/points-estimates-in/?utm_source=openai))
