← Docs hub

SKIX 리팩터링 계획 — 제품 요구 도출부터 제품 인수까지

이 문서는 현재 리팩터링 진행률을 정리한 표가 아니라, 제품 요구를 확인하는 단계부터 구조 설계·구현·제품 인수까지 필요한 업무를 새로 시작하는 TODO다. 사용자가 작성한 SKIX Framework Blueprint 초안은 중요한 설계 입력이지만 확정 요구사항이나 승인된 정답으로 간주하지 않는다. 제품 목적과 실제 사용 시나리오에서 요구사항을 도출하고, 그 요구로 초안을 검증·수정·승인한 뒤 상세 설계에 들어간다.

모든 체크는 미착수다. 기존 코드·문서·진행 기록은 제품 동작과 제약을 확인하는 증거로 조사하되, 기존 구조나 진행률을 목표 설계의 전제로 삼지 않는다.

관리 표준과 전체 Todo 요약

엑셀 개발 항목 양식의 대구분 / 소분류 / 세부사항 / 담당자 / 상태 구조를 적용한다. 이 문서에서는 리팩터링 생애주기를 대분류로 두고, 세부 업무마다 A–F 역할 owner와 확인 가능한 산출물을 연결한다.

상태 규칙: 미착수는 작업 전, 진행은 owner가 착수하고 증거 위치를 기록한 상태, 차단은 선행 결정/의존성 때문에 진행할 수 없어 blocker와 결정 owner가 등록된 상태, 완료는 산출물과 수용 기준을 reviewer가 확인한 상태다. 단순 시작, 코드 작성, Binder ACK만으로 완료 처리하지 않는다. 현재 표의 모든 행은 계획 상태인 미착수다.

전체 Todo 상세

분석 · 0. 제품 목적과 요구사항을 먼저 도출

• [ ] P0.1 — 제품 목표와 사용자 결정 수집: 제품이 제공해야 할 사용자 가치, 제품군/보드 범위, 운영 환경, 출시·호환 제약, 제품 책임자의 결정사항을 수집한다. 확인되지 않은 항목은 결정 질문과 결정 owner로 남긴다.
• [ ] P0.2 — 핵심 사용 시나리오 정의: PUI/Launcher, AI Agent, 앱/외부 호출자, IoT, 예약 작업, 진단·관리자, 로봇 수동·자율 동작에서 시작 조건, 정상 결과, 사용자에게 보이는 실패·취소·복구를 정의한다.
• [ ] P0.3 — 제품 요구사항 원장 작성: 각 항목에 ID, 사용자/제품 근거, 기능 요구, 수용 기준, 우선순위, owner, 미결 질문을 기록한다. 기능 요구 외에 안전 정지, 권한·보안·개인정보, 가용성, 성능/자원, 관측성, 업그레이드/호환성/롤백 요구를 포함한다.
• [ ] P0.4 — 실행 의미와 인수 기준 결정: 요청 접수, 실행 시작, 진행 관측, 취소, 물리 동작 완료, 실패·복구가 제품에서 각각 무엇을 뜻하는지 정한다. ACK·callback·Task 종료를 실제 기능 완료로 볼 수 있는 조건도 제품 owner와 합의한다.
• [ ] P0.5 — 요구사항 기준선 승인: 제품·플랫폼·안전 책임자가 모호성, 우선순위, 정량 기준, 미결 위험을 확인하고 요구사항 baseline revision을 승인한다.

완료 산출물: 사용 시나리오, 요구사항 원장, 용어·상태 정의, 수용 기준, 미결 결정 목록, 승인 revision.

분석 · 1. 사용자 작성 Blueprint 초안을 요구사항에 비춰 검토·보완

• [ ] P1.1 — 초안 주장 추적: Blueprint의 각 목표·계층·서비스·도메인·흐름·그림을 P0 요구사항 ID에 연결한다. 요구로 뒷받침되지 않는 설계 가정은 가정으로 표시한다.
• [ ] P1.2 — 누락·상충·미결 확인: 요구사항 누락, 문서와 다이어그램 불일치, 용어/상태 의미 충돌, 확정되지 않은 기술 선택, 구현 가능성·제품 제약을 검토한다. 사용자 초안 자체의 잘못된 전제도 수정 후보로 기록한다.
• [ ] P1.3 — 대안과 경계 검토: 앱/SDK, Binder 진입, Android 시스템 프로세스, 제품 Runtime, 공통 서비스, 제품 도메인, Agent/ROS 2/MCU/HAL 제공자 경계를 요구로부터 비교한다. 최소 2개 구조 대안과 선택·기각 근거를 ADR에 남긴다.
• [ ] P1.4 — Blueprint 및 그림 개정: 요구 추적표와 결정 결과에 맞춰 범위, 계층, 용어, 인터페이스, 상태 흐름, 미결 사항을 고친다. 추적되지 않는 목표 구조를 확정 표현으로 두지 않는다.
• [ ] P1.5 — Blueprint 검토 승인: 제품·시스템 아키텍처·Android 플랫폼·하드웨어 담당자가 개정본, 요구 추적성, 미결 위험, 결정 owner를 함께 검토한다. 승인 revision을 구조 설계 기준으로 지정한다.

