A2A-TaskManager 기능 조합 카탈로그
DeviceAgent 전체 기능과 데이터 흐름, Vision/WSS/LiveView/LLM/AWS까지 포함한 상세 카탈로그는 DeviceAgent Agentic Function And Data Catalog를 함께 본다.
기능을 실제 시나리오로 조립할 때 사용하는 Capability Card, 자원 호환성, 완료·실패·재계획 규칙은 DeviceAgent Agentic Capability Composition Guide를 기준으로 한다.
문서 목적
이 문서는 A2A Planner가 A1 기기의 기능을 새 시나리오로 조합할 때 사용하는 설계 기준이다. MR6 DeviceAgent의 60개 등록 task method, planning context, 완료·취소 이벤트와 2026-07-29 실기기 검증 결과를 기준으로 한다.
중요한 구분은 다음 네 가지다.
- 실행 가능: TaskManager task로 등록할 수 있다.
- 완료 보장: 물리 또는 외부 terminal event까지 기다린다.
- 조회 가능: Planner context로 사용할 수 있지만 실행 task는 아니다.
- 미연결: 기기에 기능은 있으나 TaskManager workflow 계약은 없다.
공통 오케스트레이션 계약
| 계약 | 소유자 | 의미 |
|---|---|---|
submitTask |
DeviceAgent | 단일 기기 작업 |
submitWorkflow |
DeviceAgent | 순차·병렬 기기 작업 묶음 |
scheduleTask |
DeviceAgent | 절대 시각 단일 작업 |
scheduleWorkflow |
DeviceAgent | 절대 시각 workflow |
after_step + delayMs |
DeviceAgent | 선행 단계 완료 뒤 상대 지연 |
step_completed |
DeviceAgent | 선행 성공 여부 조건 |
input_from |
Planner/adapter | 이전 단계 결과를 후속 입력으로 연결 |
getTaskStatus/getQueueStatus |
DeviceAgent | 현재 단계와 자원 상태 |
cancelTask/cancelWorkflow |
DeviceAgent | 취소와 보상 실행 |
| bounded replan | Cloud A2A | 실패·정책 위반·사용자 개입 때 계획 재평가 |
direct는 즉시 조회, queued_wait는 같은 자원의 직렬 실행,
async는 terminal event까지 기다리는 물리·세션 작업이다.
60개 등록 method 전체 인벤토리
TaskExecutorBootstrap에 실제 등록된 method 기준이다. 사용자 기능뿐
아니라 조회, 취소, 내부 상태 동기화용 method도 포함한다.
| 모듈 | 수 | 등록 method | 시나리오에서의 의미 |
|---|---|---|---|
| Framework | 7 | getBatteryInfo, getFirmwareVersion, getMainState, getDeviceStatus, getAirCleanerOperation, setLauncherScreen, getConfiguration |
상태 관찰과 Launcher 앱 진입 |
| Station evidence | 2 | getStationLocationEvidence, probeDockingSignal |
스테이션 위치 후보와 물리 동작 없는 도킹 신호 관찰 |
| Stationary observation | 2 | rotateInPlace, observeVisionSemantics |
회전 완료와 정지·관찰 자세 기반 의미 관찰 |
| Main API | 11 | getAirClearAutoStartModeEnable, getFollowMeStatus, reqmap, isMapFilePresent, resetReturnToStationCounter, setAMRMonitoring, checkSecurityBasicAvailability, startSecurityMode, pauseSecurityMode, resumeSecurityMode, stopSecurityMode |
Map·AMR·보안 capability |
| Movement | 4 | setMoveTo, returnToStation, setMoving, stopMovement |
이동·복귀와 취소 |
| Cleaning | 4 | setAirCleanerOperation, setStatusClean, stopCleaning, ampStop |
청정 lifecycle과 하위 정지 |
| LLM/TTS | 4 | setChangeLlmStatus, setLlmTts, stopLlm, stopTts |
음성·LLM 세션 제어 |
| IoT/settings | 3 | setDeviceStatus, setConfig, getConfig |
상태 전달과 설정 |
| Routine/LED | 3 | setEyeLedColor, setCurrentPuiEyeLedColor, startEyeLedScene |
눈 LED와 scene |
| Product schedule | 17 | addSchedule, editSchedule, deleteSchedule, scheduleiot, setActiveSchedule, puiEditSchedule, callschedule, getschedule, getUpComingSchedule, setScheduleExecuted, getScheduleHolidays, setScheduleHolidays, setScheduleExecutionOnHoliday, removeScheduleHoliday, refreshSchedule, gpsLocNearBy, interSchedule |
생활 스케줄 CRUD·휴일·interaction |
| Update event | 3 | OTAUpdateArmResult, OTAUpdateMcuResult, setFirmwareUpdateStatus |
OTA 결과·상태 수신 |
합계 60개 등록 method이며 11개 executor 객체가 이를 처리한다. 60개 모두를 LLM 선택지로 그대로 노출하지 않는다.
| 노출 등급 | 용도 | 대표 예 |
|---|---|---|
| 사용자 목표 | 자연어 요청에서 직접 계획 | 이동, 복귀, 청정, 설정, 스케줄, 웰컴, 바이탈사인 |
| 관찰·조건 | 실행 전후 판단 근거 | 배터리, 위치, 공기질, Map, 청정 상태 |
| lifecycle 보조 | 취소·pause·resume·보상 | 이동 정지, 청정 정지, interaction pause |
| 내부 동기화 | subsystem 상태 전달 | setDeviceStatus, setStatusClean, OTA result |
| 미연결 | TaskManager 계약 추가 전 금지 | LiveView |
Planner는 의미 capability를 선택하고 adapter가 실제 method, queue, timeout, completion, cancel 계약으로 변환한다. 이 경계가 있어야 method 이름 keyword를 찾는 룰 기반 라우팅을 피할 수 있다.
기능 도메인
이동
| Method | 사용자 기능 | 입력 | 완료 | 취소 |
|---|---|---|---|---|
setMoveTo |
방·POI·좌표 이동 | 방 이름/ID 또는 x/y/degree |
movement.arrived와 이동 idle |
stopMovement |
returnToStation |
스테이션 복귀·도킹 | timeout | movement.stationCharging |
stopMovement |
setMoving |
수동 이동 제어 | action |
명령 처리 | stopMovement |
stopMovement |
진행 이동 정지 | 없음 | 정지 명령 처리 | 해당 없음 |
getFollowMeStatus |
팔로우미 상태 확인 | 없음 | 즉시 조회 | 해당 없음 |
Planner는 임의 좌표를 만들지 않는다. 방 이름 또는 ID를 계획에 넣으면
DeviceAgent가 실제 Area catalog에서 poiId, 이름과 좌표를 resolve한다.
이동 전에 청정이 실행 중이면 청정을 먼저 정지하고 cleaning.stopped를
확인한 뒤 이동한다.
실기기 검증:
- 거실
areaId=2이동 완료. movement.arrived후 controller idle까지 기다림.- 복귀는 도킹·충전 이벤트까지 기다린 뒤 완료.
청정
표준 method는 setAirCleanerOperation이다.
| 의미 | 별칭 또는 입력 | 완료 후보 |
|---|---|---|
| 고정·기본 청정 | startBasicAirClear, action=1 mode=0 |
cleaning.started 또는 cleaning.stopped |
| 전체 청정 | startAllAirClear, mode=1 |
cleaning.reportDone |
| 선택 공간 청정 | startSelectiveAirClear, mode=2, area 목록 |
cleaning.stepComplete/reportDone |
| 공기질 기반 청정 | startAirSensorAirClear, mode=3 |
cleaning.reportDone |
| 일시정지·재개 | pauseAirClear, resumeAirClear |
상태 이벤트 |
| 정지 | stopAirClear, action=0 |
cleaning.stopped |
| 청정 후 복귀 | returnAirClearToStation, action=4 |
청정·복귀 계약에 따라 분리 |
주요 입력은 speed, ai, areaId, positionId, cleanMinTimeMs,
cleanMaxTimeMs, timeoutMs다.
실기기에서 청정 시작과 정지를 각각 독립 task로 실행해
cleaning.started/stopped와 physical completion을 확인했다.
상태·Planning context
| 영역 | Planner가 받는 정보 | 가능한 판단 |
|---|---|---|
| 배터리 | 잔량, 저전력, 충전 상태 | 실행·복귀 가능 여부 |
| 위치 | 방 ID·이름, 좌표, 스테이션 여부 | 조건부 이동, 현재 위치 응답 |
| Map | 실제 방 목록·ID·좌표, 편집 상태 | target resolve 가능 여부 |
| 이동 | moving, paused, status, blocked | 중복 이동·pause 처리 |
| 청정 | running, paused, last action, area | 이동 전 정지, 현재 작업 응답 |
| 공기질 | PM, TVOC, NOx, HCHO, CO2, 온습도, 통합 등급 | 상태 해석과 청정 제안 |
| TaskManager | queue, running/pending task | 진행 설명, 충돌·취소 판단 |
| 설정 | 야간·프라이버시·음량·청정 옵션 등 | 정책과 사용자 선호 반영 |
대표 조회 method:
getBatteryInfogetFirmwareVersiongetMainStategetDeviceStatusgetAirCleanerOperationgetAirClearAutoStartModeEnablegetConfiguration,getConfiggetTaskStatus,getQueueStatus,listTasks
공기질은 실행 task가 아니라 읽기 전용 context다. 기본 흐름은
조회 → DEF 해석 → 사용자 확인 → 필요 시 ODL 실행이다.
위치 이름은 runtime Area에서 비어 있으면 같은 ID의 Area catalog로
복구한다. 도킹 상태는 사용자에게 스테이션으로 표현한다.
기기 설정
setConfig/getConfig로 다루는 설정:
- LED/LCD 밝기와 LED 표시 모드
- 온도 단위, 센서 민감도, UV 모드
- 청정 완료 기준, 자동 청정, 최대 청정 시간
- 음성 인식, 음성 유형, 효과·버튼·음성 음량, mute
- 매너, 프라이버시, 야간, 홈 잠금
- 야간 시작·종료 시각
- 기기 이름, 테마, outdoor/weekly WI
안전한 조합은 현재값 조회 → 변경 → post-check → DEF 확인이다.
값이 비어 있는 설정은 성공한 조회처럼 발화하지 않는다.
LLM, TTS, LED, Launcher
| Method | 기능 | 현재 terminal 의미 |
|---|---|---|
setLlmTts |
TTS 요청 | 재생 요청 전달, 재생 종료 아님 |
setChangeLlmStatus |
LLM 상태 제어 | 상태 명령 전달 |
stopLlm, stopTts |
LLM/TTS 정지 | 정지 명령 전달 |
setEyeLedColor |
LED 색 변경 | 명령 전달 |
startEyeLedScene |
LED scene | scene 시작 |
setLauncherScreen |
화면·앱 진입 | 화면 전환 또는 앱 세션 시작 |
TTS 종료 callback이 없으므로 “TTS가 끝난 다음”을 아직 기기 workflow 완료 조건으로 사용하지 않는다.
바이탈사인은 setLauncherScreen(vitalSign)으로 실행 가능하다.
setAppStatus에서 app.sessionStarted/Ended를 만들 수 있지만
sessionEnded는 성공과 취소를 구분하지 않는다. 측정 성공이 필요한
시나리오는 typed result event가 생기기 전까지 사용자 확인을 요구한다.
제품 스케줄과 interaction
제품 스케줄:
- 등록·수정·삭제:
addSchedule,editSchedule,deleteSchedule - 활성화:
setActiveSchedule - 조회:
getschedule,getUpComingSchedule - IoT/PUI 동기화:
scheduleiot,puiEditSchedule - 휴일 정책: get/set/remove holiday, holiday execution
- 실행 갱신:
setScheduleExecuted,refreshSchedule
interSchedule은 welcome, wakeup, relax 같은 장시간 interaction을
실행하며 start/stop/pause/resume/returnToStation을 지원한다.
관찰 가능한 단계:
interaction.startedinteraction.arrivedinteraction.actionStartedinteraction.actionEndedinteraction.returninginteraction.completed
웰컴 내부 행동을 Planner가 작은 명령으로 다시 만들기보다 기존 interaction lifecycle을 사용해야 프라이버시·야간·홈 잠금 정책을 보존할 수 있다.
TaskManager 예약
세 가지 시간 개념을 분리한다.
| 시간 계층 | 소유자 | 대표 발화 |
|---|---|---|
| 반복 생활 스케줄 | 제품 ScheduleManager | “매일 8시에 웰컴 실행해줘” |
| 일회성 절대 시각 | TaskManager schedule | “오늘 9시에 안방 청정해줘” |
| 단계 상대 지연 | workflow trigger | “거실 도착 30초 후 바이탈사인 켜줘” |
Planner는 시간을 구조화하고 DeviceAgent가 실제 대기와 조건 판정을 소유한다. Cloud가 30초를 세거나 callback마다 문장을 다시 해석하지 않는다.
보안, Map, LiveView
| 기능 | 상태 |
|---|---|
checkSecurityBasicAvailability |
구독·PIN·프라이버시·잠금·네트워크·카메라 조건 조회 |
startSecurityMode |
security.started, 120초 async |
reqmap |
mapping.dataReceived 대기 |
isMapFilePresent |
map 존재 즉시 조회 |
| LiveView | 별도 IStreamingControl, TaskManager 미연결 |
보안 시작 전 availability가 선행돼야 한다. LiveView는 task ID, queue, typed terminal event가 없어 현재 workflow에 넣지 않는다.
업데이트
OTAUpdateArmResult, OTAUpdateMcuResult, setFirmwareUpdateStatus는
업데이트 상태 처리 기능이다. OTA 시작 자체와 동일한 기능이 아니다.
업데이트 실행 시나리오는 배터리·충전·네트워크·사용 중 여부를 함께
확인하는 별도 계약이 필요하다.
시나리오 조합 문법
새 시나리오는 다음 다섯 요소로 설계한다.
- Goal: 사용자가 최종적으로 원하는 상태.
- Observe: 판단에 필요한 context나 query.
- Act: TaskManager method.
- Wait: terminal event 또는 명시적 timeout.
- Replan boundary: 실패, 정책 차단, 사용자 취소, 의미 있는 상태 변화.
예:
Goal: 안방 공기 개선 후 복귀
Observe: battery, current location, cleaning state, room catalog
Act 1: setMoveTo(안방)
Wait 1: movement.arrived
Act 2: startBasicAirClear
Wait 2: cleaning.stopped
Act 3: returnToStation
Wait 3: movement.stationCharging
Replan: low battery, unknown room, move failure, user cancel
조합 가능한 대표 시나리오
기기 중심
- 거실 이동 → 청정 시작 → 종료 → 복귀.
- 청정 여부 조회 → 실행 중이면 정지 → 안방 이동.
- 배터리 확인 → 충분하면 작은방 이동 → 청정.
- 공기질 조회 → 상태 설명 → 사용자 승인 → 청정.
- 설정 조회 → 야간 모드 변경 → 재조회.
- map 확인 → 실제 방 resolve → 이동.
- security availability → 가능할 때만 security 시작.
- 웰컴 interaction → action 종료 → 복귀.
- 이동 완료 → 30초 대기 → 바이탈사인.
- 바이탈사인 session 종료 → 결과 불명확 시 확인 → 복귀.
A2A owner 혼합
ODL 공기질 context → DEF 해석ODL 청정 완료 → FRG 뉴스 조회 → DEF 요약ODL 이동 완료 → STM 이야기 세션ODL 이동 완료 → ETR 영어 놀이DEF 선호 확인 → SCH 반복 스케줄FRG 외부 날씨 → DEF 설명 → ODL 청정 제안
기기 task는 DeviceAgent가 완료를 소유하고, FRG/DEF/STM/ETR 콘텐츠는 Cloud A2A owner가 세션을 소유한다.
Experience Supervisor 후보
Supervisor는 workflow 위에서 goal을 유지하고 다음 이벤트만 선별해 재계획한다.
- terminal success/failure
- 정책 차단
- 사용자 취소·pause·resume
- 저전력, 위치 상실, map 변경
- 의미 있는 공기질 변화
- 외부 앱 세션 종료
대표 Agentic 동작:
- 청정 중 저전력이 되면 중단·복귀를 제안하고 승인 후 재계획.
- 웰컴 대상 미감지 시 무한 대기하지 않고 종료·복귀.
- 야간에 큰 음량 콘텐츠를 요청하면 음량 변경을 확인.
- 특정 방 공기질이 반복 악화되면 강제 자동 실행 대신 루틴 등록 제안.
- 외부 앱 종료 이유가 모호하면 성공을 추정하지 않고 후속 확인.
모든 telemetry 변화마다 LLM을 호출하지 않는다. 로컬 정책으로 처리할 수 있는 상태 전이는 DeviceAgent가 처리하고, 의미 경계에서만 bounded replan을 호출한다.
기능 조합 레시피
새 시나리오는 Goal → Observe → Act → Wait → Branch → Compensate →
Replan 순서로 설계한다.
| 항목 | 정의 | 예 |
|---|---|---|
| Goal | 최종 기기·사용자 상태 | 안방 공기 개선 후 복귀 |
| Observe | 판단할 현재 정보 | 배터리, 위치, 청정, 공기질 |
| Act | 실행할 의미 capability | 이동, 청정, 앱 시작 |
| Wait | 후속 단계 진입 조건 | arrived, stopped, session ended |
| Branch | 구조화 결과에 따른 분기 | 저전력이면 청정 생략 |
| Compensate | 실패·취소 시 안전 복구 | 정지 후 스테이션 복귀 |
| Replan | Cloud 판단을 다시 부를 경계 | 정책 차단, 목적지 상실, 사용자 개입 |
| 시나리오 | 구체 단계 | 현재 상태 |
|---|---|---|
| 저전력 안전 청정 | 배터리 → 조건 → 이동 → 청정 → 복귀 | 구현 가능 |
| 공기질 기반 선택 청정 | 센서 snapshot → DEF 해석 → 확인 → 이동·청정 | freshness 보강 권장 |
| 이동 후 바이탈사인 | 이동 → 앱 시작 → 종료 → 결과 확인 → 복귀 | 성공·취소 typed result 필요 |
| 웰컴 후 복귀 | interaction start → action ended → returning → completed | 구현 가능 |
| 야간 콘텐츠 | 야간 설정 → 음량 확인 → 이동 → 콘텐츠 handoff | Cloud owner 연계 필요 |
| 청정 후 뉴스 | cleaning terminal → FRG → DEF | on-device A2A bridge 필요 |
| 보안 순찰 | availability → start/pause/resume/stop → patrol event → 복귀 | managed lifecycle 코드 연결, 실기기 E2E 필요 |
| LiveView 확인 | 보안 이벤트 → LiveView → 사용자 종료 | TaskManager adapter 필요 |
이전 단계 결과는 input_from으로 구조화해 전달한다. 자연어 응답을 다시
파싱해 기기 명령을 생성하지 않는다. 배터리 percent는 condition이,
이동 completedAreaId는 후속 target 검증이 사용한다.
현재 금지 조합
app.sessionEnded를 바이탈 측정 성공으로 간주.- TTS 요청 반환을 재생 종료로 간주.
- LiveView를 TaskManager workflow에 직접 삽입.
- 보안 availability 실패 뒤 실행 계속.
- stale 공기질 snapshot으로 자동 청정 강제.
- 실제 좌표가 없는 방 이름으로 이동.
- progress마다 Cloud LLM 재호출.
- typed cancel·terminal event 없는 기능을 cancellable로 노출.
실기기 검증 요약
2026-07-29 192.168.123.118:5555:
- DeviceAgent
0.257, platform certificate 검증. - DB downgrade와 package signature fatal 없이 부팅.
- 53 executor, 11 public queue 정상.
- 방 목록: 주방 1, 거실 2, 작은방 3, 안방 6.
- 실제 거실 이동 완료.
- 실제 청정 start/stop 완료.
- 실제 스테이션 복귀와 도킹 완료.
- 스테이션 위치 이름 planning context 반영.
- 원격 monitor는 로컬 보관 token과 Worker secret 불일치로
401. 운영 secret을 임의 회전하지 않고 별도 credential 과제로 분리.
다음 구현 우선순위
- 현재 on-device Agent
1.19.36에 Cloud A2A bridge를 회귀 없이 정합. - capability context를 executor registry 기반으로 확장.
- 바이탈사인 성공·취소 typed result 추가.
- TTS terminal event 추가.
- LiveView TaskManager adapter 설계.
- security 즉시 거절을 terminal failure로 연결.
- monitor credential 자동 주입과 rotation 절차 확립.
- 완료·취소·재계획 경계를 포함한 50~60개 회귀 시나리오 운영.