← Docs hub

TaskManager 사양 7 · Core와 Task 규범

TaskManager Core, 관리 대상 Task, 기기 상태와 도메인별 연동의 필수 규범을 정의한다.

이 장의 결론: 모든 Task는 실행 허용, 자원, 취소, timeout과 terminal authority를 명시하고 기기 도메인의 정책을 계승해야 한다.

29. TaskManager Core, 관리 대상 Task와 기기 연동 규범

이 장은 앞의 구현 설명을 제품 사양의 세 계층으로 정리한다. TaskManager가 공통으로 보장할 사양, 각 Task가 개별적으로 선언할 사양, 실제 기기 상태가 실행 허용과 완료에 미치는 영향을 분리한다.

위 3계층 계약 구조도는 모든 Task에 공통인 TaskManager Core 사양, 기능별 입력·정책·완료·취소를 정의하는 관리 대상 Task 단위 사양, 실제 제품 상태와 자원 제약을 제공하는 기기 도메인 연동 사양을 분리한다.

이 세 층을 섞으면 다음과 같은 오류가 생긴다.

• TaskManager가 요청을 접수했지만 기존 DeviceAgent 정책에서 뒤늦게 거절된다.
• 메서드가 반환됐다는 이유만으로 물리 동작을 완료 처리한다.
• LLM 활성 중 신규 동작 제한과 이미 수행 중인 동작의 일시정지·재개를 같은 정책으로 오해한다.
• 장기 앱 세션을 화면 전환 ACK만으로 완료 처리한다.
• Planner가 기기 상태를 참고했어도 DeviceAgent의 최종 안전 정책을 우회하게 된다.

29.1 TaskManager Core 규범 사양

TaskManager Core는 기능의 내용이 아니라 실행의 질서와 증거를 소유한다.

29.1.1 Core 불변 조건

1. Task 접수 성공은 기능 완료가 아니다. accepted=true는 실행 허용 판정과 기록 생성에 성공했다는 뜻이다.
2. 물리 Task의 성공은 최신 완료 증거로 확정한다. completionSinceMs보다 오래된 콜백은 사용할 수 없다.
3. 취소는 성공으로 변환하지 않는다. 사용자 취소, PUI 중단, 외부 앱 종료를 목적 달성으로 해석하지 않는다.
4. TaskManager는 기기 도메인 안전 정책보다 높은 권한을 갖지 않는다. 대기열 우선순위가 배터리, 오류, 개인정보 보호와 제품 모드 제한을 우회하지 않는다.
5. 관찰 이벤트는 실행 명령이 아니다. 센서 값이나 콜백을 그대로 구동 Task로 다시 제출하지 않는다.
6. 상위 Planner 장애가 현재의 안전한 동작을 깨면 안 된다. 정상적인 후속 실행과 기기 내 취소·시간 제한 처리는 기기에서 마감한다.
7. 같은 물리 효과를 만드는 중복 제출을 식별할 수 있어야 한다. 요청·추적·Workflow·단계 ID를 보존한다.
8. 지원하지 않는 기능을 유사 기능으로 임의 대체하지 않는다. 실행기나 필수 입력이 없으면 명시적으로 거절한다.

29.1.2 실행 허용 정책과 실행 중 정책의 차이

실행 허용 정책은 두 시점에 적용된다.

따라서 TaskManager가 accepted=true를 반환해도 기기 도메인 실행 시점에 상태가 바뀌면 POLICY_NOT_ALLOWED 또는 도메인 오류로 실패할 수 있다. 목표는 도메인 규칙을 TaskManager에 복제하는 것이 아니다. 공통으로 표현할 수 있는 상태와 자원을 실행 허용 판정에 반영하되, 최종 도메인 판정을 유지하는 것이다.

29.2 관리 대상 Task 단위 규범 사양

관리 대상 Task는 단순한 “함수 이름과 매개변수 묶음”이 아니다. 최소한 다음 다섯 질문에 답할 수 있어야 한다.

관리 대상 기능은 다음 질문에 모두 답할 수 있어야 한다.

• 무엇을 실행하는가?
• 어떤 상태와 자원이 있어야 시작할 수 있는가?
• 언제 실제 완료로 판단하는가?
• 어떻게 중단하고 복구하는가?
• 실패 후 누가 다음 결정을 하는가?

29.2.1 Task 설명자 필드

현재 TaskPolicyRegistry.resolve()는 요청이 정책 기본값을 덮어쓸 수 있게 한다. 그러나 호출자가 임의로 대기열, 우선순위와 시간 제한을 바꿔도 된다는 뜻은 아니다. 외부 공개 AAR과 Cloud 계약에는 기능 설명자가 허용한 변경 항목만 노출해야 한다.

