Google Play 타겟 API 36 기한: 2026년 8월 31일에 달라지는 것

Google은 Play 스토어의 타겟 API 하한선을 해마다 한 번씩 올리고, 2026년은 API 36 주기입니다. 헷갈리는 부분은 숫자가 아닙니다. "타겟 API 수준 요구사항"이라는 하나의 이름 아래에 사실은 규칙이 두 개 들어 있다는 점이 헷갈립니다. 하나는 무엇을 업로드할 수 있는지를 정하고, 다른 하나는 더 낮은 기준으로 이미 게시된 앱을 누가 설치할 수 있는지를 정합니다. 이 질문으로 검색되는 페이지 대부분이 둘을 뭉뚱그리고, 그래서 개발자가 다시 만들 필요 없는 앱을 다시 만들거나 정작 중요했던 Play Console 경고를 그냥 넘기게 됩니다.

이 글은 그 둘을 갈라놓고, 기기 유형별 숫자를 정리한 다음, 8월이면 저희 문의함에 실제로 들어오는 질문에 답합니다. 테스터 12명이 14일 연속 참여하는 비공개 테스트(closed testing)가 절반쯤 진행된 앱은 어떻게 되느냐는 질문입니다. PrimeTestLab은 개발자를 대신해 그 테스트 쪽을 맡고 있어서 이 일정 충돌을 자주 봅니다. 해당 섹션의 안내는 서비스를 쓰든 직접 테스터를 모집하든 똑같이 적용됩니다. 아래의 모든 날짜와 수준은 2026년 8월 9일에 Google 문서에서 직접 확인했으며, Google이 실제로 문서화하지 않은 부분은 그럴듯한 추측으로 메우지 않고 그렇다고 표시했습니다.

한 문장으로 보는 규칙

2026년 8월 31일부터 일반적인 휴대전화, 태블릿, 폴더블, Android Auto 앱은 Google Play에 제출하려면 Android 16, API 수준 36 이상을 타겟으로 해야 합니다. 완전히 새로운 앱이든 이미 게시된 앱의 업데이트든 마찬가지입니다. 이 한 문장이 대부분의 독자에게 해당합니다. 예외와, 손대지 않는 앱에 적용되는 별도의 더 낮은 기준선이 이 글 나머지의 주제입니다.

이름은 하나, 규칙은 둘

Google은 "타겟 API 수준 요구사항"이라는 표현을 전혀 다르게 동작하는 두 가지에 함께 씁니다. 이 둘을 구분해 두는 것이 이 페이지로 할 수 있는 가장 값진 일입니다.

그래서 업데이트 계획 없이 API 35에 조용히 머물러 있는 앱은 규칙 2에 따라 8월 31일에 요구사항을 충족한 상태이고, 무언가를 출시하려는 순간 규칙 1에 따라 미충족 상태가 됩니다. 모순이 아니라 설계입니다. Google은 스토어에 남아 있는 것의 기준보다 스토어에 새로 들어오는 것의 기준을 더 빨리 올립니다.

Google이 정확히 정의한 세 단어

정책은 세 용어에 기대고 있고, 각각의 뜻이 여러분이 어느 규칙 아래 있는지를 정합니다.

• 새 앱: "아직 Google Play에 게시되지 않은" 앱입니다. 어떤 패키지 이름의 첫 업로드를 말합니다.
• 기존 앱: 이미 Google Play에 게시되어 있는 앱입니다.
• 앱 업데이트: 현재 버전을 대체하려고 검토에 제출하는 기존 앱의 새 버전입니다. 업데이트는 노출 규칙이 아니라 제출 규칙으로 판단합니다.

기기 유형별 요구사항

"Android 앱"은 한 줄이 아닙니다. 휴대전화, 태블릿, 폴더블, Android Auto는 API 36으로 갑니다. Wear OS와 Android Automotive OS는 API 35에서 멈춥니다. Android TV와 Android XR은 API 34에서 멈춥니다. 업데이트하지 않을 앱의 기준선은 이보다 더 낮고, 아래 전환 버튼이 두 묶음을 오갑니다.

