스마트폰에서 앱이 크래시(Crash) 나면 사용자는 불평하며 재부팅을 하지만, 시속 100km로 달리는 자동차에서 인포테인먼트 시스템이 먹통이 되면 그것은 생존의 문제가 된다. 최근 자동차 산업의 패러다임이 Android Automotive OS (AAOS) 중심으로 재편되면서, 단순한 편의성을 넘어선 '극강의 안정성'이 요구되고 있다. AOSP(Android Open Source Project)를 기반으로 자체 IVI를 구축하는 OEM과 Tier-1 엔지니어들에게 있어, Automotive 시스템 검증은 선택이 아닌 필수 생존 전략이다. 이 글에서는 수많은 프로젝트를 거치며 겪었던 시행착오를 바탕으로, 품질 보증의 양대 산맥인 CTS와 VTS를 활용한 실전 검증 방법론을 다룬다.
CTS: 호환성 확보를 위한 첫 번째 관문
많은 개발자들이 CTS(Compatibility Test Suite)를 단순히 '구글 인증을 받기 위한 숙제' 정도로 치부하곤 한다. 하지만 AAOS 환경에서 CTS는 상위 레이어 앱들이 하드웨어 파편화 없이 정상적으로 동작함을 보장하는 최소한의 안전장치다. 특히 Android 호환성 정의 문서(CDD)를 준수하지 않은 커스텀 구현은 향후 OTA 업데이트 시 치명적인 시스템 붕괴를 초래할 수 있다.
Automotive 환경의 CTS는 모바일과 달리 차량 특화 모듈에 집중해야 한다. 예를 들어, 기어 상태 변경이나 HVAC 제어와 같은 차량 속성(Vehicle Property)이 안드로이드 프레임워크 표준 API와 정확히 매핑되는지를 검증한다. 우리는 과거 프로젝트에서 독자적인 HAL 인터페이스를 고집하다가 CTS의 CtsCarTestCases 모듈에서만 300개 이상의 실패(Failure)를 경험했고, 결국 표준 아키텍처로 회귀하는 데 2주를 허비했다.
VTS: 커널과 HAL의 무결성 검증
CTS가 앱 생태계를 위한 것이라면, VTS(Vendor Test Suite)는 하드웨어와 OS 간의 결합을 검증하는 핵심 도구다. Automotive 개발의 진짜 난관은 대부분 여기서 발생한다. 차량용 센서, 오디오 DSP, 카메라 HAL이 리눅스 커널 및 안드로이드 프레임워크와 정확히 통신하는지를 확인해야 하기 때문이다.
특히 VHAL(Vehicle Hardware Abstraction Layer) 구현 검증은 필수적이다. 아래는 VTS 테스트 실패 시 흔히 분석하게 되는 VHAL 인터페이스 정의(AIDL)와 이를 검증하는 테스트 로직의 개념적인 예시이다. AOSP 소스 코드를 분석할 때 이 구조를 이해하는 것이 디버깅의 시작이다.
// VHAL 인터페이스 (IVehicle.aidl 예시)
// VTS는 이 인터페이스가 규격대로 동작하는지 강제로 호출하여 테스트한다.
package android.hardware.automotive.vehicle;
import android.hardware.automotive.vehicle.IVehicleCallback;
import android.hardware.automotive.vehicle.VehiclePropConfig;
import android.hardware.automotive.vehicle.VehiclePropValue;
interface IVehicle {
/**
* 차량 속성 값을 가져옵니다.
* VTS는 잘못된 propId를 주입하여 에러 처리가 올바른지 확인합니다.
*/
void get(in VehiclePropValue propValue, in IVehicleCallback callback);
/**
* 차량 속성 값을 설정합니다.
* 예를 들어, HVAC 온도를 설정했을 때 실제 하드웨어 신호가 트리거되는지 검증합니다.
*/
void set(in VehiclePropValue propValue, in IVehicleCallback callback);
// ... 기타 구독(subscribe) 메서드 등
}
// [엔지니어 노트]
// VTS 테스트 실패 시 logcat만 보지 말고 'vts-tradefed' 로그를 확인해야 한다.
// 특히 'STATUS_INVALID_ARGUMENT' 에러는 HAL 구현체에서
// 파라미터 검증 로직이 누락되었을 때 자주 발생한다.
CTS vs VTS: 전략적 접근 비교
성공적인 AAOS 인증을 위해서는 두 테스트의 성격을 명확히 구분하고 리소스를 배분해야 한다. 아래 표는 실무 관점에서 정리한 두 테스트의 비교다.
| 구분 | CTS (Compatibility Test Suite) | VTS (Vendor Test Suite) |
|---|---|---|
| 주요 타겟 | Application Framework API | HAL (Hardware Abstraction Layer) & Kernel |
| 실패 원인 | 표준 API 미준수, Permission 설정 오류 | 드라이버 버그, HAL 구현체 오류, SELinux 정책 |
| Automotive 핵심 | CtsCarTestCases (CarService 동작 확인) |
VtsHalAutomotiveVehicleTargetTest (VHAL 검증) |
| 수정 주체 | 주로 App/Framework 개발자 | BSP(Board Support Package) 엔지니어 |
Conclusion
AOSP Automotive 기반의 시스템을 구축한다는 것은 단순히 안드로이드를 자동차에 이식하는 것이 아니다. 그것은 구글이 정해놓은 엄격한 보안 및 호환성 규격을 통과하여, 사용자의 생명을 담보할 수 있는 수준의 소프트웨어 품질을 증명하는 과정이다. CTS와 VTS는 귀찮은 인증 절차가 아니라, 우리가 만든 시스템이 도로 위에서 멈추지 않게 하는 최후의 방어선임을 명심해야 한다. 지금 당장 터미널을 열고 run cts -m CtsCarTestCases를 실행해 보라. 그 결과값이 곧 당신 제품의 신뢰도다.
Post a Comment