29.2.2 Task 유형별 필수 사양

29.2.3 Task 최종 상태 판정

시간 제한은 완료 조건을 대신하지 않는다. 제한 시간이 지나면 성공으로 처리하지 않고 FAILED 또는 세션별 명시 정책으로 마감한다. 바이탈사인처럼 사용자의 측정 완료나 취소로 끝나는 Task는 임의로 30초 뒤 완료 처리하지 않는다. 앱의 완료·취소 증거를 기다려야 한다.

29.3 LLM/음성 세션과 기기 동작 연동 사양

이 절은 TaskManager 전체 요청 경로를 음성 중심으로 설명하지 않는다. LLM·음성 세션이 마이크, 스피커와 추론 자원을 점유할 때 추가로 적용되는 도메인 제약만 정의한다.

“LLM 동작 중 다른 동작 제한”은 하나의 boolean 규칙이 아니다. 현재 구현에는 신규 명령 실행 제한, 기존 동작 일시정지·재개, LLM 상태 관찰이 별도로 존재한다.

29.3.1 LLM 상태 모델

LlmPipelineObservationBridge는 다음 상태를 planning context의 voice_llm으로 투영한다.

이 값은 ondevice_agent_reported_status를 기반으로 하며 유효 시간과 최신성 조건이 있다. 오래된 상태를 Planner의 실행 근거로 사용하면 안 된다.

29.3.2 신규 기기 동작 제한

CmdPolicyManager.commonCheck()는 LlmManager.isLlmProcessingStatus()가 true인 동안 일반 이동, 청정과 스케줄 계열의 신규 동작을 기본적으로 거절한다.

현재 예외는 다음과 같다.

• 공기 센서 자동 청정 호출은 제한적으로 허용한다.
• 저전력/에러에 의한 안전 복귀는 CHK_OPT_IGNORE_LLM으로 LLM 제한을 우회할 수 있다.
• 이 우회는 안전·내부 복구용이며 일반 Cloud·VOICE Task에 노출하면 안 된다.

중요한 현재 경계:

• TaskManager Core의 TaskDomainResourcePolicy는 아직 모든 물리 Task에 voice_session 자원을 자동으로 할당하지 않는다.
• 따라서 LLM 활성 상태의 일반 Task가 TaskManager의 실행 허용 판정을 통과한 뒤 기존 기기 도메인 정책에서 거절될 수 있다.
• 계획 컨텍스트의 voice_llm.pipeline_busy는 Planner 입력이지만, 이것만으로 DeviceAgent의 최종 정책을 대체하지 않는다.

29.3.3 기존 동작 일시정지·재개

호출어가 감지되면 notifyLearnedKeywordDetected 경로가 setDeviceStatus(action=pause)를 호출한다. 이 경로는 현재 활성 domain 중 하나를 pause한다.

LLM 처리가 끝나고 기기 동작이 일시정지 상태이면 setLlmStatus 경로가 재개를 시도한다. 일시정지 요청자는 목록으로 관리된다. 따라서 필터 커버 오류처럼 LLM 외 다른 원인이 남아 있으면 LLM 종료만으로 재개하지 않는다. E01/S08 같은 오류 상태도 재개를 막는다.

persist.sys.debug.deviceagent.maumai_tmp_pause_resume는 LLM 상태 변화만으로 일시정지·재개를 연결하는 임시 속성이다. 기본 활성 사양으로 간주하면 안 된다. 제품 기준은 호출어, 명시적 기기 상태 생명주기와 실제 오류 조건을 함께 확인한다.

29.3.4 LLM 연동 규범

1. 사용자의 음성 세션 시작을 위해 현재 Workflow를 COMPLETED로 만들지 않는다. 필요한 도메인만 일시정지한다. 현재 TaskRecord에는 별도 PAUSED 상태가 없어 기록은 RUNNING으로 남으므로, 도메인 일시정지 사실은 단계·이벤트로 보강해야 한다.
2. 음성 세션 중 새 물리 Task는 기기 도메인 정책이 허용할 때만 실행한다.
3. 안전 복귀 같은 긴급 경로는 일반 사용자 우선순위와 분리한다.
4. 재개는 LLM IDLE 상태만 보지 않고 일시정지 요청자와 현재 오류를 확인한다.
5. voice_session_active, pipeline_busy, output_state를 구분한다. 외부 TTS 재생을 사용자 음성 추론 세션으로 오해하지 않는다.
6. Task 이벤트에는 “LLM 때문에 실행 허용 거절”, “LLM으로 기존 동작 일시정지”, “다른 오류 때문에 재개 보류”를 서로 다른 실패 사유로 노출해야 한다.

