← Docs hub

SKIX 리팩터링 프레임워크 설계안

이 문서는 무엇을 어떤 책임으로 나눠 만들 것인지 정하는 전체 설계의 정본이다. AOSP 위에서 로봇 동작과 기존 제품 서비스를 함께 관리하는 프레임워크를 만든다. DeviceAgent의 코드를 폴더만 바꾸는 작업이 아니라, 요청·상태·정책·실행·완료의 소유자를 분리하는 작업이다.

실제 리팩터링 진행 상황의 정본은 리팩터링 진행 현황이다. 아래 표와 구조도는 목표 책임을 설명하며, 클래스 존재나 그림의 실선만으로 제품 연결 완료를 뜻하지 않는다. 특정 외부 로봇 SDK 검토는 별도 문서로 관리하며 본 리팩터링의 완료율에 합산하지 않는다.

논의한 개선과 현재 구현 · 2026-10-02 기준

설계 방향과 구현 진척을 구분한다. 아래의 설계 반영은 제품 탑재나 실제 실행 완료를 뜻하지 않는다. 최신 소스·빌드·탑재 입력 근거는 브랜치 정합 현황의 상단을 기준으로 본다.

합친 설계의 핵심 — 하나의 SDK, 공통 서버, 기능별 실행 책임

앱이 기능을 요청하고 → 공통 서버가 실행 조건과 작업 수명을 관리하고 → Domain이 기능별 상태와 실행을 소유하고 → 제공자가 장치에 연결한다. 기존 Agent에 남아 있는 실행 책임은 이 구조로 단계별 이관한다.

• SDK 정본: base/core의 공개 Manager·모델과 base/compatibility의 기존 IPC 변환. 소비 앱마다 별도 SDK를 만들지 않는다.
• 서버 정본: services/core의 control·execution·domain·entrypoint·runtime. Android 연결과 프로세스 수명은 services/runtime 및 APK Host가 담당한다.
• 제품 정합: 팀원 SDK·Launcher·SystemUI·DeviceAgent·EventAssetAgent의 기능을 계약과 동작 기준으로 반영한다. Launcher의 화면·시나리오는 소비 앱에, 공통 상태바·팝업은 SystemUI 서비스에 남기고 장치 실행은 기능별 owner 하나만 유지한다.
• 빌드 연결: Gradle AAR/APK와 AOSP Make/Soong 입력을 함께 관리한다. 현재 별도 AOSP 후보에 소스 732개를 배치하고 SDK·Host Make 등록과 Soong 6개 라이브러리 참조를 검사했다. 이는 전체 AOSP 컴파일·이미지·부팅 완료가 아니다.

현재 위치: SDK·서버 구조와 제품 호환 정합을 진행한 상태다. APK Host는 Runtime을 시작하지만, 목표 AOSP Root의 부팅 연결과 Domain별 실제 실행 책임 이관은 남아 있다. 내부 Service를 모두 Android bound Service로 만들 필요는 없다.

고도화의 의미: 새 계층을 더 만드는 것이 아니라 책임·계약·수명과 이관 조건을 구체화하는 것이다. 최근 구현은 제품 동작 호환과 빌드 입력 정합에 집중돼 있다. 이 작업만으로 Domain 실행 책임 이관·실제 AOSP 연결·제품 부팅이 완료되지는 않는다. Planner는 추후 확장 경계이며 이번 리팩터링의 집중 대상이 아니다.

<a id="scope"></a>

1. 목적과 설계 경계

이번 통합으로 고정한 설계 기준

