A2A Book Roadmap
이 문서는 A2A 작업 자료를 책처럼 읽기 위한 순서를 제공한다. 목적은 작업 로그를 나열하는 것이 아니라, Cloud A2A부터 실제 DeviceAgent TaskManager까지 이어지는 설계 의도를 한 흐름으로 이해하는 것이다.
읽는 순서
| Part | 제목 | 핵심 질문 |
|---|---|---|
| 1 | A2A Executive Summary | 현재 결론, 남은 리스크, 다음 액션은 무엇인가 |
| 2 | System Overview | 전체 시스템은 어떤 레이어로 나뉘는가 |
| 3 | Local Access Guide | 브라우저에서 어디로 접속하고 서버가 안 열릴 때 어떻게 확인하는가 |
| 4 | A2A Global Wiki Operations | 여러 Codex 창에서 위키를 어떻게 공유/갱신하는가 |
| 5 | A2A Role-Based Reader Paths | 내 역할에서는 어떤 장부터 봐야 하는가 |
| 6 | Visual Map | 전체 데이터/이벤트 흐름을 한 장으로 어떻게 볼 수 있는가 |
| 7 | A2A Glossary and Concept Index | 반복되는 용어를 어디서 한 번에 확인하는가 |
| 8 | Architecture Diagrams | 항목별 구조도를 어디서 한 번에 볼 수 있는가 |
| 9 | Speech-LLM Context-Aware A2A Architecture | Speech/STT, context, planner, agent/skill, 복합제어가 어떻게 하나의 loop로 연결되는가 |
| 10 | Planner and Routing | Planner는 route family와 multi-step을 어떻게 판단하는가 |
| 11 | Contract Matrix | Cloud, 온디바이스, DeviceAgent 사이에 어떤 payload가 오가는가 |
| 12 | Device Task Flow | 복합명령이 실제 task queue로 어떻게 내려가는가 |
| 13 | Scenario Walkthroughs | 실제 발화는 단계별로 어떤 데이터로 바뀌는가 |
| 14 | 19.comToMe A2A Workflow Example | ComeToMe 기능을 A2A/TaskManager workflow로 보면 어떤 데이터가 흐르는가 |
| 15 | 19.comToMe DeviceAgent Contract | ComeToMe를 업체 구현 계약으로 바꾸면 어떤 API/event/reason이 필요한가 |
| 16 | Source Map | 구현은 어느 repo/파일에 있는가 |
| 17 | A2A Evidence Index | 각 장의 설계/소스/검증 근거는 어디에 있는가 |
| 18 | Requirements Traceability Matrix | 요구사항, 설계, 구현, 테스트가 서로 맞는가 |
| 19 | A2A Next Action Board | 지금 다음으로 무엇을 해야 하는가 |
| 20 | Validation Guide | 무엇이 검증됐고 무엇이 ADB/실기기에서 남았는가 |
| 21 | Vendor Handoff | SoC/DeviceAgent 업체에는 무엇을 요구해야 하는가 |
| 22 | DeviceAgent Vendor Implementation Package | 업체가 어떤 패키지를 구현/제출해야 하는가 |
| 23 | DeviceAgent TaskManager API Contract | DeviceAgent 업체가 맞춰야 할 API와 event payload는 무엇인가 |
| 24 | SoC TaskManager Execution Subsystem | TaskManager를 SoC 실행 오케스트레이션 기능 범주로 보면 무엇인가 |
| 25 | DeviceAgent / SoC Domain Map | TaskManager 뒤의 moving/cleaning/map/schedule 도메인은 어떻게 연결되는가 |
| 26 | Vendor API Acceptance Checklist | API별 PASS 기준은 무엇인가 |
| 27 | Vendor Test Evidence Template | 업체가 어떤 테스트 증거를 제출해야 하는가 |
| 28 | Vendor Open Questions | 구현 전에 닫아야 할 질문은 무엇인가 |
| 29 | Status and Gap Audit | 현재 완료/미완료/검증 공백은 무엇인가 |
| 30 | Documentation Quality Audit | 이 위키가 얼마나 충분히 구조화되었고 어디가 남았는가 |
| 31 | Work Breakdown | Cloud, 온디바이스, DeviceAgent 담당자는 무엇을 해야 하는가 |
| 32 | Memory and Personalization | 이전 맥락과 개인화는 어떻게 붙일 것인가 |
| 33 | Memory DB and Sync Contract | 메모리 DB schema, sync cursor, 삭제 정책은 무엇인가 |
| 34 | Benchmark and Router Evolution | 라우터 성능 개선은 어떤 기준으로 봐야 하는가 |
전체 구조 한 줄
Cloud는 “무엇을 어떤 순서로 할지” 계획하고, 온디바이스와 DeviceAgent는 “기기에서 어떻게 안전하게 실행할지” 책임진다.
왜 이 순서인가
Planner부터 보면 개별 prompt와 route family에 빠지기 쉽다. 먼저 전체 레이어와 책임 분리를 잡고, 그 다음 계약과 실행 흐름을 보면 왜 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