← Docs hub

A2A Before/After Impact Analysis

이 문서는 A2A 도입 전후의 차이를 기획/개발/업체/QA가 같은 언어로 설명하기 위한 분석 자료다. 핵심은 “명령을 하나 골라 실행하는 구조”에서 “맥락을 해석하고, 목표를 계획하고, 실행 계층에 안전하게 위임하는 구조”로 이동했다는 점이다.

1. 한 줄 결론

A2A는 단순 라우터 교체가 아니다. 기존 command selector를 context-aware decision control layer로 끌어올리는 변화다.

기존:
  발화 -> command/intent 선택 -> 직접 실행

A2A 이후:
  발화 + 대화맥락 + 기기상태 + catalog + 실행 event
  -> route family
  -> agent/skill 후보
  -> step plan
  -> TaskManager 실행
  -> event 기반 완료/재계획

2. Before/After 요약

3. 제품 관점 효과

3.1 사용자는 “기능명”보다 “목표”를 말할 수 있다

기존 구조에서는 사용자가 제품이 아는 명령어에 맞춰 말해야 했다. A2A에서는 사용자의 목표를 먼저 해석하고, 그 목표를 수행 가능한 agent/skill/step으로 변환한다.

예시:

사용자: 안방은 밤에만 조용하게 청정해줘

기존 관점:
  청정, 조용, 밤, 안방 중 어떤 command인지 직접 고르기 어려움

A2A 관점:
  goal: 안방 공기청정 스케줄 생성
  missing slot: 시작/종료 시간 또는 기본 야간 시간 확인
  step:
    1. schedule slot 수집
    2. 고정청정 payload 생성
    3. schedule API 호출

효과는 사용자가 “정확한 기능명”을 몰라도 목표 중심으로 말할 수 있다는 점이다.

3.2 실패가 “끝”이 아니라 “복구 지점”이 된다

기존에는 실행 실패가 곧 사용자에게 실패 응답으로 끝나는 경우가 많다. A2A에서는 실패 event를 구조화해서 재질문, 대체 step, 재계획 여부를 판단할 수 있다.

TaskManager event:
  status: BLOCKED
  reason_code: DOCK_NOT_VISIBLE
  recoverability: user_input_required
  requires_cloud_decision: true

Cloud replan:
  "스테이션을 찾기 어려워요. 현재 위치에서 다시 탐색할까요?"

효과는 사용자가 다시 처음부터 말하지 않아도 되고, 시스템은 실패 원인을 다음 행동으로 연결할 수 있다는 점이다.

3.3 멀티턴 UX가 제품 기능이 된다

스케줄, 예약, 설정, 복합명령은 한 문장으로 끝나지 않는 경우가 많다. A2A는 active workflow와 missing slot을 유지하므로, 사용자의 다음 발화를 같은 목표의 slot answer로 해석할 수 있다.

사용자: 작은방 청정 예약해줘
시스템: 몇 시부터 몇 시까지 할까요?
사용자: 밤 열 시부터 아침 일곱 시까지
시스템: 작은방 청정을 밤 10시부터 오전 7시까지 예약할게요.

효과는 “다시 말해 주세요”가 아니라 “부족한 값만 물어보는” 제품 경험이다.

4. 기술 관점 효과

4.1 판단과 실행의 책임이 분리된다

Cloud A2A는 무엇을 어떤 순서로 할지 결정한다. On-device Bridge는 그 결정을 기기 계약으로 변환한다. DeviceAgent TaskManager는 실제 실행 lifecycle을 관리한다.

4.2 Catalog가 hallucination을 줄인다

Planner에게 모든 기능을 열어두면 LLM은 실제 없는 기능도 만들어낼 수 있다. Catalog는 planner가 사용할 수 있는 agent/skill/capability의 범위를 제한한다.

catalog가 제공하는 것:
  - 어떤 family가 있는가
  - 어떤 agent가 owner가 될 수 있는가
  - 어떤 skill이 현재 노출 가능한가
  - 어떤 capability가 device에서 지원되는가
  - 어떤 기능은 scheduling 가능한가