Android Auto는 Android Automotive OS가 아닙니다

이 두 이름은 해마다 개발자의 시간을 실제로 잡아먹습니다. Android Auto는 휴대전화의 앱을 차량 화면에 투사하므로 그 앱은 휴대전화 앱이고 휴대전화 규칙을 따릅니다. API 36입니다. Android Automotive OS는 차량 자체에서 도는 운영체제이고, 더 낮은 타겟 예외로 지목된 항목 중 하나입니다. API 35입니다. 미디어나 내비게이션 앱을 둘 다에 내신다면 둘 중 높은 쪽이 필요합니다.

내 앱도 해당될까요? 세 가지만 답해 보세요

8월 31일이 여러분의 문제인지는 세 가지에 달려 있습니다. 지금 무엇을 하려는지, 어떤 기기 유형으로 출시하는지, 그리고 현재 빌드가 실제로 무엇을 타겟으로 하는지입니다. 아래 도구는 Google이 공개한 기준선을 그 조합에 적용해서, 여러분이 두 규칙 중 어느 쪽에 있는지 알려 줍니다.

판정이 문제없다고 나와도 마지막의 기한 전 체크리스트는 보시는 편이 좋습니다. "내 소스가 타겟 36으로 되어 있다"와 "Google이 평가한 아티팩트가 36을 선언한다"는 같은 말이 아니기 때문입니다. 이번 주기 전체에서 가장 흔한 헛된 안심은, 업로드한 번들이 아니라 Gradle 파일을 읽고 안심하는 것입니다.

8월 31일을 놓치면 실제로 벌어지는 일

여러분이 어느 규칙 아래 있느냐에 따라 결과가 둘로 갈립니다. 기준선보다 낮은 빌드를 업로드하려 하면 그 제출은 요구사항을 충족하지 못합니다. 게시된 앱을 노출 기준선 아래에서 그냥 두면, 앱의 타겟보다 높은 Android 버전을 쓰는 기기의 신규 사용자에게 검색과 설치가 되지 않습니다. 어느 쪽도 삭제가 아닙니다.

업로드를 시도하는 경우

이 결과가 무엇에 걸려 있는지 보세요. 업로드라는 행위입니다. 달력만으로는 이미 서비스 중인 빌드에 아무 일도 일어나지 않습니다. 그래서 어떤 앱이 9월 1일에는 아무 문제가 없다가 9월 2일에 막힐 수 있습니다. 순전히 버그 수정을 출시하기로 마음먹었기 때문입니다.

게시된 앱을 기준선 아래에 그대로 두는 경우

경쟁 페이지들이 "앱이 사라진다"라고 쓰는 부분인데, 중요한 지점에서 틀렸습니다. Google의 표현은 앱이 특정 사용자 그룹에게 "검색되지 않게 된다"입니다. 구체적으로는 이렇습니다.

• 더 새로운 기기의 신규 사용자가 접근하지 못합니다. 사용자의 기기가 앱의 타겟보다 높은 Android 버전을 실행하면, Google Play는 그 사용자에게 앱을 더 이상 보여 주거나 설치해 주지 않습니다.
• 더 오래된 기기의 신규 사용자는 영향이 없습니다. 앱의 타겟과 같거나 낮은 API 수준을 실행하는 기기는 여전히 앱을 받을 수 있습니다.
• 이미 설치한 사용자는 영향이 없습니다. 이미 앱을 설치한 사람은 지원되는 Android 버전에서 앱을 계속 찾고, 다시 설치하고, 사용할 수 있습니다.
• 딥링크는 사실대로 알려 줍니다. 조건에 맞지 않는 더 새로운 기기에서 Play 스토어 링크를 연 사용자에게는 이 앱이 "이전 버전의 Android용으로 만들어졌다"는 안내가 표시됩니다.

벌어지지 않는 일

해마다 8월이면 이 정책은 Google 지원 포럼에서 똑같은 네 가지 공포를 낳습니다. 그중 어느 것도 타겟 API 수준 페이지가 설명하는 내용이 아닙니다.

