SKIX Framework 폴더 구조와 진행도
실제 skix-framework/base/를 기준으로 어디를 수정하고 있으며, 그 폴더가 어느 단계까지 구현됐는지 설명한다. 기준은 refactor/blueprint-foundation, 963c62a + 확인한 미커밋 소스다. 디렉터리·클래스 존재는 기능 완료가 아니다.
전체 현황 · 하위 작업별 WBS · 폴더 데이터 · 편집용 구조도
진행도를 읽는 기준
| 단계 | 의미 |
|---|---|
| 구조 정의 | 역할·패키지·계약 경계가 존재. README만 있는 폴더도 여기에 해당 |
| 내부 동작 | 실제 동작 코드·내부 계약 구현. 전체 기능 완성이나 제품 적용을 뜻하지 않음 |
| 제품 연결 | Android host·기존 DeviceAgent 경로 연결. 일부 producer 연결을 전체 provider 완료로 확대하지 않음 |
| 실기기 인수 | 실제 Binder·센서·물리 동작·재부팅 증거. 현재 모두 미검증 |
확인 / 일부 / —는 단계별 증거 표시이며 등간격 점수나 백분율이 아니다. 전체 완료율은 미산정이다. 소스 수는 구현 위치를 찾는 보조 정보이며 진척률 계산에 사용하지 않는다.
Blueprint와 현재 구현의 대응
제품 Framework Blueprint의 §3 계층 책임, §5 요청 흐름, §8 이관 단계와 같은 방향이다. 폴더를 나눈 이유는 호출 위치뿐 아니라 상태·권한·실행 책임을 분리하고 실제 행동을 단계적으로 이관하기 위해서다.
| Blueprint 책임 | 실제 구현 위치 | 현재와 남은 작업 |
|---|---|---|
| 앱의 typed 계약 | core / compatibility | SDK·AIDL 존재, 제품 소비자 이관 계속 |
| 공통 실행 권한·취소·결과 | execution/task | queue·claim·파일 기록 구현, 실행 재조정 남음 |
| 도메인 행동·상태 | domain/amr · domain/cleaning | 이동/청소 실행·인계 구현, 실제 provider 명령·귀속 관측 남음 |
| 공통 판정·자원 | control | lifecycle·capability·resource 구현, 제품 정책과 실제 재관측 연결 남음 |
| 서비스 협력·외부 연결 | integration / adapters | 경계 중심, 기존 DeviceAgent adapter를 검증하면서 이관 |
| 조립과 Android 호스트 | server/runtime · services/runtime | 같은 root 조립·관측 gateway·Task 저장 연결, managed transport 연결 남음 |
| 제품 SystemServer·설정 | systemserver / data/etc | README 경계, AOSP 제품 연결은 후속 |
현재는 Blueprint의 공통 실행 구현과 실제 행동 이관 단계가 병행 중이다. base/adapters로 파일만 옮기거나 services/runtime에 도메인 정책을 넣어 완료로 처리하지 않는다. 새 경로와 legacy 경로가 같은 장치 명령을 중복 발행하지 않는 단일 소유권을 유지한다.
1층 · base 전체 설계 — 사용자가 보는 소스 지도
사용자가 확인한 tree -L 3 배치를 그대로 읽되, 패키지 경로 때문에 가려지는 서비스 책임은 아래 2층에서 확장한다.
skix-framework/base/
├── Android.bp Soong 소스 filegroup; 제품 설치 모듈은 아직 아님
├── README.md 정본 소스 소유권·이관 규칙 안내
├── adapters/ 물리 provider 구현의 최종 이관 위치
│ └── README.md 현재 경계 정의; 실제 adapter는 기존 앱에도 남아 있음
├── api/ 공개 API 변경 이력을 검토할 signature 위치
│ └── README.md typed 계약 안정화 후 signature 생성·검사 도입
├── compatibility/ 기존 호출과 새 계약을 연결하는 호환 계층
│ ├── README.md 유지할 legacy 계약과 번역 경계
│ ├── aidl/com/ 비공개 host 관측 gateway IPC
│ └── java/com/ legacy SDK/IPC 번역·전달 코드
├── core/ 앱이 의존하는 공개 Framework 표면
│ ├── aidl/com/ root discovery·Task 등 공개 Binder 계약
│ ├── java/com/ typed Manager·DTO·클라이언트 계약
│ └── tests/src/ 공개 계약·호환 동작 검사
├── data/
│ └── etc/README.md 제품 권한·sysconfig·설정 파일 배치 예정
├── services/ 서버의 판단·실행·호스트 구현
│ ├── core/java/ Android transport와 분리한 서비스 로직 → 2층
│ ├── runtime/ Android Service·Binder·관측 gateway
│ │ ├── README.md Android 의존 소스와 portable core의 분리 규칙
│ │ └── java/ 실제 host·Stub·caller adapter
│ ├── systemserver/
│ │ └── README.md 얇은 SystemService/부팅 bridge 구현 예정
│ └── tests/
│ ├── instrumentation/ 기기·Android 런타임 테스트 코드; 실행 인수는 후속
│ └── src/ 서비스 상태·권한·실행·저장 JVM 회귀
└── tree.txt 탐색용 스냅샷; 빌드 입력이나 진행도 정본 아님
왜 core와 services/core를 나눴나: 앱은 Manager와 DTO를 사용하고, 서버가 상태·정책·실행 권한을 소유한다. 앱이 서버 내부 클래스를 직접 호출하지 않도록 의존 방향을 고정한다.
왜 services/core와 services/runtime을 나눴나: 도메인 판단과 Task 상태 전이는 JVM에서 검증할 수 있게 유지하고, Binder·Context·PackageManager·Android Service는 런타임 연결부에 둔다. 같은 Java package라도 source root를 나눈 이유가 이것이다.
왜 adapters와 compatibility가 다른가: adapter는 장치/프로세스 기술 계약을 도메인 port로 연결하고, compatibility는 기존 호출자의 계약을 보존한다. 둘 다 Task의 실행권이나 도메인 상태를 별도로 소유하지 않는다. 지금은 adapters가 README 단계이며 기존 DeviceAgent adapter를 검증하면서 이관해야 한다.
왜 systemserver를 비워 두었나: 제품 부팅 bridge는 Runtime을 연결하는 얇은 계층이어야 한다. 제품 module·서명·권한·SELinux·boot phase 계약 없이 파일만 추가해 제품 통합으로 오인하지 않도록 구현을 분리했다. Android.bp의 filegroup은 소스 목록이며 설치 완료 증거가 아니다.
2층 · 서버 내부 설계 — 누가 판단하고 실행하는가
기준 경로: services/core/java/com/sk/airbot/frameworkservice/server/.
server/
├── runtime/ 같은 root 조립·시작·종료·provider gate
├── entrypoint/
│ ├── binder/ transport-free endpoint 계약
│ ├── identity/ caller 신원·접근 판정
│ ├── validation/ 버전·입력·admission 검사
│ └── observation/ 외부 관측 수신·State 전달
├── control/
│ ├── lifecycle/ 구성요소 수명·세대
│ ├── health/ 서비스 건강 상태 조회
│ ├── state/ 관측 순서·세대·신선도
│ ├── capability/ provider 등록·준비 상태
│ ├── policy/ 공통 정책 판정 계약
│ └── resource/ 자원 소유·lease·재관측
├── execution/
│ ├── task/ 공통 owner·queue·claim·취소·기록
│ ├── evidence/ 실행 완료 근거 계약
│ ├── workflow/ 다단계 실행 조합 — 골격
│ └── scheduler/ 예약 계산 — 영속/Alarm 연결 남음
├── domain/ 각 도메인 상태와 행동 → 3층
├── integration/ 서비스 협력·외부 시스템 연결 경계
│ ├── agent/ Agent 협력 경계
│ ├── android/ Android 협력 경계
│ ├── hal/ HAL 연결 경계
│ ├── mcu/ MCU 연결 경계
│ └── task/ Task 협력 경계
└── legacy/ 잔여 호환 코드의 격리 경계
runtime은 서비스를 조립하지만 도메인 정책을 결정하지 않는다. entrypoint는 호출을 검증하지만 청소·이동 절차를 실행하지 않는다. control은 준비 상태와 자원 권한을 관리하고, execution/task는 모든 도메인이 사용하는 공통 실행 수명을 관리한다. domain은 이 공통 실행권으로 자신의 실제 행동을 수행한다. integration의 하위 폴더는 대부분 경계 단계이며 완성된 연결 구현으로 세지 않는다.
3층 · 도메인 내부 — 공통 Task와 실제 장치 행동의 연결
domain/
├── amr/
│ ├── execution/ 이동 접수·dispatch·실행 세션
│ ├── observation/ 원본 관측·실행 귀속
│ ├── completion/ 완료 증거 판정
│ └── state/ AMR 요청 상태·관측 상태
├── cleaning/
│ ├── execution/ 청소 동작·전체 중단 전환 계약
│ ├── handoff/ Cleaning 반환→재관측→AMR 획득
│ └── ... 팬 진단·관측 등 실제 하위 구현
├── iot/ · power/ · airquality/ 관측 callback→State 경로 부분 연결
├── vision/ 내부 카메라 session 구현
├── ui/ · mcu/ · update/ ManagerService 골격 중심
├── pairing/ · eventasset/ ManagerService 골격 중심
├── system/ · diagnostics/ · security/ ManagerService 골격 중심
└── llm/ 기존 코드 보존, 현재 신규 확대 보류
위 3층은 책임을 드러내기 위한 발췌 트리다. 모든 파일을 나열한 출력은 아니며, 상세 현황은 아래 도메인별 표를 따른다. command, interaction, mobility, schedule, wellness 같은 지원 패키지는 독립 Manager 5개가 추가됐다는 의미가 아니다.
이동 요청은 typed 요청 → entrypoint 검사 → AMR 접수 → provider/제품 정책 검사 → 공통 Task queue·claim → 실행 전 재검사·자원 획득 → AMR/Cleaning port → 귀속된 관측 판정 순서로 흐른다. 파일 기록은 execution/task가, Android 파일 위치와 host 수명은 services/runtime이 맡는다. 물리 관측 없이 Task 성공이나 자원 FREE를 추정하지 않는다.
같은 구조를 확인하는 명령
저장소 루트에서 실행한다. 첫 명령은 사용자 화면과 같은 파일 수준, 나머지는 패키지 경로를 건너뛰고 책임별 디렉터리를 보여준다.
tree skix-framework/base -L 3 -I '.git|out|build'
tree skix-framework/base/services/core/java/com/sk/airbot/frameworkservice/server -d -L 2
tree skix-framework/base/services/core/java/com/sk/airbot/frameworkservice/server/domain/amr -d -L 2
tree skix-framework/base/services/runtime/java/com/sk/airbot/frameworkservice/server -d -L 3
README의 과거 날짜 설명과 현재 코드가 다르면 현재 코드를 기준으로 읽는다. 예를 들어 현재 Android host는 LocalHostBinder와 관측 gateway 연결을 사용하며, 과거의 onBind() = null 설명이 최신 동작을 대표하지 않는다. 이는 공개 SystemServer root 서비스가 완성됐다는 뜻은 아니다.
이 트리는 책임을 찾기 위한 축약이다. 서버 접두는 skix-framework/base/services/core/java/com/sk/airbot/frameworkservice/server/이며 그림의 서버·도메인 경로는 이 접두를 생략한다.
01 · 폴더 경계와 Android 제품 연결
| 폴더 · WBS | 현재 상태 | 다음 작업 |
|---|---|---|
core/java · W01 |
부분 구현 | 대표 앱 API 이관과 중복 실행 방지 |
core/aidl · W01 / W11 |
계약·adapter 존재 | 실제 root 서비스 공개·권한·death 인수 |
compatibility · W01 / W03 / W04 |
부분 연결 | 직접 호출 축소와 제품별 호환 검증 |
api · W01 |
README 경계 | typed API 안정화 후 signature 관리 |
adapters · W04 / W05 |
README 경계 | 현재 DeviceAgent adapter의 검증 후 이관 |
services/core · W02–W10 |
부분 구현 | 하위 폴더별 구현·provider 연결 |
services/runtime · W03 / W07 / W11 |
부분 연결 | managed 실행 provider·실제 Binder 인수 |
services/systemserver · W11 |
README 경계 | 제품 module·boot phase·서비스 공개 |
data/etc · W11 |
README 경계 | 제품 포함 경로·SELinux·권한 배치 |
core/tests · W01 |
검증 코드 존재 | 제품 앱과 SDK 호환 인수 |
services/tests · W02–W12 |
JVM 통과 근거 | instrumentation·실기기 인수 실행 |
apps/SkixFrameworkService · W11 / W12 |
APK 빌드 근거 | 제품 서명·설치·부팅 검증 |
02 · services/core 내부 책임과 진행
| 폴더 · WBS | 현재 상태 | 다음 작업 |
|---|---|---|
runtime · W02 / W05 |
내부 구현 | provider 준비 gate 구현, 실제 transport 연결 남음 |
entrypoint · W01 / W03 / W06 |
내부 구현·부분 연결 | 공개 root Binder의 실제 권한 인수 |
control · W02 / W05 |
기반 구현·제품 연결 남음 | 실제 readiness·제품 정책·자원 재관측 |
execution/task · W06 / W07 |
내부 구현·host 저장 연결 | 실행 재조정·보존·용량 회복 |
execution/evidence · W06 |
내부 계약 | 장치 terminal 근거와 Task 귀속 |
execution/workflow · W08 |
골격·이식 대상 | 순차/병렬·실패/취소·중복 실행 계약 |
execution/scheduler · W08 |
일부 구현 | 영속 예약·Alarm·재부팅 복원 |
domain · W03 / W04 / W09 / W10 |
도메인별 상이 | 아래 도메인별 표 참조 |
integration · W04 / W05 / W11 |
대부분 package 경계 | 기존 adapter 위치와 중복 없이 이관 |
legacy · W01 |
package 경계 | 현재 compatibility·DeviceAgent와 이관 범위 결정 |
03 · 도메인별 구현 단계
| 폴더 · WBS | 현재 상태 | 다음 작업 |
|---|---|---|
domain/amr · W04 / W06 |
내부 구현 / provider 미완 | managed 명령·완료·중단 callback |
domain/cleaning · W03 / W04 |
명령/관측 부분 연결 | 전체 청소 중단 근거·managed 실행 |
domain/iot · W03 |
관측 경로 연결 | 실프로세스 reconnect·기기 신선도 |
domain/power · W03 |
관측 경로 연결 | 센서 의미·unknown 정책·기기 검증 |
domain/airquality · W03 |
관측 경로 연결 | 센서 단위·유효성·기기 검증 |
domain/vision · W09 |
내부 세션 구현 | 기존 static 경로의 제품 provider 이관 |
domain/llm · W10 |
기존 구현 보존 / 보류 | 현재 범위에서 신규 확대 제외 |
domain/ui · W09 |
수명주기 골격 | typed 동작·provider·결과/복구 계약 분해 |
domain/mcu · W09 |
수명주기 골격 | typed 동작·provider·결과/복구 계약 분해 |
domain/update · W09 |
수명주기 골격 | typed 동작·provider·결과/복구 계약 분해 |
domain/pairing · W09 |
수명주기 골격 | typed 동작·provider·결과/복구 계약 분해 |
domain/eventasset · W09 |
수명주기 골격 | typed 동작·provider·결과/복구 계약 분해 |
domain/system · W09 |
수명주기 골격 | typed 동작·provider·결과/복구 계약 분해 |
domain/diagnostics · W09 |
수명주기 골격 | typed 동작·provider·결과/복구 계약 분해 |
domain/security · W09 |
수명주기 골격 | typed 동작·provider·결과/복구 계약 분해 |
도메인 보조 폴더
command/, mobility/, wellness/는 패키지 경계이고, interaction/에는 상태·정책 타입, schedule/에는 예약 상태 타입이 있다. 이를 별도 제품 Manager 완료로 세지 않는다. 소비자·소유권을 확인한 뒤 상세 WBS로 연결한다.
실제로 비어 있거나 골격인 부분
api/,adapters/,services/systemserver/,data/etc/는 이번 확인에서 README만 있다. 비어 있는 signature나 SystemService를 구현 완료로 표현하지 않는다.domain/ui,mcu,update,pairing,eventasset,system,diagnostics,security의 ManagerService는 공통 수명주기 기반을 호출하는 생성자 수준이다. 도메인 명령·provider·결과/복구는 별도 작업이다.- provider adapter의 현재 구현은
apps/DeviceAgent와 기존 호환 경로에도 있다.base/adapters/가 비었다는 이유로 기존 명령 adapter 자체가 없다고 해석하지 않는다.
이번 구현 위치와 다음 수정 위치
이번 Task 파일 기록은 execution/task/의 journal·snapshot, runtime/의 주입, Android services/runtime/ host의 private 파일 연결에 걸쳐 있다. 파일 저장은 연결됐지만 과거 기록을 실행 권한으로 복원하는 기능은 없다.
다음 AMR·Cleaning managed 실행 연결은 domain/amr, domain/cleaning, runtime, entrypoint와 apps/DeviceAgent의 adapter를 함께 다룬다. 그 후 execution/task에서 자원 재관측·실행 재조정을 연결하고 execution/workflow, execution/scheduler로 진행한다.
근거와 검증
- 폴더·README·8개 골격 ManagerService를 현재 소스에서 확인하고 폴더 데이터에 실재 경로를 기록했다.
- Framework 995/95, host 정적7은 직전 Task 저장 묶음의 검증이다. 이번 폴더 문서 작업에서 JVM/APK를 재실행한 수치가 아니다.
- DeviceAgent139/19는 그보다 앞선 Cleaning 팬 묶음. 제품 Binder·AOSP·실기기 인수는 미검증이며 후속 단계에서 수행한다.
Connections
이번 실제 코드 연결 — W05/W06
server/runtime/MovementProviderSession은 같은 root의 Capability에 AMR·Cleaning provider를 등록하고, 연결별 준비 상태와 순번을 검사한다. MovementServices의 새 구성 경로는 이 검사를 접수·실행 준비에 적용한다. 이전 연결 callback과 해제는 새 연결에 적용하지 않으며, 정책 검사 중 재연결도 거부한다. 자원 FREE·물리 정지·Task 완료는 별도 계약이다.
Android host의 실제 managed transport 연결과 장치 실행 ID·관측 귀속은 아직 남아 있다. 이 구현의 Connection 토큰은 내부 readiness 연결 식별자이며 물리 명령의 실행 ID가 아니다.
최신 코드 검증: Framework 1006 tests / 96 suites, 실패·오류·skip 0, 앱 및 테스트 APK 빌드 통과. 새 provider gate 단위 9개·실행 체인 2개를 포함한다. 이 수치는 내부 코드 검증이며 실제 transport·물리 장치 인수는 포함하지 않는다.