외주개발

같은 기획안을 보내고 같은 기능을 설명했는데도, 돌아온 모바일 앱 개발 견적이 업체마다 크게 다른 경우가 있습니다. 한쪽은 충분히 만들 수 있다고 하고, 다른 쪽은 그 범위로는 불가능하다고 합니다. 견적서를 나란히 놓고 봐도 항목 이름이 서로 달라서 무엇과 무엇을 비교해야 하는지조차 분명하지 않습니다. 결국 가장 익숙한 기준인 총액으로 판단하게 되고, 그 판단은 대부분 개발 중반이나 출시 직전에 되돌아옵니다.

디비컨설팅은 100건 이상의 프로젝트를 수행하며 삼성물산, GS건설, 하나투어, LS일렉트릭 등 국내 기업의 앱과 플랫폼을 구축해 왔습니다. 그 과정에서 반복적으로 확인한 것은, 견적 차이가 업체의 욕심이나 인심에서 나오는 경우는 드물다는 사실입니다. 대부분은 견적서에 담긴 범위와 투입 인력, 그리고 개발이 끝난 뒤의 책임 범위가 서로 다르기 때문에 생깁니다. 즉 금액이 다른 것이 아니라, 사실은 서로 다른 것을 팔고 있는 상태에 가깝습니다.

이 글은 적정 금액을 알려 드리는 글이 아닙니다. 금액은 요구사항에 따라 달라지므로 일반화할 수 없습니다. 대신 견적이 달라지는 구조를 네 가지로 나누어 설명하고, 지금 책상 위에 놓인 견적서를 같은 기준으로 맞춰 비교하는 방법을 정리했습니다. 구조를 알면 비교가 가능해지고, 비교가 가능해지면 선택의 근거가 생깁니다.

모바일 앱 개발 견적이 업체마다 달라지는 4가지 구조

견적서의 총액은 결과값입니다. 그 값을 만들어 낸 변수는 대체로 다음 네 가지입니다.

1. 투입되는 개발 팀의 구성

가장 큰 변수는 누가 만드는가입니다. 시니어 개발자가 설계를 잡고 주니어가 구현하는 팀과, 전원을 주니어로 채운 팀은 같은 기간을 적어 내더라도 단가가 다릅니다. 정규 개발 조직을 운영하는 회사와, 수주한 뒤에 프리랜서를 모아 팀을 꾸리는 회사도 다릅니다. 후자는 견적을 낮게 쓸 수 있지만, 프로젝트 중간에 인력이 빠지면 그 시점부터 일정이 흔들리고 인수인계에 들어간 시간은 그대로 손실이 됩니다. 국내 인력만으로 구성할 것인지, 글로벌 인력을 포함할 것인지도 단가에 직접 영향을 줍니다.

여기서 중요한 것은 단가 자체가 아니라 결과물의 차이입니다. 같은 화면, 같은 기능이라도 데이터 구조와 API 설계를 어떻게 잡았는지에 따라 몇 달 뒤 기능 하나를 추가하는 작업량이 크게 달라집니다. 초기 견적에서 아낀 부분이 운영 단계에서 되돌아오는 가장 전형적인 경로가 이것입니다. 그래서 견적서를 볼 때는 총액보다 먼저 인력 구성표를 확인하셔야 합니다.

2. 견적에 포함된 범위가 다르다

두 번째는 범위입니다. 모바일 앱 개발이라는 같은 문구 아래 각 업체가 포함시킨 항목이 서로 다릅니다. 특히 다음 항목들은 견적서에서 조용히 빠져 있다가 개발 중반에 추가 비용으로 등장하는 경우가 많습니다.

항목	견적에서 빠지기 쉬운 정도
UI/UX 디자인	보통
관리자 페이지(어드민)	매우 높음
QA(품질 테스트)	높음
서버 설정 및 배포	높음
앱스토어 등록 및 심사 대응	매우 높음
출시 후 하자보수	높음

표에서 특히 주의할 항목은 관리자 페이지입니다. 사용자용 앱만 만들어 놓으면 운영을 할 수 없습니다. 회원 조회, 콘텐츠 등록, 푸시 발송, 기본 통계 같은 기능이 필요하다는 사실은 보통 출시 직전에 발견됩니다. 어떤 항목이 견적서에서 자주 빠지는지는 관리자 페이지 개발, 견적서에서 가장 자주 빠지는 항목에 정리해 두었습니다. 앱스토어와 구글 플레이 심사 대응도 마찬가지입니다. 심사 반려는 흔한 일이고, 대응 주체가 견적에 적혀 있지 않으면 반려된 그 시점부터 협의가 시작됩니다.