1. 앱 → SDK → Binder 진입부 → 공통 관리·Task → Domain → 제공자로 책임을 나눈다. 조회·짧은 명령까지 모든 호출을 Task로 만들지는 않는다.
2. Launcher/2는 소비 앱, ProductSystemUI는 SKIX 공통 UI 제공 서비스다. SystemUI는 독립 시스템 APK로 상태바·팝업과 Binder API를 제공한다. SDK는 계약을 소유하며, 장치 상태 원본과 제품 실행 수명은 기능별 서버 owner가 소유한다. UI 렌더링을 services/core나 system_server로 이동하지 않는다.
3. DeviceAgent 분해는 소유권 이관으로 완료한다. Manager·Service 클래스 분리만으로 끝내지 않고 요청·상태·실행·완료·재연결을 기능별로 옮긴다. 이행 중 장치 실행 owner는 하나만 유지한다.
4. 공통 TaskManager는 실행 수명의 owner다. 제품별 조건·장치 제어·관측 해석은 Domain에 둔다. 접수·전송 성공과 물리 완료를 구분한다.
5. Runtime이 내부 서비스를 조립하고 시작한다. 내부 Java Service마다 앱의 bind가 필요한 것은 아니다. APK Host 기동과 목표 AOSP Root 연결은 별도 작업이다.
6. 팀원 소스는 동작과 계약을 비교해 정합한다. 전체 브랜치를 그대로 채택하지 않고 기능 누락·호환·안전 조건을 확인해 같은 책임으로 반영한다.
7. 필요한 추상화만 만든다. Manager=앱 API, Endpoint=IPC 경계, Service=기능 owner, Runtime=구동 수명, Port=요구 인터페이스, Adapter=외부 구현 변환이다. 나머지 명칭도 역할과 의존 방향을 설명할 때만 사용한다. 폴더 규칙은 의존 검사와 실제 빌드 경계로 보강한다.
8. Planner는 추후 확장 대상이다. 이번 완료 조건은 제품 기능 이관·빌드·부팅·실행 검증이며 Planner 구현을 포함하지 않는다.

설계 반영과 제품 완료를 구분하는 기준

반영됨: 공개 SDK/서버 namespace, 현재 7개 Domain, 공통 Task·상태·정책·자원, APK Host Runtime 시작 구조, 소비 앱·팀원 동작 정합 원칙, 불필요한 폴더 제거.

진행 중: 기능별 실행 owner 이관, Launcher 등 잔여 동작 정합, QSSI·별도 AOSP 후보의 소스/사전 빌드 입력 연결. 후보의 제품 선택 검사는 전체 이미지 빌드 증거가 아니다.

남은 제품 완료 조건: 운영 AOSP의 모듈 발견·Kati/Soong·이미지 생성, Host 자동기동·재시작·권한·SELinux, 실제 Binder와 장치 실행/취소/복구, 이중 owner 제거. 각 단계의 검증 근거는 진행 현황 문서에 기록한다.

하나의 제품 실행 기반

PUI·Launcher·AI Agent·IoT·예약은 서로 다른 호출자다. 호출자가 달라도 같은 장치 상태와 안전 조건을 사용하고, 진행·취소·완료 결과를 같은 기준으로 관측해야 한다.

Experience Goal의 추론 엔진은 SoC TaskManager의 필수 구성요소가 아니다. 프레임워크는 현재 상태, Capability, 실행 중간 결과와 Evidence를 제공하고, 상위에서 수정한 계획을 중요한 정책 위반 여부에 따라 수락·거부하며 이유를 반환한다. ROS 2의 요청·피드백·결과·취소와 생명주기 관념을 참고하되, ROS 2 자체를 모든 도메인의 필수 전송 계층으로 강제하지 않는다.

<a id="topology"></a>

2. 전체 구조와 구동 위치

AOSP와 SKIX를 한 장에서 보기

전체 배치도 원본 SVG 확대

그림 읽기: 위쪽 앱에서 두 경로로 내려간다. Android 기본 화면·오디오·카메라 기능은 Android API를 사용하고, 제품 의미가 있는 이동·청소·작업 관리는 SKIX Manager를 사용한다. SKIX 요청은 Binder 경계 → 공통 관리 → 도메인 실행 → 하위 서비스·장치로 이어지고, 관측과 결과는 반대로 돌아온다. SKIX가 Android Framework나 HAL을 대체하는 구조가 아니다.

