견적서 두 장에 모두 ‘회원가입, 예약, 결제’가 적혀 있는데 금액은 다를 수 있습니다. 한쪽에는 고객이 보는 화면만 들어 있고, 다른 쪽에는 예약을 변경하는 관리자 기능과 결제 취소 처리까지 포함돼 있다면 같은 개발을 비교하고 있는 것이 아닙니다.
앱 개발비를 검토할 때는 총액을 먼저 판단하기보다 고객이 신청한 일이 운영자에게 넘어가 처리되는 과정까지 포함됐는지 살펴보는 편이 좋습니다. 화면 이름이 같아도 그 뒤에서 해야 할 일은 다를 수 있기 때문입니다.
기능 이름보다 처리 범위를 맞춰야 합니다
예약 서비스를 예로 들어보겠습니다. 다음은 특정 프로젝트의 견적이 아니라, 같은 기능 이름 아래에서 범위가 달라지는 경우를 설명한 예시입니다.
| 견적서의 기능 이름 | 고객 화면에서 할 일 | 함께 확인할 운영 범위 |
|---|---|---|
| 예약 | 날짜와 시간을 선택해 신청 | 중복 예약 방지, 일정 변경, 운영자 승인 여부 |
| 결제 | 금액 확인 후 결제 | 취소·부분 취소, 실패 상태 확인, 정산 자료 |
| 알림 | 처리 결과 안내 받기 | 발송 조건, 실패 확인, 재발송 권한, 이용 요금 |
| 회원 | 가입·로그인·정보 수정 | 탈퇴 처리, 담당자 권한, 계정 복구 |
이 항목을 전부 첫 버전에 넣어야 한다는 뜻은 아닙니다. 무엇은 개발하고 무엇은 사람이 처리할지, 제외한 부분은 어떤 방법으로 운영할지를 함께 정해야 한다는 뜻입니다. 견적에서 빠진 일이 실제 서비스에서도 사라지는 것은 아닙니다.
관리자와 서버는 별도 화면이 아니라 서비스의 뒷부분입니다
고객이 문의를 남겼는데 운영자가 확인할 방법이 없다면 접수 기능은 절반만 만들어진 셈입니다. 파일을 올릴 수 있다면 보관 위치와 다운로드 권한이 필요하고, 처리 상태를 바꾸면 고객에게 알려줄지도 정해야 합니다.
케이엠웍스의 동국제강 모바일 운송관리도 모바일 업무 처리와 업무용 메시징을 함께 구축한 사례입니다. 이런 업무 시스템을 검토할 때는 앱 화면 수만 세기보다 현장 담당자와 관리자가 어떤 정보를 주고받는지 살펴봐야 범위를 놓치지 않습니다.
처음 만드는 비용과 계속 쓰는 비용을 나눠 보세요
견적서에서 개발비와 서버 이용료, 외부 서비스 사용료, 운영 지원비를 구분해 달라고 요청하세요. 결제·문자·지도 같은 연동은 연결 기능을 만드는 비용과 서비스를 사용하는 비용이 서로 다릅니다. 이용 계약을 누가 맺고 어느 계정으로 운영하는지도 정해둘 필요가 있습니다.
출시 지원 역시 ‘배포 포함’ 한 줄로 끝내기보다는 앱스토어 등록, 서버 반영, 운영 설정, 초기 오류 대응 중 어디까지 포함하는지 확인하는 것이 좋습니다. 유지보수는 지원 기간뿐 아니라 오류 수정과 기능 추가의 경계도 봐야 합니다.
견적 요청 전에 준비할 자료
완성된 기획서가 꼭 필요한 것은 아닙니다. 다음 다섯 가지가 정리돼 있으면 첫 범위 검토를 시작할 수 있습니다.
- 누가 사용하고, 어떤 일을 끝내야 하는 서비스인지
- 고객의 신청을 누가 확인하고 처리하는지
- 반드시 필요한 기능과 나중에 추가해도 되는 기능
- 연결해야 할 기존 시스템과 그 담당자
- 희망 일정, 예산 범위, 참고 서비스에서 필요한 부분
참고 앱을 보내실 때는 ‘이 앱처럼’보다 ‘이 예약 방식은 필요하고, 커뮤니티 기능은 필요 없다’고 구분해 주시면 좋습니다. 구현할 범위를 좁히는 데 훨씬 도움이 됩니다.
아직 범위가 정해지지 않은 항목은 견적서에서도 미정으로 표시하고, 어떤 조건이 확인되면 금액을 확정할 수 있는지 남겨두세요. 불확실한 항목이 어디 있는지 알아야 일정과 예산을 함께 관리할 수 있습니다.
앱·관리자·서버의 연결 범위는 플랫폼 구축 가이드에서 이어서 확인할 수 있습니다. 구상 중인 기능과 운영 방식을 제작 문의에 남겨주시면, 함께 개발할 범위와 나눠 진행할 범위를 검토하겠습니다.