완료 산출물: 요구사항-Blueprint 추적표, 초안 검토 이슈, 대안/ADR, 수정된 Blueprint와 SVG, 검토 승인 기록.

분석 · 2. 현행 제품과 플랫폼을 조사해 실현 조건 및 전환 범위 확정

• [ ] P2.1 — 제품 동작 증거 수집: 승인된 시나리오별 기존 앱/API, 권한, 명령 흐름, 실제 실행자, 결과 피드백, 오류·취소·복구를 코드·설정·로그·실기기 근거로 확인한다.
• [ ] P2.2 — AOSP/보드 제약 조사: Android 버전과 제품 변형, system/system_ext/vendor 경계, Binder·권한·SELinux, 부팅·서명, MCU/드라이버/HAL 제공 조건을 확인한다. 문서 추정과 실제 제품 증거를 구분한다.
• [ ] P2.3 — 상태·데이터·저장 조사: 서비스와 provider lifecycle, 도메인 상태, Task/Workflow/Schedule, Resource, 관측·Evidence의 현재 owner·수명·저장·복구를 확인한다.
• [ ] P2.4 — 호환·운영 제약 확인: 소비 앱과 wire contract, 기존 설정/데이터, 성능·메모리·지연 기준, 진단, 설치·업데이트·롤백 조건을 조사한다.
• [ ] P2.5 — 요구 대비 현행 gap 기록: 현재 동작·제약을 승인 요구와 수정된 Blueprint에 연결해 보존/변경/제거/미확인 항목, 위험, 전환 비용을 기록한다. 이는 현황 증거이며 완료율 판정이 아니다.

완료 산출물: 코드·제품 동작 지도, AOSP/보드 제약표, 상태·데이터 inventory, 호환표, 요구별 gap 및 위험 원장.

설계 · 3. 승인된 Blueprint를 구현 가능한 아키텍처와 계약으로 구체화

