← Docs hub

2026-10-08 최신 전체 현황: 12개 구역 · 97개 할 일과 진행 단계. 소스 연결과 기기 인수를 분리해 기록했습니다. 아래 날짜가 앞선 상태 설명은 당시 이력이며 최신 완료 판정은 새 표를 기준으로 확인하세요.

SKIX Framework 브랜치 정합 — 구조·진척·다음 작업

현재는 팀 SDK와 제품 앱을 우리 구조에 맞추는 작업을 진행 중이다. Framework 패키지를 com.sk.intellix 기준으로 바꾸고 새 SDK·Host·소비 앱의 소스와 APK 빌드를 맞췄다. 현재 제품 실행 owner는 유지된다. 과거 기기 검증 이력과 별도로, 새 namespace의 debug Host에서 실제 Android 서비스 바인딩 2건과 관측 Parcel 전달 6건을 확인했다. 이 검사는 같은 프로세스에서 수행했으며 운영 제품 앱의 관측 전달 검증은 남아 있다. 새 바이너리는 QSSI 작업 저장소의 선택 APK 11개에 반영했다. 별도 AOSP 후보 입력까지 반영했으며, 운영 AOSP 적용·전체 이미지 생성·제품 자동부팅·운영 IPC 및 실센서 동작은 남아 있다.

최근 소스 정리: Host의 TTS, Pairing의 BLE, IoT·WSS의 listener/worker 수명 정리에 이어 Launcher의 초기 상태 전달, Launcher2의 공기질 샘플 처리를 정합했다. DeviceAgent는 실행하지 않은 지도 요청을 접수 성공으로 반환하지 않도록 수정했다. Runtime 팬과 ICT 팬의 거절 응답, ICT 하위 진단 상태의 결과 전달도 정리했다. 새 추상화나 실행 owner는 추가하지 않았다. 이어서 MCU 패킷 길이와 이동 좌표 검증을 보강했다. 지도·Runtime Adapter와 하위 AMRAgent 차이를 분류했고, SafeCare의 해제된 충전소 listener가 늦게 호출되는 경로도 정리했다. 현재 호출되지 않는 AMR Adapter 이동 경로의 입력 보호는 소스에서 검증했으며 제품 APK 동작 변경과 구분한다. 콜백 caller 번호의 범위 검사를 수정했고, DeviceAgent가 사용하는 공통 서버 소스 14개만 Gradle·Make에 포함하도록 빌드 경계를 고정했다. DeviceAgent의 전체 조립 차이를 대조하고 Wi-Fi 감시자와 상위 종료 경로의 해제 누수를 수정했다.

이번 WSS 정합: EventAsset 연결이 일시적으로 끊겨도 등록을 유지하고, 연결이 폐기되면 해제 후 다시 연결한다. 인증 접수가 거절되면 남은 요청 ID를 정리해 다음 감지가 다시 시도할 수 있게 했다. 호출되지 않는 DeviceAgent 업로드 래퍼 7개를 제거했으며, 업로드 책임은 기존 EventAsset 서비스에 두고 typed 경로와 기존 AIDL 계약은 유지했다. 새로운 Service·계층은 추가하지 않았다.

이번에 이어서 반영한 내용: WSS 순찰 상태와 인증 처리가 같은 잠금을 사용하도록 정리했다. 인증 timeout은 일반 화면 작업 정리로 지워지지 않게 분리하고, 재개 시 기존 순찰 정책을 거치도록 수정했다. 종료 시 예약 취소·상태 초기화를 복원했고, 저배터리 뒤 기본 순찰을 재개할 수 있도록 상태 누락을 보완했다. 얼굴 인증은 시작한 요청 ID를 보관해 이전 요청의 콜백이 새 요청을 중단·승인·통지하지 않도록 했다. 이 변경들은 기존 DeviceAgent 실행 책임 안에서 처리했으며, 공통 domain 서비스로 실행 책임이 이관된 것은 아니다.

현재 테스트 환경: 기기는 연결이 끊겨 있어 테스트를 보류했다. 앞의 기기 결과는 이전 검증 이력이다. 인터넷은 재연결됐으며, 이번에는 소스·로컬 테스트·Release APK·제품 빌드 입력까지만 확인했다.

이번에 달라진 제품 경로

완료 기준은 분리한다: 소스 수정·단위 테스트·APK 빌드·후보 입력은 확인했지만, 운영 APK 교체·다른 프로세스의 Binder 연결·실센서/장치·전체 이미지 부팅은 아직 남아 있다. 위 검사는 변경별 묶음이며 전체 완료율로 합산하지 않는다. 실행 책임을 Domain Service로 옮기는 Phase 2도 진행 완료 상태가 아니다.

팀원 정합 확인: 9개 소비 앱의 추적된 비Java main 파일 1,318개를 대조했다. 경로 부재 2개는 기존 IoT IPC 순번 충돌과 Launcher 리소스 병합으로 분류했다. EventAssetAgent·Launcher2는 Android가 합치는 리소스 이름 기준으로 확인해 새 기능 문구 누락·중복이 없음을 확인했다. 파일 일치율을 기능 완료율로 환산하지 않는다.

이동과 Task · 지금 연결된 경로와 남은 이관

현재 제품 이동: SDK의 moveTo() → DeviceAgent MovementCommandHandler → LegacyMovementGateway → 기존 실행 정책·장치 실행부. 귀환·일시정지·재개·중단은 공통 AmrOperations를 거쳐 기존 제품 실행부로 연결된다. 잘못된 좌표를 거절하는 이번 수정은 이 경로의 입력 검증이다.

공통 Task 이동: MovementServices에는 Task 접수·자원·세션·완료 경로가 구현돼 있다. 이를 제품에 연결하는 FrameworkHostComposition.withMovement(...) 구성도 있지만, 현재 Android Host는 관측용 기본 구성을 사용한다. DeviceAgent의 제품 이동 요청을 공통 Task로 보내고 실제 완료·중단 이벤트를 연결하는 이관은 남아 있다. 정책 접수나 명령 반환만으로 Task 완료를 만들지 않는다.

하위 AMR 연결 확인: 현재 이동 명령과 상태 변환은 실행 ID·장치 세대·이벤트 순번을 보존하지 않는다. 패킷의 currPart는 조각 번호다. 현재 Task ID를 늦은 콜백에 붙여 완료 처리하지 않으며, 펌웨어 확장 지원 여부도 미확인이다. 실행 책임 이관은 이 종단 계약과 기기 증거를 확보한 뒤 진행한다. 그동안 다른 제품 기능의 정합을 이어간다.

최신 DeviceAgent 빌드: 0.256, APK SHA-256 44e5e365267bcc01c882dde35a45a56a13c24a30ee9f285d6140e7a02fd4785f. QSSI와 별도 AOSP 후보의 입력 2곳에 반영했다. 운영 기기의 이전 확인 버전은 0.258이므로 운영 교체·배포 버전 정합은 아직 완료되지 않았다.

소스 근거: MovementCommandHandler, LegacyMovementGateway, LegacyAmrExecutionAdapter, SkixFrameworkHostService.onCreate(), FrameworkHostComposition, MovementServices. 검증 근거는 저장소의 skix-movement-coordinate-admission-evidence-2026-10-02.json, skix-mcu-packet-boundary-evidence-2026-10-02.json, skix-map-runtime-adapter-convergence-evidence-2026-10-02.json에 묶었다. 추가 WSS 근거는 skix-wss-whole-peer-convergence-evidence-2026-10-02.json, skix-eventasset-binding-lifetime-evidence-2026-10-02.json, skix-wss-verification-start-evidence-2026-10-02.json, skix-wss-upload-wrapper-retirement-evidence-2026-10-02.json이다. 전체 차이 분류는 정적 검토이며 기기·클라우드·전체 부팅 완료와 구분한다. 이번 묶음의 최신 근거는 skix-wss-monitor-convergence-evidence-2026-10-02.json, skix-wss-movement-error-convergence-evidence-2026-10-02.json, skix-wss-timeout-convergence-evidence-2026-10-02.json, skix-wss-state-cleanup-convergence-evidence-2026-10-02.json, skix-wss-face-session-convergence-evidence-2026-10-02.json이다. 최근 수정과 테스트 수를 전체 정합 완료나 실기기 성공으로 합산하지 않는다. 기존 계층·작업지도 SVG는 유지한다.

전체 작업지도 · 현재 구조에서 최종 모습까지

공통 System UI · 제공 서비스와 소비 앱의 경계

Launcher는 소비 앱, ProductSystemUI는 SKIX 공통 UI 제공 서비스다. Framework 구성의 책임 기준에는 SystemUI를 포함하고, 배포 기준에는 com.sk.productsystemui 독립 APK로 표시한다. services/core나 system_server로 UI 렌더링을 옮기는 작업을 뜻하지 않는다.

• 앱 → 공통 UI: SkixManager.systemUi() → SkixSystemUiManager → IProductSystemUi Binder → SystemPopupService. 팝업 요청과 상태바 정책을 전달하고 결과·내비게이션 이벤트를 받는다.
• 공통 UI → 상태 서비스: TopBarDeviceState가 장치 SDK를 조회·구독한다. 상태바는 표시를 소유하지만 배터리·장치 상태의 원본과 로봇 실행 책임은 소유하지 않는다.
• 현재 구현: SDK가 AIDL 계약을 단일 소유하고 팀원 SystemUI가 생성된 Stub을 구현한다. 부팅 receiver는 상태바를 시작하고, SDK는 팝업 서비스를 bind한다. 실제 부팅·overlay·앱 전환 회귀는 별도 검증이 필요하다.

소스 근거: systemui/README.md, SystemPopupService.java, TopBarService.java, TopBarDeviceState.java, AndroidManifest.xml, canonical SDK의 systemui/SkixSystemUiManager.java. Android 기본 com.android.systemui와는 별도 제품 서비스다.

왼쪽은 지금 동작 책임이 있는 곳, 오른쪽은 이관을 마친 뒤의 구조다. DeviceAgent에서 추출한 로직과 공통 서버의 Control·TaskManager·7개 Domain Service를 함께 표시했다. Launcher/2는 SDK 소비 앱이다. ProductSystemUI는 SKIX 공통 UI 서비스로 API를 제공하며, 독립 시스템 APK에서 실행된다. 제품 실행부와 HAL은 별도 계층이다. 폴더 기준은 skix-framework/base/ 아래 경로다.

짙은 청색은 해당 소스·빌드 묶음의 확인, 옅은 청색은 부분 구현·연결, 흰 점선은 남은 이관을 나타낸다. 소스·빌드 확인 → 이미지 입력 → 격리 기기 확인까지 근거가 있지만, 운영 제품 연결·전체 이미지·자동부팅·실제 장치 검증은 남아 있다. 전체 완료율은 검증 범위가 달라 계산하지 않았다.

계층 표현은 AOSP 공식 Architecture overview의 앱·Framework API·시스템 서비스·HAL·Kernel 구분을 참고했다. SKIX의 배치와 진척은 우리 소스를 기준으로 그렸으며, AOSP 기본 구성 자체에 SKIX가 포함된다는 뜻은 아니다. 기존 Android Layer 위에서 보는 SKIX 그림은 아래에 유지했다.

Phase 1 → Phase 2 · 목표·책임·WBS·예상 일정

Phase 1은 기존 제품 기능을 보존하며 팀원 소스와 빌드·제품 연결을 맞추는 단계다. Phase 2는 검증한 기능의 실행 책임을 공통 Framework로 옮기는 단계다. 현재는 Phase 1 진행 중이다. 공통 서버 구현은 일부 먼저 진행됐지만, 제품 실행 책임 이관이 완료된 상태는 아니다.

책임을 나누는 기준

아래 담당은 사람을 확정 배정한 것이 아니라 책임 역할이다. SYSTEM 6명의 실제 이름·역량 배정은 별도 합의한다. 한 사람이 여러 역할을 맡아도 기능별 주관 책임은 하나로 유지한다.