API 36을 타겟으로 하면 구형 기기 지원이 끊기나요?

그 자체로는 아닙니다. targetSdk는 앱이 어떤 Android 동작 수준에 맞춰 만들어지고 테스트되었는지를 선언합니다. minSdk는 앱을 설치할 수 있는 가장 낮은 Android 버전을 정합니다. 둘은 별개의 숫자이고, 타겟을 36으로 올린다고 최소치가 따라 올라가지는 않습니다. 코드와 업그레이드한 의존성이 호환되는 한, 앱은 그 최소치까지의 구형 Android 버전을 계속 지원할 수 있습니다.

주기마다 가장 큰 불안을 만드는 오해가 바로 이것입니다. 개발자가 "Android 16을 타겟으로 해야 한다"를 읽고, "Android 16에서만 돈다"는 뜻으로 받아들인 다음, Google이 방금 자기 앱이 닿을 수 있는 기기 대부분을 없앴다고 결론을 내립니다. 아래에서 최소치를 옮겨 보고 실제로 무엇이 달라지는지 확인해 보세요.

세 개의 숫자, 그리고 Google Play가 단속하는 것

지금 앱이 비공개 테스트 중이라면

새 개인 개발자 계정으로 테스터 12명, 14일 연속의 필수 비공개 테스트를 돌리고 계신다면, 기한이 그 기간 한가운데 떨어집니다. 안전한 선택은 8월 31일 전에 API 36 빌드를 같은 비공개 트랙에 올려 두고, 모든 테스터를 참여 상태로 유지하며, 기한 때문에 트랙을 바꾸거나 테스터를 다시 모으는 일이 없도록 하는 것입니다.

Google의 타겟 API 페이지와 Google의 비공개 테스트 페이지는 서로 다른 팀이 서로 다른 목적으로 쓴 문서이고, 어느 쪽도 다른 쪽을 다루지 않습니다. 그래서 실제로 빈 곳이 생기는데, 정직한 방법은 문서화된 영역이 어디서 끝나는지를 정확히 보여 드리는 것입니다.

확인된 사실

• 해당되는 새 개인 계정은 프로덕션 액세스를 신청하기 전에 최근 14일 이상 지속적으로 테스트에 참여한 테스터 12명 이상을 대상으로 비공개 테스트를 진행해야 합니다. 이는 2023년 11월 13일 이후에 만든 개인 계정에 적용됩니다. 검증됨
• Google 개발자 문서는 업로드된 APK가 Play의 타겟 API 요구사항을 충족해야 한다고 밝히며, 테스트 트랙에 대한 예외는 공개하지 않았습니다. 이 표현은 테스트 전용이 아니라 트랙을 가리지 않는 서술이므로, 기한 이후 비공개 트랙에 새로 올리는 빌드는 API 36이 필요하다고 보고 계획하세요. 이는 강한 추론이지 테스트 트랙에 대해 문서화된 규칙은 아닙니다. 일부 확인
• Google 자신의 안내는 문제를 고치는 동안 비공개 테스트 중인 앱을 계속 업데이트하도록 권장하며, 자격 기간을 고정된 하나의 아티팩트가 아니라 테스터 참여의 연속성을 기준으로 정의합니다. 검증됨
• 내부 테스트는 테스터 100명이 상한이며, 자격을 주는 비공개 테스트를 대신하지 못합니다. 검증됨

Google이 문서화하지 않은 것

답을 모르는 상황이므로 올바른 전략은 답을 맞히려 드는 것이 아닙니다. 날짜 전에 요구사항을 충족하는 빌드를 트랙 안에 두어서 그 질문 자체를 무의미하게 만드는 것입니다. 어느 쪽 결과가 나오든 안전하고, 예전 아티팩트가 어차피 계속 돌았을 경우에도 손해가 없습니다.

어느 쪽이든 안전한 순서

