Monday, July 28, 2025

AOSP Automotive 테스트의 핵심: 안정적인 차량용 OS를 위한 필수 검증 절차
  /   No comments   

자율주행과 커넥티드카 기술이 자동차 산업의 패러다임을 바꾸고 있는 오늘날, 차량용 인포테인먼트(IVI, In-Vehicle Infotainment) 시스템의 중심에는 Android Automotive OS(AAOS)가 자리 잡고 있습니다. AAOS는 우리가 스마트폰에서 경험했던 편리한 사용자 경험을 자동차로 그대로 가져왔지만, 그 이면에는 스마트폰과는 비교할 수 없는 수준의 안정성과 신뢰성이 요구됩니다. 운전자의 안전과 직결되는 만큼, 작은 오류 하나가 치명적인 결과를 초래할 수 있기 때문입니다. 그렇기 때문에 AOSP(Android Open Source Project)를 기반으로 AAOS를 개발하는 모든 자동차 제조사(OEM)와 부품 공급사(Tier-1)에게 '테스트'는 선택이 아닌 필수 생존 전략입니다. 이 글에서는 AOSP Automotive 시스템의 품질을 보증하는 핵심적인 테스트 방법론과 그 철학에 대해 IT 전문가의 시각으로 깊이 있게 탐구해 보겠습니다.

1. 왜 테스트가 그토록 중요한가? - 호환성 정의 문서(CDD)의 이해

AOSP Automotive 테스트를 이야기하기 전에 반드시 짚고 넘어가야 할 개념이 있습니다. 바로 호환성 정의 문서(CDD, Compatibility Definition Document)입니다. 구글은 안드로이드 생태계의 파편화를 막고 모든 안드로이드 기기에서 앱이 일관되게 동작하도록 하기 위해 CDD라는 '규약집'을 제공합니다. 이 문서에는 안드로이드 기기가 '안드로이드 호환' 기기로 인정받기 위해 반드시 지켜야 할 하드웨어 및 소프트웨어 요구사항이 아주 상세하게 명시되어 있습니다.

자동차의 경우는 더욱 엄격합니다. AAOS가 탑재된 차량이 구글의 핵심적인 자동차 서비스, 즉 GAS(Google Automotive Services)—Google Maps, Google Assistant, Google Play Store 등을 포함—를 탑재하려면 반드시 CDD의 모든 조항을 준수하고 관련 테스트를 통과해야 합니다. 만약 CDD를 위반하면 GAS 라이선스를 받을 수 없게 되며, 이는 곧 시장에서 경쟁력을 상실함을 의미합니다. 따라서 CDD는 AAOS 개발의 '헌법'과도 같으며, 지금부터 설명할 모든 테스트는 이 헌법을 제대로 준수하고 있는지를 검증하는 과정이라 할 수 있습니다.

2. AOSP Automotive 테스트의 3대 핵심: CTS, VTS, STS

AOSP Automotive 시스템의 호환성과 안정성을 검증하기 위해 구글은 크게 세 가지 공식 테스트 스위트(Test Suite)를 제공합니다. 이들은 각각 다른 계층을 담당하며, 시스템 전체를 촘촘하게 검증하는 역할을 합니다. 마치 건물을 지을 때 구조 안전, 전기 설비, 소방 안전을 각각 다른 전문가가 검사하는 것과 같습니다.

2.1. CTS (Compatibility Test Suite): 애플리케이션과 프레임워크의 약속

CTS는 안드로이드 테스트의 가장 기본이자 핵심입니다. 이는 안드로이드 애플리케이션 프레임워크(Application Framework) 레벨에서 기기가 CDD를 준수하는지를 검증합니다. 쉽게 말해, 개발자들이 사용하는 공개 API(Application Programming Interface)가 의도된 대로 정확하게 동작하는지를 확인하는 테스트입니다. 예를 들어, Play Store에서 다운로드한 내비게이션 앱이 차량의 위치 정보 API를 호출했을 때, 시스템이 정확한 GPS 좌표를 오차 없이 반환해야 합니다. 만약 특정 제조사가 이 API를 임의로 수정하여 다른 형태로 값을 반환한다면, 앱은 오동작하게 되고 생태계 전체의 신뢰가 무너집니다.

