← Docs hub

간접 목표에서 A2A Experience까지: 구현 가능성

이 문서는 다음과 같은 간접 발화를 특정 데모 문장으로 처리하지 않고, A2A가 필요한 행동과 workflow로 일반화할 수 있는지 분석한다.

“하이나무, 엄마가 오랜만에 오셔. 편하게 맞아주고 오늘 기억 하나 남겨줘.”

1. 결론

이 장면의 제한된 MVP는 구현 가능하다. 2026-08-01 기준 의미 admission 결과를 기존 검증 plan에 결속하는 feature-gated 1차 live slice까지 연결됐다. 그러나 현재 시스템이 임의의 간접 발화를 자동으로 완성형 Experience로 만드는 상태는 아니다.

현재 확보된 기반은 다음과 같다.

• typed capability 기반 단일·복합 계획
• step 순서와 depends_on
• device context condition
• input_from과 step result 전달
• TaskManager callback과 workflow state
• 실패·보류·사용자 변경에서만 동작하는 bounded replan

현재 빠진 핵심은 다음과 같다.

• 원하는 효과를 capability로 조합하는 Goal Composer
• 동의·촬영·로컬 저장·Memory Card 표시 capability
• 콘텐츠와 물리 task를 잇는 terminal contract

현재 Experience Admission과 runtime activation gate는 구현돼 있다. activation은 새 action을 만들지 않고 같은 Router 결과의 기존 step만 Goal contract에 결속한다. 상세 구조는 A2A Experience Workflow: 설계 이론과 현재 구현에서 본다.

2. 왜 A2A가 필요한가

“사진 찍어줘” 같은 단일 명령에는 A2A가 필수는 아니다. 이 장면은 서로 다른 owner와 lifecycle을 가진 기능이 연결되므로 A2A가 필요하다.

TaskManager는 결정된 물리 workflow를 실행한다. Experience Supervisor는 그 위에서 사용자 목표, 동의, 의미 event, 실패와 변경을 관리한다.

3. 현재 구조가 잘하는 것

현재 Planner 계약은 다음을 표현할 수 있다.

steps:
  - id: prepare_room
    action:
      capability_id: stationary_purify
      operation_id: start
    wait_policy: completed

  - id: welcome
    depends_on: [prepare_room]
    execution_target: content

  - id: return_station
    depends_on: [welcome]
    action:
      capability_id: return_to_station
      operation_id: start

TaskManager와 workflow state는 submitted, completed, waiting과 step result를 유지한다. 정상 완료는 다음 dependency를 해제하므로 매 단계마다 LLM을 호출할 필요가 없다.

Supervisor 판단은 아래 경계에서만 필요하다.

• 사용자 목표 변경 또는 취소
• FAILED, BLOCKED, TIMEOUT, NEEDS_USER_INPUT
• 다음 행동을 고르기 위한 의미 결과

4. 현재 구조가 못하는 것

4.1 최초 Experience 진입

현재 base router는 장기 Experience policy를 직접 만들지 않는다. Supervisor는 활성 Experience의 후속 event를 처리할 수 있지만, 최초 발화를 Experience로 승격하는 ingress가 없다.

4.2 간접 발화 일반화

현재 간접 표현은 capability alias에 걸리면 동작할 수 있다. 그러나 “편하게 해줘”, “손님 맞을 준비를 해줘”처럼 여러 효과를 포함한 목표는 alias만으로 안전하게 처리할 수 없다.

문장별 cue를 늘리면 서술을 행동으로 과승격하는 문제가 생긴다.

4.3 촬영과 UI closure

SKLauncher2에는 카메라 권한이 있지만 가족 사진 촬영과 Memory Card UI는 현재 구현돼 있지 않다. EventAssetAgent의 CameraBroker와 암호화 저장은 기술 기반으로 재사용할 수 있지만, security clip의 업로드·보존 정책과 가족 사진 도메인은 반드시 분리해야 한다.

5. 문장 규칙이 아닌 일반화 방식

Main Router는 장기 정책 전체가 아니라 최소 의미 요청을 한 번에 반환한다.