• [ ] P3.1 — 요구사항·품질 시나리오 추적: 승인된 기능 요구와 비기능 요구 각각에 시스템 책임, 품질 시나리오(자극·조건·측정 결과), 설계 위치, 검증 level을 연결한다. 값이 미정이면 측정 책임자와 결정 시점을 등록한다.
• [ ] P3.2 — 시스템 컨텍스트와 외부 경계: actor, 소비 앱, 외부 시스템, 장치/provider, 데이터 흐름, 신뢰 경계, 포함/제외 책임을 context diagram과 인터페이스 목록으로 정의한다.
• [ ] P3.3 — 구조 대안과 설계 결정: 요구별로 2개 이상 후보를 비교한다. 단일/다중 프로세스, system_server 경량 Root와 system_ext Runtime 분리, 서비스 조립 방식 등 영향을 받는 선택을 근거·비용·위험·후속 검증과 함께 ADR로 남긴다.
• [ ] P3.4 — 배치·프로세스·부팅 구조: 앱 SDK, Binder 진입, Android host, system_server Root, system_ext Runtime, native/provider를 프로세스·파티션·시작 주체·재시작·서명 단위에 배치한다. Android Service와 native daemon의 부팅 방식을 구분한다.
• [ ] P3.5 — 계층·모듈 경계와 의존 규칙: public core, runtime/host, entrypoint, control, execution, domain, integration, adapter, compatibility, systemserver의 책임·허용 의존·금지 참조·조립 지점을 정의한다. 이 설계가 승인되기 전에는 폴더 구조를 고정하지 않는다.
• [ ] P3.6 — API·IPC·버전 계약: SDK Manager, typed API/AIDL, 내부 Port, callback/query, 호출자 identity, 권한 거부, 오류·timeout·idempotency·versioning·legacy 변환을 요청/응답 예제로 명세한다. 소비자와 제공자가 계약을 함께 승인한다.
• [ ] P3.7 — 보안·신뢰·개인정보 경계: UID/package 신뢰 규칙, 권한 부여 지점, system_server와 제품 Runtime 권한 분리, signature permission/SELinux, 민감 데이터·진단 로그·감사 정책을 threat model과 권한표로 작성한다.
• [ ] P3.8 — 서비스·도메인 책임 catalog: 공통 서비스와 각 제품 도메인마다 단일 상태 authority, 정책 판단자, API owner, 실행자, 제공자, 관측 출처, 제품 수용 기준을 지정한다. 15개 도메인은 요구와 용량에 따라 묶거나 세분하되, 상태 정본은 중복 소유하지 않는다.
• [ ] P3.9 — 상태·데이터·저장 모델: 서비스 lifecycle, provider session/generation, domain state, Task, Workflow, Schedule, Resource lease, Observation/Evidence를 분리한다. 각 데이터의 owner·수명·저장·정합성·복구·보존·마이그레이션을 정의한다.
• [ ] P3.10 — 실행·상태전이·자원 모델: admission → 최신 정책/상태 재확인 → 자원 확보 → 실행 claim → provider 호출 → 관측 → 완료/실패/취소 → 결과와 Evidence → 자원 반환의 전이와 불변조건을 sequence/state diagram으로 정의한다. ACK와 물리 완료 판정 근거를 구분한다.
• [ ] P3.11 — Provider/MCU/HAL 계약: 각 소비 Port의 소유자, 단위·범위·방향, readiness, 세대/요청 ID, callback 수명, timeout·오류·재연결·safe-stop, mock 가능 범위를 정한다. F가 하드웨어 상세를 작성하고 소비 계층 owner가 계약을 공동 검토한다.
• [ ] P3.12 — 공통 품질·운영 구조: 지연·처리량·메모리·스레드·동시성 budget, health/diagnostics/observability, 장애 격리·재시작·재관측·복구·로그 상관 키를 요구 수준과 계층별 책임으로 구체화한다.
• [ ] P3.13 — 제품 빌드·이관·전환 구조: SDK/server/host/Root/provider artifact 의존, 제품 variant 탑재·서명, 구·신 경로 공존, 데이터/설정 호환, 단계 활성화·rollback 조건과 담당자를 정의한다.
• [ ] P3.14 — 검증 아키텍처: 각 계약/불변조건에 unit·contract·module boundary·process integration·AOSP image·board/device 시험을 매핑한다. 가짜 provider로 증명할 수 있는 항목과 실제 장비가 필요한 항목을 분리한다.
• [ ] P3.15 — 통합 설계 묶음 발행: context/topology/module map, API/provider contract, domain owner catalog, state/sequence, threat model, NFR/operation, migration/test plan, ADR와 요구 trace를 같은 revision으로 묶는다.

완료 산출물: 승인된 요구/품질 trace, 최소 2개 구조 대안 ADR, HLD 및 계층별 LLD, API/IPC/provider 계약, owner catalog, 상태/data/sequence 모델, threat model, NFR·운영·전환·검증 계획이 서로 같은 revision을 가리킨다.

설계 · 4. 구현 전 설계 검토 및 착수 gate

• [ ] P4.1 — 추적성·설계 완결성 리뷰: P0 요구 ID마다 Blueprint·설계 section·owner·검증 case가 연결됐는지 확인하고, orphan 설계와 무근거 요구를 표시한다.
• [ ] P4.2 — 구조·배치·의존성 리뷰: 프로세스/파티션/부팅 구조, Android 경계, dependency direction, Runtime 조립, 단일 owner 원칙을 A와 B–F reviewer가 대안 대비 검토한다.
• [ ] P4.3 — 계약·상태 모델 리뷰: 공개 API/Binder/provider 계약, 오류·버전·권한, lifecycle/Task/Workflow/Resource/Evidence 상태와 소유권을 소비자·제공자 양쪽이 검토한다.
• [ ] P4.4 — 보안·안전·장애 시나리오 리뷰: 비인가 UID, 오래된/중복/역전 callback, binder/process/provider death, 부분 자원 확보, cancel timeout, 재부팅 복구, safe-stop 시나리오의 대응과 관측 근거를 확인한다.
• [ ] P4.5 — 성능·운영·전환 검토: quality scenario의 수치와 측정법, 관측성, build/image 구성, data migration, feature activation, rollback을 검토한다.
• [ ] P4.6 — 하드웨어 전문 설계 승인: F가 단위·범위·보드/driver/HAL 수명·동시성·오류·복구·SELinux와 실제 검증 조건을 승인한다. hardware consumer는 이 계약을 동시에 승인한다.
• [ ] P4.7 — 독립 계층 리뷰 및 위험 종결: 작성자와 다른 reviewer가 각 산출물을 읽고, finding을 요구/ADR/계약 수정 또는 승인된 위험으로 종결한다. 차단 항목은 담당자와 결정자를 기록한다.
• [ ] P4.8 — 설계 baseline/G1 승인: A는 trace와 문서 revision을 묶고 B–F는 자기 계층과 인접 계약에 서명한다. 제품 owner가 미결 위험·수용 기준·검증 환경을 승인한다.

