앱 MVP Android 16KB 페이지 크기: 네이티브 코드·정렬·실행 검증을 나누는 5가지 기준
Android 앱 MVP의 출시 준비에서 “테스트 기기에서 앱이 열렸다”는 한 줄은 충분한 기록이 아닐 수 있습니다. Android 15부터는 16KB 메모리 페이지 크기로 구성된 기기를 지원합니다.
Android 15(API 35) 이상을 타깃하는 Google Play 앱 업데이트에는 64비트 기기의 16KB 페이지 크기 지원 요건이 적용됩니다. 하지만 이 사실만으로 우리 앱이 영향을 받는지, 빌드를 고쳐야 하는지, 실제 앱 흐름을 통과하는지는 알 수 없습니다.
먼저 답하면, 초기 Android MVP 팀은 대상 업데이트의 조건, 앱·SDK에 네이티브 코드가 있는지, 공유 라이브러리와 APK의 정렬 상태, 16KB 환경에서의 실행 관찰, 릴리스 판단 기록을 서로 다른 확인 항목으로 남기는 편이 좋습니다.
이 글은 Android Developers 공식 문서를 바탕으로 한 기술 점검 기준입니다. 특정 앱의 Google Play 심사·출시 가능 여부, 설치 성공, 성능 개선, 보안·정책 적합성, 트래픽·전환·매출 성과를 보장하지 않습니다.
앱 번들의 배포 경로 자체는 Android 앱 번들 배포 기준에서, 사용자가 지원할 OS 범위를 정하는 판단은 앱 MVP 지원 OS 범위 기준에서 따로 다룹니다.
여기서는 그 사이에 있는 16KB 호환성의 빌드와 검증 경계에 집중합니다.
먼저 구분할 것: 적용 조건과 현재 앱의 영향 여부
Android Developers는 Android 15(API 35) 이상을 타깃하는 Google Play 앱이 64비트 기기에서 16KB 메모리 페이지 크기를 지원해야 한다고 안내합니다. 문서에 따르면 2027년 2월 1일부터 이 지원이 없는 앱 업데이트는 출시할 수 없습니다.
이 요건은 특정 팀에게 곧바로 “오늘 수정해야 한다”는 우선순위를 뜻하지는 않습니다. 대상 버전, 업데이트인지 신규 배포인지, 64비트 바이너리와 실제 배포 경로를 한 릴리스 기록에서 분리해야 합니다.
target SDK가 35 이상이다와 앱에 네이티브 코드가 있다도 같은 질문이 아닙니다. Android Developers는 C/C++ 코드, NDK, 네이티브 라이브러리를 쓰는 외부 SDK·의존성, 네이티브 라이브러리를 쓰는 앱 빌더가 있으면 네이티브 코드를 사용한다고 설명합니다.
반대로 Java·Kotlin 코드와 모든 라이브러리·SDK가 네이티브 코드를 쓰지 않는 구성이라면 16KB 기기를 지원한다고 설명하면서도 16KB 환경 테스트를 권합니다. 팀은 “영향 없음”을 기억에 의존하지 말고, 현재 APK와 의존성 목록으로 확인한 날짜·빌드 번호를 남겨야 합니다.
기준 1. .so 존재와 앱 전체 호환성을 같은 결과로 쓰지 않습니다
Android Developers는 APK Analyzer에서 APK의 lib 폴더를 확인해 공유 객체 파일인 .so가 있는지 보라고 안내합니다. .so가 있다면 앱이 네이티브 코드를 사용한다는 신호입니다.
이는 출발점이지, 해당 라이브러리가 이미 16KB에 맞춰 빌드되었거나 실제 앱이 문제 없이 작동한다는 증거는 아닙니다.
확인표에는 검사한 APK 또는 AAB 식별, lib 폴더·.so 관찰, 직접 작성한 코드인지 SDK 의존성인지, 라이브러리 공급자·버전, 다음 조치 담당자를 나눠 둡니다.
SDK가 네이티브 라이브러리를 포함한다는 사실과, 공급자가 어떤 버전에서 16KB 지원을 밝히는지는 서로 다른 근거입니다. “SDK를 최신으로 올렸다”만으로 실제 패키지의 결과를 대체하지 마세요.
기준 2. 빌드 도구 업데이트와 공유 라이브러리 정렬을 분리합니다
16KB 기기에서 압축되지 않은 공유 라이브러리를 제공하는 앱은 16KB ZIP 정렬 경계가 필요합니다. Android Developers는 이 경우 Android Gradle Plugin 8.5.1 이상으로의 업데이트를 안내합니다.
또한 NDK r28 이상은 16KB ELF 정렬로 기본 컴파일하며, 미리 빌드한 공유 라이브러리도 다시 컴파일해 다시 포함해야 할 수 있다고 설명합니다.
여기서 “AGP 또는 NDK를 올렸다”는 도구 설정의 사실입니다. 우리 APK 안의 모든 관련 .so가 정렬됐다는 산출물 검사 결과입니다.
둘을 같은 완료 표시로 묶으면 오래된 외부 SDK·직접 포함한 .so·별도 빌드 경로가 확인표에서 빠질 수 있습니다. 빌드 설정, 의존성 교체, 새로 만든 APK 검사 로그를 나란히 남기세요.
기준 3. zipalign 실행과 수정 작업을 혼동하지 않습니다
Android Developers의 zipalign 문서는 -c 옵션이 정렬만 검사하고 APK를 수정하지 않는다고 설명합니다. 공유 라이브러리가 담긴 APK의 16KB 정렬 확인에는 zipalign -c -P 16 -v 4 existing.apk 명령을 제시합니다.
이 명령의 결과는 특정 파일을 특정 조건으로 검사한 기록입니다. 앱 코드·의존성·서명·배포 트랙을 전부 확인했다는 선언은 아닙니다.
특히 커스텀 빌드 시스템을 쓰는 팀은 정렬 수행 위치와 서명 순서를 따로 검토해야 합니다. zipalign 문서는 apksigner를 쓰는 경우 APK 서명 전에 정렬해야 하며, 서명 뒤 APK를 바꾸면 서명이 무효가 된다고 안내합니다.
이 글은 팀의 정확한 빌드 명령을 처방하지 않습니다. 검사 대상 파일명, 명령, 실행 시각, 결과, 해당 파일이 어떤 릴리스 후보인지가 이어지도록 기록하세요.
기준 4. 호환 모드 표시를 최종 통과로 읽지 않습니다
Android Developers는 16KB 커널에서 특정 조건이면 앱이 16KB backcompat 모드로 실행될 수 있고, 이 모드는 일부 앱이 작동하도록 도울 수 있다고 설명합니다.
동시에 가장 신뢰성 있고 안정적인 결과를 위해서는 앱이 16KB에 정렬되어야 한다고 안내합니다. 호환 모드 관찰과 네이티브 라이브러리·패키징·앱 동작의 목표 상태는 분리하세요.
android:pageSizeCompat는 애플리케이션의 페이지 크기 호환 모드 설정을 재정의할 수 있는 매니페스트 속성입니다. 이 속성의 존재는 “설정을 넣으면 문제가 해결된다”는 보장이 아닙니다.
왜 이 옵션을 검토하는지, 현재 설정값은 무엇인지, 실제 16KB 환경에서 어떤 흐름을 관찰했는지를 같은 변경 기록에 두고 앱별로 검토하세요.
기준 5. 패키지 검사 뒤에는 16KB 환경의 사용자 흐름을 따로 봅니다
공식 문서는 16KB 환경에서 테스트한 뒤 adb shell getconf PAGE_SIZE가 16384을 반환하는지 확인하고, 페이지 크기를 전제로 한 코드가 영향을 받는 구역을 충분히 테스트하라고 안내합니다.
Android Emulator의 Android 15 이상 16KB 시스템 이미지, 지원 기기의 개발자 옵션 등은 문서에서 제시한 테스트 경로입니다.
여기서 중요한 것은 에뮬레이터를 만들었다는 사실과 실제 핵심 흐름을 관찰했다는 사실도 다르다는 점입니다. 팀의 최소 기록은 다음처럼 시작할 수 있습니다.
대상 릴리스의 target SDK·64비트 구성·배포 경로를 적었는가.
현재 APK의
.so와 네이티브 SDK·의존성을 확인했는가.빌드 도구·사전 빌드 라이브러리 변경과
zipalign검사 결과를 연결했는가.16KB 환경에서
PAGE_SIZE=16384을 확인한 기기 또는 에뮬레이터를 기록했는가.로그인, 핵심 기능, 파일·네트워크 처리처럼 우리 앱에 실제로 필요한 흐름의 관찰 결과와 미확인 항목을 나눴는가.
이 다섯 줄은 출시 통과 도장이 아닙니다. 어떤 사실을 확인했고 무엇이 아직 미확인인지가 드러나는 릴리스 판단의 시작점입니다.
유인어스는 민간 사업 지원 서비스입니다. 실제 업데이트 전에는 현재 Android Developers 문서, 앱의 빌드·의존성·서명·Play Console 설정, 실제 16KB 환경의 테스트 결과를 함께 검토하세요.
자주 묻는 질문
Kotlin으로만 작성했다면 16KB 점검이 필요 없나요?
Android Developers는 Java·Kotlin 코드와 모든 라이브러리·SDK가 네이티브 코드를 쓰지 않는 앱은 16KB 기기를 지원한다고 설명합니다. 다만 예기치 않은 동작 회귀가 없는지 16KB 환경에서 테스트할 것을 권합니다.
실제 앱의 SDK와 의존성은 별도로 확인하세요.
APK Analyzer에서 .so가 보이면 곧바로 호환되지 않는 건가요?
아닙니다. .so는 네이티브 코드 사용 여부를 확인하는 신호입니다. 해당 라이브러리의 빌드·정렬 상태와 16KB 환경의 실제 실행 관찰은 추가로 확인해야 합니다.
zipalign -c가 통과하면 출시 준비가 끝난 건가요?
아닙니다. -c는 정렬을 검사할 뿐 APK를 수정하지 않습니다. 통과 결과는 검사한 파일의 정렬 기록이며, 앱의 핵심 흐름·서명·배포 트랙·실기기 결과는 별도 확인 대상입니다.
호환 모드로 실행되면 16KB 정렬은 하지 않아도 되나요?
그렇게 단정할 수 없습니다. Android Developers는 호환 모드가 일부 앱을 작동하게 할 수 있다고 설명합니다.
동시에 신뢰성과 안정성을 위해 16KB 정렬을 권합니다. 앱별 빌드와 테스트 근거를 분리해 검토하세요.
확인한 공식 출처
- Android Developers · Support 16 KB page sizes — Android 15의 16KB 기기 지원, Google Play 호환성 안내, 네이티브 코드 확인, 빌드·정렬·16KB 환경 테스트 기준을 2026-09-20 KST에 직접 확인했습니다. - Android Developers · zipalign — -c, -P 16, APK 서명 전후의 정렬 주의사항을 2026-09-20 KST에 직접 확인했습니다. - Android Developers · application element — android:pageSizeCompat 속성의 문서화 범위를 2026-09-20 KST에 직접 확인했습니다.