Codex는 위 역할별 코드 작업을 순서대로 수행한다. HAL 구현·보드 동작·제품 수용을 단독으로 승인하지 않는다. 자동 백그라운드 일정 실행을 약속하는 계획이 아니라, 실제 작업 세션에서 사용할 순서와 예상 소요다.

Phase 1 WBS · 팀원 정합과 제품 연결

목표 산출물: 팀원 기능 반영 목록 + 단일 SDK·APK 기준선 + 제품 빌드/부팅/기능 검증 기록. 기존 실행 owner를 유지해 구조 변경과 기능 회귀 원인을 분리한다.

Phase 1 통과 조건: 소스 대조나 APK 빌드만으로 통과하지 않는다. 전체 제품 구성·부팅·운영 IPC·핵심 기능 회귀와 복구 기준이 함께 확인돼야 한다. 현재 후보에 전체 AOSP 빌드 도구가 없고 원본 vendor Git 연결도 미정합이므로 1.4–1.6은 환경 연결 작업을 포함한다.

Phase 2 WBS · 공통 서비스가 실제 기능을 소유

목표 산출물: 앱 → SDK → Binder → Control/Task → Domain Service → Port/제품 Adapter → 장치로 이어지는 실제 제품 경로. Phase 1 기준선에 기능별 이관을 적용한다. 새 Planner·새 Domain 확대는 이번 범위에서 제외한다.

Phase 2는 기능별로 진행한다: 2.1 → 2.2/2.3 → 2.4 → AMR(2.5) → Cleaning(2.6) → 나머지 기존 기능(2.7) 순서다. 앱 전환·회귀 검증은 각 기능 이관마다 함께 수행하며 마지막에 몰지 않는다. 하나의 실행 owner를 두 번 활성화하지 않는다. Phase 1에서 Host 부팅을 확인해도 목표 system_server Root 구현까지 완료된 것으로 계산하지 않는다.

예상 일정 · 작업일 기준, 2026-10-02 작성

예상안이며 확정 납기가 아니다. 실측 처리량·미발견 기능 차이·전체 빌드 및 기기 가용 시간을 반영한 일정 기준선이 아직 없다. 아래 기간은 Codex가 집중 작업 세션에서 소스 구현·검토를 수행할 때의 초기 범위 추정이며, 6명 병렬 투입이나 24시간 자동 실행을 가정하지 않는다. W1은 다음 집중 작업 시작일부터의 첫 작업 주다.

Phase 1은 약 10–20작업일, Phase 2는 약 25–40작업일을 최초 계획 범위로 둔다. 작업 창에는 검토·수정 여유가 있어 기간을 단순 합산한 확정 종료일을 제시하지 않는다. 전체 이미지 빌드 환경·vendor 소스·장치 이벤트 규격이 확보되지 않은 기간은 별도 대기이며 종료일을 밀 수 있다. 첫 소스 묶음과 첫 실제 제품 빌드가 끝나면 예상안을 다시 산정한다.

지금 Codex의 다음 작업: Phase 1의 WSS 시작·중단 접수와 나머지 팀원 동작 차이를 대조한다. 최신 DeviceAgent APK는 44e5e365…이며 QSSI와 AOSP 후보 입력 두 곳에 반영했다. WssManager의 최근 수명·정책·얼굴 세션 수정은 각각 검토했지만 파일 전체 정합 완료로 올리지 않았다. 정적 검토 근거 62쌍·추가 연결 대상 13쌍은 전체 완료율이 아니다. 실제 DB·알람·팬·이동·보고 실행은 DeviceAgent가 담당하고, 공통 실행 owner 이관은 Phase 2에 남아 있다. 기기 연결이 끊겨 운영 설치·부팅·실센서 검증은 보류한다.

최근 근거: skix-command-runtime-wiring-evidence-2026-10-02.json, skix-entry-callback-convergence-evidence-2026-10-02.json, skix-product-schedule-peer-convergence-evidence-2026-10-02.json, skix-cleaning-current-review-applicability-evidence-2026-10-02.json. 소스 차이 75쌍 중 56쌍에 현재 검토 근거를 연결했고 19쌍은 추가 확인이 필요하다. 이 수치를 전체 기능 완료율로 환산하지 않는다.

한눈에 보는 진행 상황 · 2026-10-02

현재 위치: 소스 정합 → SDK·APK 빌드 → QSSI 작업 입력·별도 AOSP 후보 입력 반영. 원본 제품 트리 적용과 전체 이미지·부팅 검증은 아직 남아 있다. 파일 비교 수치만으로 전체 완료율을 계산하지 않는다.

다음 순서: ① 남은 제품 동작 차이 정합 → ② 실제 AOSP 제품 구성·Host 탑재 연결 → ③ 이미지 생성·자동부팅·운영 IPC 검증 → ④ 기능별 Domain 실행 책임 이관과 제품 검증. 기존 제품 실행 owner는 현재 유지한다.

최신 연결 점검 · DeviceAgent 관측 전달

수정 완료: 설치 ID는 com.sk.airbot.frameworkservice로 유지하면서 서비스 클래스는 com.sk.intellix.frameworkservice.server.entrypoint.service.*로 연결한다. 이전에는 설치 ID 뒤에 클래스 경로를 붙여 이름 변경 전 서비스로 연결하려던 오류가 있었다.

DeviceAgent 초기화에서 네 Publisher를 생성해 수신자로 등록한다. 종료 시 수신자를 해제하고 Publisher를 닫는다. 공통 worker가 연결·전송·재시도·종료를 담당한다. 이 표는 현재 소스의 관측 전달 경로이며 장치 실행 책임을 Domain으로 이관했다는 뜻은 아니다.

당시 관측 수정 묶음 확인: 실제 Publisher·worker를 실행하는 host 검사에서 잘못된 클래스 이름을 재현한 뒤, 4개 Manifest 대상과 서명 거절 검사를 통과했다. DeviceAgent unit 221건/43 suite와 Release 빌드가 성공했다. 당시 APK SHA-256은 909245fd19c64d64e5e3f00d74b6283fb02e15c85bfd86a380924cd354ea5f38이며 QSSI 작업 입력과 별도 AOSP 후보 입력에 반영했다. 실제 Make 선택도 양쪽에서 각각 1건 통과했다. 소스·산출물 각각 독립 명세 → 품질 검토를 마쳤다. 최신 resetDevice 수정 APK는 778376fd5eebec12c32e708470ecca52e253652a01fd1a7c7b2362b82b1dc376으로 두 입력을 갱신했으며 위 Phase 1 진행에 기록했다.

남은 확인: 운영 APK 교체, 새 Publisher의 실제 Binder 전달, 실센서·전체 이미지·부팅 검증. Android API를 대역으로 제공한 host 검사를 기기 성공으로 계산하지 않는다. 상세 근거는 저장소의 docs/refactor/skix-observation-component-evidence-2026-10-02.json에 기록했다.

기기에서 확인한 범위 · 제품 연결에 남은 조건

새 Host는 기기에서 생성·바인딩된다. 운영 DeviceAgent까지 새 관측 경로로 연결됐다는 뜻은 아니다. 기존 인증서와 대조한 최신 debug Host·테스트 APK를 설치하고 설치 SHA를 다시 확인했다. 운영 DeviceAgent·EventAsset은 교체하지 않았다.

운영 DeviceAgent의 현재 패키지 정보에는 ACCESS_SKIX_FRAMEWORK 권한 요청이 표시되지 않는다. 서명 일치와 UID1000만으로 제품 연결 성공을 판단하지 않는다. 실제 제품 경로를 확인하려면 최신 producer가 포함된 APK의 배포 버전과 권한을 먼저 맞춰야 한다. 같은 프로세스의 Parcel 검사를 kernel IPC나 물리 동작 검증으로 계산하지 않는다.

검증 근거: 저장소의 docs/refactor/skix-host-device-binding-evidence-2026-10-02.json과 docs/refactor/skix-product-observation-device-gap-2026-10-02.json. 두 묶음 모두 독립 명세 → 품질 검토를 마쳤다.

Blueprint와의 차이 · 설계 변경과 미구현을 구분

2026-09-10 상세 설계 이력은 보존 문서다. 당시의 DeviceAgent 집중 배치·범용 Task 제출 예시를 현재 목표로 그대로 적용하지 않는다. 목표 기준은 현재 Blueprint의 2·4·5·8절이다.

판단: 큰 설계 방향은 현재 Blueprint를 따르지만 목표 구조 구현이 끝난 상태는 아니다. 현재 APK Host와 기존 제품 owner를 최종 구조로 고정하지 않는다. 폴더 재배치·이름 변경·팀원 정합은 이관 준비이며, 서비스 실행 책임과 부팅 경계를 실제로 연결해야 한다.

이번 반영 · 제품명 없는 Framework 패키지

Framework 소스와 소비 코드를 새 이름으로 정리했다. 실행 책임 이관과 전체 브랜치 정합은 계속 진행 중이다.

IoT는 현행 소스의 dev·opr·mal_dev·mal_opr·stg 5개 변형을 빌드했다. 이전 문서의 4변형/10APK는 이전 묶음의 이력이다. 이전 namespace 묶음에서는 DeviceAgent unit 221건과 EventAssetAgent unit 393건이 통과했다. EventAssetAgent의 후속 전체 검사 396건은 아래 최신 확인에 별도로 기록한다. SDK AAR에는 새 Framework class 526개, 이전 Framework class 0개, 중복 class 0개이며 기존 DeviceControl class 17개는 유지된다. 독립 명세 → 품질 검토를 통과했다.

새 격리 APK로 기기의 PIN 8·중단 8·이동 4, 전송 계약 검사 20건을 실행했다. 일반 UID·설치 SHA를 확인했고 운영 DeviceAgent 0.258·EventAssetAgent 1.015는 교체하지 않았다. 메모리 Binder·대체 gateway 검사이므로 운영 Binder나 물리 동작 성공을 뜻하지 않는다.

이미지 입력 반영: a1-qssi-quber에서 Make가 선택하는 APK 11개를 새 namespace 빌드와 맞췄다. 교체 전 불일치 11건을 재현했고, 백업·실제 설치 ID·버전·플랫폼 서명 대조 후 교체하여 11건 모두 통과했다. 구 Launcher·IoT stg는 이번 이미지 선택 경로에 없어 제외했다.

원본 제품 트리의 남은 작업: 실제 빌드 트리 g13qcs6490/LA.QSSI.13.0.R1/vendor/quber는 별도 디렉터리이며 이번 입력이 연결되지 않았다. 이 트리에는 Host prebuilt 모듈도 없어, 제품 구성과 연결한 뒤 이미지·부팅·제품 IPC를 검증해야 한다. 아래 기존 부팅 증거는 namespace 변경 전 바이너리 기준이다. 지도 제출 요청의 mapMetadataPath 키는 compatibility 상수로 통합해 SDK 송신부와 DeviceAgent 수신부에 반영했다. 경계 검사 실패를 재현한 뒤 영향 host 8건, SDK unit 252건·DeviceAgent unit 221건과 Release 빌드를 통과했다. 기존 전송 문자열·거절 조건은 유지되며 DeviceAgent APK 해시도 이전과 같다. 실제 지도 파일 적용·기기 Binder·로봇 동작 검증은 별도다.

제품 입력 연결 · 후보와 운영 제품을 구분

별도 AOSP 작업 공간에 모듈 설정 10개·선택 APK 11개를 반영하고, 누락된 상위 quber.mk도 원본과 동일하게 복구했다. 실제 QSSI → Quber → 제품 선택 파일을 실행해 소스·프리빌트 두 방식에서 Host·EventAsset·SystemUI 선택을 확인했다. Host의 system_ext 배치·서명 설정·소스/프리빌트 중복 방지, Launcher 권한과 APK 선택을 합쳐 17개 입력 검사가 통과했다.

이는 후보 입력 정합이다. 원본 AOSP와 운영 APK는 바꾸지 않았다. 원본 vendor Git metadata가 없어 후보는 필요한 원본 파일을 복제한 별도 공간이며, 보드·HAL 상속과 전체 Kati/Soong 모듈 빌드는 아직 검증하지 않았다. 정본 근거는 skix-full-aosp-product-overlay-evidence-2026-10-02.json, skix-product-inheritance-evidence-2026-10-02.json이다.

