← Docs hub

SKIX Blueprint — 재구성 전 상세 설계 이력

보존 문서 — 현재 목표 설계로 사용하지 않는다. 2026-09-10 재구성 직전의 상세 설명과 그림을 원문 보존했다. 초기 MR7 분석, 이후 추가된 설계, 당시 구현 기록이 함께 있으므로 아래의 “현재”는 각각 작성 당시를 뜻한다. DeviceAgent 내부 집중 배치, 범용 Task 제출 API 등 초기 안은 현재 Blueprint의 하이브리드 배치·도메인별 접수 경계로 대체한다. 최신 구현·검증 여부는 진행 현황에서 확인한다.

2026-10-02 설계 통합 안내: 이후 논의한 SDK/서버 namespace, 소비 앱과 Domain의 책임, Task 수명, 내부 Service 초기화, 팀원 기능 정합과 AOSP 빌드 연결 기준은 현재 Blueprint의 통합 기준에 반영했다. 아래 과거 설계를 최신 구현 상태로 읽지 않는다.

보존 내용 안내

이 페이지는 AOSP 위에 올라가는 SKIX 프레임워크의 목표 구조와 설계 기준을 다룬다. 실제 리팩터링 진행 상황의 정본은 리팩터링 진행 현황이다. 구현 커밋·테스트 결과·제품 연결 여부·남은 작업은 진행 현황에 기록하고, 이 설계안과 분리해 관리한다. 특정 외부 로봇 SDK의 호환성 검토는 별도 문서에서 진행하며 이 설계의 필수 구현 범위로 취급하지 않는다.

역할 해설: AI Agent와 프레임워크 — 누가 실행하고 누가 작업을 관리하나. TTS 엔진을 프레임워크로 옮기는 것이 아니라, AI Agent의 실행과 프레임워크의 도메인·Task·자원 관리를 분리한다.

연결·관측 계약: 제공자 연결 세대와 TTS 전달 상세. 서비스 준비와 장치 연결 준비를 구분하고, 이전 연결의 관측을 새 작업에 적용하지 않는 경계를 설명한다.

최신 내부 기반: Resource·Capability·Task Runtime 상세 구조. 현재 7개 서비스 조립, 폴더별 책임, 자원 반환 후 미확인 상태, 기능 조회와 실행 승인의 차이를 확인한다.

폴더 중심으로 보기: skix-framework/base/ 폴더·모듈·역할 SVG · 모듈별 담당 업무와 실제 소스 설명. 상위 지능 서비스는 외부의 상황 해석·계획 수정 역할을 뜻하며, 특정 제품명이나 필수 프로토콜명이 아니다.

전체 구성요소 상세 구조도 — 전체 계층·도메인 15개·소스와 구동 위치 에서 실제 소스와 아직 연결 전인 목표를 구분해 볼 수 있다.

처음 읽는 경우 SKIX 전체 구조 — 처음 보는 안내서에서 요청·판단·실행·결과 환류를 먼저 보고, 세부 비교는 전체 구조 Atlas에서 본다.

이 문서는 전체 설계 근거를 보존하는 상세 Blueprint다. 빠르게 구조와 현재 구현 상태를 파악하려면 먼저 SKIX 리팩터링 한눈에 보기를 읽고, 실제 반영 여부는 리팩터링 진행 현황에서 확인한다.

문서 적용 기준

이 문서는 구현 상태가 다른 항목을 한 구조 안에서 다루므로 다음 세 기준을 구분한다.

아래 구조도와 API 이름은 별도 표시가 없으면 목표 계약을 뜻한다. 현재 동작 사실과 목표 설계를 혼동하지 않도록 구현 근거가 확인된 항목만 현재 기준선 또는 병합 후보로 표기한다.

설계 배경과 목표

SKIX 프레임워크의 역할

핵심 정의
Android AOSP 위에서 기기 상태, 안전 정책, 공유 자원, 공개 API, 실행 과정과 결과 전달을 일관된 계약으로 제공하는 단일 namuh 기기 내부 제품 프레임워크다.

SKIX 프레임워크는 Android의 Manager/Service 구조 위에 제품 실행 제어의 핵심 원리인 상태 관찰·안전 정책·공유 자원 조정, 비동기 작업 생명주기와 물리 완료 근거를 결합한다. 기기 기능을 여러 호출 채널이 안전하게 공유하는 실행 기반이다.

공통 프레임워크가 필요한 이유

호출 채널별 적용 방식

실행 요청 단위 선택 기준

기능 하나라도 완료 확인·취소·시간 제한이 필요하면 관리형 단일 Task로 제출한다.

SKIX 프레임워크 구조

AOSP 경계에서 시작해 호출 창구, 공통 제어, TaskManager와 도메인 실행 순서로 구성한다.

전체 구조

그림 1. Android 위에서 동작하는 SKIX 제품 프레임워크 전체 구조
호출 앱의 Android 기본 API 경로와 SKIX 제품 기능 경로, Binder/AIDL, 공통 제어, DeviceAgent 실행, HAL·하드웨어와 callback 반환을 한 장에 연결한다. 원본 SVG 열기

<a id="mr7-current-position"></a>

2026-09-04 기준 MR7 초기 구조 대응 — 과거 분석

아래 오버레이와 표는 초기 분석 시점의 기록이며 현재 구현 상태가 아니다. 이후 공통 런타임·Task 소유권·typed Binder 구현을 포함한 최신 상태는 리팩터링 진행 현황에서 관리한다.

MR7 = Product Interface + Domain Framework 기반 구현
Framework Control Plane + Managed Execution Plane 미구현

원본 도형을 내부에 그대로 포함한 독립형 MR7 구조 대응 SVG
배경은 위의 Blueprint 전체 구조를 단일 SVG 안에 그대로 포함하며, 그 위에만 대칭(역할과 경계가 직접 대응), 유사(일부 대응), 다름(책임이 다름), 미구현 배지를 얹었다. 빨간 점선은 현재 요청이 중앙 SKIX Product Framework Service authority를 우회하는 경로다. 외부 SVG 중첩 참조가 없어 위키의 <img> 삽입 환경에서도 전체 구조와 오버레이가 함께 보인다. 독립형 오버레이 SVG 열기

