앱이 16 KB 메모리 페이지 크기를 지원해야 한다는 경고, 이렇게 해결합니다

경고는 짧고, 기껏해야 파일 이름 하나를 알려 주며, 빌드가 끝났다고 생각한 다음에야 찾아옵니다. 그래서 늘 같은 세 가지 잘못된 길로 접어듭니다. 이미 바뀐 기한을 믿거나, 프레임워크만 올려 놓고 일이 끝났다고 여기거나, 로컬 APK 하나만 확인하고 정작 Google이 빌드에 쓰는 번들은 들여다보지 않는 것입니다. 이 글은 문제가 실제로 풀리는 순서대로 짰습니다. 확인하고, 원인을 지목하고, 고치고, 증명합니다. 모든 내용은 2026년 8월 5일 기준이며, Google의 페이지 크기 가이드가 마지막으로 갱신된 바로 그날 대조했습니다. 근거가 공식 릴리스 노트가 아니라 유지보수자의 이슈 트래커인 경우에는 사실로 반올림하지 않고 카드에 그대로 밝혀 두었습니다.

세 단계로 해결하기

요구사항 자체는 범위가 좁습니다. Google의 페이지 크기 가이드는 Android 15(API 레벨 35) 이상을 타깃으로 하는 앱이 64비트 기기에서 16 KB 메모리 페이지 크기를 지원해야 하며, 2027년 2월 1일부터는 그렇지 않은 업데이트를 출시할 수 없다고 밝힙니다. 적용 대상은 네이티브 코드뿐입니다. 앱과 그 안의 모든 라이브러리와 SDK가 순수 Java 또는 Kotlin이라면 이미 16 KB 기기를 지원한다고 Google이 명시합니다. 문제는 이 경고를 본 개발자 대부분이 자기가 그 범주에 든다고 믿지만 실제로는 아니라는 점입니다.

한 화면에 담은 판단 전체

의존성 버전을 하나라도 바꾸기 전에 이 흐름을 따라가 보십시오. 2분쯤 걸리는데, 맞는 것을 고치는 일과 애초에 문제가 아니었던 패키지 열한 개를 올리는 일의 차이가 여기서 갈립니다.

Play Console 경고가 실제로 뜻하는 것

표현이 중요한 이유는, 이 이야기의 공포 버전이 정확한 버전보다 빨리 퍼지기 때문입니다. Google이 실제로 보여 주는 문구를 읽고 나면 적용 범위는 좁고 다룰 만한 크기가 됩니다.

이 카드를 읽을 때 흔히 두 가지를 잘못 읽습니다. 첫째, "Action by Feb 1, 2027"은 삭제까지 남은 카운트다운이 아닙니다. 같은 페이지의 Google 본문도 결과를 그런 업데이트를 출시할 수 없다는 것으로 설명합니다. 둘째, Extension granted라는 문자열이 Google 스크린샷에 보이기는 하지만, 그것이 지금 나에게 연장 신청 절차가 열려 있다는 근거는 되지 않습니다. 본인 Play Console 안에서 그 선택지가 실제로 보일 때만 연장이 있다고 판단하십시오.

읽으신 기한은 어느 쪽인가요?

세 개의 날짜가 돌아다니고 있고 살아 있는 것은 하나뿐입니다. 보신 날짜를 고르시면, 2026년 8월 5일에 마지막으로 갱신된 Google의 현행 문서와 대조해 상태를 알려 드립니다.

16 KB 요구사항이 내 앱에도 해당되나요

순수 Java 또는 Kotlin 앱

이 부분에서 Google은 분명합니다. 앱과 그 안의 모든 라이브러리와 SDK가 Java 또는 Kotlin만 쓴다면 그 앱은 이미 16 KB 기기를 지원합니다. 다만 예기치 못한 회귀를 잡기 위해 16 KB 환경에서 테스트해 보라고 권장하는데, 에뮬레이터 한 번 돌리는 비용입니다.

함정은 "그 안의 모든 라이브러리와 SDK"라는 표현입니다. 데이터베이스, 분석, 크래시 리포팅, 미디어, 지도, 머신러닝, 보안 의존성 중 하나만으로도, 소스에는 Kotlin밖에 없는 프로젝트에 네이티브 바이너리가 들어올 수 있습니다. "나는 C++를 안 썼다"는 증거가 아닙니다. 증거는 lib 폴더입니다.

Flutter, React Native, Unity, Kivy, 노코드 빌더

