SKIX 서비스 아키텍처 폴더 런타임 지도 (2026-09-12)
packages-mr7-refacto 에 맞춰서, 폴더 기준으로 “어디가 어떤 책임인지” 한눈에 보는 지도입니다.
바로 보는 방법 (3줄)
core는 앱이 사용하는 Manager와 통신 계약,services는 요청을 처리하는 서비스 코드입니다.services/core/.../control은 공통 상태·정책·자원 관리,execution은 작업·워크플로·실행 근거를 담당합니다.domain은 제품 기능별 상태와 실행을 소유합니다. 실제 제품 연결 여부는 별도의 구현 상태 구조도에서 확인합니다.
용어를 먼저 잡아두기
- 시스템 시작과 접근 권한
- 한 줄 요약: 시스템이 켜질 때 누가 누구를 붙이고 누가 부를 수 있는지 정하는 면
- 포함 폴더:
services/systemserver,data/etc. 현재 SystemServer 쪽은 경계 설명만 있으며 구체적인 시작 서비스는 미구현입니다. - 프레임워크 공통 실행
- 한 줄 요약: App 요청의 유효성, Task/State/Evidence/Policy/Resource를 공통 규칙으로 관리하는 면
- 포함 폴더:
core/java,core/aidl,services/core/.../control,services/core/.../execution,services/core/.../runtime - 제품 기능별 서비스
- 한 줄 요약: AMR/청소/비전/LLM 같은 각 기능의 상태·정책·실행 수명을 소유
- 포함 폴더:
services/core/.../domain - 기존 Agent와 장치 연결
- 한 줄 요약: 기존 Agent/ROS2/MCU/HAL로 최종 동작을 전달하는 면
- 포함 폴더:
adapters,compatibility
폴더별 한 줄 책임 지도
| 폴더/구간 | 핵심 책임 | 확인 포인트 |
|---|---|---|
skix-framework/base/core/java |
앱용 Manager API와 Java 모델 | 호출 계약과 SDK 호환성 |
skix-framework/base/core/aidl |
프로세스 사이 Binder 통신 계약 | 인터페이스 변경 영향 범위 |
services/core/.../control |
공통 제어 계층 (상태·정책·자원·Capability·Lifecycle) | 런타임 정책/자원 충돌 차단 |
services/core/.../execution/task |
공통 Task owner (submit/queue/claim/cancel/timeout) | 도메인에서 직접 Task 상태 쓰지 않음 |
services/core/.../execution/task/completion |
완료 관측과 Task 최종 상태 연동 | 증거 기반으로만 terminal 갱신 |
services/core/.../domain |
도메인 owner/상태/adapter 규칙 | AMR, Cleaning, Vision, LLM, IOT ... |
services/core/.../domain/*/execution |
공통 Task 실행권으로 장치 동작을 수행 | AMR 실행기, Cleaning 정지 계약; Vision은 session, LLM 배정기는 미완 작업본 |
services/core/.../runtime |
서비스 구성과 시작·정지 순서 | 순수 Java 조립 코드 |
services/runtime/java |
Android Service 및 Binder 호스트 | SkixFrameworkHostService와 Android 호출자 확인 |
services/systemserver |
향후 AOSP 시작·접근 권한 연결 경계 | 현재 README만 존재, 제품 통합 미완 |
adapters |
기존 공급자 경로(Agent/ROS2/MCU/HAL) | 운영 전환 시 동시 호출/시퀀스 보장 |
compatibility |
legacy 번들/옛 API 연동 경계 | 새로운 runtime owner 분리 전환 도우미 |
오늘 기준 핵심 오해를 바로잡기
- TaskManagerService는 도메인 Service가 아니다.
- 공통 실행권(큐/취소/상태/타임아웃)만 가진다.
- AMR/Cleaning/Vision/LLM는 각각 자기 owner로 동작 정책과 실행 수명을 다룬다.
- 같은 APK 안에 같이 있어도 책임은 다르다.
- Process 공유는 단지 배포 단위일 뿐이고, owner는 클래스/서비스 단위로 나뉜다.
- 완성 표시(색)는 ‘제품 동작 완료’가 아니라 ‘범위 내 검증 상태’다.
- 파란색/주황색이라도 실기기 부팅/공급자 이관까지 완료된 뜻은 아니다.
“TaskManager는 도메인인가?” 바로 정리
아니요.
- TaskManagerService는
execution/task에 있는 공통 실행권 관리자입니다. - DomainManagerService(AMR, Cleaning, LLM, Vision …)는 어떤 동작을 실제로 수행할지/상태를 소유합니다.
- 즉
TaskManagerService는요청을 받아 큐에 넣고 진행·취소·결과 전환을 담당하고, 각 도메인은도메인 상태 + 실행 제약 + 완료 수명을 담당합니다.
2026-09-12 기준 구현 범위
아래는 폴더별 경계 요약입니다. 검증 날짜와 범위는 진행 현황을 기준으로 봅니다. 이 문서 초안의 “완전 검증”, “AOSP core runtime 완료/안정” 표기는 근거보다 넓어 정정했습니다. 내부 테스트 통과는 도메인 전체 이관이나 제품 부팅 완료를 뜻하지 않습니다.
바로 보는 상태표 (폴더 단위)
| 경로 | 현재 상태 | 다음 핵심 마일스톤 |
|---|---|---|
services/core/.../execution/task |
접수·실행권·취소 내부 구현 | 제품 공급자·정책 연동 |
services/core/.../execution/task/completion |
완료 관측 내부 구현 | 외부 관측을 실제 Task와 연결 |
services/core/.../domain/amr + domain/amr/execution |
이동 실행·중단 내부 검증 범위 존재 | 공급자 실기기 연결 |
services/core/.../domain/cleaning + domain/cleaning/handoff |
부분 | cleaning 실행 수명 전체 이관 |
services/core/.../domain/vision + domain/vision/session |
부분 | broker/provider/앱 호출 경로 연결 |
services/core/.../domain/llm + domain/llm/execution |
완료 관측 일부 구현, 배정기 작업본 미완 | AI Agent 재생 요청·완료 연결 검증 |
services/core/.../domain/airquality |
부분 | 실시간 관측 producer 연결 |
services/core/.../domain/power |
부분 | 권한 동작/장애 전환 이관 |
나머지 domain/* |
골격 | 공통 수명/회복/완료 시나리오 이식 |
코드에서 확인하는 의존 방향
domain/* → execution/task → control/* 방향으로 공통 기능을 사용합니다.
공통 실행 계층에서 특정 domain/* 구현을 import하면
tools/verify-skix-layer-boundaries.sh가 실패하도록 보강했습니다.
이 검사는 Java/Kotlin import 경계에 대한 정적 검사이며, 동시 접근이나 실기기 정책 충돌 자체를 증명하는 검사는 아닙니다.
Connections
- 전체 구조를 먼저 보려면: 구조 Atlas
- 진행률 최신판: 구현 현황
- Domain 서비스 성숙도: ManagerService 성숙도
- AOSP 시작/Runtime 연결: 시작 서비스, Runtime 조립