특히 Automotive 환경을 위해서는 CTS-V (CTS for Automotive)라는 특화된 테스트 스위트가 추가로 제공됩니다. CTS-V는 일반적인 CTS 항목에 더해 다음과 같이 자동차에 특화된 기능들을 집중적으로 검증합니다.

  • Car API: 차량 속도, 기어 상태, 온도 등 차량 속성(Vehicle Properties)에 접근하는 API의 정확성
  • Car UI Library: 운전자 주의 분산(Driver Distraction) 가이드라인을 준수하는 UI 컴포넌트들의 동작 검증
  • 미디어 API: 차량 환경에서의 오디오 재생, 탐색, 블루투스 연결 등의 안정성
  • 로터리 컨트롤러: 터치스크린 외에 물리적 다이얼(Rotary Controller)을 통한 UI 제어의 일관성

CTS 통과는 GAS 인증의 가장 기본적인 전제조건이며, 수십만 개에 달하는 테스트 케이스를 모두 통과해야 합니다. 이는 마치 "우리가 만든 자동차 OS는 모든 안드로이드 앱과 문제없이 소통할 수 있습니다"라는 공인 인증서와 같습니다.

2.2. VTS (Vendor Test Suite): 하드웨어와 소프트웨어의 가교

CTS가 소프트웨어 상위 레벨의 '약속'을 검증한다면, VTS는 그보다 더 깊숙한 곳, 즉 하드웨어 추상화 계층(HAL, Hardware Abstraction Layer)과 리눅스 커널(Linux Kernel)의 구현을 검증합니다. HAL은 안드로이드 프레임워크라는 '표준 언어'와 제조사가 만든 다양한 하드웨어(카메라, 센서, 오디오 칩 등)의 '고유 언어'를 통역해주는 중간 계층입니다. VTS는 이 '통역사'가 표준 문법(HAL Interface)을 정확하게 지켜서 통역하고 있는지를 확인하는 역할을 합니다.

예를 들어, 안드로이드 프레임워크가 후방 카메라를 켜달라고 HAL에 요청(`ICameraProvider::getCameraDeviceInterface()`)을 보냈을 때, 제조사의 카메라 HAL 구현체는 CDD에 정의된 규격대로 응답해야 합니다. 만약 응답이 지연되거나, 규격에 맞지 않는 데이터를 반환하면 후방 카메라 화면이 늦게 뜨거나 깨져 보이는 등 심각한 문제로 이어질 수 있습니다. VTS는 바로 이런 하드웨어 종속적인 부분의 구현 정확성을 파고들어 검증합니다.

VTS의 주요 테스트 영역은 다음과 같습니다.

  • HAL Interface 테스트: 정의된 모든 HAL 인터페이스(HIDL 또는 AIDL 기반)의 동작을 검증합니다. 각 함수 호출에 대한 입력값과 반환값이 명세와 일치하는지 확인합니다.
  • 커널(Kernel) 테스트: 리눅스 커널의 특정 설정(e.g., ION, ashmem)과 시스템 콜(System Call) 동작이 안드로이드 요구사항을 충족하는지 검사합니다.
  • 성능(Performance) 테스트: HAL 구현의 반응 속도나 처리량 등 비기능적 요구사항을 테스트합니다.

과거에는 제조사들이 HAL을 각기 다른 방식으로 구현하여 안정성 문제가 많았지만, VTS의 도입으로 HAL 구현이 표준화되면서 시스템 전체의 안정성이 크게 향상되었습니다. VTS 통과는 "우리 자동차에 탑재된 모든 하드웨어는 안드로이드 시스템과 완벽하게 호환됩니다"라는 기술적인 보증서 역할을 합니다.

2.3. STS (Security Test Suite): 보안의 최전선

오늘날의 자동차는 외부 네트워크와 항상 연결되어 있는 '움직이는 컴퓨터'입니다. 이는 곧 해킹의 위협에 항상 노출되어 있음을 의미합니다. STS는 안드로이드 시스템의 보안 취약점을 검증하는 데 특화된 테스트 스위트입니다. 이 테스트는 이미 알려진 보안 취약점(CVE, Common Vulnerabilities and Exposures)에 대해 시스템이 제대로 패치되었는지를 확인하는 것을 주목적으로 합니다.