이 스택들은 설계상 네이티브 런타임, 엔진 바이너리, 플러그인 라이브러리를 함께 담기 때문에 거의 언제나 적용 대상입니다. Google은 네이티브 라이브러리를 쓰는 서드파티 앱 빌더를, 작성자가 C나 C++를 전혀 쓰지 않았어도 앱이 영향을 받는 경로로 명시적으로 언급합니다. 달라지는 것은 네이티브 코드가 있느냐가 아니라 문제가 되는 조각을 어느 패키지가 넣었느냐입니다. 그래서 파일 이름의 출처를 밝히는 일이 어떤 업그레이드보다 먼저 옵니다.

확인하는 방법, 정확히

출시용 APK를 열고 lib를 펼친 뒤 그 안의 ABI 폴더를 보십시오. 보통 arm64-v8a와 x86_64입니다. 공유 오브젝트 파일이 하나라도 있으면 앱이 네이티브 코드를 쓰고 있다는 뜻입니다. .so 파일도 lib 폴더도 없다면 이 APK는 네이티브 코드를 전혀 쓰지 않습니다. 분석기의 Alignment 열은 정렬에 문제가 있는 파일에 경고를 띄우는데, "뭔가 잘못됐다"에서 파일 이름까지 가는 가장 빠른 길입니다.

4 KB 바이너리가 16 KB 기기에서 실패하는 이유

구조는 이게 전부이고, 계속 마주치게 될 그 숫자도 이것으로 설명됩니다. 정렬은 2의 거듭제곱으로 표시합니다. 2**12는 4096바이트, 2**14는 16384바이트입니다. Google의 규칙은 네이티브 라이브러리의 모든 LOAD 세그먼트가 2**14 이상에 정렬되어야 한다는 것입니다. 2**14로 빌드된 라이브러리는 4 KB 기기와 16 KB 기기 모두에서 동작합니다. 16384가 4096의 깔끔한 배수이기 때문입니다. 반대로 2**12로 빌드된 라이브러리는 작은 페이지 크기에서만 동작합니다. 이 비대칭 때문에 해결책은 언제나 "정렬을 올린다"이지 "기기를 판별한다"가 아닙니다.

라이브러리 바깥에는 완전히 별개인 두 번째 제약이 하나 더 있습니다. APK 안에 압축하지 않고 저장된 네이티브 라이브러리는 ZIP 아카이브 안에서도 16 KB 경계에 놓여야 합니다. 이것은 패키징 속성이고, zipalign으로 확인하며 빌드 플러그인이 설정합니다. 안에 든 라이브러리가 전부 완벽하게 정렬되어 있어도 이쪽이 틀어질 수 있습니다. 이 두 개념을 분리해서 기억하는 것이 이 섹션에서 가져가실 수 있는 가장 쓸모 있는 한 가지입니다.

프레임워크별 가장 짧은 해결법

기준선을 한 표에 모으면

확신 수준 라벨은 이 페이지 어디에서나 같은 뜻입니다. 확인됨은 현행 1차 출처가 직접 그렇게 밝힌 경우입니다. 부분 확인은 믿을 만한 출처가 핵심 주장은 뒷받침하지만 세부 구현까지는 아닌 경우입니다. 보고됨은 근거가 공식 릴리스 노트가 아니라 유지보수자의 이슈 트래커나 개발자 보고인 경우입니다.

오류를 일으키는 라이브러리를 정확히 찾기

APK Analyzer에서 시작하십시오

Build > Analyze APK...를 열고 출시용 APK를 불러온 뒤 lib를 펼치십시오. 안에는 ABI마다 폴더가 하나씩 있고, 보통 arm64-v8a와 x86_64입니다. Alignment 열이 정렬에 문제가 있는 파일에 경고를 표시합니다. Android Studio 자체의 경고와 Lint도 요건을 못 맞춘 네이티브 라이브러리를 짚어 주므로, 같은 사실이 여러 곳에서 보일 수 있습니다.

버전 번호를 하나라도 건드리기 전에 표시된 파일 이름을 전부 적어 두십시오. 두 ABI 폴더를 따로 확인하십시오. arm64-v8a는 통과하는데 x86_64가 실패하거나 그 반대인 경우는 아주 흔합니다. 서로 다른 바이너리이고 서로 다른 파이프라인에서 빌드되었을 수 있기 때문입니다.

명령줄 출력 판독하기

터미널이 편하시다면, Google이 제공하는 check_elf_alignment.sh가 APK에 대해 ALIGNED 또는 UNALIGNED를 보고하고, llvm-objdump로 라이브러리 하나를 직접 들여다볼 수도 있습니다. 둘 다 Android SDK Build-Tools 35.0.0 이상이 필요합니다. 무엇이 출력되든 아래에 붙여 넣으시면 다시 읽어 드립니다.

