SKIX 리팩터링 한눈에 보기
이 페이지는 SKIX 프레임워크 리팩터링을 처음 접하는 사람을 위한 시작점이다. 상세 설계를 모두 읽지 않아도 왜 나누는지, 어디까지 구현됐는지, 다음 작업이 무엇인지를 먼저 파악할 수 있도록 정리한다.
30초 요약
기존에는 앱 요청, 상태, 정책, 작업 순서, 실제 기기 실행이 DeviceAgent 주변에
집중돼 있었다. 목표는 이를 다음 세 경계로 나누는 것이다.
| 경계 | 역할 | 대표 구성요소 |
|---|---|---|
| 앱 호출 창구 | 앱이 타입이 정해진 API로 기능을 요청하고 상태를 조회 | Skix*Manager |
| 제품 프레임워크 | 상태·정책·자원·Task 생명주기와 도메인 서비스를 관리 | *ManagerService |
| 기기 실행 | 기존 Agent·ROS 2·MCU·HAL이 실제 센서와 구동부를 제어 | provider adapter |
핵심은 DeviceAgent를 이름만 바꾸는 것이 아니다. AMR, Cleaning, AirQuality,
Power, Vision, IoT, LLM, UI 같은 큰 도메인은 각각 Manager / ManagerService를 갖고, 공통 상태와
정책·Task만 프레임워크 서비스가 조정한다.
- 이 그림이 답하는 질문: DeviceAgent 중심 구조가 무엇으로 바뀌는가?
- 읽는 순서: 왼쪽 현재→가운데 책임 분리→오른쪽 목표 순서로 읽는다.
- 현재 검증 범위: 구조와 JVM 계약 기준이며 AOSP 제품 포함·실기기 완료는 아니다.
실제 작업 폴더는 어디인가
- 이 그림이 답하는 질문: 실행 APK, 프레임워크 골격, MR6 이식 원본과 MR7 통합 작업장은 어디인가?
- 읽는 순서: 위쪽 MR7의
apps/와skix-framework/base/를 먼저 보고, 아래쪽 MR6 원본과 MR7 통합 브랜치를 본다. - 현재 검증 범위: 저장소·브랜치 배치 기준이며 실제 AOSP product 포함 위치 검증은 별도다.
전체 process·partition·24개 ManagerService와 Agent/ROS 2/HAL 연결은 SKIX 로보틱스 프레임워크 전체 구조 Atlas에서 본다.
한 요청이 처리되는 방식
예를 들어 “이동을 시작해줘”라는 요청은 다음 순서로 처리한다.
- 앱이
SkixAmrManager의 typed API를 호출한다. - Binder 진입점이 호출자 권한과 입력값을 확인한다.
TaskManagerService가 Task ID와 실행 생명주기를 만든다.StateManagerService가 현재 기기 상태와 관측 최신성을 제공한다.- Policy/Resource 계층이 안전 규칙과 공유 자원 충돌을 판정한다.
AmrManagerService가 Agent/HAL provider에 실제 명령을 위임한다.- provider가 관측값과 완료 근거를 다시 올린다.
- Evidence가 실제 완료를 확인하면 Task가 최종 상태로 전이된다.
따라서 명령을 접수한 것, 상태가 바뀐 것, 물리 동작이 끝난 것은 서로 다른 사건이다. 이 구분이 Workflow 수정·취소·재계획과 정책 충돌 설명의 기반이 된다.
지금 어디까지 왔나
2026-09-06 refactor/blueprint-foundation 기준이다.
| 구분 | 현재 상태 | 무엇이 확인됐나 |
|---|---|---|
| AOSP형 소스 트리 | 구현·정적 검증 | skix-framework/base/core, services, adapters, compatibility 경계 |
| 공개 Manager와 도메인 서비스 골격 | 구현·정적 검증 | Power를 포함한 15개 제품 도메인을 공통 서비스 하나로 합치지 않고 분리 |
| 서비스 lifecycle | JVM 검증 | dependency order, boot phase, health, 실패 rollback, shared lifecycle affinity |
| Task Core | JVM 검증 | 접수, queue, 상태 전이, 취소 의도, bounded history |
| Policy 기반 | JVM 검증 | 도메인 요구사항과 충돌 판정의 첫 slice |
| State Projection | JVM 검증 | typed key, source/time/freshness, 순서 검증, immutable snapshot |
| IoT Connectivity 관측 adapter | JVM 검증 | MR6 AWS callback을 CONNECTED/DISCONNECTED, source, 5분 TTL의 typed record로 변환 |
| AMR StationLocation 관측 adapter | JVM 검증 | MR6 station evidence subset, source, 10분 TTL과 fingerprint dedup을 typed record로 변환 |
| LLM Pipeline 관측 adapter | JVM 검증 | MR6 status 0..12를 content-free typed 상태와 60초 TTL로 변환; unknown 억제 |
| AirQuality 관측 adapter | JVM 검증 | 측정 문자열과 warming_up/ready/invalid, 60초 TTL을 보존 |
| Power/Battery 관측 adapter | JVM 검증 | Battery를 System에서 분리하고 percent·low·charging·raw capacity와 5분 TTL을 투영 |
| Power 공개 API | SDK JVM 검증 | SkixPowerManager, SkixDeviceManagers.power() 추가; 기존 Manage battery API는 forwarding 호환 유지 |
| Runtime composition | JVM·APK 빌드 검증 | Runtime/Health + State 최소 구성 |
| Root Binder admission core | 구현·JVM 검증 | service/API/24개 Manager ID와 identity·scope·lifecycle fail-closed 판정. Android Binder adapter는 후속 |
| Manager endpoint registry | 구현·JVM 검증 | known ID만 등록, duplicate/null/late mutation 차단, publish 후 immutable snapshot; IBinder 연결은 후속 |
| versioned root AIDL | 구현·SDK 검증 | version·Manager discovery·typed Binder lookup만 노출. Android Stub은 후속 |
| Bundle 계약 상수화 | 정적 검증 | 도메인 wire 문자열을 Constants로 이동 중 |
| MR6 observation 연결 | adapter 구현 | 5개 typed 변환은 완료. 실제 DeviceAgent producer/Binder dual-publish 연결은 아직 미구현 |
| Binder·SystemServer·제품 패키징 | 기반 일부 구현 | AIDL·transport-free admission은 구현. Android identity adapter, publish, SELinux, product makefile 연결 필요 |
| 실기기 동작 | 미검증 | 부팅, process death, 센서·모터 완료, OTA/rollback 증거 없음 |
여기서 JVM 검증은 코드 계약을 확인했다는 뜻이다. AOSP 이미지에 포함되거나
실제 로봇이 움직였다는 뜻은 아니다.
바로 다음 차례
다음 증분은 Android caller evidence adapter + Root Binder Stub + 명시적 Manager Binder registry 조립이다.
Binder calling UID
-> UID/package/user/permission/signature 검증
-> 구현된 FrameworkAdmissionController
-> 명시적 Manager ID registry
-> 검증된 Manager Binder 반환 또는 fail-closed denial
service 이름, API version 1, 24개 Manager ID, versioned root AIDL과 identity·scope·lifecycle admission core는 구현하고 JVM 검증했다. 아직 Android UID와 package의 실제 소유 관계, signature permission, Binder Stub, SystemServer publish가 연결되지 않았으므로 제품 Binder 구현 완료로 부르지 않는다. 상세 경계는 Root Binder Admission Core에서 본다.
이 cross-process seam이 생긴 다음 Connectivity(b579a36), StationLocation(68380e8),
LLM(e9a0d6d), AirQuality(4952948), Power/Battery(5fbf2e4) producer를
StateManagerService로 dual-publish한다. 기존 경로는 유지하고 값, source, timestamp,
TTL, 중복 제거 결과의 shadow parity가 확인된 뒤에만 writer 소유권을 전환한다.
주의할 점도 명시했다. MR6 StationLocation fingerprint는 station_area_id를
포함하지 않는다. 현재 adapter는 이 동작을 호환성 테스트로 보존했으며, ID만
변경된 경우도 새 관측으로 볼지는 shadow 결과를 근거로 별도 결정한다.
그 다음 순서는 SystemServer/runtime bind·death 복구 → producer dual-publish → Evidence → Policy/Resource 보강 → Workflow/Scheduler → 첫 AMR vertical slice → AOSP·실기기 검증이다.
용어를 쉽게 구분하기
| 용어 | 쉬운 뜻 | 주의할 점 |
|---|---|---|
Manager |
앱이 사용하는 호출 창구 | 실제 상태와 하드웨어를 소유하지 않음 |
ManagerService |
제품 기능의 규칙과 상태를 소유하는 실행 서비스 | 모든 도메인을 한 서비스에 몰지 않음 |
State |
현재 관측된 사실의 최신본 | 성공·실패를 단독으로 증명하지 않음 |
Policy |
지금 이 요청을 해도 되는지 판단 | 실제 명령을 실행하지 않음 |
Task |
요청 한 건의 접수부터 종료까지의 기록 | 물리 완료 근거 없이 성공 처리하지 않음 |
Workflow |
여러 Task의 순서와 조건 | 각 Task의 실제 실행은 도메인 서비스에 위임 |
Evidence |
실제 결과를 확인하는 근거 | 단순 callback 수신과 구분 |
Agent/provider |
센서·모터·외부 플랫폼과 연결하는 실행 어댑터 | 전체 정책이나 Workflow를 결정하지 않음 |
무엇을 읽으면 되나
| 알고 싶은 내용 | 문서 |
|---|---|
| 실제 진행률과 검증 결과 | 리팩터링 진행 현황 |
| 전체 목표 구조와 설계 이유 | 제품 프레임워크 Blueprint |
| 앱부터 ROS 2·HAL까지 전체 구조 | 전체 구조 Atlas |
| 현재 Runtime에 실제 구성된 서비스 | Runtime Composition |
| root Binder 요청이 서비스에 들어가기 전의 검사 | Root Binder Admission Core |
| 상태 저장 방식과 MR6 이식 경계 | StateManager Projection |
| 전체 Manager/Service/Agent 목록 | 전체 서비스 맵 |
| MR6 TaskManager 분석과 MR7 통합 판단 | DeviceAgent·TaskManager Convergence |
완료라고 부를 수 있는 시점
기능 하나는 다음 단계를 각각 통과해야 완료로 본다.
설계 확정
-> 소스 구현
-> 단위/정적 검증
-> APK/AOSP 제품 빌드
-> Binder·권한·재시작 검증
-> 실제 센서·구동부 완료 증거
-> OTA·rollback 검증
현재는 기반 코드의 소스 구현과 JVM/정적 검증이 진행된 단계다. 문서에서는
설계, 구현, JVM 검증, 제품 빌드, 실기기 검증을 계속 분리해 표시한다.