이 글의 순서
선정 안내보다 협약서의 완료 기준을 먼저 봅니다
같은 이름의 지원사업이라도 운영기관과 협약에 따라 사용할 수 있는 개발비, 마감과 제출물이 다를 수 있습니다.
아직 협약서가 나오지 않았다면 선정 안내, 예상 개발 사업비, 사업 종료일과 사업계획서의 핵심 기능으로 1차 상담을 할 수 있습니다. 다만 최종 범위와 계약 일정은 실제 협약 조건을 확인한 뒤 정해야 합니다.
지원금으로 인정되는 비용과 부가세, 자부담, 계약·검수 서류는 사업마다 다릅니다. 개발업체의 설명만으로 결정하지 말고 협약 지침과 운영기관에 확인하세요. DevCraft가 표시하는 개발비는 부가세 포함 기준이지만 실제 집행 인정 여부를 보장하지는 않습니다.
확인해보세요
- 협약 시작일과 사업 종료일은 언제인가?
- 외주 개발 계약과 비용 집행이 가능한 기간은 언제인가?
- 중간보고·최종보고·검수 완료일은 각각 언제인가?
- 완료해야 하는 필수 기능이나 화면이 정해져 있는가?
- 웹 공개, 앱 마켓 제출 또는 사용자 테스트가 필요한가?
최종보고일에서 거꾸로 일정을 잡습니다
마지막 날까지 개발하면 검수와 자료 정리 시간이 사라집니다. 사업 마감보다 앞선 내부 완료일이 필요합니다.
위 기간은 일반적인 안전 여유이며 사업 조건과 개발 범위에 따라 달라집니다. 이미 남은 기간이 짧다면 기능을 무리하게 모두 넣기보다 협약에서 반드시 확인해야 하는 결과를 먼저 구분하고, 이후 기능은 추가 개발로 나누는 판단이 필요합니다.
마감 3~4주 전
주요 기능 개발을 마치고 고객 검수, 오류 수정과 외부 서비스 연결을 확인합니다.
마감 2~3주 전
서버 배포, 웹 공개 또는 앱 마켓 제출을 진행하고 심사 보완 가능 시간을 남깁니다.
마감 1~2주 전
구현 기능, 주요 화면, 테스트와 배포 자료를 최종 양식에 맞춰 정리합니다.
사업계획서 기능을 필수·첫 출시·이후 기능으로 나눕니다
선정 과정에서 작성한 계획은 목표를 설명하기 위해 범위가 크게 잡혀 있을 수 있습니다. 실제 개발은 사업비와 남은 기간 안에서 완료 가능해야 합니다.
고객, 파트너, 관리자 등 여러 역할이 있다면 가장 중요한 사용자 한 종류의 흐름부터 완성하는 방법도 검토할 수 있습니다. 초기 사용량이 적다면 복잡한 자동 정산이나 승인 과정을 관리자 수동 처리로 시작해 일정과 예산을 줄일 수 있습니다.
범위를 줄일 때는 임의로 기능을 빼지 말고 협약 담당자에게 변경 가능한 범위와 절차를 확인해야 합니다. 개발업체는 가능한 개발 방법을 제안할 수 있지만 평가 기준의 최종 판단은 운영기관의 안내를 따라야 합니다.
필수 결과
협약과 평가 조건에서 반드시 구현하거나 확인해야 하는 핵심 기능과 제출물입니다.
첫 출시 기능
사용자가 핵심 행동을 끝내고 관리자가 실제 운영할 수 있도록 필요한 기능입니다.
이후 추가 기능
추천, 고급 통계, 복잡한 자동화처럼 첫 결과를 확인한 뒤 개발해도 되는 기능입니다.
중간보고 전에 화면과 기능을 직접 확인합니다
중간보고 직전에 처음 화면을 보면 빠진 기능을 고칠 시간이 부족합니다. 개발 중 확인 시점을 미리 정하세요.
확인 결과는 말로만 남기지 말고 화면별 의견과 결정 내용을 기록하세요. 고객사에서 여러 사람이 확인한다면 최종 결정 담당자를 정하고 의견 전달일을 일정표에 넣는 것이 좋습니다. 고객 확인이 늦어지면 개발 완료와 결과자료 준비 일정도 함께 밀릴 수 있습니다.
확인해보세요
- 계약 직후 핵심 화면과 사용 과정 확인
- 디자인 확정 전 고객·관리자 흐름 확인
- 주요 기능 연결 후 실제 데이터 입력과 예외 상황 확인
- 중간보고 전 구현 화면과 진행 현황 정리
- 최종 검수 전 기능별 완료·보완 목록 확정
화면이 모두 완성될 때까지 기다리지 말고 로그인, 핵심 행동, 관리자 처리처럼 중요한 흐름부터 순서대로 확인하세요.
외부 서비스 승인과 앱 마켓 심사를 별도 일정으로 둡니다
결제, 공공데이터, 지도, 본인인증과 앱 마켓은 개발업체만의 일정으로 결정되지 않습니다.
외부 서비스마다 사업자 자료, 도메인, 개인정보 처리 내용, 보증보험이나 별도 심사가 필요할 수 있습니다. 고객이 만들어야 하는 계정과 제출 자료를 개발 초기에 확인하세요. 승인이 늦어질 가능성이 있다면 임시 데이터로 개발을 진행할 수 있는지와 최종 연결 시점을 함께 정합니다.
Apple과 Google 마켓 심사는 개발 완료와 출시 완료가 같은 날이라는 보장이 없습니다. 계정 준비, 앱 정보와 이미지, 개인정보 관련 페이지, 테스트 계정과 심사 보완 시간을 따로 잡아야 합니다. 지원사업에서 “출시”가 필수라면 웹 공개로 가능한지, 마켓 등록 완료가 필요한지 운영기관에 먼저 확인하세요.
확인해보세요
- Apple·Google 계정과 사업자 인증이 준비됐는가?
- 결제·문자·지도·공공데이터 제공사의 승인 담당자가 정해졌는가?
- 마켓 심사 보완이 생겨도 사업 마감 전 대응할 시간이 있는가?
결과자료는 개발 마지막이 아니라 단계마다 준비합니다
결과보고서를 전부 개발업체가 대신 작성하는 것은 아니지만, 실제 개발을 설명하는 자료는 개발 과정에서 남길 수 있습니다.
운영기관 양식이 있다면 개발 초기에 전달하고 개발 관련 항목 중 업체가 준비할 수 있는 범위를 확인하세요. 회계·정산 증빙, 지원금 적격 여부와 최종 평가 결과는 개발업체가 판단하거나 보장할 수 없습니다.
중간 확인 때마다 화면과 기능 상태를 기록하면 마지막에 자료를 다시 만드는 부담이 줄어듭니다. 최종보고 직전에는 개발 결과와 사업계획서 표현이 다르지 않은지 고객이 직접 확인해야 합니다.
기능 자료
계약 범위와 실제 구현한 기능 목록, 변경·제외된 기능의 확인 기록입니다.
화면 자료
고객과 관리자의 주요 화면, 핵심 사용 과정과 동작을 확인할 수 있는 자료입니다.
테스트 자료
중요 기능의 테스트 항목, 확인 결과와 보완 내역입니다.
배포 자료
서버 배포, 웹 공개, 앱 마켓 제출과 운영 환경을 설명하는 자료입니다.
남은 기간이 짧다면 완료 가능한 범위를 먼저 확정합니다
짧은 일정 자체보다 더 위험한 것은 필수 기능과 결정 담당자가 정해지지 않은 상태로 개발을 시작하는 것입니다.
먼저 사업 마감일, 사용 가능한 사업비, 필수 결과와 외부 승인 여부를 한 장으로 정리하세요. 그다음 가장 중요한 사용자가 목표 행동을 끝내는 흐름과 이를 처리할 최소 관리자 기능을 정합니다. 자료 제공일과 고객 확인일을 고정하면 개발 가능 여부를 판단하기 쉬워집니다.
범위가 제한된 프로젝트는 약 2개월, 일반적인 신규 앱·웹은 평균 약 3개월, 복잡한 프로젝트는 약 4~6개월이 걸릴 수 있습니다. 남은 기간이 이보다 짧다면 기존 서비스 개선, 제한된 웹 기능 또는 관리자 일부처럼 완료 기준이 분명한 방식도 검토해야 합니다.
선정 알림만 받은 상태라도 사업명, 예상 사업비와 종료일을 알면 1차 상담에서 일정 위험을 먼저 확인할 수 있습니다.