싼 견적이 끝까지 싼 경우는 많지 않습니다. 빠져 있던 항목이 하나씩 추가되면서 최종 정산액이 처음에 비싸 보였던 견적과 비슷해지는 일은 드물지 않습니다. 차이가 있다면, 그 과정에서 일정이 밀리고 발주사 담당자의 시간이 계속 소모된다는 점입니다.

3. 같은 요구사항을 다르게 해석한다

요구사항 문서에 카카오 로그인이라고 한 줄 적혀 있다고 하겠습니다. 한 업체는 이것을 SDK를 연동해 로그인 버튼이 동작하는 상태로 해석합니다. 다른 업체는 실제 운영이 가능한 상태로 해석합니다. 기존 이메일 회원과 카카오 계정을 연결하는 처리, 회원 탈퇴 시 연결 해제, 앱을 재설치했을 때 기존 데이터 복원까지 포함하는 것입니다. 두 해석의 작업량은 몇 배 차이가 납니다. 그런데 견적서에는 양쪽 모두 카카오 로그인이라고만 적힙니다.

이런 항목이 앱 하나에 수십 개 있습니다. 푸시 알림, 결제, 검색, 이미지 업로드, 권한 처리 모두 같습니다. 견적서가 구체적이지 않을수록 계약 이후에 그건 범위에 없었다는 대화가 반복됩니다. 견적서의 항목 수가 적고 설명이 짧다면, 금액이 저렴해서가 아니라 해석이 열려 있기 때문일 가능성이 높습니다. 해석이 열려 있는 견적은 계약서가 아니라 협상의 시작점에 가깝습니다.

4. 개발이 끝난 뒤의 책임 범위

네 번째는 개발이 끝난 다음입니다. 하자보수 기간이 몇 개월인지, 그 기간에 무엇이 무상이고 무엇이 유상인지, 출시 이후 운영과 기능 개선은 어떤 조건으로 진행되는지가 견적에 반영되어 있는지 확인해야 합니다. 소스코드와 산출물을 발주사가 넘겨받는지, 아니면 업체 서버에 남은 채로 운영만 위탁하는 형태인지도 금액에 큰 영향을 줍니다.

이 부분이 견적에서 빠지면 출시 직후부터 협상력이 역전됩니다. 앱은 이미 서비스 중이고, 코드를 아는 곳은 한 군데뿐이기 때문입니다. 운영과 유지보수까지 포함해 비교해야 견적의 실제 크기가 보입니다. 출시 이후에 어떤 비용이 발생하는지는 앱 유지보수 비용, 출시 후에 진짜 돈이 드는 이유에서 더 자세히 다뤘습니다.

견적서를 비교할 때 확인할 4가지

지금 두세 개의 견적서를 받아 둔 상태라면, 업체를 다시 찾기 전에 가지고 있는 견적서부터 같은 기준으로 정렬하는 편이 빠릅니다. 업체 선정 기준 자체를 먼저 세우고 싶다면 SI 업체 선정 기준과 비용 구조를 함께 보셔도 좋습니다. 다음 네 가지만 확인해도 비교가 가능해집니다.

1. 범위 정의 — 모든 업체에 동일한 범위를 제시하고 받았는가

업체마다 다른 설명을 듣고 각자 다른 기준으로 견적을 썼다면, 그 견적서들은 애초에 비교 대상이 아닙니다. 기능 목록과 화면 수, 지원 대상 OS, 연동할 외부 서비스를 한 장으로 정리해 동일하게 전달한 뒤 다시 받는 편이 정확합니다.

물어야 할 질문: 이 견적에 포함되지 않은 항목을 따로 적어 주실 수 있습니까.

2. 인력 구성 — 누가 실제로 투입되는지 적혀 있는가

등급별 인원과 각 인원의 투입 기간이 명시되어 있는지 봅니다. 총액만 적힌 견적서는 검증이 불가능합니다. 개발 기간이 비현실적으로 짧게 잡혀 있다면 QA와 수정 기간이 빠져 있다는 뜻인 경우가 많습니다. 단계별로 실제 얼마나 걸리는지는 앱 개발 기간이 계획보다 길어지는 이유에서 확인하실 수 있습니다.

물어야 할 질문: 투입되는 인력이 정규 조직입니까, 프로젝트 단위로 모집하는 인력입니까.

3. 유지보수 포함 여부 — 견적 안에 있는가, 밖에 있는가

하자보수 기간과 범위, 그 이후의 유지보수 조건이 견적서 본문에 있는지 봅니다. 별도 협의라고만 적혀 있다면 그 항목은 견적에 없는 것으로 보셔야 합니다.

물어야 할 질문: 하자보수 기간에 무상으로 처리되는 범위와 유상 범위의 기준은 무엇입니까.

4. 산출물 — 무엇을 넘겨받는가