Gate G1: 요구 추적 완료, 핵심 계약·상태·보안 설계 승인, HAL 전문 승인, 미해결 차단 위험 종결 전에는 대규모 구현을 시작하지 않는다.

구축 · 5. 6명 R&R·capacity와 구현 단위 확정

• [ ] P5.1 — 역할 역량 및 가용 시간 확인: 각 구성원의 Android/AOSP, SDK/API, framework/runtime, workflow, 제품 도메인, driver/HAL 경험과 투입 가능 시간을 확인한다.
• [ ] P5.2 — A–F 주담당과 검토자 지정: 아래 계층 경계에 실제 이름을 매핑하고, 단일 owner·backup·변경 승인자·peer reviewer를 지정한다. HAL 구현자는 검증 가능한 전문 역량을 확인해 배정한다.
• [ ] P5.3 — workload 기반 도메인 분해: P2 gap과 P3 catalog로 작업량·리스크를 산정한다. 규모가 큰 제품 도메인은 추가 contributor를 배정하되, 공통 계약과 domain owner는 유지한다.
• [ ] P5.4 — 실행 카드와 통합 순서 생성: 각 카드에 요구 ID, 산출물, owner/reviewer, 선행 카드, 계약 revision, 검증 명령/기준, 통합 조건, rollback을 적는다.
• [ ] P5.5 — 통합 기준선 승인: 브랜치/모듈 경계, artifact·환경·제품 revision, 주간 통합 주기, API/provider contract 변경 절차를 합의한다.

구축 · 6. 승인된 계층 계약 순서로 구현·통합

• [ ] P6.1 — SDK와 public contract 구현: versioned typed API, 호출·오류 의미, 호환 변환, 소비 앱 연동을 구현하고 contract test로 확인한다.
• [ ] P6.2 — Android platform/IPC 경로 구현: Binder 진입, 호출자 인증·권한, service host/system_server 연결, 제품 등록·부팅 연결을 구현하고 허용/거부 경로를 검증한다.
• [ ] P6.3 — 공통 framework runtime 구현: 조립·lifecycle·health와 승인된 State/Policy/Resource/Capability 소유 경계를 구현한다.
• [ ] P6.4 — execution framework 구현: Task/Workflow/Schedule 수명, admission, cancel/timeout/retry, persistence/recovery, 결과/Evidence correlation을 구현한다.
• [ ] P6.5 — provider/HAL 전문 구현: HAL 담당자가 승인된 provider 계약에 따라 하드웨어 경로를 구현·단위검증·보드 검증한다. 다른 역할은 HAL 소스 구현을 맡지 않고 계약 소비, mock/fake, 상위 통합 검증을 담당한다.
• [ ] P6.6 — 제품 도메인 vertical slice 구현: 승인된 요구 우선순위대로 도메인을 묶어 caller→권한→정책/자원→domain→provider→관측/Evidence→제품 결과까지 세로로 통합한다.
• [ ] P6.7 — 기존 동작 이관: 보존 동작, 구·신 경로 공존 기간, 데이터/설정 변환, 중복 제어 방지, 제거 조건을 slice별로 구현한다.

검증 · 7. AOSP 통합, 검증, 전환 및 제품 인수

• [ ] P7.1 — 코드·계약 검증: unit, contract, 경계 규칙, 상태/동시성, persistence, fake/mock provider, 호환성 검증을 수행한다.
• [ ] P7.2 — Android/AOSP 제품 빌드 검증: 실제 variant에서 SDK·server·host·Root·HAL package를 빌드하고 탑재 위치, signing, permission/SELinux, 부팅 준비 상태를 확인한다.
• [ ] P7.3 — 통합·장애·성능 검증: 프로세스/Binder/provider 재시작, stale·중복 callback, 자원 경합, 실패·취소·복구, 지연·메모리·스레드·보안 수용 기준을 확인한다.
• [ ] P7.4 — HAL/보드 및 실기기 인수: HAL 전문 담당자가 보드 입출력과 오류 동작을 확인하고, 제품 담당자가 실제 시나리오의 성공·거부·취소·복구를 상관 로그 및 장치 관측으로 승인한다.
• [ ] P7.5 — 단계적 전환·rollback 리허설: 활성화 단위, 감시 지표, 중단 기준, 기존 경로 복귀 절차를 실제 이미지/장치에서 연습한다.
• [ ] P7.6 — 제품 인수 및 운영 이관: 요구사항별 증거, known limitation, source/image revision, 진단·복구 절차를 묶어 제품 owner가 승인한다.

