← Docs hub

A2A Presentation Storyline

이 문서는 팀원에게 SK-Intellix A2A 작업을 발표할 때 사용할 이야기 순서다. 단순히 문서를 나열하는 것이 아니라, 왜 이 구조가 필요했고, Planner가 어떤 의미를 갖고, 기존 명령 체계와 TaskManager가 어떻게 통합되며, Reactive/Proactive와 Robotics Brain 방향으로 어떻게 확장되는지를 하나의 서사로 설명한다.

0. 발표의 한 줄 메시지

우리가 만들고 있는 것은 단순한 음성 명령 라우터가 아니라, 사용자 발화와 기기 상태를 바탕으로 무엇을 어떤 순서로 할지 계획하고, 기존 명령 체계를 안전하게 통합하며, 장기적으로 reactive/proactive 의사결정을 함께 다루는 로보틱스 의사결정 제어 계층이다.

1. 발표 전체 흐름

2. 발표의 서사 구조

2.1 문제 정의: 기존 명령 체계의 한계

기존 구조는 대체로 “사용자 발화 -> 분류 -> 특정 함수 호출”에 가깝다. 이 구조는 단일 명령에는 효율적이지만 아래 요구가 들어오면 한계가 생긴다.

거실로 가서 공기 상태 확인하고, 나쁘면 안방으로 이동해서 청정해줘

이 발화는 단일 command가 아니다.

• 이동이 먼저 필요하다.
• 상태 조회 결과가 다음 실행 조건이 된다.
• 청정은 앞 step의 결과와 현재 위치에 의존한다.
• 실행 중 막히면 실패 reason이 필요하다.
• 정상 진행 중에는 Cloud LLM이 매번 다시 판단할 필요가 없다.

따라서 필요한 것은 “명령 하나를 고르는 selector”가 아니라 “목표를 보고 step과 의존성을 만드는 planner”다.

2.2 A2A 개요: 말에서 plan으로

A2A의 기본 흐름은 아래다.

User Speech / STT
-> Cloud A2A Planner
-> Agent / Skill selection
-> Runtime Orchestration
-> On-device Bridge
-> DeviceAgent TaskManager
-> Native Domain Execution
-> Event / Reason Feedback

여기서 Cloud는 “무엇을 어떤 순서로 할지”를 계획하고, 기기 쪽은 “실제로 어떻게 안전하게 수행할지”를 책임진다.

2.3 Planner의 의미: selector가 아니라 계획자

Planner는 단순히 ODL, FRG, SCH 중 하나를 고르는 모듈이 아니다. 실제 output은 아래를 포함한다.

selected_routes
selected_agent
selected_skill
turn_mode
steps[]
depends_on
input_from
output_key
missing_slots
needs_second_pass

즉 Planner는 아래를 결정한다.

• 지금 발화가 단일 응답인지, 멀티턴인지, 복합 step인지
• 어느 route family가 주 owner인지
• 어떤 agent/skill이 실행 주체인지
• step 간 순서와 의존성이 있는지
• 사용자에게 추가 slot을 물어야 하는지
• 애매하면 second pass로 넘겨야 하는지

세부 판단 구조는 A2A Planner Deep Dive를 열고 설명한다.

2.4 판단 레이어: 축과 evidence

발화가 들어오면 바로 LLM이 모든 것을 판단하는 것이 아니다. 앞단은 deterministic evidence layer로 동작한다.

recognized_text 정규화
-> preclassifier 축별 evidence 생성
-> reply_object_meta 생성
-> replyability_meta 생성
-> candidate flow/pool 생성
-> main planner LLM 판단
-> 필요 시 second pass

여기서 우리가 “축”이라고 부른 것은 family 자체가 아니라 evidence 방향이다.

튜닝은 family를 룰로 고정하는 것이 아니라, 어떤 축을 얼마나 살리고 언제 2차 판단으로 넘길지 조정한 작업이다.