1. 같은 비공개 트랙과 같은 테스터 그룹을 유지하세요

   API 36 빌드를 담으려고 새 트랙을 만들지 말고, 참여 중인 테스터를 빼지 마세요. Google이 세는 14일 연속성은 테스터가 참여 상태를 유지하는지에 관한 것이므로, 지켜야 할 자산은 그 참여 명단입니다.

2. API 36은 기한 당일이 아니라 그 전에 빌드하고 테스트하세요

   마이그레이션을 별도의 작업으로 두고 별도의 테스트 회차를 잡으세요. 화면 가장자리 레이아웃이 깨진 것을 8월 30일에 발견하는 날과 8월 10일에 발견하는 날은 완전히 다릅니다.

3. 기존 비공개 트랙에 더 높은 versionCode로 올리세요

   기존 번들을 대체하는 모든 번들은 versionCode를 올려야 합니다. Google은 자격 기간을 테스터 참여의 연속성을 기준으로 정의하고 테스트 중에도 문제를 계속 고치도록 명시적으로 권장하지만, 모든 빌드 교체 상황을 포괄하는 절대적인 보장을 공개하지는 않습니다. 같은 트랙과 같은 참여 테스터를 유지하고, 업로드 후 Play Console의 카운터를 확인하세요. 이번이 첫 주기라면 테스트 도중 업데이트의 전체 메커니즘을 읽어 보실 만합니다.

4. 출시본이 실제로 테스터에게 도달했는지 확인하세요

   게시된 출시본과 전달된 출시본은 다릅니다. 비공개 출시본이 실제로 서비스 중인지, versionCode가 더 높은지, 참여 명단의 테스터가 업데이트를 볼 수 있는지 확인하세요.

5. 처리가 끝난 뒤 정책 상태를 다시 확인하세요

   번들 처리에 시간을 준 다음 앱의 정책 상태 페이지를 다시 여세요. 타겟 API 경고가 남아 있으면 아무 출시본이나 지우는 대신 점검 목록을 따라가세요.

6. 마이그레이션이 정말 제때 끝날 수 없을 때만 기한 연장을 신청하세요

   연장은 2026년 11월 1일까지 시간을 벌어 주고 영향을 받는 앱별로 신청합니다. 기술 작업을 멈출 이유는 아닙니다.

2026년 11월 1일 기한 연장 신청 방법

영향을 받는 개발자는 2026년 11월 1일까지 배포가 유지되는 기한 연장을 신청할 수 있습니다. 신청은 앱별로 하며, 해당 앱의 Play Console 정책 경고에서 시작합니다. Google은 이를 자동이라거나 보장된다거나 영구 면제라고 설명하지 않으므로, 신청이 열려 있는 동안에도 마이그레이션은 계속하세요.

Google Play Console · 실제 스크린샷 클릭하면 확대됩니다

1. Play Console에서 해당 앱을 여세요

   기한 연장은 계정 단위가 아니라 앱 단위입니다. 여러 앱을 게시하신다면 영향을 받는 앱마다 이 과정을 반복하게 됩니다.

   검증됨
2. 정책 상태로 이동하세요

   Google이 요구사항 미충족으로 보는 앱에만 타겟 API 문제가 표시됩니다. 앱이 이미 요구사항을 충족한다면 연장할 대상도, 찾을 양식도 없습니다.

   검증됨
3. 타겟 API 경고 또는 문제 세부정보를 여세요

   위 스크린샷에 보이는 문제 제목은 App must target Android 16 (API level 36) or higher입니다. 문구는 앱별로, 그리고 배포 단계에 따라 달라질 수 있으니 보장된 공통 문자열이 아니라 실제 계정 하나에서 확인된 화면으로 보세요.

   검증됨
4. 문제 화면이나 알림의 기한 연장 링크를 따라가세요

   Google은 영향을 받는 개발자 일부를 문제 패널이 아니라 앱 알림으로 안내합니다. 옵션이 없다고 결론 내리기 전에 두 곳을 모두 확인하세요.

   검증됨
