앱 개발 범위, 다섯 가지만 적어 보내면 된다

업체마다 다른 앱을 계산한다

“중고 거래 앱 같은 거요.” 문의가 이 한 줄로 들어오면 받는 쪽에서는 각자 다른 앱을 그린다. 물건 등록과 목록 화면까지만 떠올리는 곳이 있고, 채팅과 본인 인증에 신고 처리까지 당연히 들어간다고 보는 곳도 있다. 계산한 앱이 다르니 돌아오는 금액도 다르다. 여러 곳에 문의해 본 사람은 견적 차이에 먼저 놀란다. 업체가 값을 부풀려서 그런 게 아니다.

범위를 가르는 자리는 다섯 군데뿐이다. 화면이 몇 개인가, 어느 스토어에 올리는가, 로그인·결제·푸시가 들어가는가, 서버가 필요한가, 운영자용 화면은 어디까지 만드는가. 이 다섯 줄을 채워 보내면 돌아온 견적들이 비로소 같은 기준 위에 놓인다.

화면부터 센다

사용자가 앱을 열어 목적을 이루기까지 거치는 화면을 하나씩 적어 본다. 온보딩, 가입, 홈, 목록, 상세, 작성, 마이페이지, 설정. 여기서 대개 빠뜨리는 게 상태 화면이다. 내용이 아직 하나도 없을 때 보이는 화면, 오류가 났을 때의 화면, 검색 결과가 없을 때의 화면. 이것까지 적으면 “간단한 앱”도 목록이 금세 길어진다. 화면 수는 디자인과 개발 양쪽에 다 붙으므로, 이 목록의 길이가 곧 기간과 비용의 뼈대다.

그림 실력은 필요 없다. 종이에 네모를 그리고 화살표로 이으면 그만이다. 예쁘게 다듬는 건 디자이너 몫이고, 발주자가 할 일은 빠진 화면이 없는지 확인하는 것이다. 이 목록 하나가 업체와 대화할 때 공통 언어가 되고, 나중에 “이건 범위에 없었다”는 다툼도 줄여 준다.

어느 스토어에, 언제부터

iOS와 Android에 모두 내려면 만드는 방식부터 갈린다. 각각 네이티브로 만들면 같은 앱을 두 벌 만드는 셈이라 작업량이 확 늘어난다. 크로스플랫폼 프레임워크는 코드 한 벌로 양쪽 스토어를 덮지만, 카메라나 알림처럼 기기에 붙는 기능은 플랫폼별로 다시 손봐야 한다. 웹뷰는 웹사이트를 앱 껍데기에 담는 방식이라 셋 중 가장 가볍다. 대신 애플 심사에서 웹사이트를 감싸기만 한 앱은 반려될 수 있으니, 콘텐츠 중심 서비스라도 앱에서만 되는 기능을 하나쯤 얹을지 미리 따져 본다.

물어볼 건 두 가지다. 어느 스토어에 낼 것인가, 처음부터 양쪽에 다 낼 것인가. 초기 사용자가 한쪽에 몰려 있다면 한 플랫폼으로 시작해 범위를 크게 줄이는 것도 충분히 타당하다.

로그인·결제·푸시에 딸려 오는 것들

기능 목록에 한 줄로 적히는 항목이 실제로는 통째로 작업 덩어리 하나다. 로그인은 버튼이 아니라 계정 체계다. 가입이 있으면 비밀번호 찾기가 있어야 하고 탈퇴도 있어야 한다. 소셜 로그인을 하나 붙일 때마다 연동 작업이 한 벌씩 더 생긴다. 결제도 결제창만 만들면 끝나지 않는다. 결제대행사 계약이 앞에 있고, 취소와 환불 흐름, 결제가 실패했을 때의 처리가 뒤에 붙는다. 푸시 알림은 보내는 쪽 서버와 받는 쪽 설정 화면이 한 쌍이고, 광고성 알림이라면 수신 동의 절차까지 따라온다.

데이터가 기기 밖으로 나가는 순간

다섯 축 가운데 범위를 가장 크게 가르는 건 서버다. 계정이 생기거나, 여러 기기에서 같은 데이터를 봐야 하거나, 사용자끼리 서로의 글을 읽는 순간부터 서버와 데이터베이스가 범위 안으로 들어온다. 데이터가 그 사람 기기 안에만 머무는 앱이라면 이 축은 통째로 비워도 된다.

눈에 안 보이는 화면

공지를 올리고, 신고를 처리하고, 회원을 관리하고, 간단한 통계를 보는 화면. 사용자는 볼 일이 없지만 서비스를 운영하려면 누군가는 써야 하는 것들이다. 첫 버전에서 어디까지 만들지, 어떤 일은 당분간 사람이 손으로 처리할지 정하는 일도 범위 산정에 들어간다.

다섯 줄이 아직 안 채워졌어도 됩니다

“이런 앱을 만들고 싶다”는 한 줄만 들고 오셔도 상담이 됩니다. 위플의 앱 개발은 위의 다섯 축을 발주자와 함께 채워 범위 문서를 먼저 만들고, 그 문서를 기준으로 기간과 금액을 제시합니다. 다른 곳 견적서를 이미 받아 두셨다면 어느 축에서 금액이 벌어졌는지 같이 뜯어봅니다. 항목별 기준은 가격 안내에서 보실 수 있습니다.