이 글의 순서
선정됐는데 앱 개발 상담은 무엇부터 준비해야 할까요?
정부지원사업에 선정되면 사업계획서에 적은 서비스를 실제로 만들어야 하지만, 어디까지 정리해서 앱개발업체에 전달해야 하는지 막막할 수 있습니다. 화면설계서나 상세 기획서를 처음부터 완성할 필요는 없습니다. 먼저 협약 조건, 사업비, 마감 일정과 반드시 확인해야 하는 기능을 공유하면 현재 조건에서 가능한 개발 범위를 함께 정할 수 있습니다.
중요한 것은 자료의 양이 아니라 개발업체가 아래 세 가지를 판단할 수 있게 하는 것입니다.
데브크래프트는 전달받은 내용을 바탕으로 핵심 화면과 사용 과정을 직접 눌러볼 수 있는 형태로 먼저 확인합니다. 이 과정에서 빠진 기능과 불필요한 기능을 구분하고, 확인된 범위를 기준으로 개발 일정을 정합니다.
확인해보세요
- 사업 기간 안에 개발과 검수를 마칠 수 있는가?
- 사용할 수 있는 사업비로 어떤 기능까지 만들 수 있는가?
- 협약과 평가에서 반드시 확인해야 하는 결과는 무엇인가?
1. 협약서와 사업 공고문
선정 안내보다 먼저 확인할 것은 실제 협약 조건입니다. 같은 정부지원사업이라도 운영기관과 협약에 따라 개발비를 사용할 수 있는 기간, 필수 결과물과 검수 방식이 다를 수 있습니다.
협약서가 아직 나오지 않았다면 공고문과 선정 안내를 먼저 전달하고, 최종 계약 범위는 협약 조건이 확정된 뒤 결정하는 것이 좋습니다.
지원금으로 인정되는 비용, 부가세, 자부담과 정산 서류는 개발업체의 설명만으로 결정하지 말고 운영기관에 최종 확인해야 합니다.
확인해보세요
- 협약 시작일과 사업 종료일
- 외주 개발비 집행 가능 기간
- 중간보고와 최종보고 일정
- 웹 공개 또는 앱 마켓 등록 조건
- 필수 제출물과 검수 방식
2. 선정된 사업계획서
사업계획서는 서비스의 목표와 선정 당시 약속한 내용을 이해하는 기준이 됩니다. 문서 전체를 다시 작성하기보다 제출한 원본을 전달하고, 평가 과정에서 특히 강조한 부분이 있다면 함께 설명하세요.
앱개발업체는 사업계획서에서 다음 내용을 먼저 확인합니다.
사업계획서에 기능이 많이 적혀 있어도 모두 첫 개발에 넣어야 한다는 뜻은 아닐 수 있습니다. 협약상 필수 결과와 첫 출시 기능, 이후 추가 기능으로 나눌 수 있는지 운영기관과 함께 확인해야 합니다.
확인해보세요
- 해결하려는 고객의 문제
- 서비스를 실제로 사용할 사람
- 핵심 기능과 운영 방식
- 선정 과정에서 강조한 기술이나 데이터 활용
- 사업 기간 안에 확인해야 하는 성과
3. 사용할 수 있는 사업비와 집행 조건
예산을 알려주지 않고 모든 기능의 견적부터 받으면 실제 집행 가능한 범위와 맞지 않는 제안이 나올 수 있습니다. 앱 개발에 사용할 수 있는 금액과 부가세·자부담 조건을 알려주면 예산 안에서 먼저 만들 기능을 정하기 쉽습니다.
견적을 비교할 때는 총액만 보지 말고 고객용 앱·웹, 관리자, 서버, 외부 서비스 연결, 테스트와 출시 지원이 각각 포함되는지 확인하세요. 자세한 비교 기준은 앱 개발 견적서 확인 체크리스트에서 볼 수 있습니다.
확인해보세요
- 개발에 사용할 수 있는 총예산
- 부가세 포함 여부와 자부담 금액
- 계약금·중도금·잔금 지급 가능 시점
- 서버, 문자, 지도, 결제 등 별도 운영비 사용 가능 여부
- 디자인, 콘텐츠 제작과 데이터 입력 비용의 포함 여부
4. 사업 종료일과 결과보고 일정
사업 종료일 하루만 전달하면 실제 개발 가능 기간을 정확하게 계산하기 어렵습니다. 개발 완료 뒤에도 고객 검수, 오류 보완, 서버 배포, 앱 마켓 심사와 결과자료 정리가 필요하기 때문입니다.
다음 날짜를 가능한 범위에서 구분해 전달하세요.
마감 직전까지 개발하는 일정은 결과자료와 심사 보완 시간을 확보하기 어렵습니다. 기존 정부지원사업 앱 개발 일정 가이드처럼 최종보고일에서 거꾸로 개발·검수·출시 일정을 정하는 것이 안전합니다.
확인해보세요
- 개발 계약을 시작할 수 있는 날짜
- 중간보고 또는 중간점검 날짜
- 주요 기능을 확인해야 하는 날짜
- 앱·웹 개발 완료 목표일
- 앱 마켓 제출 또는 웹 공개 목표일
- 최종 검수와 결과보고 마감일
5. 반드시 필요한 기능과 확인 기준
“예약 앱”, “교육 플랫폼”, “AI 서비스”처럼 서비스 이름만 전달하면 업체마다 필요한 범위를 다르게 해석할 수 있습니다. 사용자가 앱에서 반드시 완료해야 하는 행동과 운영자가 반드시 처리해야 하는 업무를 문장으로 적어주세요.
예를 들어 예약 서비스라면 다음처럼 설명할 수 있습니다.
추천, 고급 통계와 복잡한 자동화처럼 첫 결과 확인에 꼭 필요하지 않은 기능은 이후 개발로 나눌 수 있습니다. 기능을 임의로 제외하기 전에 사업계획서와 평가 조건에 영향을 주는지 운영기관에 확인해야 합니다.