5. 요청받은 정보를 제출하세요

   Google은 공개 도움말 페이지에 정확한 질문 항목을 게시하지 않았으므로, 어디선가 본 "이런 걸 물어본다" 목록은 확인되지 않은 정보로 보세요. 실제 마이그레이션 계획에 근거해 답하시면 됩니다.

   일부 확인
6. 2026년 11월 1일을 최종 시한으로 여기세요

   기한 연장은 날짜를 옮길 뿐 요구사항을 없애지 않습니다. 8월 31일까지 못 끝낸 일은 11월 1일까지는 끝나 있어야 합니다.

   검증됨
7. 신청이 열려 있는 동안에도 마이그레이션을 계속하세요

   Google의 표현 어디에도 승인을 약속하는 대목은 없습니다. 아직 받지도 않은 기한 연장을 전제로 일정을 짜는 것이 이번 주기에 할 수 있는 가장 비싼 가정입니다.

   일부 확인

하나만 더 기억해 두시면 좋습니다. Google은 기한 연장에 대한 각주를 API 36 요구사항에 붙여 두었고, 본문은 대개 연장을 기존 앱의 배포를 유지해 주는 장치로 설명합니다. 새 앱, 업데이트, 기존 앱의 모든 조합을 같은 수준의 정밀도로 훑어 주지는 않습니다. 계획 중인 특정 업로드까지 연장이 덮어 준다고 넘겨짚기 전에, 여러분 앱의 경고가 무엇을 덮는다고 말하는지 직접 읽어 보세요.

앱을 API 36으로 올리는 방법

네 단계입니다. API 36 SDK를 설치하고, compileSdk와 targetSdk를 36으로 올리고, 그 과정에서 깨지는 의존성을 업데이트하고, Android 16 동작 변경을 테스트합니다. 숫자를 바꾸는 것은 한 줄짜리 수정입니다. 앱이 여전히 제대로 도는지 증명하는 일이 실제 마이그레이션입니다.

1단계: Android 16 SDK 설치

Android Studio를 열고 SDK Manager로 가서 API 수준 36용 Android SDK Platform을 현재 36.x.x 빌드 도구와 함께 설치하세요. 플랫폼이 설치되어 있지 않으면 compileSdk를 올렸을 때 여러분이 한 일과 아무 상관 없어 보이는 빌드 오류만 납니다.

2단계: 빌드에서 수준 올리기

본인 스택을 고르세요. 파일 경로와 정확한 줄은 달라도 목적지는 같습니다. 업로드하는 번들 안의 매니페스트가 타겟 36을 선언해야 한다는 것입니다.

android {
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.app"
        minSdk = 24
        targetSdk = 36
        versionCode = 2
        versionName = "1.0.1"
    }
}

android {
    compileSdk 36

    defaultConfig {
        applicationId "com.example.app"
        minSdkVersion 24
        targetSdkVersion 36
        versionCode 2
        versionName "1.0.1"
    }
}

android {
    compileSdk = flutter.compileSdkVersion
    compileSdk = 36

    defaultConfig {
        targetSdk = flutter.targetSdkVersion
        targetSdk = 36
    }
}

buildscript {
    ext {
        buildToolsVersion = "36.0.0"
        minSdkVersion = 24
        compileSdkVersion = 36
        targetSdkVersion = 36
    }
}

ext {
    minSdkVersion = 24
    compileSdkVersion = 36
    targetSdkVersion = 36
}

3단계: 의존성과 프레임워크 도구 업데이트

컴파일 수준을 올릴 때 오래된 의존성이 무너집니다. Android Gradle Plugin, Gradle 자체, Kotlin, AndroidX 라이브러리, Google Play services, 그리고 네이티브 코드를 담고 있는 광고나 분석 SDK까지 손대게 될 각오를 하세요. 이 글은 일부러 "올바른 버전"을 적지 않습니다. 호환 버전은 매주 바뀌고, 여기 박아 둔 목록은 보름이면 사람을 잘못 이끌기 때문입니다. 마이그레이션하는 그날 프레임워크의 최신 출시 노트에서 직접 가져오세요.

