앱 MVP Play Feature Delivery: 설치 시점·조건부·온디맨드를 나누는 5가지 기준

앱 MVP Play Feature Delivery: 설치 시점·조건부·온디맨드를 나누는 5가지 기준

Android 앱 MVP의 첫 다운로드 크기를 줄이고 싶을 때, 기능을 분리했다는 사실만으로 사용자가 그 기능을 쓸 수 있게 되는 것은 아닙니다. 설치 때 함께 들어오는지, 특정 기기에서만 자동으로 들어오는지, 사용자가 필요로 할 때 내려받는지, 다운로드가 끝나기 전 화면은 무엇을 보여 주는지를 한 결정으로 섞으면 출시 뒤 빈 화면과 재현하기 어려운 오류가 생깁니다.

Google Play의 Feature Delivery는 앱 번들을 바탕으로 기능을 feature module로 분리하고, 설치 시점·조건부·온디맨드처럼 전달 방식을 선택할 수 있게 합니다(C001). 이 글은 어떤 방식이 항상 낫다고 말하지 않습니다. 초기 팀이 기능의 필요 시점, 대상 기기, 실패 뒤 대안, 실제 설치 상태를 서로 다른 기록으로 남기기 위한 실무 기준입니다.

먼저 답하기: 기능 분리와 기능 사용 가능은 다른 상태입니다

기능 모듈은 base module에서 코드를 나누는 구조이고, 전달 방식은 그 모듈이 기기에 언제 존재할지를 정하는 선택입니다. Android Developers는 기본적으로 별도 전달 옵션을 정하지 않은 feature module은 설치 시 내려받는다고 설명합니다(C002). 즉 모듈을 만들었다고 자동으로 첫 다운로드가 줄어드는 것은 아닙니다.

기준 1: 첫 실행에 반드시 필요한 흐름은 설치 시점과 함께 판단합니다

로그인 뒤 반드시 보여야 하는 화면, 앱의 핵심 탐색처럼 첫 실행부터 필요한 기능은 “나중에 받을 수 있다”는 말만으로 분리하지 않습니다. Feature Delivery 개요는 고급 전달 옵션을 쓰지 않은 feature module이 기본적으로 설치 시 다운로드된다고 안내합니다(C002). 기능을 나누되 초기 제공을 유지할 수도 있다는 뜻입니다.

따라서 MVP 기획표에는 ‘사용자가 언제 처음 이 기능을 필요로 하는가’를 적습니다. 가입 직후 필요한 기능이라면 초기 다운로드와 시작 흐름의 책임을 함께 검수하고, 실제 사용 시점이 뒤라면 다음 기준에서 온디맨드 가능성을 검토합니다. 이 판단은 모든 기기에서 설치 용량이 줄었다는 성과 주장이 아니라, 사용자 경험의 의존성을 드러내는 설계 기록입니다.

앱 MVP의 필수 기능과 단계별 출시 범위 점검하기

기준 2: 온디맨드는 ‘요청 성공’이 아니라 설치 완료 뒤에 화면을 엽니다

온디맨드 전달은 base APK를 설치한 뒤 필요한 구성 요소를 요청해 내려받는 방식입니다(C003). Android Developers는 이 방식이 코드 리팩터링 등 추가 작업을 요구할 수 있으므로, 실제로 필요할 기능을 신중히 고르라고 안내합니다(C004). 첫 설치 크기만 보고 모든 기능을 옮기는 접근은 적절하지 않습니다.

또한 startInstall() 요청은 비동기이며, 요청만 보낸다고 설치 성공을 추적하지는 않습니다. 공식 문서는 상태 변경과 오류를 처리하기 위해 요청 상태를 모니터링하라고 명시합니다(C005). 그러므로 ‘설치 요청’, ‘다운로드 중’, ‘설치됨’, ‘실패·취소’는 별도 UI 상태로 둡니다. 기능 화면으로 이동하는 조건은 요청 버튼을 눌렀다는 사실이 아니라 해당 모듈의 설치 완료여야 합니다.

사용자의 의사가 분명한 뒤 요청하고, 대기·오류·재시도 안내를 남기는 것은 기능을 숨기는 전략이 아니라 사용 불가 상태를 정직하게 드러내는 운영 방식입니다.

기준 3: 조건부 전달은 대상 기기를 고르는 규칙이지 기능 통과 증명이 아닙니다

조건부 전달은 기기 기능·국가·API 수준·기기 모델·RAM 같은 조건에 따라 설치 시 모듈을 자동으로 내려받도록 정할 수 있습니다(C006). 조건을 모두 충족하지 않으면 해당 모듈은 설치 시 내려받지지 않으며, 뒤에 온디맨드로 요청할 수 있습니다(C007).

