MVP 개발 범위, 어디까지 잘라야 하나 — 1차 출시에서 빼도 되는 것과 빼면 안 되는 것

MVP 개발 범위를 정하는 회의는 대체로 이렇게 끝납니다. 시작할 때는 “일단 핵심 기능만 빠르게 내보자”였는데, 두 시간 뒤 화이트보드에는 회원가입과 소셜로그인, 결제, 쿠폰, 관리자 대시보드, 푸시 알림, 통계 리포트가 나란히 적혀 있습니다.

누구도 무리한 요구를 하지 않았습니다. 각 부서가 “이건 없으면 서비스가 안 된다”고 말한 것만 모았을 뿐입니다. 문제는 그 목록을 그대로 개발사에 넘기는 순간 시작됩니다. 견적은 1차 출시가 아니라 완성품 기준으로 돌아오고, 3개월이던 일정은 7~8개월이 됩니다. 그리고 시장 반응을 한 번도 확인하지 못한 채 예산의 대부분을 씁니다.

MVP가 실패하는 지점은 개발 속도가 아닙니다. 범위를 잘라낼 권한을 가진 사람이 프로젝트 안에 없다는 것입니다.

디비컨설팅은 100건 이상의 웹·앱·플랫폼 프로젝트를 수행했고, 50개 이상의 글로벌 파트너사와 함께 일하고 있습니다. 삼성물산 홈닉(주거 플랫폼 앱), GS건설 엘리시안 리조트(리조트 웹·앱 통합 구축), 하나투어 하나오픈챗(여행 상담 채팅 서비스), 직방 호갱노노(부동산 데이터 서비스), LS일렉트릭 테크스퀘어(산업 B2B 거래 플랫폼)가 그 결과물입니다. 고객 만족도는 98%이며, 국내에서 인력을 직접 채용하는 방식과 비교해 평균 40~60%의 비용을 절감합니다.

아래 기준은 그 프로젝트들에서 반복적으로 확인한 것입니다. 앱 개발 외주를 처음 발주하는 기업일수록, 같은 세 가지 지점에서 범위가 무너집니다.

MVP 개발 범위는 왜 항상 부풀어 오르는가

기능 목록이 ‘부서별 합집합’으로 만들어진다

기획팀은 사용자 여정을, 마케팅팀은 유입과 프로모션을, 운영팀은 관리 도구를, 경영진은 투자자에게 보여줄 화면을 각각 요구합니다. 각각의 요구는 개별적으로 모두 타당합니다. 다만 그것을 그대로 합치면 MVP가 아니라 2년 차 서비스의 기능 명세가 됩니다. 합집합을 만드는 회의는 있지만, 교집합을 남기는 회의는 없습니다.

‘나중에’라는 말이 문서 어디에도 남지 않는다

회의에서는 “그건 2차에 하죠”라는 말이 분명히 나옵니다. 그런데 그 말은 회의록에만 있고, 요구사항 정의서와 견적서에는 남지 않습니다. 2차로 미룬 기능이 문서에 ‘2차’라고 적히지 않으면, 개발사 입장에서 그것은 1차 범위입니다. 견적이 커지는 것도 이 때문이고, 개발이 끝난 뒤 “이건 원래 1차 아니었나요”라는 분쟁이 생기는 것도 이 때문입니다. 일정이 계획보다 길어지는 구조는 앱 개발 기간에서 단계별로 따로 정리했습니다.

개발사에게는 범위를 줄일 이유가 없다

이 부분은 솔직하게 말하는 편이 낫습니다. 투입 기간을 기준으로 계약하는 구조에서 범위가 줄면 개발사의 매출도 줄어듭니다. 발주사가 기능을 하나 더 얹을 때 “그건 2차로 미루시죠”라고 말할 동기가 구조적으로 없습니다. 그래서 범위 통제는 개발사의 선의에 기대는 문제가 아니라, 누가 그 역할을 맡도록 계약되어 있는가의 문제입니다.

1차 출시에서 빼도 되는 것과 빼면 안 되는 것

실무에서 쓰는 기준은 한 문장입니다. 나중에 추가하면 되는 것은 빼고, 나중에 바꾸려면 처음부터 다시 만들어야 하는 것은 남깁니다. 이 기준이 대부분의 논쟁을 정리합니다.