Framework 소스 탑재 준비 · 후보 공간에 실제 입력 배치

후보의 vendor/quber/packages에도 Framework 소스 732개를 배치했다. SDK·공통 Host·서버 라이브러리와 빌드 설정·manifest·리소스가 대상이다. 다른 제품 앱은 앞서 검증한 프리빌트를 유지한다. 이전 소스 모드 검사는 임시 연결로 제품 선택만 확인했으므로, 이번 실제 소스 배치와 구분한다.

배치 도구는 지정한 입력만 복사하고, 임시 공간에서 해시를 검증한 뒤 반영한다. 기록 파일 생성에 실패하면 소스 디렉터리를 게시하지 않는다. 관련 검사 6건과 실제 AOSP bpfmt 문법·형식 검사를 통과했다. 정본 근거는 skix-aosp-source-inputs-evidence-2026-10-02.json이다. 이는 소스 탑재 준비이며 전체 Soong/Kati 빌드·이미지 생성·자동부팅 성공을 뜻하지 않는다. 원본 AOSP·운영 APK·팀원 저장소와 기존 SVG는 변경하지 않았다.

SafeCare 정합 · 반영한 동작과 남은 차이

팀원 코드에서 빠졌던 실제 호출 경로를 아래처럼 반영했다.

• 예약 접수: 접수 잠금 안에서 중단 상태를 확인해 새 예약의 저장을 막는다. 같은 실행 요청 ID의 재전송은 영속 접수 이력과 대조한다.
• 반복 예약 ID: 서버 예약 ID는 같은 예약을 나타내고, 실행 요청 ID는 이번 실행을 나타낸다. 팀원 방식에 맞춰 실행 요청에 UUID를 만들고 서버 예약 ID는 워커 등록 전에 따로 고정한다. 다음 회차를 과거 요청으로 취급하거나, 워커 대기 중 모델 변경으로 다른 예약에 접수하는 문제를 막는다. 응답 유실 시 자동 재전송하지 않는다. 상위 시스템의 중복 트리거 자체를 자동 판별하는 기능은 별도다.
• 메뉴 팝업: 배터리·네트워크 경고는 확인만, 작업 중단 선택에는 취소도 표시한다. 시작 화면과 공통 생성 함수를 사용한다.
• 화면·인증 안내: Splash 종료 제거와 인증 성공/실패 공통 Toast를 반영한다. Fragment·Context 검사와 스캐너 표시를 유지한다.
• 설정 사본: 위치 ID·이름·모드·반복 주기를 요청 사본에 보존한다. 원본과 사본의 목록 변경은 서로 영향을 주지 않는다.
• 종료 타이머: 시작 요청이 종료된 뒤 timeout을 다시 등록하던 문제를 재현하고 팀원의 active 요청 확인 조건을 반영했다. 종료 후 타이머 정리, 화면에 남는 실패 안내의 기한, 다음 요청의 독립성을 검사했다.
• 지역 판정: Malaysia에서도 availability가 허용이면 시작을 막지 않도록 팀원 코드와 기존 Launcher 순서에 맞췄다. 지역 제한 안내는 전달된 결과가 불가일 때만 표시한다. 실제 판정 코드의 허용·불가·미전달·null·미연결 분기를 두 지역에서 검사했고, 관련 host 회귀 7건을 통과했다.

Launcher 예약 ID 검증: 실제 요청 생성 테스트에서 같은 예약의 다음 실행이 같은 ID를 재사용하던 실패를 재현했다. 수정 후 Launcher unit 41건/22 suite와 Release 빌드, 워커 대기·접수 보호 host 4건, EventAsset의 기존 영속 접수 이력 선택 unit 20건/1 suite가 통과했다. 새 Launcher APK를 백업·서명·해시 확인 후 QSSI 작업 입력과 별도 AOSP 후보에 반영했고, Make 선택 검사도 각각 1건 통과했다. 이 검사는 운영 Binder·실제 순찰·부팅 완료의 증거가 아니다. 근거: skix-schedule-occurrence-evidence-2026-10-02.json.

Launcher 추가 정합 · 누락 동작 두 곳 복구

팀원 코드의 동작을 수용하면서 기존 null 입력·타입 기본값·화면 보호는 유지했다. 귀환 안내는 실제 helper·callback을 사용한 host 4건, AQM 목록은 실제 handler·정본 모델을 사용한 host 5건으로 확인했다. 최신 AQM 변경 기준 Launcher unit 41건/22 suite, failure·error·skip 0 및 Release 빌드가 통과했다. 이 테스트의 worker·Activity는 대역이므로 실제 센서나 Android 화면 동작이 검증됐다는 뜻은 아니다.

Launcher Java는 양쪽 380개이며 팀원 파일 누락은 없다. namespace 정규화 비교의 차이 13개는 실제 동작·보호조건·단순 표현 차이로 분류했다. 이 목록은 두 수정 전 비교 기준이며 전체 완료율이 아니다. skix-launcher-remaining-classification-2026-10-02.md, skix-return-guide-owner-evidence-2026-10-02.json, skix-launcher-aqm-list-evidence-2026-10-02.json에 판단과 검증 근거를 기록한다. 최신 Launcher2 APK SHA-256은 c52c9c8701182badba150f1f0fb1d9fdd33b3a77882c1df6e0ec68a072efdd83이다. 이 값은 후속 AQM 측정 입력 보호까지 포함한다. 백업·설치 ID·버전·플랫폼 서명을 확인해 QSSI 작업 입력과 별도 AOSP 후보에 반영했으며 Make 선택 검사도 각각 1건 통과했다. 원본 AOSP와 운영 APK는 유지했다. 앞선 예약 ID 검증은 해당 묶음의 이력으로 남기며 최신 APK의 전체 제품 검증으로 합산하지 않는다.

최신 확인: EventAssetAgent unit 396건/28 suite, failure·error·skip 0 및 Release 빌드 통과. APK 설치 ID·버전·플랫폼 서명을 대조하고 백업한 뒤 QSSI 작업 저장소의 EventAssetAgent 입력을 갱신했다. 최신 station listener 변경은 QSSI와 격리 AOSP 후보의 입력 2곳에 반영했고 Make 선택 검사가 각각 1건 통과했다. 최신 APK SHA-256은 71434607d7518066381494e525768b01abd63eece62aa0a8ce20a6002918b5aa이다. 교체·해제된 listener의 늦은 전달을 막으며 이미 실행 중인 콜백을 중단하는 기능은 아니다. Android Looper·운영 Binder·실제 화면·순찰·전체 이미지 부팅 검증은 별도다.

남은 11개 파일은 모두 미이관 기능이라는 뜻이 아니다. 빌드 대상 app/src/main/java는 양쪽 180개이고 팀원 누락은 없다. Framework namespace만 맞춰 비교하면 169개가 같고 11개가 다르다. 4개는 import·주석·메서드 배치 차이, 나머지는 이름 변경·Toast 소비 방식·재연결/인증 보호·제품 정책 차이를 포함한다. 이 수치는 기능 완료율이 아니다. 과거 370/372개 목록과는 조사 범위도 다르다.

실패 안내는 원인에 맞춰 유지한다. 팀원 코드는 시작을 막은 결과를 구독 실패 안내로 연결하지만, 현재 SDK의 PREVENTED 분류는 REJECTED·CANCELLED·EXPIRED를 모두 포함한다. DeviceAgent는 요청 취소나 기한 만료에도 이 상태들을 만든다. 따라서 구독 실패로 일괄 변경하지 않고 일반 실패 안내를 유지한다. 실제 시작 호출이 -1을 반환하는 기존 구독 안내·메뉴 복귀 경로는 별개로 보존한다.

시작 경고·idle 책임 대조: 메뉴 진입 안내와 실제 시작 직전 재검사를 구분하고, STOP 접수 뒤 idle 관측을 기다리는 보호를 유지했다. 기존 영향 unit 82건/3 suite를 확인했다. STOP 접수나 idle 관측만으로 물리 중단 완료를 뜻하지 않는다. 재연결 listener·오래된 인증/Toast callback 보호는 유지한다. 정본 근거는 skix-region-availability-evidence-2026-10-02.json, skix-resolution-timer-evidence-2026-10-02.json, skix-eventasset-remaining-classification-2026-10-02.md, skix-safecare-prevented-classification-evidence-2026-10-02.json 및 해당 SHA 기록이다. 실패 원인은 SDK SecurityPatrolRequestSnapshot.isPrevented() → DeviceAgent WssPatrolStartRequests.cancel()/refresh() → EventAsset SafeCareStartCoordinator.awaitStart()/resolved()의 실제 소스 흐름으로 대조했다.

새 SDK AAR SHA-256: de4ed30ae04c2eddcf0a227f33f3b54777c503b2a9d1d76e9d933354dc7c215c. 정본 근거: skix-framework-namespace-evidence-2026-10-02.json, skix-framework-namespace-image-evidence-2026-10-02.json, skix-map-metadata-wire-evidence-2026-10-02.json. 최신 AAR은 정본+7개 소비 경로에 반영했다. 타 소비 APK는 앞선 namespace 빌드 묶음이며 이번 상수 정리로 다시 빌드한 것으로 표시하지 않는다. 이름 변경을 Domain Service 실행 책임 이관이나 전체 정합 완료로 계산하지 않는다.

먼저 볼 것 · 목표와 현재를 구분

1. 목표: DeviceAgent의 이관 대상 기능은 Domain Service가 소유하고 DeviceAgent는 제품 연결·호환 adapter로 축소한다.
2. 현재 제품: Launcher/2는 SDK를 소비하며 ProductSystemUI는 공통 UI API를 제공하고, DeviceAgent·EventAssetAgent·IotAgent가 실행·연결을 담당한다.
3. 분리한 공통 서버: Control·TaskManager·7개 Domain Service가 있지만 현재 제품의 모든 명령이 이쪽으로 이동한 것은 아니다.
4. 확인 범위: SDK·소비 APK·Host 이미지 입력, 기기의 Host 초기화·합성 관측 Binder 전달·설치된 CameraBroker 상태 조회까지 확인했다. 전체 이미지 생성·자동부팅·실센서 및 기능별 실행 책임 이관은 남아 있다.

그림은 목표 구조 → 현재 이관 상태 → 공통 서버 내부 → 유지한 Android Layer → Core 기동 목표 → 현재 부팅 경로 순서로 읽는다. 클릭하면 원본 SVG를 확대할 수 있으며, 상세 폴더와 변경 이력은 아래에 둔다.

리팩터링 목표 · 기능 책임을 Domain Service로 이관

완료 방향은 DeviceAgent의 기능 책임을 Domain Service로 나누는 것이다. Domain이 상태·정책·실행 접수·관측 해석을 맡고, 장치·모델·화면의 실제 실행은 port와 제품 제공자로 연결한다. DeviceAgent는 필요한 legacy IPC·장치 연결·callback adapter 위주로 줄인다. 지금처럼 제품 owner가 모든 기능을 계속 소유하는 구조를 최종 상태로 두지 않는다.

Blueprint의 목표 배치는 system_server의 얇은 Root·부팅 연결부 + system_ext 독립 제품 Runtime의 공통·도메인 서비스다. SDK는 호출 앱에 놓인다. EventAssetAgent의 전문 실행·저장, SystemUI의 화면 등은 해당 owner를 유지하며 공통 서버에 중복 구현하지 않는다. 기능별 책임 이관은 실제 caller·계약·완료/중단 의미까지 함께 맞춰야 한다.

위 그림은 목표와 그 구간별 이관 진척을 보여준다. 아래는 현재 실제 소유권의 비교 그림이다. 현재와 목표를 한 실행 경로처럼 섞지 않는다.

현재 이관 상태 · 기존 제품 owner와 분리된 Core

