A2A Book Roadmap
이 문서는 A2A 작업 자료를 책처럼 읽기 위한 순서를 제공한다. 목적은 작업 로그를 나열하는 것이 아니라, Cloud A2A부터 실제 DeviceAgent TaskManager까지 이어지는 설계 의도를 한 흐름으로 이해하는 것이다.
읽는 순서
| Part | 제목 | 핵심 질문 |
|---|---|---|
| 0 | A2A Presentation Storyline | 팀 전체 서사와 읽는 순서는 무엇인가 |
| 0-1 | A2A Presentation Deck Outline | 팀 발표를 슬라이드 순서로 만들면 어떤 흐름이 되는가 |
| 1 | A2A Product PRD | 제품/플랫폼 관점에서 A2A는 어떤 문제를 풀고 어떤 KPI로 봐야 하는가 |
| 2 | A2A Adoption Benefits and Roadmap | context-aware, planner, catalog, Task Orchestration을 넣으면 무엇이 좋아지는가 |
| 2-1 | A2A Before/After Impact Analysis | 기존 명령 체계 대비 A2A가 무엇을 고도화하고 어떤 효과를 만드는가 |
| 3 | A2A Executive Summary | 현재 결론, 남은 리스크, 다음 액션은 무엇인가 |
| 4 | System Overview | 전체 시스템은 어떤 레이어로 나뉘는가 |
| 5 | Speech-LLM Context-Aware A2A Architecture | Speech/STT, context, planner, agent/skill, 복합제어가 어떻게 하나의 loop로 연결되는가 |
| 6 | Planner and Routing | Planner는 route family와 multi-step을 어떻게 판단하는가 |
| 6-1 | A2A Planner Deep Dive | 실제 소스 기준 preclassifier, object typer, second pass, task orchestration은 어떻게 이어지는가 |
| 6-2 | Semantic Boundary Calibration Playbook | DEF/STT_NULL, ODL/SCH, DQR/FRG 같은 의미 경계를 어떻게 조정하는가 |
| 6-3 | A2A Router Axis Tuning Roadmap | 테스트셋 확정, 오분류 transition 분석, cue/prompt/system 반영, full-run/holdout 검증을 어떤 cycle로 돌리는가 |
| 6-4 | A2A Planner Cleanup Backlog | planner 계약 drift와 남은 정리 과제를 어떤 순서로 닫을 것인가 |
| 7 | Schedule Milestone PRD and UX Spec | 고정청정 스케줄 1차 마일스톤은 어떤 UX/slot/API 기준으로 닫을 것인가 |
| 8 | Contract Matrix | Cloud, 온디바이스, DeviceAgent 사이에 어떤 payload가 오가는가 |
| 9 | Device Task Flow | 복합명령이 실제 task queue로 어떻게 내려가는가 |
| 9-1 | DeviceAgent TaskManager 기준 사양서 | DeviceAgent TaskManager가 source, queue, workflow, event, reason을 어떻게 처리하는가 |
| 9-1-1 | TaskManager Device Context Planning Spec | TaskManager, 스케줄링, device context를 planner가 쓰면 제품적으로 무엇이 가능해지는가 |
| 9-2 | Cloud·On-device·TaskManager Closed Loop | feature 브랜치의 TaskManager runtime을 최신 Planner 축에 안전하게 이식하려면 어떤 순서와 보호 구역이 필요한가 |
| 9-3 | Experience Goal: 명령 수행에서 결과 위임으로 | Planner와 TaskManager 다음에 왜 목표 연속성 계층이 필요하며 AS-IS/TO-BE가 무엇인가 |
| 9-4 | Experience Goal과 기존 Planner 통합 | 기존 owner, plan, TaskManager 권위를 유지하면서 Goal sidecar를 어떻게 결속하는가 |
| 9-5 | Experience Goal Usability Playbook | 결과 위임이 사용자 부담, 신뢰, 복구성에 어떤 효과를 주는가 |
| 9-6 | Experience Runtime Validation Closure | 현재 callback backbone과 실패 UX는 어디까지 닫혔고 무엇이 아직 No-Go인가 |
| 10 | Scenario Walkthroughs | 실제 발화는 단계별로 어떤 데이터로 바뀌는가 |
| 11 | Memory and Personalization | 이전 맥락과 개인화는 어떻게 붙일 것인가 |
| 12 | Memory DB and Sync Contract | 메모리 DB schema, sync cursor, 삭제 정책은 무엇인가 |
| 12-1 | A2A RL-Like Feedback Improvement Opportunities | planner/event/memory feedback을 서비스 개선 루프로 만들 수 있는가 |
| 13 | 19.comToMe A2A Workflow Example | ComeToMe 기능을 A2A/TaskManager workflow로 보면 어떤 데이터가 흐르는가 |
| 14 | 19.comToMe DeviceAgent Contract | ComeToMe를 업체 구현 계약으로 바꾸면 어떤 API/event/reason이 필요한가 |
| 15 | DeviceAgent TaskManager API Contract | DeviceAgent 업체가 맞춰야 할 API와 event payload는 무엇인가 |
| 16 | DeviceAgent TaskManager 기준 사양서 | TaskManager를 SoC 실행 오케스트레이션 기능 범주로 보면 무엇인가 |
| 17 | DeviceAgent / SoC Domain Map | TaskManager 뒤의 moving/cleaning/map/schedule 도메인은 어떻게 연결되는가 |
| 18 | A2A Vendor One-Pager | 업체에 한 장으로 설명할 책임 경계와 제출 evidence는 무엇인가 |
| 19 | Vendor Handoff | SoC/DeviceAgent 업체에는 무엇을 요구해야 하는가 |
| 20 | DeviceAgent Vendor Implementation Package | 업체가 어떤 패키지를 구현/제출해야 하는가 |
| 21 | Vendor API Acceptance Checklist | API별 PASS 기준은 무엇인가 |
| 22 | Vendor Test Evidence Template | 업체가 어떤 테스트 증거를 제출해야 하는가 |
| 23 | Vendor Open Questions | 구현 전에 닫아야 할 질문은 무엇인가 |
| 24 | Source Map | 구현은 어느 repo/파일에 있는가 |
| 25 | A2A Evidence Index | 각 장의 설계/소스/검증 근거는 어디에 있는가 |
| 26 | Requirements Traceability Matrix | 요구사항, 설계, 구현, 테스트가 서로 맞는가 |
| 27 | A2A Success Criteria | A2A가 성공했다고 말하려면 어떤 gate를 통과해야 하는가 |
| 28 | Validation Guide | 무엇이 검증됐고 무엇이 ADB/실기기에서 남았는가 |
| 29 | Status and Gap Audit | 현재 완료/미완료/검증 공백은 무엇인가 |
| 30 | A2A Next Action Board | 지금 다음으로 무엇을 해야 하는가 |
| 31 | Benchmark and Router Evolution | 라우터 성능 개선은 어떤 기준으로 봐야 하는가 |
| 32 | Work Breakdown | Cloud, 온디바이스, DeviceAgent 담당자는 무엇을 해야 하는가 |
| 33 | A2A Role-Based Reader Paths | 내 역할에서는 어떤 장부터 봐야 하는가 |
| 34 | Visual Map | 전체 데이터/이벤트 흐름을 한 장으로 어떻게 볼 수 있는가 |
| 35 | Architecture Diagrams | 항목별 구조도를 어디서 한 번에 볼 수 있는가 |
| 36 | A2A Glossary and Concept Index | 반복되는 용어를 어디서 한 번에 확인하는가 |
| 37 | Documentation Quality Audit | 이 위키가 얼마나 충분히 구조화되었고 어디가 남았는가 |
| Appendix A | Local Access Guide | 브라우저에서 어디로 접속하고 서버가 안 열릴 때 어떻게 확인하는가 |
| Appendix B | A2A Global Wiki Operations | 여러 Codex 창에서 위키를 어떻게 공유/갱신하는가 |
전체 구조 한 줄
Cloud는 “무엇을 어떤 순서로 할지” 계획하고, 온디바이스와 DeviceAgent는 “기기에서 어떻게 안전하게 실행할지” 책임진다.
왜 이 순서인가
발표에서는 Presentation Storyline으로 전체 목적을 먼저 잡고 들어간다. Planner부터 보면 개별 prompt와 route family에 빠지기 쉽다. 먼저 전체 레이어와 책임 분리를 잡고, Planner/Routing에서 개념을 확인한 뒤, Planner Deep Dive에서 실제 소스 기준 판단 레이어를 본다. 그 다음 계약과 실행 흐름을 보면 왜 device_task_requests, device_intent_step, task_event, requires_cloud_decision이 필요한지 자연스럽게 연결된다.
가장 중요한 판단
- 정상 task 진행마다 Cloud LLM을 다시 돌리지 않는다.
- Cloud replan은 실패, 차단, 일시중단, 사용자 결정 필요 같은 이벤트에만 제한한다.
- 물리적 순서는
depends_on과wait_policy로 표현한다. - step 결과를 다음 step이 의미적으로 써야 하면
input_from으로 표현한다. token_text는 Planner가 임의 생성하지 않고, catalog/contract에서 안전하게 제공된 경우에만 사용한다.
원본 지식 페이지
상세 원문은 아래 위치에 있다.
wiki/concepts/A2A Book Roadmap.md
wiki/concepts/A2A Table of Contents.md
wiki/concepts/A2A Reader Guide.md
wiki/concepts/A2A Glossary.md