이 규칙은 “이 기기에서 기능이 제대로 동작한다”는 품질 증명과 다릅니다. 예를 들어 특정 하드웨어를 기준으로 모듈을 배포했다면, 실제 대상 기기에서 모듈이 포함됐는지, 기능 진입과 오류 흐름이 검수됐는지, 조건 미충족 기기에는 대안 안내가 있는지를 따로 확인해야 합니다. 조건표에는 어떤 조건을 썼는지와 그 조건을 선택한 제품 이유를 함께 남기세요.

기준 4: 모듈이 없을 때 외부 진입점과 내부 화면을 같은 경로로 취급하지 않습니다

선택 모듈에는 아직 설치되지 않았을 수 있다는 전제가 있습니다. Android Developers는 다른 앱이 실행하려 할 때 모듈이 내려받아져 있다는 보장이 없으므로 feature module의 Activity를 android:exported="true"로 지정하지 말라고 안내합니다(C008). 모듈의 코드·리소스에 접근하기 전 설치 여부도 확인해야 합니다(C009).

그래서 딥링크·알림·공유 링크처럼 앱 밖에서 들어오는 경로는 별도로 검수합니다. base에 있는 진입점이 설치 상태를 확인하고, 설치 전이면 다운로드 또는 적절한 오류 안내로 보내며, 설치 뒤에는 목적지로 이어지는지 테스트합니다. 내부 탭에서만 열어 본 결과를 외부 진입점까지 통과한 것으로 기록하지 않는 것이 핵심입니다. 관련 글 앱 MVP Android 앱 번들 배포: 업로드·기기별 제공·기능 모듈을 나누는 5가지 기준은 AAB와 기기별 제공 범위를 다룹니다. 이 글은 기능 모듈을 언제 쓸 수 있는지의 사용자 흐름에 집중합니다.

기준 5: 출시 검수에는 설치 상태와 실패 경로를 함께 남깁니다

온디맨드 모듈은 이미 설치된 기기에 다시 요청할 수도 있고, 이 경우 API가 완료된 것으로 처리합니다(C010). 지연 설치는 진행 상황을 추적할 수 없는 best-effort 요청이므로, 접근 전 실제 설치 여부를 확인해야 합니다(C011). 이런 차이 때문에 테스트 기록도 ‘API 호출됨’이 아니라 ‘대상 기기에서 해당 모듈이 설치됨’으로 작성해야 합니다.

출시 전에는 적어도 네 가지를 각각 확인합니다. 설치 시 제공되는 기능, 조건이 맞아 자동 포함된 기능, 사용자의 요청 뒤 설치가 끝난 기능, 설치되지 않았거나 실패한 기능의 안내입니다. 기기·OS·앱 버전·모듈명·진입 경로·관찰 결과·미확인 항목을 남기면, 다음 번들에서 전달 규칙이 바뀌었을 때 같은 기준으로 비교할 수 있습니다. 이는 Play Console 심사 통과나 특정 다운로드 크기 개선을 보장하지 않습니다.

우리 서비스에 맞는 앱 MVP 범위와 출시 검수 흐름 설계하기

자주 묻는 질문

기능을 모듈로 나누면 첫 다운로드가 자동으로 줄어드나요?

아닙니다. 별도 전달 옵션을 지정하지 않은 feature module은 기본적으로 설치 시 내려받습니다. 처음부터 꼭 필요한 기능인지, 설치 뒤에 필요해지는 기능인지부터 판단해야 합니다.

온디맨드 다운로드 요청이 성공하면 바로 화면을 열어도 되나요?

아닙니다. Android Developers는 요청 상태와 오류를 처리하라고 안내합니다. 화면 진입은 요청 전송이 아니라 모듈 설치 완료를 확인한 뒤에 진행하는 편이 안전합니다.

조건부 전달을 걸면 지원 기기 검수가 끝난 건가요?

아닙니다. 조건부 전달은 설치 시 모듈을 받을 기기 조건을 정합니다. 실제 대상 기기에서 모듈 포함, 진입 흐름, 기능 동작, 조건 미충족 시 대안을 각각 확인해야 합니다.

선택 모듈에 있는 화면을 외부 링크에서 바로 열 수 있나요?

설치되지 않았을 수 있으므로 그대로 가정하면 안 됩니다. base 쪽 진입점에서 설치 상태를 확인한 뒤 다운로드나 안내를 거쳐 목적지로 보내는 흐름을 검수하세요.

공식 출처

Android Developers: Overview of Play Feature Delivery — 2026-09-26 직접 확인

Android Developers: Configure on demand delivery — 2026-09-26 직접 확인

Android Developers: Configure conditional delivery — 2026-09-26 직접 확인

발행일: 2026-09-26 · 작성: 유인어스 정책자금·정부지원사업 인사이트