왼쪽은 현재 제품의 실행 경로, 오른쪽은 분리한 공통 서버와 이미지 입력에 연결한 Host다. Host 탑재 설정과 일부 Binder 검증을 마쳤지만 기존 제품 명령 전체를 이관한 상태는 아니다. Launcher/2는 API 소비층, ProductSystemUI는 공통 UI 서비스 영역에 두고, DeviceAgent·EventAssetAgent·IotAgent의 실행 책임을 별도로 표시했다. 두 경로가 이미 하나로 통합된 것처럼 그리지 않았다.

공통 서버 내부 · TaskManager와 기능별 Service

base/core는 공개 SDK, base/services/core는 서버 로직이다. 서버 내부의 Task·Control·Domain·Runtime을 확대했다. 실제 Domain Service 7개는 유지하고, 사용하지 않는 생성자 골격 8개는 제거했다. 기존 제품 명령이 모두 TaskManager를 통과하는 상태는 아니다.

실제 폴더로 구조 읽기

skix-framework/base/
├── core/                 공개 Manager·모델·Task 계약, 내부 AIDL
├── compatibility/        기존 제품 IPC·Bundle·callback 변환
└── services/
    ├── core/java/.../server/
    │   ├── control/      상태·정책·자원·권한
    │   ├── execution/    Task 접수·실행권·기록·예약
    │   ├── domain/       AMR·Cleaning 등 기능별 서버 로직
    │   ├── entrypoint/   요청 검증·서버 진입 경계
    │   └── runtime/      공통 서비스 조립·시작·종료
    ├── runtime/java/     Android Service·Binder·관측 Gateway
    └── tests/            서버 로직·Android 경계 검사

core는 앱이 쓰는 SDK이고 services/core는 서버 로직이다. services/runtime은 서버를 Android에서 구동하는 연결부다. 실제 앱은 apps/DeviceAgent, apps/SKMLauncher2, apps/SkixFrameworkService 등에 있다. 빈 예약 폴더와 사용하지 않는 Service 골격은 제거했다.

내부 README는 base·Android runtime·SDK 패키징·DeviceAgent·Launcher2의 역할과 현재/목표/미검증을 설명한다. 다음 세션은 인수인계 → 해당 README → 작업 카드 → 필요한 소스 변경분 순서로 복구한다. 상세 로그와 SHA는 정합 기록에 둔다.

Android Layer에서 SKIX는 어디에 놓이나

왼쪽은 Android의 기본 계층이고 오른쪽은 우리 코드가 맡는 책임이다. 같은 높이에 놓였다고 같은 프로세스에 들어간다는 뜻은 아니다. 이 대응은 AOSP 공식 Architecture overview와 Android Platform architecture를 참고해 현재 코드에 적용했다.

두 개의 core를 구분하면 그림이 읽힌다: base/core는 앱의 공개 계약, base/services/core는 서버 로직이다. Binder는 이들 사이의 연결 방식이다.

리팩터링 후 부팅 목표 · Core Service 초기화

리팩터링의 기동 목표는 SKIX Host가 Core Service를 한 수명 아래 초기화하는 것이다. Core의 ManagerService마다 APK나 프로세스를 따로 띄우는 구조가 아니다. 목표의 얇은 Android Root·부팅 연결부가 제품 Host를 생성하면 Host 안에서 루트·저장·의존성을 조립하고 ServiceRegistry가 Core Service의 onStart()를 실행한다.

이 내부 초기화 코드는 이미 있다. 기본 구성은 Control·Task/Evidence와 Iot·AirQuality·Power·Cleaning 관측을 시작한다. 소스에 존재하는 Amr·Llm·Vision까지 모두 자동 활성화하지 않는다. AMR 실행은 withMovement와 장치 provider 연결을 명시해야 한다. FrameworkRuntimeHost가 전달하는 CORE_SERVICES(500)은 내부 수명 단계이며 Android의 SystemServer boot phase 자동 연결이 아니다.

아직 남은 부분은 제품 부팅 시작 경로, 공개 SDK/Binder 연결, 기능별 장치 adapter와 기존 owner의 실행 책임 이관이다. 위 그림의 점선은 이 목표 연결이다. 아래 그림은 비교를 위한 현재 제품 부팅 경로이며 목표 완료 상태를 뜻하지 않는다.

현재 코드의 부팅 · 기존 제품 경로와 bind 기반 Host

DeviceAgent의 잠금 전 시작, IoT·상태바의 부팅 완료 시작, EventAsset·공통 Host의 bind 기반 활성화를 구분했다. 각 컴포넌트의 onCreate()에서 의존 연결·외부 서비스 bind·runtime 초기화가 어떻게 이어지는지 그림 안에 표시했다. 서로 다른 APK 사이에 확정되지 않은 실행 순서는 그리지 않았다.

서비스 시작과 bind는 구분한다. AOSP 시스템 서비스는 SystemServer가 시작한다. APK의 Android Service는 시작 요청 또는 bind로 생성할 수 있다. 현재 SKIX는 Gateway가 Host에 BIND_AUTO_CREATE로 연결하고, Host의 onCreate()가 Core 객체를 조립해 lifecycle을 시작한다. onBind()는 Binder를 반환하며 내부 Task·State·Policy 서비스마다 개별 bind를 하지 않는다. 클라이언트 연결과 독립적인 제품 부팅·재시작 수명은 아직 확정·검증되지 않았다.

Android 공통 구간은 AOSP 부팅 설명·Zygote 설명·Direct Boot 설명을 참고했다. SKIX 구간은 현재 manifest·receiver·서비스 소스 기준이며 실제 기기 부팅 trace는 아니다.

그림 읽는 법: 배경색은 컴포넌트 종류, 테두리와 상태 문구는 확인 범위다. 실선 호출·제어, 파란 점선 callback, 녹색 점선 관측, 회색 점선 미완료 연결을 구분했다. 그림을 클릭하면 편집 가능한 SVG 원본을 확대할 수 있다.

정합 작업 이력 · 아래 SHA와 검증은 각 작업 당시 기준

현재 namespace와 입력 상태는 문서 상단을 기준으로 본다. 아래 기록의 이전 APK SHA·기기 결과를 최신 바이너리 검증으로 해석하지 않는다.

이번에 실제로 바뀐 부분

팀원 소스 정합에 이어 지도 거절 처리·ICT 초기화 방어·Host 이미지 입력을 반영하고, 관측 Binder와 설치된 CameraBroker 상태 조회를 기기에서 확인했다. SDK 정본과 기존 제품 실행 owner는 유지한다. 아래의 “확인”은 적힌 범위에 한정되며 전체 제품 완료율이 아니다.

검증을 세 단계로 구분한다. 소스 수준에서는 SDK 계약과 팀원 기능 차이를 정합했다. 이미지 입력 수준에서는 소비 앱과 Host의 APK·서명·제품 선택을 맞췄다. 기기에서는 Host 생성·관측 Gateway·설치된 CameraBroker의 실제 Binder 상태 조회를 확인했다. 이들을 전체 제품 완료율로 합산하지 않는다.

기기 결과: Framework Host와 테스트 APK를 설치해 계약 19개·Host 초기화 1개·권한 거절 1개를 서로 다른 실행 묶음에서 확인했다. 임시 플랫폼 서명 system UID 앱으로 별도 프로세스의 Power Gateway에 정상 관측3건을 전달하고 중복 순번·미래 시각·종료 후 호출3건을 거절하는 것도 확인했다. 임시 앱은 제거하고 서비스 정리까지 확인했다. 임시 앱의 권한 요청은 공유 system UID에 영향을 줄 수 있으므로 기존 DeviceAgent의 권한이나 전달 성공으로 해석하지 않는다.

CameraBroker 기기 결과: EventAssetAgent·Launcher2가 사용하는 AAR와 팀원의 AAR는 동일하다. 임시 플랫폼 서명 앱으로 설치된 Broker1.0.17에 bind해 원격 Binder descriptor와 isCameraRunning() 호출을 확인했다. 결과는 true였으며 프레임 조회·클라이언트 등록·카메라 시작 요청은 하지 않았다. 임시 앱 제거 후 기존 Broker·Vision 프로세스와 연결이 유지됐다. 현재 설치본과의 상태조회 IPC 호환성 근거이며 최신 소스·새 이미지 탑재·촬영 성공·Framework Vision 실행 책임 이관을 뜻하지 않는다.

이미지 입력과 설치본: 새 DeviceAgent/QSSI 입력은 90651aff82bcd804f07b059d0ce155dd58cba0147592ad061c71b70337b37b4c, Host Release/QSSI 입력은 e947a19c0a83aafc9dd620a26ffbf0cbe0047f13cb05b452998e112e22dbcd05다. SDK 정본 AAR은 d113cb90…로 유지했다. 기기의 기존 DeviceAgent0.258은 유지했고 새0.256은 설치하지 않았다. Host 기기 검사에는 Debug 플랫폼 서명 APK를 사용했으므로 Release 이미지 부팅 검증과 구분한다.

다음 작업: 남은 제품 caller 의미 차이 정합 → 새 DeviceAgent producer의 실제 관측 전달 → 이미지 생성과 자동부팅·장애 복구 → 기능별 실행 책임 이관. CameraBroker 제품 입력은 별도로 확보해야 한다. 공개 Task SDK 연결은 공유 UID의 caller·Task 소유권 정책 결정이 선행하며, 이를 우회해 공개하지 않는다.

Blueprint는 검토할 초안이다. 기존 제품의 실행 책임을 먼저 확인하고 필요한 계약을 수용한다. 전체 merge/rebase, 새로운 도메인 일괄 생성, Planner 구현은 이번 범위에 넣지 않는다.

DeviceAgent · 관측 연결과 검증 빌드 정합

제품의 기존 처리를 유지하면서 Framework 관측 실패를 분리했다. 새 APK와 QSSI 입력까지 반영했고, 기기에는 설치하지 않았다.

MCU 수신 → 기존 센서 갱신 + fan / AirQuality 관측
AMR 수신 → 기존 상태 처리 + Power 관측
IoT 연결 상태 → 기존 상태 저장 + IoT 관측
                              ↓
                     관측 실패는 각 호출에서 격리
                     제품 처리와 명령 반환은 계속

• 격리 검증 APK: 팀원 테스트가 요구하던 별도 패키지의 빌드 설정과 Manifest를 복구했다. 시스템 UID·제품 권한·제품 서비스를 제거한 APK와 테스트 APK를 생성했다. 관측 변경을 포함해 다시 빌드했다. 다만 아래 작업 큐·이동 거절·TTS/AMR·제품 서비스 종료 수정 전의 APK이며, 컴파일·Manifest 확인까지다. 기기 테스트 실행 결과는 아니다.
• MCU 관측: fan·AirQuality 콜백 각각의 실패를 격리했다. 실제 수신 분기 회귀 검사 4건과 Release 빌드가 통과했다. MCU 하위 소스 16개와 runtime 의존성 연결 32개는 팀원 동작을 유지한다.
• Power·IoT 관측: 관측 예외가 제품 콜백·명령 반환에 전파되지 않도록 수정했다. IoT 기존 상태 저장·빈 값 처리·원문 전달을 유지했다. 실제 분기 검사 3건과 단일 명령 담당·조립 검사 3건이 통과했다.

청소 시간 정책은 실제 팀원 메서드와 공통 정책을 20,000개 입력으로 대조했다. 이는 host 입력 비교이며 실기기 청소·팬 수명 검증은 아니다. IoT Binder는 기존 호출 순번을 보존한다. 팀원 파일을 그대로 복사해 호출 순번을 바꾸는 방식은 적용하지 않았다.

각 코드 변경은 독립 명세·품질 검토를 거쳤다. 최신 DeviceAgent Release와 QSSI 입력은 동일한 플랫폼 서명·동일한 SHA이며 이전 입력은 백업했다. 관측 실패 격리가 Domain Service로의 실행 책임 이관 완료를 뜻하지 않는다. Android·MCU·Binder·AWS의 실제 동작은 host 검사와 구분하며, 전체 이미지 생성·자동부팅·실센서 전달은 남아 있다.