4단계: 빌드, 업로드, 아티팩트 확인

• 서명된 Android App Bundle을 생성하고 versionCode를 올리세요.
• 디버그 빌드가 아니라 릴리스 아티팩트를 테스트하세요. 코드 축소와 리소스 축소는 디버그 빌드가 가려 주던 문제를 드러냅니다.
• 의도한 트랙에 업로드하고, 그 아티팩트가 타겟 API 수준 36을 보고하는지 Play Console에서 확인하세요.
• 처리가 끝나면 모든 활성 트랙을 살펴보고 정책 상태를 다시 여세요.

API 36을 출시하기 전에 테스트할 Android 16 동작

API 36을 타겟으로 하면 Android 16 기기에서 앱에 Android 16 동작이 켜집니다. 우선순위가 높은 항목은 화면 가장자리까지 쓰는 레이아웃, 예측 뒤로 가기, 큰 화면에서의 방향 자유도, 건강 권한, 고정 간격 예약, 텍스트 레이아웃입니다. 아래에서 해당하는 항목을 체크하시면 일반적인 목록이 아니라 여러분 앱에 맞는 테스트 목록이 나옵니다.

가장자리 레이아웃과 예측 뒤로 가기: 영향 범위가 가장 넓습니다

가장자리까지 쓰는 레이아웃은 앱이 특별한 API를 쓰지 않아도 걸리기 때문에 영향 범위가 넓습니다. Android 16에서 API 36을 타겟으로 하는 앱은 기존의 예외 처리 속성을 더 이상 쓸 수 없어서, 시스템 바가 자리를 비켜 줄 것이라 가정했던 콘텐츠가 이제 그 아래로 들어갑니다. 증상은 겉보기 문제로만 보이다가, 주요 버튼이 제스처 바 밑에 깔려 눌리지 않는 순간부터 실제 문제가 됩니다.

예측 뒤로 가기도 비슷하게 영향 범위가 넓습니다. 앱이 예전 방식의 뒤로 가기 처리를 등록해 두었다면, 타겟 36에서 예측 뒤로 가기가 기본으로 켜진 뒤에는 그 경로가 예전처럼 호출되지 않을 수 있습니다. 모달, WebView, 저장하지 않은 입력이 있는 폼, 종료 직전 마지막 화면까지 모든 탐색 깊이에서 뒤로 가기를 테스트하세요.

타겟 36의 보편적 문제가 아닌 것

16 KB 페이지 크기 요구사항은 어떻게 되나요?

다른 요구사항, 다른 날짜, 같은 앱들입니다. 타겟 API 기한은 매니페스트가 선언하는 수준에 관한 것입니다. 16 KB 페이지 크기 요구사항은 여러분의 네이티브 라이브러리가 메모리 페이지가 16 KB인 기기에서 동작하는지에 관한 것입니다. Google의 현재 안내는 16 KB를 지원하지 않는 대상 앱의 업데이트를 더 이상 출시할 수 없게 되는 날짜로 2027년 2월 1일을 명시합니다.

• 대상: Google의 요구사항은 64비트 Google Play 기기에서 API 35 이상을 타겟으로 하는 앱에 적용됩니다. 그중에서도 네이티브 .so 라이브러리를 직접 또는 SDK를 통해 포함하는 앱이 명시적인 재빌드와 정렬 작업이 필요할 가능성이 큽니다. 앱이 Kotlin이나 Java로만 되어 있다면 대체로 이미 호환되지만, 그래도 가정하지 말고 테스트해 보는 편이 좋습니다.
• 아닌 것: 2026년 8월 31일 타겟 API 기한의 일부가 아니며, 한쪽을 통과했다고 다른 쪽을 통과하는 것도 아닙니다.
• 같이 걸리는 이유: 이번 달에 타겟 수준을 올리는 사람은 어차피 재빌드를 하게 되고, 바로 그때 페이지 크기 문제가 드러납니다. 두 가지가 헷갈리는 이유가 이 시기 겹침입니다.