초기 설계 표기와 현재 목표의 차이: 이 원본의 DeviceAgent 실행 박스와 ‘현재 구현’ 범례는 작성 당시의 이관 출발점을 포함한다. 지금 목표는 그 책임을 AMR·Cleaning·AirQuality·UI 등 독립 도메인 서비스와 제공자 어댑터로 나누는 것이다. 또한 Task·Policy·Resource 박스가 앱에 내부 상태 변경 권한을 직접 공개한다는 뜻은 아니다. 현재 소유권과 공개 범위는 아래 모듈 지도 및 4·5절을 따른다.

AOSP 기반 위에 쌓는 제품 프레임워크 계층

AOSP–SKIX 계층도 원본 SVG 확대

그림 읽기: 아래쪽 Android/AOSP가 프로세스·권한·통신·HAL 기반을 제공하고, 그 위에 제공자 연결 → 도메인 → Task 실행 관리 → 공통 상태·정책·자원 → 앱 호출 계약이 놓인다. 옆의 보안·관측 축은 모든 계층에 적용되는 공통 조건이다. Plane은 프로세스 이름이 아니라 역할별 계층이라는 뜻이다.

이 그림은 책임 계층도다. 위아래로 나뉜 박스가 별도 APK 하나씩을 뜻하지 않으며, Cleaning · air 같은 초기 기능 묶음도 상태 소유권 통합을 뜻하지 않는다. 현재 Cleaning과 AirQuality는 별도 서비스다. 실제 구동 위치는 아래 하이브리드 표, 현재 7개 도메인과 추후 검토 기능은 4절에서 확인한다.

현재 목표의 전체 모듈 책임 지도

전체 모듈 지도 원본 SVG 확대

그림 읽기: 위쪽 호출자가 Manager를 사용하고, 공통 서비스와 도메인 서비스가 협력해 아래쪽 실행 제공자에 동작을 맡긴다. 결과는 관측 → 도메인 상태·Evidence → Task 결과 → 호출자로 돌아온다. 박스 수는 APK·프로세스 수가 아니라 책임 단위다. 그림의 소스 존재와 목표 연결 표기는 구성요소 상세에서 확인한다.

AOSP 부팅 연결과 제품 실행을 분리하는 하이브리드

skix-framework/base는 소스 구조이며, 폴더 생성만으로 AOSP 서비스가 등록되지는 않는다. SDK 산출물, 서버 코드, Android 호스트 패키지, 제품 빌드 포함 설정, 권한·SELinux·부팅 연결을 각각 구성해야 한다. Android Service 호스트와 native daemon의 시작 방식은 다르다. init.rc에 모든 ManagerService를 하나씩 올리는 구조가 아니다. native 제공자에 init 서비스가 필요할 수 있지만 Java 도메인 서비스는 Runtime이 의존 순서로 조립·시작한다.

현재 연결 여부: APK Host의 비공개 내부 연결과 공통 Runtime 조립·시작은 구현했다. 새 namespace Host APK와 QSSI 작업 저장소 입력까지 반영했지만 별도 AOSP 후보의 제품 입력과 QSSI 상위 상속 경로까지 연결했다. 운영 AOSP 적용·전체 Kati/Soong 빌드, Root 등록·공개 경계·제품 자동 부팅·전체 도메인 활성화는 완료되지 않았다. 이전 기기 검증을 최신 바이너리의 제품 부팅 증거로 사용하지 않는다. Android 호스트 구현과 미검증 경계.

<a id="folders"></a>

3. 폴더 구조와 의존 방향

공통 작업 관리와 도메인 실행의 폴더 경계

TaskManager는 AMR·Cleaning보다 넓은 공통 작업 관리 책임이다. 폴더의 물리적 부모가 아니라 모든 도메인이 사용하는 실행권·Task 상태의 공통 소유자라는 뜻이다.

