외주 개발 견적을 받으면 가장 먼저 드는 생각. "이게 비싼 건지, 싼 건지 모르겠다." 같은 프로젝트인데 업체마다 2배, 3배 차이가 나기도 합니다. 외주 개발 견적을 판단하는 실전 기준을 정리합니다.

외주 개발은 공산품이 아니다 — 가격만으로는 결과물을 알 수 없습니다

외주 개발 견적을 비교할 때 가장 먼저 짚어야 할 것은, 외주 개발은 공산품이 아니라는 점입니다. 같은 모델 번호의 휴대폰처럼 사양이 표준화된 물건이 아니기 때문에 단순히 가격만 놓고 비교하면 정확히 거꾸로 판단하게 되는 일이 흔합니다.

쇼핑몰을 예로 들어 보겠습니다. A 업체에서 1,000만 원, B 업체에서 6,000만 원 견적이 나왔다고 가정합니다. 그러면 6,000만 원 쪽이 6배 비싸 보입니다. 그런데 안에 들어 있는 작업을 열어 보면 두 견적이 같은 결과물을 만들고 있는 게 아닐 가능성이 높습니다.

1,000만 원 견적은 그누보드·카페24·아임웹 같은 기존 솔루션 위에 스킨만 갈아 끼우는 작업인 경우가 많습니다. 이 경우엔 1,000만 원도 사실 비싼 가격입니다. 솔루션이 제공하는 디자인 템플릿을 약간 손보는 일이라 자체 개발 비중이 거의 없기 때문입니다.

반대로 6,000만 원 견적이 해당 쇼핑몰의 사업 모델에 맞춰 백엔드·프론트엔드·인프라를 처음부터 설계해 만드는 작업이라면, 그 가격은 오히려 합리적이거나 쌀 수도 있습니다. 솔루션 위에서는 만들 수 없는 결제·재고·정산·운영 자동화·데이터 모델까지 모두 사업에 맞게 짜는 일이기 때문입니다.

즉 1,000만 원이 비싸고 6,000만 원이 쌀 수도 있다는 뜻입니다.

비싼 게 항상 답은 아니다 — 같은 그레이드 안에서 비교해야 합니다

여기서 자연스럽게 따라오는 결론이 있습니다. 1,000만 원짜리 개발사와 6,000만 원짜리 개발사는 사실상 다른 제품을 파는 회사이기 때문에, 두 견적을 직접 비교하는 것 자체가 의미가 없습니다. 사과와 오렌지를 가격으로 비교하는 셈입니다. 견적 비교는 같은 그레이드 안에서만 의미를 가집니다.

그래서 절차는 순서가 정해져 있습니다. 첫째, 우리가 무엇을 만들 것인지 — 어떤 그레이드 안에서 풀어야 하는 문제인지 먼저 정해야 합니다. 그리고 그 답은 비즈니스 단계가 정합니다.

사업이 막 시작해 시장 반응을 먼저 보고 싶거나, 쇼핑몰의 핵심 기능(상품 등록·결제·배송·관리자) 정도면 충분한 상황에서는 그누보드·카페24·아임웹 같은 솔루션 그레이드가 가장 합리적입니다. 솔루션이 이미 대부분의 기능을 제공하기 때문에 굳이 맞춤형을 들여올 이유가 없습니다. 반대로 사업이 자라면서 솔루션이 가정한 결제·재고·정산·운영 자동화 모델이 사업과 어긋나기 시작하면, 그때부터가 맞춤형 그레이드로 넘어가는 자리입니다. 그 전에 미리 들이는 건 오히려 과한 비용입니다.

둘째, 그 그레이드에 해당하는 제품을 실제로 만드는 개발사를 후보로 좁힙니다. 솔루션 그레이드라면 솔루션 작업이 주력인 회사들, 맞춤형 그레이드라면 자체 백엔드·프론트엔드·인프라 설계까지 처음부터 가는 회사들 — 영역 자체가 다른 회사들입니다. 한쪽 그레이드 회사에 다른 그레이드 일을 맡기는 것 자체가 처음부터 어긋난 출발입니다.

셋째, 같은 그레이드 안에서 비로소 의미 있는 비교가 시작됩니다. 견적서에 무엇이 포함되어 있는지, 개발사의 포트폴리오는 어떤지, 해당 도메인의 개발 경험은 충분한지, 가격이 시장 평균 대비 합리적인지를 같이 봅니다. 비슷한 규모·성격의 결과물을 실제로 만든 적이 있는지, 그 결과물이 운영 단계에서도 잘 굴러갔는지, 그리고 가격이 합리적인지 — 이 셋이 함께 맞아야 안전한 선택이 됩니다.