DeviceAgent · 작업 큐와 콜백 정합

서로 다른 기능이 같은 큐 번호를 사용해 다른 작업까지 취소하던 문제를 수정했다.

WSS 명령       → 2000번대 ┐
                         ├→ 기존 공통 작업 큐 → 장치 명령 실행
Streaming 명령 → 3000번대 ┘

• 작업 큐: WSS 취소가 Streaming 작업을 지우거나 실행 상태를 잘못 조회하던 충돌을 host에서 재현했다. Streaming 번호만 분리했고, 5개 회귀 시나리오와 Release 빌드가 통과했다. 공개 IPC·명령 형식은 유지한다. 이 큐는 기존 제품 내부 큐이며 Framework TaskManager의 실행 수명 관리와 구분한다.
• 콜백·상태: 팀원 소스 7개를 실제 호출 경로와 대조했다. 청소 차단·특수 모드·조회·재부팅 처리를 유지한다. 오래된 테스트 조립 코드를 실제 Gate에 연결해 6개 차단 사례와 허용 경로를 확인했다. 테스트 복구이며 추가 제품 동작 변경은 아니다. 실제 Binder 콜백 전달은 별도 검증이 필요하다.
• Vision: 팀원 소스 6개의 동작 차이를 검토했으며 누락은 발견하지 않았다. 현재 확인한 QSSI 설정 51개에서는 CameraBroker 탑재 선언을 찾지 못했다. 전체 이미지에서 서비스가 없다는 판정은 아니다. 최신 소스 또는 제품용 APK 정본을 확인해야 한다.

최신 DeviceAgent Release와 QSSI 입력 SHA는 90651aff82bcd804f07b059d0ce155dd58cba0147592ad061c71b70337b37b4c로 같다. 플랫폼 서명 확인과 이전 입력 백업을 완료했다. 새 APK 설치·전체 이미지 부팅·실제 장치 동작은 아직 검증하지 않았다.

DeviceAgent · 실제 명령 결과와 연결 종료

미구현 이동 명령의 잘못된 접수 응답과 TTS·AMR·제품 서비스 연결 종료 결함을 수정했다. 네 변경 모두 소스·Release APK·QSSI 입력까지 반영했으며 기기에는 설치하지 않았다.

• 이동 접수: moveToSetLocation은 실행 코드가 없는데 빈 응답이 접수 성공으로 해석됐다. 기존 거절 응답을 반환하도록 수정했다. 실제 handler와 SDK 결과 해석을 함께 실행한 회귀 5개 및 영향 검사 4개가 통과했다. 새 이동 기능이나 완료 이벤트를 만들지 않았다.
• TTS 종료: Android 연결 해제 예외가 송신 스레드 정리를 중단했다. 해당 예외를 기록하고 나머지 정리를 계속하도록 수정했다. 실제 Binding·Session·Client host 회귀 6개, 관련 unit 54개가 통과했다.

• AMR 종료: 연결 해제 예외가 DeviceAgent 종료 흐름으로 전파됐다. 해당 예외를 격리하고 이전 callback 차단·단일 해제·재연결을 유지했다. 실제 AMRService·Lifecycle·CallbackRegistration host 회귀 4개, 관련 unit 23개가 통과했다.

• 제품 서비스 종료: IoT·Update·Pairing 연결 해제 중 하나가 실패하면 뒤 연결과 receiver·network 정리가 건너뛰어졌다. 세 unbind 호출만 실패를 격리해 나머지 정리를 계속한다. 실제 종료 메서드 host 6개가 통과했으며 정상 순서와 치명적 Error 전파를 유지한다. 다른 정리 단계의 모든 실패를 처리한 것은 아니다.

관측 publisher 4종은 DeviceAgent 생성·종료 흐름에 연결되어 있다. 이동은 RuntimePorts → AmrOperations → 제품 adapter, 청소는 CommandHandler → CleaningOperations → 제품 adapter를 실제로 호출한다. 이 경로는 공통 실행 로직을 제품에 연결한 상태이며, DeviceAgent의 실행 책임을 Domain Service로 모두 옮긴 상태는 아니다.

각 변경은 실패 재현과 독립 명세→품질 검토를 거쳤다. host에서는 Android·원격 전송 경계를 대역으로 처리했다. 실제 TTS 음성·AMR 장치·Binder 경쟁·새 이미지 부팅은 아직 검증하지 않았다. 앞선 기기 검사 결과를 이번 APK의 기기 검증으로 사용하지 않는다.

Binder 요청과 제품 초기화 정합

팀원 코드에서 빠졌던 Bundle 클래스 로더 설정을 복구했다. 예약처럼 SDK 모델이 들어 있는 요청은 첫 Bundle 조회 전에 DeviceAgent 클래스 로더를 지정한다. 실제 요청 메서드를 실행한 host 7개가 통과했고, 기존 null·빈 요청·일반 명령·권한 거절 응답을 유지했다. host의 Bundle 복원과 호출자 판정은 대역이다. 실제 Parcelable 전송·Binder 권한 검증은 남아 있다. Release 빌드·플랫폼 서명·백업·QSSI 입력 반영을 마쳤으며 새 APK는 기기에 설치하지 않았다.

제품 초기화도 팀원 본문과 대조했다. 서비스 연결과 부팅 명령 처리는 동일하며, 초기화에는 관측 전달 4종과 TTS 등록 관리가 추가됐다. MCU·설정 이관·청소 예약·SoundFlow·LCD·네트워크·OTA 초기화는 유지한다. 이는 소스 대조 결과이며 실제 Android 부팅 성공을 뜻하지 않는다.

익명 구현에서 adapter로 옮긴 동작

팀원 DeviceAgent에 모여 있던 설정·공기질·이동·복구·시스템·버전·제품 등록·시뮬레이션 구현을 adapter 15개, 메서드 158개와 대조했다. 검토 범위에서 빠진 메서드는 발견하지 않았다. 147개는 패키지 이름·주석·서식을 제외한 본문이 같고, 나머지 11개는 Context 사용·변수명·AMR 실행 연결 차이를 개별 확인했다. 독립 명세·품질 검토를 통과했으며 이번 대조에서는 제품 코드를 추가로 바꾸지 않았다.

이동의 기존 스테이션 복귀 분기와 일시정지·재개·중단 인자는 공통 AmrOperations → 제품 adapter 경로에서 유지한다. 158개는 전체 정합 완료율이나 실제 실행 성공 수치가 아니다. 내부 상태 저장 8개와 MCU 패킷 2개 본문은 같고, 팬·OTP·OTA·Pairing 전달도 기존 인수와 미연결·예외 처리를 유지한다. 전체 이미지 부팅·실제 장치 실행은 남아 있다.

명령 등록과 지연 실행 연결

양쪽 모두 명령 처리기 35개를 등록하고 실행 의존성 32개를 참조한다. 이 범위에서 팀원 등록이 빠진 곳은 없었다. 관측 전달 추가, 청소 의존성의 null 검증, 지도 생성자의 인수 순서 변경은 실제 연결과 일치한다. MainApi의 명령 진입·callback·MCU OTA 연결도 유지한다.

등록 순서가 달라진 구간은 실제 선택 조건과 Dispatcher로 대조했다. 179개 후보 문자열과 null·알 수 없는 명령을 확인했으며, 순찰 상태 조회는 의도적으로 Security에서 SecurityPatrol 처리기로 옮겼다. 같은 상태 조회 항목을 반환한다. 나머지 후보의 첫 처리기 선택은 유지한다. 이는 명령 선택 검증이며 각 처리기의 장치 실행 성공을 뜻하지 않는다.

지연 작업은 팀원 코드처럼 기존 MainHandler에 등록하도록 복구했다. 매번 새 Handler를 생성하던 차이를 제거했다. 실제 연결 람다의 host 2개가 수정 전 실패하고 수정 후 통과했으며, 명세·품질 검토와 Release 빌드를 통과했다. 플랫폼 서명·기존 입력 백업·QSSI APK 갱신을 확인했다. host의 취소 확인은 소유권 호환성 검증이며 제품 종료 때 취소가 구현됐다는 뜻은 아니다. Android Looper·새 APK 설치·부팅은 미검증이다.

실행 경계 복구와 남은 명령 대조

이번에 바꾼 코드: 오류 발생 후 스테이션 복귀가 팀원 코드와 같은 ExecutionPolicyGateway를 거치도록 복구했다. 기존 허용·부분 허용·거절 결과와 인자는 유지한다. 명령 전달 인터페이스 3개에는 팀원의 @FunctionalInterface를 복구해, 추상 메서드를 잘못 추가하면 컴파일 단계에서 잡도록 했다. 새 인터페이스나 계층은 추가하지 않았다. 두 변경 각각의 영향 host 검증·독립 명세/품질 검토·Release 빌드를 통과했고, 플랫폼 서명·백업·QSSI 입력 갱신을 확인했다.

코드가 이미 보존된 구간: 실행 의존성 32개의 필드·생성자·setter 연결, 상태/펌웨어/카메라/전달 6파일, 관리정보/진단/명령 전달/오류 4파일, 설정/등록/예약/LLM 12파일을 전체 소스 차이와 대조했다. 검토 범위에서 팀원 기능 누락은 발견하지 않았다. LLM의 명령·키·값 29개는 공통 상수를 재귀 해석한 실제 문자열이 팀원 값과 같고, 실행 본문도 같다.

설정에는 기존 차이가 하나 있다. 직접 야간모드 명령은 앞뒤 공백과 대소문자를 허용한다. SDK가 전달하는 "true"·"false" 계약과 기존 setConfig 처리는 유지한다. 이 차이를 단순 서식 변경으로 계산하지 않았다. 위 파일 수는 검토 범위이며 완료율이 아니다. 전달 검증의 Bundle은 host 대역이고, 소스 대조는 실제 Binder·LLM·장치 실행·부팅 성공을 증명하지 않는다.

SafeCare 화면 앱의 호출권한 누락 복구

EventAssetAgent가 PIN·순찰 API에서 거절되는 원인을 수정했다. 화면과 인증 세션을 맡는 com.sk.airbot.eventassetagent가 팀원 코드의 WSS 화면 앱 허용 목록에는 있었지만 우리 목록에는 빠져 있었다. 해당 항목을 반영했다. 기존 system UID·PID·패키지·호출 역할 검사는 유지한다. 이 값은 패키지 이름의 SHA-256이며 APK 서명 인증서와는 다르다.

실제 WSS 검사 코드와 SHA-256 구현을 실행한 host 11개 항목이 통과했다. 화면 앱 호출은 허용하고 일반 앱·알 수 없는 앱·테스트 패키지·다른 PID·원격 전용 API 호출은 계속 거절한다. 실패 재현, 명세·품질 검토와 Release 빌드 50초를 통과했다. 이전 이미지 입력 백업·플랫폼 서명 대조·QSSI APK 교체 후 SHA 일치를 확인했다. Android 호출자 정보는 host 대역이므로 실제 PIN 검증·순찰·기기 부팅 성공은 아직 증명하지 않았다.

도메인 의존성 검사와 남은 차이

팀원의 DeviceAgent 도메인 검사 규칙을 가져와 공통 검사에 연결했다. domain에서 app/service를 직접 참조하거나 지정된 전역 객체를 직접 사용하는 변경을 잡는다. 검사 파일·필수 소스가 없거나 검색에 오류가 나도 실패하도록 보강했다. 제품 검사 4개·공통 회귀·현재 소스 트리 검사와 명세·품질 검토를 통과했다. 이 검사는 소스 의존성 검사이며 Soong 모듈 경계를 모두 분리했다는 뜻은 아니다.

AIDL·Manifest·리소스·빌드 입력 등 팀원 88개와 우리 88개를 대조했다. 79개는 원문이 같고, 차이 8개와 팀원 전용 1개는 SDK 정본 연결·기존 Binder 순번·버전·검사 이관으로 구분했다. IoT AIDL의 기존 순번을 바꾸는 팀원 변경은 그대로 복사하지 않았다. 선택적 annotation의 Proguard 경고 정합은 남아 있다. 파일 수를 제품 완료율로 계산하지 않는다.