Task 상태·실행 배정은 공통 실행 계층, 장치 명령·도메인 상태·정지 절차는 각 도메인에 둔다. 현재 AMR–Cleaning 직접 협력은 유지되며, 폴더 분리가 범용 도메인 조정자 구현을 의미하지 않는다. 클래스명·공개 계약·동작은 유지하고 내부 package/import와 대응 테스트 경로를 함께 옮긴다.

아래는 책임을 찾기 위한 축약 트리다. 파일·클래스가 존재하는 위치와 아직 연결 전인 목표는 소스 대응표로 확인한다.

skix-framework/base/
├── Android.bp                    SDK·서버 빌드 정의
├── core/                         앱이 사용하는 공개 SDK와 계약
│   ├── java/                     Manager · typed model · Constants
│   ├── aidl/                     Binder 내부 전송 계약
│   └── tests/                    SDK 계약 검증
├── services/
│   ├── core/java/.../server/      Android 구현과 분리한 서버
│   │   ├── runtime/              서비스 조립·시작·종료
│   │   ├── entrypoint/           호출자 검증·접수
│   │   ├── control/              health · state · policy · resource · capability
│   │   ├── execution/            task · 실행·결과 근거
│   │   └── domain/               amr · cleaning · airquality · power · iot · llm · vision
│   ├── runtime/java/             Android Host · Binder · Android 어댑터
│   └── tests/                    서버 계약·동시성·회귀 검증
└── compatibility/                기존 IPC·wire 계약 변환

apps/                             Host 및 제품 앱·실행 제공자·패키징

services/core/는 서버의 제품 판단이고 services/runtime/은 Android 실행 호스트다. 또한 server/runtime/은 서비스를 조립하는 폴더이지 domain/의 상위 소유자가 아니다. 실제 Java 서버 패키지 루트는 com.sk.intellix.frameworkservice.server, 공개 SDK는 com.sk.intellix.framework다.

구조 규칙은 skix-framework/ARCHITECTURE.md에 둔다. 삭제한 api/, adapters/, data/etc/, services/systemserver/와 빈 integration/, legacy/ 폴더를 필수 구조로 다시 만들지 않는다. 제공자 구현은 현재 소유 앱·Android 어댑터에 두고, AOSP Root는 실제 부팅 통합을 구현할 때 배치를 결정한다. 폴더 이름만으로 공개 API나 별도 빌드 모듈 경계가 생기지는 않는다.

폴더를 나눈 뒤에도 서로의 내부 구현을 직접 호출하면 책임 분리는 완성되지 않는다. 각 경계는 요청·응답·관측 포트와 테스트로 유지한다.

<a id="owners"></a>

4. Manager·Service·Agent 책임

앱의 호출 창구와 서버의 책임을 나누는 구조

Manager–Service 계층도 원본 SVG 확대

그림 읽기: 앱 안의 Manager는 호출을 편하게 만드는 SDK이고, Binder 건너편 Service가 상태·권한·수명과 실행 요청을 관리한다. Agent·HAL은 실제 장치나 모델을 실행하고 관측을 돌려준다. 아래로 내려가는 요청과 위로 돌아오는 결과를 함께 읽는다.

원본의 초기 DeviceAgent 내부 배치는 이관 출발점이다. 새 서버 정본은 skix-framework/base/services/, 앱 계약은 core/에 둔다. 도메인을 다시 DeviceAgent 한 서비스로 합치거나 도메인마다 AOSP system_server 서비스를 만드는 뜻이 아니다.

같은 기능을 세 관점으로 분리한다

공개 API 호환 이름·서버 서비스·프로세스의 개수는 반드시 1:1이 아니다. 기존 17개 Manager 호환은 기존 호출 계약을 단계적으로 변환한다는 뜻이지, 17개가 하나의 DeviceAgent 서비스 상태를 계속 공유한다는 뜻이 아니다. 독립적인 제품 상태·사양·장애 범위가 있으면 서비스 소유자를 분리하고, 범용 실행 관리만 공통으로 재사용한다.