같은 그레이드 안에서 견적서를 비교하는 5가지 축

3단계 절차의 마지막 — 같은 그레이드 안에서 비교 — 가 실제로 어떤 모습인지 풀어 봅니다. 같은 그레이드의 견적이라도 결과물의 품질·안정성·총 비용은 보통 다섯 축에서 갈립니다. 이 축들이 견적서와 미팅에서 드러나는 방식을 알아야 같은 그레이드 안에서도 안전한 회사를 골라낼 수 있습니다.

1. 투입 인력의 직급과 경력

"프론트엔드 개발 1명" 이 아니라, 실제 투입되는 개발자의 경력 수준을 확인합니다. 주니어(1~3년) 와 시니어(7년+) 의 생산성 차이는 단순한 속도가 아닙니다. 시니어는 설계 단계에서 운영 이슈를 예방하고, 기술 선택에서 실수를 줄여 — 나중에 발생할 비용을 미리 아낍니다.

질문: "실제 이 프로젝트에 투입되는 개발자의 경력은 어느 정도인가요? 미팅에 나오신 분이 직접 개발하시나요?"

2. 재하청 여부

견적 금액의 높고 낮음과는 별개로, 재하청 구조 자체가 위험 신호입니다. A사가 계약을 따서 일부를 B사에 넘기고, B사가 다시 C 에게 넘기는 구조에서는 단계마다 마진이 붙기 때문에 — 가격이 더 낮아진다고 단정할 수도 없고, 같은 결과물에 오히려 더 비싼 값을 치르는 경우도 있습니다. 진짜 문제는 가격이 아니라 책임 소재가 흐려진다는 점입니다. 실제로 코드를 작성하는 사람이 누구인지, 그 사람의 역량은 어느 정도인지, 운영 단계에서 문제가 생기면 누구에게 요청해야 하는지가 모두 분명하지 않게 됩니다. 요구사항도 단계를 거치며 의도가 변형되고, 수정 요청은 같은 경로를 거꾸로 돌아옵니다. 같은 가격이라면 사내에서 직접 개발하는 회사 쪽이 거의 항상 더 안전합니다.

질문: "개발은 전부 사내 인력으로 진행하시나요? 외부 파트너사에 위탁하는 작업이 있다면 어느 부분인가요?"

3. 요구사항 범위의 명확성

같은 "쇼핑몰 개발" 이라도 회원가입(소셜 로그인 포함?)·상품 관리(엑셀 일괄 업로드?)·결제(어떤 PG?)·배송 조회(택배사 API 연동?)·관리자 페이지(어디까지?)·반응형(모바일 앱도?) 같은 항목이 포함될 수도, 안 될 수도 있습니다. 견적서에 이 범위가 명시되어 있지 않으면 나중에 "그건 별도입니다" 를 듣게 됩니다.

질문: "견적에 포함된 기능 목록을 상세하게 받을 수 있을까요? 포함되지 않는 항목도 명시해 주세요."

4. 중간 산출물과 검수 방법

3개월 프로젝트에서 중간 확인 없이 최종 납품만 하겠다는 업체는 피하는 것이 좋습니다. 격주 또는 월 1회라도 실제 동작하는 결과물을 확인할 수 있어야 합니다. 스크린샷이 아니라 동작하는 코드를 보여줄 수 있는지 확인합니다.

질문: "개발 진행 중에 동작하는 결과물을 직접 확인할 수 있나요? 어떤 주기로 공유하시나요?"

5. 사후 지원 범위

개발이 끝나도 프로젝트는 끝나지 않습니다. 운영 중 발견되는 버그, 소소한 수정 요청, 서버 이슈 — 무상 버그 수정 기간이 어디까지인지, 기능 추가는 별도 계약인지, 서버 운영·관리 범위는 어디까지인지, 소스 코드 인수인계가 가능한지 견적에서 확인합니다.

질문: "납품 후 버그 수정은 어느 기간까지 무상인가요? 소스 코드는 전부 전달받을 수 있나요?"

잘못된 선택의 비용 — 그레이드부터 같은 그레이드 안의 함정까지

외주 개발에서 가장 비싼 비용은 "다시 만드는 비용" 이고, 이 비용은 두 단계에서 발생합니다.