MR7의 주 작업은 SkixManager·BaseManager·typed managers가 있는 Product Interface Layer와 ModuleCommandDispatcher·domain handlers가 있는 Domain Framework Plane이다. 현재 요청은 두 영역 사이에서 중앙 제어·관리형 실행 계층을 건너뛰는 현재 경로를 사용한다. 따라서 typed API와 handler 분리는 유지하되, 이것을 Framework Control Plane이나 Managed Execution Plane의 완성으로 해석하면 안 된다.

SKMLauncher2의 Fragment·ViewModel·Repository 비교는 전체 리팩터링 위치가 아니다. MVVM 분석은 Experience/Consumer의 앱 내부 사용 사례이며, Product Interface를 어떤 방식으로 소비하는지 보여 주는 확대도다. 코드별 정합성, 현재 우회 호출과 수정 순서는 MR7 정합성 감사 문서에서 확인한다.

설계와 감사 이후 실제 소스 반영 상태, 검증 결과, MR6 task_manager 이식 진행은 SKIX 제품 프레임워크 리팩터링 진행 현황에서 계속 관리한다. 서비스 라이프사이클과 도메인 상태 감사는 이 Blueprint의 lifecycle/state 원칙이 MR7 소스에서 어떻게 분리되고 있는지 추적한다. 도메인별 Bundle 계약 상수화는 기존 문자열 wire 계약을 base/compatibility에 모으고 typed Manager와 Agent가 같은 원본을 쓰는 진행 상태를 추적한다.

구조 표현은 Android 공식 문서의 AOSP Architecture, Platform Architecture, AIDL Overview를 기준으로 삼았다. Android가 제공하는 Manager·System Service·HAL 경계는 유지하고, 그 위에 SKIX 제품 상태·정책· 작업 생명주기와 실제 완료 근거를 추가한다.

앱이 요청하고 제품 실행 계층이 수행하는 흐름

그림 1-A. 요청 구조화, Binder 전달, 기기 실행과 결과 반환
앱 프로세스는 요청과 화면 상태를 구조화하고 제품 실행 서비스는 상태·정책·Task와 실제 완료 근거를 관리한다. 원본 SVG 열기

SKIX Application Architecture Framework는 Android·Jetpack 사용 규칙과 앱 구조를 AAR·템플릿· 검증 도구로 제공한다. SKIX Product Runtime Framework는 Manager·Binder Service를 통해 기기 상태, 정책, Task와 UI 세션을 실제로 소유한다. 응용 프로그램 아키텍처 표준에서 UiAction·UiState, 제한적인 UiEffect, ViewModel, UseCase, Repository와 제품 실행 모듈의 역할을 정의한다.

AOSP 위에서의 위치

그림 2. AOSP 위의 SKIX 프레임워크 내부 계층
제품 인터페이스, 공통 제어 계층, TaskManager와 도메인 프레임워크의 위치를 보여준다. 원본 SVG 열기

현재 DeviceAgent가 놓인 위치

DeviceAgent는 /system/priv-app의 플랫폼 서명 상시 실행 앱이자 Binder 제품 서비스다. 이는 현재 구현 기준선이고, 목표는 AOSP system_server의 얇은 SkixFrameworkSystemService와 독립 system_ext Runtime을 결합한 하이브리드다. 부팅·root Binder·권한·runtime death는 전자가, Task·Workflow·Policy·State·Evidence·도메인 권위는 후자가 담당한다. DeviceAgent는 provider·legacy gateway로 축소한다. 구조·SVG·부팅·복구 상세 현재 확인한 manifest의 .DeviceAgent는 exported=true이고 서비스 전체에 적용되는 signature permission이 선언돼 있지 않다. 일부 명령은 Binder.getCallingUid()를 개별 검사하지만 일반 명령 전체를 보호하는 공통 관문은 아니다. 플랫폼 서명으로 설치됐다는 사실은 호출자 접근 제어를 대신하지 않는다. 공개 Manager API를 연결하기 전에 서비스 권한, UID·패키지·인증서 검증과 메서드별 허용 범위를 제품 Runtime Binder 진입점에서 공통 적용해야 한다.

Android 호출 창구(Manager)와 실행 서비스(Service)의 분리

Android Application Framework의 구조처럼 앱이 쓰는 호출 창구(Manager)와 실제 상태·정책을 관리하는 실행 서비스(Service)를 Binder 경계로 분리한다. 호출 앱은 공개 Manager API를 사용하고, 실제 상태와 정책은 기기 안의 서비스 한곳이 책임진다.

그림 3. 호출 창구와 실행 서비스의 책임 분리
호출 앱의 Manager, Binder 계약, 제품 프레임워크 서비스와 기기 도메인의 경계를 보여준다. 원본 SVG 열기

Manager는 호출 앱이 쓰기 쉬운 요청을 만들고 서비스 연결·재연결과 결과 전달을 담당한다. Manager는 호출 창구로 남고 Service가 기기 상태와 정책을 소유한다. Manager가 잠시 저장한 값이 기기의 새로운 기준 상태가 되어서는 안 된다.

AudioManager, PowerManager, DisplayManager, WindowManager, UiModeManager, AlarmManager처럼 Android가 이미 제공하는 기능은 Application과 SKIX Service가 Context.getSystemService()로 직접 사용한다. AOSP 기본 Framework를 다시 구현하지 않는다. SKIX는 그 위에 제품 의미, 공통 상태·정책, 작업 추적 정보와 물리 완료 근거를 추가한다.

필요한 호출 창구와 실행 서비스

Manager는 호출 편의와 Binder 연결 대리부를 제공하고, Service는 최종 상태와 판단을 소유한다. 구성요소 이름은 목표 구조의 책임 명칭이다.

표의 State Service, Policy Service, Task Service는 1차 단계에서 각각 별도 APK나 프로세스를 뜻하지 않는다. 초기 배치는 DeviceAgent 프로세스의 하나의 제품 Runtime Binder 진입점 뒤에 논리 모듈로 둔다. 별도 프로세스는 장애 격리, 독립 업데이트 또는 파트너 보안 경계가 실제로 필요하다는 근거가 생겼을 때만 분리한다.

Manager별 대표 API

공개 API는 get/set/config를 일률적으로 제공하지 않는다. Task·UI·Schedule은 실행 요청을 받지만, 상태·정책·이벤트·건강 정보는 조회와 구독이 기본이다. 모든 요청과 결과는 임의의 setConfig(Bundle) 대신 버전이 붙은 명확한 형식을 사용한다.

제품 기능과 관리형 실행 API

실행 판단과 관측 API

