같은 기획서를 세 곳에 보냈는데 3,000만 원, 6,000만 원, 9,000만 원이 돌아왔다면, 세 업체 중 두 곳이 거짓말을 하고 있는 것이 아닙니다. 외주 개발 견적이 업체마다 몇 배씩 벌어지는 이유는, 세 견적서가 애초에 같은 것을 계산하지 않았기 때문입니다. 무엇을 넣고 무엇을 뺐는지가 다르고, 그 차이는 견적서 위에 거의 표시되지 않습니다.
그래서 견적서를 비교하는 일은 가격을 비교하는 일이 아닙니다. 범위를 비교하는 일입니다.
개발사를 알아보시면서 이런 생각 하셨을 겁니다.
"제일 싼 데로 하면 되는 거 아닌가… 근데 왜 이렇게까지 차이가 나지…"
"싸게 계약했다가 나중에 추가금 폭탄 맞는 거 아냐? 지난번에도 그랬는데.."
"견적서에서 뭐가 빠졌는지를 내가 어떻게 알아…"
이 세 가지가 정확히 견적이 갈리는 세 지점입니다. 하나씩 뜯어보겠습니다.
개발 외주 견적에서 인건비는 어떻게 계산되나요?
개발 견적의 바닥에는 공표된 인건비 기준이 깔려 있고, 그 아래로 내려간 견적은 반드시 다른 곳에서 비용을 회수합니다.
한국인공지능·소프트웨어산업협회(KOSA)는 매년 SW기술자 평균임금을 공표합니다. 2026년 적용 기준으로 일 평균임금은 41만 4,762원이며, 전년 대비 4.7% 올랐습니다. 이 금액은 월 20.5일 근무를 기준으로 산출됐고, 기본급뿐 아니라 제수당·상여금·퇴직급여충당금·4대 보험 사업자 부담금까지 포함된 실지급 인건비입니다. (아이티데일리 보도)
직무별로 보면 격차가 뚜렷합니다.
| 직무 | 월 평균임금 |
|---|---|
| IT기획자 | 1,185만 원 |
| IT아키텍트 | 1,110만 원 |
| 응용SW개발자 | 775만 원 |
이 숫자를 프로젝트에 대입해 보겠습니다. 개발자 3명이 3개월 투입되는 앱 프로젝트라면, 응용SW개발자 기준 인건비만 단순 계산으로 약 6,975만 원입니다. 여기에는 기획자도, 디자이너도, 테스터도, 관리 인력도 아직 한 명도 들어가 있지 않습니다.
그런데 같은 프로젝트에 3,000만 원짜리 견적이 나옵니다. 그러면 셋 중 하나입니다. 투입 인원이 더 적거나, 투입 기간이 더 짧거나, 견적에 포함된 범위가 더 좁거나. 대부분은 세 번째입니다.
싼 견적이 거짓말인 경우는 드뭅니다. 다만 그 견적서는 당신이 상상한 것보다 작은 것을 계산하고 있습니다.
계약 후에 추가금이 붙는 이유는 무엇인가요?
추가금은 업체의 태도 문제가 아니라, 견적 시점에 요구사항이 얼마나 확정돼 있었는지의 문제입니다.
소프트웨어 개발에는 다른 산업과 구별되는 특성이 하나 있습니다. 만들어 가면서 요구사항이 구체화된다는 것입니다. 이건 업계의 변명이 아니라 정부 가이드가 전제로 삼고 있는 사실입니다. 과학기술정보통신부가 배포한 공공소프트웨어사업 과업변경 가이드는 소프트웨어사업이 시스템을 구축하는 과정에서 요구사항이 구체화되는 성격을 갖는다는 점을 명시하고, 그래서 사업 기간 중 과업변경이 발생할 수밖에 없다는 전제 위에서 절차를 설계하고 있습니다. (보안뉴스 보도)
같은 가이드는 어떤 변경이 '적정한' 변경인지에 대한 판단 기준도 제시합니다.
- 법령 개정 등 법·제도 변경에 따른 과업변경
- 기술적·정책적 환경 변화에 따른 과업변경
- 수·발주자 간 사업비 조정 없이 수행 가능하다고 합의한 경미한 과업변경
민간 프로젝트에 그대로 적용되는 규정은 아니지만, "어떤 변경까지가 원래 계약 안이고 어디부터가 추가인가"를 사전에 합의해 두는 방식은 그대로 가져올 수 있습니다.
그래서 견적을 볼 때 물어야 할 질문은 "얼마인가"가 아니라 이것입니다.
"이 견적은 어느 시점의, 어느 수준까지 확정된 요구사항을 기준으로 산정된 겁니까?"
이 질문에 문서로 답하지 못하는 견적서는, 금액이 얼마든 아직 견적이 아닙니다.
견적서에서 자주 빠지는 항목은 무엇인가요?
견적 차이의 상당 부분은 기능 목록이 아니라, 기능 목록 바깥에 있는 네 가지에서 발생합니다.
- 기획·설계 — 화면 정의, 데이터 구조 설계, 정책 정리. 이걸 발주사가 다 준비한다는 전제로 뺀 견적이 많습니다.
- 테스트·품질관리 — 기능이 동작하는 것과 품질이 검증된 것은 다릅니다. KOSA 발표에서 IT품질관리자와 IT테스터의 임금 상승률이 가장 높게 나타난 것도 이 역할의 무게가 커졌다는 신호입니다.
- 배포·인프라 — 서버, 도메인, 스토어 심사, 보안 설정. 개발이 끝나도 서비스는 아직 안 열립니다.
- 운영·하자보수 — 오픈 이후 몇 개월을, 어디까지 무상으로 볼 것인가.
받으신 견적서를 지금 옆에 놓고 아래를 체크해 보세요.
견적서 확인 체크리스트 7
- 기획·설계 산출물이 견적에 포함되는가, 발주사 제공 전제인가
- QA·테스트 공수가 별도 항목으로 잡혀 있는가
- 서버·인프라 비용이 견적 안인가 밖인가
- 무상 하자보수 기간이 며칠·몇 개월로 명시돼 있는가
- 요구사항 변경이 발생했을 때의 처리 절차가 문서에 있는가
- 소스코드와 산출물의 소유권이 어디로 귀속되는가
- 프로젝트 종료 후 유지보수 계약 조건이 사전에 제시되는가
이 일곱 개 중 네 개 이상이 비어 있다면, 그 견적서는 싼 게 아니라 아직 다 안 적힌 것입니다.
싼 견적과 비싼 견적은 실제로 무엇이 다른가요?
같은 3,000만 원 차이가 어디에서 생기는지 항목별로 놓고 보면, 가격이 아니라 범위가 다르다는 게 드러납니다.
| 항목 | A사 (저가) | B사 (중간) | C사 (고가) |
|---|---|---|---|
| 기획·설계 | 발주사 제공 전제 | 일부 지원 | 포함 |
| 디자인 | 템플릿 | 부분 커스텀 | 전체 제작 |
| QA·테스트 | 개발자 자체 확인 | 기능 테스트 | 시나리오 기반 QA |
| 배포·인프라 | 별도 | 별도 | 포함 |
| 하자보수 | 1개월 | 3개월 | 6개월 |
| 요구사항 변경 | 전건 추가 견적 | 협의 | 기준 사전 합의 |
세 견적서 모두 정직할 수 있습니다. 문제는 발주사가 A사 견적을 보면서 머릿속으로는 C사 범위를 상상한다는 것입니다. 그 간극이 나중에 추가금과 분쟁으로 돌아옵니다.
크로플이 6단계 프로세스의 첫 단계를 '상담 및 범위 정의'에 두고, 그다음이 곧바로 스토리보드·디자인인 이유가 여기 있습니다. 범위를 문서로 고정하지 않은 상태에서 나온 숫자는 견적이 아니라 희망 사항입니다.
실제로 저희가 맡은 프로젝트 중에는 범위가 처음부터 어그러진 상태로 넘어온 건도 있었습니다. 이미 다른 개발자가 작업하다 멈춘 코드를 이어받는 경우입니다.
"기존 개발자의 코드를 이어받는 까다로운 조건이었음에도 불구하고 결제 기능부터 세부 수정사항까지 깔끔하게 처리해주셨습니다." — 주식회사 에**씨, 크로플 프로젝트 후기
이런 건은 견적을 내는 방식 자체가 다릅니다. 새로 만드는 게 아니라 남이 만든 것의 상태를 먼저 진단해야 하기 때문입니다. 이 주제는 목요일 글에서 따로 다루겠습니다.
견적을 받기 전에 무엇을 준비해야 하나요?
발주사가 세 가지만 정리해서 보내면, 받는 견적의 편차가 눈에 띄게 줄어듭니다.
하나, 화면 목록. 완성도는 낮아도 됩니다. 로그인, 목록, 상세, 결제, 마이페이지처럼 화면 단위로만 적어도 견적의 기준선이 생깁니다.
둘, 반드시 있어야 하는 기능과 없어도 되는 기능의 구분. 이걸 나눠주지 않으면 모든 업체가 각자 다르게 가정합니다. 견적이 3배 벌어지는 가장 흔한 원인입니다.
셋, 오픈 목표일과 그 이유. 투자 심사인지, 지원사업 마감인지, 시즌인지에 따라 설계 전략이 달라집니다.
여기까지 정리가 어렵다면, 그 정리를 함께 해주는 곳을 고르는 게 맞습니다.
"기획의 빈틈을 전문가의 시선으로 메꿔주신 덕분에 프로젝트를 성공적으로 마무리할 수 있었습니다." — via***o, 크로플 프로젝트 후기
어떤 규모의 프로젝트가 어떤 형태로 나왔는지 궁금하시면 크로플이 진행한 프로젝트 사례를 먼저 보셔도 좋습니다. 회사 소개와 진행 방식은 회사소개서 PDF에 정리해 두었습니다.
정리하면
외주 개발 견적의 차이는 업체의 양심 차이가 아니라 견적에 담긴 범위의 차이입니다. 인건비에는 공표된 기준선이 있고, 요구사항은 만들면서 구체화되며, 견적서에서 빠지기 쉬운 항목은 정해져 있습니다. 이 세 가지를 알고 견적서를 보면, 3배 차이의 정체가 대부분 설명됩니다.
가장 위험한 선택은 비싼 견적을 고르는 것도, 싼 견적을 고르는 것도 아닙니다. 범위가 안 적힌 견적서에 도장을 찍는 것입니다.
지금 받아두신 견적서가 있다면, 위 체크리스트 7개를 기준으로 한 번 훑어보시고, 비어 있는 항목이 무엇인지부터 확인해 보세요.
자주 묻는 질문
Q. 외주 개발 견적은 보통 몇 곳에서 받아보는 게 좋나요? 3곳 정도가 적당합니다. 다만 세 곳에 똑같은 자료를 보내야 비교가 성립합니다. 자료가 다르면 견적 차이가 업체 차이인지 자료 차이인지 구분할 수 없습니다.
Q. 견적이 유독 낮은 업체는 걸러야 하나요? 금액만으로 거를 필요는 없습니다. 대신 무엇이 빠져서 낮은지를 물어보시면 됩니다. 답이 명확하면 오히려 합리적인 견적일 수 있고, 답이 흐리면 그게 위험 신호입니다.
Q. 요구사항이 바뀌면 무조건 추가금이 발생하나요? 아닙니다. 계약 시점에 변경 처리 기준을 합의해 두면, 경미한 변경은 조정 없이 흡수하고 중대한 변경만 별도 협의하는 구조를 만들 수 있습니다. 문제는 그 기준이 없는 경우입니다.
Q. 소스코드 소유권은 보통 어디로 가나요? 계약서에 명시하기 나름입니다. 명시하지 않으면 분쟁의 소지가 남으므로, 견적 단계에서 미리 확인하는 것이 안전합니다. 개별 계약의 법적 효력은 전문가 확인이 필요합니다.
글쓴이 · 임호범 — 주식회사 크로플 대표. 기획부터 운영까지 한 팀처럼 움직이는 개발 파트너십을 만들고 있습니다. 크로플은 자체 서비스 알레오를 직접 개발·운영하며 그 경험을 클라이언트 프로젝트에 적용합니다.
