← Docs hub

차세대 플랫폼 검토

1. 검토 전제

• 현행 구성: QCS6490 Android AP + RK3588 Linux·ROS AMR AP.
• 차세대 AP: QCS6490보다 상위 SoC 적용. 1안도 Android AP 교체를 전제로 하며 구체 모델은 미정.
• 제품 요구: 서드파티 앱 도입·확장, Google 서비스 활용 가능성, AMR 자율주행 유지, 원형 디스플레이 적용.
• 미정 사항: 필수 앱과 배포 방식, ROS 버전·의존 패키지, 차세대 BSP·지원 수명, 패널 해상도와 실제 사양.

상위 SoC의 연산 자원 증가는 통합에 유리할 수 있으나, 앱 호환성·ROS 이식·장애 격리·인증 문제를 직접 해결하지는 않는다.

2. 구성안 비교

그림 확대

2.1 1안: Android AP와 Linux·ROS AMR AP 분리 — 출시 범위 관리

장점: Android 앱·음성·미디어와 Linux·ROS 주행 환경을 각각 활용한다. 앱과 로봇 플랫폼의 변경 범위를 나누기 좋고, 전원/reset 경계가 분리되면 한쪽 재시작의 영향을 제한할 수 있다.

단점: 두 보드와 주변 부품의 원가·공간·소비전력 부담이 남는다. 두 OS의 보안 업데이트, AP 간 명령·상태 정합성, 버전 호환과 현장 진단을 관리해야 한다. 상위 Android AP로의 BSP·HAL·앱 이식도 필요하다.

2.2 2안: 단일 칩 Linux·ROS 통합 — 원가와 구성 단순화

장점: Linux·ROS 중심으로 주행·센서·전용 UI를 통합하고 별도 보드와 연결 부품을 줄일 수 있다. 승인된 서비스 SDK와 자체 UI만으로 제품 기능을 충족한다면 하드웨어·운영 구성이 단순해질 가능성이 있다.

단점: Android APK와 Google Play를 같은 방식으로 제공하지 못한다. 필수 서비스별 Linux 지원과 상용 사용 조건을 확보하고, UI·음성·미디어·계정·업데이트 기능을 이식해야 한다. UI·AI 부하와 주행이 자원을 공유하며 AP 장애가 전체 기능에 영향을 줄 수 있다.

2.3 3안: 단일 칩 Android·ROS 통합 — 앱 환경과 보드 통합의 동시 확보

장점: Android 앱 환경을 유지하면서 보드를 통합할 수 있다. 공급사가 지원하는 Linux guest 구성이 있으면 일부 ROS 사용자 공간을 유지할 여지가 있다.

단점: AMR 전체의 Android native 이식 또는 Linux guest 지원이 필요하다. 센서·모터·GPU/NPU 접근, 장치 소유권, 기동·복구, 자원 격리와 Android 인증을 함께 검증해야 한다. 일반적인 ROS 지원이나 가상화 기능만으로 제품 구동을 보장할 수 없다.

3. 구성안별 비즈니스 로직과 주행 Workflow 분담

비즈니스 로직은 사용자 의도·목표·Plan과 제품 전체의 작업 순서를 관리한다. 주행 Workflow는 이동 요청을 받아 경로 실행·장애물 대응·주행 재시도·정지·결과 보고를 관리한다. 두 책임은 단일 칩에서도 구분한다.

그림 확대

예: “거실로 이동해서 공기를 정화해줘.” 비즈니스 로직이 거실 이동 → 청정 실행 → 결과 확인을 관리한다. 주행 Workflow는 거실까지의 이동을 수행하며, 장애물을 만나면 주행 범위 안에서 경로를 조정한다. 이동이 불가능하면 실패 원인을 상위에 보고하고, 상위가 사용자 확인·계획 변경·작업 중단을 결정한다. 주행 계층이 사용자 목표나 청정 순서를 임의로 바꾸지 않는다.

취소는 상위에서 주행 계층으로 전달하고, 실제 정지·취소 결과를 받은 뒤 작업 상태를 갱신한다. 통신 단절 시 주행을 계속할지 정지할지는 주행 계층의 사전 정의 정책으로 처리한다. 모터의 고주기 제어와 보호 동작은 하위 제어기에서 담당한다. Plan에 필요한 모델 호출은 클라우드를 활용할 수 있으며, 표의 배치는 제품 내 요청·실행 관리의 담당 영역이다.