Execution은 Task 실행의 허용·자원·이벤트, Framework는 SKIX 구성요소의 건강 상태를 뜻한다. 정책 변경 구독은 register...Listener와 unregister...Listener를 짝으로 제공하고, callback 실행 스레드는 호출자가 Executor로 지정한다. 판정 사유는 최초 callback에 포함하므로 별도 decisionId 재조회 API를 만들지 않는다. 합성된 정책 원문과 내부 규칙 조회는 권한 있는 진단 도구에만 제공한다.

Task 생명주기의 권위 원본은 SkixTaskManager 하나다. SkixExecutionEventManager는 감사와 장애 분석을 위한 횡단 이벤트를 제공할 뿐, Task의 최종 상태를 별도로 확정하지 않는다.

프레임워크 핵심 구조

공통 구성요소와 역할

안전 기준은 호출 앱이 완화할 수 없다

정책은 호출 앱마다 따로 판단하지 않는다. 시스템 안전 기준, 제품 기준, 호출 앱의 허용 범위와 현재 기기 상태를 차례로 적용하고 가장 엄격한 조건을 최종 결과로 사용한다.

그림 4. 계층형 정책 합성
시스템 안전 기준부터 현재 기기 상태까지 네 조건을 순서대로 확인하고 실행 여부를 결정한다. 원본 SVG 열기

실행 요청
  1. 시스템 안전 기준을 지키는가?
  2. 제품 사양에서 허용한 동작인가?
  3. 호출 앱에 이 기능을 사용할 권한이 있는가?
  4. 현재 기기 상태가 실행 가능하고, 필요한 사용자 동의를 받았는가?

네 조건을 모두 통과해야 실행한다.
하나라도 통과하지 못하면 사유와 함께 거부하거나 조건이 충족될 때까지 보류한다.

• 어느 계층이든 deny이면 실행하지 않는다.
• 상위 계층의 동의·자원·완료 증거 요구를 하위가 제거할 수 없다.
• 시간 제한·속도·우선순위는 허용 구간 중 가장 엄격한 값으로 제한한다.
• 판정에는 적용한 정책 계층과 버전, 외부 공개 사유를 남긴다.
• reasonCode와 reasonSummary에는 호출자가 조치할 수 있는 공개 가능한 거부·보류 사유만 담는다.

상태 조회와 실행 정책의 경계

Client의 상태·정책 조회는 사전 안내다. 화면 제어와 요청 구성에는 사용할 수 있지만, 조회 직후 기기 상태가 달라질 수 있으므로 실행 권한이나 성공 보장이 되지 않는다.

상태가 오래됐거나 정책 조건이 바뀌면 실행을 보류·거부하고, 진행 중 위반이 생기면 정책에 따라 일시 정지·취소·안전 정지한다. 기존 직접 명령도 같은 정책 관문을 통과하며 Client가 우회 값을 지정할 수 없다. 도메인 고유 안전 규칙은 최종 방어선으로 남는다.

예를 들어 제품 정책이 “이동 중에는 헤드 틸트 관찰 동작을 허용하지 않는다”라면 Client가 이동 전 허용 상태를 조회했더라도, 실행 시점에 이동 중이면 프레임워크가 요청을 막는다. 이동 도메인의 주행 자세와 모터 안전 규칙도 별도로 유지한다.

상태·정책·자원을 함께 확인한다

기능 명세(Capability)는 단순한 메서드 목록이 아니라 기능의 사용 설명서다. 입력·출력·실행 전 조건, 정책·자원·실행기·완료 근거를 한곳에서 연결한다. 예를 들어 mobility.move_to_room은 등록된 공간과 최신 위치 상태, 이동 자원 점유권, 이동 정책, AMR 실행기와 movement.arrived 완료 근거를 함께 선언한다. 상세 계약은 뒤의 참고 자료에 둔다.

실행 중인 작업을 관리하는 TaskManager

TaskManager는 요청의 의미를 해석하거나 모터를 직접 제어하는 기능이 아니다. 앱·IoT·예약 같은 호출자가 실행할 작업과 순서를 정해 제출하면, TaskManager는 어떤 단계가 실행 중인지, 언제 다음 단계로 넘어갈지, 최종적으로 성공·실패·취소 중 무엇으로 끝났는지 관리한다.

호출자·TaskManager·DeviceAgent의 책임

여러 기능을 순서대로 실행하거나 실제 완료를 기다려야 할 때 TaskManager가 필요하다. 앱이 안방 이동 → 청정 → 스테이션 복귀 Workflow를 제출했다면 다음과 같이 처리한다.

1. 이동 Task를 실행하고 AMR의 실제 도착 결과를 기다린다.
2. 도착 근거가 확인된 뒤에만 청정 Task를 시작한다.
3. 청정의 완료·취소·실패를 구분하고 다음 단계 실행 가능 여부를 확인한다.
4. 복귀 Task의 실제 도킹 결과까지 확인한 후 Workflow를 종료한다.
5. 각 단계와 전체 Workflow의 진행 상태·실패 이유·최종 결과를 호출자에게 전달한다.

그림 5. 기능은 유지하고 실행 관리를 공통화하는 구조
호출자가 실행 과정을 각각 연결하는 구조와 TaskManager가 작업 생명주기를 관리하는 구조를 비교한다. 원본 SVG 열기

요청 → 계약 검증 → 정책·자원 판정 → 작업 실행 → 물리 완료 근거 → 결과

그림 6. 관리형 실행 폐루프
요청 판정부터 Task 실행, 도메인 결과 알림, 물리 근거와 최종 결과까지의 흐름을 보여준다. 원본 SVG 열기

아래 상태는 목표 공개 계약이다. 현재 병합 후보가 사용하는 PENDING, RUNNING, COMPLETED, CANCELLED, FAILED, PARTIAL_FAILED는 내부 상태로 유지하고 공개 Adapter에서 아래 상태로 변환한다.

SUBMITTED → ADMITTED → QUEUED → RUNNING → WAITING_EVIDENCE
                                      └→ SUCCEEDED | FAILED | CANCELLED | TIMED_OUT

그림 7. Task 생명주기와 종료 상태
요청 접수부터 정책·자원 판정, 실행, 물리 완료 근거 확인과 최종 종료까지의 공개 상태 계약을 보여준다. 원본 SVG 열기