공기질 5개·MCU OTA 2개, 제품 명령·지도·SafeCare 8개 파일도 전체 차이를 대조했다. 공기질은 실제 양쪽 계산 코드의 등급 1,554·정렬 8,001·이력 17개 입력 결과가 같았다. 오류/OTA 공통 문자열 8개도 팀원 값과 같다. 지도 오류 메시지·잘못된 JSON의 실패 순서, 내부 순찰 snapshot 생성자 규격, MCU 미연결 시 반환 차이는 별도로 기록했다. 정상 경로 보존과 소스 대조를 실제 센서·MCU·Binder 실행 성공으로 해석하지 않는다. 예약·WSS 요청 보호 규칙은 아래 범위까지 검토했다. EventAsset의 나머지 화면·검증 입력 정합과 제품 실행 책임 이관은 남아 있다.

SafeCare 화면과 실행 소유자 정합

현재는 EventAssetAgent의 화면과 실행 경로를 팀원 소스에 맞추고 있다. 실행 책임을 Domain Service로 옮긴 상태는 아니다.

화면 종료와 종료 요청 전달은 물리적인 로봇 정지 완료를 뜻하지 않는다. 충전대 진입은 저전력 안내를 다시 표시할 수 있도록 기록을 초기화한다. 상태를 관측하지 못했다는 이유로 실행 종료를 선언하지 않는다.

현재 시작 admission·Task 중단 확인·연결 revision·claim/cancel 보호를 유지한다. 시작 버튼은 팀원의 원래 화면처럼 연결 전에도 표시되지만, 미연결 요청은 실행 소유자의 연결·세대 검사에서 차단한다. station listener 재연결/해제, PIN context 무효화, 사용자 실패 팝업과 toast 수명 보호는 의도적으로 유지했다.

소스 검증: 최신 앱 unit 393건/28개 suite, Release·격리 APK 빌드와 독립 명세 → 품질 검토를 통과했다. 최근 작업명 안내·설정 초기화·Session 화면 전환은 각각 실패 재현 후 반영했다. 제품 APK/QSSI 입력은 백업·플랫폼 서명·SHA 대조 후 갱신했다. 파일 이동이나 검증 개수를 실행 책임 이관·전체 완료율로 계산하지 않는다.

기기 검증: API 33 기기의 별도 verification 앱에서 네 묶음을 실행했다. 기존 전송·문구·Intent/창 계약 46건, 작업명 안내 2건, 설정 옵션 뷰 3건, 귀환/일시정지 뷰·클릭 4건이 각각 통과했다. 각 묶음은 해당 시점의 APK로 실행했으며, 최신 APK의 전체 55건을 한 번에 실행했다는 의미는 아니다. 귀환/일시정지 뷰는 기기에서 렌더링한 이미지도 확인했다. 일반 UID·설치 APK SHA를 대조했고 운영 DeviceAgent 0.258·EventAssetAgent 1.015는 유지했다. 실제 제품 Binder·Launcher 전환·로봇 귀환/중단·제품 부팅 성공은 미검증이다.

새로 점검한 남은 차이: Gradle app/src 기준 팀원 370개/우리 372개 중 원문 동일 347개, 내용 차이 23개, 팀원 전용 누락 0개다. 이 수치는 정적 파일 비교이며 의미 정합 완료를 뜻하지 않는다. 팀원 instrumentation 파일의 누락은 해소했지만 다음 기능 차이는 추가 검토·반영해야 한다.

• 예약 접수 순간의 중단 검사: 이번에 팀원 조건 반영 완료. 후속 실행과 중단의 경합은 별도 검증 대상이다.
• 메뉴 경고 팝업의 취소 버튼: 팀원 정책 반영 완료. 실제 SystemUI 렌더링·운영 IPC 검증은 남아 있다.
• Activity 시작 화면 제거와 인증 Toast: 팀원 호출 경로 반영 완료. 기기 렌더링·실제 인증 검증은 남아 있다.
• 설정 복사 생성자와 실제 요청 호출부: 반영 완료. 나머지 연결·실행 보호 차이는 별도 대조 대상이다.

전체 EventAsset 의미 정합, Launcher의 남은 차이, 새 제품 APK 설치, 전체 이미지 생성·자동부팅 및 목표 Domain Service 실행 책임 이관은 미완료다.

최신 EventAssetAgent 제품 APK/QSSI SHA-256: 85e59f8282742239a216d1422345647b7a8c7ebd5af1d659f8a964071adea646. 저장소 근거는 skix-eventasset-task-prompt-evidence-2026-10-02.json, skix-eventasset-config-init-evidence-2026-10-02.json, skix-eventasset-session-screen-evidence-2026-10-02.json, skix-eventasset-source-difference-inventory-2026-10-02.json이다. 기존 46건은 skix-eventasset-isolated-device-evidence-2026-10-02.json에 기록했다.

예약과 WSS 요청 검토

예약은 팀원 파일 9개 중 동일 5개와 의도적인 차이 4개를 대조했고 누락은 없다. 입력 8건·등록 15건·저장 9건의 실제 Java host 검사를 확인했다. 기존 예약 종류·시간 보호·저장 실패 처리와 등록 순서를 유지한다. TaskManager로 예약 실행 책임을 이관하거나 Android Alarm 실동작을 검증한 것은 아니다.

WSS 시작·중단·실행 식별자 3개 파일은 실제 JUnit 27건으로 검토했다. 중단 요청 소유권 검사 3건은 우리 코드에서 통과하고 팀원 코드에서는 실패해, 큐 접수 전 실행·다른 registry·서로 다른 owner를 차단하는 기존 보호를 유지했다. 시작 중인 요청 기록의 만료는 실제 실행 취소를 뜻하지 않고, 기록은 프로세스 재시작을 넘는 영속 상태가 아니다. 근거는 skix-schedule-peer-convergence-2026-10-01.json과 skix-wss-request-peer-convergence-2026-10-02.json이다.

당시 검토 후 현재 상태: EventAsset의 verification 설정·화면·호출 경로는 위의 기능별 근거로 검토·수정을 이어갔으며, DeviceAgent의 얼굴 인증 세션 보호까지 이어서 반영했다. 위에서 설명한 13개 팀원 전용 파일은 당시 탐색 목록이며, 현재 13쌍의 근거 연결 대상과 다른 집계다. 다음은 WSS 시작·중단 접수와 남은 전체 파일 차이의 정합 근거를 연결하는 일이다. 실제 서비스 연결·제품 동작과 실행 책임 이관은 별도 검증이 필요하다.

팀원 소스 검토 범위

DeviceAgent Java는 팀원 315개·우리 353개를 대조했으며 팀원 파일 누락은 없다. 팀원 기준으로 원문 동일 213개, 주석·서식 또는 공통 문자열 상수 치환 후 토큰 동일 28개, 동작 차이를 검토해야 하는 파일 74개로 분류했다. 우리 전용 파일은 38개다. 이 숫자는 검토 범위를 정한 목록이며 전체 의미 정합 완료율이 아니다. 일부 검토는 이미 완료했고, 남은 차이는 파일별 현재 SHA와 호출 경로를 기준으로 확인한다. AIDL·Gradle·리소스 전체 검토까지 포함하는 수치도 아니다.

청소·이동 정합에서 확인한 동작

청소·이동 관련 6개 파일의 전체 차이와 실제 호출 경로를 검토했고, 팀원 동작 누락은 발견하지 않았다. 예약 갱신·현재 예약 조회, 선택 구역과 AI 스캔 구역 ID 일치, 없는 목적지 거절, 콜백 무효화·실패 후 정리를 유지했다. 정상 청소·보고·상태 전달과 제품 정책의 실행 순서도 대조했다. 현재 정책의 세 반환값에 한해 접수 판단이 같으며 향후 모든 정책 결과를 보장하는 것은 아니다.

실제 BasicCleaningManager와 공통 시간 정책·예약 상태 및 청소 시간 계산을 실행한 host 48개(청소 47·예약 상태 1)가 통과했다. Android·MCU·관측 provider와 일부 transaction은 대역이다. 명령 handler 전체 실행, 실제 팬 정지·로봇 이동·새 이미지 부팅 검증과 구분한다. 이 검토에서는 제품 소스를 추가로 변경하지 않았으며 파일별 SHA를 저장했다. 전체 74개 차이의 정합 완료를 뜻하지 않는다.

Launcher2 · 팀원 변경 8개 묶음 반영

현재는 소스 정합·Release APK·QSSI 입력까지 반영했다. 기기 Launcher는 교체하지 않았으며 실제 UI·Binder·순찰·청소·MQTT 검증은 남아 있다.

각 묶음은 실패 재현 → 영향 검사 → Release 빌드 → 독립 명세·품질 검토를 거쳤다. 앞선 예약 데이터 변환 묶음은 영향 검사 16건 PASS·Release 빌드 31초다. Android 자료형·화면 상수·SafeCare 설정 판정은 host 대역을 사용했고, 기기 실행 증거로 해석하지 않는다. 기존 묶음 결과를 합산한 새 전체 검사 수치로 표현하지 않는다. 해당 이전 묶음의 Launcher2/QSSI 입력 SHA-256은 4faceaa171e72c480f9f3f64fc17aacd9fadafaf25807e42c632bf5d4183705b이다. 플랫폼 서명 대조·기존 입력 백업·원자적 교체 후 SHA 일치를 확인했다. 현재 반복 예약 ID 정합 뒤 Launcher2의 QSSI/별도 AOSP 후보 입력 SHA-256은 ebc9c3b7bc37fe00a38dc87acefbe93b8c3917b9792d2c85f558ae4f7d31a964이며 상단 최신 검증과 연결한다.

예약 휴일은 팀 SDK와 같은 전달 의미여서 유지했다. 지역 설정은 기존 ms-MY 처리를 보존했다. 파일 차이를 없애기 위한 일괄 치환은 하지 않는다. Launcher의 팀원 Java 파일 누락은 없으며, 구현 차이 12개 파일은 기존 보호 동작·SDK 사용 방식까지 대조하고 있다. 파일 존재와 전체 동작 정합 완료는 구분한다. DeviceAgent 시스템 제어는 팀원 동작이 기존 Gateway에 수용되어 있고, LLM의 공통 상수·숫자 상태 입력 지원도 보존한다. 나머지 DeviceAgent 소스의 의미 차이 검토는 계속 진행 중이다.

구조 해설과 확인 범위

현재 연결과 진행 상태 읽기

그림 읽는 순서: 위에서 아래로 시스템 앱·화면 → SDK API → Binder → 서버 책임 → 장치 연결을 읽는다. 서버 책임 안에서 왼쪽은 현재 제품 서비스, 오른쪽은 분리된 공통 Core Service다. 그림을 누르면 크게 볼 수 있다.

Launcher/Launcher2는 시스템 앱 소비층이다. HOME·설정·청소/이동 화면과 사용자 흐름을 담당하며 SkixXxxManager API를 소비한다. DeviceAgent의 로봇 실행 책임과 같은 구역에 묶지 않는다. ICT·Pairing·EventAsset의 화면도 소비층에 있다. ProductSystemUI는 SKIX 플랫폼의 공통 UI 제공 서비스다. TopBarService가 상태바를 그리고 SystemPopupService가 Binder API를 제공한다. 독립 시스템 APK로 배치하며 로봇 실행 Domain과 구분한다.

그림의 계층은 논리 책임이다. 하나의 APK가 UI·SDK 소비·Binder 서비스 역할을 함께 가질 수 있다. EventAsset의 화면과 SafeCare 실행 서비스, IoT의 요청 클라이언트와 MQTT/WSS 서비스는 각각 역할을 나눠 표시했다. 상단의 앱 API와 하단의 서버 Service도 같은 의미가 아니다.

짙은 테두리는 SDK/APK 입력 확인, 중간 테두리는 내부 구현, 옅은 점선 테두리는 제품 연결이 남은 영역이다. 배경색은 앱·Framework·장치·외부 시스템의 종류를 구분한다. 상태 문구와 함께 읽으며 전체 완료율로 해석하지 않는다.