4. 구성안별 앱·Google 서비스·원형 화면의 장단점

앱·서비스 선택의 폭과 도입 속도는 Android를 유지하는 1·3안의 주요 이점이다. Android용으로 제공되는 다양한 앱·SDK를 후보로 활용할 수 있고, 제품에서 지원되는 기존 Android 배포본은 별도 OS 포팅 없이 도입할 수 있다. System S/W와 앱 팀은 서비스 자체를 다시 만드는 부담을 줄이고 제품 연동·원형 화면 대응에 집중할 수 있다. Android의 앱 배포·SDK 생태계는 이러한 재사용의 기반이다. Android 앱·서비스 생태계.

이미 Android에서 서비스 중인 타사 앱을 제품에 도입할 때, Android에서는 공급사가 제공하는 앱을 활용할 수 있다. Linux로 전환하면 같은 서비스를 제공하기 위한 추가 작업이 생길 수 있다. Linux용 앱이 있으면 해당 배포본을 사용하지만, Android용 앱만 있으면 공급사의 Linux 포팅·지원이 필요하거나 웹·SDK를 이용해 서비스 화면과 기능을 별도로 통합해야 한다. 타사 앱의 소스·사용권이 없으면 우리가 직접 포팅하기도 어렵다. 따라서 Linux 전환 비용에는 자체 소프트웨어 이식뿐 아니라 타사 서비스 확보·공급사 협의·대체 연동·후속 유지보수도 포함한다. Android 앱 역시 제품의 OS 버전·CPU ABI·Google 서비스·DRM 지원과 사용 조건을 확인해야 한다.

그림 확대

1안과 3안은 서비스 다양성, 기존 Android 앱·SDK 재사용, 신규 서비스 도입 시 포팅 부담 감소라는 공통 이점이 있다. 사용자 서비스 기반과 Google 서비스 경로도 유사하다. 차이는 주행 환경을 별도 AP에 유지하는지, Android와 동일 SoC에 통합하는지다. 2안은 자체 원형 UI를 구성하기에 유연하지만, 필수 서비스를 Linux에서 제공하고 사용자 서비스 계층을 통합해야 한다. Linux에도 관련 구성요소가 있으므로, 선택한 배포판·BSP의 제공 범위를 확인해 재사용과 자체 개발을 나눈다.

Spotify 등의 공식 앱·임베디드 SDK·Connect·휴대폰 연동은 제공 기능과 계약 조건이 다르므로 동일한 서비스로 간주하지 않는다. 원형 화면은 세 안 모두 로그인·권한창·키보드까지 조작 가능해야 한다. 실제 패널 사양과 기기 유형은 선정 후 확인한다.

관련 자료: Android 호환성, Google Mobile Services, 서비스별 비교, 원형 디스플레이 포팅.

4.1 System S/W 관점에서 Android를 유지하는 실질적 이점

Android를 유지하면 전원·화면·오디오·앱 권한·서비스 통신·진단을 공통 시스템 기반 위에서 구성할 수 있다. System S/W 팀은 이 기반의 제품별 설정과 BSP·HAL 연결에 집중하고, SKIX의 작업 관리·Context 제공·AI Planner 연계에 개발 역량을 투입할 수 있다. 핵심 이점은 공통 기능의 신규 구성과 앱별 중복 구현, 장애 분석 방식의 분산을 줄이는 데 있다. AOSP 구조.

Linux·ROS로 전환하면 주행 기능 외에 UI·앱·음성·장치를 함께 운영하는 제품 System Service 계층을 구성해야 한다. Linux의 기존 서비스와 라이브러리를 재사용하되, 제품 공통 API·상태 알림·권한·우선순위·장애 복구를 연결하는 개발과 운영을 우리가 담당한다. ROS의 노드·통신·주행 관리만으로 이 사용자 서비스 계층이 완성되지는 않는다.

System Service 비교 그림 확대

사용자 기능

화면·음성·카메라가 함께 동작할 때 필요한 공통 제어 기반이다.

구성요소 예

• Android: PowerManager, DisplayManager, WindowManager, SurfaceFlinger, AudioManager, CameraService.
• Linux: 커널 전원 관리, Wayland, Qt, ALSA, PipeWire, WirePlumber, V4L2, GStreamer.

서비스 운영