• 이 그림이 답하는 질문: Task 요청은 어느 시점에 실제 성공으로 끝나는가?
• 읽는 순서: 요청 접수, 실행 대기·진행, 물리 완료 근거, 종료 상태 순서로 읽는다.
• 현재 검증 범위: 공개 상태 계약과 JVM Task core 기준이다. MR6 persistence 전체 이식과 실기기 완료 판정은 남아 있다.

전환기에는 다음 매핑을 사용한다. 내부 정보만으로 공개 단계를 확정할 수 없으면 더 구체적인 상태를 추측하지 않고 앞 단계로 표현한다.

공개 이벤트는 eventName에 상태명을 반복하지 않고 TASK_STATE_CHANGED와 state를 분리한다. 호출자는 state를 기준으로 종료 여부를 판단하고, reasonCode와 단계 결과로 원인을 확인한다.

API 반환은 요청 수락을 의미할 뿐 완료가 아니다. 이동은 도착, 복귀는 도킹, 청정은 정의된 종료 상태, Vital Signs는 사용자 측정 완료 또는 취소처럼 기능별 최종 상태 계약을 따른다. 결과 알림은 requestId, workflowId, stepId, taskId, traceId로 원래 Task에 귀속한다.

제품 예약, Task의 1회 지연과 Workflow 내부 시간 조건은 서로 다른 시간선으로 관리한다.

프레임워크와 Task 생명주기

프레임워크는 Task 상태만 관리해서는 충분하지 않다. 기동 순서, 서비스 연결, 호출자 세션, 도메인 실행과 완료 증거가 각자의 생명주기를 가지며, Task는 이 상태들을 바탕으로 실행 가능 여부와 다음 단계를 결정한다.

그림 8. 프레임워크와 Task 생명주기
프레임워크 기동부터 서비스 연결, Task 실행, 물리 완료 근거와 장애 복구까지의 관계를 보여준다. 원본 SVG 열기

서비스 연결 종료가 곧 Task 성공이나 실패를 뜻하지 않는다. 필요한 서비스가 끊기면 구성요소 상태를 DEGRADED 또는 RECOVERING으로 바꾸고, 진행 중 Task는 기능별 안전 정책에 따라 대기, 재시도, 취소 또는 안전 정지한다. 재연결 뒤에도 같은 요청을 중복 실행하지 않도록 Task 기록과 완료 증거의 상관관계를 유지한다.

호출 계층과 기기 실행 기반의 경계

앱·PUI·IoT·예약·AI 같은 호출 애플리케이션은 StateMirror와 기능 명세로 현재 상태와 허용 기능을 확인하고 구조화된 Task·Workflow를 제출한다. 프레임워크는 정책·자원 검증, 실행 관리와 완료 근거 반환을 담당한다. 이 계약을 유지하면 호출 애플리케이션이 바뀌어도 기기 실행 계층은 유지된다.

그림 9. 호출 계층 변화와 제품 실행 제어의 경계
호출자는 공통 실행 계약에 의존하고, 프레임워크는 상태·정책·자원·완료 판정을 일관되게 관리한다. 원본 SVG 열기

외부 사용 방식과 호환성

기존 호출은 그대로 유지하고, 순서·대기·취소·완료 증거가 필요한 관리형 요청만 Task 계약으로 확장한다.

MQTT 계약은 전송 계층이 아니라 응용 계약을 확장한다

TaskManager 도입 때문에 MQTT 전체를 교체하지 않는다. broker·Topic·인증·QoS는 유지하고, 기존 단일 명령의 JSON도 그대로 허용한다. 변경되는 범위는 순서·대기·취소·완료 추적이 필요한 요청에 관리 의미를 추가하는 payload와 결과 이벤트다.

그림 10. MQTT 전송 호환성과 관리형 실행 계약
기존 JSON 해석을 유지한 채 단일 Task만 호환 어댑터로 감싼다. 복합 Workflow의 MQTT 공통 해석기는 별도 수용 범위로 구분한다. 원본 SVG 열기

AWS IoT Domain Framework로 Client별 양방향 관계를 연다

IotAgent가 단일 AWS IoT Core 연결과 자격 증명을 소유한다. 각 Client Service App은 SkixIotCoreManager를 통해 필요한 domain/channel만 선택한다. Binder 뒤의 SkixIotCoreService는 caller 권한, Client별 구독, publish 전달 상태와 재연결 생명주기를 소유한다. Client가 별도 MQTT 연결을 만들거나 raw Topic을 받는 구조가 아니다.

그림 10-A. AWS IoT Domain Framework 책임 구조 — 기존 MQTT JSON과 Task Contract는 유지한다. 신규 API는 Manager → Binder Service → IotAgentAdapter를 거치며, 기존 제품 handler와 신규 Client callback은 하나의 물리 수신에서 중복 없이 분배한다.

• 이 그림이 답하는 질문: 앱별 IoT 요청을 분리하면서 실제 AWS 연결은 어떻게 하나로 유지하는가?
• 읽는 순서: 앱의 IoT 창구에서 IotManagerService와 IotAgent를 거쳐 AWS IoT까지 읽는다.
• 현재 검증 범위: 계약과 책임 분리 설계다. 제품 Broker 연결과 실기기 송수신 완료를 뜻하지 않는다.

SkixIotCoreManager가 공통 진입점이며, CleaningIotManager, MobilityIotManager 같은 전용 Manager는 같은 정책 경로를 쓰는 선택적 wrapper다. Client A와 B가 같은 cleaning.command를 구독해도 Handle A1/B1은 독립적이다. A의 unsubscribe 또는 Binder death는 A1만 닫고 B1은 유지한다.

Client A: subscribe(cleaning.command) → Handle A1  / publish(cleaning.state) → Receipt A2
Client B: subscribe(cleaning.command) → Handle B1  / subscribe(mobility.command) → Handle B2
Physical: cleaning.command Topic 1개 → Framework가 A1·B1 callback으로 독립 fan-out

Client 공개 범위와 Service 내부 통제

실행은 시스템 공통 정책, 서명된 Domain 명세, 호출자 권한, 이번 요청의 조건까지 네 조건을 모두 통과해야 허용한다. 계약식은 Root Policy ∩ signed DomainDescriptor ∩ caller grant ∩ operation request다. 내부 DomainDescriptor는 AWS→Client의 subscribeChannels와 Client→AWS의 publishChannels를 분리해, 구독 권한이 발행 권한으로 확대되지 않도록 한다.

새 Domain 추가