DeviceAgent 내부 분리와 Framework Service 이관은 다르다. 현재 제품 경로는 SkixXxxManager → Binder → DeviceAgent MainApi/Composition → 기능별 CommandHandler → 제품 adapter/장치다. 이동·청소·일정·지도·설정 등의 기존 비즈니스 로직과 실행 책임은 상당 부분 DeviceAgent에 남아 있다. 공개 Manager API 분리와 내부 Handler 분리는 진행했지만, 모든 기능을 독립 Framework Service로 옮긴 상태는 아니다.

TaskManager는 오른쪽 공통 Framework 구현에 표시했다. TaskManagerService에는 접수·중복 방지·큐·기록·취소 의도·이력 관리가 있고, Control과 Domain에는 실행 허용·자원 점유·관측·완료 처리 계약이 있다. 이는 기존 DeviceAgent의 모든 명령이 TaskManager를 통과한다는 뜻이 아니다. TaskManagerEndpoint는 transport-neutral 진입부이고 공개 Android Binder 게시와 별개다. 기본 FrameworkHostComposition은 관측 구성으로 AMR 실행을 자동 활성화하지 않는다.

base/core는 공개 SDK 계약이며, 서버 로직은 base/services/core에 있다. 두 경로의 core를 구분해야 한다. DeviceAgent 업무를 기능별로 나누며 만든 공통 Service가 아래 구역에 놓여 있지만, 소스가 있다는 이유만으로 현재 제품 명령의 실행 owner가 모두 옮겨졌다고 표시하지 않는다.

연결은 실선 호출·제어, 파란 점선 비동기 callback, 녹색 점선 관측 데이터, 회색 점선 미완료 연결로 구분한다. 소스 연결이 실기기 성공을 뜻하지 않는다. 공통 Host의 SDK 연결·탑재·시작 주체와 기존 실행 owner 이관은 함께 확인해야 한다.

구조 정리는 빈 미래 폴더·비실행 scaffold·정적 service locator·중복 AIDL 제거를 포함한다. SDK 입력 통일·APK 생성은 확인했지만 전체 이미지 생성·부팅·기기 동작은 남아 있다.

설치본과 새 빌드 구분: 기기의 DeviceAgent는 기존0.258이며 새0.256은 미설치다. CameraBroker1.0.17의 원격 상태 조회는 확인했지만, 새 이미지 입력이나 실제 촬영 성공은 확인하지 않았다.

기존 현재 연결 상세 그림

파일 수, 테스트 수, AAR 복사 수로 전체 완료율을 계산하지 않는다. 소스 구현 / APK 빌드 / 이미지 입력 / 이미지 생성 / 기기 동작을 각각 표시한다.

책임을 어디에 두었나

SystemUI 사용 방식: 제품 앱 → SkixManager.systemUi() → IProductSystemUi Binder → ProductSystemUI APK. 팝업 요청·결과, 상태바 정책, 내비게이션 callback은 SDK로 사용한다. 청소·이동 등의 실행과 정책 판단은 해당 기능 owner에 남는다.

현재 SystemUI 서비스는 signature 권한으로 보호된다. SDK manifest가 호출 권한을 제공하며, 서비스와 호출 앱의 서명 조건도 맞아야 한다. 상태바는 부팅 receiver에서 시작하고, 팝업 서비스는 SDK가 명시적으로 bind한다. 현재 목표에는 별도 시스템 APK 방식이 적합하며 SystemServer 이관을 필수로 두지 않는다.

부팅 시 서비스 준비와 앱의 Manager 연결은 다르다

필수 서비스는 부팅 과정에서 준비하고, 앱은 자기 프로세스가 시작된 뒤 Manager로 연결해 Binder를 재사용한다. 일반 API 호출마다 bind/unbind하는 구조를 목표로 하지 않는다. 앞의 SystemUI 그림은 책임과 호출 관계를 나타낸 것이며, 모든 서비스가 부팅 때 준비됐다는 뜻은 아니다.

서버는 언제 올라오고, Manager는 언제 연결하나

• 서버 초기화: 부팅 경로가 공통 Runtime과 필수 서비스를 시작한다. 상태·Task·정책 등 필요한 내부 모듈을 구성하고, 요청을 받을 준비가 됐는지 확인한다. 부팅 완료와 개별 서비스 준비 완료는 별도 조건이다.
• 앱 연결: Launcher처럼 상시 사용하는 앱은 앱 시작 시 필요한 Manager 연결을 미리 준비하는 방향이다. 아직 실행되지 않은 앱의 Manager를 시스템 부팅 때 대신 생성하거나 bind할 수는 없다. 선택 기능은 처음 사용할 때 연결해도 된다.
• 일반 호출: 연결된 Binder를 여러 요청에 재사용한다. 호출마다 새 서비스·Runtime을 만들거나 bind/unbind하지 않는다. 첫 연결 비용과 일반 요청 처리 비용을 구분해 측정한다.
• 종료·복구: 앱이 더 이상 연결을 사용하지 않을 때 client를 해제한다. 서버 프로세스가 종료되면 연결 복구와 상태 재조회가 필요하다. 서버를 부팅 때 시작했다고 프로세스가 영구히 살아 있다는 뜻은 아니다.

SkixXxxManager는 앱 안의 SDK 객체다. 반면 Domain Service는 기능의 상태·정책·실행을 소유하는 서버 모듈이다. Domain Service마다 Android Service와 bind가 하나씩 필요한 것은 아니다. 같은 Host 안의 모듈은 직접 호출하고, 프로세스 경계에만 Binder 연결을 둔다. 또한 system_server에서 등록하는 서비스와 독립 APK의 bound service는 시작·연결 방식이 다르므로 같은 그림 기호만으로 동일한 생명주기를 가정하지 않는다.

상주 수명은 서버 쪽에서 보장해야 한다. bind만으로 생성된 Android Service는 마지막 client가 해제되면 종료될 수 있다. 필수 APK 서비스는 제품에서 허용하는 시작 경로와 서비스 수명 정책을 갖추고, client의 bind 수명과 분리해야 한다. startService() 호출 하나만으로 자동 재시작·부팅 순서·Android 백그라운드 실행 조건까지 해결되는 것은 아니다. Android bound service 수명 설명을 기준으로 제품 정책을 구현하고 확인한다.

현재 소스에서 확인한 부분과 남은 작업

앞으로의 완료 기준: 필수 서비스 목록과 시작 책임을 정하고 → 의존 순서대로 초기화 → 요청 가능 상태 확인 → 상시 앱 연결 → Binder 재사용 → 서버 재시작 시 재연결을 제품 이미지에서 확인한다. 준비 전 호출은 기능별 대기·거절·타임아웃 규칙을 정하며, 요청 접수를 장치 실행 완료로 해석하지 않는다. 큰 선택 기능은 필요 시 초기화해 부팅 시간과 메모리 사용을 관리한다.

코드 근거: ../systemui/.../BootReceiver.java, SystemPopupService.java, base/core/.../systemui/SkixSystemUiManager.java, base/services/runtime/.../SkixFrameworkHostService.java, apps/SkixFrameworkService/app/src/main/AndroidManifest.xml. 위 표는 소스 확인 결과이며 전체 이미지 부팅·최초 호출 지연·장애 복구가 실기기에서 검증됐다는 의미는 아니다.

실제 폴더와 설명

skix-framework/
├── ARCHITECTURE.md                 이름·책임·의존성 판단의 대표 규칙
└── base/
    ├── Android.bp                  순수 서버 모듈·계약의 Soong 정의
    ├── core/
    │   ├── java/                   공개 SDK·공통 모델·계약
    │   ├── aidl/                   SDK 소유 IPC 계약
    │   └── tests/src/              SDK·계약 JVM 테스트
    ├── compatibility/
    │   ├── java/                   기존 IPC·Bundle 번역
    │   └── aidl/                   기존 wire 호환 계약
    └── services/
        ├── core/java/.../server/
        │   ├── control/            공통 상태·정책·자원 제어
        │   ├── execution/          task 접수·실행·결과 처리
        │   ├── domain/             기능별 계약·상태·정책·실행
        │   ├── entrypoint/         typed 요청 검증과 위임
        │   └── runtime/            순수 구성요소 조립·수명 연결
        ├── runtime/java/           Android Service·Binder 구현
        └── tests/                  서버 JVM·instrumentation 테스트

apps/AirbotSdkProject/skix-framework-sdk/  SDK Gradle 빌드 모듈
apps/DeviceAgent/                         현재 장치 실행·제품 연결
apps/EventAssetAgent/                     SafeCare 실행·저장·화면
apps/SkixFrameworkService/                선택적 공통 Framework Host
../systemui/                             공통 시스템 화면 APK

core·control·execution·domain·entrypoint·runtime은 책임과 빌드 경계다. 기능을 추가할 때 모든 접미사와 하위 폴더를 만들라는 템플릿이 아니다.

폴더 이름만 바꾸는 것은 실행 책임 이관이 아니다. Manager는 클라이언트 API, Endpoint는 진입 검증, Port는 외부 행위 요구 계약, Adapter는 그 계약으로의 변환 구현이다. 새 타입은 별도 책임·수명·교체 지점이 있을 때만 추가한다.

이번에 소스로 연결한 주요 항목

남은 API 차이는 파일 이름만으로 복사하지 않는다. 예를 들어 팀 Manage에 있는 상태 callback은 우리 SkixDeviceStateManager, 보정·시뮬레이션은 SkixMaintenanceManager, 클라우드 연결 조회는 SkixCloudBridgeManager와 책임을 대조한다. MR8 이후의 선택적 B2B 조회처럼 현재 MR7 제품 명령과 caller가 확인되지 않은 항목은 별도 미결 항목으로 둔다.

최신 바이너리와 검증 기준

추가 정합: Provisioning 등록 상태·BLE serial 반환형을 팀 typed 계약으로 맞췄다. 새 SDK(d113cb90…)를 정본+7개 소비 앱에 동기화했고, 7앱 Release·IoT 4변형 포함 10APK의 platform 서명을 확인했다. Make가 선택하는 이미지 입력9개도 백업 후 교체했다. 아래 이전 SHA 기록은 해당 시점의 검증 이력이다.

기기 테스트 승인·부분 검증: 192.168.10.5:5555에서 Host 초기화와 관측 Gateway의 실제 Binder 경로를 확인했다. 기존 DeviceAgent는 유지했다. 상세 범위는 위 기기 결과를 따르며 전체 이미지 생성·제품 자동부팅 증거는 아니다.

이전 namespace SDK AAR SHA-256: d113cb9043a61601a249d79a0efc0e6613835a57b2f57dc864a3d74b7f063df8. 새 정본은 상단에 표시했다.

최신 ProductSystemUI APK / QSSI 입력 SHA-256: fd7aa994a70bf9c8acd331152d63b11244f4774ee0270e06f287deb929a95590.

이 반환형 정합은 JVM descriptor 변경을 포함한다. 기존 SDK로 컴파일한 앱 바이너리를 그대로 사용하지 않고 모든 소비 앱을 새 AAR로 재빌드했다. 이번 검증 근거는 skix-provisioning-result-evidence-20261001.json, skix-sdk-d113-consumer-apk-evidence-20261001.json, skix-sdk-d113-image-evidence-20261001.json이다.

이전 묶음의 검증 이력

아래 SHA와 테스트 수는 이전 정합 시점의 기록이다. 현재 입력은 위 표와 d113 SHA를 따른다.

이전 SDK AAR SHA-256: 79c6dd0711309340093fbf4680a137c6e4bb3b461802eafa87fc925f5d98b926.

이전 SystemUI APK / QSSI prebuilt SHA-256: 3d2bdf8842c81406135ba86da1a79e20069bf7fbc754bd5f938214973faae84a.