앱과 AI Planner가 같은 설정·권한·상태 체계를 사용하도록 연결한다.

구성요소 예

• Android: ConnectivityManager, ActivityManager, Binder/AIDL, PackageManager, SELinux, SettingsProvider.
• Linux: NetworkManager, systemd, D-Bus, 계정 및 접근 통제, 설정 저장소.

유지보수

업데이트 실패와 현장 장애에 대응하는 운영 기반이다.

구성요소 예

• Android: Virtual A/B, logcat, dumpsys, bugreport.
• Linux: RAUC, 부트로더, 시스템 로그, 코어덤프, 추적 도구.

표의 Linux 개발 범위는 구성요소를 새로 만드는 작업과 기존 기능을 설정·연결하는 작업을 포함한다. 배포판·BSP가 통합해 제공하는 범위만큼 자체 개발량은 줄어든다. Android도 제품별 정책, BSP·HAL 연결, 원형 UI, 마이크·AEC·DSP 튜닝과 회귀 시험은 필요하지만 공통 서비스·API·진단 체계를 재사용할 수 있다.

예를 들어 음악 재생 중 음성 안내를 출력하고 화면을 끄는 동작은 Android의 오디오 포커스·전원·화면 서비스를 연결해 구성한다. Linux에서는 오디오 정책 관리자·화면 시스템·전원 관리를 연결하고, 안내 종료 후 음량 복원과 화면이 꺼진 동안의 작업 유지까지 하나의 제품 정책으로 묶는다. 이 통합 계층은 새 앱과 서비스가 추가될 때도 계속 유지해야 한다.

관련 기반: Android 구조, 전원 관리, 오디오 포커스, 앱 격리, Virtual A/B, WirePlumber 정책 관리, NetworkManager, RAUC 업데이트·부팅 연동.

4.2 세 구성안에서 달라지는 System S/W 부담

System S/W 관점에서는 Android의 공통 서비스와 기존 개발 자산을 재사용할 수 있는 1안이 개발 범위를 관리하기 쉽다. 3안도 Android 재사용 이점은 같지만 ROS 통합 부담이 추가된다. 2안의 경제성은 보드 절감액과 함께 사용자 서비스 재통합·이식·장기 유지보수 비용으로 판단한다. Android에서도 로봇의 물리적 안전 제어와 SKIX의 목표·작업·결과 관리는 제품 고유 개발 영역이다.

5. 비용 부담과 경제성

그림 확대

5.1 비용 발생 항목

세 안 모두 차세대 상위 SoC의 완성 보드 견적을 기준으로 비교한다. 1안의 현행 QCS6490 보드 가격과 통합안의 신규 보드 가격을 그대로 비교하지 않는다.

5.2 총비용과 손익분기

총비용 = 초기 개발·인증비 + 생산 수량×대당 완성제품 원가 + 지원 기간의 운영·보안·품질 대응비

대당 원가는 AP·RAM·저장·PMIC·PCB·연결·냉각·라이선스·조립·검사·수율 손실을 포함한다. 통합안의 절감액은 제거하는 AMR 보드 가격에서 상위 SoC·메모리·냉각 등의 추가 비용을 차감해 계산한다.

1안 대비 대당 순절감액을 S, 추가 개발비와 지원 기간의 추가 운영비를 F라고 할 때, S>0·F>0이고 비용이 선형이면 회수 수량은 N=F/S다. 순절감이 없으면 생산량 증가만으로 통합 개발비를 회수할 수 없다. 견적 전에는 금액이나 절감률을 확정하지 않는다.

6. 최종 권고와 결정 조건

그림 확대

두 AP의 장애 독립성은 전원·reset 경계에 따라 달라진다. 단일 칩은 앱·AI·주행 동시 부하와 장애·복구를 검증한다.

7. 선정 절차

필수 서비스와 BSP 지원 확인 → 안별 개발·완성 BOM 견적 → 동일 기능 시제품 검증 → 총비용 비교 → 최종 SoC·구조 선정 순서로 진행한다. 현재 권고는 플랫폼 설계 판단이며 실측 성능·인증·이식 완료 결과는 아니다.

Connections

• 차세대 프레임워크 — 문맥 이해에서 목표 달성과 기기 실행까지

• 원형 디스플레이 Android 포팅 상세

• Android·Linux·Qt 상세 비교
• SK-Intellix Hub