experience_request:
  intent_shape: experience_goal
  goal_summary: 방문 가족이 편안하게 환영받고 동의한 오늘의 기억을 남긴다
  desired_effects:
    - guest_comfort
    - warm_welcome
    - consented_local_memory
  constraints:
    - local_only_media
    - explicit_consent_before_capture
    - user_can_cancel
  autonomy_level: bounded
  needs_confirmation: true

이후 Goal Composer가 아래 정보로만 plan을 구성한다.

1. experience_request
2. capability card
3. current device context
4. autonomy/consent policy

capability card는 특정 발화가 아니라 effect, precondition, side effect, resource, completion, privacy를 정의한다.

capability_id: consented_memory_capture
effects: [local_memory_created]
preconditions:
  - camera_available
  - explicit_consent_granted
side_effects:
  - captures_personal_media
resources: [camera]
completion: [memory.asset_stored]
privacy:
  storage: local_only

6. 요청과 서술의 안전 경계

촬영, 건강, 보안, 외부 전송은 명시적 동의나 사전 승인 routine 없이 자동으로 실행하면 안 된다.

7. 가족 환영·기억 장면

Goal
  방문 가족이 편안하게 환영받고, 동의한 오늘의 기억을 남긴다.

Observe
  위치, 공간, 공기질, 배터리, 진행 task, 카메라 가용성

Plan
  1. 환경 준비
  2. 도착 event 또는 사용자 확인 대기
  3. 환영 interaction
  4. 사진 여부와 촬영 동의 확인
  5. 촬영
  6. 로컬 암호화 저장
  7. SKLauncher2 Memory Card 표시
  8. 필요 시 스테이션 복귀

정상 callback은 TaskManager가 처리한다. 다음 상황에서만 Supervisor가 판단한다.

• 동의 거절 시 사진 step 제거 또는 텍스트 카드 제안
• 카메라 점유 시 재시도·축소·질문
• 배터리 부족 시 이동·촬영 범위 축소
• “사진은 빼줘”라는 사용자 변경
• 도착 event가 장시간 오지 않는 경우

8. 구현 가능성

따라서 이 장면만을 위한 구현은 비교적 빠르다. 하지만 범용 능력으로 만들려면 experience_request → desired effects → grounded capability composition 경계를 먼저 만들어야 한다.

9. 토큰과 지연 방어

1. 최초 unified router call 1회
2. admission과 capability 검증은 deterministic
3. 정상 task progress에서 추가 LLM 호출 0회
4. ambiguity와 failure boundary에서만 bounded replan
5. Experience당 Supervisor decision 기본 상한 3회

단순 명령에는 Experience 경로를 열지 않으므로 기존 latency를 늘리지 않는다.

10. 검증 기준

추가로 기존 family router 전체 회귀와 TaskManager 60개 시나리오를 유지한다.

핵심 metric은 다음과 같다.

• goal recognition recall
• non-request over-action rate
• capability hallucination 0
• step completeness
• condition/dependency preservation
• callback correlation
• consent compliance 100%

간접 목표 recall보다 서술을 행동으로 잘못 실행하는 over-action을 우선 방어해야 한다.

11. 구현 순서

1. 최소 experience_request와 request/statement admission
2. desired effect ontology와 capability effect metadata
3. content terminal, result schema, active Experience 생성
4. consented memory capture vertical slice
5. SKLauncher2 Memory Card
6. 환영·휴식·수면·환경 회복 Experience catalog

Experience catalog는 고정 문장 모음이 아니라 goal, effect, constraint, success criteria의 재사용 가능한 의미 계약이어야 한다.

12. 최종 판단

현재 시스템은 A2A workflow의 하위 골격을 갖고 있다. 부족한 것은 “문장을 더 잘 매칭하는 cue”가 아니라 간접 목표를 안전하게 실행 계획으로 승격하는 상위 의미 계층이다.

Indirect request
  -> semantic experience_request
  -> desired effects
  -> grounded capability composition
  -> deterministic policy validation
  -> TaskManager/content execution
  -> terminal evidence
  -> bounded replan

이 구조를 추가하면 특정 가족 환영 장면을 넘어 여러 웰니스 경험으로 확장할 수 있다. 이 구조 없이 문장별 alias와 조건문을 늘리면 데모 스크립트 수준에 머문다.