앱 MVP Android target SDK 전환: 변경 범위·호환성·실기기 검수를 나누는 5가지 기준
앱 MVP Android target SDK 전환: 변경 범위·호환성·실기기 검수를 나누는 5가지 기준
Android 앱 MVP에서 target SDK를 올릴 때 가장 흔한 혼동은 “빌드가 성공했다”와 “전환이 끝났다”를 같은 신호로 보는 일입니다. `compileSdk`는 새 API에 접근할 수 있는 컴파일 범위를, `targetSdk`는 앱의 런타임 동작과 테스트한 플랫폼 버전을 나타낸다고 Android Developers는 설명합니다(C001). 따라서 숫자를 바꾼 뒤에는 설정 파일, 새로 적용되는 동작, 외부 라이브러리, 실제 기기 흐름, 배포 후보를 따로 읽어야 합니다.
최신 Android 마이그레이션 문서는 새 OS에서 기존 앱의 호환성을 먼저 시험하고, 이어 새 target SDK에만 적용되는 동작 변경을 검토하라고 안내합니다(C002). 호환성 도구는 `targetSdkVersion`을 바꾸지 않고도 일부 대상 동작 변경을 개별적으로 켜고 시험할 수 있습니다(C003). 이 글은 특정 앱의 통과·심사·출시를 보장하지 않습니다. 대신 MVP 팀이 전환 과정에서 남겨야 할 다섯 가지 확인 기록을 정리합니다.
먼저 답하기: target SDK 전환은 숫자 하나가 아니라 다섯 개의 다른 확인입니다
`targetSdk`를 올리면 특정 버전에서 대상 앱에만 적용되는 동작이 한꺼번에 활성화될 수 있습니다(C003). 반면 최신 OS에서 앱을 실행해 보는 기본 호환성은 target SDK 값을 바꾸지 않고도 먼저 시험할 수 있습니다(C002). 두 검수는 순서상 연결되지만, 같은 증거는 아닙니다.
구분 | 확인할 질문 | 완료로 오해하기 쉬운 신호 |
|---|---|---|
build 설정 | compileSdk·targetSdk·minSdk는 각각 무엇인가 | Gradle 숫자 한 줄을 바꿈 |
플랫폼 동작 | 새 target에서 적용되는 변경은 무엇인가 | 앱 첫 화면이 열림 |
의존성 | 라이브러리·외부 SDK가 새 환경에서 어떤 상태인가 | 앱 코드만 컴파일됨 |
기기 검수 | 핵심 흐름을 어느 OS·기기·폼팩터에서 봤는가 | 에뮬레이터 한 대 통과 |
배포 판단 | 서명된 후보와 스토어 상태는 무엇인가 | 로컬 APK 설치 성공 |
기준 1: compileSdk·targetSdk·minSdk를 같은 뜻으로 쓰지 않습니다
Android Developers는 `minSdk`를 지원하려는 가장 낮은 Android 버전으로, `compileSdk`를 새 API 접근 범위로, `targetSdk`를 런타임 동작과 테스트한 버전의 선언으로 구분합니다(C001). `targetSdk`와 `compileSdk`는 반드시 같을 필요가 없다고도 안내합니다(C001). 그러므로 전환 기록의 첫 줄에는 세 값을 각각 남기고, 이번 변경에서 실제로 바꾼 값을 표시하세요.
이 구분은 ‘새 API를 코드에서 쓸 수 있다’와 ‘새 플랫폼 동작을 앱이 대상으로 선언했다’를 분리합니다. 예를 들어 compile SDK를 올려 경고를 먼저 살펴보는 작업, target SDK를 올려 대상 동작을 켜는 작업, min SDK를 유지해 호환 기기를 정하는 작업은 다른 선택입니다. 어느 값도 제품 기능·외부 SDK·배포 적합성을 자동으로 증명하지 않습니다.
기준 2: ‘모든 앱’ 동작과 ‘새 target’ 동작을 두 묶음으로 확인합니다
Android의 새 버전에는 target SDK와 무관하게 최신 OS에서 실행되는 모든 앱에 영향을 줄 수 있는 동작 변경이 있고, 새 target SDK를 선언한 앱에 추가로 적용되는 변경도 있습니다(C002). 따라서 새 기기에서 기본 호환성을 먼저 확인한 뒤, 전환 후보에서 대상 앱용 변경을 별도 목록으로 검수하는 흐름이 필요합니다.
각 목록에는 영향을 받을 수 있는 화면과 작업을 적습니다. 예를 들어 로그인, 파일 선택, 권한 요청, 알림 탭, 백그라운드 작업, 결제 전후, 딥링크처럼 시스템 경계가 있는 흐름은 전환 뒤 다시 확인할 후보가 될 수 있습니다. 이것은 해당 기능이 반드시 바뀐다는 주장이 아닙니다. 앱이 실제로 사용하는 API·권한·라이브러리와 해당 Android 버전의 공식 동작 변경 문서를 대조해야 하는 QA 방법입니다.
Android 17 마이그레이션 안내도 최신 플랫폼에서 기존 기능을 시험한 후, 새 target에 적용되는 동작 변경을 중점적으로 검토하라고 설명합니다(C002). 기능별 결과에는 재현한 OS·기기, 테스트 계정 또는 조건, 통과·실패·미확인 상태를 남기세요. 한 화면의 성공을 전체 전환의 성공으로 일반화하지 않게 됩니다.
기준 3: 호환성 토글은 원인 분리에 쓰고, 최종 전환과 혼동하지 않습니다
Android 호환성 프레임워크 도구는 개발자 옵션 또는 ADB로 개별 동작 변경을 켜고 끌 수 있게 해 줍니다(C003). 새 target SDK를 아직 바꾸지 않은 상태에서도 특정 변경의 영향을 분리해 시험할 수 있다는 뜻입니다(C003). 문제가 생겼을 때 여러 변경을 한꺼번에 추측하기보다, 관련 변경 하나와 핵심 흐름 하나를 연결해 보는 데 유용합니다.
다만 토글에서 통과했다는 사실은 최종 빌드의 모든 조건을 재현한 증거가 아닙니다. 토글의 변경 ID, 기기·이미지, 앱 빌드 식별자, 실행한 흐름, 로그 또는 관찰 결과를 기록하고, 실제 target SDK를 올린 release 후보에서 같은 흐름을 다시 검수하세요. 디버그 가능한 앱에서 가능한 도구 조건과, 배포 후보에서 확인한 조건도 구분해야 합니다.
관련 글 앱 MVP Android 성능 측정: 릴리스 빌드·기기 조건·결과 해석을 나누는 5가지 기준은 성능 결과의 비교 조건을 다룹니다. 이 글은 target SDK 전환에 따른 동작 변경과 검수 범위를 분리하는 글입니다.
기준 4: 외부 라이브러리와 SDK는 앱 코드와 별도 행으로 확인합니다
Android 17 마이그레이션 문서는 플랫폼·API·서드파티 SDK 문제를 보고하고, 앱 안의 라이브러리와 SDK가 최신 Android에서 예상대로 동작하는지 점검하라고 안내합니다(C002). 따라서 앱 코드 검색만으로 전환 영향이 없다고 결론내리면 안 됩니다. 의존성 그래프, 잠금 파일, Gradle 플러그인, 외부 SDK의 현재 지원 안내, manifest 병합 결과를 별도로 확인하세요.
확인하지 못한 공급사 지원 범위는 `UNKNOWN`으로 남기는 편이 낫습니다. 업데이트 가능한 버전이 보인다는 사실, 새 OS에서 기능이 실행됐다는 사실, 공급사가 해당 target SDK를 지원한다고 문서로 밝힌 사실은 서로 다른 수준의 근거입니다. 특히 인증·결제·분석·알림처럼 제품 흐름에 걸친 SDK는 정상 경로와 오류·취소·복구 경로를 함께 시험해야 합니다.
이 점검은 개인정보 적합성, 스토어 심사, 보안 또는 성능을 보장하지 않습니다. 다만 누구의 확인이 남았는지와 어떤 근거가 비어 있는지를 분리해 다음 결정을 추적 가능하게 만듭니다.
기준 5: Play 요구사항·서명 후보·공개 상태를 마지막에 다시 읽습니다
Google Play의 공식 target API 안내는 2026년 8월 31일부터 신규 앱과 업데이트가 Android 16(API 36) 이상을 target해야 제출할 수 있다고 명시합니다. Wear OS·Android Automotive OS, Android TV·Android XR에는 다른 기준이 적혀 있으며, 기존 앱의 신규 사용자 공개 가능 조건과 연장 요청 안내도 별도로 설명합니다(C004). 이 요구사항은 날짜와 배포 채널·폼팩터에 따라 바뀔 수 있으므로, 실제 제출 직전에 최신 원문과 로그인한 Play Console 상태를 다시 확인해야 합니다.
전환의 마지막 기록에는 release 후보의 버전 코드·서명 산출물, target SDK, 테스트한 기기·OS, 남은 알려진 이슈, 업로드·검토·공개 상태를 나눠 두세요. 로컬 설치 성공은 스토어 제출 성공과 다르고, 업로드 성공은 공개 완료와 다릅니다. 변경이 보이는 콘솔 화면도 실제 사용자에게 공개된 스토어 상태를 단독으로 증명하지 않을 수 있습니다.
우리 앱의 target SDK 전환 체크리스트 설계하기
자주 묻는 질문
target SDK를 올리면 compile SDK도 반드시 같은 값으로 올려야 하나요?
Android Developers는 compileSdk가 새 API 접근을, targetSdk가 앱의 런타임 동작을 정한다고 설명합니다. 값의 관계와 실제 빌드 구성은 프로젝트에 따라 확인해야 하므로, 같은 숫자라는 사실만으로 전환 완료를 판단하지 않는 편이 좋습니다.
새 OS에서 앱이 열리면 target SDK 전환 검수도 끝난 건가요?
아닙니다. 최신 OS에서의 기본 호환성, 새 target SDK에 의해 활성화되는 동작 변경, 라이브러리와 SDK 호환성, 핵심 사용자 흐름은 별도 확인 대상입니다.
호환성 토글 테스트가 실제 target SDK 변경을 대체하나요?
호환성 프레임워크 도구는 대상 변경을 개별적으로 켜고 끄며 영향 범위를 시험하는 데 도움을 줄 수 있습니다. 다만 최종 target SDK·빌드 구성·배포 후보를 바꾸고 검수하는 절차 자체를 대신하지는 않습니다.
Google Play의 target API 요구사항이 모든 배포 채널에 똑같이 적용되나요?
공식 Play 안내는 Google Play 업로드와 공개 가능 상태의 요구사항을 설명합니다. 내부 배포, 다른 스토어, 기기 범위와 예외는 사용 중인 채널과 최신 공식 안내를 따로 확인해야 합니다.
공식 출처
Android Developers: Configure your build — 2026-09-28 직접 확인
Android Developers: Compatibility framework tools — 2026-09-28 직접 확인
Android Developers: Migrate apps to Android 17 — 2026-09-28 직접 확인
Android Developers: Meet Google Play's target API level requirement — 2026-09-28 직접 확인
발행일: 2026-09-28 · 작성: 유인어스 정책자금·정부지원사업 인사이트