A2A Glossary and Concept Index

이 문서는 A2A Wiki를 읽을 때 반복해서 등장하는 용어를 한 곳에 모은 색인이다.

목적:

Cloud, 온디바이스, DeviceAgent/SoC, QA, 업체가 같은 단어를 같은 의미로 쓰게 한다.
문서마다 흩어진 개념을 빠르게 찾아가게 한다.
“Planner”, “TaskManager”, “workflow”, “event”, “memory” 같은 단어가 섞여 오해되는 것을 줄인다.

A2A Glossary and Concept Index

1. 가장 먼저 알아야 할 12개 용어

용어	한 줄 정의	먼저 볼 문서
A2A	Cloud Planner가 여러 agent/device step을 계획하고 실행 계층에 넘기는 구조	System Overview
Planner	사용자 발화를 route family와 step plan으로 바꾸는 Cloud LLM 계층	Planner and Routing
Route Family	ODL, DEF, FRG, SCH, DQR, UNS, STT_NULL 같은 상위 라우팅 범주	Planner and Routing
Step Plan	Planner가 만든 실행 단계 목록. `depends_on`, `input_from`, `output_key`를 가질 수 있다	Scenario Walkthroughs
`device_task_requests`	Cloud Runtime이 온디바이스로 보내는 device 실행 요청 목록	Device Task Flow
On-device Bridge	Cloud 응답을 받아 DeviceAgent 호출 또는 로컬 token/task 실행으로 변환하는 계층	Source Map
DeviceAgent	실제 기기 상태와 실행 API를 가진 SoC 쪽 앱/서비스 영역	DeviceAgent / SoC Domain Map
TaskManager	DeviceAgent 안에서 task/workflow queue, event, reason, context를 관리하는 실행 서브시스템	SoC TaskManager Execution Subsystem
Domain Manager	`moving`, `cleaning`, `map`, `schedule`처럼 실제 조건 판단과 실행 권한을 가진 DeviceAgent 내부 도메인	DeviceAgent / SoC Domain Map
`reason_code`	실패/차단 사유를 Cloud가 정책적으로 판단할 수 있게 구조화한 code	Contract Matrix
`requires_cloud_decision`	Cloud replan/사용자 확인이 필요한 event인지 표시하는 boolean	Validation Guide
Device Context	Cloud plan 전에 읽는 최소 기기 상태 snapshot	Memory DB and Sync Contract, SoC TaskManager Execution Subsystem

2. Cloud A2A 용어

용어	의미	혼동 방지
`turn_mode`	한 사용자 발화를 `singleton`, `multi_turn`, `parallel` 중 어느 형태로 처리할지 나타낸다	device workflow의 long-running 여부와는 다르다
`singleton`	한 번의 응답/실행으로 끝나는 turn	내부 step이 하나라는 뜻은 아니다
`multi_turn`	슬롯 부족, 확인 필요, 진행 중 workflow 등 다음 사용자 turn이 필요할 수 있는 구조	DeviceAgent의 `submitWorkflow`와 이름은 비슷하지만 계층이 다르다
`parallel`	서로 독립적인 intent를 병렬로 처리할 수 있는 turn	물리적 순서가 필요한 복합명령에는 쓰지 않는다
`selected_routes`	Planner가 고른 route family 목록	실제 실행 method 목록이 아니다
`steps`	실행 또는 판단 단계 목록	각 step은 Cloud agent일 수도 있고 device intent일 수도 있다
`depends_on`	실행 순서 또는 unlock 관계	결과 데이터를 의미적으로 쓴다는 뜻은 아니다
`input_from`	이전 step 결과를 다음 step 입력으로 사용한다는 의미	단순 순서 제어보다 강한 데이터 의존성이다
`output_key`	다음 step이나 event trace가 참조할 결과 이름	callback에서 유실되면 replan이 어려워진다
`execution_target`	step이 Cloud에서 처리되는지 device로 내려가는지 구분	route family만으로 target이 확정되지는 않는다

3. Route Family 용어

Family	의미	대표 예
`ODL`	로컬 기기 실행 또는 현재 기기 상태 조회	“거실로 가”, “청정 시작해”, “배터리 얼마야”
`SCH`	알람/타이머/스케줄/예약/루틴 관리	“내일 7시에 청정 예약해줘”
`DQR`	기기/제품/기능 설명, 사용법, 문제해결	“이 기능이 뭐야”, “필터는 어떻게 갈아”
`FRG`	외부/public 정보 조회, 추천, 최신 정보	“근처 병원 찾아줘”, “오늘 날씨 알려줘”
`DEF`	일반 대화, wording, 감정/반응, 가벼운 도움	“고마워”, “문장 좀 바꿔줘”
`UNS`	사용자가 실행을 원하지만 지원하지 않는 기능	“유튜브 틀어줘” 같은 미지원 실행
`STT_NULL`	의미가 무너졌거나 target이 없어 전체 의도 복구가 필요한 STT	깨진 조각, 목적 없는 잔여 발화
`STM`	story mode 진입	명시적 이야기 모드 시작
`ETR`	English tutor mode 진입	명시적 영어 튜터 시작

4. Device 실행 용어