2.5 기존 명령 체계 통합: 버리는 것이 아니라 감싸는 것

중요한 설계 판단은 기존 DeviceAgent 명령 체계를 버리지 않는다는 점이다. 기존 command는 유지하되, MainApi.executeMethod(...) 근처에 TaskManager layer를 넣어 task-aware 실행으로 확장한다.

기존:
  Source -> MainApi -> executeMethodInternal -> domain function

변경 후:
  Source -> MainApi
    -> TaskManager control method면 submit/status/cancel/workflow 처리
    -> legacy method면 TaskManager wrapper 후 기존 domain function 위임

이 구조의 이점은 아래다.

• 기존 domain 조건 판단을 우회하지 않는다.
• Cloud LLM뿐 아니라 MQTT/App/예약/로컬 음성도 같은 TaskManager 경로를 탈 수 있다.
• 장기 실행 task의 queue, cancel, timeout, callback을 공통화할 수 있다.
• 실패 reason을 구조화해 Cloud replan과 연결할 수 있다.

2.6 복합명령: TaskManager가 필요한 이유

복합명령은 “여러 함수를 순서대로 호출”하는 문제가 아니다. 각 step 사이에 상태가 변하고, 실패 가능성이 있으며, 사용자가 중간에 취소하거나 다른 발화를 할 수 있다.

예시:

거실로 가서 청정하고 안방으로 이동해

흐름:

Cloud Planner:
  step_1 ODL 거실 이동
  step_2 ODL 거실 청정, depends_on step_1
  step_3 ODL 안방 이동, depends_on step_2

On-device Bridge:
  device_task_requests를 workflow로 등록

DeviceAgent TaskManager:
  step queue 실행
  QUEUED/RUNNING/PROGRESS/COMPLETED event 관리
  FAILED/BLOCKED/NEEDS_USER_INPUT이면 reason_code와 함께 보고

정상 이벤트마다 Cloud LLM을 다시 돌리지 않는 것이 핵심이다. Cloud는 처음에 계획을 세우고, 정상 진행은 로컬/DeviceAgent가 처리한다. Cloud가 다시 개입하는 경우는 판단이 필요한 이벤트에 한정한다.

2.7 현재 proactive 진행상황

현재 중심은 사용자 발화 기반 reactive A2A다. 하지만 proactive는 별도 철학이 아니라, signal/event가 사용자 발화 대신 planner 입력으로 들어오는 확장으로 볼 수 있다.

Reactive:
  user utterance -> planner -> action/answer

Proactive:
  sensor/event/policy signal -> gate/risk policy -> planner 또는 lightweight decision -> suggestion/action

지금 단계에서는 proactive가 완성된 제품 기능이라기보다, 아래 기반을 정리하는 중으로 보는 것이 맞다.

• context-aware input 구조
• memory/personalization 설계
• event/reason feedback 구조
• planner와 runtime의 역할 분리
• proactive trigger가 들어와도 같은 안전 정책을 적용할 수 있는 기반

2.8 미래 방향: 로보틱스의 머리

장기적으로 목표는 reactive와 proactive를 통합하는 로보틱스 의사결정 제어 계층이다.

사용자 발화
기기 상태
환경 변화
작업 진행 이벤트
사용자 선호/메모리
정책/안전 조건

이 입력들이 모두 planner의 판단 재료가 되고, planner는 아래를 결정한다.

지금 응답만 할 것인가
기기 action을 실행할 것인가
사용자에게 물어볼 것인가
기존 workflow를 계속할 것인가
실패한 task를 재시도/대체/중단할 것인가
proactive 제안을 띄울 것인가

이 관점에서 A2A Planner는 단순 Cloud 라우터가 아니라, 로보틱스의 “목표 해석, 작업 분해, 실행 위임, 이벤트 기반 재판단”을 담당하는 머리의 초기 형태다.

2.9 Context의 시간 축: 과거, 현재, 미래

현재 우리가 붙이고 있는 context-aware 구조는 시간 축으로 보면 세 단계다.

