SoC TaskManager Framework Refactor Roadmap
이 장은 현재 DeviceAgent TaskManager 작업을 나중에 SoC 실행 프레임워크로 발전시키기 위한 리팩터링 방향이다.
현재 위치
현재 구조는 DeviceAgent 내부의 task package로 구현되어 있다.
com.sk.airbot.deviceagent.task
현재 장점:
- TaskManager API entry가 생겼다.
- task/workflow/parallelGroup 개념이 있다.
- executor registry와 skeleton executor가 있다.
- event/reason/context 계약이 있다.
- Cloud/MQTT/App/로컬 음성/예약 같은 multi-source ingress로 확장할 방향이 명확해졌다.
- unit/integration/instrumented test source가 있다.
현재 한계:
- 아직 DeviceAgent 앱 내부 패키지 성격이 강하다.
- domain executor와 실제 SoC service/HAL boundary가 완전히 분리된 프레임워크 형태는 아니다.
- AIDL/Binder/service registration 경계는 별도 분석/정리가 필요하다.
- 업체 구현 diff와 실기기 evidence가 아직 없다.
목표 구조
Task Framework API
-> Multi-source Ingress Adapter
-> Admission / Policy
-> Scheduler / Queue / Workflow
-> Executor Registry
-> Domain Adapter
-> SoC Service / HAL / Native
-> Event Bus / Callback
-> Evidence / Trace
리팩터링 단계
| Phase | 목표 | 결과물 |
|---|---|---|
| 1 | DeviceAgent 내부 프레임워크 안정화 | method/reason/event/test matrix 고정 |
| 2 | Multi-source Ingress 정리 | Cloud/MQTT/App/로컬 음성/예약 source contract |
| 3 | Domain Adapter 분리 | movement/cleaning/map/LLM/TTS/IoT/update adapter |
| 4 | Service Boundary 정리 | AIDL/Binder/init/sepolicy/partition 분석 |
| 5 | Product Framework화 | API spec, adapter SDK, test harness, migration guide |
Open Questions
| 질문 | 이유 |
|---|---|
| TaskManager가 앱 내부 모듈로 충분한가, 별도 service화가 필요한가 | lifecycle, process death, long-running task 영향 |
| Binder/AIDL로 공개할 범위는 어디까지인가 | vendor/system boundary와 권한 정책 |
| queue persistence가 필요한가 | reboot/앱 재시작 후 workflow 복원 |
| parallelGroup을 제품 기능에서 실제로 허용할 것인가 | 안전성/리소스/동시 제어 문제 |
| source별 event 후처리를 어디까지 나눌 것인가 | Cloud replan, MQTT ack/report, App UI, 예약 retry가 서로 다름 |
| Cloud replan event를 어디까지 올릴 것인가 | 토큰 비용과 지연 시간 제어 |
업체에 요구할 리팩터링 관점
- domain executor는 TaskManager core와 분리한다.
- event/reason schema는 Cloud/On-device/MQTT/App/예약 source와 호환되게 유지한다.
- 상태 조회는 planning context로 제공하고, 실행 task와 혼동하지 않는다.
- 실패/차단은 구조화 reason으로 제공한다.
- 테스트 evidence는 API 단위가 아니라 workflow trace 단위로 제출한다.