견적서에 적힌 총액만 비교하면 정작 중요한 차이를 놓치기 쉽습니다. 같은 기능이어도 산정 기준이 다르면 금액 차이가 크게 날 수 있습니다. 견적을 볼 때 확인해야 할 것들과, 견적 산정 방식의 차이까지 정리했습니다.
1. 개발비는 "기능 개수"가 아니라 "복잡도"로 결정됩니다
화면 수가 같아도 데이터 구조, 외부 연동, 예외 처리 범위에 따라 공수는 크게 달라집니다. 견적서에 화면 수만 적혀 있다면, 어떤 기준으로 복잡도를 산정했는지 물어보는 게 좋습니다. 예를 들어 화면 10개짜리 단순 게시판과, 화면 10개짜리 실시간 예약 시스템은 겉보기 규모는 비슷해도 실제 개발 공수는 몇 배 차이가 날 수 있습니다.
2. 견적 산정 방식도 함께 확인하기
같은 프로젝트라도 어떤 방식으로 비용을 산정하느냐에 따라 계약 구조가 달라집니다. 어느 방식이 무조건 좋다기보다, 프로젝트 성격에 맞는 방식인지가 중요합니다.
| 방식 | 설명 | 적합한 경우 |
|---|---|---|
| 정액제(도급) | 정해진 범위를 정해진 금액으로 계약 | 기능 범위가 명확히 정리된 프로젝트 |
| 시간 정산(맨먼스) | 투입 인력·기간에 따라 비용 정산 | 범위가 계속 바뀔 가능성이 큰 프로젝트 |
| 스프린트 단위(애자일) | 일정 주기마다 우선순위를 다시 정해 진행 | 가설 검증이 필요한 초기 서비스, MVP |
기획이 아직 유동적인 상태에서 정액제로 계약하면, 범위가 조금만 바뀌어도 추가 견적 논의가 반복될 수 있습니다. 반대로 범위가 이미 명확한 프로젝트를 시간 정산으로 진행하면 총비용을 예측하기 어려워집니다. 저희는 보통 기획 완성도에 맞춰 방식을 함께 제안드립니다.
3. 견적에 포함된 범위를 명확히 확인하기
- 기획·설계 공수가 포함되어 있는지
- 디자인(UI/UX) 작업이 별도인지
- QA·테스트 기간이 포함되어 있는지
- 배포·서버 설정 등 인프라 작업 포함 여부
- 오픈 이후 일정 기간의 무상 하자보수 포함 여부
이 항목들이 견적서에 명시되어 있지 않다고 해서 무조건 문제인 것은 아닙니다. 다만 "포함되어 있는지 아닌지"를 알 수 없는 상태로 계약하면, 나중에 어느 한쪽은 "당연히 포함된 줄 알았다"고 생각하게 됩니다. 계약 전에 이 다섯 가지만 짚어봐도 대부분의 오해를 예방할 수 있습니다.
4. 낮은 견적이 항상 유리한 건 아닙니다
동일한 범위인데 유독 낮은 견적이 있다면, 실제로는 범위가 좁게 잡혀 있거나 추후 추가 비용이 발생할 가능성이 높습니다. 총액보다 "무엇이 포함되고 무엇이 빠졌는지"를 비교하는 게 정확합니다. 여러 견적을 비교할 때는 총액을 나란히 놓기보다, 위에서 확인한 항목들을 기준으로 표를 만들어 비교해보시면 실제 차이가 훨씬 선명하게 보입니다.
5. 견적은 기획서의 완성도에 비례합니다
기획이 구체적일수록 견적의 오차 범위도 줄어듭니다. 반대로 아이디어 단계라면, 정확한 견적보다는 예상 범위(레인지)로 먼저 받아보는 것을 권장합니다. 기획서를 어떻게 준비하면 좋은지는 별도로 자세히 정리해두었으니, 함께 참고하시면 도움이 됩니다.
정확한 견적이 필요하시다면, 지금 갖고 계신 자료가 무엇이든 편하게 공유해 주세요. 범위를 함께 정리해드립니다.