AOSP는 안드로이드 (운영체제)의 공개 소스 기반이며, Google이 유지·발전시키는 Android 소스 트리와 그 개발·배포 질서를 함께 가리킨다.[1][2] 이 문서는 AOSP를 Google Play 같은 유통 계층이나 OEM 커스터마이징과 구분되는 기준점으로 설명한다.[1][2]

1. 개요

AOSP는 단순히 코드를 공개해 둔 저장소가 아니라, Android를 만들고 변형하고 검증하는 공통 기준이다. 공식 문서는 AOSP를 공개적으로 수정 가능한 Android source code로 설명하고, 누구나 코드를 내려받아 기기나 목적에 맞게 수정할 수 있다고 밝힌다.[1] 다만 AOSP는 Android를 온전히 설명하는 전부가 아니며, 앱이 서버 백엔드나 특정 Google 서비스에 의존하는 경우와 완전한 엔드유저 앱 세트를 보장하지는 않는다.[1][2]

AOSP를 Android 전체와 분리해서 보는 이유는, 같은 소스 기반이라도 제조사와 배포 방식에 따라 실제 제품이 크게 달라지기 때문이다. 그래서 AOSP는 안드로이드 (운영체제)의 공통 기반이지만, 사용자 경험은 Google Play, 제조사 앱, 정책, 업데이트 주기 같은 요소가 덧붙여져 완성된다.[1][2]

2. 소스 트리와 빌드

Android 소스는 Google이 호스팅하는 여러 Git 저장소 묶음으로 제공되며, repo 클라이언트를 통해 내려받는 것이 표준 흐름이다.[3] AOSP 개발자는 source build/envsetup.sh로 환경을 초기화한 뒤 lunch로 대상을 고르고, Soong이 Android.bp 파일을 읽어 빌드를 구성한다.[3][4][5]

이 구조는 AOSP가 단일 패키지가 아니라 협업 가능한 소스 트리라는 점을 보여 준다. 커널, 프레임워크, 시스템 구성요소, 기기별 오버레이와 모듈이 분리되어 있어, 기기 제조사와 벤더는 필요한 부분만 덮어쓰거나 추가할 수 있다.[4][6] AOSP를 이해할 때는 “소스 전체를 받아서 한 번에 굽는 운영체제”라기보다, 브랜치와 타깃을 고르며 조립하는 빌드 시스템으로 보는 편이 정확하다.[3][4]

3. 아키텍처와 경계

공식 아키텍처 설명은 AOSP를 Linux kernel, HAL, native libraries, Android framework, system services, ART의 층으로 설명한다.[2] 이 계층 구조 덕분에 앱 개발자는 안정적인 Android API를 상대로 개발하고, 하드웨어 벤더는 HAL과 커널 쪽에서 장치별 차이를 흡수할 수 있다.[2][6]

AOSP의 경계가 중요한 이유는, 공개 소스가 곧바로 완전한 제품 경험을 뜻하지 않기 때문이다. Application Sandbox와 SELinux, Verified Boot 같은 보안 계층은 기기 신뢰성을 높이지만, 앱 호환성, 인증, 배포 정책은 별개의 질서로 움직인다.[2][7][8] 그래서 AOSP는 “Android를 만들 수 있게 하는 공통 기반”이고, Google Play는 그 기반 위에서 앱을 전달하고 검증하는 상용 유통 계층으로 구분해서 읽는 편이 맞다.[1][2]

4. 호환성과 커스터마이징

AOSP의 가장 중요한 제약은 자유도보다 호환성 관리다. 공식 문서는 AOSP-compatible device와 Android-compatible device를 구분하고, 호환성 프로그램을 통해 장치 제작자가 무엇을 지켜야 하는지 설명한다.[2] 다시 말해 AOSP는 마음대로 변형할 수 있지만, Android 생태계에 그대로 참여하려면 호환성 문서와 테스트 기준을 맞춰야 한다.[2]

이 때문에 제조사 커스터마이징은 본질적으로 AOSP 위에서 이루어지는 변형 작업이다. 파티션 분리, 벤더 전용 바이너리, 시스템 모듈과 커널의 책임 분리가 이어지면서, 같은 Android 계열이라도 구현 차이가 남는다.[6] 이런 경계 덕분에 AAB 같은 앱 배포 형식이나 안드로이드 (운영체제)의 버전 변화가 있어도, 플랫폼과 기기 구현을 따로 추적할 수 있다.[6][7]

5. 보안과 신뢰 체인

AOSP는 보안도 소스 공개와 별개로 계층화해 다룬다. Application Sandbox는 앱을 고유 UID와 프로세스로 분리해 서로와 시스템을 보호하고, Secure an Android device 문서는 이를 앱 격리, 권한 모델, 플랫폼 보안 아키텍처의 일부로 설명한다.[7][8] 이 모델은 앱 실행과 시스템 권한을 직접 연결하지 않고, 각 앱이 기본적으로 다른 앱을 신뢰하지 않는다는 전제를 깔아 둔다.[7]

여기에 Verified Boot와 파일·파티션 무결성 검사가 더해져, 기기가 부팅될 때부터 신뢰 체인을 검증한다.[6][8] 결과적으로 AOSP의 보안은 단일 기능이 아니라, 앱 샌드박스, 시스템 제어, 저장소 분리, 부팅 검증이 겹쳐 작동하는 구조다.[7][8]

6. 왜 중요한가

AOSP는 Android의 역사와 현재를 함께 보여 주는 기준점이다. 공개 소스가 어디까지이며 어떤 부분이 기기 제조사나 서비스 계층에서 달라지는지 이해하면, Android 버전 업데이트, 기기 호환성, 보안 모델, 앱 배포의 차이를 같은 틀에서 설명할 수 있다.[1][2][4] 개발자는 AOSP를 통해 플랫폼의 내부를 읽고, 제조사와 서비스 제공자는 그 경계를 기준으로 자신들의 변형과 추가 기능을 설계한다.[2][6]

7. 관련 문서

8. 인용 및 각주

[1] AOSP overview, Android Open Source Project, Ssource.android.com(새 탭에서 열림)

[2] Architecture overview, Android Open Source Project, Ssource.android.com(새 탭에서 열림)

[3] Download the Android source, Android Open Source Project, Ssource.android.com(새 탭에서 열림)

[4] Build overview, Android Open Source Project, Ssource.android.com(새 탭에서 열림)

[5] Build Android, Android Open Source Project, Ssource.android.com(새 탭에서 열림)

[6] Partitions overview, Android Open Source Project, Ssource.android.com(새 탭에서 열림)

[7] Application Sandbox, Android Open Source Project, Ssource.android.com(새 탭에서 열림)

[8] Secure an Android device, Android Open Source Project, Ssource.android.com(새 탭에서 열림)