A2A Presentation Deck Outline
이 문서는 팀 발표용 슬라이드 순서다. 위키 문서 전체를 그대로 읽는 것이 아니라, 청중이 “왜 필요한가 -> 무엇을 만들었나 -> 무엇이 좋아졌나 -> 다음에 무엇을 해야 하나”를 따라오도록 재구성한다.
1. 발표 목표
발표의 목표는 A2A를 기능 하나가 아니라 SK-Intellix의 의사결정 제어 계층으로 설명하는 것이다.
기존 단일 명령 처리
-> context-aware planner
-> agent/skill catalog
-> TaskManager runtime
-> reactive/proactive 통합 방향
2. 권장 슬라이드 흐름
| Slide | 제목 | 핵심 메시지 | 열 문서 |
|---|---|---|---|
| 1 | 한 줄 메시지 | A2A는 음성 라우터가 아니라 로보틱스 의사결정 계층이다. | A2A Product PRD |
| 2 | 기존 구조의 한계 | 단일 command 구조는 맥락, 복합명령, 실패 복구에 약하다. | A2A Presentation Storyline |
| 3 | 제품 목표 | 사용자는 자연어로 목표를 말하고 시스템은 plan/task로 바꾼다. | A2A Adoption Benefits and Roadmap |
| 4 | 전체 아키텍처 | Speech/STT, Planner, Agent/Skill, Bridge, TaskManager가 loop로 연결된다. | System Overview |
| 5 | Planner의 역할 | Planner는 selector가 아니라 owner/skill/step/dependency를 만든다. | A2A Planner Deep Dive |
| 6 | 판단축과 evidence | preclassifier는 정답을 고르지 않고 LLM이 볼 evidence 축을 만든다. | Semantic Boundary Calibration Playbook |
| 7 | Schedule 1차 마일스톤 | 고정청정 스케줄을 slot filling/multiturn/API 호출의 첫 검증 대상으로 둔다. | Schedule Milestone PRD and UX Spec |
| 8 | TaskManager 통합 | 기존 명령을 버리지 않고 task/workflow/event/reason 계층으로 감싼다. | DeviceAgent TaskManager 기준 사양서 |
| 9 | 업체 협업 경계 | 업체는 Cloud prompt가 아니라 TaskManager API와 event evidence를 맞추면 된다. | A2A Vendor One-Pager |
| 10 | 성공 기준 | routing, workflow, event, 실기기 evidence로 성공을 판단한다. | A2A Success Criteria |
| 11 | 미래 방향 | proactive는 signal/event가 planner 입력으로 들어오는 확장이다. | Reactive and Proactive Operation |
| 12 | 요청사항 | benchmark baseline, schedule spec, vendor API, E2E evidence를 닫아야 한다. | A2A Next Action Board |
3. 발표할 때 강조할 문장
| 구간 | 말할 문장 |
|---|---|
| 시작 | “우리가 만드는 것은 발화 분류기가 아니라, 목표를 이해하고 실행 가능한 step으로 나누는 planner입니다.” |
| Planner | “LLM이 마음대로 판단하는 구조가 아니라, catalog와 cue evidence로 가능한 선택지를 제한합니다.” |
| 축 조정 | “축 조정은 row별 rule 추가가 아니라, 의미 경계를 조정하는 calibration입니다.” |
| TaskManager | “Cloud는 무엇을 할지 계획하고, DeviceAgent는 어떻게 안전하게 실행할지 책임집니다.” |
| Proactive | “미래 방향은 변화량 context를 이용해 사용자가 말하기 전에도 제안할 수 있는 구조입니다.” |
4. 발표 후 받을 질문과 답변
| 질문 | 답변 방향 |
|---|---|
| 왜 LLM이 꼭 필요한가 | 단일 intent matching이 아니라 context, slot, dependency, failure replan을 함께 판단해야 하기 때문이다. |
| 룰베이스와 뭐가 다른가 | cue는 family를 강제하지 않고 LLM 판단을 위한 evidence axis로 사용된다. |
| 비용이 커지지 않나 | 정상 task progress마다 Cloud LLM을 돌리지 않고 decision event에서만 replan한다. |
| 업체는 뭘 구현해야 하나 | TaskManager API, event/reason contract, evidence fixture를 구현하면 된다. |
| 1차 기능은 무엇인가 | 고정청정 스케줄 생성이며, 이후 다른 schedule 기능은 slot registry와 adapter로 확장한다. |
5. 발표 자료로 만들 때 필요한 추가 산출물
- 슬라이드용 1페이지 시스템 구조도
- Schedule slot filling 예시 대화
- Router axis before/after 표
- TaskManager event/reason 예시
- 업체 요청사항 checklist