앱 개발 순서 총정리, 기획부터 출시까지

앱 개발 순서는 만들 범위 정하기, 개발, 검사, 스토어 테스트와 심사, 출시 뒤 하자보수의 다섯 단계로 보면 됩니다. 과학기술정보통신부 「정보시스템 개발구축 사업 표준계약서」가 범위 확정부터 검사, 하자보수까지의 순서를 정해 두었고, 애플과 구글 공식 안내가 출시 직전의 테스트와 심사를 정해 두었습니다.

외주로 맡기든 직접 만들든, 이 순서를 알면 지금 어디쯤 와 있는지와 다음에 무엇을 준비할지가 보입니다. 2026년 10월 21일에 표준계약서 원문과 App Store·Google Play 공식 안내를 직접 읽고 단계별로 정리했습니다.

표준계약서가 정한 순서 — 과업내용서로 범위 확정, 납품 뒤 14일 안에 검사, 인도한 날부터 1년 이내 하자보수 — 표준계약서가 정한 순서 — 범위 확정, 14일 안 검사, 1년 이내 하자보수 (과기정통부 표준계약서 기준, 2026년 10월 21일 확인)

1. 앱 개발 순서는 어떻게 되나요?

다섯 단계입니다. 범위·개발·검사·하자보수는 표준계약서 조항에서, 스토어 테스트와 심사는 애플·구글 공식 안내에서 나온 순서입니다.

만들 범위 정하기: 화면과 기능을 과업내용서에 적어 합의합니다
개발: 범위대로 만들고, 바뀌는 기능은 서면으로 고칩니다
검사: 다 만든 앱이 과업내용서대로 되는지 확인합니다
스토어 테스트와 심사: 테스터에게 먼저 써 보게 하고 심사에 냅니다
출시와 하자보수: 공개한 뒤 생긴 오류를 정한 기간 안에 고칩니다

표준계약서는 정부가 정한 개발 방법이 아니라 계약 양식입니다. 다만 민간 사이 소프트웨어 개발 계약에 쓰도록 만든 공식 양식이라, 일이 어떤 차례로 넘어가는지 보기에 좋습니다.

2. 만들 범위를 과업내용서로 먼저 정합니다

첫 단계는 무엇을 만들지 문서로 정하는 일입니다. 표준계약서는 이 문서를 과업내용서라고 부르고, 요구사항정의서처럼 이름이 달라도 최종 합의한 범위를 적은 문서면 같다고 봅니다.

표준계약서 제5조는 계약 뒤 지체 없이 과업내용서를 발급해 과업내용을 확정하라고 적었습니다. 범위를 바로 정하기 어려우면 따로 분석·설계를 거쳐 정할 수 있는데, 그 예정일은 전체 계약기간의 30% 안에 두도록 했습니다(특약으로 넘길 수 있음).

화면과 기능 목록이 과업내용서에 적혀야 그다음 단계인 검사와 하자보수의 기준이 생깁니다. 범위를 정리하는 법은 앱 개발 기획서 쓰는 법에서, 핵심 기능만 먼저 만드는 방식은 MVP 개발 뜻에서 다룹니다.

3. 개발 중에 바뀌는 기능은 서면으로 고칩니다

만들다 보면 기능을 더하거나 빼고 싶어집니다. 표준계약서 제7조는 이미 확정했거나 만들고 있는 과업도 두 사람이 합의해 서면으로 바꿀 수 있다고 적었습니다.

말로 추가 작업을 시킨 경우도 정해 두었습니다. 업체가 받은 지시를 서면으로 알렸는데 발주자가 7일 안에 서면으로 답하지 않으면, 그 내용대로 과업이 바뀐 것으로 추정합니다.

한국인공지능·소프트웨어산업협회(KOSA)의 「SW사업 대가산정 가이드」 2025년 개정판도 「과업내용의 변경은 그 변경이 필요한 부분의 이행 전에 완료해야 함」이라고 적었습니다. 바꿀 기능은 만들기 전에 문서로 정리하는 편이 다툼이 적습니다.

