← Docs hub

SKIX 로보틱스 프레임워크 전체 구조 Atlas

처음 읽는 순서: 이 페이지에서 전체 구성 확인 → 폴더별 역할과 상태 책임 → 요청·실행·결과 흐름의 실제 사례 → 구현 진행 현황. 영문 클래스 이름은 소스를 찾기 위해 유지하고, 무엇을 하는지는 한국어 역할 설명으로 읽으면 된다.

실행 구현과 프레임워크의 차이: AI Agent·LLM 도메인·TaskManager 관계 해설과 확대 구조도. 아래 폴더 구조 지도를 함께 보면, TaskManager가 왜 상단 실행권(공통)이고 AMR/Cleaning/Llm/Vision이 왜 별도 도메인인지(기능 소유권 기준) 빠르게 확인됩니다. 아래 전체 구조는 유지하며, TTS 사례의 실제 실행 주체와 미구현 연결을 별도로 설명한다.

공통 작업 관리와 도메인 실행의 폴더 경계

TaskManager는 AMR·Cleaning보다 넓은 공통 작업 관리 책임이다. 폴더의 물리적 부모가 아니라 모든 도메인이 사용하는 실행권·Task 상태의 공통 소유자라는 뜻이다.

Task 상태·실행 배정은 공통 실행 계층, 장치 명령·도메인 상태·정지 절차는 각 도메인에 둔다. 현재 AMR–Cleaning 직접 협력은 유지되며, 폴더 분리가 범용 도메인 조정자 구현을 의미하지 않는다. 클래스명·공개 계약·동작은 유지하고 내부 package/import와 대응 테스트 경로를 함께 옮긴다.

전체 모듈과 역할을 먼저 보기

먼저 AOSP Plane부터 읽기

SKIX는 먼저 Android가 기기를 올리는 계층을 먼저 보면 빠르게 이해됩니다.