공통 구성요소 — 제품 기능과 구분

현재 서버에 구현한 제품 도메인 — 7개

아래 경로는 services/core/java/.../server/ 기준이다. 서비스 클래스가 존재하는 것과 해당 제품 기능의 실행 이관이 끝난 것은 별개다.

추후 기능 검토: MCU·Update·Pairing·UI·EventAsset·System·Diagnostics·Security는 초기 책임 후보다. 현재 독립 Domain Service 8개가 추가 구현돼 있다는 뜻이 아니다. 제품 요구와 기존 owner를 분석해 기존 도메인·공통 서비스·제공자 중 어디에 둘지 정하고, 필요할 때만 새 서비스를 만든다.

이 그림은 초기 15개 기능 후보를 보존한 참고 자료다. 현재 구현 목록은 위 7개 표, 최신 구현 구조도는 현재 계층별 구조를 따른다.

TTS 경계: AI Agent가 합성·재생을 수행하고 LLM 도메인은 기기 측 요청·세션·관측 해석을 맡는다. Task는 진행·취소·완료, Resource는 충돌을 관리한다. TTS 엔진을 DeviceAgent나 TaskManager로 옮긴다는 뜻이 아니다. AI Agent와 프레임워크 역할 상세.

<a id="execution"></a>

5. 요청부터 완료까지

앱 요청에서 제품 실행 결과까지

요청·결과 역할 흐름 원본 SVG 확대

그림 읽기: 앱은 의도와 화면을 맡고, 프레임워크는 실행 가능 여부·작업 수명·상태와 결과를 맡는다. 제공자가 실제 동작하고 반환한 관측을 확인한 뒤 앱에 결과를 알린다. 초기 그림의 넓은 Task 요청 표현은 역할 설명이며, 공개 제출 API는 아래의 도메인별 typed 계약을 따른다.

관측을 받아 다음 동작을 결정하는 순환 구조

실행·관측 순환 구조 원본 SVG 확대

그림 읽기: 요청을 한 번 보내고 끝내지 않는다. 상태·정책·자원을 확인해 실행하고, 진행 관측과 Evidence로 다음 단계·대기·실패·취소를 판정한다. 상위 계획 변경도 이 경계를 다시 통과한다. ‘폐루프’는 이 피드백 순환을 뜻하며, 현재 모든 제품 경로에 이미 연결됐다는 표시는 아니다.

관리가 필요한 작업의 왕복

앱·IoT·예약
  → 공개 Manager → Binder 신원·권한 검사
  → 도메인별 typed 요청 접수
  → 정책·준비 상태 검사 → Task 등록·대기
  → 실행 직전 재검사·자원 확보 → 도메인 실행기 → 제공자
  ← 상태·Evidence ← 장치 관측·실행 피드백
  → Task 진행·최종 결과 → 호출자 조회·구독

위 순서는 목표 책임 흐름이다. 접수와 자원 확보 사이에 경쟁이 발생할 수 있으므로 조회 결과를 승인으로 재사용하지 않고 실행 경계에서 검증한다.

공개 접수는 도메인별 typed 계약으로 좁힌다. 범용 문자열·Bundle을 SkixTaskManager.submitTask(...)에 모두 밀어 넣는 초기 예시를 새 공개 API의 정본으로 사용하지 않는다. 공통 SkixTaskManager는 작업의 조회·목록·취소 등 공통 관리 경계를 제공한다. 현재 typed Task 통신 범위.

모든 호출을 긴 Task로 만들지는 않는다

이동 예시는 청소 중단 요청 → 팬 정지 근거 확인 → 주행 실행 → 도착과 구동부 정지 확인 → Task 종료다. 청소 중단을 요청한 순간이나 목적지 이벤트 하나만으로 전체 완료를 확정하지 않는다. 이동 작업 상세.