소스코드, API 명세, DB 스키마, 배포 절차 문서가 인계 목록에 들어 있는지 봅니다. 산출물 목록이 없는 견적은 개발이 끝난 뒤 다른 업체로 이전할 수 없는 구조가 되기 쉽습니다.

물어야 할 질문: 계약 종료 시 인계되는 산출물 목록을 문서로 받을 수 있습니까.

마지막으로 한 가지를 더 권해 드립니다. 가장 낮은 견적을 낸 업체에 왜 더 저렴한지 설명을 요구하십시오. 인력 구성이나 개발 방식, 보유한 기반 코드로 설명할 수 있다면 합리적인 견적입니다. 설명하지 못한다면 금액이 낮은 것이 아니라 범위가 빠진 것입니다.

발주 방식 세 가지를 비교하면 기준이 명확해집니다

견적서를 같은 기준으로 맞춰 놓고 나면, 다음 질문은 어떤 방식으로 발주할 것인가입니다. 선택지는 크게 세 가지입니다.

구분	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
요구사항 정의 책임	개발사와 분담	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
재작업 리스크	보통	높음	낮음
총비용 관점	높음	예측하기 어려움	낮음

실무에서 실제 결정은 인도냐 베트남이냐가 아닙니다. 요구사항을 정의하고 일정을 관리하는 책임을 누가 지느냐입니다. 사내에 개발 조직이 없는 회사가 해외 팀에 직접 발주하면, 요구사항을 영어로 정의하고 우선순위를 조정하고 산출물을 검수하는 일이 전부 발주사 담당자 몫이 됩니다. 단가는 분명히 낮아지지만, 담당자 한 사람이 사실상 PM 업무를 전담하게 되고 그 시간은 다른 업무를 하지 못한 비용으로 돌아옵니다. 여기에 시차와 언어 때문에 생기는 재작업까지 더해지면 총비용 관점에서는 절감이 사라지는 경우가 많습니다. 이 구조는 IT 외주개발 비용이 견적보다 항상 더 나오는 이유에서 더 자세히 다뤘습니다.

세 번째 방식은 이 지점을 바꿉니다. 단가는 해외 수준을 유지하되, 커뮤니케이션과 책임은 국내 수준으로 둡니다. 한국인 PM이 한국어로 요구사항을 문서화하고, 그 문서를 기준으로 글로벌 개발팀에 작업을 배분하고 일정과 품질을 관리합니다. 발주사는 영어로 대화할 필요도, 해외 인력을 직접 관리할 필요도 없습니다. PM 한 사람과 한국어로 소통하면 됩니다.

디비컨설팅이 국내 대비 개발비 56% 절감을 제시할 수 있는 이유도 여기에 있습니다. 단가 구조는 글로벌이고 관리 구조는 국내이기 때문입니다. 검증된 50개 이상의 글로벌 파트너사 풀을 운영하기 때문에 프로젝트 성격에 맞는 인력을 매번 새로 찾을 필요가 없다는 점도 기간과 비용에 함께 반영됩니다. 전체 구조는 IT 아웃소싱 서비스 페이지에 정리되어 있습니다.

디비컨설팅이 견적을 산정하는 방식

디비컨설팅은 다음 다섯 단계로 프로젝트를 진행하며, 견적은 1단계가 끝난 시점에 확정됩니다.

• ① 상담 및 요구 분석 — 해결하려는 문제와 사용자, 필수 기능을 확인하고 요구사항을 한국어로 문서화합니다. 이 단계가 대부분의 재작업을 없앱니다. 앞에서 본 카카오 로그인 같은 항목을 어디까지 구현할 것인지 문서에서 먼저 결정하기 때문입니다.
• ② 개발팀 구성 — 확정된 요구사항에 맞춰 2~4주 내에 전담 개발팀을 구성합니다. 등급별 인원과 투입 기간이 이 시점에 정해집니다.
• ③ 프로젝트 개발 — 애자일 방식으로 진행하며 진행 상황을 투명하게 공유합니다. 발주사는 완성본이 아니라 중간 결과물을 계속 보게 됩니다.
• ④ 테스트 및 배포 — QA를 거쳐 릴리스하고, 앱스토어와 구글 플레이 등록 과정을 함께 처리합니다.
• ⑤ 운영 및 유지보수 — 산출물과 문서를 함께 인계하고, 이후 운영과 기능 개선을 장기적으로 지원합니다.

이 과정을 거친 견적서에는 등급별 인력 구성과 투입 기간이 적히고, 기획과 디자인, 개발, QA, 배포, 유지보수가 항목별로 구분되어 기재됩니다. 총액 한 줄이 아니라 항목별로 나뉘어 있기 때문에 다른 업체의 견적과 같은 기준으로 놓고 비교할 수 있고, 범위를 조정해 예산에 맞추는 협의도 가능합니다. 앱 개발 범위와 진행 방식은 앱 개발 외주 서비스 페이지에 정리되어 있습니다.

