Android CPU 아키텍처(ABI) 이해: arm64-v8a, armeabi-v7a 및 x86이 중요한 이유
분할된 APK 파일 세트를 병합한 후 휴대전화에서 "앱이 설치되지 않음" 메시지가 표시되는 것을 본 적이 있거나 더 나쁜 경우 아이콘을 탭한 순간에 앱이 제대로 설치되어 충돌하는 것을 본 적이 있다면 실제 문제는 손상된 다운로드와 관련이 없을 가능성이 높습니다. 이는 거의 확실하게 아키텍처에 관한 것입니다. 휴대폰이 실행되는 CPU와 앱의 기본 코드가 컴파일된 CPU 간의 불일치입니다. 대부분의 Android 사용자는 조용히 무언가를 깨뜨리고 빠르게 관련성이 높아지기 전까지는 이에 대해 생각할 필요가 없습니다. APK에 대한 CPU 아키텍처의 의미, Play 스토어의 단일 앱이 비밀리에 여러 다른 빌드로 제공되는 이유, 설치하기 전에 호환성을 확인하는 방법은 다음과 같습니다.
ABI란?
ABI는 애플리케이션 바이너리 인터페이스를 의미합니다. 실제로는 칩이 이해하는 명령어 세트, 즉 프로세서가 직접 실행할 수 있는 원시 기계어 코드 형식입니다. Java 또는 Kotlin으로 작성된 대부분의 Android 앱은 Android 런타임(ART) 내에서 실행되는 바이트코드로 컴파일되며 ART는 앱이 어느 칩에 위치하는지 특별히 신경 쓰지 않습니다. 이 계층은 설계상 아키텍처에 구애받지 않습니다. 이는 Android 앱이 일반적으로 광범위한 하드웨어에서 "작동"하는 이유 중 큰 부분을 차지합니다.
네이티브 코드는 다른 이야기입니다. 많은 앱, 특히 게임, 카메라 앱, 기계 학습 도구, 그리고 많은 오디오나 비디오 처리를 수행하는 모든 앱은 Android NDK를 통해 C 또는 C++로 작성된 기본 라이브러리를 제공합니다. 이러한 라이브러리는 하나의 특정 명령어 세트에 대한 기계어 코드로 미리 컴파일되며, 하나의 명령어 세트용으로 제작된 칩은 일반적으로 다른 명령어 세트용으로 작성된 기계어 코드를 실행할 수 없습니다. 이것이 ABI가 이해할만한 가치가 있는 존재로 존재하는 이유입니다. 앱에 기본 .so 라이브러리가 하나라도 포함되는 순간 호환성은 라이브러리가 구축된 아키텍처와 연결됩니다.
여러분이 접하게 될 아키텍처
이 분야에는 더 다양한 종류가 있었지만(일반 armeabi 또는 MIPS를 기억하시나요?) 2026년에는 이 분야가 알 만한 가치가 있는 4개의 ABI로 범위가 좁아졌습니다.
| ABI | 비트 폭 | 일반적인 장치 | 메모 |
|---|---|---|---|
| arm64-v8a | 64비트 ARM | 대략 2019년 이후 판매된 거의 모든 휴대폰 | 새 앱의 기본 대상입니다. Google은 몇 년 동안 새로운 Play 스토어 제출에 대해 64비트 지원을 요구했습니다. |
| armeabi-v7a | 32비트 ARM | 구형 또는 저가형 기기, 일부 저가형 전화기는 여전히 신흥 시장에서 판매됩니다. | 대부분의 활성 장치에는 더 이상 필요하지 않지만 이전 버전과의 호환성을 위해 많은 앱에서 여전히 제공됩니다. |
| x86 | 32비트 인텔 | 오래된 Intel 기반 태블릿, 레거시 에뮬레이터 | 대부분 구식입니다. 오늘날 실제 32비트 x86 휴대폰을 접하는 경우는 거의 없습니다. |
| x86_64 | 64비트 인텔 | 일부 Chromebook, 데스크톱 Android 에뮬레이터, 일부 x86 태블릿 | x86 기반 Android Studio AVD 또는 특정 BlueStacks 빌드와 같은 에뮬레이터에서 앱을 테스트하는 경우 중요합니다. |
지난 5~6년 동안 구입한 휴대폰을 보유하고 있다면 거의 확실히 arm64-v8a일 것입니다. 기억할 가치가 있는 예외는 기본 노트북이나 데스크톱 CPU와 일치하기 때문에 x86_64에서 자주 실행되는 에뮬레이터와 Chromebook입니다.
앱이 여러 빌드를 모두 배송하는 데 귀찮은 이유
한 가지 분명한 질문은 왜 개발자가 모든 아키텍처의 기본 라이브러리를 단일 APK에 집어넣고 끝내지 않는가입니다. 일부 앱은 바로 이러한 작업을 수행하며 이를 범용 또는 "뚱뚱한" APK라고 합니다. 단점은 크기입니다. arm64-v8a, armeabi-v7a, x86 및 x86_64용 기본 라이브러리가 모두 함께 번들로 제공되는 게임은 장치에 필요한 하나의 아키텍처만 포함하는 빌드에 비해 크기가 쉽게 두 배 또는 세 배 증가할 수 있습니다. 이를 수백만 건의 설치에 곱하면 해당 장치에서 절대 실행되지 않는 코드에 대해 실제로 상당한 양의 대역폭과 저장 공간이 낭비되는 것을 보게 됩니다.
이러한 낭비를 피하기 위해 Google Play와 Android 앱 번들(AAB) 형식은 앱을 작은 기본 APK와 일련의 구성 APK로 분할합니다. 그 중 하나는 아키텍처 전용입니다. 휴대폰에서 앱을 요청하면 Play 스토어는 일치하는 화면 밀도 및 언어 분할과 함께 칩과 일치하는 아키텍처 분할만 포함된 기본 APK를 제공합니다. 단일 앱처럼 작동하지만 뒤에서는 여러 목적에 맞게 제작된 부분으로 구성된 설치가 완료됩니다.
분할 APK 및 앱 번들(AAB)이 이를 사용하는 방법
.apks 또는 .xapk 패키지를 열었고 split_config.arm64_v8a.apk, split_config.armeabi_v7a.apk, split_config.xxhdpi.apk 및 split_config.en.apk와 같은 파일 이름이 base.apk 옆에 있는 것을 본 적이 있다면 이것이 바로 이 시스템이 작동 중인 것입니다. Play 스토어에서 자동으로 전달되는 대신 파일 세트로 내보낸 것입니다. 밀도 및 언어 분할은 전화기가 필요하지 않은 리소스를 단순히 무시하므로 일반적으로 무차별적으로 설치하는 것이 안전합니다. 아키텍처 분할은 다릅니다. 잘못된 것을 설치하거나 일치하는 것을 설치하지 못하면 실제 문제에 직면하게 됩니다.
분할 패키지를 설치 가능한 단일 APK로 다시 병합하기 위해 변환기를 사용하는 경우 병합 프로세스에서는 어떤 아키텍처 분할을 접을지 선택해야 합니다. 좋은 변환기는 조용히 하나만 유지하고 기기와 일치하기를 바라는 대신 실제로 유용하거나 사용자가 선택할 수 있는 모든 아키텍처 분할을 유지합니다.
아키텍처가 일치하지 않으면 어떻게 되나요?
일반 사용자에게는 모양과 느낌이 다르기 때문에 구분할 가치가 있는 두 가지 뚜렷한 실패 모드가 있습니다.
첫 번째는 완전한 설치 실패입니다. 앱이 의미 있는 폴백 없이 거의 전적으로 네이티브 코드를 중심으로 구축된 경우 Android의 패키지 관리자는 앱 설치를 전혀 거부하며 일반적으로 INSTALL_FAILED_NO_MATCHING_ABIS와 같은 오류가 표시됩니다. 앱을 열 수도 없습니다. 설치 기사가 문 앞에서 당신을 멈춰 세웁니다.
두 번째로 더 실망스러운 결과는 소리 없는 부분적인 성공입니다. 앱에 자체적으로는 잘 로드되는 Java 또는 Kotlin 진입점이 있지만 아키텍처에 존재하지 않는 네이티브 라이브러리를 호출하려고 시도하는 경우 설치가 정상적으로 완료됩니다. 아이콘을 탭하기 전까지는 모든 것이 괜찮아 보이는데, 이 시점에서 앱이 거의 즉시 충돌하며 종종 로그에 UnsatisfiedLinkError가 묻혀 있습니다. 이것은 전형적인 "변환하고 설치한 다음 즉시 닫힙니다"라는 이야기이며 거의 항상 손상된 파일보다는 아키텍처 문제입니다.
자신의 휴대폰 아키텍처를 확인하는 방법
대다수의 사람들에게 이는 간단합니다. 휴대폰이 2019년 이후 버전이라면 arm64-v8a를 가정하고 계속 진행하세요. 확실하게 하고 싶거나 오래되었거나 특이한 장치를 다루고 있는 경우 몇 가지 실용적인 옵션이 있습니다.
- 휴대폰의 정확한 칩셋 모델(상자, 설명서 또는 GSMArena와 같은 사이트에서 확인 가능)을 찾아 해당 칩셋이 32비트 또는 64비트 ARM인지 검색하세요.
- CPU 아키텍처를 직접 보고하는 경량 시스템 정보 앱을 설치하세요. 이 목적을 위해 특별히 제공되는 무료 앱이 몇 가지 있습니다.
- 휴대폰이 원래 OS 버전으로 Android 9 이상과 함께 배송되었는지 확인하세요. 그 시대의 Google의 64비트 요구 사항으로 인해 arm64-v8a는 자격을 갖춘 모든 것에 대해 기본적으로 보장됩니다.
APK가 지원하는 아키텍처를 확인하는 방법
Play 스토어 외부에서 파일을 설치하기 전에 추측하기보다는 파일 내부에 무엇이 있는지 확인하는 것이 좋습니다. APK의 기본 라이브러리는 lib/arm64-v8a/ 또는 lib/armeabi-v7a/와 같이 lib/ 디렉터리 내 아키텍처 이름을 딴 폴더에 있습니다. APK의 내부 구조를 검사할 수 있는 모든 도구는 이러한 폴더 중 어떤 폴더가 존재하는지 정확하게 알려줄 수 있으며, 이는 파일이 어떤 장치에서 실행될지 정확하게 알려줍니다.
설치하기 전에 확인하세요.
APK 정보 도구는 APK의 내부 lib/ 폴더를 읽고 빌드된 모든 아키텍처를 나열하므로 사이드로드하기 전에 호환성을 확인할 수 있습니다. XAPK-APK 변환기를 사용하여 분할 패키지를 변환하면 변환할 때마다 이를 자동으로 표시하여 병합된 파일에 있는 아키텍처를 나열하고 빌드에 일반 장치에 필요한 슬라이스가 누락된 것처럼 보일 때 플래그를 지정합니다.
Universal APK와 Single-ABI APK: 어느 것을 사용해야 합니까?
| 항목 | 범용/지방 APK | 단일 ABI APK |
|---|---|---|
| 파일 크기 | 더 크며 때로는 2-4배 | 소형, 장치에 필요한 것만 포함 |
| 호환성 | 거의 모든 장치에서 작동 | 일치하는 아키텍처에서만 작동합니다. |
| 다음에 가장 적합 | 수신자가 불확실한 경우 어디에서나 작동하는 하나의 파일 공유 | 자신의 장치(해당 아키텍처를 이미 알고 있는 경우) |
| 위험 | ABI 불일치 위험이 매우 낮음 | 잘못된 것을 선택하면 실패하거나 충돌합니다 |
사람들이 분할 패키지로 저지르는 일반적인 실수
- 모든 분할이 선택 사항이라고 가정합니다. 밀도와 언어 분할은 일반적으로 이루어지지만 아키텍처 분할은 그렇지 않습니다. 병합 중에는 절대 건너뛰지 마세요.
- 미러 사이트에서 분할된 하나의 아키텍처만 가져옵니다. 타사 다운로드가 armeabi-v7a 슬라이스만 제공하는 경우 앱 자체가 합법적이더라도 arm64-v8a가 필요한 장치에서는 단순히 실패할 수 있습니다.
- 태블릿과 Chromebook이 항상 ARM이 아니라는 사실을 잊어버리세요. Android 앱을 실행하는 많은 Chromebook과 일부 구형 태블릿은 ARM이 아닌 x86 또는 x86_64입니다.
- x86 에뮬레이터 내에서 ARM 전용 APK를 테스트합니다. 일부 오래된 에뮬레이터 빌드는 x86에서 실행되며, ARM 네이티브 라이브러리만 제공하는 APK는 APK 패키징 방식에 관계없이 해당 빌드 내에서 실행되지 않습니다.
- "유니버설"과 "단일 ABI"를 혼동합니다. 범용 APK는 모든 것을 포함하기 때문에 의도적으로 더 큽니다. 단일 ABI APK는 크기가 작고 의도적으로 하나의 칩 제품군으로 제한됩니다.
주요 시사점
- ABI는 칩이 이해하는 명령어 세트입니다. 네이티브(C/C++) 코드를 포함하는 앱에만 중요합니다.
- arm64-v8a는 거의 모든 최신 전화기를 지원합니다. armeabi-v7a는 구형 장치용입니다. x86/x86_64는 대부분 에뮬레이터와 Chromebook에 표시됩니다.
- 앱은 일반적으로 모든 기기에 불필요한 네이티브 코드를 제공하지 않도록 아키텍처별로 분할됩니다.
- 일치하지 않는 아키텍처는 설치를 완전히 차단하거나 성공적으로 설치한 것처럼 보이는 즉시 충돌을 일으킵니다.
- 어떤 것을 설치하기 전에 장치의 아키텍처와 APK가 지원하는 아키텍처를 모두 확인할 수 있으므로 추측을 완전히 피할 수 있습니다.
자주 묻는 질문 (FAQ)
일반 Play 스토어 앱을 설치하려면 휴대폰의 아키텍처를 알아야 합니까?
아니요. Play 스토어는 자동으로 기기를 감지하고 일치하는 아키텍처 분할만 제공하므로 이는 Play 스토어 외부에서 APK를 사이드로드하는 경우에만 관련됩니다.
하나의 APK가 여러 아키텍처를 동시에 지원할 수 있나요?
예. 범용 또는 팻 APK는 지원되는 모든 아키텍처에 대한 기본 라이브러리를 하나의 파일로 묶습니다. 더 크지만 칩에 관계없이 모든 호환 장치에 설치됩니다.
변환된 APK가 설치되었지만 즉시 충돌이 발생하는 이유는 무엇입니까?
이는 일반적으로 앱에 제대로 설치되는 소량의 Java 코드가 있지만 기기의 아키텍처에 포함되지 않은 네이티브 라이브러리를 로드하려고 시도하여 런타임에 UnsatisfiedLinkError가 발생하는 경우에 발생합니다.
arm64-v8a는 armeabi-v7a 앱과 역호환되나요?
일반적으로 그렇습니다. 대부분의 arm64-v8a 칩은 32비트 ARM 명령어도 실행할 수 있으므로 armeabi-v7a 전용 APK는 일반적으로 최신 arm64 휴대폰에서 계속 실행되지만 그 반대의 경우는 실행되지 않습니다.
x86 Android 기기는 2026년에도 여전히 존재하나요?
오늘날 휴대폰에서는 드물지만 일부 구형 Intel 기반 태블릿, Android 앱을 실행하는 소수의 Chromebook 및 대부분의 데스크톱 Android 에뮬레이터에서는 x86 또는 x86_64를 여전히 찾을 수 있습니다.
이건 하나도 외울 필요가 없습니다. 짧은 버전: 최신 휴대폰은 거의 항상 arm64-v8a이며, 앱은 공간을 절약하기 위해 아키텍처별로 분할되며, 무언가가 설치를 거부하거나 연 직후 충돌하는 경우 아키텍처 불일치는 파일 자체가 손상되었다고 가정하기 전에 배제할 가치가 있는 첫 번째 사항 중 하나입니다.