최근 산업용 키오스크(Kiosk) 디바이스 개발 프로젝트를 리딩하면서 흥미로운 이슈에 직면했습니다. 하드웨어 벤더사(BSP)로부터 전달받은 보드 지원 패키지를 기반으로 소스 코드를 빌드하고, 성공적으로 부팅까지 마쳤지만 클라이언트는 당황한 기색이 역력했습니다. "화면은 나오는데, Play 스토어는 어디 갔나요? 유튜브 앱은요?"라는 질문이 돌아왔기 때문입니다. 개발자들에게는 너무나 당연한 이야기지만, 비즈니스 관계자들에게는 충격적인 사실일 수 있습니다. 우리가 흔히 사용하는 스마트폰의 android 경험과, 개발자가 마주하는 로우 레벨의 소스 코드는 전혀 다른 세상이기 때문입니다.
Android vs AOSP: 근본적인 아키텍처의 괴리
이 문제를 해결하기 위해서는 AOSP(Android Open Source Project)의 본질을 이해해야 합니다. 많은 사람들이 '안드로이드'를 구글이 제공하는 하나의 완제품 운영체제로 인식하지만, 엔지니어링 관점에서 android는 리눅스 커널 위에 올라가는 거대한 소프트웨어 스택일 뿐입니다.
실제 AOSP 소스 트리(`repo init`으로 내려받는 수십 기가바이트의 코드)에는 구글의 상용 서비스가 단 한 줄도 포함되어 있지 않습니다. 여기에는 리눅스 커널, HAL(Hardware Abstraction Layer), 네이티브 라이브러리, 그리고 안드로이드 런타임(ART)과 같은 뼈대만 존재합니다. 우리가 매일 사용하는 Gmail, Maps, Play Store는 'Google Mobile Services(GMS)'라는 별도의 독점 라이선스 패키지입니다.
이 차이를 무시하고 상용 앱을 AOSP 기반 디바이스에 올리려 시도하면, 수많은 `ClassNotFoundException`이나 `GooglePlayServicesNotAvailableException` 로그를 뿜어내며 앱이 강제 종료되는 현상을 목격하게 됩니다. 이는 앱들이 OS 레벨에서 제공한다고 가정하는 GMS 프레임워크가 누락되었기 때문입니다.
초기 접근의 실패: 단순 APK 사이드로딩
처음 이 문제를 겪는 주니어 개발자들이 흔히 하는 실수가 있습니다. 바로 GMS 관련 APK 파일들(GmsCore, PlayStore 등)을 인터넷에서 구해 `adb install`로 설치하려는 시도입니다. 저 역시 과거 임베디드 보드 작업 시 이 방법을 시도했으나 참담하게 실패했습니다.
이유는 간단합니다. GMS 앱들은 단순한 유저 애플리케이션이 아니기 때문입니다. 이들은 시스템 권한(`system/priv-app`)을 요구하며, 특정 서명 키(Signing Key)가 OS 빌드 키와 일치하거나, 화이트리스트에 등록되어 있어야 합니다. 단순 설치로는 권한 부여 실패(Permission Denial)로 인해 백그라운드 서비스가 계속해서 크래시(Crash)를 일으키며 배터리만 광탈시키는 결과를 초래합니다.
AOSP 커스텀 빌드 및 GMS 통합 전략
제대로 된 안드로이드 디바이스를 구축하기 위해서는 빌드 시스템 레벨에서의 접근이 필요합니다. 아래는 AOSP 빌드 시 디바이스 설정을 정의하는 `device.mk` 파일의 예시입니다. 여기서 우리는 어떤 패키지를 포함할지 결정해야 합니다.
// device/manufacturer/codename/device.mk
// 1. AOSP 기본 패키지 상속
$(call inherit-product, $(SRC_TARGET_DIR)/product/aosp_base.mk)
// 2. 중요: 화면 해상도 및 DPI 설정 (이게 없으면 UI가 깨짐)
PRODUCT_AAPT_CONFIG := normal
PRODUCT_AAPT_PREF_CONFIG := xhdpi
// 3. 커스텀 패키지 추가 (여기에 GMS 패키지가 포함되어야 함)
// 주의: GMS는 구글 라이선스 계약(MADA) 체결 후 제공받은 파트너만 포함 가능
# $(call inherit-product-if-exists, vendor/google/products/gms.mk)
// 4. 대안: 필수적인 오픈소스 앱 오버라이드
PRODUCT_PACKAGES += \
Launcher3QuickStep \
WallpaperPicker \
Settings \
SystemUI
// 5. HAL 모듈 정의 (하드웨어 가속 등)
PRODUCT_PACKAGES += \
android.hardware.graphics.allocator@2.0-impl \
android.hardware.graphics.mapper@2.0-impl위 코드에서 주석 처리된 `vendor/google/products/gms.mk` 부분이 핵심입니다. 정식 인증을 받은 제조사만이 구글로부터 GMS 바이너리를 받아 저 라인의 주석을 해제하고 빌드할 수 있습니다. 만약 인증을 받지 못한다면? 여러분은 AOSP만으로 기능을 구현해야 하며, 이는 구글 지도 API나 FCM 푸시를 사용할 수 없음을 의미합니다.
특히 `PRODUCT_PACKAGES`를 선언할 때, 의존성 관리가 매우 중요합니다. 예를 들어, 최신 안드로이드 버전에서는 `SystemUI`가 매우 복잡하게 얽혀 있어, 특정 라이브러리가 누락되면 부팅 로고에서 무한 루프(Bootloop)에 빠지게 됩니다. 빌드 로그(`logcat`)에서 `ServiceManager: Waiting for service SurfaceFlinger` 같은 메시지가 뜬다면, 그래픽 HAL 드라이버 연동 실패를 의심해봐야 합니다.
숨겨진 복병: Android System WebView
또 하나의 치명적인 차이는 WebView입니다. 상용 안드로이드 폰은 구글 크롬 기반의 최신 WebView가 Play 스토어를 통해 자동으로 업데이트됩니다. 반면, AOSP 빌드에 포함된 WebView는 소스 코드 시점의 버전에 고정되어 있습니다. 보안 취약점이 발견되어도 OS 전체를 다시 빌드해서 펌웨어 업데이트(OTA)를 하지 않는 이상 패치할 방법이 없습니다. 따라서 하이브리드 앱을 개발하거나 웹뷰 의존도가 높은 서비스를 AOSP 기기에서 돌릴 때는 반드시 최신 Chromium 소스를 받아 별도로 빌드하여 통합하는 과정이 필요합니다.
| 구분 | AOSP (순정) | Google Android (GMS 탑재) |
|---|---|---|
| 핵심 커널 | Linux Kernel (LTS) | Linux Kernel + Vendor Patch |
| 앱 생태계 | F-Droid, 수동 설치 | Google Play Store |
| 푸시 알림 | 구현 불가 (또는 MQTT 자체구현) | Firebase Cloud Messaging (FCM) |
| 위치 정보 | GPS Raw Data (느림) | Google Location Services (Wi-Fi/Cell 보정) |
| 라이선스 | Apache 2.0 / GPL (무료) | MADA 계약 필요 (유료/인증 필수) |
위 표에서 볼 수 있듯이, AOSP는 '자유'롭지만 '불편'하고, 구글 안드로이드는 '제약'이 있지만 '강력'합니다. 산업용 기기에서는 보안이나 비용 문제로 GMS를 포기하고 AOSP를 선택하는 경우가 많습니다. 이 경우, 위치 정보 측위 속도가 현저히 느려지거나(AGPS 미지원), 앱 업데이트 메커니즘을 자체적으로 개발해야 하는 기술적 부채가 발생합니다.
공식 AOSP 빌드 가이드 확인하기GMS 인증과 CDD/CTS의 벽
만약 여러분이 "그래, 돈을 내고서라도 GMS를 탑재하겠다"라고 결정했다고 해도, 문제는 끝나지 않습니다. 구글은 안드로이드 생태계의 파편화를 막기 위해 CDD(Compatibility Definition Document)라는 엄격한 하드웨어/소프트웨어 요구사항을 제시합니다. 이 문서를 준수하지 않은 기기는 GMS 라이선스를 받을 수 없습니다.
예를 들어, CDD는 특정 해상도 비율이나, USB C타입 단자의 구현 방식, 심지어는 커널의 특정 플래그 설정까지 강제합니다. 제가 겪었던 사례 중 하나는, 저가형 센서를 사용했다가 정밀도 기준 미달로 CTS를 통과하지 못해 하드웨어 설계를 변경해야 했던 경우입니다. 즉, android 기기를 만든다는 것은 단순히 코드를 빌드하는 것이 아니라, 구글이 정해놓은 거대한 규격의 틀 안에 제품을 맞추는 과정입니다.
언제 AOSP를 선택해야 하는가?
그렇다면 GMS 없는 AOSP는 의미가 없을까요? 아닙니다. 다음과 같은 경우에는 AOSP가 훨씬 유리합니다.
- 철저한 보안이 필요한 국방/금융 단말기: 구글 서버로 데이터가 전송되는 것을 원천 차단해야 할 때.
- 특수 목적 키오스크: 사용자가 유튜브를 보거나 딴짓을 하면 안 되는 환경.
- 중국 시장 타겟 제품: 중국에서는 구글 서비스가 차단되므로, 어차피 AOSP 기반에 로컬 서비스(Baidu 등)를 올려야 합니다.
Conclusion
안드로이드는 개방형 OS라는 가면을 쓰고 있지만, 그 실체는 AOSP라는 뼈대 위에 구글의 독점적 서비스가 혈관처럼 얽혀 있는 구조입니다. android 기반의 하드웨어나 서비스를 개발할 때는, 초기 기획 단계에서부터 우리가 필요한 것이 순수한 오픈소스 OS인지, 아니면 구글의 풍부한 생태계인지를 명확히 정의해야 합니다. 이 결정이 늦어질수록, 프로젝트 후반부에 겪게 될 라이선스 비용과 기술적 수정 비용은 기하급수적으로 늘어날 것입니다. AOSP의 자유도와 GMS의 편의성 사이에서, 여러분의 프로젝트에 최적화된 균형점을 찾으시길 바랍니다.
Post a Comment