A2A Adoption Benefits and Roadmap
이 문서는 A2A 구조를 도입했을 때 제품과 플랫폼 관점에서 무엇이 좋아지는지, 그리고 현재 reactive 음성명령에서 장기 robotics brain 방향까지 어떤 순서로 확장할지 정리한다. 기존 명령 체계와 A2A 이후 구조의 차이를 먼저 보고 싶다면 A2A Before/After Impact Analysis를 먼저 본다.
이 그림은 현재의 reactive router baseline에서 schedule workflow, task orchestration, feedback calibration을 거쳐 proactive/robotics decision layer로 확장되는 단계를 요약한다.
1. A2A 도입으로 얻는 이점
| 영역 | 기존 한계 | A2A 도입 효과 |
|---|---|---|
| 사용자 발화 해석 | 단일 command 중심 | 발화 목적, context, capability를 함께 보고 route/plan 생성 |
| 복합명령 | 여러 command를 수동으로 연결해야 함 | step/dependency/input_from으로 workflow 표현 |
| 멀티턴 | slot 누락 시 흐름이 끊김 | active workflow와 missing slot 기반 follow-up |
| 기기 상태 반영 | 현재 상태가 판단 전에 충분히 반영되지 않음 | device context snapshot을 planner 입력으로 사용 |
| 실행 안정성 | 실패/차단이 자연어 또는 domain error로 흩어짐 | reason_code/recoverability/requires_cloud_decision 구조화 |
| 업체 협업 | Cloud 판단과 DeviceAgent 구현 경계가 모호함 | AAR/API contract와 TaskManager event boundary로 분리 |
| 성능 튜닝 | 라벨별 prompt 수정 중심 | semantic boundary calibration과 benchmark baseline 관리 |
| 미래 확장 | reactive 명령과 proactive event가 분리됨 | 같은 planner/runtime 철학으로 signal 기반 판단 확장 |
2. Context-aware의 실질 이점
Context-aware는 단순히 prompt에 정보를 많이 넣는 것이 아니다. 어떤 정보를 어느 시점에 판단축으로 사용할지 정리하는 구조다.
| Context | 현재 의미 | 이점 |
|---|---|---|
| 과거 대화 | 직전 발화, active workflow, missing slot | 짧은 후속 답변을 복구 |
| 현재 기기 상태 | 위치, 배터리, 청정/이동 상태, 지원 기능 | 실행 가능성 판단과 안전한 거절 |
| 현재 catalog | agent/skill/capability 목록 | hallucinated skill 방지 |
| 실행 event | task status, reason_code, recoverability | 실패 시 replan 또는 사용자 확인 |
| 미래 변화량 | 아직 본격 구현 전 | proactive 판단과 위험 예측 방향 |
예시:
사용자: 안방 공기청정 예약해줘
시스템: 몇 시부터 몇 시까지 할까요?
사용자: 밤 열 시부터 아침 일곱 시까지
두 번째 사용자 발화만 보면 단순 시간 표현이다. 하지만 active schedule workflow가 있으므로 시간 slot answer로 해석된다. 이것이 context-aware routing의 실질 가치다.
3. Planner 도입 효과
Planner는 selector보다 상위 개념이다.
selector:
utterance -> family 하나 선택
planner:
utterance + context + catalog + device state
-> owner route
-> turn mode
-> step list
-> dependency
-> missing slot
-> replan policy
Planner를 두면 아래가 가능해진다.
- 하나의 발화를 여러 step으로 나눈다.
- step 간 순서와 의존성을 표현한다.
- 사용자에게 지금 무엇을 물어야 하는지 결정한다.
- 지원 불가, 기기 상태 제한, 안전 조건을 판단에 넣는다.
- 실패 event를 보고 전체 workflow를 다시 계획할 수 있다.
4. Agent/Skill Catalog 도입 효과
Catalog는 LLM에게 “아무거나 해도 된다”고 열어주는 것이 아니라, 가능한 agent와 skill의 세계를 제한한다.
| 구성요소 | 역할 |
|---|---|
| route family | ODL, SCH, DQR, FRG, DEF, UNS, STT_NULL 같은 큰 방향 |
| agent | 실제 판단/응답/실행을 맡는 owner |
| skill | agent가 수행할 수 있는 기능 단위 |
| capability | 실제 기기/서비스가 지원하는 기능 |
| visibility | planner에 노출해도 되는지 여부 |
| scheduling flag | workflow/slot 기반 실행 가능 여부 |
이 구조의 이점은 아래다.
- Planner가 catalog 밖 기능을 만들 가능성을 줄인다.
- 기획/업체/개발자가 같은 기능 목록을 기준으로 이야기할 수 있다.
- 새 기능을 추가할 때 prompt 전체를 바꾸지 않고 catalog와 contract를 확장할 수 있다.
- UNS와 DQR/ODL 경계가 명확해진다.
5. Task Orchestration 도입 효과
Task Orchestration은 “LLM이 모든 실행을 계속 판단하는 구조”가 아니다.
Cloud Planner:
목표와 step을 만든다.
On-device Bridge:
Cloud step을 기기 실행 요청으로 변환한다.
DeviceAgent TaskManager:
queue, cancel, timeout, progress, result, reason을 관리한다.
Cloud Replan:
requires_cloud_decision=true일 때만 재개입한다.
이 구조는 비용과 안정성 모두에 이점이 있다.
- 정상 progress마다 LLM 호출을 하지 않아 latency와 비용을 줄인다.
- 실행 lifecycle은 기기 쪽에서 deterministic하게 관리한다.
- Cloud는 실패/차단/사용자 판단 필요 시점에만 고수준 판단을 한다.
- MQTT/App/PUI/Cloud 등 여러 source가 같은 TaskManager contract를 쓸 수 있다.
6. Reactive에서 Proactive로 가는 길
현재 중심은 reactive다.
사용자 발화 -> Planner -> Task/Answer
다음 단계는 현재 상태와 event 변화량을 proactive 후보로 올리는 것이다.
기기 상태 변화
환경 변화
사용자 반복 패턴
task 실패/중단 이력
정책/안전 gate
-> proactive candidate
-> planner 또는 lightweight decision
-> 제안/확인/자동화
여기서 중요한 점은 proactive가 곧바로 자동 실행을 의미하지 않는다는 것이다. 초기에는 제안과 확인 중심으로 시작하고, 안전한 반복 패턴만 제한적으로 자동화 후보가 된다.
7. 로드맵
| 단계 | 이름 | 목표 | 대표 산출물 |
|---|---|---|---|
| Phase 0 | Concept alignment | A2A 목적, 용어, 발표 흐름 정리 | storyline, glossary, research list |
| Phase 1 | Router baseline | family routing 축과 benchmark baseline 고정 | answer set, full-run result, failure transition |
| Phase 2 | Schedule workflow | schedule slot/multiturn/API mapping 구현 | slot schema, follow-up contract |
| Phase 3 | Task orchestration | 복합명령 runtime과 TaskManager event 연결 | workflow state, task event contract |
| Phase 4 | Vendor/API stabilization | AAR/API boundary와 업체 acceptance 고정 | API checklist, evidence template |
| Phase 5 | Feedback calibration | 사용자 correction/task outcome 기반 offline 개선 | interaction trace, boundary review |
| Phase 6 | Proactive pilot | 변화량 기반 suggestion/confirmation | proactive trigger policy, safety gate |
| Phase 7 | Robotics decision layer | reactive/proactive/task/memory 통합 | robotics brain architecture |
8. 팀별 메시지
| 대상 | 설명해야 할 메시지 |
|---|---|
| 기획 | A2A는 기능 하나가 아니라 복합명령/맥락/실패복구를 가능하게 하는 제품 기반이다. |
| Cloud 개발 | Planner는 route family, step, dependency, replan policy를 책임진다. |
| On-device 개발 | Cloud step을 기기 실행 요청으로 안전하게 변환하고 멀티턴 상태를 유지한다. |
| DeviceAgent/SoC | TaskManager는 execution lifecycle과 event/reason contract를 책임진다. |
| 업체 | Cloud 내부 prompt가 아니라 AAR/API와 event evidence를 맞추면 된다. |
| QA | 단순 성공/실패가 아니라 route decision, task event, reason, replan 여부를 함께 검증한다. |
9. 다음 기획 과제
| 우선순위 | 과제 | 이유 |
|---|---|---|
| P0 | A2A Product PRD 확정 | 팀/업체 설명의 기준점 |
| P0 | Router baseline freeze | 이후 이식/확장 회귀 판단 기준 |
| P1 | Schedule workflow UX spec | slot 질문 순서와 종료 조건 확정 |
| P1 | Vendor-facing TaskManager API 확정 | 구현 전달 전 boundary 고정 |
| P1 | Proactive pilot scope 정의 | reactive와 구분되는 제품 가치 검증 |
| P2 | Feedback learning data schema | 장기 튜닝 자동화 기반 |