← Docs hub

Speech-LLM Context-Aware A2A Architecture

이 문서는 Speech 기반 사용자 발화가 Cloud A2A Planner, Agent/Skill, 복합제어, 온디바이스 Bridge, DeviceAgent TaskManager, Memory로 이어지는 전체 판단 구조를 한 번에 연결한다.

기존 문서들이 개별 축을 설명한다면, 이 문서는 “실제 음성 명령 한 턴이 어떤 context를 읽고, 어떤 agent/skill plan으로 바뀌고, 어떤 기준으로 기기 복합제어까지 내려가는가”를 설명하는 상위 운영 가이드다.

이 구조를 왜 도입하는지와 구축 이점은 Architecture Rationale and Benefits를 먼저 보면 된다.

Reactive voice turn과 proactive signal turn을 함께 운영하는 구조는 Reactive and Proactive Operation을 기준으로 본다.

Speech-LLM Context-Aware A2A Architecture

1. 목적

Speech-LLM 환경에서 A2A가 해결해야 하는 핵심은 단순 classification이 아니다.

필요한 것은 아래 네 가지를 동시에 만족하는 turn supervisor다.

목표
Speech/STT 깨진 발화와 살아 있는 의도를 구분한다.
Context-aware 현재 발화를 우선하되, 세션/메모리/기기 상태를 보조 증거로 사용한다.
Planner route family 하나를 고르는 데서 끝나지 않고, agent step과 의존성을 만든다.
Composite control Cloud step, device step, memory update, event/replan을 안전하게 연결한다.

2. 전체 판단 루프

매 turn에서 동일한 구조를 반복한다.

Speech Input
  -> STT recognized_text
  -> STT_NULL / recoverability guard
  -> Context Assembly
  -> Context-aware Planner
  -> Agent & Skill Step Plan
  -> Runtime Execution
  -> On-device / DeviceAgent TaskManager
  -> Event / Memory / Replan Feedback

중요한 점은 STT_NULL 검사가 선행되지만, 복합명령 후보가 명확한 발화를 노이즈라는 이유로 통째로 버리면 안 된다는 것이다. STT가 일부 불완전해도 자연스러운 첫 응답 방향과 실행 가능한 step이 살아 있으면 planner로 넘긴다.

3. Context Assembly

Planner는 아래 입력을 함께 본다.

입력 역할 우선순위
recognized_text 현재 STT 결과. 모든 판단의 기준점 최상
voice_context 최근 턴, active workflow, pending follow-up, last route 높음
device_context 배터리, 현재 위치/방, 지도, cleaning/movement 상태, task queue, capability 높음
memory_snapshot 단기/중기/장기 사용자 맥락과 선호 보조
preclassifier_hints family 판단용 evidence flag 보조
capability_registry 가능한 device action/state/settings 및 미지원 범위 보조
ranked_top_flows legacy flow/catalog 후보 보조

기준은 명확하다.

3.1 Context의 시간 축

Context-aware 구조는 단순히 정보를 많이 넣는 것이 아니라, 시간 축을 나누어 해석하는 구조다.

시간 축 현재 반영 상태 Planner에 주는 의미
과거 반영 중 대화 내역, voice context, active workflow, slot state를 통해 현재 발화의 의미를 보정한다.
현재 반영 중 Device context를 통해 현재 기기 상태, 위치, battery, movement, cleaning, queue를 보고 가능한 plan을 줄인다.
미래 향후 방향 현재 상태의 변화량과 추세를 계산해 가까운 미래의 실패/완료/위험 가능성을 예측한다.

현재까지의 구조는 “과거 맥락 + 현재 기기 상태”를 planner 동작 전 context로 녹이는 단계다. 앞으로는 여기에 변화량 기반 context를 추가해 proactive 판단과 대체 plan 생성으로 확장하는 것이 방향이다.

과거: 이전 대화, active workflow, memory
현재: device planning context, current task queue, battery/location/cleaning/movement
미래: delta, trend, predicted state, proactive risk

3.2 Context-aware의 직접 이점

이점 설명
STT 노이즈 내성 발화 일부가 깨져도 target/reply shape/workflow slot이 살아 있으면 복구 가능하다.
재질문 감소 이미 수집된 slot, active workflow, 최근 대화 맥락을 다시 묻지 않는다.
실행 실패 감소 device_context로 배터리, 위치, queue, capability를 확인해 불가능한 plan을 줄인다.
개인화 기반 응답 short/mid/long memory를 통해 반복 선호와 최근 맥락을 반영한다.
복합명령 안정성 이전 step 결과와 실행 순서를 명시해 mixed workflow를 안정화한다.