기본 경로는 제품 이미지에 포함되는 로컬 built-in descriptor다. 공통 codec을 사용하는 Domain은 descriptor·schema·권한·계약 테스트만 추가하며 Framework Core의 분기문을 수정하지 않는다. 원격 skix-domain-catalog는 이미 설치된 capability의 활성화·축소·회수만 담당하며, 설치되지 않은 실행 코드나 새 하드웨어 기능을 원격 설정만으로 추가할 수는 없다.

발행 상태와 복구

개념 계약은 publish(domain, channel, payload)이고, 실제 API는 statusCallback을 함께 받는다. 상태는 LOCAL_ACCEPTED → QUEUED_OFFLINE → SENT → PUBACKED → RESPONDED로 진행하거나 FAILED로 끝난다. PublishReceipt는 최종 성공이 아닌 접수 시점의 상태다. 후속 결과는 PublishStatusCallback 또는 getPublishStatus()로 확인한다.

연결, 구독, 발행은 서로 다른 생명주기로 관리해 각 장애의 영향 범위를 격리한다. Broker 단절은 logical handle을 유지한 채 복구하고, Client 종료는 해당 구독만 닫으며, 개별 발행 실패는 해당 메시지만 재처리한다. Framework Service가 재시작되면 기존 Binder handle은 무효이므로 Manager가 재bind 후 구독 intent를 다시 제출해 새 handle을 받는다.

그림 10-B. 연결·구독·발행 생명주기 — 마지막 logical reference가 없어질 때만 Broker unsubscribe를 수행한다. Broker 재연결, Binder death, Framework Service 재시작의 복구 규칙은 서로 다르며, 필요한 범위만 복구해 정상 Client와 메시지에 장애가 번지는 것을 막는다. 신규 domain 등록 경로는 Catalog SVG, 전체 API·오류·전환 계약은 AWS IoT Domain Framework 상세 설계를 본다.

• 이 그림이 답하는 질문: IoT 연결이 끊겼을 때 기기 전체 연결과 앱별 구독을 어떻게 나눠 복구하는가?
• 읽는 순서: 연결 준비부터 정상 사용, 끊김, 다시 연결 순서로 읽고 장애 범위 격리 규칙을 확인한다.
• 현재 검증 범위: 목표 lifecycle 계약이며 실 AWS 장시간 복구 시험은 남아 있다.

현재 구현을 세 단계로 구분한다

MQTT JSON
  → CmdTopic의 기존 기능별 해석
  → 기존 method·parameter Bundle 생성
  → IotTaskManagerBridge.wrapCommand()
       request.task 없음       → 기존 직접 실행 Bundle 유지
       request.task {}         → method=submitTask, taskMethod=기존 method
       request.task.managed=false → 기존 직접 실행 Bundle 유지
  → sendModuleCommand(Bundle)
  → MainApi 직접 실행 또는 TaskManager

request.task가 없으면 기존 직접 실행, 빈 {}도 관리형 실행 의도로 처리한다. managed=false이면 기존 직접 실행을 유지한다. 관리형 요청에서 실행 방식·대기열·우선순위·시간 제한을 생략하면 TaskPolicyRegistry의 기능별 기본값을 사용한다. IoT 변환부는 correlationId를 traceId와 함께 보존하고 replyTo도 다음 계층으로 전달한다.

기존 단일 명령

{
  "request": {
    "method": "setMoveTo",
    "payload": {"positionId": "5"}
  }
}

관리형 단일 Task

{
  "correlationId": "iot-20260830-0001",
  "replyTo": "device/reply/command",
  "request": {
    "method": "setMoveTo",
    "payload": {"positionId": "5"},
    "task": {}
  }
}

위 메시지는 내부에서 다음 Bundle 의미로 바뀐다. forceTaskManager는 DeviceAgent 내부 라우팅 표식이며 공개 MQTT 필수 필드가 아니다. IoT 단일 Task는 method=submitTask 자체로 TaskManager 제어 API에 진입한다.

method=submitTask
taskMethod=setMoveTo
source=iot
traceId=iot-20260830-0001
correlationId=iot-20260830-0001
replyTo=device/reply/command

여러 단계를 한 실행으로 관리할 때는 submitWorkflow와 subTasks 목록을 사용한다. 이 Bundle 계약은 DeviceAgent TaskManager와 AAR·Cloud 변환부에 구현되어 있다. 다만 아래와 같은 외부 MQTT JSON을 모든 Topic에서 공통으로 해석하는 연결부는 단일 Task 어댑터와 별도로 수용·회귀 검증해야 한다.

{
  "requestId": "iot-20260830-0002",
  "traceId": "iot-20260830-0002",
  "request": {
    "method": "submitWorkflow",
    "payload": {
      "subTasks": [
        {"taskMethod": "setMoveTo", "positionId": "5"},
        {"taskMethod": "startBasicAirClear"},
        {"taskMethod": "returnToStation"}
      ]
    }
  }
}

MQTT 전달 특성은 구현 상태를 구분한다

기존 직접 요청과 관리형 요청이 함께 존재하는 동안의 동시성

현재 직접 요청은 기존 DeviceAgent 정책과 도메인 차단 규칙을 사용하고, 관리형 요청은 여기에 TaskManager의 접수·대기열·자원 판정을 추가한다. 두 경로가 새 자원 조정기를 완전히 공유하는 상태는 아니다. 관리형 Workflow가 이동 중일 때 기존 직접 이동 명령이 들어오는 충돌을 막으려면 진입점에서 사용 중 거절, 허용된 선점 또는 관리형 전환 중 하나를 정하고 실행권을 하나만 선택해야 한다.

상세 필드와 결과 알림 규칙은 MQTT Task Contract를 기준으로 하고, 제품 반영 전에는 기존 요청·응답, 단일 관리 Task, 복합 Workflow를 각각 회귀 시험한다.

호출 앱 계약

• 모든 공개 Manager는 SkixFramework Client Core AAR의 Service 탐색, 연결·재연결, Binder 연결 종료, API 버전과 결과 알림 전달을 공유한다.
• Binder Service는 UID·인증서·권한과 입력 형식 버전을 검증하며 payload의 호출자 문자열을 신뢰하지 않는다.
• 일반 파트너 앱은 허용된 기능 명세·공개 상태·요약 사유만 읽는다.
• SKIX 시스템 앱·Planner는 형식이 명확한 정책·자원·이벤트·서비스 상태 근거를 읽을 수 있다.
• 개발·관제 도구의 원시 추적 정보와 완료 근거는 별도 권한과 감사 기록을 요구한다.