29.4 기기 상태와 자원 연동 행렬

아래 표의 Core는 TaskManager의 실행 허용과 런타임을, 기기 도메인은 기존 DeviceAgent의 기능 정책을 뜻한다.

29.4.1 현재 자원 요구 계약

현재 speaker, microphone, tilt_head, voice_session, map_writer, network_uplink은 공통 자원 점유 계약으로 완전히 모델링돼 있지 않다. 문자열 규칙만 추가하지 말고 기능 설명자와 실행기가 같은 자원 용어를 사용하도록 확장해야 한다.

29.5 도메인별 관리 대상 Task 사양

29.5.1 이동과 스테이션 복귀

MovementTaskExecutor는 이동 전에 활성 청정을 멈추고 cleaning.stopped를 기다리는 전환 경로를 갖는다. 이는 “청정 중 이동 불가” 정책을 임의로 우회하는 예외가 아니다. 같은 Workflow 안에서 선행 물리 동작을 안전하게 정리한 뒤 이동하는 관리 전환이다.

현재 엄격 검증기가 허용하는 setMoveTo 키와 실행기가 실제로 인식하는 areaId, targetRoom, roomName 범위에 차이가 있다. 엄격 검증을 기본 활성화하기 전에 검증기와 표준 어댑터를 정합해야 한다.

29.5.2 청정

청정 시작 응답을 완료로 볼지, 일정 시간 청정 후 중지를 완료로 볼지, 전체 이동청정 결과 보고까지 기다릴지는 Workflow 목적에 따라 completionTarget으로 구분한다.

29.5.3 LLM/TTS

TTS는 스피커를 사용하지만 현재 공통 speaker 자원 점유 계약이 없다. Security·이동과 동시 실행 가능한지, 사용자 음성 입력 중 재생을 허용할지는 제품 UX 정책으로 명시하고 기능 자원에 반영해야 한다.

29.5.4 바이탈사인과 외부 앱 세션

바이탈사인은 화면을 띄운 순간 끝나는 단기 UI Task가 아니다. 측정 완료 또는 취소까지 이어지는 장기 세션이다. 후속 단계는 앱 세션의 최종 증거를 받은 뒤에만 시작한다.

29.5.5 보안

Security 시작은 자신의 현재 Security 상태를 자원 스냅숏에서 제외해 자기 충돌을 피한다. 일시정지·재개·중지는 기존 세션 제어로 실행을 허용한다.

29.5.6 Welcome·Wakeup·Relax 상호작용

interSchedule의 기본값은 ASYNC 실행, interaction 대기열, HIGH 우선순위, 1200초 제한이다. 완료 상태는 scheduleId를 키로 조회한다. InterScheduleManager에는 LLM 개입 정책으로 WAIT, RESTART, STOP이 정의돼 있으며 현재 기본값은 STOP이다.

STOP 정책에서도 relax 음원은 호출어 또는 LLM 세션이 시작되면 일시정지하고, 세션이 끝나면 재개하는 별도 흐름을 따른다. 단순히 예약 시각이 됐거나 TTS가 시작됐다는 이유로 전체 상호작용을 완료 처리하면 안 된다.

29.5.7 Vision, 회전과 스테이션 관찰

관찰 Task가 COMPLETED라는 것은 센서 호출이 정상 종료됐다는 뜻일 수 있다. 원하는 객체를 찾았거나 스테이션 위치 변경을 확정했다는 뜻은 아니다. 결과 구조의 detected, 신뢰도, 최신성과 증거 품질을 다음 단계 조건에서 확인해야 한다.

29.6 Workflow에서 Task 단위 사양을 사용하는 방법

예를 들어 “안방으로 이동해 바이탈사인을 측정하고 끝나면 스테이션으로 복귀”는 단순히 세 Task를 나열한 것이 아니라, 서로 다른 세 완료 계약을 연결한 Workflow다.

중간에 사용자가 말을 걸면 단계 1 또는 단계 3은 일시정지·재개 대상이 될 수 있다. 단계 2는 외부 앱 세션 정책에 따라 음성 처리 허용 여부를 따로 정의해야 한다. 바이탈사인 화면이 열렸다고 단계 3을 시작하거나, LLM이 IDLE이 됐다는 이유만으로 바이탈사인 세션을 완료 처리하면 안 된다.

29.7 구현 상태와 보강 우선순위

보강의 핵심은 if (발화에 특정 단어가 있으면) 같은 규칙을 늘리는 것이 아니다. 기능이 요구하는 자원, 현재 기기 상태와 Task 완료 계약을 구조화해 상위 Planner와 DeviceAgent가 같은 용어와 계약을 사용하게 하는 것이다.