첫째, 그레이드를 잘못 고른 경우입니다. 사업이 솔루션 그레이드로 충분한데 맞춤형으로 들어가면 들인 비용 대비 사업이 실제로 활용하는 부분이 일부에 그칩니다. 반대로 솔루션이 가정한 모델로 더 이상 풀 수 없는 사업을 솔루션 그레이드에 억지로 끼워 맞추면, 운영 비효율이 누적되다가 결국 맞춤형으로 통째로 갈아엎는 비용이 따라붙습니다. 그레이드가 맞지 않은 채 1년을 끌고 가면, 나중의 마이그레이션 비용이 처음 견적의 몇 배가 되는 경우가 많습니다.

둘째, 같은 그레이드 안에서 잘못 고른 경우입니다. 같은 그레이드 안에서도 개발사마다 결과물 품질 차이가 큽니다. 2,000만 원짜리 맞춤형 개발사에 맡겼다가 결과물 문제로 같은 그레이드의 다른 회사에 몇천만 원을 더 들여 다시 시작하는 경우 — 또는 그조차 못 가고, 출시 전부터 문제가 계속 터지며 시간이 흘러 사업 시기를 놓친 채 프로젝트가 그대로 드랍되는 경우 — 너무 흔히 보입니다. 같은 그레이드 안에서 낮은 견적이 무조건 위험한 것도, 높은 견적이 안전을 보장하는 것도 아닙니다. 비싼 가격을 받고도 부실한 결과물을 내거나 사기에 가까운 경우도 적지 않습니다. 낮은 견적이라면 어디서 비용을 절감했는지, 높은 견적이라면 그 값이 어디서 나오는지 — 어느 쪽이든 위 다섯 축으로 다방면으로 면밀히 검토해야 합니다.

특히 '뭐든 다 된다' 는 식의 견적은 가장 조심해야 합니다. 어떤 예산이든 맞추고, 어떤 기능이든 만들고, 어떤 일정이든 가능하다 — 모든 요구를 선심 쓰듯 다 받는 견적입니다. 메커니즘은 단순합니다. 애초에 들어줄 생각이 없기 때문에 무엇이든 가능하다고 답할 수 있고, 실제로 줄 가치가 0 이라 약속의 크기에는 아무 비용도 따라붙지 않습니다. 사기꾼이 시장에서 끊이지 않는 이유도 여기에 있습니다 — 그들이 약속하는 '가상의 제품' 은 실제로 만들 부담이 없기 때문에 이 세상 어떤 실제 제품보다 항상 더 경쟁력 있게 보입니다. 정작 진지하게 만드는 정직한 개발사는 예산·일정·범위 사이의 트레이드오프를 솔직하게 말할 수밖에 없고, 그렇게 피땀 흘려 짠 견적이 '뭐든 된다' 는 견적 옆에 나란히 놓여 묻히는 경우를 자주 봅니다. 솔직함이 보이지 않는 견적은 만들 사람이 직접 쓴 게 아닐 가능성이 높습니다.

그레이드별 시장 가격 감각

정해진 공식은 없지만, 그레이드별로 시장에서 통용되는 대략적인 가격 감각이 있습니다.

솔루션 그레이드 — 그누보드·카페24·아임웹 같은 솔루션 위에서 디자인·기능 customization. 쇼핑몰 기준 수백만 원 ~ 1,000만 원대가 일반적이고, 복잡한 customization 이 더해지면 2,000만 원대까지 올라갑니다.

맞춤형 그레이드 — 자체 백엔드·프론트엔드·인프라 설계. 중규모 쇼핑몰 기준 5,000만 원 ~ 1억 원대가 일반적이고, 결제·정산·운영 자동화가 깊어질수록 1억 원대 이상으로 올라갑니다.

이 범위를 크게 벗어나는 견적은 보통 그레이드 자체가 다르거나, 같은 그레이드 안의 인력 수준·재하청·SI 오버헤드 같은 구조 차이에서 옵니다.

정리

외주 개발 견적 판단은 가격 비교가 아니라 그레이드 안에서의 비교입니다. 절차는 셋입니다.

• ① 무엇을 만들 것인가 — 비즈니스 단계가 솔루션 그레이드인지 맞춤형 그레이드인지 정해줍니다
• ② 누가 만드는가 — 그 그레이드를 주력으로 하는 개발사 후보로 좁힙니다
• ③ 어떻게 비교하는가 — 같은 그레이드 안에서 인력·재하청·요구사항 범위·중간 산출물·사후 지원의 5축을 견적서에서 확인합니다

이 셋만 순서대로 따라가면 "이 견적이 합리적인가" 라는 질문에 자기 사업의 맥락에서 답할 수 있습니다.

*견적에 대해 궁금한 점이 있다면, 프로젝트 상담을 통해 편하게 문의해 주세요. 개발 계약과 무관하게 견적 관련 자문을 제공합니다.*