MVP 개발 견적, 무엇이 범위와 비용을 결정할까

MVP의 범위를 줄인다는 것은 기능을 무작정 빼는 일이 아닙니다. 어떤 사용자가 어떤 문제를 해결하고, 출시 뒤 어떤 행동이나 결과를 확인할지 정한 다음 그 판단에 직접 필요한 흐름만 첫 버전에 남기는 일입니다.

GOV.UK 서비스 매뉴얼은 사용자가 누구이고 무엇을 하려는지, 현재 어떤 방식과 불편을 겪는지부터 조사하라고 안내합니다. 기능 아이디어는 사용자 문제에 대한 가정과 구분해야 합니다. 견적 요청에도 대상 사용자, 현재 방식, 핵심 문제와 확인하려는 결과를 적으면 구현 범위를 판단하기 쉬워집니다.

견적에서 화면 한 장은 고정된 작업 단위가 아닙니다. 목록 화면도 보기만 가능한지, 검색·수정·삭제·다운로드가 필요한지에 따라 처리할 상태와 오류가 달라집니다. 가입, 승인, 결제처럼 여러 단계가 연결되면 중간 실패와 재시도도 확인해야 합니다.

역할이 늘어나면 각 역할이 볼 수 있는 메뉴뿐 아니라 같은 데이터에서 조회·생성·수정·승인할 수 있는 범위를 정해야 합니다. 고객, 운영자와 관리자처럼 실제 역할별 핵심 흐름을 시작부터 끝까지 적는 편이 단순한 화면 목록보다 정확한 견적 자료가 됩니다.

새로 입력하는 데이터만 사용하는 서비스와 기존 엑셀·데이터베이스를 이전해야 하는 서비스는 준비 과정이 다릅니다. 데이터 형식이 일정하지 않거나 중복과 누락이 있으면 화면 개발과 별도로 정리·변환·검증 범위가 필요할 수 있습니다.

결제, 소셜 로그인, 지도, 이메일과 사내 시스템 같은 외부 연동은 API 문서만으로 끝나지 않습니다. 계정 소유자, 개발용 접근 권한, 호출 제한, 실패 응답과 운영 전환 절차를 확인해야 합니다. 아직 접근 권한이나 샘플 데이터가 없다면 확인 전제와 대체 흐름을 견적에 가정으로 남겨야 합니다.

시연용 화면은 정해진 입력과 순서만 보여주면 되지만 실제 서비스는 잘못된 입력, 접근 권한, 데이터 노출, 모바일과 키보드 사용, 서버 오류를 처리해야 합니다. GOV.UK 서비스 매뉴얼도 프로토타입 코드는 운영 서비스와 같은 보안·성능 기준을 충족하지 않을 수 있으므로 그대로 복사해 운영하지 말라고 안내합니다.

OWASP ASVS는 웹 애플리케이션 보안 통제를 시험하고 계약에서 검증 요구사항을 정하는 기준을 제공합니다. W3C의 WCAG는 웹 콘텐츠 접근성을 인식·운용·이해·견고성의 원칙과 시험 가능한 기준으로 설명합니다. 어떤 수준까지 확인할지는 서비스 위험과 계약에 따라 정하되, 운영에 필요한 검수 작업을 화면 제작과 분리하지 않아야 합니다.

확정된 화면과 문구가 있는 프로젝트는 구현 기준이 비교적 명확합니다. 반대로 참고 서비스만 있고 정보 구조, 문구와 화면 흐름을 함께 정해야 한다면 기획·디자인 확인 과정이 견적에 포함되어야 합니다.

처음부터 완성된 디자인이 꼭 필요한 것은 아닙니다. 종이 스케치나 간단한 프로토타입도 흐름을 확인하는 데 사용할 수 있습니다. 다만 누가 시안을 만들고 몇 차례 확인할지, 로고·문구·이미지와 정책 내용을 언제 제공할지 정해야 구현 뒤 전체 구조를 다시 바꾸는 일을 줄일 수 있습니다.

로컬 컴퓨터에서 실행되는 상태, 테스트 주소에 배포된 상태와 실제 도메인에서 운영되는 상태는 같지 않습니다. Railway는 변경을 운영과 분리해 시험할 수 있도록 환경별 서비스와 설정을 격리하며, 변수는 빌드와 실행 과정에 별도로 제공한다고 안내합니다.

견적에는 운영 배포, 도메인, 데이터베이스, 이메일과 외부 서비스 설정을 어디까지 포함하는지 적어야 합니다. 작업이 끝난 뒤 고객이 저장소와 운영 계정을 소유하고 실행·배포·오류 확인 방법을 받을 것인지, 별도 유지보수로 전환할 것인지도 완료 기준에 포함합니다.

견적 요청 시 모든 내용을 완벽하게 확정할 필요는 없습니다. 대신 현재 알고 있는 것과 아직 확인하지 못한 것을 구분해야 합니다. NXLAB은 기능, 데이터, 연동, 검수와 인계 항목마다 확정·가정·제외 상태를 붙여 견적의 전제를 드러냅니다.

확정은 현재 견적에 포함할 구현과 완료 기준, 가정은 자료나 접근 권한을 받은 뒤 검증할 전제, 제외는 첫 출시 뒤 판단할 항목입니다. 가정이 실제와 다르면 영향 범위를 확인한 뒤 변경 절차로 다시 합의합니다. 이 구분이 있으면 불확실성을 숨긴 낮은 견적과 범위가 명확한 견적을 구별하기 쉬워집니다.

업체마다 총액만 받으면 기획, 디자인, 운영 품질과 인계가 어디까지 포함됐는지 비교하기 어렵습니다. 같은 목표와 흐름을 전달하고 기능별 포함·제외, 외부 비용, 수정·검수와 완료 산출물을 같은 항목으로 요청해야 차이를 판단할 수 있습니다.

NXLAB은 해결할 문제, 핵심 사용자 흐름, 역할, 데이터·연동, 운영 환경과 인계 조건을 확인한 뒤 범위와 견적을 제안합니다. 확인하지 않은 가격이나 기간을 먼저 약속하지 않으며, 전문 보안 진단·대량 데이터 정제·복잡한 외부 연동처럼 별도 합의가 필요한 작업은 기본 범위와 구분합니다.