외주 개발 견적을 3~5곳에서 받아 보면 가격이 2~3배 차이 나는 일은 흔합니다. 많은 의뢰자가 "그럼 가장 싼 곳?"으로 결론 내리지만, 이 선택이 프로젝트 실패로 이어지는 경우도 많이 봤습니다. 견적은 가격이 아니라 "어떻게 만들 것인가"의 번역문입니다. 견적을 읽는 5가지 기준을 공유합니다.
기준 1 — 포함 범위가 구체적인가
"로그인·회원가입·결제·관리자 포함" 같은 한 줄 리스트는 위험 신호. 좋은 견적은 기능별로 세부 항목·예상 시간·전제 조건이 적혀 있습니다. 모호한 견적일수록 나중에 "그건 포함 아니에요"가 많이 나옵니다.
기준 2 — 제외 항목(Out of scope)이 명시돼 있는가
좋은 견적에는 반드시 "이건 안 합니다" 섹션이 있습니다. 의뢰자가 당연히 포함이라 생각했던 것(예: 광고 추적 코드 삽입, 앱스토어 심사 대응)이 빠져 있으면 나중에 추가 비용이 붙습니다. 제외가 안 적힌 견적은 사실 범위가 정해지지 않은 것입니다.
기준 3 — 산정 근거가 설명되는가
"프런트 개발 500만 원"처럼 덩어리 단가가 아니라 화면 수 × 평균 공수 × 단가 구조로 풀어 쓰는 견적이 신뢰도 높습니다. 공수를 숨기는 견적은 협상도 어렵고, 범위 변경 시 기준점이 없어 재견적이 주먹구구가 됩니다.
기준 4 — 인력 구성이 맞는가
한 사람이 프런트·백·디자인·배포를 다 하는 소형팀과, 역할별 담당자가 나눠진 중대형팀은 단가 구조가 다릅니다. 소형팀이 무조건 나쁜 것도, 대형팀이 무조건 좋은 것도 아닙니다. 프로젝트 규모와 맞는지가 중요합니다. 소규모 MVP에 대형팀을 쓰면 커뮤니케이션 비용이 품질보다 커집니다.
기준 5 — 유지보수·추가 요금 조건
"개발 완료 후 1개월 무상 유지보수"까지는 표준. 그 안에 포함되는 것(버그 수정)과 포함되지 않는 것(신기능·대규모 개선)의 구분이 적혀 있는가. 이후 유상 유지보수의 시간당 단가가 견적서에 있는 쪽이 투명합니다.
싼 견적이 위험한 3가지 신호
- "우리는 템플릿으로 빨리 만듭니다": 템플릿이 나쁜 게 아니지만, 커스터마이징이 필요한 제품에 템플릿을 고집하면 중간에 벽에 부딪힙니다.
- "디자인도 다 해드려요" + 단가가 극단적으로 낮음: 디자인은 제대로 하면 개발 못지않게 시간이 드는 작업. 극저가에 포함된다면 대부분 품질이 떨어집니다.
- 질문 없이 견적 먼저 나옴: 좋은 개발사는 견적 내기 전에 반드시 요구사항을 질문합니다. 물어보지 않고 견적이 먼저 나오면 "일단 수주해 보자"에 가깝습니다.
비싼 견적이 꼭 좋은 것도 아닙니다
- 인력 단가가 높다고 품질이 비례하지 않음. 팀 구성·실무자 실력을 확인.
- 대기업 관리비·영업비가 단가에 붙어 있는 경우. MVP엔 과잉.
- "유명한 회사" 프리미엄. 레퍼런스로 눈을 끌지만 막상 실무자가 주니어인 경우 많음.
추천 프로세스
- 3~5곳에 같은 요구사항 문서를 보낸다.
- 견적서에 위 5가지 기준이 있는지 체크한다.
- 가장 싼 곳과 가장 비싼 곳을 후보에서 빼고, 중간 2~3곳을 인터뷰한다.
- 실무자(PM 아님)와 1회 이상 대화한다.
- 이전 작업 3건의 실제 운영 URL을 달라고 한다.
한 줄로
견적의 숫자는 답이 아니라 질문입니다. 그 숫자가 나온 이유가 설명되지 않는 견적은 저렴해서 위험하고 비싸서도 위험합니다. 견적을 읽는 힘 그 자체가 외주 성공률을 크게 좌우합니다.