SKIX Framework Blueprint WBS — 한눈에 보기
이 문서는 브랜치 머지 목록이 아니라, 제품 공통 Framework를 정하고 만들어 검증하기 위한 업무 목록이다. 제품 요구를 확인하고, 현재 SoC 코드를 조사한 뒤, Blueprint를 승인하고, 담당·작업 순서를 정해 기능을 구현한 다음 제품 이미지와 보드에서 확인한다.
프로젝트 전체 업무 목록 — 무엇을 만들고 확인하나
아래는 프로젝트를 실제 업무 묶음으로 나눈 지도다. 번호를 기준으로 담당 지정과 진행 공유를 할 수 있고, 세부 번호의 완료 기준·산출물은 상세 TODO에 있다. Blueprint를 정하고 승인하는 일이 먼저이며, 구현·제품 탑재는 승인된 범위만 진행한다.
| NO | 대분류 | 소분류·세부 업무 묶음 | 완료할 결과 |
|---|---|---|---|
| 1 | 분석 — 제품 요구 | 1.1 대상 제품·보드·Android 버전 정리<br>1.2 앱·Agent 등 사용 주체 확인<br>1.3 사용자 시나리오 작성<br>1.4 기능별 필수·선택·제외 구분<br>1.5 요구별 완료 판정 방법 정리<br>1.6 응답시간·복구 등 품질 기준 설정 | 제품 범위, 요구 목록, 수용 기준 |
| 2 | 분석 — 현재 SoC 조사 | 2.1 앱에서 장치까지 실제 호출 경로 추적<br>2.2 기능을 실제 실행하는 코드·프로세스 확인<br>2.3 API와 사용하는 앱·모듈 연결<br>2.4 상태·저장 위치와 데이터 원천 확인<br>2.5 서비스 시작·권한·재시작 방식 확인<br>2.6 소스부터 SDK/APK/이미지까지 빌드 경로 추적<br>2.7 HAL/MCU 명령·응답·오류·재연결 조사 | 파일 경로·호출자 근거가 있는 현행 지도와 차이·위험 목록 |
| 3 | 설계 — Blueprint와 구조 | 3.1 Blueprint를 요구와 대조해 수정<br>3.2 전체 구조도 작성<br>3.3 계층별 책임과 호출 방향 정의<br>3.4 기능별 실행 담당 한 곳 지정<br>3.5 상태·저장·완료 결과의 주인 지정<br>3.6 앱 공개 API와 내부 호출 구분<br>3.7 Binder 호출자·권한·입력 검사 정의<br>3.8 Android 서비스 위치·기동·복구 설계<br>3.9 실제 폴더·패키지와 책임 연결<br>3.10 Soong/Gradle 모듈과 허용 의존 정의<br>3.11 Manager·Service 등 이름 사용 규칙 정의<br>3.12 접수·거절·실행·중단·완료 흐름 정의<br>3.13 HAL/MCU 업체 계약과 오류 규칙 정리<br>3.14 보안·성능·진단 기준 작성<br>3.15 결과물 형식과 제품 탑재 위치 결정<br>3.16 구조 대안·결정 이유·미결 위험 기록<br>3.17 설계 리뷰와 Blueprint 승인 | 승인된 Blueprint, 책임표, 구조도, 결정·위험 기록 |
| 4 | 설계·구축·검증 — 앱 공개 기능(SDK) | 4.1–4.4 앱에 제공할 기능·요청/결과·알림·호환 규칙 정의<br>4.5 SDK 구현·배포<br>4.6 실제 앱에 연결<br>4.7 SDK와 기존 앱 호환 시험 | 버전이 붙은 SDK와 앱 연결·호환 증거 |
| 5 | 설계·구축·검증 — Binder 통신과 접근 권한 | 5.1 현재 서비스·AIDL·호출자 조사<br>5.2 신원·권한·입력 검사 정의<br>5.3 필요한 IPC만 선정<br>5.4 서비스 등록·AIDL 연결<br>5.5 결과 알림 해제·시간 초과·프로세스 종료 처리<br>5.6 허용/거절 호출과 재시작 시험 | 서비스 호출 계약, 권한 설정, IPC 시험 결과 |
| 6 | 설계·구축·검증 — Android 서비스 기동 | 6.1 현재 부팅·서비스 시작 방식 조사<br>6.2 프로세스·partition 배치 결정<br>6.3 서비스 준비·종료·재시작 방식 구현<br>6.4 서비스 연결·장애 복구 확인 | 제품 부팅 뒤 서비스 기동·복구 증거 |
| 7 | 설계·구축·검증 — 공통 실행 기능 | 요청 접수·상태·취소·완료, 권한 정책, 자원 충돌, 공통 기록 중 실제 여러 기능이 쓰는 것만 정하고 구현 | 여러 기능이 공유하는 코드와 계약시험 |
| 8 | 설계·구축·검증 — AMR 이동 | 이동·정지·위치 요구 확인 → 장치 명령·완료 규칙 정의 → 앱부터 AMR까지 연결 → 접수와 실제 완료/정지 구분 시험 | AMR 수직 경로와 장치 결과 증거 |
| 9 | 설계·구축·검증 — Cleaning·예약·SafeCare | 청소·예약·인증·중단 요구 확인 → 실행 담당·결과 규칙 정의 → 제품 경로 연결 → 중복·취소·실제 중지 시험 | Cleaning 수직 경로와 중단·완료 증거 |
| 10 | 설계·구축·검증 — 배터리·센서 상태 | 실제 필요한 상태와 값 출처 확인 → 단위·갱신·오래된 값 규칙 정의 → 조회/알림 연결 → 값 누락·오류 시험 | 승인된 상태 조회·관측 경로와 시험 결과 |
| 11 | 설계·구축·검증 — IoT·외부 Agent | 제품 요구가 승인된 연결만 대상으로 삼고, 외부 요청·권한·재시도·장치 응답을 정의·연결·장애 시험 | 외부 연결 계약과 승인 기능의 시험 결과 |
| 12 | 설계·구축·검증 — DeviceAgent·HAL·MCU | Android 연결 코드와 보드 구현 경계 정의 → 명령·상태 연결 → 업체 규격과 보드 동작 대조 | 장치 연결 규격·연결 코드·보드 확인 자료 |
| 13 | 설계·구축·검증 — 데이터·설정 | 저장할 값·주인·위치·보존기간 결정 → 필요한 저장만 구현 → 업데이트·초기화·재부팅 확인 | 데이터 배치·보존·초기화 결과 |
| 14 | 구축·검증 — Soong 빌드·제품 이미지 | 빌드 모듈·산출물 선택 → 승인 파일을 제품 설정에 연결 → 빌드·서명·이미지 포함·부팅 확인 | 재현 가능한 빌드와 이미지 확인 기록 |
| 15 | 설계·구축·검증 — 보안·운영·진단 | 호출 권한·민감정보·로그·장애 격리·복구 규칙을 정하고 적용·시험 | 보안 설정과 운영 진단·복구 증거 |
| 16 | 검증·인수 — 계층부터 보드까지 | 자동시험 → 앱/Binder 통합 → 제품 빌드/이미지 → 실기기·장기 시험 순으로 증거 확인 | 통과·실패·미검증 목록, 잔여 위험, 인수·원복 기록 |
| 17 | 구축 준비 — 여섯 명 역할·실행 순서 | 주담당·지원·검토자 지정, 작업 순서·통합 기준·기준선 정리 | 여섯 명 책임표와 실행 계획 |
중요한 순서: 1–3번에서 제품 요구·현행 구조·Blueprint를 정하고 승인한다. 그 다음 4–15번에서 승인된 기능만 구현한다. 16번에서 앱·제품 이미지·실기기 증거로 판정한다. 17번은 이 작업을 누가 어떤 순서로 맡을지 정한다.
소스 폴더 기준으로 찾기
전체 TODO에는 19개 업무 구역, 201개 세부 번호가 있다. 위의 1–17번은 제품 요구부터 담당 배정까지의 업무이고, 상세 문서의 18번은 실제 SoC 폴더·빌드 경로별 할 일, 19번은 AMR·Cleaning·상태·외부 연결 등 기능별 할 일이다. 한 항목은 설계/구축/시험으로 나눠 담당·상태·완료 결과·업체 확인을 기록한다. 이 목록은 브랜치 머지 목록이나 제품 완료율이 아니다. 201개 상세 TODO 전체 보기.
| 실제 SoC 소스 위치 | 여기서 확인할 업무 | 상세 WBS 번호 |
|---|---|---|
base/core/java, base/core/aidl |
앱이 쓰는 공개 기능·모델·Binder 계약 | 4–5, 18.1–18.8 |
base/compatibility/java, base/compatibility/aidl |
기존 앱과 IPC를 새 계약에 연결 | 18.9–18.12 |
services/core/.../control, execution |
공통 요청·정책·자원·상태와 작업 수명 | 7, 18.13–18.20 |
services/core/.../domain/* |
실제 기능별 코드와 실행 책임 | 8–12, 18.21–18.24, 19.1–19.24 |
services/core/.../entrypoint, integration |
Binder 진입 확인과 DeviceAgent/HAL/MCU 연결 | 5, 12, 18.25–18.32 |
services/runtime |
Android 서비스 조립·기동·장애 복구 | 6, 18.33–18.36 |
Android.bp, core/tests, services/tests, data/ |
빌드·시험·제품 설정·저장 검증 | 13–16, 18.37–18.48 |
여섯 명의 주관 책임
| 담당 | 주관하는 업무 | 책임의 경계 |
|---|---|---|
| M1 — 시스템 구조·Blueprint | 제품 요구, 현재 구조 조사, 전체 Blueprint와 리뷰 | 기능별 실행 코드를 모두 맡는 것이 아니라, 책임 경계와 결정 사항을 통합한다. |
| M2 — SDK·앱 계약 | 공개 API, AIDL/Binder 계약, 앱 호환 | 제품 기능의 실제 장치 동작을 대신 소유하지 않는다. |
| M3 — 공통 제어·실행 | 실제 여러 기능이 공유하는 요청·정책·자원·상태·저장 | 공통화 근거가 없는 기능별 로직을 끌어오지 않는다. |
| M4 — AMR 기능 | 이동·정지·위치·완료 결과 | AMR 요청부터 장치 결과까지 기능 단위로 책임진다. |
| M5 — Cleaning 기능 | 청소·예약·SafeCare 요청과 결과 | 청소 요청부터 중단/완료 확인까지 기능 단위로 책임진다. |
| M6 — Android 제품 통합 | 서비스 기동, product/build, 이미지, 통합 시험 | HAL 내부 구현은 지정된 BSP/HAL 담당과 경계를 나눈다. |
| BSP/HAL 담당 | MCU/HAL 구현·장치 규격·보드 증거 | 여섯 명 모두가 HAL 내부를 구현하는 방식으로 배정하지 않는다. |
진행률과 상태를 읽는 법
- 2026-09-30 기준 상세표 201개 업무 중
167 미착수,28 자료 일부 있음,5 범위 확인/초안 정리 필요,1 초안 리뷰 필요다. 이 수는 업무 준비 상태의 개수이며 전체 진행률 퍼센트가 아니다. - 상세 TODO의
미착수,자료 일부 있음,범위 확인 필요,초안 리뷰 필요,진행 중,완료,범위 제외는 업무 산출물 기준으로 관리한다. - 코드가 존재하거나 브랜치 머지가 끝난 것만으로 Blueprint 승인·제품 이미지·보드 시험 완료로 세지 않는다.
- 업무 완료에는 해당 줄에 적힌 산출물과 필요한 리뷰/시험 근거가 있어야 한다.
- 실기기 자료가 없는 장치 항목은 지우지 않고
업체/보드 자료 필요로 남겨, 필요한 의존성을 드러낸다. - 퍼센트는 중요도와 수용 기준을 팀이 합의한 뒤 계산한다. 항목 수만으로 전체 진행률을 주장하지 않는다.