어느 의존성이 담고 있는지 알아내기

Play Console도 APK Analyzer도 파일 이름만 주고 소유자는 알려 주지 않습니다. 아래에 입력하시면 그 바이너리에 대해 알려진 내용을 근거의 질과 함께 알려 드리고, 파일 이름이 이미 들어간 검색 명령어까지 드립니다.

로컬 APK가 아니라 앱 번들을 확인하십시오

이 문제의 가장 답답한 형태가 여기서 나옵니다. 개발자는 전부 업그레이드하고, 로컬 APK를 들여다보고, 깨끗한 출력을 확인하고, 업로드하는데 경고는 그대로 남아 있습니다. 확인한 것들이 틀린 게 아닙니다. Play가 평가하는 대상을 한 번도 확인하지 않았을 뿐입니다.

그러니 업로드하려는 번들에 대해 매번 이것을 실행하십시오.

bundletool dump config --bundle=app-release.aab | grep alignment

원하는 결과는 PAGE_ALIGNMENT_16K입니다. PAGE_ALIGNMENT_4K는 번들이 bundletool에 네이티브 라이브러리를 4 KB 경계로 패키징하라고 말하고 있다는 뜻이므로, Play가 그 번들로 빌드하는 APK는 전부 틀리게 됩니다. Google은 Android Gradle Plugin 8.3부터 8.5까지가 바로 이 어긋남을 만들 수 있다고 특별히 경고합니다. 로컬 빌드는 정렬된 것처럼 보이는데, Play가 번들로 빌드한 앱은 16 KB 기기에서 제대로 설치되지 않습니다. 권장되는 해결책은 Android Gradle Plugin 8.5.1 이상으로 올리는 것입니다.

내 파일 이름이 들어간 명령어 전부

파일 이름을 한 번만 입력하십시오. 아래 명령어가 전부 그 이름으로 다시 쓰이고, 각 탭마다 통과로 인정되는 정확한 출력을 보여 드립니다. 결과가 좋은 것인지 짐작할 일이 없습니다.

AGP와 NDK, 그리고 패키징 함정

위험한 중간 지대는 Android Gradle Plugin 8.3에서 8.5까지입니다. 이 범위에서는 로컬 빌드가 완전히 멀쩡해 보이는데도 bundletool이 Play용으로 번들에서 만들어 내는 APK를 ZIP 정렬하지 않을 수 있고, 결과에 대한 Google의 표현은 단호합니다. 그 번들로 빌드된 앱은 제대로 설치되지 않습니다. 8.5.0을 쓰고 계시고 로컬 APK가 떠올릴 수 있는 모든 검사를 통과한다면, 가장 먼저 배제해야 할 것이 이것입니다.

빌드 설정 참고표

패키징으로는 고칠 수 없는 부분

직접 쓰신 C나 C++가 페이지 크기를 가정하고 있다면 어떤 빌드 옵션도 구해 주지 못합니다. 고정된 4096 값과 PAGE_SIZE 상수에 기대는 부분을 없애고, 실행 시점에 getpagesize() 또는 sysconf(_SC_PAGESIZE)로 실제 값을 조회하고, 모든 mmap() 호출과 손으로 페이지 정렬하고 있는 인자를 전부 다시 보십시오. 이것은 앱이 16 KB 기기에 깨끗하게 설치되고 번들 검사도 통과한 다음, 메모리 매핑을 처음 건드리는 순간 죽는 유형의 실패입니다.

실제 16 KB 환경에서 테스트하기

현실적인 길이 셋, 전문적인 길이 둘 있습니다. 오늘 당장 닿을 수 있는 쪽을 고르십시오. 페이지 크기 실패를 잡아낸다는 목적에서는 이들 사이에 품질 차이가 없습니다.

adb shell getconf PAGE_SIZE

실제로 돌려 봐야 할 것

환경이 확인되고 나면, 쓸모 있는 테스트는 "실행이 되는가"가 아닙니다. 네이티브 실패는 네이티브 코드를 건드리는 기능에 몰리므로 그쪽을 의도적으로 돌리십시오. 콜드 실행, 앱 안에서의 화면 이동, 카메라, 데이터베이스 읽기와 쓰기, 미디어 재생과 녹화, 인증, 백그라운드 작업, 머신러닝이나 증강현실 기능, 모든 네이티브 플러그인이 닿는 화면, 그리고 직접 쓰신 코드 중 메모리 매핑을 쓰는 부분입니다. 방금 올린 라이브러리가 떠받치는 기능이 있다면, 바로 그 기능이 테스트입니다.