6개 앱 APK 묶음은 APK 생성·서명·권한 검사이며 새 단위 테스트나 설치·실행 검증을 뜻하지 않는다. 이후 이미지 입력 정합에서 ICT·PairingAgent·DeviceAgent를 갱신했다. DeviceAgent Release build도 통과했으며 R8의 선택적 annotation(Immutable·GuardedBy) 경고는 남아 있다. IoT dev/opr·mal_dev/mal_opr Release 네 변형의 이미지 입력까지 정합했다. Launcher2 카메라/HY 구 APK 분리는 최신 0.285 단일 APK와 runtime property 계약으로 통합했다. 실제 제품 옵션 값·화면은 미검증이며, EventAssetAgent 1.011 제품 포함 조건과 이미지 입력도 연결했다. 녹화 Binder 권한을 보완한 EventAssetAgent Release(28s)와 호출 권한을 명시한 DeviceAgent Release(19s)를 이미지 입력에 반영했다. 기존 APK·Make 입력은 별도 백업했다. EventAssetAgent의 카메라 경로는 외부 CameraBroker 서비스도 필요하며, 현재 확인한 QSSI 설정 범위에서는 해당 서비스 탑재 선언을 찾지 못했다. 전체 이미지 부재를 뜻하지 않는다.

AQM 보고 경로는 팀 코드와 동일하게 nullable 측정값 생성 결과를 확인한 뒤 전달한다. 사용할 수 없으면 명시 로그를 남기고 중단하며, PM·습도·온도·VOC/NOx·포름알데히드·CO2 및 등록 센서 정보를 유지한다. 실제 함수 host 검사는 JSON·장치 경계를 double로 대체했으므로 SDK wire·broker·실기기 전달의 증거는 아니다. CmdTopic의 남은 팀 차이 중 온디바이스 지도와 배경 변경 응답은 현재 호출 경로 때문에 유지한다. 팀 WifiMonitor의 중복 등록 방지와 등록 실패 복구를 반영했다. 종료 시 네트워크 콜백·대기 메시지·주기 작업을 정리하고, 해제 오류가 나도 finally에서 작업 정리를 수행한다. 종료 후 진입한 콜백이 새 감시 작업을 시작하지 않는 것을 host 검사로 확인했다. Android·예약 실행·socket 경계를 대체한 검사이며, 이미 진행 중인 콜백/네트워크 호출의 강제 취소와 실제 Wi-Fi 동작은 미검증이다.

IotAgent의 기존 Binder unregisterCallback() 자기 호출로 발생하는 StackOverflowError를 host에서 재현하고 제거했다. 팀의 RemoteCallbackList를 사용해 여러 클라이언트의 등록·개별 해제와 서비스 종료 시 목록 정리를 연결했다. 이벤트 콜백과 MQTT·SafeCare 업무 경로는 그대로 유지한다. 실제 메서드와 종료 함수를 실행하는 host 검사에서 등록/해제/정리를 확인했지만 Android callback 목록은 double이므로 실제 Binder death·IPC 검증은 별도로 필요하다.

호출되지 않는 securityMode 즉시 응답 helper와 전역 응답 주소·요청 ID를 팀 구조에 맞춰 제거했다. 원격 요청은 SafeCare inbox에 보관한 뒤 worker가 요청별 replyTo와 처리 결과로 응답한다. 상태 이벤트·PIN·업로드 경로는 유지한다. 구조 회귀 검사 7개·JVM 85개와 제품 Release 4종을 확인했으며, 실제 broker·Binder·기기 동작 검증은 별도로 남아 있다.

오류 보고와 배경 변경 응답은 Bundle 진입도 유지하되 typed 모델로 변환한 뒤 같은 MQTT 조립 함수를 사용한다. 오류 코드는 E03일 때만 상세 메시지를 포함하며, 배경 응답의 요청별 주소·상관 ID·결과·메시지를 유지한다. 실제 함수 host 검사로 기본값·null 입력·전송 예외 격리를 확인했으며 Android Bundle·MQTT·Binder는 검증하지 않았다.

IoT 업무 진입 10곳에 팀의 준비 상태 검사를 반영했다. 검사 시 Framework 장치 연결이 없으면 명시 로그를 남기고 전달을 건너뛴다. 설정 적용 결과의 거절·미전달도 로그로 확인할 수 있게 했다. gateway 연결 전 listener 등록과 청소 문자열·생략 필드는 유지한다. 실제 함수 host 검사로 전달/차단과 진단을 확인했지만 실제 Binder 연결·물리 실행 검증은 별도로 남아 있다.

일정의 청소 옵션은 기존 지원을 유지한다. 옵션 일부만 들어올 때 없는 청소·풍량 코드를 변환하다 발생하던 NullPointerException을 재현하고 수정했다. 없는 필드는 생략하고 명시된 false는 유지한다. 실제 일정 변환 클래스·SDK 모델·상태 코드 매핑과 host org.json 검사에서 옵션 8조합·요일·작업 좌표·매개변수·손상 일정 전체 거절을 확인했다. Android JSON·MQTT/Binder·기기 일정 실행은 미검증이다.

서버 지도 처리의 중복 parser를 제거하고 ServerMapSnapshotDecoder에 연결했다. 방 순서·좌표·배정·스캔·보안 위치와 optional 기본값을 검증했으며, 필수 구조나 숫자가 잘못된 지도는 전체를 거절한다. 기존 숫자 오류를 0으로 대체하던 동작보다 엄격하다. 온디바이스 지도 응답·복호화·metadata reload는 그대로 유지했다. 실제 지도 다운로드·Binder 전달·기기 지도 변경은 아직 검증하지 않았다.

SafeCare의 typed 서비스와 기존 녹화 서비스는 모두 CONTROL_SAFECARE signature 권한으로 보호한다. SDK 소비 앱과 DeviceAgent의 호출 권한 및 현재 DeviceAgent·IoT·EventAsset APK의 플랫폼 서명을 확인했다. 서비스·DeviceAgent·SDK 권한 회귀 3개와 제품 활성/비활성 Make 선택을 검증했다. 실제 Binder 연결·촬영·중단 성공은 아직 확인하지 않았다. 이전 권한 보완 빌드의 EventAsset APK SHA는 af9825ccf0725526f7a69688a3201351a9b65823612ea06b5e608549d5614890, DeviceAgent는 ea13491cce74830171018beea43dbb625412c78cfafac57dafd0a9f70f304c91이다. 앞선 6개 앱 APK 묶음의 EventAsset SHA는 이번 재빌드 전 이력이다.

Launcher2의 옵션 누락·property 조회 실패는 현재 팀/우리 동일 소스의 기본값 true를 따른다. 구 HY APK는 property 이름 문자열을 true와 비교해 camera/mic를 항상 끄는 구현이었다. 이 차이는 실제 제품 옵션·UI 확인 시 검증해야 한다. Host 검사는 Android property stub을 사용한 소스 검증이며 실기기 검증이 아니다.

Launcher2 상태바는 이제 SDK의 화면 정책을 통해 ProductSystemUI에 연결한다. 13개 화면 슬롯의 showType·좌표·너비를 유지하고 높이는 팀 계약의 38dp로 맞췄다. Launcher의 자체 상태 아이콘·시간·네트워크 구독을 제거했으며, SystemUI가 없을 때 자체 표시로 대체하지 않는다. 화면 제목·뒤로가기·기존 터치 처리는 유지한다. 실제 Coordinator host 검사는 가려진 Fragment·복귀·부모 슬롯·미측정 대기·종료 해제를 포함하지만 Android view/Fragment doubles이므로 실제 화면 검증이 아니다. Launcher2 JVM40개/21suites와 Release 빌드(3m4s)를 확인하고 이미지 입력 APK를 다시 갱신했다. 앞선 Launcher2 APK SHA는 이번 상태바 정합 전 이력이다. 이번 검증 근거는 skix-launcher2-topbar-integration-evidence-20261001.json이다.

배포 목록은 tools/artifacts/framework-sdk-manifest.json, source/consumer 검사 근거는 tools/tests/test_framework_sdk_artifact_identity.py에 있다. 미커밋 소스를 포함한 개발 기준이며, 정식 제품 release 승인이나 전체 정합 완료를 뜻하지 않는다.

다음 작업 — 순서와 종료 조건

1. 남은 제품 동작 차이 정리: 실제 caller·명령·callback·재연결/종료 동작으로 수용·유지·보류를 결정한다. 사용하지 않는 별칭을 추가하거나 안전 장치를 팀판으로 되돌리지 않는다.
2. APK와 이미지 입력 통합: 새 SDK 기준 7개 소비 앱 APK 빌드를 확인했다. Launcher2 입력을 최신 APK로 맞췄으며, EventAssetAgent 포함 조건도 연결했으며, 설치된 CameraBroker의 상태조회 IPC는 확인했고, 다음은 정본 소스·배포 APK와 QSSI 입력을 확보한 뒤 새 이미지의 기동·등록·프레임 경로를 검증한다. Launcher/Launcher2는 같은 앱 ID이므로 제품 구성에 맞춰 하나를 선택한다. 추가 국가·제품 변형은 해당 요구에 맞춰 검증한다.
3. 제품 이미지 검증: Host의 source/prebuilt 선택과 system_ext 입력은 연결했다. 전체 이미지 생성·부팅에서 현행 producer bind와 권한·재연결을 확인한다. 목표 SystemServer Root와 공개 SDK 연결은 별도 미완이다.
4. 실제 실행 검증: 이미지 생성·부팅 → Binder 연결 → 앱 전환·프로세스 재시작 → 장치 기능·중단·장애 복구를 확인한다.
5. Blueprint 승인: 현재 제품 근거와 요구를 연결해 구조·단일 owner·의존성·R&R을 리뷰한다. 승인되지 않은 초안을 구현 완료로 취급하지 않는다.

AMRService는 현재 직접 IAMR 연결과 local의 연결·callback 수명 보호를 유지한다. 현재 팀 최종 소스에서 되돌린 중간 AMR owner 실험은 가져오지 않는다. 실제 movement completion, 외부 IWssControl 소비자, Framework Host 이미지 입력은 연결했고, 실제 제품 부팅·SDK root 연결은 별도 검증 대상으로 남는다.

이전 기록과 달라진 점

2026-09-30 문서는 일정 등록 result의 수용을 보류하고, SDK 후보와 consumer AAR이 다르며 ICT 기본 입력도 미정합이라고 기록했다. 이후 소스 정합에서 일정 등록 API를 수용했고 ICT 입력을 SDK AAR로 통일했으며, 2026-10-01 정본과 7개 consumer를 같은 AAR로 맞췄다. 과거 SHA·파일 수·테스트 수는 당시 이력이며 위 최신 표를 대체하지 않는다.

이 페이지는 현재 구조와 다음 작업을 보는 대표 요약이다. 세부 코드 변경·검증 이력은 저장소 docs/refactor/skix-next-session.md, skix-branch-convergence-plan-2026-09-22.md, skix-work-cost.md를 따른다. 총 토큰 절감률은 동등 baseline과 전체 telemetry가 없어 미측정이다.

Connections

• 제품 Robotics Framework Blueprint — 목표 초안과 계층 방향
• 리팩터링 진행 지도 — 전체 작업 구역과 과거 상세 이력
• Blueprint로 가기 위한 WBS — 분석·설계·구축·검증 업무 목록
• 소스별 세부 업무 — 기능·폴더별 담당 업무
• 6인 R&R — 책임과 인계 기준
• 실행 TODO — 설계 산출물과 승인 게이트

초기화·CameraBroker 검증 근거

• skix-startup-callback-convergence-evidence-20261001.json: 팀원 초기화·콜백8파일 비교, ICT null guard 수용, host12·Release21s·이미지 입력 백업/서명/SHA.
• skix-camera-broker-device-evidence-20261001.json: 설치본·소비 AAR SHA, 원격 상태 조회 raw결과, 임시 앱 제거·기존 Vision 연결 유지.
• 위 근거는 로컬 작업 기록이다. R8 annotation/java 중복 및 probe javac bootstrap 경고는 남아 있으며, 실제 제품 자동부팅·실센서·프레임 검증으로 확대 해석하지 않는다.