서핑베어
홈 › 블로그 › 개발 견적서 읽기
개발 견적서 읽는 법 — 어디를 봐야 비교가 되는가
견적서 세 장을 놓고 총액만 비교하면 대개 잘못된 선택을 합니다. 총액이 다른 이유는 단가가 아니라 포함 범위인 경우가 많기 때문입니다.
비교 항목 싼 견적의 이유 질문 목록
결론부터
견적서를 읽는 순서는 총액이 마지막입니다. 먼저 볼 것은 범위, 그다음 가정, 그다음 제외 항목입니다. 이 세 가지가 다르면 총액 비교는 의미가 없습니다.
가장 싼 견적이 나쁜 것도 아닙니다. 다만 싼 이유를 알아야 합니다 — 범위를 좁게 읽었거나, 유지보수를 뺐거나, 인력 구성이 다르거나. 이유를 모르는 저가가 위험합니다.
읽는 순서
싼 견적의 흔한 이유 — 어느 것인지 확인한다
| 이유 | 문제 여부 | 확인 질문 |
|---|---|---|
| 범위를 좁게 해석했다 | 문제 | 이 기능이 포함입니까? 견적서 어느 항목입니까? |
| 유지보수·운영이 빠졌다 | 문제 | 납품 후 대응은 별도 계약입니까? 기간과 비용은? |
| 유사 프로젝트 경험이 있어 빠르다 | 괜찮음 | 유사 사례를 볼 수 있습니까? |
| 기존 코드·프레임워크를 재사용한다 | 조건부 | 소유권과 라이선스는 어떻게 됩니까? |
| 주니어 중심 구성이다 | 조건부 | 리뷰 체계와 책임자는 누구입니까? |
| 일정을 낙관적으로 잡았다 | 문제 | 지연 시 조항이 계약에 있습니까? |
반드시 물어볼 질문 다섯 개
비교표를 직접 만든다
견적서 형식은 회사마다 다르므로, 우리 기준의 표로 옮겨야 비교가 됩니다. 행은 우리 요구사항 문서의 기능 목록, 열은 각 개발사. 칸에는 포함·제외·별도 견적을 적습니다.
이 표를 만들면 대개 두 가지가 드러납니다. 어느 개발사가 우리 문서를 제대로 읽었는지, 그리고 우리 문서에서 어느 항목이 애매했는지. 두 번째가 더 값진 정보입니다.
표를 만든 뒤에 총액을 넣습니다. 이 순서를 지키면 "가장 싼 곳"이 아니라 "같은 범위에서 가장 싼 곳"을 고를 수 있습니다.
자주 묻는 질문
견적을 몇 곳에서 받는 것이 좋습니까?
세 곳 정도가 실무적입니다. 두 곳은 편차의 원인을 알기 어렵고, 다섯 곳 이상은 비교 작업 자체가 부담이 됩니다. 중요한 것은 개수보다 같은 문서를 줬는지입니다.
단가(인월)를 비교하면 되지 않습니까?
인월 단가는 참고 지표입니다. 같은 기능을 만드는 데 필요한 인월 수가 회사마다 다르기 때문에, 단가가 낮아도 총액이 높을 수 있습니다. 범위 대비 총액이 기준입니다.
가장 싼 곳을 고르면 안 됩니까?
싼 이유가 확인되면 괜찮습니다. 유사 경험이나 재사용 자산 때문이라면 합리적인 저가입니다. 범위를 좁게 읽었거나 유지보수를 뺀 저가는 나중에 더 비싸집니다.
견적이 예산을 넘으면 어떻게 합니까?
기능 우선순위로 조정하세요. 전체를 깎아달라고 요청하면 품질이나 범위가 조용히 줄어듭니다. 필수만 1차로 하고 선택 기능을 2차로 미루는 편이 결과가 낫습니다.