견적서의 첫 페이지보다 상세내역을 보세요.
“MVP 개발 20,000,000원”처럼 총액만 적힌 견적서는 비교하기 쉽지만 실제 범위를 판단하기 어렵습니다. 사용자 화면 15개인지, 관리자까지 포함하는지, 디자인과 배포는 별도인지에 따라 같은 금액의 의미가 달라집니다.
1. 가장 먼저 ‘무엇을 만드는지’ 확인합니다.
회원, 검색, 신청, 결제, 예약 등 실제 사용자 기능이 요구사항과 일치하는지 확인합니다.
회원조회, 신청처리, 콘텐츠관리, 상태변경 등 운영에 필요한 관리자 범위를 확인합니다.
결제, 문자, 이메일, 지도, 소셜로그인, 공공 API 등 연동 대상과 비용을 확인합니다.
PC 웹, 모바일 웹, 반응형, Android, iOS 중 실제 견적 대상이 무엇인지 확인합니다.
2. ‘개발’이라는 한 단어 안에 무엇이 포함됐는지 확인합니다.
| 항목 | 확인할 질문 | 견적서에서 볼 내용 |
|---|---|---|
| 기획 | 화면과 정책은 누가 정의하나요? | 요구사항 분석, 화면설계, 정책정의 포함 여부 |
| 디자인 | 디자인 시안과 원본도 제공하나요? | UI/UX, 퍼블리싱, 디자인 원본 범위 |
| 개발 | 프론트·백엔드·DB·관리자를 모두 포함하나요? | 개발 대상과 제외 기능 |
| 테스트 | 어떤 환경에서 누가 검수하나요? | 기능·통합·브라우저·기기 테스트 범위 |
| 배포 | 운영환경에 실제 오픈까지 해주나요? | 서버 구축, 배포, 도메인·SSL, 앱 등록 여부 |
3. 견적 총액 밖에서 발생하는 비용도 확인하세요.
클라우드, 문자, 이메일, 지도, 결제, 본인인증 등은 별도 과금될 수 있습니다.
계약 후 화면·기능·정책 변경 시 어떤 기준으로 추가 견적이 발생하는지 확인합니다.
서버 운영, 유지보수, 모니터링, 기술지원 등이 개발비에 포함되는지 확인합니다.
4. 개발 완료 후 무엇을 받는지도 견적 단계에서 확인합니다.
인수인계는 프로젝트 마지막에 갑자기 협의하는 항목이 아닙니다. 필요한 산출물이 있다면 견적 요청과 계약 단계에서부터 명확하게 적는 편이 안전합니다.
5. ‘수정 가능’이라는 표현도 구체적으로 확인하세요.
개발 과정에서 화면 문구를 바꾸는 것과 새로운 업무절차를 추가하는 것은 같은 수정이 아닙니다. 또한 오픈 후 발견된 오류를 고치는 하자보수와 새로운 기능을 추가하는 유지·추가개발도 구분해야 합니다.
| 구분 | 예시 | 확인할 내용 |
|---|---|---|
| 요구사항 구체화 | 기존 기능 내 세부 정책 확정 | 기본 수행범위인지 확인 |
| 요구사항 변경 | 신규 화면·업무흐름·연동 추가 | 추가비용 산정 기준 확인 |
| 하자보수 | 합의된 기능이 정상 동작하지 않음 | 무상 처리 기간·조건 확인 |
| 추가개발 | 오픈 후 새로운 기능 요청 | 별도 견적·유지보수 방식 확인 |
6. 견적서를 받으면 최소한 이것은 체크하세요.
견적서에서 가장 중요한 숫자는 총액이 아니라 ‘포함 범위’입니다.
계약 전에는 금액을 깎는 것보다 무엇이 포함되고, 무엇이 제외되며, 어떤 상황에서 추가비용이 발생하는지 명확히 하는 것이 먼저입니다.