안드로이드 아키텍처: JDK·NDK·AOSP를 하나의 빌드 파이프라인으로 묶기

커널 위에 얹힌 안드로이드는 앱 한 줄을 빌드하는 것도 HAL·ART·서명까지 이어지는 파이프라인을 통과해야 나온다. 리눅스 커널→HAL→네이티브 라이브러리→ART 런타임→프레임워크→앱 계층으로 이어지는 레이어드 구조가 그 골격이고, 권한·샌드박스·SELinux가 계층마다 보안 경계를 유지한다. 개발환경은 Android Studio·Gradle(AGP)·JDK·SDK/NDK·CMake/Clang·에뮬레이터로 구성되며, 소스에서 빌드·서명·배포(AAB/APK)·관측까지 전 주기를 자동화하는 게 목표다. 여기에 AOSP(Android Open Source Project)까지 걸리면 디바이스 포팅, 벤더 HAL, 시스템 앱, 보안 패치 적용의 표준 골격이 하나 더 필요해진다.

레이어가 나뉘는 이유

커널·드라이버와 HAL을 분리하면 하드웨어 추상화가 생기고, 벤더별 구현 차이가 프레임워크에 노출되지 않는 안정적 계약이 유지된다. 네이티브 라이브러리(Bionic, libc++, Media, OpenGL/Vulkan)와 ART 가상머신은 이 위에서 성능과 호환성을 균형화하는 실행 기반을 제공한다.

⤢✕

빌드 시스템이 실제로 하는 일

Android Studio와 AGP(Gradle 플러그인)는 멀티 모듈 빌드와 변형(variant)·프로덕트 플리버 구성을 다루고, D8/R8로 컴파일·최적화한 뒤 AAB/APK로 패키징한다. 로컬·인스트루먼트 테스트, 코드 서명(v1~v3), Play App Signing, CI/CD 통합이 여기에 더해져 품질과 재현성을 끌어올린다.

JDK와 NDK, 언제 나눠 쓰나

비즈니스 로직과 UI는 Kotlin/Java(JDK) 중심으로 구현하고, 성능이 민감하거나 네이티브 자원에 직접 접근해야 하는 부분만 C/C++(NDK)로 분리한다. 두 언어 경계는 JNI 브리지로 관리해야 하고, ABI·STL·스레딩 모델·예외 전파 같은 트레이드오프를 고려해 크로스 컴파일과 심볼 안정성을 챙겨야 한다.

구분	JDK(코틀린/자바)	NDK(C/C++)	AOSP(플랫폼)
성능	일반 로직·UI에 충분, JIT/AOT 혼합	고성능·저지연 유리, SIMD/NEON 활용	시스템 전역 최적화 가능
확장성	멀티 모듈·라이브러리 생태계 풍부	특정 ABI·플랫폼 종속성 관리 필요	디바이스 클래스 확장 용이
일관성	프레임워크 API 안정성 높음	ABI 호환·STL 버전 관리 리스크	VINTF·CTS로 호환성 보장
안정성	GC·메모리 안전성 상대적으로 우수	포인터·스레드 안전 이슈 관리 필요	커널/드라이버 품질 영향 큼
운영 편의	빌드/테스트/배포 도구 성숙	툴체인·심볼·크래시 분석 난이도 상승	빌드 시간·리소스 요구 높음

AOSP로 디바이스까지 확장하기

SoC BSP, BoardConfig, Device Tree, HAL 모듈, Vendor 파티션을 구성해 기기 Bring-up 절차를 표준화하고, Vendor Interface 안정성(VINTF)을 준수해야 한다. CTS/VTS/STS를 통과해 프레임워크 호환성을 보장하고, 보안 패치 백포트와 롤백 보호(AVB)를 적용한다.

보안·리소스 격리

앱 샌드박스(UID 분리), 권한 모델, SELinux Enforcing, Scoped Storage, Keystore 기반 암호학적 보호 체계로 공격면을 최소화한다. Verified Boot, 동적 코드 로딩 제약, 네이티브 라이브러리 무결성 검증이 런타임 보호를 강화한다.

표준 앱 개발환경을 구성하는 절차

