앱 개발 견적서를 세 군데서 받아놓고 나면 대부분 같은 자리에서 막혀요. 총액은 두 배 넘게 차이가 나는데, 왜 차이가 나는지 설명할 수가 없거든요. 싼 곳이 부실한 건지, 비싼 곳이 제대로 하는 건지, 아니면 애초에 세 곳이 서로 다른 앱을 만들겠다고 적어 온 건지 구분이 안 되는 상태요.
이 글은 견적을 잘 받는 법이 아니라 이미 받은 견적서를 뜯어보는 법이에요. 견적서 세 장을 책상에 놓고 어느 줄부터 봐야 하는지, 어디가 비어 있으면 그게 나중에 돈이 되는지, 같은 축에 놓고 비교하려면 무엇을 다시 물어야 하는지를 순서대로 정리했어요. IT 외주 견적서 전반의 공통 원칙은 IT 외주 개발 견적서 완전 분석 가이드에 따로 정리해 뒀으니, 여기서는 앱이라서 생기는 문제에 집중할게요.
비용 이야기를 하기 전에 기준을 밝힐게요. 아래에 나오는 금액 관련 설명은 공표된 산업 통계가 아니라 국내 외주 시장에서 실제로 오가는 견적을 기준으로 한 것이에요. 그래서 확정된 수치로 말할 수 있는 자리가 아니면 금액 대신 구조와 비율로 설명했어요. 숫자로 적은 건 Apple과 Google이 공개해 둔 스토어 요금 정도예요.
견적서의 품질은 총액이 아니라 줄의 개수에서 먼저 드러나요. 한 장에 총액만 적혀 온 견적서는 협상할 지점이 없어요. 기능을 하나 빼면 얼마를 빼야 하는지, 하나 더하면 얼마를 더해야 하는지 계산할 근거가 없으니까요. 앱 견적서라면 최소한 아래 항목이 각각 별도의 줄로 잡혀 있어야 해요.
여기에 하나만 더 요구하면 견적서의 성격이 달라져요. 가정 목록이에요. "기획서가 확정된 상태를 전제로 한다", "디자인 시안은 2라운드까지를 전제로 한다", "결제는 결제대행사 표준 SDK 사용을 전제로 한다" 같은 문장이요. 좋은 견적서는 자기가 무엇을 모르는 채로 값을 매겼는지 먼저 밝혀요. 가정이 적혀 있으면 나중에 추가비용이 생겼을 때 누구 책임인지 다투는 대신 그 줄을 펴놓고 확인하면 돼요. 가정 목록이 없는 견적서는 나중에 "그건 당연히 별도죠"라는 말이 나올 자리를 통째로 비워둔 것과 같아요.
앱 견적은 크게 두 방식으로 와요. MD 단가 방식은 "1명이 하루 일하는 값 곱하기 며칠"로 계산해요. 기능당 정액 방식은 "로그인 얼마, 결제 얼마"처럼 기능 단위로 값을 붙여요. 어느 쪽이 좋다기보다 내 프로젝트의 범위가 얼마나 확정됐는지에 따라 유리한 쪽이 갈려요.
범위가 확정됐고 기능 정의가 문서로 있는 상태라면 정액이 안전해요. 개발이 늦어져도 내가 더 내지 않으니까요. 대신 정액은 개발사가 리스크를 떠안기 때문에 안전마진이 얹혀요. 범위가 아직 흐릿한데 정액으로 계약하면, 개발사는 좁게 해석해서 값을 매기고 나중에 "그건 범위 밖"이 반복돼요.
반대로 MD 방식은 투명해요. 어떤 등급의 인력이 며칠 붙는지가 보이고, 기능이 늘거나 줄 때 산수로 조정할 수 있어요. 대신 총액이 보장되지 않아서, 상한선 없이 계약하면 예산이 열려 있는 상태가 돼요. MD 방식 견적을 받았다면 총 MD 수의 상한과 초과 시 처리 방법을 반드시 문서에 넣으세요.
실무에서 가장 무난한 건 섞는 거예요. 화면과 흐름이 확정된 부분은 정액으로 묶고, 외부 연동처럼 열어봐야 아는 부분은 MD 풀로 잡아두는 방식이요. "연동 대응 20MD를 풀로 잡고, 쓰지 않으면 정산에서 뺀다" 같은 조항이 있으면 서로 안전마진을 줄일 수 있어요.
단가와 수량의 산수를 직접 검산하는 것, PM과 기획과 QA가 별도 줄로 잡혀 있는지 보는 것은 앱이 아니어도 똑같아서 앞서 링크한 견적서 가이드에 정리돼 있어요. 앱에서 하나만 더 보태면 개발 공수와 출시 공수가 섞여 있는지예요. 빌드 설정, 서명과 인증서 발급, 스토어 제출, 반려 대응은 코드를 쓰는 일이 아닌데도 사람이 며칠씩 붙어요. 이게 개발 MD 안에 묻혀 있으면 개발이 끝난 뒤 출시까지 며칠이 더 필요한지 계산할 수가 없어요.
세 곳의 견적이 크게 벌어지는 건 대부분 실력 차이가 아니에요. 서로 다른 것을 만들겠다고 적었기 때문이에요. 실제로 차이를 만드는 지점은 거의 정해져 있어요.
그래서 견적서를 비교하기 전에 해야 할 일은 값을 깎는 게 아니라, 세 곳이 각각 무엇을 만들겠다고 적었는지 맞춰보는 것이에요. 이 작업을 하고 나면 대개 "제일 싼 곳이 제일 적게 만들겠다고 적었다"가 드러나요. 반대로 제일 비싼 곳이 필요 없는 것까지 넣어둔 경우도 자주 나와요.
앱 개발 외주 비용은 화면 수로 정해지지 않아요. 화면이 30개여도 대부분 목록과 상세면 가볍고, 화면이 12개여도 실시간 채팅과 결제가 있으면 무거워요. 비용을 실제로 밀어 올리는 변수는 이런 것들이에요.
이 변수들이 기간과 금액에 어떻게 반영되는지 감을 먼저 잡고 싶다면 MVP 개발 기간과 비용을 현실적으로 잡는 법을 같이 보세요. 견적서를 읽을 때 "이 앱은 왜 이 구간에 있는가"를 설명할 수 있게 돼요.
추가비용은 개발사가 나빠서 생기기보다, 견적서에 그 줄이 아예 없어서 생겨요. 앱 프로젝트에서 반복적으로 빠지는 항목은 거의 목록이 정해져 있어요.
확인 방법은 간단해요. 이 목록을 그대로 들고 견적서를 훑으면서 해당 줄이 있는지, 없다면 포함인지 별도인지만 물어보세요. "포함이에요"라는 구두 답변을 받았다면 그 답을 견적서 개정본에 한 줄로 넣어달라고 하세요. 견적서에 없는 포함은 나중에 없는 것이 되기 쉬워요.
앱 견적서가 IT 외주 견적서와 갈리는 지점이 여기예요. 견적서에 어떤 방식으로 두 플랫폼을 만드는지가 안 적혀 있다면, 그 견적서는 아직 읽을 준비가 안 된 거예요.
크로스플랫폼(플러터, 리액트 네이티브 계열)은 코드 한 벌로 두 스토어에 올려요. 개발 공수는 확실히 줄지만 공짜는 아니에요. 플랫폼별로 다르게 동작하는 부분, 예를 들어 푸시, 결제, 권한, 카메라 같은 영역에는 분기 처리 공수가 붙어요. 견적서에 이 분기 공수가 없으면 나중에 "안드로이드에서만 안 된다"가 추가 건으로 넘어와요.
네이티브 두 벌은 화면과 로직을 각각 만들어요. 서버와 기획과 디자인은 공유하니까 총액이 정확히 두 배가 되지는 않지만, 클라이언트 개발 공수는 사실상 두 번 들어가요. 대신 OS 신기능 대응이나 세밀한 성능 튜닝은 유리해요.
어느 쪽이든 QA는 따로 봐야 해요. 테스트는 코드를 공유해도 줄지 않아요. 기기와 OS 버전 조합만큼 늘어나니까요. 견적서를 볼 때 이 세 가지를 확인하세요.
개발이 끝나도 앱은 바로 출시되지 않아요. 스토어에 올리고 심사를 통과해야 해요. 이 구간이 견적서에서 통째로 빠져 있는 경우가 흔한데, 실제로는 일정과 공수가 모두 걸리는 자리예요.
먼저 계정이에요. 개발자 계정을 누구 명의로 만들지 정해야 해요. 개발사 명의로 올리면 나중에 앱 소유권 이전 절차가 따로 필요해요. 발주사 명의로 만들고 개발사를 팀 멤버로 초대하는 방식이 이관에서 가장 깔끔해요. 계정 요금은 Apple이 공개한 개발자 프로그램 연 99달러, Google Play는 최초 등록 25달러예요. 인앱결제 수수료 역시 Apple과 Google이 각각 공표한 요율(조건에 따라 15퍼센트 또는 30퍼센트)이 적용돼요. 다만 한국은 앱 마켓 사업자가 특정 결제방식을 강제하지 못하도록 전기통신사업법이 규정하고 있어서 외부결제 선택지가 열려 있고, 이 경우 적용 요율이 달라져요. 어느 쪽이든 최신 요율은 Apple과 Google이 공개한 정책 문서에서 직접 확인하세요. 앱 안에서 디지털 상품을 판다면 이 수수료가 사업 모델에 그대로 들어오니까 견적과 별개로 미리 계산해 두세요.
그다음이 심사예요. 견적서에서 확인할 문장은 하나예요. "반려되면 몇 회까지 무상 대응인가요?" 첫 제출에 통과하는 경우도 있지만, 로그인 방식이나 결제 정책, 개인정보 수집 고지 같은 이유로 한두 번 오가는 일은 드물지 않아요. 회수를 정해두면 서로 다투지 않아요.
마지막으로 등록물이에요. 스크린샷, 소개 문구, 카테고리, 연령 등급 설문, 데이터 안전 섹션 작성까지 누가 하는지 정해야 해요. 개발사가 안 한다면 발주사가 해야 하는 일이고, 이건 출시 직전에 몰아서 하기 가장 힘든 일이에요.
견적서 세 장을 그대로 비교하면 결론이 안 나요. 포맷이 다르고 묶음 단위가 다르니까요. 순서는 이렇게 잡으세요.
이 표를 다 만들면 대화의 성격이 바뀌어요. "좀 더 깎아주세요"가 아니라 "귀사 견적에는 푸시 알림 설정이 안 보이는데 포함인가요"로 물을 수 있어요. 후자가 훨씬 잘 통해요.
받은 견적서를 펼치고 왼쪽 열을 위에서부터 훑어보세요. 오른쪽 열은 그 줄이 비어 있을 때 실제로 벌어지는 일이에요. 빈칸이 눈에 띄게 많으면 값을 깎는 대신 견적서를 다시 받는 편이 빨라요.
| 항목 | 견적서에 있어야 하는 형태 | 비어 있으면 나중에 생기는 일 |
|---|---|---|
| 산정 단위 | MD 단가 × 일수, 또는 기능당 정액 금액 | 기능이 늘고 줄 때 조정 금액을 계산할 근거가 없어져요 |
| 기능 목록 | 화면과 API 단위로 줄이 나뉜 목록 | "회원 관리에 소셜 로그인은 없었다" 같은 해석 차이가 추가비용이 돼요 |
| 플랫폼 구분 | iOS · 안드로이드 · 관리자 웹 각각의 공수 | 안드로이드가 뒤늦게 별건으로 넘어와요 |
| 디자인 범위 | 디자인할 화면 수와 시안 라운드 수 | 시안 3안째부터 별도 청구가 붙어요 |
| QA와 테스트 | 테스트 기기, OS 버전, 회귀 테스트 횟수 | 검수에서 나온 버그의 수정 책임이 흐려져요 |
| 스토어 배포 | 제출, 반려 대응 횟수, 등록물 제작 주체 | 출시 직전에 스크린샷과 소개 문구를 발주사가 급히 만들게 돼요 |
| 인프라·외부 서비스 | 항목별 명의자와 요금 부담 주체 | 운영 첫 달 청구서를 누가 낼지부터 다시 이야기해요 |
| 유지보수 | 기간, 무상 범위, 이후 단가 | "무상 3개월"의 무상 범위를 서로 다르게 기억해요 |
| 이관 산출물 | 소스코드, 문서, 계정 목록 | 직접 운영으로 돌릴 때 이관 비용이 따로 붙어요 |
| 가정 목록 | 무엇을 전제로 매긴 값인지 적은 문장 | 추가비용이 생겼을 때 책임을 가릴 기준이 없어요 |
국내 외주 시장에서 실제로 오가는 견적서를 기준으로 정리했어요. 공표된 산업 통계가 아니에요.
어느 쪽이 좋은 방식이라기보다, 범위가 얼마나 확정됐는지에 따라 유리한 쪽이 갈려요. 내 상황이 어느 행에 걸리는지로 판단하세요.
| 비교 축 | MD 단가 방식 | 기능당 정액 방식 |
|---|---|---|
| 유리한 상황 | 범위가 아직 확정되지 않았을 때 | 기능 정의가 문서로 확정됐을 때 |
| 총액 예측 | 상한을 걸지 않으면 열려 있어요 | 계약 시점에 고정돼요 |
| 범위 변경 | 산수로 바로 조정돼요 | 건별 재견적이 필요해요 |
| 안전마진 | 상대적으로 적게 얹혀요 | 개발사가 리스크를 지니 더 얹혀요 |
| 투명성 | 인력 등급과 투입 일수가 보여요 | 내부 공수는 보이지 않아요 |
| 발주자 리스크 | 일정이 늘면 비용이 늘어요 | 좁게 해석돼 "범위 밖"이 반복될 수 있어요 |
| 반드시 넣을 조항 | 총 MD 상한과 초과 시 처리 방법 | 기능 단위 정의와 완료 판정 기준 |
견적서 세 장을 그대로 나란히 놓으면 결론이 안 나요. 아래 여덟 개 축만 뽑아 표로 옮기면 어디가 왜 비싼지가 한 화면에 보여요.
| 비교 항목 | 표에 적는 값 | 차이가 났을 때 해석 |
|---|---|---|
| 기능 매핑률 | 내 화면 목록 중 견적에 잡힌 비율 | 낮은 곳은 싼 게 아니라 적게 만들겠다는 뜻이에요 |
| 총 MD | 견적서에 잡힌 합계 공수 | 총액이 비슷한데 MD가 적으면 단가가 높은 팀이에요 |
| 평균 단가 | 총액 ÷ 총 MD | 단가가 낮고 MD가 많으면 주니어 비중을 확인하세요 |
| 플랫폼 방식 | 크로스플랫폼 1벌 / 네이티브 2벌 | 방식이 다르면 총액 비교 자체가 성립하지 않아요 |
| 디자인 라운드 | 시안 횟수와 디자인 화면 수 | 라운드가 적은 곳은 나중에 추가 청구가 붙어요 |
| 제외 항목 수 | "포함하지 않음"으로 적힌 줄의 개수 | 이 열이 실제 범위 차이를 가장 정확히 보여줘요 |
| 유지보수 1년 | 월 단가 × 12개월 | 개발비 기준 순위가 여기서 뒤집히는 경우가 많아요 |
| 인프라 1년 | 클라우드·외부 서비스 예상 요금 | 부담 주체가 다르면 총비용이 달라져요 |
추가비용은 개발사가 나빠서가 아니라 그 줄이 견적서에 없어서 생겨요. 왼쪽 항목을 견적서에서 찾아보고, 없으면 가운데 질문을 그대로 보내세요.
| 누락되기 쉬운 항목 | 이렇게 물어보세요 | 견적서에 반영되는 형태 |
|---|---|---|
| 소셜 로그인·본인인증 | 로그인은 어떤 방식까지 포함인가요? | 방식별로 줄을 나눠 각각 공수 표기 |
| 푸시 알림 | 알림 종류와 발송 조건 설정까지 포함인가요? | 알림 종류 수와 서버 설정 공수를 별도 줄로 |
| 딥링크 | 알림을 눌렀을 때 해당 화면으로 이동하나요? | 대상 화면 수 기준으로 공수 표기 |
| 스토어 등록물 | 스크린샷과 소개 문구는 누가 만드나요? | 제작 주체와 수정 라운드 명시 |
| 심사 반려 대응 | 반려되면 몇 회까지 무상 대응인가요? | 무상 대응 횟수를 숫자로 명시 |
| 관리자 권한 체계 | 운영자와 관리자 권한을 나눌 수 있나요? | 역할 수와 권한 화면 공수를 별도 줄로 |
| 크래시·분석 도구 | 출시 후 오류는 어디서 확인하나요? | 도구 세팅 공수와 계정 명의 명시 |
| OS 업데이트 대응 | 새 OS 버전이 나오면 누가 대응하나요? | 유지보수 범위 포함 여부 명시 |
| 인수인계 문서 | 배포 런북과 아키텍처 문서가 산출물인가요? | 산출물 목록에 문서명으로 명시 |
제일 싼 견적이 항상 문제인 건 아니에요. 비슷한 앱을 여러 번 만들어봐서 재사용할 코드가 있는 회사는 실제로 싸게 할 수 있어요. 문제는 그 이유가 견적서에 안 적혀 있을 때예요. 싼 견적을 받았다면 아래 세 가지를 순서대로 확인하고, 답이 아니면 후보에서 빼세요.
추가로 볼 신호가 두 가지 더 있어요. 계약금 비중이 유난히 높은 구조, 그리고 개발비는 낮은데 유지보수 단가가 높은 구조요. 후자는 나쁘다기보다 총비용으로 계산해야 한다는 뜻이에요. 업체 검증 자체를 더 넓게 하고 싶다면 앱 개발사 선택 전 확인할 체크리스트를 같이 보세요.
재견적은 사고가 아니라 예정된 이벤트예요. 언제 생기는지가 거의 정해져 있어서, 견적서 단계에서 미리 규칙을 정해두면 분쟁이 안 나요. 대표적인 지점은 이래요.
변경 요청 처리 규칙 자체는 앱이 아니어도 같아요. 변경 1건의 단가, 승인 절차, 일정 영향 평가, 누적 한도 네 가지인데 앞서 링크한 견적서 가이드에 정리해 뒀어요. 앱에서 따로 정해둘 건 두 줄이에요. 스토어 정책이 바뀌어 기능을 고쳐야 할 때 누구 비용으로 하는지, 그리고 심사 반려로 생긴 재작업이 변경 요청인지 하자보수인지요. 이 둘은 앱에서만 생기는 자리라 일반 계약서 문구에는 대개 빠져 있어요.
사실 견적서의 품질은 요청서의 품질을 넘지 못해요. 같은 문서를 세 곳에 보내야 비교가 가능하니까, 아래 여섯 가지를 한 묶음으로 만들어 동시에 보내세요.
범위를 어디서 끊을지 판단하는 절차는 MVP 범위 확정 절차에 단계별로 정리해 뒀어요. 견적을 받기 전에 이 작업을 하면 세 곳의 견적 편차가 눈에 띄게 줄어요. 개발사가 상상으로 빈칸을 메우는 폭이 줄어드니까요.
견적서는 계약서가 아니에요. 그런데 실제 분쟁은 대부분 "견적서에 그렇게 적혀 있었잖아요" 자리에서 생겨요. 그래서 계약 직전에 이 다섯 가지를 확인하세요.
소스코드 저작권 귀속, 하자보수 기간과 하자의 정의, 중도 해지 정산처럼 앱이 아니어도 똑같이 봐야 하는 조항은 앱 개발사 선택 전 확인할 체크리스트에 표로 정리해 뒀어요. 여기서는 견적서를 봐야만 확인되는 항목과 앱 고유의 자산 이관만 남겼어요.
마지막으로 순서만 남길게요. 견적서 세 장을 앞에 놓고 이 순서로 30분만 쓰면 대부분의 문제가 미리 드러나요.
7번이 중요해요. 같은 질문을 같은 문장으로 보내면 답변의 차이가 곧 회사의 차이로 보여요. 어디는 하루 만에 항목별로 답하고, 어디는 "미팅에서 말씀드릴게요"라고 답해요. 그 차이가 프로젝트 중반의 소통 방식과 거의 같아요.
포텐랩은 견적서를 낼 때 기능 목록, 가정 목록, 제외 항목, 스토어 배포 공수, 이관 산출물을 기본 섹션으로 넣어요. 값을 낮게 보이게 만드는 것보다 나중에 다툴 자리를 미리 없애는 편이 서로 낫다고 보기 때문이고, 수행완수율 97퍼센트를 유지하는 이유이기도 해요. 지금 받은 견적서를 어떻게 읽어야 할지 막혔다면, 그 견적서를 들고 오셔도 좋아요. 같은 축으로 정리한 비교표를 만들어 드릴게요.
화면 목록과 기능 구분을 함께 보내면 보통 며칠 안에 받을 수 있어요. 반대로 아이디어만 전달하면 개발사가 빈칸을 상상으로 채우느라 시간이 걸리고, 나온 견적도 세 곳이 크게 벌어져요. 요청서의 상세도가 회신 속도와 견적 정확도를 함께 결정해요.
요청해도 돼요. "기능별로 공수와 금액을 나눠 주실 수 있을까요"는 무리한 요구가 아니라 표준 요청이에요. 나누기 어렵다는 답이 오면, 내부에서도 산정 근거가 정리되지 않았다는 신호로 볼 수 있어요.
개발비만 비교하면 순위가 자주 뒤집혀요. 개발비에 1년치 유지보수와 인프라·외부 서비스 요금을 더한 값으로 비교하세요. 그리고 총액이 낮은 이유가 기능 누락 때문인지, 재사용할 자산이 있어서인지를 먼저 구분해야 해요.
대체로 코드 한 벌로 만드는 크로스플랫폼이 개발 공수가 적어요. 다만 푸시·결제·권한처럼 플랫폼별로 다르게 동작하는 영역의 분기 공수와, 기기 조합만큼 늘어나는 QA 공수는 줄지 않아요. 견적서에 어느 방식인지 안 적혀 있으면 비교 자체가 성립하지 않으니 먼저 확인하세요.
아니에요. 개발자 계정 요금(Apple 연 99달러, Google Play 최초 등록 25달러)과 인앱결제 수수료는 Apple·Google에 내는 비용이라 개발 견적과 별개예요. 견적서에서 확인할 건 계정을 누구 명의로 만드는지, 심사 제출과 반려 대응 공수가 잡혀 있는지예요.
대체로 바뀌어요. 기획이 확정되는 시점, 디자인 시안이 확정되는 시점, 외부 연동 스펙을 확인하는 시점에 재견적이 생겨요. 문제라기보다 예정된 이벤트라서, 견적서에 언제 재견적하는지와 변경 1건의 단가 규칙이 함께 적혀 있으면 충분해요.