효과는 “가능한 것만 계획한다”는 grounding이다. 기획자는 기능 범위를 catalog로 설명하고, 개발자는 contract로 구현하며, QA는 같은 목록으로 검증한다.

4.3 Semantic axis 튜닝으로 성능 개선이 관리 가능해진다

A2A에서 중요한 것은 단어 하나를 추가하는 것이 아니라 판단축을 조정하는 것이다.

예시 축:
  DEF <-> STT_NULL:
    즉답 가능한 짧은 대화인가, 전체 의도 재질문이 필요한 노이즈인가

  ODL <-> SCH:
    즉시 기기 제어인가, 등록/수정/삭제/조회 workflow인가

  DQR <-> FRG:
    로컬 제품/기기 Q&A인가, 외부/public 지식 조회인가

효과는 튜닝 결과를 benchmark, holdout, mismatch transition으로 추적할 수 있다는 점이다. 즉 “느낌상 좋아졌다”가 아니라 어떤 의미 경계가 이동했는지 설명할 수 있다.

5. 업체/QA 관점 효과

5.1 업체 전달 범위가 prompt가 아니라 contract가 된다

업체가 Cloud prompt 내부를 이해할 필요는 없다. 업체는 AAR/API, TaskManager event, reason_code, callback evidence를 맞추면 된다.

5.2 QA 기준이 기능 성공/실패에서 decision trace로 확장된다

기존 QA는 “명령이 실행됐는가”를 주로 본다. A2A 이후에는 실행 전 판단과 실행 후 event까지 함께 봐야 한다.

검증 포인트:

• 발화가 올바른 route family로 갔는가
• Planner가 필요한 step과 dependency를 만들었는가
• catalog 밖 기능을 만들지 않았는가
• missing slot이면 적절한 follow-up을 했는가
• side effect가 있는 작업은 confirmation/replan gate를 지켰는가
• TaskManager event가 Cloud replan 조건과 맞게 올라왔는가

효과는 회귀가 발생했을 때 “LLM이 이상했다”가 아니라 “어느 축/계약/event가 깨졌는지”를 추적할 수 있다는 점이다.

6. 장기 방향: 로보틱스 의사결정 계층

A2A의 장기 가치는 reactive 음성명령만이 아니다. 현재 구조는 과거 대화, 현재 기기상태, 실행 event를 planner 앞단 context로 모으기 시작했다. 다음 단계는 변화량을 보고 미래 상태를 추정하는 proactive 판단이다.

과거:
  대화 이력, active workflow, 사용자 선호

현재:
  기기 위치, 배터리, 센서, domain state, 지원 capability

미래:
  상태 변화량, 반복 패턴, 위험도, 실패 가능성, 예상 사용자 목표

효과는 로봇이 단순히 “시키는 일”만 하는 것이 아니라, 상황을 보고 제안하고, 안전하게 확인하고, 필요한 경우 계획을 수정하는 방향으로 확장될 수 있다는 점이다.

단, proactive가 곧 자동 실행을 의미하지는 않는다. 초기에는 suggestion과 confirmation 중심으로 시작하고, 자동화는 반복성, 안전성, 사용자의 명시적 허용이 확인된 경우에만 제한적으로 열어야 한다.

7. 기대 효과를 어떻게 측정할 것인가

8. 주의할 점

A2A를 넣는다고 모든 문제가 자동 해결되지는 않는다.

• STT 품질이 낮으면 planner 입력 자체가 흔들린다.
• Catalog가 부정확하면 planner가 잘못된 기능 세계를 본다.
• Cue를 단어장처럼 과하게 늘리면 rule-based overfit으로 성능이 흔들린다.
• TaskManager event/reason이 빈약하면 Cloud replan이 의미 있게 동작하기 어렵다.
• Proactive는 안전/권한/사용자 피로도 gate가 없으면 제품 리스크가 된다.

따라서 A2A의 효과는 planner만이 아니라 STT, catalog, context provider, TaskManager, benchmark, vendor evidence가 함께 맞을 때 나온다.

9. 관련 문서

• A2A Adoption Benefits and Roadmap
• A2A Product PRD
• A2A Planner Deep Dive
• Semantic Boundary Calibration Playbook
• DeviceAgent TaskManager 기준 사양서
• A2A Success Criteria