최근 자동차 산업이 SDV(Software Defined Vehicle)로 전환되면서 인포테인먼트 시스템(IVI)의 아키텍처가 핵심 경쟁력으로 부상했습니다. 많은 개발자와 사용자가 '안드로이드 오토(Android Auto)'와 '안드로이드 오토모티브 OS(Android Automotive OS, 이하 AAOS)'를 혼용하지만, 엔지니어링 관점에서 이 둘은 '원격 렌더링 클라이언트'와 '임베디드 네이티브 OS'라는 완전히 다른 기술적 뿌리를 가집니다. 본 글에서는 단순한 기능 비교를 넘어, 시스템 아키텍처, 하드웨어 추상화 계층(HAL)의 통합 방식, 그리고 OEM과 개발자가 고려해야 할 트레이드오프를 분석합니다.
1. 안드로이드 오토: 투사(Projection) 기반의 씬 클라이언트
2015년 출시된 안드로이드 오토는 기존 레거시 IVI 시스템의 한계를 극복하기 위해 고안된 프로젝션 프로토콜(Projection Protocol) 솔루션입니다. 기술적으로 이 시스템은 'VNC(Virtual Network Computing)'나 'Remote Desktop'과 유사한 구조를 가집니다.
아키텍처 및 데이터 흐름
안드로이드 오토 환경에서 차량의 헤드 유닛(Head Unit)은 단순한 입출력 장치(Sink) 역할만 수행합니다. 실제 컴퓨팅, 앱 실행, 네트워크 통신은 모두 연결된 모바일 디바이스(Source)에서 처리됩니다.
- Source (Mobile): 가상 디스플레이를 생성하고 앱 UI를 렌더링한 후, H.264 등의 코덱으로 비디오 스트림을 인코딩하여 전송합니다.
- Sink (Head Unit): 모바일로부터 수신한 비디오/오디오 스트림을 디코딩하여 화면에 표시하고, 터치 이벤트나 마이크 입력을 모바일로 역전송합니다.
제약 사항과 병목
이 구조는 OEM의 개발 비용을 낮추지만, 다음과 같은 기술적 한계를 가집니다.
- 지연 시간(Latency): 인코딩-전송-디코딩 과정을 거치므로 네이티브 실행 대비 입력 지연이 발생할 수 있습니다.
- 차량 데이터 접근 불가: 모바일 기기는 차량의 CAN(Controller Area Network) 버스에 직접 접근할 권한이 없습니다. 따라서 공조 장치(HVAC) 제어나 창문 개폐와 같은 로직을 수행할 수 없습니다.
2. 안드로이드 오토모티브 OS (AAOS): 네이티브 통합과 VHAL
AAOS는 안드로이드 오픈 소스 프로젝트(AOSP)를 기반으로 차량 환경에 맞게 확장된 풀스택 운영체제입니다. 모바일 기기 없이 차량 내 칩셋(AP)에서 직접 구동됩니다.
Vehicle HAL (VHAL)의 역할
AAOS의 핵심 차별점은 하드웨어 추상화 계층인 VHAL(Vehicle Hardware Abstraction Layer)입니다. 안드로이드 프레임워크는 VHAL을 통해 차량의 MCU 및 ECU와 통신합니다.
CarPropertyManager를 활용하면 제조사에 관계없이 표준화된 방식으로 차량 센서 데이터(속도, 기어, 연료량 등)를 읽을 수 있습니다.
다음은 VHAL이 차량의 속도 데이터를 처리하는 개념적인 아키텍처 코드 예시입니다.
// 1. VHAL Interface Definition (HAL definition in .hal or .aidl)
// 차량 제조사는 이 인터페이스를 구현하여 CAN 버스 데이터를 매핑해야 함
package android.hardware.automotive.vehicle;
@VintfStability
interface IVehicle {
// 차량 속성 값을 가져오는 메서드
GetValueResult get(in VehiclePropValue propValue);
// 차량 속성 변경을 구독하는 메서드
void subscribe(in IVehicleCallback callback, in VehiclePropConfigs[] options);
}
/*
* 2. Application Level (Java/Kotlin)
* 개발자는 하위 하드웨어(CAN/LIN)의 복잡성을 몰라도 표준 API로 접근 가능
*/
import android.car.hardware.CarPropertyValue;
import android.car.hardware.property.CarPropertyManager;
public void readVehicleSpeed(CarPropertyManager propertyManager) {
// PERF_VEHICLE_SPEED는 VHAL에 정의된 표준 Property ID
float speed = propertyManager.getFloatProperty(
VehiclePropertyIds.PERF_VEHICLE_SPEED,
0 // Area ID (Global)
);
// 데이터 처리 로직...
}
이러한 구조 덕분에 AAOS는 단순한 미디어 재생을 넘어, 공조 제어, 시트 포지셔닝, BMS(Battery Management System) 연동 길 안내 등 Deep Integration이 가능합니다.
3. GAS(Google Automotive Services) vs AOSP
엔지니어링 리드는 AAOS 도입 시 라이선스 모델을 구분해야 합니다.
- AOSP (오픈소스): 누구나 무료로 사용할 수 있는 기본 OS입니다. 하지만 구글 지도, 플레이 스토어, 음성 비서가 포함되지 않습니다. 제조사가 자체 앱 스토어나 내비게이션을 구축해야 합니다. (예: 초기 중국 수출용 모델)
- GAS (라이선스): 구글의 독점 서비스(GMS의 차량 버전)가 포함된 버전입니다. 플레이 스토어를 통해 서드파티 앱 생태계를 즉시 확보할 수 있으나, 엄격한 CDD(Compatibility Definition Document) 준수와 구글의 인증이 필요합니다. (예: 볼보, 폴스타, 르노 등)
4. 기술적 트레이드오프 분석
두 기술은 상호 배타적이지 않으며, 많은 AAOS 차량이 안드로이드 오토 프로젝션도 동시에 지원합니다. 하지만 시스템 설계 시점에서는 명확한 장단점 분석이 필요합니다.
| 비교 항목 | 안드로이드 오토 (Projection) | 안드로이드 오토모티브 (AAOS) |
|---|---|---|
| 컴퓨팅 위치 | 사용자 스마트폰 (BYOD) | 차량 내장 AP (Qualcomm, Nvidia 등) |
| 차량 데이터 접근 | 불가능 (오디오/비디오 포커스만 제어) | 가능 (VHAL을 통한 ECU/CAN 제어) |
| OS 업데이트 | 플레이 스토어 앱 업데이트로 가능 | OEM의 OTA(Over-The-Air) 파이프라인 의존 |
| 하드웨어 비용 | 저렴 (디스플레이 및 디코더만 필요) | 비쌈 (고성능 AP, 메모리, 스토리지 필수) |
| 사용자 경험(UX) | 개인화된 앱 환경 유지 | 차량과 일체화된 심리스(Seamless) 경험 |
5. 결론: SDV 시대를 위한 엔지니어링 전략
안드로이드 오토가 '연결성(Connectivity)'에 초점을 맞춘 과도기적 기술이라면, 안드로이드 오토모티브 OS는 차량을 스마트 디바이스로 재정의하는 플랫폼입니다. 차량 제조사 입장에서는 자체 소프트웨어 역량이 부족할 경우 AAOS와 GAS를 도입하여 빠르게 생태계를 구축하는 것이 효율적인 전략이 될 수 있습니다.
개발자 및 엔지니어링 리드는 다음 사항을 고려해야 합니다.
- 단순 미디어/메시징 앱이라면 안드로이드 오토와 AAOS 모두를 지원하는 통합 아키텍처를 설계하십시오.
- 차량 제어, 배터리 관리, 상세 내비게이션 등 차량 데이터와 밀접한 기능이 필요하다면 AAOS의 VHAL을 적극 활용해야 합니다.
- SDV 환경에서는 하드웨어 스펙이 고정된 상태에서 소프트웨어만 진화하므로, 리소스 최적화와 메모리 누수 관리가 스마트폰 앱 개발보다 훨씬 엄격하게 요구됩니다.
참고 자료 및 도구
구글은 개발자들이 실제 차량 없이도 AAOS 환경을 테스트할 수 있도록 에뮬레이터를 제공합니다.
AAOS 에뮬레이터 가이드 AOSP Automotive 문서
Post a Comment