DeviceAgent 책임 과집중 해소

DeviceAgent를 단순히 여러 클래스로 나누는 것만으로는 과집중이 해소되지 않는다. 상태·정책·자원·작업·UI의 최종 판단권이 계속 한 객체에 남아 있으면 변경 영향과 장애 범위도 그대로다. 책임은 기능 수가 아니라 최종 판단권을 기준으로 나눈다.

그림 11. 프레임워크와 DeviceAgent의 책임 분리
DeviceAgent에 모인 공통 관리 책임을 단일 소유자로 분리하고, 실제 기능 실행과 하드웨어 안전만 실행 경계에 유지하는 구조다. 원본 SVG 열기

TaskManager와 DeviceAgent가 나누어 맡는 일

TaskManager는 작업표와 진행 상태를 관리하고, DeviceAgent는 실제 기기 기능을 수행한다. 상태·정책·자원 서비스는 두 영역이 같은 현재 상태와 안전 기준을 사용하도록 돕는다.

어떤 책임을 옮기고 무엇을 남기는가

이동 중 헤드 틸트 다운, 모터 정지, 센서 오류처럼 하드웨어와 강하게 결합된 규칙은 기존 도메인에 남긴다. 카메라와 이동의 동시 사용, 음성 세션 중 행동, 전면 표시 경쟁처럼 여러 도메인을 조정하는 규칙은 프레임워크가 합성한다.

이동 → 청정 → 복귀에서 DeviceAgent가 실제 완료·실패 근거를 반환하면 TaskManager가 다음 단계, 재시도, 보상 동작 또는 전체 종료를 결정한다.

상태마다 값을 최종 기록하는 곳을 하나만 둔다. 이를 단일 상태 기록 책임이라고 한다. 위치는 이동 결과 알림 담당부, 청정 상태는 청정 결과 알림 담당부가 기록한다. StateMirror는 이 값을 공통 형식으로 읽어 주지만 같은 상태를 별도로 판단하거나 다시 소유하지 않는다. Task 완료도 API 접수 응답이 아니라 물리 결과 알림으로 판정한다.

구현 현황(2026-09-05): b77c2c5에서 이 원칙의 첫 concrete slice인 StateManagerService가 Runtime+State 기본 composition에 연결됐다. typed key/record, source·관측 시각·freshness, READY gate와 immutable snapshot은 JVM에서 검증됐다. 다만 MR6 observation bridge의 producer adapter, 기존 상태와의 dual-publish 동등성, Binder/AOSP/실기기 연결은 아직 완료되지 않았다. 구현·이식 경계와 SVG

안전한 이관 순서

1. 공통 상태를 먼저 분리: 기존 실행은 유지하고 StateMirror가 읽기 전용 최신본을 제공한다.
2. 판단을 나란히 비교: Policy·Resource·Task 판정을 실제 실행 없이 기존 결과와 비교한다.
3. 기능별 실행권 이전: 검증된 기능만 관리형 경로로 전환하며 기존 경로와 동시에 실행하지 않는다.
4. DeviceAgent를 실행 Facade로 축소: 공통 판단은 제거하고 도메인 명령·근거 변환·하드웨어 안전에 집중한다.
5. 프로세스 분리는 근거가 있을 때만 수행: 장애 격리·독립 OTA·보안 경계가 필요할 때 Binder Service 분리를 검토한다.

전환 중에는 정책 책임 중복, 기존 대기열과 작업 대기열의 중복 실행, 상태 기록 책임 중복, 결과 알림에서 명령을 다시 호출하는 순환, 하드웨어 안전 장치 완화를 금지한다. 특히 동일 기능의 실행권을 두 경로가 동시에 갖지 않는다.

참고 자료

공개 호출 API와 결과 조회

Manager별 함수는 Manager별 대표 API를 기준으로 한다. 최종 정책, 자원 점유권, 완료 근거와 구성요소 상태는 Service가 소유하며 일반 호출자가 임의로 변경할 수 없다.

공통 Client Core는 Service 탐색, 연결·재연결, Binder 연결 종료, 버전 확인과 결과 알림 전달을 공유한다. 각 Manager가 Binder 연결과 상태 캐시를 따로 만들지 않게 하는 SDK 기반이다.

상태·정책·기능 명세 계약

상태 종류와 공통 형식

StateEnvelope
  domain, key, typed_value
  source, captured_at, received_at
  freshness, sequence, confidence
  visibility, correlation_id

기능 명세와 공유 자원

CapabilityDescriptor
  capability_id, version, domain, operation
  input_schema, output_schema
  preconditions, policy_refs, resource_claims
  executor_ref, completion_evidence, failure_reasons
  risk_level, visibility, availability

ResourceLease는 점유 주체, 사용 방식, 우선순위, 선점 가능 여부, 획득·만료 시각과 해제 사유를 가진다. 호출 앱은 직접 점유권을 조작하지 않고 작업·UI 요청을 통해 필요한 자원을 선언한다.

UI와 호출 앱 세션

공통 UI AAR와 시스템 화면

공통 UI는 정적 자산을 배포하는 AAR과 실행 중 UI 상태를 조정하는 Service로 분리한다. UI Resource Kit AAR와 UI Foundation AAR는 SKMLauncher2의 공통 자산·구성요소를 공유하되, 화면별 상태나 제품 실행 정책은 포함하지 않는다.

UI AAR는 SKMLauncher2 전체 코드를 공유하지 않는다. 리소스는 skix_ prefix와 이름 공간을 사용하고, 중앙 권한·상태·우선순위가 필요한 요청만 SkixUiManager로 보낸다.

앱 내부 Android UI 구조와 SKIX 제품 UI 조정

그림 12. MVVM + UDF 기본형과 제품 UI 세션 경계
앱 내부의 상태 흐름, 선택형 Reducer, 공개 UI API와 제품 UI 세션의 책임을 분리한다. 원본 SVG 열기

• 이 그림이 답하는 질문: 사용자 입력과 새 화면 상태는 앱 안에서 어느 방향으로 흐르는가?
• 읽는 순서: 화면, ViewModel, Repository, Manager 순서로 요청을 읽고 아래 점선으로 돌아오는 UiState를 확인한다.
• 현재 검증 범위: 앱 구조 표준과 MR7 대응 관계를 설명한다. 모든 기존 화면의 이관 완료를 뜻하지 않는다.

