← Docs hub

SoC TaskManager Vendor Briefing Path

이 문서는 SoC/DeviceAgent 업체와 회의하거나 설명할 때 사용할 진입로다. 업체에게 처음부터 전체 소스 설명을 던지면 흐름을 잃기 쉽기 때문에, “왜 바꾸는가 -> 무엇이 바뀌는가 -> 어디를 구현하는가 -> 무엇을 제출해야 하는가” 순서로 설명한다.

1. 10분 요약 설명

업체에게 가장 먼저 전달할 메시지:

이번 작업은 Cloud LLM 전용 기능 추가가 아니다.
기존 DeviceAgent의 직접 method 실행 구조 앞에 TaskManager layer를 추가해서,
Cloud A2A, MQTT 서버, App/Remote, 예약/자동화, 로컬 음성 명령을 같은 SoC 실행 framework로 수용하려는 작업이다.

10분 안에 설명할 핵심:

2. 30분 구조 설명

30분 회의에서는 아래 순서로 설명한다.

2.1 기존 구조

DeviceAgent
-> MainApi.executeMethod(...)
-> executeMethodInternal(...)
-> FrameworkCommandBridge / command handler / domain manager
-> AppCmd callback

핵심 포인트:

• 기존 구조는 단일 method 실행에는 적합하다.
• 하지만 Cloud/MQTT/App/예약이 모두 직접 method를 호출하면 실행 정책과 callback이 source별로 갈라진다.
• 복합명령의 step 상태와 실패 reason을 공통으로 관리하기 어렵다.

2.2 변경 구조

Cloud/MQTT/App/Local Voice/Internal Schedule
-> submitTask / submitWorkflow
-> TaskManager
-> validation / policy / queue / workflow
-> TaskExecutorRegistry
-> 기존 domain handler 또는 SoC executor
-> onTaskEvent

핵심 포인트:

• TaskManager는 기존 domain logic을 대체하지 않는다.
• TaskManager는 기존 domain logic 앞에서 task lifecycle을 관리한다.
• source는 달라도 event/reason/trace contract는 하나로 맞춘다.

2.3 업체가 구현해야 할 경계

3. 60분 구현 딥다이브

구현자와는 아래 순서로 본다.

4. 설명 중 반드시 짚을 오해

5. 회의 후 업체에게 요청할 산출물