확인해보세요
- 고객이 날짜와 시간을 선택해 예약을 신청한다.
- 관리자가 신청 내용을 확인하고 승인한다.
- 고객이 승인 결과를 알림으로 확인한다.
- 관리자가 예약 변경과 취소 내역을 관리한다.
6. 사용자와 관리자 역할
고객이 사용하는 앱만 만들어서는 실제 서비스를 운영하기 어려울 수 있습니다. 회원, 판매자, 강사, 상담사와 관리자처럼 역할이 나뉜다면 각 사용자가 무엇을 보고 처리하는지 알려주세요.
운영자가 매일 반복할 업무를 먼저 정리하면 필요한 관리자 화면과 자동화 범위를 판단하기 쉽습니다. 실제 앱과 관리자 화면의 차이는 앱·관리자 데모에서 직접 확인할 수 있습니다.
확인해보세요
- 서비스를 가장 먼저 사용할 고객은 누구인가?
- 파트너나 공급자처럼 별도 사용자가 필요한가?
- 가입 승인과 권한 관리는 누가 하는가?
- 신청, 결제, 취소와 환불은 누가 처리하는가?
- 콘텐츠와 공지, 통계는 누가 관리하는가?
7. 외부 서비스와 이미 보유한 자료
결제, 문자, 지도, 본인인증, AI와 공공데이터는 개발 외에 계정 생성과 사용 승인이 필요할 수 있습니다. 사용하고 싶은 서비스가 정해졌다면 업체명과 현재 준비 상태를 알려주세요. 아직 정하지 못했다면 필요한 기능만 설명하고 상담에서 후보를 정할 수 있습니다.
이미 보유한 자료도 함께 전달하면 다시 만드는 작업을 줄일 수 있습니다.
계정은 가능하면 서비스를 운영할 회사나 사업자 명의로 준비하고, 개발업체에는 필요한 권한만 제공하는 것이 장기 운영과 인수에 유리합니다.

확인해보세요
- 로고와 브랜드 색상
- 기존 디자인 또는 참고 서비스
- 회원·상품·콘텐츠 등 이전할 데이터
- 개인정보처리방침과 서비스 이용약관
- Apple·Google 개발자 계정
- 도메인, 서버와 외부 서비스 계정
- 결과보고 양식과 화면 자료 규격
처음 상담할 때는 여섯 가지만 알려주셔도 됩니다
모든 자료가 준비될 때까지 상담을 미룰 필요는 없습니다. 아래 여섯 가지가 있으면 1차 상담에서 일정과 예산의 위험을 먼저 확인할 수 있습니다.
데브크래프트는 30분 전화 상담에서 사업 조건과 만들려는 서비스를 먼저 확인하고, 필요한 경우 대면 또는 화상 상담에서 기능 범위, 출시와 운영 방향을 자세히 정리합니다. 개발 과정과 화면 확인 방식은 전체 개발 진행 방식에서 확인할 수 있습니다.
정부지원사업으로 진행한 실제 개발 구조는 HeadLog 건강데이터 기반 두통 기록 앱 사례에서 볼 수 있습니다. 개발 결과보고서 전체를 대신 작성하거나 평가 결과를 보장하지는 않지만, 구현 기능과 주요 화면, 테스트와 배포 상태처럼 개발 내용을 설명하는 자료는 진행 과정에서 함께 정리할 수 있습니다.
선정된 사업명, 사용할 수 있는 사업비와 종료일을 알려주시면 사업비와 개발 일정 30분 무료 상담에서 현재 조건으로 가능한 개발 범위와 먼저 준비할 내용을 확인해드립니다.
확인해보세요
- 선정된 사업명
- 앱 개발에 사용할 수 있는 사업비
- 사업 종료일과 결과보고일
- 서비스를 사용할 핵심 고객
- 반드시 구현해야 하는 기능
- 현재 보유한 기획·디자인·데이터 자료