STS는 매달 구글이 발표하는 안드로이드 보안 게시판(Android Security Bulletin)과 연동되어 업데이트됩니다. 예를 들어, 특정 미디어 코덱에서 버퍼 오버플로우 취약점이 발견되면, STS는 해당 취약점을 악용하는 테스트 케이스를 포함하게 됩니다. 만약 차량 시스템이 이 테스트를 통과하지 못한다면, 악의적인 미디어 파일을 통해 해커가 시스템 제어 권한을 탈취할 수도 있습니다. STS는 이러한 비극적인 시나리오를 사전에 방지하는 매우 중요한 안전장치입니다.

요약하자면, CTS, VTS, STS는 각각 애플리케이션 호환성, 하드웨어 연동 안정성, 그리고 시스템 보안이라는 세 가지 중요한 축을 담당하며, 이 세 가지 테스트를 모두 통과해야 비로소 '신뢰할 수 있는 AOSP Automotive 시스템'이라고 말할 수 있습니다.

3. 어떻게 테스트를 실행하는가? - Tradefed와 atest

그렇다면 이 방대한 양의 테스트들은 어떻게 실행하고 관리할까요? 여기에는 Trade Federation(줄여서 Tradefed)이라는 강력한 테스트 하네스(Test Harness)가 사용됩니다. Tradefed는 단순히 테스트를 실행하는 것을 넘어, 테스트의 전 과정을 자동화하고 관리하는 '야전 사령부'와 같은 역할을 합니다.

3.1. Tradefed (Trade Federation): 테스트 자동화의 지휘관

Tradefed는 자바(Java) 기반의 오픈소스 테스트 프레임워크로, 다음과 같은 복잡한 작업들을 처리합니다.

  • 장치 관리: 여러 대의 테스트 대상 기기(DUT, Device Under Test)의 상태를 관리하고, 테스트에 사용할 수 있는 기기를 자동으로 할당합니다.
  • 빌드 프로비저닝: 테스트에 필요한 시스템 이미지, 테스트 APK 등을 기기에 자동으로 설치(Flashing)합니다.
  • 테스트 실행 및 제어: CTS, VTS 등 다양한 유형의 테스트를 예약하고, 순차적 또는 병렬적으로 실행하며, 중간에 기기가 멈추거나 재부팅되어도 테스트를 이어서 진행합니다.
  • 결과 수집 및 보고: 모든 테스트의 성공/실패 여부, 로그, 버그리포트, 스크린샷 등을 수집하여 체계적인 보고서를 생성합니다.

엔지니어는 복잡한 XML 설정 파일을 통해 원하는 테스트 계획(Test Plan)을 정의하고 Tradefed에 전달하기만 하면, 나머지 과정은 Tradefed가 알아서 처리해줍니다. 수십만 개의 테스트를 수백 대의 기기에서 밤낮없이 실행해야 하는 OEM 입장에서는 Trade_exec_command_exec_command_exec_command_exec_command_exec_command_commandfed 없이는 호환성 테스트를 수행하는 것이 거의 불가능에 가깝습니다.

3.2. atest: 개발자를 위한 간편한 테스트 도구

Tradefed가 강력한 만큼 설정이 복잡하고 무겁다는 단점이 있습니다. 개발자가 자신의 코드 수정 사항이 미치는 영향을 빠르고 간단하게 확인하고 싶을 때마다 Tradefed를 설정하는 것은 비효율적입니다. 이러한 필요에 의해 탄생한 것이 바로 `atest`입니다.

`atest`는 AOSP 소스 트리 내에서 사용할 수 있는 파이썬(Python) 기반의 커맨드 라인 도구로, 개발자가 단 한 줄의 명령어로 특정 테스트를 빌드하고 실행할 수 있게 해줍니다.

예를 들어, 개발자가 카메라 HAL 관련 코드를 수정한 뒤, 해당 부분에 대한 VTS 테스트만 실행해보고 싶다면 터미널에 다음과 같이 입력하면 됩니다.


$ source build/envsetup.sh
$ lunch aosp_car_x86_64-userdebug
$ atest VtsHalCameraProviderV2_4TargetTest