앱이 네이티브 라이브러리를 포함한다면, 페이지 크기 확인을 API 36 빌드에 막판에 끼워 넣는 대신 별도의 테스트 회차를 가진 별도 작업으로 다루세요. 두 변경은 빌드의 서로 다른 부분을 건드리고, 둘을 동시에 디버깅하는 것이야말로 일주일짜리 마이그레이션이 삼 주짜리가 되는 길입니다.

API 36을 올렸는데 경고가 그대로입니다

보통 셋 중 하나입니다. 번들 처리가 아직 끝나지 않아 정책 상태가 갱신되지 않았거나, 더 오래된 아티팩트가 다른 활성 트랙에 남아 있거나, 프로젝트는 36이어도 업로드한 아티팩트는 실제로 36을 선언하지 않는 경우입니다. 목록을 따라 내려가시고, 출시본부터 지우지는 마세요.

지금 개발자들이 보고하는 문제 제목은 Your app must target Android 16 (API level 36) or higher이며, Play Console 화면 그대로 영어입니다. Google은 모든 업로드 흐름에 대한 표준 오류 문구 전문을 공개한 적이 없으므로, 인터넷에서 찾은 정확한 문구는 그것을 포함해 공식이 아니라 관찰된 사례로 보세요.

습관 하나로 이 문제의 대부분이 영구히 정리됩니다. 업로드할 때마다 Play Console의 아티팩트에서 타겟 API 수준을 다시 읽고 versionCode 옆에 적어 두세요. 십 초면 되고, "분명히 고쳤는데"라는 부류의 문제 전체가 한 주에서 사라집니다.

기한 전 체크리스트

실제로 벌어지는 순서대로 열네 항목입니다. 마지막 네 개가 사람들이 건너뛰는 항목이고, 경고가 사라지느냐를 결정하는 것도 바로 그 넷입니다.

이 기한에서 PrimeTestLab이 맡는 부분

경계를 분명히 해 두겠습니다. 저희는 여러분의 코드를 마이그레이션하지 않습니다. targetSdk를 올리고, 의존성을 업데이트하고, Android 16 동작 변경을 고치는 일은 여러분의 빌드이고, 이 글이 그 부분에 대한 저희 기여의 전부입니다. 저희가 맡는 것은 충돌하는 나머지 절반, 새 개인 계정이 프로덕션에 도달하기 위해 필요한 실기기 테스터 12명의 14일 연속 참여입니다.

문제는 시기가 겹친다는 점입니다. 2026년 8월에 처음 출시하는 사람은 서로 아무 관계도 없는 어려운 일 두 가지를 같은 기간에 요구받습니다. API 36 빌드를 내는 일과, 자격을 주는 비공개 테스트를 2주 내내 유지하는 일입니다. 빌드는 풀 수 있는 엔지니어링 과제입니다. 실제 사람 열두 명을 모아 실기기에서 14일 동안 참여 상태로 유지하는 일이 조용히 한 달을 잡아먹는 쪽입니다.

비공개 테스트를 직접 할 때와 맡길 때

이번 달에 일을 배치하는 순서

두 문제를 동시에 마주하셨다면 순차가 아니라 병렬로 돌리세요. 비공개 테스트를 지금 시작하세요. 그 14일은 압축할 수 없는 달력 시간이기 때문입니다. 그리고 API 36 마이그레이션을 그 옆에서 함께 진행하세요. 준비가 되면 요구사항을 충족하는 빌드를 같은 비공개 트랙에 더 높은 versionCode로, 같은 테스터가 참여를 유지한 채로 밀어 넣으시면 됩니다. 그렇게 하면 기한과 테스트 기간이 같은 2주를 두고 다투지 않게 됩니다.

자주 묻는 질문

핵심 요약

2026년 8월 9일 기준 정책 스냅샷입니다. Google은 이 페이지들을 예고 없이 바꾸므로, 날짜를 근거로 무언가를 결정하시기 전에 위의 1차 출처를 확인하세요. 이 글은 8월 31일 직후와 2026년 11월 1일 이후에 다시 확인할 예정입니다.