빼면 안 되는 것 — 나중에 바꾸면 재작업이 되는 영역

• 핵심 가치 경로 하나 — 사용자가 이 서비스에 돈이나 시간을 쓰는 단 하나의 흐름입니다. 이것이 흐릿하면 나머지를 다 만들어도 검증할 대상이 없습니다.
• 데이터 구조 — 사용자·거래·콘텐츠의 관계 정의입니다. 출시 후 데이터가 쌓인 뒤에 스키마를 바꾸면, 마이그레이션 비용이 신규 개발보다 커지는 경우가 많습니다.
• 로그와 계측 — 어느 화면에서 이탈하는지 기록되지 않으면 2차에서 무엇을 만들지 판단할 근거가 없습니다. MVP의 목적은 출시가 아니라 학습입니다.
• 보안·개인정보 최소 요건 — 인증, 권한 분리, 개인정보 저장 범위입니다. 나중에 얹는 것이 가장 비싼 항목입니다.

빼도 되는 것 — 초기에는 사람이 대신할 수 있는 영역

• 관리자 화면 자동화 — 초기 사용자 규모에서는 운영자가 직접 처리해도 됩니다. 관리자 페이지는 1차 범위에서 가장 크고, 가장 급하지 않은 덩어리입니다.
• 소셜로그인 다중 연동 — 하나로 시작해도 검증에는 지장이 없습니다.
• 쿠폰·프로모션·추천 코드 — 성장 기능이지 검증 기능이 아닙니다.
• 통계 대시보드 — 초기에는 데이터를 직접 조회해도 충분합니다.
• 다국어와 세분화된 푸시 — 대상이 정해지기 전에 만들면 대부분 다시 만듭니다.

이 목록을 그대로 쓰시라는 뜻은 아닙니다. 다만 ‘빼도 되는 것’은 대체로 사람이 대신할 수 있는 일이고, ‘빼면 안 되는 것’은 사람이 대신할 수 없는 구조라는 원칙은 업종과 무관하게 적용됩니다. 출시 이후에 실제로 돈이 드는 항목은 앱 유지보수 비용에서 별도로 다뤘습니다.

그래서, 이 판단은 누가 하는가

여기까지는 기준의 문제였고, 남는 것은 주체의 문제입니다. 발주사가 마주하는 실제 선택지는 국내냐 해외냐가 아니라, 범위를 정의하고 지켜낼 사람을 어디에 두느냐입니다.

	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
요구사항 정의 책임	개발사	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	영어	한국어
범위를 잘라낼 동기	낮음	발주사에게만 있음	한국 PM
발주사 담당자 투입 시간	보통	매우 많음	적음
재작업 리스크	낮음	높음	낮음
총비용 관점	비쌈	기대만큼 싸지 않음	실질 절감

개발 단가만 보면 두 번째가 가장 저렴해 보입니다. 하지만 요구사항을 영어로 정의하고, 시차를 넘겨 일정을 조율하고, 산출물을 검수하는 일을 발주사 담당자가 직접 하게 됩니다. 사내에 그 일을 전담할 인력이 없다면 두 번째 선택지는 저렴한 개발이 아니라 보이지 않는 인건비입니다. 해외 개발 조직이 실제로 어떻게 운영되는지는 인도 IT 아웃소싱에서 더 자세히 정리했습니다.

디비컨설팅이 범위를 관리하는 방식

IT 아웃소싱을 진행할 때, 발주사는 한국인 PM 한 사람하고만 한국어로 소통합니다. 요구사항 정의부터 검수까지가 그 PM의 책임 범위입니다.

1. 상담 및 요구 분석 — 비즈니스 목표와 기술 요건을 한국어 문서로 정리합니다. 1차 범위와 2차 범위를 이 단계에서 문서상 분리해 적습니다. 이후 발생하는 재작업의 대부분이 여기서 사라집니다.
2. 개발팀 구성 — 확정된 범위에 맞춰 전담팀을 2~4주 내에 구성합니다. 범위가 작으면 팀도 작게 시작합니다.
3. 프로젝트 개발 — 애자일 방식으로 진행하며 진척 상황을 투명하게 공유합니다. 발주사 담당자가 하루를 조율에 쓰지 않는 구조입니다.
4. 테스트 및 배포 — QA 프로세스를 거쳐 릴리스합니다.
5. 운영 및 유지보수 — 문서와 함께 인계하고 장기 지원을 이어갑니다. 2차 범위는 1차에서 쌓인 데이터를 근거로 다시 정의합니다.