즉 현재는 “과거 맥락 + 현재 기기 상태”를 planner 동작 전 context로 해석하는 단계다. 사용자가 방금 말한 문장만 보는 것이 아니라, 이전 턴에서 어떤 workflow가 열려 있었는지, 어떤 slot이 비어 있는지, 기기가 지금 어디에 있고 무엇을 하고 있는지를 함께 본다.

앞으로의 방향은 여기에 “변화량”을 추가하는 것이다. 예를 들어 배터리가 단순히 20%라는 현재값만 보는 것이 아니라, 최근 10분 동안 얼마나 빠르게 줄었는지, 이동 중인지, 청정 중인지, queue가 밀려 있는지를 보고 가까운 미래의 실패 가능성을 예측한다.

현재 구조:
  과거 대화/voice context + 현재 device context
  -> planner가 현재 가능한 plan을 줄이고 선택

미래 방향:
  과거 context + 현재 device context + 변화량/추세 context
  -> planner 또는 proactive gate가 다음 상태를 예측
  -> 사전 질문, 사전 경고, 대체 plan, proactive 제안 가능

이 부분은 아직 완성된 기능이라기보다 우리가 나아갈 방향이다. 현재는 context를 “읽고 반영하는 구조”를 세우는 단계이고, 다음 단계는 context의 변화량을 계산해 미래 상태를 추정하는 방향이다.

3. Deep Dive와 논문 정리로 내려가는 경로

발표 본문은 큰 흐름을 설명하는 문서이고, 실제 설계 근거와 소스 레벨 구조는 아래 Deep Dive 문서에서 설명한다. 팀원이나 업체에게 설명할 때는 발표 흐름을 먼저 보여준 뒤, 질문이 나오는 지점에서 해당 deep dive로 내려가는 방식이 좋다.

3.1 논문 정리까지 포함해야 하는 이유

현재 wiki에 쌓인 내용은 단순 구현 메모가 아니다. 아래 축들이 모두 연구 주제로 분리될 수 있다.

• Speech 환경에서 noisy STT를 robust하게 routing하는 문제
• deterministic evidence layer와 LLM planner를 결합하는 구조
• 복합명령을 step plan과 task workflow로 분해하는 구조
• DeviceAgent TaskManager를 Cloud/MQTT/App/예약 명령의 공통 실행 프레임워크로 확장하는 구조
• 정상 이벤트는 로컬에서 처리하고 판단 필요 이벤트만 Cloud replan으로 올리는 event-driven architecture
• 과거 대화 맥락, 현재 기기 상태, 미래 변화량 추정을 통합하는 context-aware robotics brain 방향

따라서 발표의 마지막에는 A2A Research Paper Topics를 열어 “이 작업이 단순 제품 구현을 넘어서 어떤 연구 축으로 확장 가능한가”를 보여주는 것이 좋다.

4. 발표 중 열어볼 핵심 페이지

5. 발표자가 강조해야 할 문장

• “Planner는 selector가 아니라, step과 의존성을 만드는 계획자입니다.”
• “Preclassifier는 정답을 고르는 룰이 아니라, LLM이 과추론하지 않게 축별 evidence를 만드는 단계입니다.”
• “기존 명령 체계는 버리지 않고, TaskManager layer로 감싸서 장기 실행과 복합명령을 다룰 수 있게 만듭니다.”
• “정상 task event마다 Cloud LLM을 다시 돌리지 않습니다. 실패/차단/사용자 결정 필요 이벤트만 replan 대상입니다.”
• “이 작업은 제품 구현이면서 동시에 Speech-LLM routing, task orchestration, event-driven replanning, memory-aware robotics control 연구 주제로 분리될 수 있습니다.”
• “이 구조는 지금은 A2A 복합명령을 위한 기반이지만, 장기적으로 reactive/proactive 로보틱스 의사결정 제어 계층으로 확장됩니다.”

6. 발표 후 남길 액션