4. Planner 산출물

Planner는 selector가 아니라 plan generator다.

최소 출력은 아래 형태여야 한다.

{
  "turn_mode": "singleton|multi_turn|parallel",
  "selected_routes": ["ODL|FRG|DEF|SCH|DQR|UNS|STT_NULL|STM|ETR"],
  "steps": [
    {
      "id": "step_1",
      "route": "FRG",
      "execution_target": "cloud",
      "purpose": "검색할 후보 지역 찾기",
      "depends_on": [],
      "input_from": [],
      "wait_policy": "completed",
      "output_key": "candidate_places"
    }
  ],
  "missing_slots": [],
  "ask_follow_up": false
}

복합명령에서 특히 중요한 필드는 아래 네 가지다.

필드 의미
depends_on 물리적/순차적 완료 대기
input_from 이전 step의 결과를 다음 step의 입력으로 사용
execution_target cloud, device, mixed, local_bridge 중 어디서 실행할지
wait_policy submitted/completed/event/needs_user_input 중 무엇을 기다릴지

5. Agent & Skills 책임

A2A의 route family는 실제 실행 책임과 연결되어야 한다.

Family Agent/Skill 관점 주요 책임
STT_NULL STT repair guard 입력이 깨졌을 때 복구 가능성, scoped probe, hard retry 판단
DEF default conversation skill 일반 대화, wording/style/meta help, 생활 조언, 최종 응답 합성
FRG search/public lookup skill 외부 정보, freshness-aware lookup, 추천, public entity 정보
SCH schedule expert skill 알람, 타이머, 리마인더, 예약 workflow
DQR device Q&A/RAG skill 기기/제품/assistant 설명, 사용법, troubleshooting
ODL on-device local/device control skill 기기 실행, live state query, device task request 생성
UNS unsupported skill 실행 의도는 있으나 현재 제품/권한/기능 범위 밖임을 안내
STM story mode skill story realtime mode 진입/유지/종료
ETR English tutor skill English tutor realtime mode 진입/유지/종료

Planner가 ODL step을 만든다고 해서 Cloud가 직접 네이티브 함수를 호출하는 것은 아니다. Cloud는 device-consumable intent/task request를 만들고, 온디바이스 Bridge와 DeviceAgent TaskManager가 실제 조건 판단과 실행을 담당한다.

6. 복합제어 원칙

복합제어는 “한 번에 여러 명령을 보낸다”가 아니라 “의존성을 가진 workflow를 안전하게 실행한다”는 뜻이다.

예시 발화:

거실로 갔다가 안방으로 이동해서 청정해줘

Planner step:

step_1 ODL device: 거실로 이동
step_2 ODL device: 안방으로 이동, depends_on=step_1
step_3 ODL device: 안방 청정 시작, depends_on=step_2

온디바이스/DeviceAgent 관점:

step_1 -> movement task
step_1 COMPLETED -> step_2 unlock
step_2 -> movement task
step_2 COMPLETED -> step_3 unlock
step_3 -> cleaning task
WORKFLOW_COMPLETED -> 종료

정상 이벤트는 Cloud LLM 재판단 대상이 아니다.

이벤트 기본 처리
QUEUED 상태 표시, audit 기록
RUNNING 진행 상태 표시
PROGRESS progress UI/notification 갱신
COMPLETED 다음 local step unlock
WORKFLOW_COMPLETED workflow 종료 및 short-term memory 기록
FAILED, BLOCKED, PAUSED, NEEDS_USER_INPUT 구조화 reason과 함께 Cloud replan 후보

7. Cloud-only 복합 계획

복합 계획이 항상 기기 제어를 포함하는 것은 아니다.

예시 발화:

보통 교통상황이 안 좋은 곳을 알아보고 오늘 그곳 정보를 줘

가능한 plan:

step_1 FRG cloud: 상습 정체 지역 후보 검색
step_2 FRG cloud: step_1 결과 지역의 오늘 정보 조회, input_from=step_1
step_3 DEF cloud: 사용자에게 결과 요약, input_from=step_2

이 경우 depends_on도 필요하지만 핵심은 input_from이다. step_2가 step_1의 결과를 의미적으로 사용해야 하기 때문이다.

8. Mixed Cloud + Device 계획

