SKIX 로보틱스 프레임워크 전체 구조 — 처음 보는 안내서
이 페이지부터 읽으면 된다. 클래스명이나 Binder 세부사항보다 먼저, 누가 요청하고 누가 판단하며 누가 실제 기기를 움직이고 결과가 어디로 돌아오는지 순서대로 설명한다.
1. SKIX를 한 문장으로
SKIX는 앱이나 상위 지능 서비스가 보낸 로봇 명령을 안전하게 받아, 현재 상태와 정책을 확인하고, 알맞은 기능이 실행하도록 연결한 뒤, 실제 결과를 다시 상태와 근거로 돌려주는 AOSP 위의 로보틱스 프레임워크다.
영문 기술어를 만났을 때
| 쉬운 뜻 | 코드·플랫폼에서 찾을 이름 |
|---|---|
| Android가 SKIX를 시작하고 보호하는 곳 | AOSP, SystemServer, system_ext |
| 앱 요청이 들어오는 보호 입구 | Binder, AIDL, root service |
| 앱이 쓰는 기능 창구 | Manager |
| 기능의 상태와 규칙을 책임지는 서비스 | ManagerService |
| 오래 걸리는 작업과 실행 순서 | Task, Workflow, Scheduler |
| 현재 기기 상태와 실행 가능 여부 | State, Policy, Capability, Resource |
| 실제 완료를 판단하는 관측 근거 | Evidence |
| 실제 기기나 외부 플랫폼에 연결하는 실행자 | Agent/provider, ROS 2, HAL, MCU |
그림은 다음 순서로 읽는다.
- 요청: 앱·Launcher·상위 지능 서비스가 “청소 시작” 같은 의도를 보낸다.
- Android 보호: AOSP 쪽 진입점이 호출자와 권한을 확인하고 Runtime을 시작·감시한다.
- 공통 판단: SKIX Runtime이 Task, 상태, 정책과 자원 충돌을 확인한다.
- 기능별 책임: Cleaning, AMR, Vision 같은 도메인 서비스가 자기 상태와 규칙으로 실행을 맡는다.
- 물리 실행: Agent/provider가 ROS 2, HAL, MCU, 센서와 모터를 실제로 호출한다.
- 결과 환류: 진행률·성공·실패·관측이 State와 Evidence로 돌아와 다음 판단에 쓰인다.
2. Manager, ManagerService, Agent는 무엇인가
이 세 가지를 같은 것으로 보면 구조가 어렵게 느껴진다.
| 구성 | 쉬운 표현 | 하는 일 | 하지 않는 일 |
|---|---|---|---|
Skix*Manager |
앱이 쓰는 리모컨 | 안정적인 typed API 제공, 요청·조회·구독 | 상태와 하드웨어를 직접 소유하지 않음 |
*ManagerService |
규칙과 상태를 가진 책임자 | 도메인 상태 machine, 정책, lifecycle, 결과 해석 | 앱 화면이나 드라이버를 직접 구현하지 않음 |
| Agent/provider | 실제 실행자 | ROS 2·HAL·MCU·기존 service를 호출하고 결과를 돌려줌 | 제품 전체 정책의 최종 결정을 소유하지 않음 |
즉, Manager는 앱이 누르는 리모컨이고, ManagerService는 규칙과 상태를 가진 책임자이며, Agent/provider는 실제 장치나 외부 플랫폼을 움직이는 실행자다.
TaskManagerService는 조금 특별하다. 대부분의 장기 명령에 Task ID를 붙이고 접수·대기·진행·취소·종료를
추적하는 관제자다. 하지만 청소, 주행, 틸팅 같은 기능의 세부 상태와 실제 명령 구현까지 흡수하지 않는다.
3. 청소 시작 명령으로 이해하기
예를 들어 앱이 청소 시작을 요청하면 다음처럼 처리한다.
CleaningManager가 typed 요청을 받는다.- Android 보호문이 호출자와 권한을 확인한다.
TaskManagerService가 추적 가능한 Task를 만든다.- Policy·State·Resource가 안전 조건과 충돌 작업을 판정한다.
CleaningManagerService가 청소 도메인 상태를 전이하고 provider에 실행을 위임한다.- Agent/provider가 실제 청소 장치·ROS 2·HAL을 동작시킨다.
- feedback과 관측이 Task·State·Evidence에 반영되고 앱/상위 지능 서비스가 이를 보고 교정·취소·재계획한다.
접수 성공 ≠ 물리 완료다. 요청이 허용되고 Task ID가 만들어졌다는 사실만으로 로봇이 일을 끝낸 것은 아니다. provider의 실제 결과와 Evidence가 돌아와 terminal 상태에 반영되어야 완료다.
4. 전체 기능은 어떻게 나뉘는가
공개 API는 현재 24개 Manager ID로 나뉜다. 아래 다섯 그룹은 읽기 위한 묶음일 뿐이다.
같은 프로세스에 배치되더라도 각 도메인은 별도 ManagerService와 별도 상태 owner를 가진다.
| 그룹 | Manager | 이 그룹이 답하는 질문 |
|---|---|---|
| 공통 제어 | Health, State, Evidence, Policy, Resource, Capability | 지금 가능한가, 왜 가능한가, 어떤 근거와 자원이 있는가 |
| 실행 관리 | Task, Workflow, Scheduler | 무엇을 언제 실행하며 진행·취소·종료를 어떻게 추적하는가 |
| 로보틱스·AI | AMR, LLM, Vision, MCU, Cleaning | 주행·추론·시각·제어·청소 기능을 누가 책임지는가 |
| 연결·제품 | IoT, Update, Pairing, EventAsset, AirQuality | 연결·업데이트·등록·자산·공기질 상태를 누가 책임지는가 |
| 기기·상호작용 | Power, UI, System, Diagnostics, Security | 전원·화면·시스템·진단·보안을 누가 책임지는가 |
Cleaning과 AirQuality는 제품 관점에서 연관되어도 같은 상태가 아니다. UI도 물리 동작의 상태 owner가 아니다. 따라서 각각 별도 Manager/ManagerService로 유지하고, 필요한 조합은 Workflow와 Policy에서 한다.
5. 서로 얽힌 제품 사양은 어디에 두는가
“주행 중에는 틸팅 다운” 같은 사양을 AMR 코드와 Tilt 코드 양쪽에 흩어 놓지 않는다.
도메인 상태 관측
-> StateManagerService가 현재 상태로 투영
-> PolicyManagerService가 함께 적용할 조건을 판정
-> ResourceManagerService가 충돌 자원을 조정
-> Task/Workflow가 실행 순서와 보상을 관리
-> 각 도메인 ManagerService가 자기 명령만 실행
이 구조에서 AMR은 주행 상태의 단일 owner이고, Tilt 계열 서비스는 틸팅 상태와 명령의 단일 owner다. “주행 중 틸팅 다운”이라는 교차 도메인 규칙은 Policy/Workflow가 조합한다. 어느 한 도메인이 다른 도메인의 내부 상태를 직접 고쳐서는 안 된다.
6. AOSP에서는 어디에 놓이는가
SKIX는 AOSP의 system_server에 로보틱스 전체를 넣지 않는 하이브리드 구조다.
| 위치 | 맡는 책임 | 이유 |
|---|---|---|
| 앱/상위 지능 서비스 process | Manager API 호출, Task/Workflow 생성·교정 | 제품 경험과 실행 의도를 표현 |
AOSP system_server |
부팅 시점, Root Binder 공개, UID·권한·서명 확인, Runtime 감시 | Android 신뢰 경계가 맡아야 함 |
system_ext SKIX Runtime |
State·Policy·Resource·Task와 24개 ManagerService | 무거운 로보틱스 상태·정책을 격리 |
| Agent/provider process | DeviceAgent 호환, ROS 2·native·HAL·MCU 연결 | 실제 장치와 기존 구현 재사용 |
시작 흐름은 SystemServer -> SkixFrameworkSystemService -> Runtime bind -> ManagerService READY -> Manager 공개
가 목표다. init.rc는 native daemon이나 vendor 보조 process에 사용할 수 있지만, 앱 형태 Runtime의
Android lifecycle과 Binder 공개는 SystemService가 관리하는 편이 맞다.
7. 지금 구현된 범위
2026-09-08 기준 기본 Runtime은 Runtime·State·Evidence·Policy·Resource·Capability·Task의 실제 7개 서비스를 생성한다. 자원·기능·작업 기반 상세에서 서비스 시작, 자원 소유권, 기능 조회의 차이를 폴더 구조와 함께 본다. 기본 기능 목록은 비어 있으며, 15개 제품 도메인과 장치 실행기가 모두 연결됐다는 뜻은 아니다.
상태를 세 종류로만 읽으면 된다.
| 상태 | 의미 | 현재 예 |
|---|---|---|
| 코드/JVM 검증 | 소스와 자동화 테스트로 계약을 확인함 | API v1·24 Manager ID, caller identity/admission core, scope grant matrix, transaction 재인가, generation snapshot, State/Task/Policy 첫 slice |
| 골격 또는 연결 중 | 구조나 adapter는 있으나 실제 Android runtime 연결이 남음 | 24개 ManagerService 골격, IoT·AMR·LLM·AirQuality·Power observation adapter, 첫 typed Task Binder |
| AOSP 제품 포함/실기기 검증 전 | 제품 이미지·SELinux·권한·기기 동작 증거가 아직 없음 | SystemServer 실제 publish, Runtime bind/death, 제품 grant, DeviceAgent dual-publish, provider terminal Evidence |
좀 더 정확한 현재 판정은 다음과 같다.
| Slice | 판정 |
|---|---|
| stable API v1과 24 Manager ID | SDK JVM 37개 및 release AAR compile 검증 |
| caller identity, Root discovery/lookup, Android trust policy | Framework JVM 및 Android release compile 검증 |
| package/user/Manager/operation grant matrix | 기본 거부·정확 일치·all-users 명시 grant·불변 snapshot JVM 검증; 실제 제품 grant 값 미설정 |
| Manager transaction 재인가 | caller trust/scope/runtime lifecycle/generation 매 호출 재검사 core JVM 검증; typed Binder 연결 후속 |
| generation-bound endpoint snapshot | 원자 교체·stale publish 거부·death invalidation JVM 검증; Runtime adapter 후속 |
| lifecycle, State, Task queue/history/cancel, Policy 첫 slice | JVM 검증 |
24개 실제 typed IBinder endpoint와 SystemServer publish |
후속 |
| permission·SELinux·product makefile와 DeviceAgent 이행 | 후속 |
| product image와 기기 동작 | AOSP product 포함 미검증, 실기기 미검증 |
JVM 통과는 AOSP 제품 포함이나 실기기 동작 증명이 아니다.
8. 상위 지능 서비스와 Framework의 경계
상위 지능 서비스는 Experience Goal에 맞게 Task와 Workflow를 만들고, 실행 중 State/Evidence를 보며 수정·교정·취소·재계획한다. Framework는 Experience를 대신 추론하지 않는다. Framework는 현재 기기 상태, capability, 정책·자원 판정, Task lifecycle, feedback, Evidence와 안정적인 거부 이유를 제공한다. 안전·하드웨어 보호 정책을 위반하는 요청은 상위 지능 서비스 요청이어도 거부한다.
9. 전문가용 상세 구조도
여기까지가 처음 읽을 내용이다. Binder 진입점, Runtime generation, 24개 ManagerService와 provider를 한 장에 모두 보고 싶을 때만 아래 상세도를 연다.
- 이 그림이 답하는 질문: 앱의 요청을 누가 보호하고 판단하며, 어떤 기능 책임자와 실행부를 거쳐 결과가 돌아오는가?
- 읽는 순서: 위의 1번 요청부터 오른쪽으로 읽고, 가운데 공통 판단→작업 관리→기능별 책임을 거쳐 아래 실행부로 내려간 뒤 초록 점선을 따라 돌아온다.
- 현재 검증 범위: 구조 문서와 JVM 계약 검증을 반영했다. AOSP 제품 포함, SELinux 실제 정책, provider의 물리 동작과 실기기 복구는 아직 별도 검증 대상이다.
상세도에서 Manager ≠ ManagerService ≠ Agent/provider이며, Root Binder의 admission은 Manager transaction
권한을 대신하지 않는다. 실제 typed Binder는 매 호출마다 caller trust, Manager scope, Runtime lifecycle과
현재 generation을 다시 확인해야 한다.
10. 궁금한 부분만 더 보기
| 궁금한 점 | 다음 문서 |
|---|---|
| 부팅과 장애 복구 | AOSP Boot와 Runtime Lifecycle |
| 요청부터 물리 완료까지 | Request-to-Evidence 전체 흐름 |
| Runtime 내부 호출 관계 | Runtime 내부 토폴로지 |
| 정책 충돌과 상태 전이 | Task·Policy·State 순환 |
| 각 도메인의 owner/provider | Domain Owner/Provider 맵 |
| DeviceAgent에서 이행하는 방법 | Legacy 이행 맵 |
| 목표와 현재 구현의 전체 비교 | 전체 구조 Atlas |
11. 코드 근거
- Public API:
skix-framework/base/core/java/com/sk/airbot/framework/SkixFrameworkContract.java - Root Binder:
skix-framework/base/core/aidl/com/sk/airbot/framework/internal/binder/ISkixFrameworkService.aidl - Android 진입점:
skix-framework/base/services/core/java/com/sk/airbot/frameworkservice/server/entrypoint - 공통 제어:
skix-framework/base/services/core/java/com/sk/airbot/frameworkservice/server/control - Task/Workflow 실행:
skix-framework/base/services/core/java/com/sk/airbot/frameworkservice/server/execution - 제품 도메인:
skix-framework/base/services/core/java/com/sk/airbot/frameworkservice/server/domain - Runtime 조립:
skix-framework/base/services/core/java/com/sk/airbot/frameworkservice/server/runtime/SkixFrameworkCompositionRoot.java - Legacy 원본:
apps/DeviceAgent/app/src/main/java/com/sk/airbot/deviceagent - AOSP lifecycle 기준:
frameworks/base/services/java/com/android/server/SystemService.java