SoC TaskManager Background

이 장은 왜 DeviceAgent에 TaskManager가 필요한지 설명한다.

기존 DeviceAgent 구조와 TaskManager layer 추가 후 변화는 Before/After Change Model을 먼저 보면 빠르게 이해할 수 있다.

문제 배경

Cloud A2A는 발화를 이해하고 계획을 세운다. 그러나 DeviceAgent 입장에서는 Cloud A2A만 upstream이 아니다. 나중에는 MQTT 명령 서버, 앱/리모트 제어, 예약/자동화, 내부 정책도 같은 실행 계층으로 들어올 수 있다.

따라서 TaskManager의 배경은 “Cloud LLM과의 규약”만이 아니라 여러 명령 유입원을 SoC 실행 모델 하나로 통합하는 것이다.

제약	upstream만으로 판단하기 어려운 이유
현재 방 위치	맵/위치 정보는 DeviceAgent/SoC 상태
이동 가능 여부	장애물, 이동 상태, station 여부는 runtime 상태
청정 동작 가능 여부	cleaning transaction, pause 상태, 현재 mode와 충돌 가능
배터리/리소스	low battery, busy queue, thermal/resource 상태는 기기 내부 상태
기존 작업 진행 중	queue와 workflow 상태를 DeviceAgent가 알아야 함

유입원	예시	TaskManager 관점
Cloud A2A / LLM	“거실로 가서 청정하고 안방으로 이동해”	plan/workflow를 task로 등록
MQTT Command Server	서버가 원격 청정/이동 명령 전달	server command를 task로 등록하고 ack/status 반환
App / Remote Control	앱 버튼, 리모컨, 예약 화면	명령 source만 다르고 실행은 동일한 task
On-device Local Voice	로컬 parser가 만든 token/function call	DeviceAgent Bundle을 task로 변환
Internal Policy / Schedule	예약 실행, 자동 복귀, 보호 정책	내부 source의 system task로 등록

계층	책임
Upstream Command Source	Cloud LLM, MQTT 서버, 앱, 예약, 내부 정책 등 task를 만들 수 있는 유입원
Cloud A2A	여러 유입원 중 하나이며, 사용자의 의도와 실행 순서를 plan으로 만든다.
MQTT Command Server	서버 명령을 task/workflow 요청으로 내려주고 ack/status를 받는다.
On-device Bridge	Cloud 또는 로컬 음성 응답을 Bundle/task/workflow로 변환해 DeviceAgent에 전달한다.
DeviceAgent TaskManager	실제 기기 상태를 보고 task admission, queue, executor, event를 관리한다.
SoC Domain	movement, cleaning, map, LLM/TTS, IoT/update 실제 동작을 수행한다.

TaskManager는 upstream 종류와 무관하게 동일한 admission, validation, queue, executor, event contract를 적용한다.
Cloud는 기기 상태를 참고해 plan을 세울 수 있지만, 실제 실행 중 조건 판단은 DeviceAgent가 한다.
MQTT/App/예약 명령도 Cloud LLM을 거치지 않고 TaskManager로 들어올 수 있어야 한다.
정상 event는 Cloud LLM을 다시 호출하지 않는다.
실패/차단/사용자 개입 필요처럼 판단이 필요한 event만 각 source의 policy에 따라 replan, retry, server report, user notification으로 분기한다.
실패 이유는 자연어 문자열이 아니라 reason_code, reason_params, requires_cloud_decision 같은 구조화 필드로 표현한다.