Android Studio 최신 안정 버전, AGP 8.x/9.x, JDK 17, SDK/NDK r26+를 설치하는 것부터 시작한다(버전은 계속 바뀌므로 최신 정보 확인이 필요하다). 모듈 구조를 잡고 buildSrc·Version Catalog로 의존성을 표준화한 뒤, 단위·인스트루먼트 테스트와 Lint, R8 설정, Proguard rules 최소화로 품질 체계를 세운다. 이어서 AAB를 생성하고 Play App Signing과 내부→베타→프로덕션 트랙 릴리스 전략으로 배포한다. AGP와 JDK 버전이 어긋나면 빌드가 실패할 수 있어 호환 매트릭스를 확인해야 하고, minSdk/targetSdk 불일치는 런타임 권한·스토리지 오류로 이어질 수 있어 매니페스트와 권한을 함께 점검해야 한다. 이렇게 표준화된 AGP·CI 파이프라인을 갖추면 빌드 시간이 2040%, 회귀 결함이 1530% 줄어드는 것으로 보고된다.

성능 민감 모듈에 NDK를 붙이는 절차

신호처리, 영상·오디오 인코딩, 암호화, 물리 연산처럼 고성능·지연 민감 영역이 적용 기준이다. ABI는 기본 arm64-v8a를 쓰고 필요하면 armeabi-v7a를 병행한다.

android {
  defaultConfig {
    externalNativeBuild { cmake { cppFlags "-O2 -DNDEBUG" } }
    ndk { abiFilters "arm64-v8a", "armeabi-v7a" }
  }
  externalNativeBuild { cmake { path "CMakeLists.txt" } }
}

cmake_minimum_required(VERSION 3.22)
project(native_core)
add_library(native_core SHARED native_core.cpp)
find_library(log-lib log)
target_link_libraries(native_core ${log-lib})

#include <jni.h>
extern "C" JNIEXPORT jint JNICALL
Java_com_example_app_NativeCore_add(JNIEnv*, jobject, jint a, jint b) { return a + b; }

크래시 덤프는 ndk-stack, addr2line으로 분석하고 심볼 스트리핑 정책을 관리해야 하며, STL 중복 링킹·예외 경계·스레드 소유권 문제를 사전에 점검해야 한다. 이 방식으로 도입한 모듈은 CPU 사용량이 2050%, 지연이 1035% 개선되는 것으로 보고되지만, 수치는 워크로드·디바이스별로 상이할 수 있어 사전 벤치마크가 필요하다.

AOSP 기반 디바이스 포팅 절차

SoC BSP, 커널 소스, 벤더 바이너리, 디바이스 스펙을 입력으로 repo init/sync와 lunch 타겟 구성, BoardConfig.mk 세팅으로 소스를 준비한다. Camera, Audio, Sensors 등의 HAL을 HIDL/AIDL 계약에 맞춰 구현하고 VINTF 매니페스트를 갱신한 뒤, m/m dist로 빌드하고 fastboot/adb sideload로 플래시하며 AVB·dm-verity를 설정한다. CTS/VTS/CTS-V를 통과시키고 전력·열·미디어 호환성을 튜닝하면 부팅 가능한 시스템 이미지와 인증 통과 리포트가 나온다. 커널·드라이버 버전 불일치, DTBO/Overlay 충돌, SELinux Denial이 발생하면 정책을 조정해야 하고, 보안 패치 레벨 동기화와 파티션 레이아웃(GSI/DSU) 호환성도 함께 검토해야 한다. CTS/VTS 준수로 호환성 이슈의 50% 이상을 사전 차단할 수 있고, 모듈화·재사용으로 유지보수 노력이 15~25% 줄어드는 것으로 보고된다.

레이어드 플랫폼 구조와 표준화된 빌드·보안 메커니즘을 기반으로 한 종단간 개발 체계라는 점이 안드로이드 아키텍처의 핵심이다. JDK 중심 개발에 NDK를 선택적으로 결합하고, 필요할 때만 AOSP로 플랫폼을 확장하는 단계적 접근이 버전 호환 매트릭스와 보안 정책을 지키면서 재현성과 안정성을 극대화하는 길이다.