• AOSP Trust / Boot Plane: services/systemserver, services/runtime/java, data/etc
• 기기 부팅 시 프레임워크를 넣을 수 있는 틀(등록, 기동, 접근 제한, SELinux 준비)을 담당합니다.
• Framework Core Plane: core/*, services/core/{runtime,entrypoint,control,execution}
• Manager/ManagerService 인터페이스, Task/State/Policy/Resource/Capability 같은 공통 제어를 담당합니다.
• Domain Plane: services/core/domain/*
• AMR, Cleaning, LLM, Vision, IoT 등 기능별 책임자입니다.
• Provider Plane: adapters, compatibility
• 기존 DeviceAgent/ROS2/MCU/HAL로 내려가는 실제 실행과의 연결 경계입니다.

한 번에 보려면:
서비스 호출(Manager) → Task 배정 → 도메인 실행기 → 상태/완료 반영
순서로 읽으시면 됩니다.
이 순서에서 Task가 실행을 직접 하지 않는 이유는 정책/자원/취소의 단일 소유자와 실행 도메인의 책임 분리를 유지하기 위해서입니다.

상태 기준은 아래 폴더 역할 지도에서 한 번에 확인하세요.
[폴더 모듈 지도(대형)](skix-folder-module-role-map-2026-09-08.html).

전체 구조를 한 가지 요청으로 이해하기

예를 들어 “주방으로 이동하면서 안내해 줘”라는 요청에는 주행과 음성이라는 서로 다른 기능이 있다. 상위 앱·서비스가 요청을 구성하고, 프레임워크는 각 기능의 실행 조건과 작업 상태를 관리한다. 목표 구조에서는 AMR 도메인이 주행 구현에, LLM 도메인이 AI Agent에 연결한다. LLM이 주행까지 직접 관리하거나, TaskManager 안에 모든 기능 코드를 넣는 구조가 아니다.

이 표는 목표 흐름의 설명이다. 현재 MR7에서 이 요청 전체가 새 경로로 실행된다는 뜻은 아니다. 조건부 재개·동시 실행·취소는 정책과 자원 계약에 따라 조정하며, 위 예시가 동시 실행 허용 사양을 새로 정하지 않는다.

지금 진행률을 읽는 기준: 분리, 연결, 제품 검증

현재는 “내부 책임 분리”가 진행된 상태이며 “제품 실행 전환”까지 완료된 상태는 아니다. 클래스 수나 테스트 수 하나로 전체 이식률을 표시하지 않는 이유다.

MR6 task_manager 브랜치는 계속 이식 원본이다. MR7에 같은 이름의 클래스나 옵션이 있다고 MR6 실행 동작까지 이식된 것은 아니다. 구체적인 차이는 TaskManager가 지금 하는 일과 남은 이식을 읽으면 된다.

이 문서 묶음에서 무엇을 보면 되는가

현재 위치를 한 문장으로: 프레임워크 소스의 폴더와 내부 관리 코드는 분리하고 있지만, 기존 앱의 모든 제품 동작이 새 서비스로 전환된 단계는 아니다. 아래 상세 SVG는 전체 목표와 내부 구성요소를 보존한 지도다. 상자가 있다는 것과 제품에서 연결되어 돈다는 것을 구별한다.

최근 실제 폴더 경계 수정: 도메인별 통신 계약과 DeviceAgent 빌드 범위. LLM 처리기의 통신 이름은 도메인별 공용 Constants를 참조하고, DeviceAgent는 그 계약 폴더만 컴파일한다. 이는 소스 의존성 분리이며, 기존 청소·잠금·주행 정책이 모두 새 서비스로 옮겨졌다는 뜻은 아니다.

<a id="runtime-wiring-status"></a>

폴더가 실제 서비스로 실행되기까지

2026-09-09 현재: 내부 관리 코드는 있으나 Android 서비스 기동 연결은 아직 없다. 폴더 지도와 아래 상세 SVG는 유지한다. 다만 코드의 책임 구조와 부팅된 제품의 실행 상태를 구분해야 한다.

표의 …는 서버 Java 패키지 com/sk/airbot/frameworkservice 이하 경로를 줄인 것이다. base/Android.bp도 현재 filegroup이며, 제품에 설치할 APK·systemserver jar 모듈을 완성한 상태가 아니다. 기존 DeviceAgent를 삭제하거나 모든 기능을 새 서비스로 넘긴 것은 아니다.

부팅 설계도 바로잡았다. 로컬 QSSI의 SystemServer.java는 phase 500 이후에 config_deviceSpecificSystemServices의 서비스를 만든다. 이미 지나간 phase는 다시 보내지 않으므로, 이 경로의 SKIX 서비스가 500에서 초기화·bind한다는 이전 설명은 맞지 않는다. 정정한 목표 순서는 생성 직후 onStart() 초기화 → 520 제품별 준비 → 600 Runtime 연결 → 준비 조건 확인 후 READY다. 아직 이 순서대로 SKIX가 실기기 부팅됐다는 의미는 아니다.

근거: MR7 70bf49c, docs/refactor/skix-runtime-host-wiring-audit-2026-09-09.md; 로컬 QSSI frameworks/base/services/java/com/android/server/SystemServer.java의 2697·2776·2803·2975행과 frameworks/base/services/core/java/com/android/server/SystemServiceManager.java의 서비스 등록·부팅 단계 전달 구현. 제품 include 후보는 확인했지만 실제 MR7 lunch 대상·설치·SELinux·부팅 검증은 남아 있다.

폴더 기준 전체 런타임 지도

폴더 기준으로 전체 책임을 한 번에 보려면 여기로 이동합니다.

• 서비스 아키텍처 폴더 런타임 지도 (2026-09-12)
• 도메인별 성숙도 요약

아래 다섯 영역 표는 이 목표 구조의 책임 지도이며, 위 표는 현재 연결 상태다.

먼저 다섯 영역으로 나누어 읽기

아래는 목표 책임 구조다. 표의 한 행을 하나의 APK로 만드는 것은 아니며, 실제 연결 완료 여부는 뒤의 구현 범례로 확인한다.

여기서 base/는 저장소 최상위의 skix-framework/base/다. apps/에 있는 빌드 프로젝트와 실제 실행 앱을 모두 없애는 것이 아니라, 재사용할 프레임워크 소스의 주인을 base/로 옮기는 것이다. systemserver/의 시작 연결과 격리 Runtime 호스트는 제품 통합 후속이며, 폴더가 있다는 이유로 부팅 연결이 끝난 것은 아니다.

그림 속 영문은 다음처럼 읽으면 된다. AOSP Trust / Boot Plane은 “Android 부팅·권한 확인 영역”, Runtime은 “서비스들을 함께 시작하고 종료하는 실행 기반”, Provider는 “실제 기능을 실행하는 구현”, Evidence는 “수행 중에 수집한 관측·결과 근거”다. 별개의 새 제품 이름이 아니다.

그림을 읽을 때 따라갈 질문

1. 누가 요청하는가? 위쪽 앱·상위 서비스에서 SDK Manager로 들어온다.
2. 누가 판단하고 관리하는가? 공통 서비스가 정책·자원·작업을, 도메인 서비스가 자기 기능을 맡는다.
3. 누가 실제로 실행하는가? 아래쪽 Agent·ROS 2·MCU·HAL 등 연결된 구현이 실행한다.
4. 어떤 결과가 돌아오는가? 실행별 진행·종료 관측이 Task·State·Evidence에 반영되는 경로를 읽는다.
5. 지금 어디까지 연결됐는가? 기본 조립 7개, 선택 내부 구현, 실제 장치 연결 후속을 구분한다.

TTS라면 AI Agent가 실제 합성·재생, LLM 도메인이 실행 연동, Task가 해당 요청의 진행·결과 관리를 맡는다. 이 세 역할을 구분하는 것이 핵심이지, TTS 기능을 AI Agent에서 떼어내겠다는 뜻은 아니다.

폴더 기준으로 읽기: base/ 폴더 → 포함 모듈 → 담당 역할 SVG. 소스 소유 구조를 먼저 보고 아래 역할 지도와 모듈별 설명을 함께 읽는다.

위쪽 공통 모듈 9개는 상태·판단·작업을 관리하고, 가운데 제품 도메인 15개는 각 기능을 책임지며, 아래 실행 구현은 실제 장치를 움직인다. 각 상자에는 모듈 이름뿐 아니라 입력과 결과, 담당 역할을 적었다.

모듈 역할 지도 크게 열기 · Mermaid 원본

각 모듈이 정확히 무엇을 하는지: 모듈 역할 사전과 실제 소스 위치. 공통 기반 10개(Runtime 포함), 제품 도메인 15개, SDK·Binder·기존 Agent 연결부를 담당 업무 / 협력 대상 / 실제 폴더 / 구현 범위로 정리했다. 주행 요청 하나를 따라가는 설명도 함께 읽을 수 있다.

예를 들어 주행 요청은 Task가 작업으로 관리 → Policy가 허용 조건 판단 → Resource가 자원 사용 조정 → AMR이 주행 기능을 책임지고 provider에 실행 요청 → State가 현재 상태, Evidence가 수행 근거를 제공하는 방향이다. 상위 지능 서비스는 이 정보를 보고 계획을 수정한다. 이는 목표 협력 흐름이며 모든 연결이 완료된 것은 아니다.

여기서 모듈은 논리적 책임 단위다. 24개 APK나 24개 프로세스를 만든다는 뜻은 아니다. 현재 기본 실행 구성은 Runtime + State + Evidence + Policy + Resource + Capability + Task다. 자원·기능·작업 Runtime 상세에서 7개 실제 서비스와 상태 흐름을 확대한다. 그림에 표시한 소스 존재·골격·장치 통합 미완료를 구분해서 읽는다. Evidence의 관측 저장 이식 범위와 남은 연결을 별도 정리했다.

구성요소를 구체적으로 보려면: 전체 계층·15개 도메인·폴더와 구동 위치 상세 구조도. 각 서비스의 한국어 역할, 실제 소유 경로, 구현과 목표 결선의 차이를 세 장으로 펼쳤다.

계층별 상세로 나누기 전에 전체를 한 화면에서 보려면 SKIX 로보틱스 프레임워크 통합 전체 구조를 먼저 연다.

이 페이지가 전체 리팩터링의 첫 구조도다. 상세 페이지를 읽기 전에 앱에서 물리 장치까지의 레이어, process/partition, 24개 Manager owner, ROS 2 연계, 현재 구현과 후속 작업을 한 번에 본다.

이 문서가 다루는 범위

이 Atlas는 문서 메뉴가 아니라 Launcher/상위 지능 서비스에서 실제 구동부까지 이어지는 전체 topology다. 위에서 아래로는 요청과 명령, 아래에서 위로는 상태·Feedback·Evidence가 이동한다. 같은 Runtime process에 배치되더라도 공개 Manager, Binder 계약, ManagerService, provider는 다른 책임이다.

한 문장 구조

SKIX는 AOSP의 부팅·권한·Binder·프로세스 복구 위에서 상태, Capability, Policy, Resource, Task, Workflow, Evidence와 제품 도메인 실행을 관리하고, 기존 Agent·ROS 2·MCU·HAL을 물리 실행 provider로 연결하는 제품 로보틱스 프레임워크다.

전체 크기 SVG 열기

• 이 그림이 답하는 질문: 요청·권한·판단·도메인 소유권·물리 실행과 결과 환류가 어느 계층과 프로세스에 놓이는가?
• 읽는 순서: 위에서 아래로 요청을 따라간 뒤, 녹색 점선을 따라 상태와 완료 근거가 돌아오는 경로를 읽는다.
• 현재 검증 범위: 문서·JVM 계약과 구현 골격을 기준으로 한 안내 지도다. AOSP 제품 포함과 실기기 동작 완료를 뜻하지 않는다.

전체 동작 구조

전체 동작 SVG 열기

App/상위 지능 서비스 -> Skix*Manager -> Root Binder(admit) -> Task/Workflow(submit)
 -> Policy/Resource(resolve) -> Domain ManagerService(dispatch)
 -> Agent/ROS2/HAL -> feedback/observation/completion
 -> State/Evidence(project) -> subscriber/상위 지능 서비스(replan)

accepted != physically completed다. 요청 접수는 물리 완료가 아니다. 실행별 결과 근거를 확인해 Task를 종료하더라도 그 결과에는 성공·실패·취소가 포함될 수 있다. Task 종료, 실제 장치 동작 완료, 자원 재사용 가능 여부는 별도로 확인한다. 예를 들어 TTS Task가 종료돼도 그 사실만으로 스피커 출력이나 재생 정지를 직접 검증한 것은 아니다.

공식 Android/AOSP 설계 기준

외부 그림 자체를 복제하지 않고 Android 공식 문서가 계층과 경계를 나누는 방식을 적용했다.

로컬 Android 13 QSSI에서는 SystemServer.java의 startBootstrapServices, startCoreServices, startOtherServices와 SystemService.java의 publishBinderService를 부팅·등록 골격의 근거로 확인했다. 현재 MR7은 이 구조를 목표로 한 골격이며 SkixFrameworkSystemService의 AOSP 제품 포함 전, SELinux 적용 전, 실기기 미검증 상태다.

어디를 보면 되는가

구현·검증 상태 범례

초록은 자동 검증된 source, 파랑은 일부 구현, 주황은 연결 전 목표, 보라는 legacy, 회색은 외부 provider다. JVM 통과를 AOSP 제품 포함이나 실기기 완료로 해석하지 않는다.

전체 호출과 소유권

App / 상위 지능 서비스 experience planner
  -> typed Skix*Manager SDK
  -> AOSP root Binder + caller admission
  -> isolated SKIX Runtime
     -> Control: Health / State / Evidence / Policy / Resource / Capability
     -> Execution: Task / Workflow / Scheduler
     -> Product: AMR / IoT / LLM / MCU / Vision / Update / Pairing / EventAsset /
                 Cleaning / AirQuality / Power / UI / System / Diagnostics / Security
  -> provider adapter
  -> Agent / ROS 2 action-service-topic / MCU / HAL
  -> observation + feedback + completion evidence
  -> State / Evidence / Task lifecycle

Manager는 클라이언트 API이고 동일 이름의 ManagerService가 최종 상태와 도메인 규칙을 소유한다. TaskManagerService는 장기 명령의 접수·queue·cancel·timeout·terminal lifecycle을, WorkflowManagerService는 단계와 보상 흐름을 소유한다. 실제 모터·센서 제어는 provider가 수행하며 접수 성공 ≠ 물리 완료다.

Runtime 내부는 Control Plane, Execution Plane, Product Domain Plane으로 나뉜다.

AOSP와 Runtime 배치

무거운 로보틱스 실행을 system_server에 넣지 않는다. system_server가 Android 신뢰 경계와 부팅을 소유하고, 격리 Runtime이 로보틱스 상태·정책·Task를 소유하는 하이브리드다.

ROS 2 관념을 SKIX에 적용하는 방법

SKIX는 ROS graph 자체가 아니다. ROS 2는 provider 중 하나이며 제품 권한·사용자·앱 lifecycle과 OTA 경계는 AOSP가 담당한다. 상위 지능 서비스의 Experience reasoning은 Framework 밖에서 계획을 만들고 수정할 수 있지만, Framework는 현재 상태와 evidence를 제공하고 안전 policy 위반은 이유와 함께 거부한다.

24개 Manager와 Runtime owner

Cleaning·AirQuality·UI·Power는 같은 Runtime process에 있을 수 있어도 같은 서비스가 아니다. 각자 상태 machine과 owner를 가지며 프로세스 공유는 배포 단위일 뿐 책임 통합을 뜻하지 않는다.

현재 구현 판정

다음 구현 순서

1. product package/user별 ManagerScopePolicy grant 구성
2. 24 concrete ManagerEndpointRegistry<IBinder> 조립
3. root Binder publication과 SkixFrameworkSystemService boot phase 및 Runtime bind/death/generation 복구
4. MR6 다섯 producer의 State dual-publish와 shadow parity
5. Evidence/Capability/Resource managed services
6. MR6 TaskManager persistence·timeout·recovery 선택 이식
7. AMR와 Cleaning action-like vertical slice: feedback/cancel/completion evidence
8. IoT·LLM·Vision·MCU 등 provider 확장
9. SELinux/product makefile/signed image/실기기 Gate

상세 구조도 모음

• Framework SVG 전체 95개 감사표
• 전체 Manager / ManagerService / Agent 맵
• SystemServer·Runtime source/process/partition
• Runtime Composition과 lifecycle
• Root Binder admission
• State projection과 MR6 observation 이식
• Task / Execution
• Product Domain Services
• Domain Policy 사양
• Bundle wire contract

코드 근거

• skix-framework/base/core/java/com/sk/airbot/framework/SkixFrameworkContract.java
• skix-framework/base/services/core/java/com/sk/airbot/frameworkservice/server/entrypoint
• skix-framework/base/services/core/java/com/sk/airbot/frameworkservice/server/control
• skix-framework/base/services/core/java/com/sk/airbot/frameworkservice/server/execution
• skix-framework/base/services/core/java/com/sk/airbot/frameworkservice/server/domain
• skix-framework/base/services/core/java/com/sk/airbot/frameworkservice/server/runtime/SkixFrameworkCompositionRoot.java
• apps/DeviceAgent/app/src/main/java/com/sk/airbot/deviceagent
• local AOSP frameworks/base/core/java/com/android/server/SystemService.java

Connections

• 리팩터링 한눈에 보기
• 리팩터링 진행 현황
• 제품 프레임워크 Blueprint
• Framework/SDK 문서 허브