Cloud-only 판단과 device 실행이 섞이는 경우도 있다.

예시 발화:

오늘 미세먼지 심하면 거실 청정해줘

가능한 plan:

step_1 FRG/ODL cloud-or-device: 오늘 미세먼지 또는 현재 공기질 확인
step_2 DEF cloud: 기준 초과 여부 판단
step_3 ODL device: 조건 충족 시 거실 청정 시작, input_from=step_1, depends_on=step_2

이 구조에서는 Planner가 조건과 순서를 표현하고, 실제 device 실행 가능성은 device_context와 온디바이스/DeviceAgent 계약이 보장해야 한다.

9. Speech-LLM 운영 규칙

Speech 환경에서는 텍스트 챗보다 아래 리스크가 크다.

리스크 운영 규칙
STT fragment STT_NULL로 닫기 전에 살아 있는 target/reply shape/agent direction을 확인한다.
발화 중 주제 전환 active workflow보다 현재 발화를 우선하고 continuation/cancel/topic_shift를 판별한다.
짧은 슬롯 응답 active workflow가 있으면 내일, 7시, 거실 같은 fragment도 workflow slot으로 해석한다.
복합명령 일부 누락 실행 가능한 prefix와 missing slot을 분리하고, 필요한 경우 가장 좁은 follow-up만 묻는다.
mode 진입 중 interruption story/tutor mode는 session owner지만, 중단/전환/부가 요청은 main router가 감독한다.

10. Memory 연결

메모리는 context-aware 판단의 보조 계층이다.

계층 단위 주요 내용
Short-term user-assistant pair, active session 최근 발화, active workflow, pending task, unresolved slot
Mid-term day/week summary 반복되는 의도, 이어지는 task, session-level preference
Long-term user/device profile 명시 확인된 안정 선호, 저장 루틴, 장기 device fact

메모리 승격 기준:

11. 현재 위키에서 보강된/보강해야 할 부분

항목 현재 상태 보강 필요성
A2A 전체 구조 system-overview, visual-map에 존재 Speech-LLM context 흐름을 본 문서로 보강
Planner 판단 planner-routing에 존재 Agent/Skill 책임과 연결을 더 명확히 해야 함
복합제어 device-task-flow, scenario-walkthroughs에 존재 Cloud-only, device-only, mixed 예시를 회귀 테스트로 고정 필요
Agent & Skills 일부 family 설명만 존재 route family와 실제 agent/skill 책임 매핑을 별도 기준으로 유지 필요
Context-aware memory, device_context 문서가 분리됨 context priority와 conflict rule을 공통 기준으로 유지 필요
Speech 환경 명시 문서 부족 STT_NULL, slot fragment, interruption, mode handling 기준 필요
검증 validation, requirements-traceability에 존재 Speech-noisy fixture, mixed multi-step fixture, event replay fixture 추가 필요

12. 구현/검증 체크리스트

체크 완료 기준
Planner prompt recognized_text, voice_context, device_context, memory_snapshot의 우선순위가 명시되어 있다.
Response schema steps[].depends_on, steps[].input_from, steps[].execution_target, steps[].wait_policy가 보존된다.
Agent catalog family별 실행 agent/skill과 제외 범위가 문서/테스트 fixture에 연결된다.
Cloud runtime Cloud-only step, device step, mixed step 변환 테스트가 있다.
On-device bridge device_intent_step 순차 실행과 local unlock 테스트가 있다.
DeviceAgent TaskManager submitWorkflow, onTaskEvent, reason_code, requires_cloud_decision 계약이 검증된다.
Memory short/mid/long memory read/write 정책과 DB schema가 분리 검증된다.
Speech regression STT_NULL, noisy DEF/FRG/ODL/SCH, slot fragment, mode interruption fixture가 있다.

13. 관련 문서

Keyboard shortcuts

⌘K / Ctrl+KOpen command palette
/Focus search
g hGo to home
g pGo to projects
g sGo to sessions
j / kNext / prev row (tables)
?Show this help
EscClose dialogs

Structured queries

Mix key:value filters with free text in the palette:

type:sessionOnly session pages
project:llm-wikiFilter by project name (substring)
model:claudeFilter by model name (substring)
date:>2026-03-01Sessions after a date
date:<2026-04-01Sessions before a date
tags:rustPages mentioning a tag/topic
sort:dateSort results by date (newest first)

Example: type:session project:llm-wiki date:>2026-04 sort:date