고쳐서 올렸는데 경고가 살아남는 이유

이 중 두 경우는 자신 있는 답 대신 단서를 다는 편이 맞습니다. Google Play가 업로드된 번들을 다시 평가하는 데 얼마나 걸리는지 못 박은 1차 출처는 없습니다. 그러니 업로드 직후에 경고가 계속 남아 있다면, 처리 시간에 대해 어디서 읽은 특정 숫자를 믿는 대신, 새 버전 코드가 최신 버전 및 app bundle 화면에 나타나는지 확인하고 나중에 다시 보는 것이 정직한 대응입니다. 그리고 호환 모드가 끼어들어서 겨우 돌아가는 앱은 고쳐진 것이 아니라 눈감아 준 것입니다.

계속 이름이 오르내리는 서드파티 라이브러리

파일 이름이 낯익어 보일 때 출발점으로 쓰시고, 그다음에는 해당 프로젝트의 현재 릴리스와 열린 이슈로 확인하십시오. 근거가 릴리스 노트가 아니라 유지보수자의 이슈 트래커인 경우에는 카드에 그렇게 적어 두었습니다.

2026년 8월 31일 API 36 기한과의 관계

Google Play는 2026년 8월 31일부터 신규 앱과 앱 업데이트가 Android 16(API 레벨 36)을 타깃으로 하도록 요구하며, 2026년 11월 1일까지 연장을 신청할 수 있습니다. 이것은 매니페스트와 동작에 관한 변경입니다. 반면 16 KB 규칙은 바이너리 호환성에 관한 변경입니다. 월요일에 targetSdk를 올리고 화요일에 16 KB 경고를 본 개발자는 무언가를 망가뜨린 것이 아닙니다. 네이티브 라이브러리는 이미 4 KB 페이지 기준으로 빌드되어 있었고, 타깃 레벨이 올라가면서 어차피 적용될 검사의 범위 안으로 앱이 들어왔을 뿐입니다.

실무에서는 증거가 두 개인 하나의 이전 작업으로 다루십시오. 어차피 타깃 레벨은 올리게 됩니다. API 36 마감에 쫓기다가 뒤늦게 발견하는 대신, 네이티브 라이브러리 점검을 같은 출시 일정에 넣으십시오. 기기 형태별 레벨, 예외, 연장 절차 전체는 Google Play API 36 기한 글에서, 계정부터 프로덕션까지 이어지는 전체 순서는 2026년 게시 요구사항 글에서 확인하실 수 있습니다.

업로드 전 출시 관문

진행 상황은 이 브라우저에만 저장됩니다. 어디로도 전송되지 않으며, 브라우저 데이터를 지우시면 함께 사라집니다.

이 문제가 비공개 테스트와 부딪히는 지점

아픈 순서는 이렇게 흘러갑니다. 개인 개발자 계정으로 비공개 테스트를 시작하고, 14일 연속 테스트 참여 기간이 돌기 시작합니다. 그리고 그 중간 어디쯤에서 타깃 레벨을 올린 순간 16 KB 경고가 드러납니다. 이제 개발자는 테스터 그룹을 그대로 유지한 채 네이티브 의존성을 다시 빌드해야 합니다. 트랙에 새 빌드를 올리는 것 자체는 문제가 없고, Google도 테스트 중에 계속 업데이트하도록 권장합니다. 진행을 무너뜨리는 것은 테스터 쪽이 조용해지는 일입니다.

바로 그 부분을 PrimeTestLab이 붙잡아 드립니다. Android 7부터 17까지 걸친 실기기의 실제 테스터 12명을 배정하고, 14일 내내 테스트 참여 상태를 유지합니다. 그래서 다시 빌드하는 동안 무너지는 테스트가 아니라 안정된 테스트를 상대하게 됩니다. 테스트는 4~6시간 안에 시작하며, 지금까지 120+개국에서 앱 7,400+개를 이 방식으로 진행해 성공률 99.9%를 기록했습니다.

직접 테스터를 모으는 경우와 맡기는 경우

경계를 분명히 해 두겠습니다. 저희는 네이티브 라이브러리를 대신 다시 빌드하지 않고, 이 글도 그런 서비스를 팔기 위한 글이 아닙니다. 16 KB 작업은 개발자의 몫이고, 이 섹션 위의 모든 내용은 그 작업을 최대한 짧게 끝내시라고 쓴 것입니다. 저희가 덜어 드리는 것은 그 옆에서 동시에 돌아가는 테스터 요구사항입니다. 그래야 두 문제가 같은 2주를 두고 다투지 않습니다.

자주 묻는 질문

핵심 요약