소프트웨어 외주개발 견적은 왜 프로젝트마다 다를까요 | 실제 6개 유형 비교
같은 '소프트웨어 개발'인데 견적이 몇 배씩 차이 나는 이유를 실제 프로젝트 6개 유형(데스크톱 유틸리티·공공 앱·하드웨어 연동·실시간 시스템·양면 플랫폼·커머스)으로 비교했어요. 유형별로 견적을 가르는 요인과 견적서에서 확인할 항목을 정리했어요.
“소프트웨어 개발 외주 견적을 받아봤는데, 어디는 3천만 원이고 어디는 9천만 원이래요.”
발주를 앞두고 가장 많이 듣는 이야기예요. 그리고 대부분 이렇게 결론을 내리시더라고요. “비싼 곳은 거품이 있고, 싼 곳은 뭔가 빠져 있겠지.”
절반만 맞아요. 견적이 갈리는 더 큰 이유는 프로젝트의 유형이 서로 다른 일이기 때문이에요. 겉으로는 다 “소프트웨어 개발”이지만, 안에서 검증해야 할 것의 양이 유형마다 몇 배씩 차이가 나요.
저희는 11년 넘게 개발 외주와 자체 서비스 운영을 함께 해오면서 성격이 전혀 다른 프로젝트들을 진행했어요. 데스크톱 유틸리티, 공공 연구기관 앱, 하드웨어와 통신하는 앱, 실시간 운영 시스템, 양면 매칭 플랫폼, 커머스 리뉴얼까지요. 이 여섯 가지를 놓고 무엇이 견적을 가르는지 정리해봤어요.
먼저 요약하면
- 견적을 가르는 건 화면 수가 아니라 검증해야 할 조합의 수예요.
- 여러 운영체제 지원, 물리 기기 통신, 실시간 처리, 두 종류의 사용자 — 이 네 가지가 붙을 때마다 테스트 범위가 배로 늘어나요.
- 총액만 비교하면 안 되고, 설계·QA·인수인계·하자보수가 포함됐는지를 맞춰놓고 비교해야 해요.
- 공개 시장 자료 기준 일반적인 범위는 MVP 500만
3,000만 원, 정식 버전 3,000만1억 원+ 정도예요(프로젝트별 편차가 커요).
1. 견적이 갈리는 진짜 이유
개발 견적은 대체로 어떤 역할이 몇 개월 투입되는가로 산정돼요. 기획자 1개월, 디자이너 1.5개월, 개발자 3개월, 이런 식이죠. 그래서 “화면이 20개니까 얼마”라는 계산이 통할 것 같지만, 실제로는 잘 맞지 않아요.
같은 화면 20개라도 확인해야 할 경우의 수가 다르기 때문이에요. 웹 브라우저에서만 돌아가면 되는 화면 20개와, Windows와 Mac 양쪽에서 각각 여러 버전을 확인해야 하는 화면 20개는 전혀 다른 일이에요. 후자는 개발 시간보다 검증 시간이 훨씬 길어져요.
견적을 크게 흔드는 요인은 대체로 이 넷이에요.
| 요인 | 왜 비용이 올라가나 |
|---|---|
| 지원해야 할 환경의 수 | 운영체제·기기·브라우저가 늘수록 확인할 조합이 곱으로 늘어나요 |
| 물리적 기기와의 통신 | 화면 안에서 끝나지 않고 실제 기기로 매번 검증해야 해요 |
| 실시간 처리 여부 | 값이 계속 바뀌므로 “언제 어긋나는지”까지 설계해야 해요 |
| 사용자 종류의 수 | 공급자·수요자·관리자가 나뉘면 흐름을 각각 설계해야 해요 |
2. 유형별로 견적이 어떻게 달라지나요
저희가 실제로 진행한 프로젝트를 유형별로 놓고, 각 유형에서 무엇이 비용을 만들었는지 정리했어요.
| 유형 | 실제 프로젝트 | 견적을 좌우한 요인 |
|---|---|---|
| 데스크톱 유틸리티 | 캐논코리아 카메라 펌웨어 업데이트 도구 (Windows·Mac, 2022) | 두 운영체제 각각의 동작 검증, 기기 상태에 따른 예외 처리 |
| 공공·연구기관 앱 | 한국건설기술연구원 토양 특성 평가 앱 (Android, 2023) | 데이터 정확도 요구, 현장 수집 환경의 변수, 공공 발주 절차 |
| 하드웨어 연동 앱 | 코닥 인스턴트 프린터 블루투스 연동 앱 (iOS, 2020) | 실제 기기와의 통신 안정성, 연결 실패 상황의 처리 |
| 실시간 운영 시스템 | 롯데백화점 수원 푸드홀 혼잡도 관리 (웹 기반 SI, 2024) | 수집·집계·판정 기준 정의, 기존 시스템 연동 협의 |
| 양면 매칭 플랫폼 | 건설현장 인력 매칭 플랫폼 (Android·iOS·웹) | 공급자·수요자 양쪽 흐름 설계, 정산과 분쟁 처리 |
| 커머스 리뉴얼 | 건설장비 쇼핑 플랫폼 지구조각가 (웹·앱, 2025) | 복잡한 상품 정보 구조, 웹과 앱의 경험 일치 |
데스크톱 유틸리티 — 환경의 수가 곧 비용이에요
화면 수만 보면 가장 단출한 축에 속해요. 그런데 Windows와 Mac을 함께 지원하면 이야기가 달라져요. 두 운영체제는 파일 접근 방식도, 권한 처리도, 설치 흐름도 달라서 사실상 두 번 검증해야 해요.
여기에 기기 상태라는 변수가 붙어요. 사용자의 기기가 어떤 상태인지에 따라 벌어질 수 있는 상황을 미리 정리해두지 않으면, 출시 후에 “특정 환경에서만 안 된다”는 문의가 이어져요. 자세한 과정은 캐논코리아 펌웨어 유틸리티 사례에 정리해뒀어요.
공공·연구기관 앱 — 정확도 요구가 공수를 만들어요
사용자 수는 많지 않아요. 그래서 언뜻 저렴해 보이지만, 실제로는 그렇지 않은 경우가 많아요. 데이터의 정확도가 곧 연구 결과의 신뢰도가 되기 때문에, 일반 앱이라면 넘어갈 수준의 오차도 여기서는 넘어갈 수 없거든요.
현장에서 수집하는 데이터를 다루면 예상 못 한 변수도 자주 등장해요. 이런 프로젝트는 개발 자체보다 기준을 정의하는 초반 과정에 시간이 더 들어요. 구체적인 내용은 연구기관 앱 개발 사례에서 다뤘어요.
하드웨어 연동 앱 — 앱 밖에서 끝나요
화면 설계보다 앞서는 질문이 있어요. “이 기기와 이 앱이 매번 제대로 연결되는가”예요. 블루투스로 붙는 프로젝트는 연결이 되는 것보다 연결이 끊겼을 때 어떻게 되는지를 설계하는 데 더 많은 공수가 들어가요.
그리고 이런 검증은 시뮬레이터로 끝나지 않아요. 실제 기기를 놓고 반복해서 확인해야 해서, 견적서의 QA 항목이 다른 유형보다 두툼해지는 게 정상이에요. 관련 내용은 하드웨어 연동 앱 사례에 있어요.
실시간 운영 시스템 — 기준을 정하는 일이 절반이에요
실시간 시스템은 “값을 보여주는 것”이 어려운 게 아니에요. 무엇을 기준으로 혼잡하다고 판정할지를 정하는 게 어려워요. 이 기준이 정해지지 않은 채로 개발을 시작하면, 개발보다 조율에 시간이 더 들어가요.
기존에 운영 중인 시스템과 연동해야 한다면 연동 협의 자체를 일정에 포함해야 해요. 여러 시스템이 얽힌 환경일수록 이 과정이 길어지거든요. 실시간 혼잡도 시스템 사례에서 더 자세히 정리했어요.
양면 매칭 플랫폼 — 시장 하나를 여는 일이에요
“매칭 앱 하나 만들려고 하는데요”로 시작하는 상담이 많아요. 그런데 매칭 서비스는 앱을 만드는 일이라기보다 작은 시장 하나를 여는 일에 가까워요. 공급자와 수요자 양쪽의 흐름을 각각 설계해야 하고, 거래가 일어나면 정산과 분쟁 처리까지 따라와요.
그래서 화면 수 대비 견적이 높게 나오는 게 자연스러워요. 자세한 이야기는 매칭 플랫폼 구축 사례와 중개 플랫폼 개발 비용에서 다뤘어요.
커머스 리뉴얼 — 흩어진 경험을 잇는 비용
이미 운영 중인 서비스를 리뉴얼하는 일은 새로 만드는 것과 다른 어려움이 있어요. 기존 데이터를 가져와야 하고, 쓰던 사용자가 낯설어하지 않아야 하고, 웹과 앱의 경험이 어긋나지 않아야 해요. 건설장비 쇼핑 플랫폼 리뉴얼 사례에 과정을 정리해뒀어요.
3. 견적서에서 반드시 확인할 항목
유형을 파악했다면, 이제 받은 견적서들을 같은 조건으로 맞춰놓고 비교할 차례예요. 아래 항목 중 하나라도 비어 있으면 명시를 요청하세요. 빠져 있다는 사실 자체가 중요한 비교 정보예요.
- 범위: 어떤 화면과 기능이 포함되고, 무엇이 제외됐는지
- 설계·기획: 포함인지 별도인지
- QA(테스트): 포함 여부와 검증 범위 (특히 기기 연동·다중 환경 프로젝트)
- 디자인: 화면 수와 수정 가능 횟수
- 인수인계: 소스코드·문서·계정·배포 방법이 포함되는지
- 하자보수: 기간과 포함되는 문제의 범위
- 유지보수: 단가나 시간당 요율이 명시됐는지
- 결제 조건: 선금·중도금·잔금이 산출물 인도 시점과 연결됐는지
이 항목들을 표로 정리해 비교하고 싶으시면, 발주 가이드북에 견적 비교표 양식을 넣어뒀어요. 인쇄해서 그대로 채워 쓰실 수 있어요.
4. 같은 조건으로 비교하는 법
견적 비교에서 가장 흔한 실수는 총액을 먼저 보는 것이에요. 순서를 바꾸면 판단이 훨씬 쉬워져요.
- 유형을 먼저 확정하세요. 우리 프로젝트가 위 여섯 유형 중 어디에 가까운지, 그리고 검증 부담을 만드는 요인(환경 수·기기 통신·실시간·사용자 종류)이 몇 개나 붙는지 확인해요.
- 항목을 맞추세요. 설계·QA·인수인계·하자보수가 포함된 견적과 빠진 견적을 나란히 놓으면 안 돼요.
- 그다음에 총액을 보세요. 이 순서로 보면 “싼 곳”이 아니라 “같은 조건에서 합리적인 곳”이 보여요.
- 되묻는 질문의 질을 보세요. 요구사항을 그대로 받아 적기만 하는 곳과, 애매한 지점을 짚어 되묻는 곳은 프로젝트 진행 중에 전혀 다른 결과를 만들어요.
마지막 항목이 의외로 중요해요. 저희 경험상 초반에 “이 부분은 이렇게 이해했는데 맞나요?” 라고 확인하는 과정이 있었던 프로젝트가 끝까지 어긋남이 적었어요.
정리하면
견적이 다른 건 대부분 개발사가 달라서가 아니라 프로젝트의 성격이 달라서예요. 우리 프로젝트에 어떤 검증 부담이 붙는지를 먼저 파악하면, 받은 견적이 비싼지 싼지가 아니라 말이 되는지 아닌지가 보이기 시작해요.
저희는 개발 외주와 함께 자체 서비스 4종을 11년 넘게 직접 운영해오면서, 만드는 단계뿐 아니라 오픈 이후에 무엇이 비용이 되는지도 겪어봤어요. 지금 준비 중인 프로젝트가 어떤 유형에 가깝고 무엇을 미리 정해두어야 할지 함께 짚어드릴 수 있어요.