이 명령어 하나로 `atest`는 내부적으로 필요한 모듈을 컴파일하고, 기기에 설치한 뒤, Tradefed를 호출하여 해당 테스트를 실행하고, 결과까지 깔끔하게 보여줍니다. 전체 CTS나 VTS를 실행하는 데는 수십 시간이 걸릴 수 있지만, `atest`를 사용하면 단 몇 분 만에 원하는 부분만 국소적으로 테스트할 수 있어 개발 생산성을 극대화할 수 있습니다. 개발 과정에서는 `atest`로 작은 단위의 회귀 테스트를 지속적으로 수행하고, 통합 빌드 단계에서 CI/CD(지속적 통합/지속적 배포) 파이프라인을 통해 Tradefed로 전체 테스트 스위트를 실행하는 것이 일반적인 워크플로우입니다.

4. 실전 워크플로우: 개념을 현실로

지금까지 설명한 개념들을 종합하여 가상의 시나리오를 통해 실전 테스트 워크플로우를 살펴보겠습니다.

  1. 요구사항 발생: 한 자동차 OEM이 자사 차량에 탑재될 AAOS의 부팅 속도를 개선하기 위해 특정 시스템 서비스를 수정하기로 결정합니다.
  2. 개발 및 단위 테스트: 개발자는 코드를 수정한 후, 자신의 개발 환경에서 기본적인 단위 테스트(Unit Test)를 실행하여 로직의 정확성을 1차 검증합니다.
  3. `atest`를 통한 국소적 검증: 개발자는 수정한 서비스와 관련된 CTS 및 VTS 모듈이 무엇인지 파악하고, `atest`를 사용하여 해당 테스트들만 빠르게 실행해봅니다. 예를 들어, `atest CtsAppLaunchTestCases` 와 같이 실행하여 앱 구동 시간에 영향을 주지 않았는지 확인합니다. 이 단계에서 실패가 발생하면 즉시 코드를 수정하고 다시 테스트합니다.
  4. 코드 제출 및 CI/CD 파이프라인 실행: `atest`를 통과한 코드를 중앙 코드 저장소(Git Repository)에 제출합니다. 코드 제출이 감지되면, Jenkins나 GitLab CI와 같은 CI/CD 시스템이 자동으로 트리거됩니다.
  5. Tradefed를 통한 전체 테스트 자동화: CI/CD 서버는 최신 소스코드를 받아 전체 시스템 이미지를 빌드합니다. 그 후, Tradefed를 호출하여 수십 대의 테스트 차량(또는 HIL 장비)에 새 빌드를 자동으로 설치합니다. Tradefed는 설정된 테스트 계획(예: 'full_cts-v', 'vts-hal')에 따라 밤새도록 CTS-V, VTS, STS 전체 테스트를 실행합니다.
  6. 결과 분석 및 리포팅: 다음 날 아침, 담당자는 Tradefed가 생성한 상세한 테스트 리포트를 확인합니다. 모든 테스트가 통과했다면 해당 변경 사항은 다음 공식 빌드에 포함됩니다. 만약 실패한 테스트 케이스가 있다면, Tradefed가 수집한 로그와 버그리포트를 분석하여 원인을 파악하고, 해당 개발자에게 수정 요청(티켓 생성)을 보냅니다.

이러한 체계적이고 자동화된 테스트 파이프라인을 통해 AOSP Automotive 시스템은 작은 코드 변경 하나하나가 전체 시스템의 안정성, 호환성, 보안에 미치는 영향을 지속적으로 검증받게 됩니다. 이것이 바로 우리가 안전하고 쾌적한 차량용 OS를 경험할 수 있는 이유입니다.

결론: 테스트는 품질의 시작과 끝

AOSP Automotive의 테스트 방법론은 단순히 버그를 찾는 행위를 넘어, 안드로이드라는 거대한 생태계의 일관성을 유지하고, 무엇보다 운전자의 안전을 보장하기 위한 정교한 시스템입니다. CDD라는 법규를 기준으로, CTS, VTS, STS라는 세 가지 다른 잣대로 시스템의 모든 계층을 꼼꼼하게 측정하고, Tradefed와 `atest`라는 효율적인 도구를 사용하여 이 과정을 자동화하고 가속화합니다. 소프트웨어 정의 자동차(SDV, Software Defined Vehicle) 시대로의 전환이 가속화되면서 소프트웨어의 품질은 곧 자동차의 품질이 되고 있습니다. 따라서 이러한 AOSP의 표준 테스트 철학을 깊이 이해하고 조직의 개발 문화에 내재화하는 것은 미래 자동차 시장에서 성공하기 위한 가장 중요한 첫걸음이 될 것입니다.


0 개의 댓글:

Post a Comment