이노베이팅 컨설팅 신청하기 (클릭)
logo
|
Blog

    앱 MVP Google Play 기기 카탈로그: 요구사항·제외 규칙·트랙을 나누는 5가지 기준

    Android MVP에서 Google Play 기기 카탈로그의 매니페스트 필터, 콘솔 제외 규칙, 트랙별 상태와 실제 QA를 분리하는 기준입니다.
    Sep 23, 2026
    앱 MVP Google Play 기기 카탈로그: 요구사항·제외 규칙·트랙을 나누는 5가지 기준

    앱 MVP Google Play 기기 카탈로그: 요구사항·제외 규칙·트랙을 나누는 5가지 기준

    먼저 답하기: 기기 지원은 ‘설치가 됐다’가 아니라 네 가지 상태를 나눠 보는 일입니다

    Android MVP를 Google Play에 올린 뒤 특정 기기에서 보이지 않거나 설치할 수 없다는 말을 들으면, 곧바로 콘솔에서 기기를 제외하거나 매니페스트를 바꾸기 쉽습니다. 하지만 그 전에 기능 요구사항, Play Console 제외 규칙, 배포 트랙, 실제 핵심 흐름 검수를 나눠 보아야 합니다.

    같은 모델이라도 배포 트랙과 번들에 따라 보이는 상태가 달라질 수 있습니다. 카메라·Bluetooth 같은 기능 선언이나 권한이 의도하지 않은 필터링으로 이어질 수도 있습니다.

    Google Play 공식 기기 카탈로그 문서는 앱 번들을 하나 이상 올린 뒤 호환 기기를 검토할 수 있다고 안내합니다(C001). Android 공식 매니페스트 문서는 Play가 `uses-feature` 선언을 사용해 요구 기능을 충족하지 않는 기기에서 앱을 필터링한다고 설명합니다(C002).

    이 글은 노출이나 심사 통과를 보장하지 않습니다. 출시 전 “누가 앱을 볼 수 있는가”와 “핵심 기능이 실제로 동작하는가”를 같은 완료 표시로 섞지 않기 위한 실무 기준입니다.

    상태

    확인할 질문

    다른 상태로 대신할 수 없는 이유

    매니페스트 요구

    앱이 반드시 필요한 하드웨어·소프트웨어 기능은 무엇인가

    코드가 기능을 쓴다는 사실만으로 필요 여부가 정해지지 않는다

    콘솔 제외

    운영상 배포하지 않을 모델·규칙이 있는가

    제외 규칙은 기능 요구와 별개의 배포 판단이다

    트랙별 가용성

    내부·비공개·공개·프로덕션 중 어느 트랙의 번들을 보나

    같은 기기라도 트랙별 번들이 달라질 수 있다

    실제 QA

    설치 뒤 핵심 과업을 끝낼 수 있는가

    카탈로그 호환 표시는 사용자 흐름 완주 증거가 아니다

    기준 1: 먼저 핵심 기능과 선택 기능을 분리합니다

    `uses-feature`는 앱이 사용하는 하드웨어 또는 소프트웨어 기능을 설명하는 매니페스트 요소입니다(C003). 공식 문서는 `android:required`로 그 기능 없이는 동작할 수 없는지, 있으면 사용하지만 없어도 앱이 동작하도록 설계됐는지를 구분할 수 있다고 설명합니다(C004). 그러므로 “카메라 권한이 있다” 또는 “Bluetooth API를 호출한다”만으로 곧바로 모든 기기에 해당 기능을 필수로 선언할 수는 없습니다.

    기능 목록을 만들 때는 화면이 아니라 핵심 과업부터 적는 편이 낫습니다. 예를 들어 현장 사진이 있으면 가치가 높아지지만 텍스트로도 신청을 완료할 수 있는 서비스라면, 카메라가 없을 때의 대체 흐름을 먼저 설계할 수 있습니다. 반대로 제품의 핵심 결과가 특정 센서 값에 의존한다면 그 센서가 없는 기기를 지원한다고 말하기 어렵습니다. 이 판단은 마케팅 문구가 아니라 제품 책임자·개발자·QA가 함께 확인할 설계 기록입니다.

    1. 사용자가 완료해야 하는 핵심 과업을 한 문장으로 씁니다.

    2. 과업마다 필요한 하드웨어·소프트웨어 기능과 대체 흐름을 나눕니다.

    3. 기능이 없으면 과업이 정말 불가능한지, 제한된 방식으로 가능한지 확인합니다.

    4. 매니페스트 선언, 실제 코드, QA 시나리오가 같은 결론을 가리키는지 검토합니다.

    우리 앱 MVP의 지원 기기 판단 기준 정리하기

    기준 2: 권한이 만든 암묵적 요구사항을 따로 점검합니다

    Android 공식 문서는 일부 하드웨어 관련 권한이 실제 기능 요구로 해석되어 Play의 필터링에 영향을 줄 수 있다고 설명합니다(C005). 특히 앱이 특정 하드웨어 기능을 사용하지만 필수는 아니라면, 해당 기능을 `required="false"`로 명시해 의도한 대로 배포 범위를 검토하는 방법을 안내합니다(C006).

    이 말은 모든 권한을 지우거나 모든 기기에 무조건 제공하라는 뜻이 아닙니다. 권한, 기능 선언, 대체 흐름을 한 묶음으로 검수하라는 뜻에 가깝습니다.

    대표적으로 카메라를 쓰는 앱은 카메라가 반드시 필요한지부터 확인해야 합니다. Android 문서는 카메라 기능을 명시하지 않으면 Google Play가 카메라를 필수로 가정해, 해당 기능을 지원하지 않는 기기를 필터링할 수 있다고 설명합니다(C007). 다만 카메라 없는 기기에도 앱을 보이게 하려면, 사용자가 실제로 카메라 없이도 핵심 과업을 계속할 수 있어야 합니다. 버튼만 남겨 두고 오류 화면으로 끝나는 상태를 ‘지원’으로 기록하지 마세요.

    점검 기록에는 “권한이 있음”, “선언이 있음”, “대체 흐름이 있음”, “대상 기기에서 실제 완료함”을 각각 남기는 것이 좋습니다. 원인을 빨리 찾으려는 마음에 매니페스트를 넓히면, 실제로는 제공할 수 없는 기능을 약속하는 결과가 될 수 있습니다.

    기준 3: 기기 카탈로그의 자동 필터와 콘솔 제외 규칙을 구분합니다

    Google Play 도움말은 배포 대상 기기가 매니페스트 선언과 Play Console의 제외 규칙, 두 요소로 결정된다고 설명합니다(C008). 매니페스트의 기능 요구로 인해 제외되는 경우와 운영자가 콘솔에서 제외한 경우는 같은 ‘보이지 않음’으로 보일 수 있지만, 수정 위치와 영향 범위가 다릅니다. 공식 안내에 따르면 제외 규칙은 지원 기기 선언을 우선하며(C009), 콘솔에서 모델을 수동 제외하면 그 모델의 모든 변형에 적용될 수 있습니다(C010).

    따라서 한 모델을 막거나 푸는 결정 전에 다음 질문을 순서대로 확인하세요. 첫째, 해당 기기에서 필수 기능이 실제로 없어서 매니페스트가 자동 필터링했는가. 둘째, 과거 테스트나 운영 이슈 때문에 콘솔 규칙으로 제외했는가. 셋째, 현재 보고 있는 상태가 어느 트랙의 번들 기준인가. 넷째, 수정 뒤에도 핵심 흐름과 오류 안내가 안전한가. 답이 다른데도 “기기 미지원” 한 줄로 처리하면 다음 릴리스에서 같은 문제가 다시 생기기 쉽습니다.

    기준 4: 트랙별 상태는 출시 상태와 사용자 경험을 분리해 읽습니다

    Google Play 기기 카탈로그 안내는 기기 지원 상태가 매니페스트 선언에 따라 트랙 수준으로 표시되며, 프로덕션·공개·비공개·내부 테스트처럼 트랙에 다른 번들이 있으면 기기별 상태도 달라질 수 있다고 설명합니다(C011). 즉 내부 테스트에서 설치되었다는 사실은 프로덕션에서 같은 기기에 노출된다는 증거가 아니고, 프로덕션에서 지원으로 보인다는 사실도 비공개 테스트 번들이 같은 조건이라는 뜻은 아닙니다.

    릴리스 회의에서는 “어느 트랙의 어느 버전 코드와 번들”인지 붙여서 기록하세요. 그리고 기기 카탈로그의 지원·제외 상태, 실제 설치 여부, 로그인이나 권한 승인 뒤의 핵심 과업 완료 여부를 서로 다른 열에 남기면 좋습니다. 이 기록은 특정 기기를 차단할 근거가 아니라, 다음 변경에서 누가 어떤 가정을 다시 검수해야 하는지 보여 주는 지도입니다.

    관련 글 앱 MVP Google Play 테스트: 내부·비공개·공개 트랙을 고르는 5가지 기준은 테스트 범위를 고르는 관점에 초점을 둡니다. 이번 글은 같은 기기라도 매니페스트·콘솔 규칙·트랙에 따라 배포 대상 해석이 달라지는 경계를 다룹니다.

    기준 5: 마지막 검수는 카탈로그 화면이 아니라 대표 기기에서의 과업 완료입니다

    기기 카탈로그는 배포 대상 판단을 돕지만, 앱의 모든 실제 동작을 대변하지는 않습니다. 공식 문서도 카탈로그가 Instant App에는 적용되지 않는다고 명시합니다(C012). 따라서 카탈로그의 상태를 앱 품질이나 모든 배포 경로의 완료 증거로 확대하면 안 됩니다.

    대표 기기 목록을 작게라도 정하고, 각 기기에서 설치·첫 실행·권한 거절·네트워크 오류·핵심 과업 완료·재실행을 확인하세요. 실패하면 “모델명”만 남기지 말고 트랙, 앱 버전, OS 버전, 매니페스트 요구, 콘솔 규칙, 재현 절차를 나눠 기록합니다. 그래야 다음 릴리스에서 규칙을 되돌릴지, 대체 흐름을 보완할지, 지원 범위를 그대로 둘지 판단할 수 있습니다.

    출시 전 배포 범위와 핵심 흐름을 함께 점검하기

    자주 묻는 질문

    기기 카탈로그에 보이면 그 기기에서 앱 품질까지 보장되나요?

    아닙니다. 카탈로그는 배포 대상과 호환 상태를 검토하는 근거 중 하나입니다. 실제 설치 뒤 핵심 과업, 권한 거절과 오류 상황은 별도 QA로 확인해야 합니다.

    기능을 선택적으로 쓰면 항상 `required="false"`로 선언해야 하나요?

    기능이 없어도 앱이 실제로 핵심 과업을 수행하도록 설계됐는지부터 판단해야 합니다. Android 공식 문서는 필수 기능과 선택 기능을 구분하는 `android:required` 속성을 안내합니다. 앱의 기능·대체 흐름·테스트 결과를 함께 검토하세요.

    콘솔에서 기기를 제외하면 특정 테스트 트랙에만 적용할 수 있나요?

    공식 Play Console 안내는 선택한 기기 모델 제외가 앱 전체에 적용되며, 개별 번들 또는 APK만 따로 제외할 수는 없다고 설명합니다. 실제 운영 변경 전에는 현재 콘솔 화면과 영향 범위를 다시 확인하세요.

    내부 테스트에서 설치됐는데 프로덕션에서 보이지 않는 이유는 무엇인가요?

    트랙별로 서로 다른 번들이 배포되면 기기 지원 상태도 달라질 수 있습니다. 먼저 어느 트랙의 어느 버전 기준인지, 매니페스트 선언과 콘솔 제외 규칙이 무엇인지 분리해 확인하세요.

    공식 출처

    Google Play Console Help: View and restrict your app's compatible devices — 2026-09-23 확인

    Android Developers: <uses-feature> — 2026-09-23 확인

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

    Share article
    유인어스 정책자금·혁신기업 전환 컨설팅

    유인어스는 주식회사 넥스트빌더가 운영하는 정책자금 및 혁신기업 전환 컨설팅 브랜드입니다. 기업의 업종·업력·재무상태를 진단해 적합한 정책금융기관과 준비 절차를 안내합니다.

    유인어스 홈 컨설팅 신청 RSS