앱 내부는 UDF 기반 MVVM을 기본으로 사용한다. UiState는 불변 화면 상태, UiAction은 사용자가 화면에 전달한 입력이다. UiEffect는 유실돼도 업무 결과가 바뀌지 않는 짧은 시각 반응에만 제한한다. 단순 화면은 ViewModel → Repository → Manager로 끝내고, 복잡한 상태 전이에만 선택적 UseCase와 Reducer·StateMachine·Coordinator를 추가한다.

ViewModel은 Binder를 직접 호출하지 않는다. UiSessionRepository는 앱 또는 Client AAR에서 callback을 화면 상태로 변환한다. SKIX UI Framework는 MVVM 구성요소가 아니다. God Manager로 만들지 않는다. 화면별 상태와 사용자 이벤트는 앱이 소유하고, 제품 UI 실행 문맥은 SkixUiService, 기기 작업 상태는 TaskManager가 소유한다.

응용 프로그램 아키텍처 표준에서 구성요소, 복잡도별 확장 기준, 오류·Coroutine·테스트 규칙과 전환 순서를 정의한다.

UI Manager·Service 경계 상세 SVG 열기

• 이 그림이 답하는 질문: 앱 화면과 제품 UI Framework는 무엇을 각각 소유하는가?
• 읽는 순서: 앱 화면 책임과 공개 UI API를 비교한 뒤 아래 제품 UI 세션 조정과 Android 기본 기능을 읽는다.
• 현재 검증 범위: 책임 경계와 API 목표 구조다. Window·Display·Overlay의 실기기 통합 완료를 뜻하지 않는다.

Launcher 연동 앱의 화면 세션 관리

이 영역을 호출 앱 연동(Client App Integration)으로 정의한다. 패키지·Activity class 직접 결합은 기존 변환부로 감싸고 안정된 대상과 서비스 상태·최종 결과 알림으로 단계적으로 이전한다.

그림 13. Launcher와 호출 앱의 UI 세션 관리
앱 내부 자유 영역과 프레임워크 소유 경계인 화면·Task 세션·복귀 관계를 보여준다. 원본 SVG 열기

UiSession: REQUESTED → LAUNCHING → READY → FOREGROUND ↔ PAUSED → DISMISSED
Task:      RUNNING → WAITING_EVIDENCE → SUCCEEDED | CANCELLED | FAILED | TIMED_OUT

화면 READY는 기능 완료가 아니다. Vital Signs는 측정 완료·사용자 취소, Security는 모드 종료·변경, Welcome은 시나리오 종료 증거가 필요하다. TaskSessionBinder가 이를 원래 Task에 연결한 뒤에만 다음 작업 흐름 단계로 진행한다.

외부 설계 원리

적용 및 전환 계획

지금 구조에서 무엇을 바꾸는가

현재 내부 Manager와 TaskManager 적용 후보는 서명·권한·회귀·실기기 검증 전까지 제품 계약으로 확정하지 않는다.

코드 기준 이행 설계

분석 기준 커밋은 1398d109이며, TaskManager 기능이 있는 별도 작업본은 TaskManager 적용 후보로 구분한다.

전환 방식 비교와 선택

기존 구조를 모두 버리는 전면 재구축보다 단계적 융합을 기본안으로 삼는다. 검증된 기기 기능과 하드웨어 안전 규칙은 유지하고, 공통 상태·정책·자원·작업 관리 책임만 기능 단위로 옮긴다. 처음에는 새 구조는 판단만 하고 실제 실행은 기존 방식이 담당한다.

유지 → 감싸기 → 판단 결과 사전 비교 → 실행 책임 이전 → 기존 분기 축소

그림 14. 기존 기능을 유지하면서 실행 책임을 옮기는 구조
새 구조는 먼저 판단만 하고 실제 실행은 기존 방식이 담당한다. 결과가 충분히 일치한 기능부터 실행 책임을 옮기며, 문제가 생기면 해당 기능만 기존 경로로 되돌린다. 원본 SVG 열기

전환 중에도 같은 요청을 실행하는 곳과 같은 상태를 최종 기록하는 곳은 각각 하나여야 한다. 기능 단위로 실행 책임을 하나만 이전해야 새 대기열과 기존 직접 호출의 중복 실행을 막을 수 있다.

협력사와 먼저 합의할 항목

• 기존 명령의 입력·결과·차단 조건·결과 알림·물리 완료 기준
• 상태 기록, 정책 판단, 자원 조정, 작업 관리와 도메인 실행의 최종 책임 주체
• 신규 API의 버전, 필드 기본값과 구버전 호출자의 호환 범위
• 판단 결과 사전 비교의 허용 오차와 기능별 실행 책임 이전 조건
• 중복 실행, 안전 정책 약화, 완료 오판이 발생했을 때의 되돌림 조건
• 동일 서명 APK와 실기기에서 확인할 물리 완료 근거와 성능 기준선

현재 코드, 병합 후보, 목표 설계를 구분한다

TaskManager 후보는 기준선 이후 431개 파일이 변경돼 전체 병합하지 않는다. 실행 생명주기, Workflow, Scheduler와 완료 근거를 분리해 기능별로 이식한다.

그림 15. 현재 실행 경로와 책임 집중 지점
공개 Binder 진입부터 MainApi, 상태·정책, 연동 서비스 결과 알림과 물리 실행까지 실제 호출 흐름을 보여준다. 원본 SVG 열기

현재 코드에서 먼저 풀어야 할 책임 집중

현재 process에서 하이브리드 process로 단계적 전환한다

현재 DeviceAgent는 android.uid.system, persistent=true인 privileged app이지 SystemService가 아니다. 기존 process 논리 경계는 호환 기준선으로 유지하고, 신규 권위 소스는 skix-framework/base로 이동한다. SkixFrameworkService.apk는 격리 Runtime, SkixFrameworkSystemService는 부팅과 전역 Binder를 소유한다.

