1. 견적이 싸다는 사실보다 ‘왜 싼가?’가 중요합니다.
작은 전문팀이 불필요한 관리비를 줄이고 익숙한 기술을 활용해 효율적으로 개발한다면 충분히 경쟁력 있는 낮은 견적이 나올 수 있습니다. 반대로 요구사항 일부를 제외하거나 테스트와 인수인계를 최소화해서 견적을 낮출 수도 있습니다.
2. 낮은 견적에서 특히 확인할 6가지
관리자, 예외처리, 외부연동 등 필요한 기능 일부가 견적에서 빠져 있을 수 있습니다.
발주자가 완성된 화면설계와 디자인을 제공한다는 전제로 계산했을 수 있습니다.
화면 구현은 되지만 다양한 예외상황과 실제 업무흐름 검증이 부족할 수 있습니다.
계약 후 필요한 기능을 추가할 때 최초 가격 차이보다 더 큰 비용이 발생할 수 있습니다.
소스·DB·계정·문서 이전이 불명확하면 업체 변경 시 비용이 커질 수 있습니다.
실제 필요한 작업량보다 적게 산정하면 일정 지연이나 품질 저하로 이어질 수 있습니다.
3. 계약금액이 아니라 ‘서비스를 오픈하는 총비용’을 비교하세요.
처음 계약할 때 보이는 금액
누락 기능과 변경에 드는 비용
오픈 지연으로 생기는 사업 영향
품질 문제를 다시 수정하는 비용
유지보수와 업체 변경에 드는 비용
예를 들어 1,000만 원 견적에 관리자·배포·인수인계가 빠져 있고 이후 800만 원이 추가된다면 처음의 가격 차이는 의미가 달라집니다. 반대로 1,000만 원 안에 필요한 범위가 모두 명확하게 포함되어 있다면 충분히 좋은 선택일 수 있습니다.
4. 이런 저가 견적은 오히려 합리적일 수 있습니다.
| 상황 | 왜 가격을 낮출 수 있나? | 확인할 것 |
|---|---|---|
| 범위가 매우 명확함 | 기획·변경 리스크가 작음 | 요구사항 문서와 결과물이 일치하는지 |
| 유사 프로젝트 경험이 많음 | 설계·개발 시행착오가 적음 | 실제 유사 수행사례와 담당자 경험 |
| 소규모 전문팀 | 관리·영업 간접비가 낮을 수 있음 | 실제 투입인력과 프로젝트 대응체계 |
| 기존 컴포넌트 활용 | 반복 개발을 줄일 수 있음 | 라이선스와 향후 수정·인수 조건 |
| MVP 범위를 의도적으로 축소 | 핵심 검증 기능만 개발 | 제외 기능이 명확하게 합의됐는지 |
5. 업체를 가격 하나로 점수화하지 마세요.
평가 비중은 프로젝트마다 달라질 수 있지만, 최소한 가격 외의 항목을 같은 표에 놓고 비교하는 것이 좋습니다.
위 비율은 예시입니다. 핵심은 평가표 자체보다 “가격이 싸다”를 다른 모든 판단 기준보다 앞에 두지 않는 것입니다.
6. 최저가 업체와 계약하기 전 체크리스트
최저가가 위험한 것이 아니라, 가격만 보고 선택하는 것이 위험합니다.
좋은 업체는 반드시 비싼 업체도, 가장 싼 업체도 아닙니다. 필요한 범위를 이해하고 그 범위를 현실적인 가격·일정·수행방식으로 설명할 수 있는 업체를 선택하세요.