4. 다 만들면 14일 안에 검사합니다

업체가 앱을 넘기면 발주자가 검사합니다. 표준계약서 제16조는 검사 대상을 과업내용서의 과업으로 한정하고, 과업내용서에 없는 사항을 이유로 검사를 미루거나 거부할 수 없다고 적었습니다.

검사는 앱을 받은 날이나 업체가 검사를 요청한 날부터 14일 안에 마쳐야 합니다(특약으로 기간을 따로 정할 수 있음). 이 기간 안에 결과를 서면으로 알리지 않으면 합격한 것으로 봅니다.

불합격이면 업체가 재검사를 요청할 수 있고, 발주자는 요청받은 날부터 10일 안에 재검사를 마칩니다. 잔금은 검사에 합격한 때에만 청구할 수 있다고 제8조에 적혀 있습니다.

개발 중 기능을 바꿀 때 — 합의해 서면으로 변경, 말로 시킨 작업은 업체가 서면 통지 후 7일 안에 답이 없으면 변경으로 추정 — 바뀌는 기능은 서면으로 — 말로 시킨 작업은 7일 안에 답하지 않으면 변경으로 추정 (과기정통부 표준계약서 제7조 기준, 2026년 10월 21일 확인)

5. 스토어에 내기 전 테스트와 심사를 거칩니다

검사를 마친 앱은 스토어 심사를 받아야 사람들이 내려받을 수 있습니다. 애플 「앱 심사 지침」 2.1은 심사에 내는 앱이 임시 문구나 빈 웹사이트 없는 최종 버전이어야 하고, 로그인이 필요하면 시연 계정을 넣으라고 적었습니다.

애플은 심사 기간을 영문 App Review 안내에 이렇게 적었습니다.

"App Review works around the clock, typically reviewing at least 50% of submissions in less than 24 hours and 90% in less than 48 hours."

보통 제출 건의 50% 이상은 24시간 안에, 90%는 48시간 안에 심사한다는 뜻입니다. 같은 안내는 제출한 앱이 불완전하면 심사가 늦어지거나 통과하지 못할 수 있다고 덧붙였습니다.

구글 Play는 평균 심사 기간을 밝히지 않았습니다. 다만 특정 개발자 계정은 검토에 최대 7일이 걸리고 예외적인 상황에서는 더 걸릴 수 있다고 Play Console 고객센터에 적었습니다.

2023년 11월 13일 이후 만든 구글 개인 개발자 계정이면 단계가 하나 더 있습니다. 테스터 12명 이상이 14일 연속 참여한 비공개 테스트를 거친 뒤에야 정식 출시(프로덕션)를 신청할 수 있습니다.

스토어 심사 기간 — 애플은 보통 50% 이상 24시간 안, 90%는 48시간 안, 구글은 특정 계정 최대 7일, 2023년 11월 13일 이후 개인 계정은 테스터 12명 14일 비공개 테스트 — 스토어 심사 — 애플 보통 90%가 48시간 안, 구글 특정 계정 최대 7일 (Apple App Review·Play Console 고객센터, 2026년 10월 21일 확인)

6. 출시한 뒤에는 하자보수 기간이 이어집니다

출시로 일이 끝나지 않습니다. 표준계약서 제21조는 업체의 하자보수 보증기간을 검사를 마치고 인도한 날부터 1년 이내 범위에서 계약서에 정한 기간으로 하고, 그 안의 하자는 즉시 무상으로 고치도록 했습니다.

하자보수 기간은 계약서 앞장(계약 전문)에 정한 기간을 따르므로, 계약할 때 몇 개월인지 숫자로 적어 두어야 합니다. 발주자의 유지·관리 소홀이나 사용상 부주의처럼 제21조가 꼽은 사유로 생긴 문제는 하자보수 대상이 아닙니다. 출시 뒤 드는 돈은 앱 유지보수 비용에 정리해 두었습니다.

정리하면 앱 개발은 다음 순서로 진행합니다.