소프트웨어 공장

안드로이드 기반의 로봇 하드웨어나 스마트 가전, 혹은 커스텀 임베디드 보드를 개발하다 보면 필연적으로 세상에 없던 나만의 커스텀 센서나 물리 모터를 제어해야 하는 순간을 마주합니다. 리눅스 커널 단에 드라이버 노드(/dev/my_sensor)를 멋지게 뚫어놓았더라도, 이를 상위 안드로이드 시스템 서비스와 앱 레이어까지 안전하게 끌어올리려면 결국 나만의 커스텀 HAL(Hardware Abstraction Layer) 모듈을 빌드해야 하는데요.하지만 구글 공식 문서를 찾아보면 구형 HIDL 방식과 최신 AIDL 방식이 뒤섞여 있어 초보 플랫폼 엔지니어들은 시작부터 갈 길을 잃기 십상입니다. 과거 안드로이드 8~9 시절에 쓰던 Passthrough HIDL 구조는 이제 완전히 역사의 뒤안길로 사라졌기 때문이죠..

안드로이드 시스템 소스코드를 깊숙이 파고들다 보면 결국 모든 길은 한 곳으로 통한다는 사실을 깨닫게 됩니다. 바로 프로세스 간 통신(IPC)의 핵심인 바인더(Binder) 메커니즘인데요. 하지만 똑같은 바인더를 쓰면서도 어떤 모듈은 .aidl 파일로 소통하고, 어떤 벤더 드라이버 레이어는 .hal(HIDL) 파일로 인터페이스를 정의하고 있어서 소스 분석 초기에 큰 혼란을 겪곤 합니다."앱 개발할 때 쓰던 AIDL을 왜 HAL 레이어 소스에서 또 쓰고 있지?", "HIDL은 이제 안 쓰이는 걸까?" 같은 의문이 드는 것은 당연합니다. 구글이 안드로이드 버전을 거듭하며 플랫폼 내부의 통신 표준 아키텍처를 계속해서 진화시켜 왔기 때문인데요. 이번 포스팅에서는 AIDL과 HIDL의 태생적인 목적 차이부터 시작해..