A2A Product PRD
이 그림은 A2A를 제품 관점에서 볼 때 사용자 입력, Cloud Planner, catalog grounding, On-device Bridge, DeviceAgent TaskManager, feedback calibration이 하나의 가치 루프를 이룬다는 점을 보여준다.
1. 배경과 목표
SK-Intellix A2A의 목표는 단순 음성 명령 분류기를 만드는 것이 아니다. 사용자 발화, 대화 맥락, 현재 기기 상태, 기능 catalog, 실행 결과 event를 함께 해석해 “무엇을 어떤 순서로 실행할지” 결정하는 의사결정 계층을 만드는 것이다.
기존 구조는 단일 명령 처리에는 빠르지만 아래 요구에 약하다.
- 발화가 깨졌지만 의미가 복구 가능한 경우
- 사용자 의도가 여러 단계로 나뉘는 복합명령
- 스케줄처럼 slot을 여러 턴에 걸쳐 채워야 하는 workflow
- 현재 기기 상태에 따라 실행 가능 여부가 달라지는 명령
- 실행 중 실패, 차단, 취소, 사용자 확인이 필요한 상황
- reactive 음성명령과 proactive event 판단을 같은 구조로 다뤄야 하는 상황
A2A는 이 문제를 Planner, Agent/Skill Catalog, Task Orchestration, Memory/Context, TaskManager Event Feedback으로 분리해서 해결한다.
2. KPI
| KPI | 의미 | 측정 방식 |
|---|---|---|
| Family routing accuracy | 발화를 올바른 route family로 보냈는가 | benchmark full-run, holdout set |
| Over-execution reduction | 깨진 STT를 기기 실행으로 과해석하지 않았는가 | STT_NULL -> ODL, DEF -> ODL 실패율 |
| Conversation recovery | 즉답 가능한 짧은 대화를 끊지 않았는가 | DEF -> STT_NULL 실패율 |
| Workflow completion | 멀티턴 slot을 끝까지 채우고 실행까지 갔는가 | schedule/task workflow E2E |
| Replan precision | 정상 event는 로컬 처리하고 판단 필요 event만 Cloud에 올렸는가 | requires_cloud_decision event audit |
| Integration stability | 기존 MainApi/DeviceAgent 기능을 우회하지 않았는가 | legacy command regression, TaskManager adapter test |
3. 사용자 및 시나리오
3.1 일반 사용자
사용자는 정확한 command syntax를 외우지 않고 자연스럽게 말한다.
거실로 가서 공기 상태 보고 안 좋으면 청정해줘
기대 동작:
- Planner가 이동, 상태 확인, 조건부 청정으로 step을 나눈다.
- On-device bridge는 step을 순서대로 DeviceAgent에 넘긴다.
- DeviceAgent TaskManager는 실행 상태와 실패 reason을 관리한다.
- 정상 진행 중에는 Cloud LLM을 매번 다시 호출하지 않는다.
3.2 스케줄 사용자
사용자는 한 번에 모든 slot을 말하지 않을 수 있다.
사용자: 안방 공기청정 예약해줘
시스템: 언제부터 언제까지 할까요?
사용자: 밤 10시부터 아침 7시까지
시스템: 매일 반복할까요?
사용자: 평일만
기대 동작:
- schedule workflow가 active state를 유지한다.
- 후속 발화는 새 intent가 아니라 missing slot answer로 해석된다.
- 필수 slot이 채워지면 schedule API payload를 만든다.
3.3 운영/업체 담당자
업체는 Cloud Planner 내부를 몰라도 된다. 대신 TaskManager와 AAR/API contract를 구현하고, event/reason contract를 맞추면 된다.
기대 동작:
submitTask,submitWorkflow,cancelTask,getTaskStatus같은 외부 boundary가 안정적이다.- 실패는 자연어가 아니라
reason_code,reason_params,recoverability,suggested_action,requires_cloud_decision으로 올라온다. - 업체 테스트 증거는 API fixture와 event trace로 제출한다.
4. 기능 범위
Must
| 기능 | 설명 | 완료 기준 |
|---|---|---|
| Context-aware routing | 발화, 대화 상태, workflow 상태, 기기 상태를 함께 해석 | route decision metadata에 context/evidence 포함 |
| Semantic boundary calibration | DEF/STT_NULL, ODL/SCH, DQR/FRG 같은 경계를 의미축으로 관리 |
benchmark와 실패군 분석 문서화 |
| Agent/Skill catalog grounding | Planner가 가능한 agent/skill 후보 안에서 계획 | catalog 기반 candidate pool 생성 |
| Multi-step planning | 복합명령을 ordered step과 dependency로 표현 | steps, depends_on, input_from, output_key 검증 |
| Schedule multi-turn workflow | slot 누락 시 follow-up 후 state 유지 | fixed cleaning schedule 생성 E2E |
| TaskManager event contract | 실행 상태와 실패 reason을 구조화 | event/reason payload 검증 |
Should
| 기능 | 설명 | 이유 |
|---|---|---|
| Benchmark baseline management | 정답지, prompt snapshot, result artifact를 함께 관리 | 튜닝 회귀 방지 |
| Follow-up strategy standardization | clarification, slot 질문, confirmation을 route action으로 정리 | UX 일관성 |
| External decision boundary | Cloud 외 MCP/MQTT/App도 TaskManager를 쓸 수 있게 boundary 일반화 | framework화 |
| Vendor acceptance package | 업체 구현/제출 기준 문서화 | 협업 리스크 감소 |
Could
| 기능 | 설명 |
|---|---|
| Proactive signal gate | 센서/event 변화량을 proactive 후보로 올리는 gate |
| Feedback learning loop | 사용자 correction과 task outcome을 offline calibration에 반영 |
| Policy dashboard | family별 실패축, event reason, replan rate 모니터링 |
5. 사용자 스토리와 수용 기준
| 사용자 스토리 | 수용 기준 |
|---|---|
| 사용자는 복합명령을 한 문장으로 말할 수 있다. | Planner output에 2개 이상 step과 dependency가 생성된다. |
| 사용자는 slot을 한 번에 말하지 않아도 된다. | system이 missing slot만 좁게 질문하고 active workflow를 유지한다. |
| 사용자는 깨진 발화를 해도 복구 가능한 경우 응답을 받는다. | minor STT corruption은 STT_NULL_HARD로 닫히지 않는다. |
| 사용자는 의미 없는 소음에는 안전한 재질문을 받는다. | no dominant interpretation은 device execution으로 승격되지 않는다. |
| 업체는 Cloud 내부 구현과 분리된 API를 구현한다. | AAR/API contract와 event fixture가 통과한다. |
6. 비범위 항목
- 모든 발화를 rule table로 직접 매핑하지 않는다.
- 정상 task progress마다 Cloud LLM을 다시 호출하지 않는다.
- TaskManager가 Planner의 의미 판단을 대신하지 않는다.
- 현재 문서 단계에서 proactive 자동 실행을 제품 기능으로 확정하지 않는다.
- 외부 업체가 Cloud Planner prompt 내부를 구현하도록 요구하지 않는다.
7. 리스크와 대응
| 리스크 | 영향 | 대응 |
|---|---|---|
| cue가 rule처럼 과하게 늘어남 | 특정 test set에는 맞지만 holdout에서 흔들림 | cue는 semantic axis evidence로만 사용하고 benchmark/holdout 동시 확인 |
| Planner와 TaskManager 책임 혼합 | 문서/구현 경계 불명확 | Cloud는 plan/replan, TaskManager는 execution lifecycle로 분리 |
| 정답지 정책 drift | 성능 수치 비교 불가 | 정답지 version, 변경 reason, result artifact를 함께 보관 |
| direct merge 충돌 | 최신 축 조정 손실 | porting plan의 keep-base 보호 구역 준수 |
| 업체 구현 해석 차이 | event/reason contract 불일치 | API acceptance checklist와 test evidence template 사용 |
8. 릴리스 마일스톤
| 단계 | 목표 | 산출물 |
|---|---|---|
| M0 | A2A 개념과 발표 흐름 정리 | storyline, roadmap, research map |
| M1 | Router axis baseline 고정 | benchmark result, failure analysis, prompt snapshot |
| M2 | Schedule multi-turn 설계 확정 | slot schema, follow-up contract, schedule API mapping |
| M3 | Task Orchestration runtime 이식 | runtime modules, workflow state, tests |
| M4 | On-device/DeviceAgent E2E | task event trace, reason_code, requires_cloud_decision |
| M5 | Proactive 확장 검토 | signal gate, policy threshold, user confirmation UX |