차세대 프레임워크
문맥 이해에서 목표 달성과 기기 실행까지
차세대 프레임워크는 주변 상황을 이해한 AI의 계획을 실제 기기 동작으로 연결하고, 관측된 결과를 통해 사용자 목표의 달성 여부를 확인하는 제품 실행 기반이다. Android의 앱·서비스·권한·하드웨어 연결 구조를 계승하고, 그 위에 로봇 제품에 필요한 Workflow·Evidence·Context Provider 계약을 구축한다.
Experience Goal은 무엇을 달성해야 하는지, Planner는 어떤 기능을 어떤 순서로 사용할지, Framework는 지금 실행 가능한지와 실제로 무엇이 일어났는지를 담당한다. 세 영역이 관측 결과를 주고받으면서 목표에 도달하거나, 추가 확인·중단·실패 보고로 작업을 마무리한다.
1. 명령 실행에서 목표 달성으로
사용자는 여러 API의 실행 순서보다 자신이 원하는 결과를 말한다. “거실 공기를 쾌적하게 해줘”에는 대상 공간, 현재 공기 상태, 사용 가능한 기능, 실행 조건과 완료 기준이 함께 들어간다. 이동 명령과 청정 명령이 각각 성공해도, 사용자가 원한 환경이 만들어졌는지는 별도로 확인해야 한다.
로봇 제품에서는 작업이 수초에서 수십 분까지 이어지고, 이동 중 장애물이나 사용자 취소가 발생하며, 센서값도 계속 바뀐다. 여러 앱과 AI가 같은 이동부·스피커·화면을 사용한다. 기능별 호출만 연결하면 순서·충돌·중단·완료 판정이 호출자마다 달라진다.
따라서 공통 실행 기반은 작업의 연속성, 현재 상태, 실행 권한, 실제 결과를 함께 관리해야 한다. 이 구조는 로봇 이동뿐 아니라 청정·청소·음성·화면·IoT 연동에도 적용된다.
2. 전체 구조: 문맥·목표·계획·실행·관측의 순환
| 영역 | 핵심 질문 | 입력과 출력 |
|---|---|---|
| Context Provider | 지금 어떤 상황이며, 어떤 정보가 믿을 만한가? | 환경·상태·기억·기능 → 출처와 시점을 가진 문맥 |
| Experience Goal | 사용자가 원하는 결과와 성공 기준은 무엇인가? | 요청·문맥 → 목표·제약·성공 기준·남은 목표 |
| Planner | 지원 기능으로 어떤 계획을 만들 것인가? | 목표·문맥·Capability → 기능·순서·조건·실패 처리 |
| Framework 공통 실행 | 지금 실행해도 되는가? 작업을 어떻게 관리하는가? | 계획·호출자·최신 상태 → 접수·거부·진행·취소·결과 |
| 도메인과 실행 제공자 | 실제 기능을 어떻게 수행하고 관측하는가? | 실행 요청 → 이동·청정·음성 등 동작과 관측 |
| Evidence 환류 | 무엇이 실제로 확인됐으며 어떤 목표가 남았는가? | 작업·관측·결과 → 근거가 있는 목표 상태 갱신 |
각 영역은 논리적 책임으로 구분한다. 일반 대화나 단일 명령은 기존 경로로 처리하며, 여러 작업과 결과 관찰이 필요한 요청에 Experience Goal의 연속성 관리가 결합한다. 상위 지능의 클라우드·기기 배치는 모델 성능과 지연·운영 조건에 따라 정한다.
3. Context Aware: 기기 주변의 환경을 해석 가능한 정보로 제공
Context Aware는 대화 이력에 더해 기기 주변에서 확보할 수 있는 환경적 정보를 종합하는 능력이다. 사람·공간·소리·영상·센서·기기 상태·진행 작업을 넓게 관찰하되, 판단에 사용할 때는 현재 요청에 필요한 정보와 유효한 근거를 선별한다.
| 문맥 영역 | 대표 정보 | 해석 시 확인할 조건 |
|---|---|---|
| 사용자와 대화 | 현재 발화, 지시 대상, 직전 질문, 확인된 화자, 동의 | 현재 요청 우선, 화자 식별과 실행 권한 구분 |
| 주변 환경 | 공기질, 소음, 조도, 온습도, 사람·장애물 관측 | 센서 지원 여부, 관측 시점·위치·신뢰도 |
| 공간과 기기 | 방 이름, 지도, 현재 위치, 도킹, 배터리, 연결 상태 | 등록된 공간과 관측 공간의 일치, 상태 만료 |
| 진행 중인 작업 | 실행 단계, 점유 자원, 중단·복구 상태, 남은 목표 | 작업 ID와 실행 세대, 완료·실패의 근거 |
| 제품 지식과 기억 | 지원 기능, 사용 조건, 사용자 선호, 과거 결과 | 명시 정보와 추정 구분, 변경·철회·유효 기간 |
Context Provider는 문맥을 제공하는 논리적 계약을 뜻한다. Android의 ContentProvider와는 다른 개념이며, 모든 정보를 한 서비스나 저장소에 모으도록 강제하지 않는다. 도메인은 자신의 상태를 소유하고, 공통 상태 계층과 문맥 제공 경로는 필요한 조회 결과를 묶는다.
목표 계약에는 값뿐 아니라 출처, 관측 시점, 유효 기간, 대상 범위, 불확실성·누락·충돌을 함께 전달한다. 예를 들어 “거실에 사람이 없다”는 과거 영상만으로 현재 사실이 될 수 없다. 센서가 없는 경우에도 값을 추측해 실행 조건으로 사용하지 않는다.
Product KG·User KG는 기능·공간·사람·기억의 관계를 연결하는 확장 수단이다. 실시간 배터리나 위치는 상태 소유자가 제공하며, 관계 그래프가 현재 상태의 권위를 대신하지 않는다.
소비 계층: AI Planner가 활용하는 Context 예시
AI Planner는 기기·환경·대화·기능 정보를 함께 활용해 Experience Goal을 위한 계획을 구성한다. Context Provider는 이 중 기기에서 제공하는 상태·관측 정보를 공통 형식으로 제공하고, 소비 계층의 AI Planner는 여기에 대화 이력과 사용 가능한 기능 목록을 결합한다.
| 정보 구분 | Context 항목 예시 | 계획·목표 판단에서의 활용 |
|---|---|---|
| 위치·공간 | 현재 방, 스테이션·도킹 여부, 지도 내 방 이름·ID | “거실”을 실제 목적지에 연결하고 이동 필요 여부 판단 |
| 동작·작업 | 주행 상태, 청소 실행·일시정지, 다른 작업 수행 여부 | 진행 작업과 충돌 여부 판단 |
| 환경·전원 | 공기질 등급, PM10·PM2.5·CO₂, 배터리 잔량·충전·저전력 | 환경 개선 필요성과 실행 가능 조건 판단 |
| 음성·연결·보안 | 음성 처리 중 여부, 대화 진행 상태, 클라우드 연결, 보안 기능 동작·주변 밝기 | 사용 가능한 실행 경로와 현재 제약 확인 |
| 정보의 출처·관측 시점 | 최근 감지된 상황, 정보를 제공한 센서·서비스, 관측 시점, 현재 유효 여부 | 현재 판단에 사용할 수 있는 정보와 다시 확인할 정보를 구분 |
| 대화·진행 문맥 | 최근 대화·요약, 직전 확인 질문, 진행 중인 작업, 추가로 필요한 입력, 계획 변경 이유 | 생략된 요청 보완과 기존 작업의 연속성 판단 |
| 기능 문맥 | 지원 기능 목록, 기능별 실행 조건, 담당 서비스 | 실제 제공 가능한 기능으로 실행 계획 구성 |
정보의 출처는 값을 제공한 센서나 서비스이고, 관측 시점·현재 유효 여부는 그 정보가 언제 측정됐으며 지금 판단에 사용해도 되는지를 뜻한다. 예를 들어 오래전에 측정한 공기질이나 이동 전 위치는 현재 상태를 다시 확인해야 한다.
예를 들어 “거실 공기를 쾌적하게 해줘”라는 요청에서는 지도에 등록된 거실 정보, 공기질, 현재 위치, 배터리, 진행 작업, 청정 기능 지원 여부를 함께 참조할 수 있다. 이후 실행 상태와 공기질 관측을 다시 받아 Experience Goal의 달성 여부를 판단한다.
기기 상태·작업 상태를 외부 문맥으로 제공하는 경계
Context Provider는 기기의 현재 상태와 작업 수행 상태를 읽어, Planner·Experience Goal과 허용된 외부 소비자가 사용할 문맥으로 제공한다. 환경 문맥 전체 중 기기·작업 상태를 담당하는 제공 경로다. 상태의 원본과 실행 책임은 각 도메인에 유지하며, Provider가 기기를 제어하거나 작업 상태를 임의로 변경하지 않는다.
기기 상태·작업 수행 상태·관측 결과를 하나의 Context로 묶어 다음과 같이 제공한다.
- 조회: 필요한 기기·작업 범위를 지정하면 상태, 작업 ID, 출처, 항목별 시각, 유효성, 누락 정보를 반환한다. 서로 다른 시점의 조회 결과를 단일 시점의 일관된 상태로 표시하지 않는다.
- 갱신: 기기 상태와 작업 진행의 변경을 반영한다. 서비스 재시작·작업 교체 이후 이전 결과가 현재 문맥에 섞이지 않도록 세대를 구분한다.
- 제공 범위: 호출자 권한과 작업 소유자 범위를 유지한다. 앱·Planner 등 프레임워크 외부 소비자에게 필요한 항목만 제공하며, 클라우드 전송은 별도 연계 계층이 담당한다.
- 완료 판단: 접수·취소 요청·Task 종료 상태와 물리적 완료를 구분한다. 확인되지 않은 결과는 완료로 변환하지 않고 근거 부족으로 제공한다.
그림 5의 초록색 Context Provider가 이 읽기 전용 제공 경계다.
4. Experience Goal과 Planner: 목표를 유지하고 계획을 조정
Experience Goal은 사용자의 상위 결과, 제약, 성공 기준을 작업 전체에 걸쳐 유지한다. Planner는 현재 가능한 기능으로 목표에 접근할 실행 계획을 구성한다. 계획의 일부가 바뀌어도 원래 목표와 사용자 조건은 보존한다.
| 구분 | “거실 공기를 쾌적하게 해줘”에 적용하는 예 |
|---|---|
| Goal | 거실의 공기 상태 개선. 정량 기준은 제품 기준·사용자 확인으로 결정 |
| 제약 | 지원 기능, 현재 접근 가능한 공간, 실행 허용 범위, 사용자 취소 |
| Plan | 상태 조회 → 필요 시 이동 → 지원 청정 기능 실행 → 관측 |
| Task | 각 실행의 접수·진행·취소·종료를 추적하는 단위 |
| Evidence | 해당 공간의 유효한 공기질 관측, 동작 결과, 실패·중단 이유 |
| 남은 목표 | 아직 충족되지 않은 성공 기준과 확인되지 않은 결과 |
사용자 요청의 위임 범위·시간·조건·필수 결과를 먼저 보존하고, 현재 상태에 따른 실행 필요성을 평가한다. 센서값이 이미 좋다고 원래 요청의 조건을 바꾸거나, 생성한 실행 단계에 맞춰 사용자의 의도를 다시 해석하지 않는다.
“쾌적함”처럼 주관적 표현을 근거 없이 센서 수치 하나로 확정하지 않는다. 자동 실행의 범위와 성공 기준을 정할 수 없으면 필요한 항목을 확인한다. 같은 목표에 여러 계획을 사용할 수 있지만, 지원하지 않는 기능이나 승인되지 않은 행동을 새로 추가하지 않는다.
5. 왜 로보틱스의 Workflow·Evidence·Context Provider인가
로봇의 동작은 시간이 걸리고, 환경에 영향을 주며, 실행 중에도 조건이 바뀐다. 이 세 특성이 차세대 프레임워크가 집중해야 할 영역을 결정한다.
| 로봇 제품의 특성 | 필요한 공통 계약 | 해결하는 문제 |
|---|---|---|
| 여러 단계가 오래 이어지고 일부만 성공함 | Workflow — 순서·선행 조건·진행·취소·실패 처리 | 호출자마다 제각각인 작업 관리와 부분 완료 누락 |
| 명령 접수와 물리적 결과가 다름 | Evidence — 출처·작업 귀속·시점·확인된 결과 | 전송 성공을 이동 완료나 환경 개선으로 오인 |
| 사람·공간·센서·기기 상태가 계속 바뀜 | Context Provider — 유효한 문맥 제공·누락·충돌 표시 | 오래된 상태나 근거 없는 추측으로 계획 실행 |
세 계약은 하나의 순환을 이룬다. Context로 계획의 전제를 확인하고, Workflow로 실행의 연속성을 관리하며, Evidence로 결과를 확인해 다음 Context와 Goal 판단에 반영한다. 여기에 Policy·Resource가 실행 허용 범위와 자원 충돌을 관리한다.
Workflow를 확장해 AI Planner가 활용하는 실행 기반 제공
SKIX Framework는 Workflow의 순서·분기·재시도 관리에 기기 상태, 실행 조건, 완료 기준, 관측 결과, 중단·복구 정보를 결합한다. AI Planner가 계획을 만들고 수정할 때 활용할 수 있도록 이 정보를 공통 형식으로 제공하는 것이 확장의 핵심이다.
| Framework가 제공하는 요소 | AI Planner가 활용하는 판단 |
|---|---|
| 지원 기능과 실행 조건 — 필요한 입력, 선행 조건, 권한, 자원 | 어떤 행동을 계획에 넣을 수 있고 지금 실행할 수 있는가 |
| 현재 상태와 진행 상황 — 실행 단계, 완료된 작업, 진행 중인 작업 | 무엇을 이어서 수행하고 무엇의 결과를 기다려야 하는가 |
| 완료 기준과 관측 결과 — 동작 결과, 환경 변화, 확인되지 않은 결과 | 실행 결과가 사용자 목표를 충족하는가, 무엇이 아직 남아 있는가 |
| 실패·중단·복구 정보 — 중단 이유, 자체 복구 진행, 재시도 가능 조건 | 기다릴 것인가, 다시 시도할 것인가, 계획을 수정할 것인가 |
| 변경·취소 범위 — 취소 가능한 작업, 유지해야 할 결과와 제약 | 이미 완료한 일을 반복하지 않고 어느 부분부터 계획을 바꿀 것인가 |
이 정보는 Workflow 하나가 모두 소유하지 않는다. Workflow·Task가 진행을 관리하고, State·Context Provider가 현재 상황을 제공하며, Evidence가 결과를 연결하고, Capability·Policy·Resource가 실행 가능 범위를 제공한다. Framework 계층이 이 요소들을 작업과 연결해 AI Planner에 제공한다.
AI Planner는 이를 바탕으로 무엇을 어떤 순서로 수행할지 판단한다. Framework는 전달받은 계획의 실행 조건을 확인하고, 진행·취소·복구와 결과 수집을 관리한다. Experience Goal은 사용자 목표와 성공 기준을 유지한다. Framework가 모델의 판단을 대신하거나 Workflow 내부에서 모든 재계획을 수행하는 구조는 아니다.
예를 들어 거실로 이동한 뒤 청정을 수행하는 작업에서 이동은 완료됐지만 청정이 중단됐다면, Framework는 이동 완료, 청정 중단 이유, 자체 복구 여부, 현재 공기질을 제공한다. AI Planner는 이 정보를 활용해 이미 완료한 이동을 반복하지 않고, 복구를 기다리거나 남은 청정 작업의 계획을 조정한다.
조회나 즉시 끝나는 짧은 호출까지 모두 장기 Workflow로 만들 필요는 없다.
Evidence도 모든 로그를 쌓는 저장소를 뜻하지 않는다. 실행 결과를 판단하는 데 필요한 관측과 종료 근거를 작업에 연결하는 계약이다. 명령 접수, 동작 시작, 동작 완료, 목표 충족을 구분한다. 예를 들어 청정 동작 완료는 확인됐어도 센서 근거가 없으면 공기질 개선은 확인되지 않은 상태로 남긴다.
이 방향은 ROS 2를 모든 기능의 필수 통신 방식으로 정하는 것과는 별개다. 이동은 ROS 2, 오디오는 Android 서비스, 장치 제어는 HAL·MCU 등 각 실행 환경을 사용하되 상위에는 일관된 작업·상태·결과 계약을 제공한다. 모터의 고주기 제어와 보호 동작은 해당 제어기에서 담당한다.
6. 왜 Android의 기본 Framework 구조를 계승하는가
회색 영역은 재사용하는 Android 기반이고, 청록 영역은 추가하는 SKIX 제품 Runtime이다. TaskManagerService가 작업의 접수·진행·취소·종료를 추적하고, Policy·Resource·State가 실행 조건을 관리하며, 기능별 서비스가 실제 실행을 Provider에 위임한다. Power·UI 등 제품 서비스는 Android 기본 서비스를 활용한다. 상위 제품 Workflow와 Linux·ROS의 주행 Workflow는 책임을 구분한다.
기존 전문가용 상세 구조도의 Manager들을 책임별로 묶고 Experience Goal·Planner를 연결한 목표 구조다. 별도 제품 Runtime과 AOSP 신뢰 경계의 구분을 유지한다.
차세대 프레임워크는 Android의 기본 구조를 계승하고, 그 위에 로보틱스 실행 기능을 확장하는 방향을 기본으로 한다. 앱·음성·미디어·원형 화면을 제공하면서 기기 작업을 안정적으로 운영해야 하는 제품 요구에 적합하기 때문이다. Android에 준비된 사용자 서비스와 권한·진단·호환성 체계를 활용하면, 공통 기반을 구성하는 개발 부담을 줄이고 환경 문맥·사용자 목표·계획·주행 실행의 연결에 집중할 수 있다.
| 계승을 선택하는 이유 | 제품에서 얻는 이점 |
|---|---|
| 사용자 서비스가 공통 체계로 준비됨 | 전원·화면·입력·오디오·앱 실행을 기존 API와 정책으로 연결 |
| 운영·보안 경계가 정립됨 | 호출자 권한, 프로세스 경계, 장치 접근, 장애 진단을 일관되게 관리 |
| 앱·서비스·하드웨어의 연결 구조가 있음 | SDK·서비스·HAL 경계로 변경 영향을 제한하고 기존 앱·라이브러리 활용 |
| 개발·유지보수 기반을 재사용할 수 있음 | 제품 고유 기능에 개발 역량을 집중하고 플랫폼 갱신 시 수정 범위를 관리 |
여기서 계승은 기존 API·서비스·운영 도구의 재사용과 Manager–Service–HAL 책임 구조의 확장을 뜻한다. 이 구조에 SKIX의 작업·상태·정책 관리와 로봇 실행 계약을 추가한다.
공통 기능 재사용과 운영 안정성
Android는 앱 실행, 패키지·권한 관리, 화면·입력, 오디오·미디어, 네트워크 연결을 공통 API와 시스템 서비스로 제공한다. 제품은 이 기반을 활용하고, SKIX는 그 위에 Task·Policy·Resource·State와 로봇 도메인 기능을 추가한다. 공통 기능을 직접 구현하고 유지해야 하는 범위를 줄이는 것이 설계상의 이점이다. AOSP 구조.
| 활용하는 기반 | 차세대 프레임워크 적용 | 운영·개발상의 이점 |
|---|---|---|
| 앱 실행·패키지·권한 관리 | Launcher·음성 AI·제품 앱을 Android의 설치·실행·권한 체계로 관리 | 앱마다 별도 실행·권한 체계를 만드는 부담 감소 |
| 화면·입력·오디오·미디어·연결 서비스 | 원형 UI와 음성·미디어 기능이 기존 플랫폼 API 사용 | 제품 기능 간 기본 동작의 일관성 확보, 기존 라이브러리 활용 |
| Manager와 Binder/AIDL | SkixManager와 기능별 API가 공통 Runtime·도메인 서비스에 연결 |
앱과 구현의 결합 감소, 호출자·요청·callback 경계 명확화 |
| 프로세스 경계와 서비스 수명 관리 | UI·AI와 기기 실행 서비스를 분리하고 종료·재접속 처리 | 화면이나 AI 프로세스 장애의 영향 범위를 제한할 기반 확보 |
| UID·권한·SELinux | 호출자별 기능 접근과 서비스·장치 접근 범위 설정 | 앱별 임의 장치 제어를 제한하고 실행 경로를 관리 |
| 전원·화면 제어 서비스 | PowerManager·DisplayManager·WindowManager 등 지원 API와 권한 정책으로 깨움·화면 상태·밝기·창 관리 연결 |
앱의 임의 제어를 줄이고 시스템 정책에 맞게 일관된 기기 상태 관리 |
| 시스템 진단·추적 도구 | logcat·dumpsys·추적 도구에 작업 ID·실행 단계·오류 상태 연결 |
현장 장애를 공통 절차로 수집·분석하고 재현하는 기반 확보 |
운영 안정성은 널리 사용되는 기반의 재사용과 제품 고유 복구 설계가 결합할 때 얻는다. 예를 들어 Launcher가 재시작돼도 실행 서비스가 살아 있다면 작업 상태를 다시 조회하도록 설계한다. 실행 서비스까지 종료된 경우에는 저장 상태와 실제 장치 상태를 대조해 복구하고, 이미 수행한 동작을 중복 실행하지 않도록 해야 한다. Android가 제공하는 프로세스·권한·진단 기반 위에 이러한 작업 복구 계약을 추가한다. 앱 샌드박스, 시스템 서비스 진단.
사용자 서비스가 통합된 Android와 Linux의 개발 범위 차이
Android는 전원·화면·입력·오디오·앱 실행·권한 같은 사용자 서비스가 공통 API와 시스템 정책으로 통합된 기반을 제공한다. 제품은 이 체계를 활용해 사용자 경험을 구성할 수 있다. Android도 Linux 커널을 사용하지만, 커널 위에 앱과 기기 기능을 연결하는 사용자 서비스 계층을 함께 제공한다는 차이가 있다. AOSP 구조.
일반적인 임베디드 Linux 구성에도 전원 관리, 그래픽, 오디오, 프로세스 관리 기능과 라이브러리가 있다. 다만 제품이 채택한 배포판·BSP에 따라 통합 수준이 다르므로, 구성요소를 선택·연결하고 공통 API·동작 정책·설정 화면·장애 복구를 제품 수준으로 완성하는 일이 개발 범위에 포함된다. Qt로 화면을 구현하는 것만으로 이 전체 서비스 계층이 갖춰지는 것은 아니다.
| 사용자 서비스 | Android에서 활용하는 통합 기반 | Linux 구성에서 확보할 제품 기능 |
|---|---|---|
| 전원·화면 상태 | 전원·화면 서비스, 앱 실행 유지 요청과 시스템 정책 | 전원 관리·화면 구동부를 연결하고 유휴·깨움·화면 꺼짐·작업 유지 정책 구성 |
| 화면·입력·키보드 | 창 관리·입력 전달·입력기·설정 API | Qt·디스플레이 서버 등 선택, 입력기·포커스·창 우선순위·설정 UI 통합 |
| 오디오·미디어 | 볼륨·출력 경로·오디오 포커스·미디어 제어 API | 오디오 구성요소 연결, 음악·TTS·알림의 우선순위와 볼륨·장치 전환 정책 구현 |
| 앱 실행·권한 | 패키지·앱 수명·권한·설정의 공통 체계 | 서비스 기동·복구와 앱 배포·접근 제어를 제품 운영 방식에 맞게 구성 |
Linux에서는 systemd의 전원 전환 억제 기능, PipeWire의 미디어 처리, Qt의 임베디드 화면 지원 등 기존 구성요소를 활용할 수 있다. 자체 개발 범위는 이들 사이의 연결과 제품 고유 정책, 부족한 기능을 보완하는 부분이다. 선택한 배포판이나 상용 미들웨어가 제공하는 기능은 재사용한다. systemd 전원 전환 억제, PipeWire, Qt 임베디드 Linux.
따라서 Android를 유지하는 1·3안은 준비된 사용자 서비스 기반을 재사용하는 이점이 있고, Linux 단일 칩인 2안은 보드 절감과 함께 사용자 서비스 계층의 통합·유지보수 비용을 계산해야 한다. 예를 들어 음악 재생 중 TTS를 출력하고 화면을 끄는 동작도, Linux에서는 오디오 우선순위·화면 정책·작업 지속 조건을 하나의 제품 동작으로 연결해 검증해야 한다. Android에서도 제품별 정책과 하드웨어 연동 검증은 필요하다.
보안과 기기 제어의 안정성
전원·화면·오디오 같은 공통 장치를 여러 앱이 직접 제어하면 상태가 충돌하거나 자원이 해제되지 않을 수 있다. Android의 시스템 서비스와 권한 경계를 활용하면 누가 어떤 제어를 요청했는지 확인하고, 공통 정책을 거쳐 장치에 반영하는 경로를 유지할 수 있다. SKIX는 이 경로에 제품의 작업 상태·자원 점유·사용자 동의를 결합한다.
| 제어 영역 | Android 기반 활용 | 제품 적용 이점과 추가 책임 |
|---|---|---|
| 보안·접근 제어 | 앱 UID·권한·Binder 호출자 확인·SELinux | 일반 앱의 전원·화면·장치 접근을 제한. SKIX 서비스에서도 호출자와 허용 기능을 검사 |
| 전원 관리 | PowerManager와 시스템 전원 정책, 필요한 범위의 wake lock |
작업에 필요한 실행·화면 유지 조건을 공통 체계에서 관리. wake lock은 제한된 시간만 유지하고 취소·실패 시 해제 |
| 화면·입력 관리 | DisplayManager·WindowManager와 밝기·입력 관련 지원 API |
화면 상태와 창·입력 처리를 시스템 정책에 연결. 원형 화면과 제품별 표시 우선순위는 별도 설계 |
| 종료·재시작 | 권한이 있는 시스템 경로와 제품 종료 절차 | 일반 앱의 임의 종료를 제한. 주행 정지 확인·작업 정리 후 종료하도록 SKIX가 순서를 관리 |
예를 들어 주행 중 화면이 꺼져도 주행 취소로 해석하지 않으며, 사용자가 전원 종료를 요청하면 주행 중단 요청 → 실제 정지 확인 → 작업 정리 → 시스템 종료 순서로 처리하도록 설계한다. 정지 확인이 오지 않을 때의 보호 동작과 시간 제한은 제품 제어 정책으로 정한다. 사용할 수 있는 API와 권한은 Android 버전·앱 권한 등급·BSP에 따라 확인한다. PowerManager, DisplayManager, WindowManager.
Android의 보안·전원·화면 관리 기반은 오동작과 무단 접근을 줄이는 데 활용한다. 물리적 안전을 보장하는 비상정지·모터 보호·하드웨어 인터록은 하위 제어기와 안전 회로에서 담당한다. Android 서비스나 AI의 정상 동작에만 의존하지 않도록 설계한다.
앱·서비스·하드웨어 호환성
호환성은 세 경계에서 관리한다.
| 경계 | 유지할 계약 | 변경 시 얻는 이점과 확인 사항 |
|---|---|---|
| 앱 ↔ 제품 SDK | 공개 Android API와 버전이 관리되는 SkixManager API |
Runtime 내부가 바뀌어도 앱 변경 범위를 줄임. 비공개 Android API 의존은 최소화 |
| SDK ↔ 제품 서비스 | 요청·결과·오류·callback과 지원 버전 | 서로 다른 버전의 앱·서비스 조합을 검증. 독립 업데이트 경계에는 Stable AIDL 적용 검토 |
| Framework ↔ 하위 실행 제공자 | HAL·어댑터와 기능·상태·결과 계약 | SoC·BSP·ROS 연결부 변경이 상위 앱에 미치는 영향을 제한. 실제 기능과 타이밍 차이는 재검증 |
AIDL을 사용한다는 사실만으로 버전 호환성이 보장되지는 않는다. 독립 업데이트가 필요한 인터페이스에는 버전 고정·호환성 검사와 신규 기능 미지원 시 처리를 적용한다. 또한 통신 형식이 호환돼도 완료의 의미나 취소 동작이 달라질 수 있으므로, SKIX의 기능 계약을 별도로 회귀 검증한다. Stable AIDL.
Android 앱 생태계를 활용하려면 대상 Android 버전·기기 유형에 해당하는 CDD 요구사항과 CTS 등 호환성 검증을 충족해야 한다. 이는 기존 앱과 라이브러리가 기대하는 API·기능 동작을 유지하는 기준이다. AOSP 채택만으로 모든 앱의 동작이나 Google 서비스 사용이 보장되지는 않는다. 필요한 Google 서비스의 지원·라이선스 조건, 원형 화면에서의 표시·입력, 앱이 요구하는 하드웨어 기능은 따로 확인한다. Android 호환성 프로그램.
장기 유지보수와 로보틱스 확장
표준 Android 동작을 유지하고 제품 확장을 SDK·제품 Runtime·도메인 어댑터에 모으면, Android 및 공급사 BSP 갱신 때 자체 수정 영역을 추적하기 쉬워진다. 기존 개발·디버깅 도구와 인력 경험도 활용할 수 있다. 이는 통합·회귀 비용을 줄이려는 설계 방향이며, 실제 절감 효과는 수정량과 시험 결과로 확인한다. 보안 패치와 OTA의 장기 운영에는 공급사 지원 기간, 배포·복구 절차, 제품별 검증이 필요하다.
목표 배치는 얇은 AOSP Root와 별도 제품 Runtime이다.
- 앱 프로세스: Manager가 타입이 있는 요청·결과 API와 서비스 연결을 제공한다.
- AOSP Root — 목표: 서비스 발견, 부팅 연결, 신뢰 경계를 담당한다.
- 제품 Runtime — 목표: 공통 Task·Policy·Resource·State와 도메인 서비스를 구동한다.
system_ext는 배치 파티션이며 프로세스 자체를 뜻하지 않는다. - 도메인과 제공자: 기능 상태와 실행 책임을 소유하고 ROS 2·HAL·MCU·기존 Agent와 연결한다. 내부 Service마다 별도 APK나 Android bound Service를 만들 필요는 없다.
이 배치에서 Android는 공통 실행·보안·운영 기반을 담당하고, SKIX의 Workflow·Evidence·Context Provider는 장기 작업, 물리적 완료 근거, 환경 문맥을 담당한다. Experience Goal과 Planner는 이 계약을 이용해 목표와 계획을 조정한다. 모델 추론이나 장기 로봇 작업은 별도 실행 영역에 두고, 모터의 고주기 제어와 보호 동작은 ROS·MCU 등 해당 제어 계층에 둔다.
채택 방향과 플랫폼 선택
Android의 사용자 서비스와 기본 Framework 구조를 제품의 공통 기반으로 유지하고, SKIX는 그 위에 Workflow·Evidence·Context Provider를 구축한다. Experience Goal과 Planner는 이 실행 기반을 통해 사용자 목표를 기기 동작과 실제 결과로 연결한다. 준비된 공통 기능의 재사용과 로봇 제품의 고유 기능 확장을 함께 추진하는 것이 차세대 프레임워크의 채택 방향이다.
이 방향은 1안의 Android AP + Linux·ROS AMR AP 분리 구성에서 직접 적용한다. Android가 사용자 서비스와 제품 비즈니스 로직을 담당하고, Linux·ROS가 주행 Workflow를 담당한다. 3안도 Android 기반을 유지하지만 동일 SoC의 ROS 통합 부담이 추가된다.
2안의 Linux 단일 칩은 원가 개선 후보로 별도 검증한다. 선택하려면 보드 절감뿐 아니라 Android 사용자 서비스의 대체·통합 비용까지 회수할 수 있어야 한다. Goal·Plan·Task·State·Evidence의 책임 구분은 유지하되, Android SDK·Binder·서비스 구현은 Linux 환경에 맞게 이식한다. 차세대 플랫폼 검토.
7. 대표 시나리오: 거실 공기 상태 개선
다음은 이동·청정·공기질 관측 기능을 지원하는 제품을 가정한 목표 시나리오다. 실제 기능 지원과 성공 기준은 제품 사양으로 결정한다.
- 요청과 대상 확인: “거실 공기를 쾌적하게 해줘.” 등록 공간의 거실을 식별하고, 대상이나 허용 행동이 불명확하면 확인한다.
- 문맥 조회: 현재 위치·배터리·공기질·활성 작업·이동 가능 여부를 출처·시점과 함께 받는다. 현재 위치의 공기질을 거실 값으로 바꾸어 해석하지 않는다.
- 목표와 계획 구성: 거실 공기 상태 개선의 성공 기준을 정하고, 필요한 경우 이동·청정·관측을 계획한다. 이미 충족된 조건은 불필요한 실행을 줄이는 데 사용한다.
- 실행 승인과 작업 관리: 최신 상태로 정책·자원·Capability를 확인한다. TaskManager가 작업 수명과 진행·취소를 관리하고 도메인이 실행한다.
- 실제 결과 확인: 이동의 결과와 청정 동작, 해당 공간의 유효한 관측을 연결한다. 통신 응답만으로 완료를 확정하지 않는다.
- 목표 갱신과 응답: 성공 기준이 충족되면 결과를 알린다. 센서 부재·접근 불가·시간 초과이면 확인된 결과와 미충족 항목을 구분해 보고한다.
8. 상황 변화와 실패: 남은 목표만 선택적으로 재계획
환경이 달라졌다고 매번 LLM을 호출하지 않는다. 도메인의 정상 복구와 계획에 정의된 재시도로 해결 가능한지 먼저 확인한다. 남은 목표를 달성하려면 계획 자체를 바꿔야 할 때 Planner의 재판단으로 연결한다.
| 상황 | 처리 방향 |
|---|---|
| 정상 진행 또는 하위 실행기의 경로 복구 중 | 관찰을 이어가고 정상 이벤트만으로 LLM을 재호출하지 않음 |
| 계약에 정의된 일시 실패와 재시도 가능 상태 | 횟수·시간 제한 안에서 재시도, 중복 물리 동작 방지 |
| 부분 완료 후 남은 목표에 다른 계획 필요 | 완료 항목을 보존하고 남은 목표와 최신 문맥으로 재계획 |
| 대상·조건·권한이 불명확하거나 확인 필요 | 필요한 항목만 사용자에게 질문하거나 실행 보류 |
| 사용자 취소·보호 조건·시간 예산 초과 | 중단·보호 동작과 확인된 결과 보고 |
재계획 응답이 돌아올 때는 목표·작업의 취소 여부, 실행 세대, 최신 상태, 기능·정책·자원을 다시 확인한다. 취소된 작업이나 과거 상태에 해당하는 계획을 실행하지 않는다. 계획을 재제출할 때는 기존 실행과의 중복도 점검한다.
재계획 횟수와 관찰 시간에는 한계를 둔다. 목표를 달성하지 못해도 계속 실행하는 대신, 중단 이유와 남은 목표를 사용자에게 전달한다. 이런 제어가 모델 호출 비용과 물리 동작의 예측 가능성을 함께 관리한다.
9. 적용 순서와 기대 효과
| 단계 | 구축 내용 | 다음 단계로 넘어가는 조건 |
|---|---|---|
| 1. 실행 책임과 계약 정리 | SDK·공통 서비스·도메인·제공자 경계, 명령 owner 정리 | 대표 기능의 기존 동작 보존과 단일 실행 책임 확인 |
| 2. 작업·상태·근거 연결 | Task 수명, 취소, 도메인 상태, 완료·실패 Evidence | 실기기 성공·실패·취소·재접속에서 결과 귀속 확인 |
| 3. 환경 문맥 제공 | 시점·출처·범위·누락을 포함한 Context 계약 | 오래된 관측·충돌·센서 부재가 판단에 올바르게 반영 |
| 4. 목표·계획 순환 연결 | Experience Goal, Planner, 선택적 재계획 | 목표 보존, 부분 완료, 취소 후 늦은 응답, 예산 제한 검증 |
| 5. 제품·플랫폼 확대 | 도메인 추가, AP 배치 변경, 공급사/BSP 이식 | 동시 부하·장애·업데이트·회귀 품질과 총비용 확인 |
기대 효과는 다음 지표로 확인한다. 사용자 목표 달성률과 잘못된 완료 보고율, 신규 기능의 앱별 중복 구현량, 취소·복구 시간, 불필요한 모델 호출 수, 지원 플랫폼 변경 시 이식 범위가 핵심이다. 개선 수치는 제품 비교 시험으로 산출한다.
Connections
- SKIX 리팩터링 프레임워크 설계안 — Blueprint — 책임 계층·구동 위치·기능별 실행 소유권
- SKIX 전체 구조 — 처음 보는 안내서 — 요청부터 상태·결과 환류까지
- Experience Goal × 지식 그래프 — 환경·사람·기억·목표·계획의 연결
- Experience Goal 개요 — 기존 Planner와 목표 생명주기의 경계
- 요청이 실제 완료 근거로 돌아오는 구조 — 작업 접수와 물리 완료의 구분
- 차세대 플랫폼 검토 — Android·Linux ROS 분리·통합과 비용 판단
- 프레임워크·SDK 문서 모음