com.sk.airbot.deviceagent
├─ bootstrap/        DeviceAgent · ComponentRuntime · peer 연결 순서
├─ compat/           LegacyCommandRegistry · LegacyBundleAdapter
├─ identity/         CallerIdentityResolver · ClientSessionRegistry
├─ state/            StateStore · DeviceStateSnapshotAdapter · derived state
├─ policy/           DeviceFactCollector · OperationAdmissionPolicy
├─ event/            FrameworkEventHub · EvidenceNormalizer
├─ task/
│  ├─ api/           TaskControlApi · TaskQueryService
│  ├─ core/          TaskLifecycleReducer · TaskRepository
│  ├─ workflow/      WorkflowEngine · DependencyResolver
│  └─ schedule/      TaskScheduler · TriggerEvaluator
└─ domain/
   ├─ mobility/      MobilityCommandAdapter · MobilityEvidenceAdapter
   ├─ cleaning/      CleaningCommandAdapter · CleaningEvidenceAdapter
   └─ ui/            UiSessionAdapter · UiEvidenceAdapter

기존 RobotMovementController, BaseCleaningManager, ScheduleManager, ErrorHandler는 도메인 동작과 하드웨어 안전 규칙을 계속 소유한다. 새 계층은 이 코드를 복제하지 않고 입력·상태·완료 증거를 정규화한다. 별도 프로세스 분리는 비정상 종료 격리나 독립 OTA의 실측 필요가 확인된 뒤 결정한다.

TaskManager 병합 후보를 다루는 방법

병합 후보에는 TaskManager.java 3,632줄, 실행기 레지스트리, Task 완료 상태 저장소와 관찰기, 작업 흐름·실행 일정, 추적 ID, TaskManagerClient AAR와 테스트가 있다. 이 기반은 버리지 않는다. 다만 큰 클래스를 그대로 옮기면 현재 MainApi와 비슷한 책임 집중이 다시 생기므로, 검증된 기능 단위로 나눠 가져온다.

목표 Task Service는 다음처럼 분리한다.

호출자 권한과 정책 책임

현재 Binder service는 앱 고유 signature permission을 요구하지 않는다. 적용 후보의 signature permission 추가는 이식 가치가 있으나, manifest 선언만으로 끝나지 않는다.

Binder UID · PID
  → PackageManager에서 package 집합 확인
  → signing certificate와 선언 permission 확인
  → CallerIdentityResolver가 caller profile 생성
  → 공개 Capability·상태·명령 범위 결정

• 호출자 제공 source를 권한 근거로 사용하지 않는다. source=CLOUD 같은 값은 trace metadata일 뿐 실행 권한이 아니다.
• 호출자가 정책 우회 여부를 정하지 않는다. bypassCallerPolicy, 강제 실행, 내부 우선순위는 일반 공개 계약에서 제거한다.
• 대기열, 우선순위, 시간 제한, 재시도, 취소 가능 여부와 자원 요구는 기능 명세와 서버 정책이 기본값·상한·하한을 소유한다. 호출자는 허용된 선택값만 요청할 수 있다.
• platform-signed system app, 동일 인증서의 내부 앱, 별도 승인 인증서의 파트너 앱을 서로 다른 caller profile로 관리한다.
• Binder death는 callback 정리뿐 아니라 해당 caller의 session·lease·취소 정책으로 연결한다.

기존 명령을 끊지 않는 계약 전환

기존 sendModuleCommand(Bundle)와 MQTT 형식은 즉시 제거하지 않는다. LegacyCommandRegistry가 270개 메서드의 입력, 결과, 차단 조건, 결과 알림, 물리 완료 기준과 관리형 전환 여부를 명시한다.

기존 요청
  → LegacyBundleAdapter
  → LegacyCommandRegistry 명세
  → 기존 직접 실행 또는 관리형 작업 중 실행 책임 하나 선택
  → 동일한 기존 결과 Bundle·결과 알림 반환

신규 요청
  → 형식이 명확한 Manager 요청
  → 기능 명세
  → 작업 허용 판정·실행·완료 근거
  → 형식이 명확한 결과·이벤트

IoT 호환성과 관리형 요청 형식은 MQTT 계약을 따른다.

상태와 완료 증거를 옮기는 순서

StateManager를 즉시 교체하지 않고 LegacyDeviceModeCoordinator로 감싼다. 먼저 DeviceStateSnapshotAdapter가 기존 위치·도킹·배터리·이동·청정 상태를 읽기 전용으로 투영한다. 새 상태 저장소는 동일 값을 다시 판단하거나 하드웨어를 제어하지 않는다.

MainService의 연동 서비스 결과 알림은 다음 순서로 분리한다.

AMR·Vision·IoT 원시 결과 알림
  → 도메인 결과 해석기
  → 기존 상태 기록 책임과 제품 반응 유지
  → FrameworkEventHub에 형식이 명확한 이벤트 이중 기록
  → EvidenceNormalizer가 taskId·stepId와 연결
  → TaskLifecycleReducer가 최종 상태 여부 판정

초기에는 기존 결과 알림과 새 형식의 이벤트를 동시에 기록해 누락·순서·지연 차이를 비교한다. 주기적으로 상태를 확인하는 방식은 호환용 보조 장치로만 남기고, 최종 구조는 완료 사건을 받는 방식을 기본으로 한다. 결과 알림이 다시 명령을 호출해 순환하거나, API 접수 응답을 실제 완료로 잘못 처리하는 경로는 차단한다.

단계별 전환과 되돌림

그림 16. 실행 책임을 단계적으로 이전하는 경로
기존 실행 유지, 판단 결과 사전 비교, 선택 이식, 도메인 변환부와 실행권 이전을 기능 단위로 진행한다. 원본 SVG 열기

완료와 배포 기준

컴파일과 JVM 시험은 구조 검증이다. 제품 전환 완료는 동일 서명 APK, 실제 Binder 호출자, 연동 서비스 연결, 센서·모터 결과 알림과 장기 실행 로그가 함께 확인된 시점으로 판정한다.

연결 문서

• SKIX 로보틱스 프레임워크 전체 구조 Atlas
• Request-to-Evidence 전체 흐름
• AOSP Boot와 Runtime Lifecycle
• SKIX Root Binder Admission Core
• SKIX Runtime Composition 구현 현황
• SKIX StateManager 읽기 전용 투영 구현
• SKIX 하이브리드 SystemService와 Runtime 구조
• SKIX 제품 프레임워크 리팩터링 진행 현황
• SKIX 도메인 정책 사양 카탈로그
• SKIX 서비스 라이프사이클과 도메인 상태 감사
• SKIX Blueprint 기준 MR7 리팩터링 정합성 감사 및 교정안
• 프레임워크와 SDK 문서 모음
• 프레임워크·SDK 시스템 설계
• SDK 계약
• SoC TaskManager 프레임워크
• TaskManager 기준 사양서