← Docs hub

Speech-LLM Context-Aware A2A Architecture

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

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

1. 목적

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

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

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는 아래 입력을 함께 본다.

기준은 명확하다.

• 현재 발화가 항상 1순위다.
• memory와 history는 현재 발화를 덮어쓰지 않는다.
• device_context는 불가능한 plan을 사전에 줄이는 데 사용한다.
• preclassifier/capability/ranked hint는 evidence이지 최종 결정자가 아니다.

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
}

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

5. Agent & Skills 책임

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

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 재판단 대상이 아니다.

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 환경에서는 텍스트 챗보다 아래 리스크가 크다.

10. Memory 연결

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

메모리 승격 기준:

• short-term은 매 turn 기록한다.
• mid-term은 session/day 단위 요약과 반복 맥락을 보존한다.
• long-term은 명시 확인 또는 반복 증거가 있는 안정 정보만 저장한다.

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

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

13. 관련 문서

• A2A System Overview
• A2A Planner and Routing
• A2A Contract Matrix
• A2A Device Task Flow
• A2A Scenario Walkthroughs
• Memory and Personalization
• Memory DB and Sync Contract
• A2A Requirements Traceability Matrix
• A2A Status and Gap Audit