실제 구축 사례

디비컨설팅이 수행한 프로젝트 가운데 공개 가능한 사례는 다음과 같습니다. 100건 이상의 프로젝트를 수행했고, 고객 만족도는 98%입니다.

• 삼성물산 — 홈닉, 주거 플랫폼 앱
• GS건설 — 엘리시안 리조트, 리조트 웹·앱 통합 구축
• 하나투어 — 하나오픈챗, 여행 상담 채팅 서비스
• 직방 — 호갱노노, 부동산 데이터 서비스
• LS일렉트릭 — 테크스퀘어, 산업 B2B 거래 플랫폼
• 교보생명 — 사내벤처(글펍), 커뮤니티 서비스
• 가천대학교 — 학사관리 시스템

대기업 계열사의 신규 서비스부터 데이터 중심 플랫폼, 대학 기간 시스템까지 성격이 다른 프로젝트를 함께 수행해 왔습니다. 더 많은 사례는 포트폴리오에서 보실 수 있습니다.

이런 기업에 적합합니다 / 반대로 권하지 않습니다

적합한 경우

• 사내에 개발 조직이 없거나 규모가 작아, 요구사항 정의와 일정 관리를 맡길 파트너가 필요한 경우
• 예산은 정해져 있는데 구현해야 할 범위가 그보다 넓은 경우
• 출시로 끝나지 않고 운영과 기능 개선까지 장기적으로 함께 갈 파트너가 필요한 경우
• 방향은 있지만 요구사항이 완전히 확정되지 않아, 정의 단계부터 함께 정리해야 하는 경우

권하지 않는 경우

• 이미 사내에 PM과 개발 조직이 있어 외부 인력을 직접 관리할 수 있는 경우. 이 경우에는 인력만 조달하는 방식이 더 효율적입니다.
• 수일 내에 착수해 바로 결과물이 나와야 하는 초단기 건. 팀 구성에 2~4주가 필요하므로 일정이 맞지 않습니다.
• 보안 규정상 소스코드와 투입 인력이 모두 국내에 있어야 하는 경우
• 요구사항을 전혀 정의할 수 없고, 정의 과정에도 참여하기 어려운 경우. 어떤 방식으로 발주하더라도 결과물이 기대와 달라집니다.

자주 묻는 질문

해외 개발팀이면 의사소통은 어떻게 하나요?

발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 산출물 검수는 PM의 책임이며, 개발팀과의 커뮤니케이션도 PM이 담당합니다. 해외 개발자와 직접 영어로 대화하실 일은 없습니다.

견적 비용은 어떻게 산정되나요?

등급별 인력 구성과 각 인력의 투입 기간을 기준으로 산정합니다. 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 구분해 제시하기 때문에 어떤 작업에 얼마의 공수가 잡혔는지 확인하실 수 있고, 범위를 조정해 예산에 맞추는 협의도 가능합니다.

기획서가 없는데 견적을 받을 수 있나요?

가능합니다. 해결하려는 문제, 주요 사용자, 반드시 있어야 하는 기능 3~5개, 그리고 희망 일정과 예산 범위만 정리되어 있으면 개략 견적을 드릴 수 있습니다. 상세 견적은 요구 분석 단계를 거친 뒤 확정합니다.

프로젝트 도중에 팀 규모를 조정할 수 있나요?

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 가운데 선택하실 수 있고, 진행 중에도 범위와 일정에 맞춰 인력을 늘리거나 줄이는 조정이 가능합니다.

소스코드 소유권은 누구에게 있나요?

발주사에 귀속됩니다. 소스코드뿐 아니라 API 명세, DB 스키마, 배포 절차 문서까지 인계하기 때문에, 이후 내부 인력이 직접 운영하시거나 다른 업체로 이관하시는 선택이 모두 가능합니다. 특정 업체에 묶여 운영을 계속 위탁해야 하는 구조가 되지 않습니다.

정리

모바일 앱 개발 견적을 금액만으로 비교하면 거의 예외 없이 실패합니다. 금액은 범위와 인력 구성, 책임 범위가 결정한 결과값이기 때문입니다. 세 업체의 견적서를 같은 범위 정의 위에 올려놓고, 누가 어떤 등급으로 얼마나 투입되는지, 유지보수가 안에 있는지 밖에 있는지, 산출물로 무엇을 넘겨받는지를 같은 기준으로 맞춘 다음에야 비교가 성립합니다. 그리고 그 기준을 맞춰 제시할 수 있는 구조를 가진 파트너를 고르는 것이, 결국 견적을 비교하는 진짜 목적입니다. 현재 검토 중인 견적서가 있다면 견적 문의를 통해 요구사항 정리부터 함께 확인해 드립니다.