<a id="state"></a>

6. 상태·생명주기·자원 소유권

서비스 수명과 작업 수명을 함께 보기

서비스·작업 생명주기 원본 SVG 확대

그림 읽기: 서비스가 시작·준비·장애·복구되는 수명과, 작업이 접수·실행·종료되는 수명은 다르다. 서비스 재연결 뒤 이전 실행의 callback을 그대로 믿지 않고 세대와 실행 식별자를 확인한다. 서비스가 READY라고 장치가 안전하게 정지한 것은 아니다.

Task 상태 전이 원본 SVG 확대

그림 읽기: 작업은 대기에서 실행으로 들어가고, 관측 근거에 따라 완료·실패·취소 흐름으로 간다. 이 원본의 상태명은 초기 개념 모델이며 현재 enum/API의 완전한 목록이 아니다. 특히 CANCELLING은 취소 의도 등록이지 실제 정지·자원 반환 완료가 아니다. 현재 상태 소유자는 바로 아래 표를 기준으로 읽는다.

서로 다른 상태를 한 enum에 합치지 않는다

각 enum의 정확한 값과 구현 범위는 상태·자원 소유권 상세를 기준으로 확인한다. 초기 상태도는 개념 설명이며 최신 코드 enum의 완전한 목록이 아니다.

시작·장애·종료의 원칙

서비스는 의존성이 준비된 뒤 요청을 받고 종료 시 신규 접수를 막는다. 제공자 단절·Binder 사망·Runtime 재시작은 별도 사건이며, 기존 Task의 물리 성공·실패를 자동 확정하지 않는다. 미확인 실행과 자원은 안전 정책에 따라 재관측·복구하고, 오래된 세대의 이벤트를 차단한다. 종료는 역의존 순서로 수행하되 필요한 물리 정지·근거 확인을 건너뛰지 않는다.

동시 접근에서 지켜야 할 불변 조건

1. 도메인별 상태 전이는 단일 소유 경계에서 직렬화하거나 동등한 원자성으로 보호한다.
2. 여러 자원이 필요한 작업은 자원 집합 단위로 승인하고 부분 확보·교착을 방지한다.
3. 자원 반환은 소유 토큰과 세대를 검사한다. 과거 작업이 새 작업의 점유를 풀 수 없다.
4. Task 종료, 실행 제공자 정지, 자원 반환은 서로 다른 사건으로 처리한다.
5. 관측은 출처·시각·연결 세대·작업 식별을 검증한다. 요청 전 RPM 0을 새 정지 근거로 재사용하지 않는다.
6. 타임아웃·재시도·취소 중에도 같은 소유권 규칙을 유지한다. 전송 실패 후 무조건 재전송하지 않는다.

이 원칙은 목표 완료 조건이다. 내부 테스트 통과와 실제 장치의 동시성·재연결 검증 완료를 구분한다. 공통 Runtime 내부 구조 · 제공자 세대 계약.

<a id="contracts"></a>

7. 정책·통신 계약

정책은 기능별로 소유하고, 충돌은 공통으로 조정한다

정책 조회는 사전 안내다. 접수 시점·실행 직전·Workflow 각 단계에서 최신 상태로 다시 판단하며, 기존 직접 명령도 같은 안전 경계를 거친다. 틸팅은 예시 하나이며 실제 이관은 기존 사양을 기능별로 목록화해 검증한다. 호출자는 중요한 정책을 완화할 수 없지만 거부 이유와 가능한 대안을 받아 계획을 수정할 수 있다.

문자열·Bundle은 경계에서 끝낸다

도메인 Constants는 내부 명명 정리이고, 외부 wire 값을 마음대로 변경할 권한이 아니다. 기존 API 호환·typed 변환·실패 결과를 함께 회귀 검증한다.

<a id="migration"></a>

8. 기존 코드 이관 계획

소스 기준과 목적지

