드는 비용
모바일 앱 제작 비용
앱은 사이트보다 비쌉니다. 복잡함의 문제가 아닙니다. 두 번 치르고, 그다음에는 해마다 치르기 때문입니다. 두 번인 것은 아이폰과 안드로이드가 서로 다른 운영체제이기 때문입니다. 해마다인 것은 공개를 유지하려면 두 스토어가 업데이트를 강제하기 때문입니다 — 아무도 손대지 않는 앱은 결국 내려갑니다. 제작 견적서는 그 부분을 말하지 않는데, 사업의 생사를 정하는 것은 바로 그 부분입니다. 이 페이지는 산정 방법, 되풀이되는 항목, 그리고 공개 뒤에도 팀이 남는 월 구독이 무엇을 바꾸는지 자세히 다룹니다.
1. 왜 두 번 내는가
예산 전체를 좌우하는 사실이며, 첫 견적을 받아 본 뒤에야 가장 흔히 알게 되는 사실입니다.
- 두 운영체제, 두 세계. iOS와 안드로이드는 언어도, 화면 관행도, 권한 규칙도 같지 않습니다. 역사적으로 이는 두 번의 완전한 개발을 뜻했고, 따라서 대략 두 배의 작업량이었습니다.
- 공통 기술은 간극을 줄이지만 지우지는 않습니다. 공통 기반을 쓰는 것은 오늘날 표준이지만, 세밀한 조율과 시험, 각 플랫폼 고유의 사정은 두 번씩 남습니다. 실제 가산을 잡으십시오. 두 배는 아닙니다.
- 만족시켜야 할 스토어가 둘. 각기 공개 규칙이 있고, 정해진 치수로 만들 이미지가 있고, 번역할 문구가 있고, 통과할 심사가 있습니다. 개발과는 별개의, 그 자체로 완결된 행정 업무입니다.
- 한 대가 아니라 기기의 무리. 화면 크기가 매우 다르고, 오래된 버전의 운영체제도 아직 쓰입니다. 웹이 스타일시트 한 장으로 해결하는 일이 여기서는 여러 구성에서의 시험을 요구합니다.
같은 규모라면 앱은 사이트보다 구조적으로 더 비쌉니다. 진짜 질문은 어떻게 덜 낼까가 아니라 그 앱이 필요한가입니다 — 그것이 5절이며, 견적을 요청하기 전에 읽을 가치가 있습니다.
2. 개발을 항목별로 산정하기
사이트와 마찬가지로 기준이 되는 요율은 존재하지 않습니다. 따로 산정하게 해야 할 항목은 다음과 같습니다. 이것들을 한 줄로 녹인 견적서는 다른 어떤 것과도 비교할 수 없습니다.
- 화면. 세어 보시고, 보여 주는 화면과 입력받는 화면을 나누십시오. 양식은 오류와 경계 상황까지 하면 조회용 화면의 몇 배가 듭니다.
- 이용자 계정. 가입, 로그인, 비밀번호 재설정, 계정 삭제 — 마지막 항목은 가입이 있는 순간 스토어가 요구합니다. 이 부분은 거의 언제나 과소평가됩니다.
- 서버와 데이터. 고정된 내용만 보여 주는 앱은 저렴합니다. 무언가를 저장하기 시작하는 순간부터 데이터베이스, 그것을 관리할 화면, 백업이 필요해집니다. 견적서의 첫 항목이 되는 경우가 많습니다.
- 알림. 기술적으로는 단순하지만 조율에 비용이 듭니다. 요청해야 할 권한, 두 운영체제에서 다른 동작, 그리고 무엇을 언제 보낼지 정하는 업무 논리를 써야 합니다.
- 앱 안에서의 결제. 구매가 있다면 스토어는 자체 방식을 강제하고 수수료를 뗍니다. 개발인 동시에 귀사 매출의 일부이기도 합니다.
- 실제 기기에서의 검수. 양보할 수 없는 단계이며, 빠듯한 견적서에서 가장 먼저 깎이는 항목입니다 — 그 대가는 공개 뒤의 수정으로, 긴급 단가에 치릅니다.
3. 해마다 이어지는 것
방치된 사이트는 공개된 채 남습니다. 방치된 앱은 쓸 수 없게 되고, 그다음 사라집니다. 그것이 본질적인 차이이며, 그것은 금전의 문제입니다.
- 개발자 계정 비용. 공개하려면 각 스토어의 계정이 필요합니다. 애플 쪽은 연간 구독, 구글 쪽은 일회성 비용입니다. 액수는 적지만, 애플 구독을 갱신하지 않으면 앱이 판매에서 내려갑니다.
- 강제되는 업데이트. 해마다 iOS와 안드로이드의 새 버전이 규칙을 옮기고, 스토어는 업데이트를 받아들이기 위해 최신 도구로 빌드할 것을 요구합니다. 따라서 앱을 하나도 바꾸지 않더라도 손을 대야 합니다.
- 서버. 호스팅, 데이터베이스, 백업. 사용과 함께 늘어나는 월 지출입니다.
- 결함 수정. 앱의 강제 종료는 깨진 페이지처럼 보이지 않습니다. 스토어 평점에 나타나고, 거기 몇 달을 남습니다.
- 평점 살피기. 아무도 돌보지 않지만, 앞으로 쓸 사람이 가장 먼저 읽는 것입니다.
계약 전에 이 항목들을 삼 년치로 잡아 두십시오. 이후 예산 없이 납품된 앱은 스토어에서 내려갈 앱입니다 — 때로는 쓰이기도 전에 말입니다.
4. 스토어의 비용 — 반려
모든 견적서에 없는 항목이지만 실재합니다. 공개는 제출이 아니라 심사입니다. 두 스토어는 앱을 읽고, 개발과 무관한 이유로 자주 반려합니다 — 불완전한 개인정보 처리방침, 찾을 수 없는 계정 삭제, 작동하지 않는 테스트 계정, 불충분하다고 판단된 권한 설명, 고유한 가치가 없는 웹사이트와의 유사성.
반려는 두 가지를 앗아갑니다. 시간 — 수정, 재제출, 다시 기다림. 그리고 날짜 — 출시를 알렸다면 그것이 밀립니다. 이 점에서 여유 없이 진행한 사업은 행정적 이유로 긴급 요금을 치르게 됩니다.
그러니 어떤 업체에든 공개를 맡는 사람이 누구이고 반려를 넘겨받는 사람이 누구인지 물으십시오. 그 답은 견적서 한 줄의 값어치가 있습니다.
5. 치르기 전에 스스로에게 던질 질문
많은 앱은 개발하지 말았어야 했고, 예산은 다른 곳에 쓰였어야 했습니다. 세 가지 질문이 정직하게 결론을 내려 줍니다.
- 사용이 반복됩니까? 앱은 자주 여는 것을 위해 설치합니다 — 주문하기, 추적하기, 출퇴근 찍기, 단골 만들기. 가끔 보는 정도라면 휴대폰에서 여는 사이트가 더 낫고, 설치를 얻어 낼 필요도 없습니다.
- 기기의 기능이 필요합니까? 알림, 카메라, 위치, 통신 없는 작동, 바코드. 이 가운데 어느 것도 쓰이지 않는다면, 앱은 웹이 못 하는 것을 무엇도 가져오지 않습니다.
- 누가 설치할 것인가? 가장 많은 사업을 가라앉히는 지점입니다. 설치를 얻는 일은 방문을 얻는 일보다 어렵습니다. 이미 붙잡아 둔 사람들 — 단골 고객, 회원, 현장 인력 — 이 없다면 앱은 품질과 무관하게 비어 있을 것입니다.
세 가지 답이 분명하지 않다면 웹사이트부터 시작하십시오. 웹사이트 제작 비용에 관한 페이지가 그 경로를 자세히 설명합니다. 앱은 사용이 생겨난 뒤에 만들어도 됩니다.
6. 공개가 아니라 그 이후에 값을 치르기
지출이 출시 이후에 몰린다면, 사야 할 것은 개발이 아닙니다. 지속되는 존재입니다.
nullbot에서는 앱도 사이트와 마찬가지로 대화로 설명합니다. 공개 전에 iOS와 안드로이드 시뮬레이터에서 돌아가는 것을 볼 수 있습니다 — 직접 조작하고 화면을 캡처할 수도 있습니다. 자체 데이터베이스를 가질 수 있고, 검수를 거치며, 대상별로 바이너리가 만들어지고, App Store와 Google Play로의 공개도 같은 자리에서 진행합니다. 각 스토어의 상태를 눈앞에 둔 채로 말입니다.
그것도 아직 저희가 파는 것이 아닙니다. 저희가 파는 것은 이듬해입니다. 남아 있는 에이전트 팀입니다. 스토어가 요구하는 업데이트를 준비하고, 심사 반려를 넘겨받고, 강제 종료를 고치고, 등록 정보와 그 번역을 지키며, 평점을 살핍니다. 앱은 오지 않을 유지보수 예산을 기다리지 않습니다 — 그것은 팀의 일상 업무입니다.
지출은 자금을 대고 다시 대야 하는 사업이기를 그칩니다. 월 구독이 되고, 공개는 더 이상 결승선이 아닙니다.
7. 1주차, 3개월차, 2년차
제안을 가르는 세 시점 — 그리고 그것은 사이트의 경우와 다릅니다. 스토어가 자기 일정을 강요하기 때문입니다.
- 1주차. 앱이 두 스토어에 공개되었고, 등록 정보가 채워졌으며, 심사용 테스트 계정이 작동합니다. 유능한 업체라면 여기까지는 합니다.
- 3개월차. 불만 세 건이 같은 화면에 몰리고, 별 두 개 평점이 맨 위에 있으며, 운영체제의 새 버전이 나왔습니다. 질문은 이렇게 됩니다 — 그 수정을 공개한 사람은 누구인가. 이후를 돌보지 않은 채 납품된 사업은 여기서 이미 이용자를 잃고 있습니다.
- 2년차. 두 스토어 모두 더 최신 도구로 빌드할 것을 요구하며, 그러지 않으면 어떤 업데이트도 거부합니다. 손대지 않으면 앱은 이미 설치한 사람에게는 남지만 어디에도 새로 설치되지 않고, 결국 실행되지 않게 됩니다. 이때 재구축 예산이 등장합니다 — 그리고 같은 이유로 다시 등장하게 됩니다.
8. 한계를, 솔직하게
- 매우 전문적인 앱은 여전히 맞춤 개발입니다. 고급 이미지 처리, 블루투스로 연결되는 기기, 정밀한 지도, 게임. 이는 전문 직무이며, 전통적인 개발 예산이 듭니다.
- 스토어 심사는 보장되지 않습니다. 어떤 업체도 승인이나 기한을 약속할 수 없습니다. 약속할 수 있는 것은 통과할 때까지 그 건을 다시 붙잡는 일입니다.
- 앱은 스스로 이용자를 만들지 않습니다. 아무도 설치하지 않으면 어떤 팀도 그것을 바꾸지 못합니다. 5절을 다시 읽으십시오. 이 사업에서 가장 절약이 되는 결정입니다.
- 회사를 구속하는 일은 승인을 거칩니다. 판매 개시, 가격 변경, 전체 이용자에게 보내는 메시지는 나가기 전에 귀하에게 제시됩니다.
9. 자주 묻는 질문
모바일 앱의 평균 가격을 왜 말하지 않는가?
조회만 하는 앱과 계정·결제·알림을 갖춘 앱의 간극이 너무 커서 평균은 아무것도 알려 주지 못하기 때문입니다. 2절의 항목들을 귀사의 조건으로 계산하면 근거 있는 규모를 얻을 수 있습니다. 단일한 금액은 두 견적서를 비교할 때 그릇된 확신만 줄 것입니다.
아이폰과 안드로이드용 앱 하나면 더 저렴한가요?
둘을 따로 개발하는 것보다는 적게 듭니다. 그것이 일반적인 방식입니다. 그러나 절약이 절반은 아닙니다. 세밀한 조율, 시험, 각 플랫폼 고유의 사정은 양쪽에 남고, 스토어 등록 정보도 두 번 만듭니다. 단일 플랫폼 대비 가산을 잡으십시오. 두 번째가 공짜가 되는 것이 아닙니다.
애플과 구글 계정이 제 명의로 필요한가요?
그렇게 하는 편이 훨씬 낫고, 계약 전에 정리해야 할 사항입니다. 외주 업체 계정으로 공개된 앱은 되찾기 어렵고, 평점 이력은 이전되지 않습니다. 나중에 접근 권한을 위임하더라도 계정은 회사 명의로 개설하십시오. 처음에 십오 분이면 되는 일이, 나중에는 완전한 교착이 됩니다.
앱을 한 번도 업데이트하지 않으면 어떻게 되나요?
세 가지가 이 순서로 일어납니다. 먼저 스토어가 빌드 도구가 너무 낡았다는 이유로 새 버전을 반려합니다. 다음으로 앱이 최신 휴대폰에서 제대로 작동하지 않게 됩니다. 마지막으로 오래 업데이트되지 않은 앱은 판매에서 내려갈 수 있습니다. 그것이 앱과 사이트를 가르는 점입니다. 가만히 두는 것은 앱을 그 자리에 남기지 않습니다. 지웁니다.
앱 대신 제 사이트로 충분한가요?
기업의 경우 대부분 그렇습니다 — 앱이 있으면 좋겠다 싶은 경우에도 마찬가지입니다. 웹사이트는 모든 휴대폰에서 작동하고, 설치를 요구하지 않으며, 통과해야 할 심사도, 해마다 강제되는 업데이트도 없습니다. 앱이 정당화되는 것은 사용이 반복되고 기기의 기능이 필요할 때입니다. 5절의 세 가지 질문이 몇 분 만에 결론을 내려 줍니다.
더 읽기
이어서 읽기: 앱이 만들어지는 과정, 단계별로, 웹사이트 제작 비용, 또는 직원 한 명의 비용.