SKIX Framework 전환 현황
공통 Framework 전환: 기반 구축과 개별 기능 연결 단계. 공개 SDK·Task·상태·정책 기반을 구축하고, 이동·보고·알림·날씨의 일부 독립 경로를 연결.
2026년 10월 16일 기준 · 현재 적용 범위와 1차 릴리즈 계획
핵심 변화: 앱은 요청과 화면, Framework는 실행과 정책, 제공자는 장치 연결과 관측을 담당. 다음 목표는 자동·선택 청정의 전체 실행과 완료·중단 판정을 통합한 독립 릴리즈.
발표 구성
- 전환 배경 — DeviceAgent 집중 구조에서 공통 실행 기반으로
- 목표 아키텍처 — 계층별 역할과 서비스 책임
- 적용 현황 — 7개 업무 영역의 구현 범위와 후속 과제
- 주요 성과 — 실행 제어·상태·보고·소비 앱 연결
- 실행 원칙 — 명령 접수와 실제 동작 완료의 구분
- 릴리즈 계획 — 1차 독립 실행 검증과 2차 품질 확대
1. 전환 배경과 목표
기존 DeviceAgent는 장치 호출, 실행 조건, 청정 순서, 상태, 타이머, 음성·화면 연계, 보고를 함께 담당. Launcher에도 일부 기능 정책이 분산되어 기능 변경 시 여러 앱의 동시 수정이 필요한 구조.
전환 목표는 제품 정책과 실행 책임의 Framework 통합. 앱별 정책 중복을 줄이고, 동일한 공개 API와 실행 기준을 모든 소비 앱에 제공.
현재는 기능별 전환 단계. 공통 실행 기반과 개별 독립 경로를 적용했으며, 전체 청정 순서와 일부 보고·정책은 통합 대상. AMR·IoT·음성 제공자 앱은 장치 및 외부 시스템 연결 역할로 유지.
2. 목표 아키텍처와 계층별 책임
| 계층 | 주요 책임 | 구현 위치 |
|---|---|---|
| 소비 앱 | 기능 요청·화면·사용자 입력 | Launcher · 시험앱 · 외부 Agent |
| 공개 SDK | Manager·공통 모델·호출 계약 | base/core |
| 공통 서버 | 정책·자원·상태·Task·기능별 실행 | base/services/core |
| Android 실행 환경 | 초기화·Binder·제공자 연결 | base/services/runtime · Framework Host |
| 호환 계층 | 기존 IPC 계약 변환 | base/compatibility |
| 공용 SystemUI | 상태바·팝업·공용 화면 제공 | 시스템 소유 제공 서비스 |
| 장치·외부 제공자 | 실제 장치 제어·관측·외부 통신 | AMR · IoT · 음성 Agent · HAL |
SDK 이름은 com.sk.intellix.framework, 서버 이름은 com.sk.intellix.frameworkservice로 통일. 기존 앱 설치 ID와 레거시 IPC 계약은 호환 범위 유지.
기능별 Core Service는 논리적 책임 단위. 각 Service를 별도 APK나 프로세스로 분리하는 구조는 아님. Framework Host가 공통 서버를 조립하고, 시험앱은 공개 SDK를 사용하는 실제 소비 앱으로 구성.
SystemUI는 시스템 소유의 공용 UI 제공 계층이며, Launcher는 소비 계층. 장치 제공자는 실제 연결을 담당하고, 제품 정책과 실행 판단은 Framework가 담당하는 역할 구분.
Android Layer 위에서 보는 SKIX
부팅 완료 시 Framework Host를 시작하는 경로 적용. 필수 Core의 부팅 준비와 소비 앱별 Manager 연결을 구분하며, 앱 호출마다 서버 전체를 초기화하지 않는 운영 구조가 목표. 부팅·재연결·권한의 제품 검증과 전체 이미지 탑재는 릴리즈 확인 항목. SystemServer 내부 탑재는 현재 적용 범위와 구분.
3. 전체 적용 현황
현재 단계: 공통 기반 구축 및 기능별 독립 경로 연결. 다음 단계: 전체 실행 통합 및 제품 검증.
전체 이관·리팩터링 진행도: 약 60% — 구현 범위 기준의 개략 추정.
공통 기반과 개별 API 연결의 진척을 반영한 작업자 판단이며, 기능별 가중치로 산출한 실측 완료율이나 기기 시험 통과율은 아님. 주요 후속 작업은 자동·선택 청정 전체 실행, 실행별 완료·중단 판정, 최신 앱 조합의 독립 기기 검증.
그림의 색상은 영역별 적용 상태를 구분하며 면적은 진행 비율과 무관.
4. 주요 성과
분산된 정책과 실행 책임의 정리
이번 전환의 핵심은 앱마다 흩어진 판단과 실행 책임을 Framework에서 일관되게 관리하는 구조의 구축. 기존 제품 동작을 기준으로 정책을 이관하고, 누락된 조건과 실행 중 상태 변경을 함께 보완.
① 실행 조건 — 시작·재개 시점의 정책 적용
기존 구조: DeviceAgent의 명령 정책, 기능별 실행 코드, Launcher의 화면·기능 정책에 판단이 분산. Framework 독립 실행 경로에서는 기존 조건의 일부 누락 가능.
적용 성과: 선택 청정 첫 이동의 배터리·개인정보·청정 오류 조건을 Framework 실행 경로에 연결. 시작뿐 아니라 준비 완료 후 전송 직전과 재개 시점에도 해당 조건을 확인. 기존 배터리 오류 조건의 누락을 복구하고, 청정 전용 제한과 일반 이동의 허용 범위를 구분.
제품 효과: 같은 기능은 호출 앱과 관계없이 같은 실행 경로에서 조건을 검사. 준비 중 오류나 정책 변경을 반영해 이전 판단만으로 동작하는 문제를 방지.
적용 범위: 선택 청정 첫 이동 경로에 반영. 자동 청정의 잠금·야간·화면 확인 등 전체 정책과 Launcher의 나머지 기능 정책은 후속 통합 대상.
② 기능 전환 — 기존 기능 정리 후 다음 동작 실행
기존 구조: 이동·청정 전환에 필요한 음성·고정 청정·추종·상호작용 등의 정리 작업이 제품 실행 코드에 결합.
적용 성과: 일반 이동·복귀·선택 청정 첫 이동에 Framework 준비 단계를 연결. 기존 기능 정리 결과와 실행 조건을 확인한 후 이동을 전송하고, 준비 실패·취소·기한 초과 시 이동을 차단.
제품 효과: 요청 접수와 실제 장치 실행을 분리하고 기능 전환 순서를 명확화. 앱별로 정리 순서를 다시 구현할 필요를 줄이는 기반 확보.
적용 범위: 이동 준비와 첫 이동 전송까지. 자동·선택 청정의 측정·팬·보고·복귀를 포함한 전체 순서 통합은 진행 과제.
③ 명령 처리 — 개별 호출에서 추적 가능한 Task로 전환
기존 구조: 기능별 직접 명령과 콜백 중심의 실행으로, 요청부터 중단까지의 공통 추적 기준이 부족.
적용 성과: 일반 이동·복귀·선택 청정 첫 이동을 Task 경로에 연결. 요청자·실행 식별자·제어 순서를 확인. 선택 청정 첫 이동에서는 이동·팬 자원을 함께 예약. 일시정지·재개·중단과 시간 초과·Host 종료 시 정지 요청을 같은 실행에 연결.
제품 효과: 누가 어떤 동작을 요청했는지, 어떤 자원을 사용 중인지, 중단 후 복구가 필요한지 공통 기준으로 관리.
적용 범위: 연결된 명령에 적용. 장치의 명령 수락과 실제 완료는 별도 판정이며, AMR 완료 이벤트의 실행별 대응과 전체 청정 완료 판정은 핵심 후속 과제.
④ 상태 해석 — 관측값·실행 상태·제품 모드의 역할 구분
기존 구조: 장치 관측, 제품 운전 모드, 앱 상태, 목적지 정보가 여러 경로에서 관리되어 같은 값의 의미와 신뢰 범위를 구분하기 어려운 구조.
적용 성과: IoT 주 모드 조회를 Framework 제품 상태 소유자에 연결하고, 위치·공기질 보고에 실행 문맥과 관측 신선도 검사를 적용. 방열 정상 판정은 실제 온도·RPM 확인 이후에만 제공. 바이탈 앱 상태 통보는 기존 제품 모드 정책에 연결.
제품 효과: 목적지를 현재 공간으로, 명령 접수를 완료로, 미관측 상태를 정상으로 해석하는 오류를 방지. 연결 변경 후 이전 상태 사용을 제한.
적용 범위: 연결된 조회·보고·상태 통보 경로. IoT 전체 상태 보고와 외부 앱의 자동 상태 전달까지 통합된 상태는 아님.
⑤ 앱 결합도 — DeviceAgent 중계를 공개 SDK 경로로 대체
기존 구조: 위치·날씨·알림 등도 DeviceAgent의 준비 상태나 중계에 의존해, DeviceAgent 제거 시 기능 연결이 함께 끊기는 구조.
적용 성과: 위치·공기질 보고의 독립 조회 경로, LLM 날씨 요청·응답 경로, Launcher 지도 변경 알림과 알림 조회·삭제를 공개 SDK와 Framework 소유 기능에 연결.
제품 효과: 소비 앱은 공개 계약을 사용하고, Framework는 실행·상태·저장 책임을 담당. 제공자 앱은 장치·외부 통신을 담당하는 역할로 정리.
적용 범위: 위 개별 경로에 반영. 별도 실외 공기질 요청·응답, IoT 전체 상태·예약, 전체 알림 발생 경로와 기존 저장 데이터 전환은 후속 대상.
발표 핵심: DeviceAgent에 집중된 실행 책임과 앱에 분산된 정책을 기능별로 분리하고, Framework의 정책 검사·Task·상태·공개 API 경로로 통합. 현재 성과는 공통 기반과 개별 독립 경로의 구축이며, 다음 목표는 자동·선택 청정 전체 실행과 실제 완료·중단까지 이어지는 독립 릴리즈.
소비 시험앱을 통한 검증
팬 시작·시간 운전·정지·틸팅, 이동·복귀·선택 Task 제어, 알림·상태 조회를 공개 API 시험 항목으로 구성.
검증 목표: 실제 반환값, Task 진행 상태, 완료·중단 결과를 동일 화면 흐름에서 확인. 최신 앱 조합의 설치·권한·실제 동작 검증은 릴리즈 절차로 수행.
5. 자동·선택 청정과 실행 완료 기준
| 기능 | 시작 조건 | 전체 실행 흐름 |
|---|---|---|
| 자동 청정 | 에어센서 공기질에 따라 연결 장소 자동 선택 | 이동 → 측정·청정 → 완료 판단·보고·복귀 |
| 선택 청정 | 사용자가 청정 장소 선택 | 이동 → 측정·청정 → 완료 판단·보고·복귀 |
| 고정 청정 | 현재 위치에서 운전 요청 | 팬 운전 → 운전 종료 |
자동·선택 청정은 공통 실행 단계를 공유하되 요청 출처와 시작 정책을 구분. LLM 사용 여부·잠금·야간·도킹·화면 확인·타이머·음성·틸트 등 기존 제품 조건과 적용 순서는 보존.
명령 접수·전달·저장과 실제 동작 완료는 별도 판단. 같은 실행의 장치 응답을 확인한 뒤 다음 단계 진행 및 자원 해제.
AMR 장치 응답과 Framework 실행 ID의 대응 확보가 핵심 통합 과제. 장치 전체의 도착 상태만으로 특정 Task의 완료나 다음 팬 동작을 확정하지 않으며, 결과 불확실 시 복구 상태로 관리.
6. 검증 현황과 릴리즈 기준
| 구분 | 현재 확인 범위 | 릴리즈 확인 항목 |
|---|---|---|
| 구현 검증 | 기능별 조건·예외·연결 수명 시험 및 컴파일 | 전체 실행 조합과 장애·재연결 일관성 |
| 배포 후보 | Host·IoT·시험앱 등의 개별 후보 생성·서명 확인 | 최신 기능을 포함한 앱 조합과 설치 권한 — 현재 후보에 최신 변경 전체가 포함된 상태는 아님 |
| 기기 검증 | DeviceAgent 없는 고정 청정의 일부 실제 동작 이력 | 최신 버전의 이동·청정·상태·완료·중단 — 최신 조합의 전체 기기 검증은 시행 전 |
| 제품 인수 | 기능별 구현 및 검증 범위 구분 | 지원 기능·알려진 제약·복구 절차 확정 |
개별 기능의 검증 결과와 제품 전체의 인수 결과를 구분. 1차 릴리즈는 최신 앱 조합에서 DeviceAgent 없이 지원 기능을 실제 수행하는 것을 기준으로 판정.
7. 단계별 추진 계획
1차 · 독립 실행 기반 릴리즈
- 기능 경로 통합 — 별도 공기질 요청·응답, IoT 상태·예약의 중계 대체.
- 청정 실행 통합 — 자동·선택 청정의 준비·이동·측정·팬·보고·복귀 연결.
- 완료·중단 판정 — 실행별 장치 응답 대응 및 불확실 상태의 복구 절차 확보.
- 배포 조합 정합 — SDK·Host·제공자·소비 앱의 서명·권한·기능 버전 일치.
- 독립 기기 검증 — DeviceAgent 없는 기능 실행·중단·장애·재연결 확인 후 지원 범위 확정.
독립 작업은 병행하고, 연관 기능을 묶어 통합 검증. 전체 이미지 빌드는 탑재 검증 단계에서 수행.
2차 · 기능 확대와 운영 품질 강화
Launcher 정책 통합, 공용 SystemUI 효과, 상태·문맥 제공, 장시간·장애·성능 시험, 재시작 복구 고도화. 기존 저장 데이터와 OTA 이관은 별도 전환 계획으로 관리.
장기 방향은 차세대 Framework 개요와 연계. 이번 릴리즈의 중심은 도메인 실행·정책·상태·완료 책임의 Framework 통합이며, Planner는 향후 확장을 위한 외부 소비 계층으로 구분.
일정 확정 기준: 청정 실행 통합, AMR 완료 판정, 최신 기기 검증 결과를 기준으로 릴리즈 일정을 산정.