• 작업 대상: MR7 packages-mr7-refacto, 브랜치 refactor/blueprint-foundation.
• TaskManager 이식 기준: MR6 a1-packages-mr6의 task_manager 작업본. 분석·비교할 원천이며 MR7 통합 완료본으로 취급하지 않는다.
• 목적지: skix-framework/base. DeviceAgent는 이행 중 기존 외부 계약·장치 연결을 이어 주며 새 공통 프레임워크의 영구 소유자가 아니다.

단계별 산출물과 통과 기준

다음 작업 — 설계와 구현을 같은 완료 조건으로 관리

1. 제품 기능별 이관표 확정: 기존 handler·조건·상태·실행·완료 callback을 해당 Domain/제공자에 연결하고, 남은 Agent owner를 명시한다.
2. 하나의 기능부터 실행 책임 이관: 요청·접수·관측·취소·완료·재연결을 한 묶음으로 옮긴다. 기존 경로를 함께 활성화하지 않는다.
3. 실제 제품 빌드 연결: SDK·Host·소비 앱의 모듈 발견, Kati/Soong 컴파일, 권한·SELinux·탑재 위치를 확인한다. 현재 후보는 공통 AOSP 빌드 소스·도구가 빠져 있어 전체 빌드를 아직 실행하지 않았다.
4. 부팅과 실행 검증: Host 자동기동 → Runtime 조립 → 제공자 연결 → Binder 요청 → 실제 관측/완료 → 장애 복구를 확인한 뒤 기능별 전환을 승인한다.

각 항목은 소스 반영, 로컬 검사, APK 생성, 이미지 생성, 실기기 실행을 따로 기록한다. 코드 수·테스트 수만으로 전체 완료율을 계산하지 않는다.

단계는 일부 병행할 수 있지만 클래스 생성·정적 검사·APK 빌드·실기기 완료는 서로 다른 증거다. 되돌림은 진행 중 작업·자원을 먼저 정리한 뒤 도메인별로 수행한다. 기존 경로와 새 경로가 동시에 같은 장치를 제어하는 이중 실행 상태를 만들지 않는다.

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

초기 MR7 분석과 현재 구현은 분리한다

기존 외부 링크의 mr7-current-position 앵커는 유지한다. 2026-09-04 초기 비교는 재구성 전 설계 이력에 보존했다. 당시의 “미구현” 표기나 줄 수를 현재 진척도로 사용하지 않는다. 현재 커밋·검증·남은 작업은 브랜치 정합 현황에서 확인한다. 이 문서는 확정된 설계 결정과 목표·이행 상태를 연결하고 상세 실행 이력은 복제하지 않는다.

<a id="references"></a>

9. 상세 문서와 설계 이력

주제별 정본으로 내려가기

문서 유지 규칙

핵심 구조도는 본문에 유지한다. AOSP–SKIX 전체 배치·계층, Manager–Service, 요청·관측 흐름, 생명주기는 본문의 해당 절에서 바로 볼 수 있어야 한다. 설명을 정리할 때 이 그림들을 보존본 링크만 남기고 제거하지 않는다. 기존 SVG의 표현이 초기 설계와 연결되면 차이를 설명하고, 최신 모듈 지도와 함께 제공한다.

새 설계 결정은 위 책임·폴더·흐름에 먼저 반영한다. 특정 모듈의 날짜별 작업 보고를 본문 중간에 계속 붙이지 않는다. 상세 페이지는 이 Blueprint의 어느 책임을 확대한 것인지 밝히고, 구현 기록은 진행 현황으로 연결한다. 기존 상세 SVG는 삭제하거나 단순화하지 않았다. 본문에는 전체·폴더·도메인·정책 지도를 배치하고, 나머지 초기 비교·MQTT·UI·생명주기 그림은 설계 이력에서 원형을 유지한다.

Connections

• Framework SDK 허브
• 실제 리팩터링 진행 현황
• 재구성 전 상세 설계 이력