실제로 만든 서비스들

범위 판단은 겪어본 사례의 수만큼 정확해집니다. 디비컨설팅이 수행한 프로젝트 중 일부입니다.

• 삼성물산 홈닉 — 주거 플랫폼 앱
• GS건설 엘리시안 리조트 — 리조트 웹·앱 통합 구축
• 하나투어 하나오픈챗 — 여행 상담 채팅 서비스
• 직방 호갱노노 — 부동산 데이터 서비스
• LS일렉트릭 테크스퀘어 — 산업 B2B 거래 플랫폼
• 교보생명 사내벤처(글펍) — 커뮤니티 서비스
• 가천대학교 — 학사관리 시스템
• 센터필드·센트로폴리스·그랑서울 — 프라임 오피스 빌딩 관리 시스템
• 와디즈 — 글로벌 플랫폼

교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT 영역의 구축 경험이 있습니다. 전체 목록은 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다

• 1차 출시로 시장 반응을 먼저 확인하려는 기업
• 사내에 개발 인력이나 전담 PM이 없는 기업
• 기획이 아직 문서로 정리되지 않은 단계의 기업
• 예산을 한 번에 집행하지 않고 단계적으로 나누려는 기업

반대로, 이런 경우에는 권하지 않습니다

• 사내에 이미 개발팀과 PM이 있고 인력만 보강하면 되는 경우 — 이때는 전체 위탁보다 인력 단위 협업이 더 저렴합니다.
• 범위를 줄일 생각이 전혀 없는 경우 — 1차에 모든 기능을 넣기로 이미 결정하셨다면, 이 글의 방식은 맞지 않습니다.
• 2주 안에 출시해야 하는 경우 — 전담팀 구성에만 2~4주가 필요합니다. 이 일정이라면 노코드 도구가 더 적합합니다.

맞지 않는 프로젝트를 서로 확인하지 않고 시작하는 것이, 양쪽 모두에게 가장 비싼 선택이기 때문에 굳이 적습니다.

자주 묻는 질문

해외 개발팀인데 의사소통은 어떻게 하나요?

발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 검수는 PM의 책임입니다. 개발팀과 직접 영어로 대화하실 일은 없습니다.

비용은 어떻게 산정되나요?

등급별 단가에 투입 기간을 곱하는 방식입니다. 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 구분해 제시하므로, 어떤 항목을 1차에서 빼면 얼마가 줄어드는지 보고 판단하실 수 있습니다. 견적과 최종 정산이 벌어지는 구조는 IT 외주개발 비용에서 따로 정리했습니다.

기획서가 없는데 견적이 가능한가요?

가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 일정과 예산 범위만 알려주시면 개략 견적을 드릴 수 있습니다. 오히려 기획서가 완성된 뒤에 문의하시면, 이미 부풀어 있는 범위를 그대로 견적하게 되는 경우가 많습니다.

진행 중에 팀 규모를 조정할 수 있나요?

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고 진행 중 조정도 가능합니다. MVP 단계에서는 작게 시작해 1차 결과를 보고 늘리는 방식을 권합니다.

소스코드 소유권은 누구에게 있나요?

발주사에 귀속됩니다. API 명세, DB 스키마, 배포 절차 문서까지 인계합니다. 1차를 저희와 진행하고 2차를 내부 팀이나 다른 개발사와 진행하셔도 문제가 없습니다. 계약 단계에서 확인하셔야 할 조항은 개발 외주 계약서에 정리해 두었습니다.

정리

MVP 개발 범위는 기능을 몇 개까지 넣느냐의 문제가 아닙니다. 나중에 추가할 수 있는 것과 나중에 바꾸면 다시 만들어야 하는 것을 구분하고, 그 구분을 문서와 계약에 남기고, 그 판단을 책임질 사람을 프로젝트 안에 두는 문제입니다. 세 가지 중 하나라도 비어 있으면 범위는 예외 없이 부풀어 오릅니다. 디비컨설팅이 한국인 PM을 구조의 중심에 두는 이유가 바로 이것입니다.