용어	의미	중요한 판단
Device Intent Step	Cloud plan 중 실제 기기로 내려가야 하는 step	Runtime에서 `device_task_requests`로 변환된다
Token	온디바이스/DeviceAgent가 기존 음성 명령처럼 소비할 수 있는 짧은 명령 표현	Planner가 임의 생성하면 안 되고 catalog/contract 기반이어야 한다
ComeToMe	`"나에게와"`/`"거실로와"` 계열 이동/추종 기능	DoA, Vision, AMR, FollowMe가 결합된 장기 device workflow다
`comeToMe`	ComeToMe를 DeviceAgent TaskManager에 등록할 때의 예시 task method	실제 구현명은 DeviceAgent 계약에서 확정해야 한다
`submitTask`	DeviceAgent TaskManager에 단일 task를 등록한다	long-running이면 event callback이 중요하다
`submitWorkflow`	여러 subtask를 하나의 workflow로 등록한다	순차성, 실패 step, parent 상태가 중요하다
`subTasks`	DeviceAgent workflow 안의 실제 실행 단위 목록	Cloud `steps`와 1:1일 수도 있고 변환될 수도 있다
`taskMethod`	DeviceAgent가 실행할 method 이름	실제 domain executor 또는 legacy 경로와 연결되어야 한다
`TaskExecutorRegistry`	`taskMethod -> executor` 바인딩	기존 안전 경로를 우회하지 않게 연결해야 한다
Domain Executor	task method를 특정 DeviceAgent 도메인으로 넘기는 실행 adapter	skeleton executor만으로 제품 실행 완료가 아니다

5. Event / Replan 용어

용어	의미	Cloud 동작
`QUEUED`	task가 queue에 들어감	보통 replan 없음
`STARTED` / `RUNNING`	task 실행 시작/진행 중	보통 replan 없음
`PROGRESS`	진행률/stage/message 갱신	보통 replan 없음
`COMPLETED`	단일 task 완료	다음 local step unlock
`WORKFLOW_STEP_COMPLETED`	workflow 안의 특정 step 완료	다음 subtask unlock
`WORKFLOW_COMPLETED`	parent workflow 전체 완료	workflow 종료 기록
`FAILED`	task 실패	reason에 따라 replan
`BLOCKED`	물리/상태 조건으로 막힘	대개 replan 또는 사용자 확인
`PAUSED`	일시정지	원인에 따라 로컬 resume 또는 Cloud 판단
`CANCELLED`	사용자/시스템 취소	workflow 정리
`reason_params`	reason code를 설명하는 구조화 parameter	target room, failed method 등
`suggested_action`	DeviceAgent가 제안하는 다음 조치	`REPLAN`, `RETRY_OR_WAIT`, `ASK_USER_TARGET` 등

6. Memory / Personalization 용어

용어	의미	사용 위치
Conversation Pair	`user -> assistant` 한 쌍의 최소 대화 단위	memory DB의 가장 작은 저장 단위
Session	여러 pair가 묶인 단기 대화 묶음. 현재 기준 최대 8 pair가 논의됨	short-term memory
Short-term Memory	하루 정도 유지되는 최근 대화/세션 기록	현재 workflow와 직전 맥락
Mid-term Memory	약 1주 단위 요약/반복 맥락	반복 작업, 최근 선호
Long-term Memory	사용자의 안정적 특성/선호/기기 프로필	명시 동의 또는 반복 증거 필요
Summary Compression	session/day/week 기록을 요약해 다음 계층으로 올리는 작업	token 비용과 privacy 관리
Sync Cursor	온디바이스와 Cloud 간 memory 동기화 위치	중복/누락 방지

7. 업체/QA 용어

용어	의미
Acceptance Checklist	업체 구현물을 받을 때 API별 PASS 기준
Evidence Template	업체가 제출해야 할 logcat, fixture, test 결과 양식
Fixture	재현 가능한 입력/출력 샘플
Artifact Validator	logcat/JSON 결과에서 trace field와 event 증거를 검사하는 도구
Open Question	구현 전에 확정해야 하는 미결정 계약
Source Map	설명과 실제 repo/file/function을 연결한 지도
Traceability Matrix	요구사항, 설계, 구현, 검증 증거를 연결한 표

8. 자주 생기는 오해

오해	올바른 이해
Planner가 task를 직접 실행한다	Planner는 plan을 만들고, 실행은 Runtime/Bridge/DeviceAgent가 한다
`depends_on`만 있으면 이전 결과를 쓴다	결과 데이터를 쓰려면 `input_from`/`output_key`가 필요하다
`COMPLETED`가 오면 Cloud가 다시 판단해야 한다	정상 완료는 로컬 workflow 진행에 사용하고 Cloud replan은 보통 열지 않는다
ComeToMe 내부 단계를 Cloud가 매번 LLM으로 판단하면 된다	Cloud는 `comeToMe` 의도와 slot을 정리하고, DoA/Vision/AMR/FollowMe lifecycle은 DeviceAgent TaskManager가 관리해야 한다
TaskManager가 domain 조건을 대신 판단하면 된다	TaskManager는 queue/lifecycle 계층이고 실제 조건은 domain manager가 유지해야 한다
Device Context가 있으면 실행 가능성이 완전히 확정된다	plan 전 snapshot일 뿐이며 실행 직전 상태가 우선이다
자연어 실패 사유만 있으면 충분하다	Cloud replan에는 `reason_code`와 `reason_params`가 필요하다

9. 읽는 순서

처음 보는 사람은 아래 순서로 읽으면 된다.