최종 완료 조건: 승인된 요구사항이 Blueprint와 설계·검증 증거까지 추적되고, 제품 이미지/실기기에서 실제 기능 결과 및 실패·복구 기준이 확인되며, 안전한 전환과 운영 인계가 승인돼야 한다.

A–F 책임 경계 및 아키텍처 R&R

A–F는 층별 결과 owner다. 설계 문서 전체를 A가 혼자 작성하지 않는다. A는 통합 모델·요구 추적·ADR 프로세스를 소유하고, B–F는 자기 기술 경계의 설계 author와 구현 owner를 겸한다. 인접 계층 계약에는 단일 accountable owner와 양쪽 공동 승인이 필요하다.

아키텍처 work package 작성·검토 책임

R&R 운용 규칙: 각 문서/결정에 A(Accountable) 1명 + R(작성 책임) 1명 이상 + 다른 계층 reviewer를 기록한다. 설계 품질은 산출물 author가, 전체 정합성과 누락 추적은 A가 책임진다. 변경된 계약의 제공자와 소비자는 모두 승인해야 하며 어느 한쪽도 상대 경계를 대신 승인하지 않는다.

도메인 분배: E는 domain catalog와 end-to-end 통합 기준을 관리하되, 15개 도메인의 구현 담당을 혼자 맡지 않는다. P5 역량/capacity 조사 뒤 B–E 중 도메인에 맞는 기여자를 배정하고 각 세부 카드에 domain author, provider consumer, reviewer를 지정한다.

HAL 인력 원칙: F에는 HAL/driver 구현과 보드 검증 역량이 확인된 한 명을 구현 owner로 지정한다. 나머지 구성원은 하드웨어 요구·Port 소비·fake/mock·통합 검증을 맡는다. F의 용량이 부족하면 범위·일정을 조정하거나 전문 인력을 추가한다.

관리·R&R 운영 규칙과 참조

• 기본 업무 행은 대분류 → 소분류 → 세부사항 → 담당 역할 → 상태 → 완료 산출물/수용 기준으로 관리한다. 실제 이름은 팀 역량 확인 후 A–F 역할에 매핑한다.
• 작업 카드에는 요구사항 ID, owner/reviewer, 선행 작업, 산출물, 완료 기준, 검증 증거 위치를 포함한다. 세부 구현 티켓은 상위 소분류 ID와 연결한다.
• 상태는 위 관리 표준에 정의한 네 값만 사용하며, 완료는 산출물과 검토 증거가 있을 때만 지정한다. 일정이 정해지기 전 날짜를 임의로 채우지 않는다.

• HAL 구현은 전문 담당자 한 명을 owner로 지정할 수 있으며, 다른 역할은 HAL 계약을 소비하고 상위 통합 검증을 수행한다.

• 체크 항목은 전부 미착수 계획이며, 증거가 확인되기 전에는 완료로 바꾸지 않는다. 상세 진행상태는 별도 evidence ledger에서 revision·명령·결과·로그·미검증 범위를 기록한다.

• Blueprint는 P0 제품 요구에서 파생·수정·승인되는 설계 문서다. 현행 코드와 과거 리팩터링 문서는 제약·전환 evidence로만 활용한다.
• HAL 구현은 전문 담당의 책임이다. 공통 역할은 HAL 계약을 소비하고 모의/통합/제품 인수 검증을 맡는다.
• 독립 구현은 G1 통과 및 API/provider 계약 고정 뒤에 시작한다. 계약을 바꾸면 영향 계층 owner와 함께 ADR·계약·검증을 갱신한다.
• 사용자 작성 SKIX Framework Blueprint 초안 — 요구 검토 후 개정할 설계 입력
• 상세 구성요소·도메인 Atlas — 현행/후보 구성 조사 참고
• TaskManager 사양 — 실행 요구를 확인할 참고 자료
• 실제 리팩터링 진행 현황 — 승인 요구와 대조할 현행 evidence 입력

Connections

• Framework SDK 허브
• 사용자 작성 SKIX Framework Blueprint 초안
• 실제 리팩터링 진행 현황