앱 아이디어를 구체화하다 보면 회원가입, 알림, 관리자 화면, 통계, 기존 시스템 연결이 모두 필요해 보입니다. 담당자는 빠진 기능이 나중에 문제가 될까 걱정하고, 개발사는 기능 목록을 기준으로 견적을 만듭니다. 하지만 처음 애플리케이션 시제품 개발에서 먼저 답할 질문은 “무엇을 얼마나 많이 만들까”가 아닙니다. 누가 어떤 일을 직접 해보면 다음 개발비를 투입할지 판단할 수 있는가입니다.
이 질문이 없으면 시제품은 두 방향으로 흔들립니다. 화면은 많지만 실제 사용을 확인하지 못하는 데모가 되거나, 운영 준비가 부족한 서비스를 성급히 공개하게 됩니다. 범위를 줄인다는 것은 아이디어를 포기하는 일이 아닙니다. 이번 단계에서 확인할 불확실성과, 확인 뒤에 결정할 일을 나누는 일입니다.
한 사람의 업무가 끝나는 장면부터 고른다
첫 범위는 사용자 한 명, 상황 하나, 행동 하나, 확인할 결과 하나로 잡는 편이 좋습니다. 예를 들어 현장 점검 앱을 검토한다고 가정해 보겠습니다. “점검 업무를 디지털화한다”는 말은 너무 큽니다. 대신 “현장 담당자가 점검 직후 사진과 메모를 남기고, 관리자가 그 기록을 보고 후속 조치를 정할 수 있는가”로 바꾸면 만들 이유가 선명해집니다.
이 경우 첫 시제품에는 점검 항목 확인, 사진과 메모 등록, 제출 기록, 관리자 확인 화면이 필요할 수 있습니다. 일정 자동 배정, 비용 정산, 월간 통계, 복잡한 권한 체계는 다음 판단으로 미룰 수 있습니다. 중요한 것은 화면 수가 적은지가 아닙니다. 담당자가 기존 메신저, 종이 양식, 엑셀보다 새 흐름을 택하는지 확인해야 합니다.
반대로 사용자가 누구인지, 어느 순간에 가장 불편한지가 아직 모호하다면 작동하는 앱부터 만들 필요는 적습니다. 이때는 화면 시안이나 눌러볼 수 있는 모형으로 업무 순서가 이해되는지 확인하는 편이 낫습니다. 실제 데이터 연결, 현장 인터넷 환경, 기기 기능처럼 구현 자체가 불확실할 때에만 제한된 사용자와 데이터로 작동하는 시험 앱을 고려하면 됩니다.
시제품의 종류는 확인하려는 위험에 맞춘다
“시제품”이라는 말은 서로 다른 결과물을 가리킵니다. 발표용 화면, 클릭 가능한 모형, 로그인과 저장이 되는 시험 앱, 외부 공개가 가능한 첫 서비스는 필요한 시간과 준비가 다릅니다. 이를 구분하지 않으면 클릭형 화면으로 확인할 일을 코드 개발에 쓰거나, 운영 서비스에 필요한 준비를 시험 앱 범위에서 빠뜨릴 수 있습니다.
업체와 첫 상담을 할 때는 기능 요구보다 아래 네 가지 답을 받아보는 편이 유용합니다.
- 이번 시제품에서 가장 틀렸을 때 손해가 큰 가정은 무엇인가
- 사용자가 끝내야 할 한 가지 업무와, 그 결과로 내릴 다음 결정은 무엇인가
- 이번 견적에서 의도적으로 빼는 기능은 무엇이며, 무엇이 확인되면 다음 단계에 넣는가
- 실제 사용자는 누가 언제 써보고, 어떤 반응이나 기록을 보면 확대·수정·중단을 정하는가
좋은 제안은 “기능을 모두 만들 수 있다”는 답보다 이 네 항목의 연결을 보여줍니다. 예를 들어 현장 담당자가 입력을 끝까지 완료하지 않는다면, 통계 화면을 더 만드는 일보다 입력 순서, 사진 첨부 부담, 통신이 끊기는 장소 같은 원인을 먼저 확인해야 합니다. 사용성 문제와 구현 문제를 같은 개발 범위로 묶지 않는 업체가 수정 비용도 더 잘 통제할 가능성이 큽니다.
업체 선택에서는 만들지 않을 것과 남는 것을 확인한다
같은 업종의 경험은 결제, 의료 정보, 위치 정보처럼 업무 규칙이 개발 방식에 큰 영향을 주는 경우 도움이 됩니다. 다만 일반적인 업무 흐름을 검증하는 첫 단계라면 포트폴리오의 화면 수보다, 업체가 모호한 요구를 작은 검증 흐름으로 바꾸는지 보는 편이 더 직접적입니다. “관리자 기능도 넣어야 한다”는 요구에 곧바로 견적을 더하기보다, 관리자가 첫 단계에서 무엇을 판단해야 하는지 되묻는지가 기준이 될 수 있습니다.
또 하나는 중단하거나 업체를 바꿔도 남는 자산입니다. 화면 원본과 소스코드만 받는다고 이어서 개발할 수 있는 것은 아닙니다. 스토어 계정, 소스 저장소, 클라우드 환경이 업체 개인이나 업체 명의로만 관리되면 권한을 옮기는 과정에서 연결 설정을 다시 준비해야 할 수 있습니다. 처음부터 발주사 조직이 계정 소유자와 관리자 권한을 확보하고, 업체에는 필요한 작업 권한을 부여하는 방식이 교체나 재개발의 부담을 줄이는 데 유리합니다.
상담 자리에서는 이렇게 물어보면 됩니다. “계약을 종료하거나 개발사를 바꾸면 우리 조직 명의로 남는 계정, 소스 저장소, 클라우드 자산은 무엇인가요? 관리자 권한과 배포 절차는 언제, 어떤 자료와 함께 넘겨받나요?” 답이 문서 목록에만 머물지 않고 실제 계정 구조와 인계 시점을 설명한다면, 시제품 이후의 선택지도 확보한 셈입니다.
첫 회의에서 기능 목록을 더 길게 만들기보다, 한 사람이 오늘의 방식 대신 앱으로 끝내 볼 업무 장면을 하나 정해 보십시오. 그 장면을 시험하는 데 필요한 것과 아직 만들지 않을 것을 함께 말할 수 있는 업체라면, 시제품을 납품물보다 다음 투자 판단을 위한 도구로 다룰 가능성이 높습니다.
