← Docs hub

Experience Goal과 기존 Planner 통합 구조

문서 역할
Experience를 처음 접한다면 먼저 Experience Goal: 명령 수행에서 결과 위임으로에서 AS-IS, 구조적 공백, TO-BE를 본다. 이 문서는 그 변화가 기존 owner, plan, TaskManager 권한을 침범하지 않는 통합 계약을 설명한다.

Experience Goal은 기존 Planner를 대체하는 두 번째 Planner가 아니다. 기존 Main Router가 만든 owner, skill, steps를 실행의 유일한 출발점으로 유지하면서, 여러 단계가 끝날 때까지 보존해야 할 사용자 목표, 시간 관계, 성공 effect를 sidecar metadata로 결속하는 상위 orchestration 계약이다.

30초 요약

기존 Planner
  = 지금 무엇을 어떤 owner와 capability로 실행할지 결정

Experience Goal
  = 왜 이 여러 단계를 이어서 수행하는지와 무엇이 끝나야 성공인지 보존

TaskManager
  = 실제 queue, dependency, wait, timeout, callback을 소유

따라서 DEF, ODL, FRG, DQR, SCH는 그대로 남는다. Experience는 새로운 family가 아니며, 일반 대화나 단일 기기 명령을 가로채지 않는다.

목표의 형식 정의, lifecycle, effect grounding, 비간섭성, 기대 효과, 연구 가설과 평가 방법은 Experience Goal Academic Deep Dive에서 별도로 다룬다. 이 문서는 그 이론을 현재 Planner와 TaskManager 코드 경계에 매핑하는 구현 문서다.

1. 기존 구조에서 바뀌지 않는 것

기존 실행 경로는 다음과 같다.

utterance + device context
  -> Main Router
  -> owner / selected skill / typed steps
  -> build_device_task_requests 또는 build_device_workflow_requests
  -> On-device bridge
  -> DeviceAgent TaskManager
  -> device executor

Experience가 입장해도 이 경로를 교체하지 않는다. 기존 plan에 목표와 effect binding을 추가하고, 실행 전후의 의미 검증 경계를 더한다.

2. 함께 동작하는 전체 흐름

2.1 계획 시점

Main Router 한 번의 structured output에서 기존 plan과 Experience 의미 증거를 함께 반환한다.

{
  "selected_routes": ["ODL"],
  "owner_selection": {
    "route_family": "ODL",
    "selected_skill": "multi_step_device_workflow"
  },
  "steps": [
    {
      "id": "step_move",
      "route": "ODL",
      "action": {
        "capability_id": "move_to_room",
        "operation_id": "start",
        "arguments": {"room_name": "주방"}
      }
    },
    {
      "id": "step_clean",
      "route": "ODL",
      "depends_on": ["step_move"],
      "action": {
        "capability_id": "selected_room_clean",
        "operation_id": "start",
        "arguments": {}
      }
    }
  ],
  "experience_request": {
    "admission_status": "candidate",
    "request_kind": "action_request",
    "delegated_outcome": true,
    "coordination_requirements": [
      "sequencing",
      "waiting"
    ],
    "goal_summary": "주방 이동과 청정을 순서대로 완료한다",
    "desired_effects": [
      "target_location_reached",
      "air_cleaning_active"
    ],
    "temporal_relation": "after_planned_step",
    "temporal_anchor_id": "step_move",
    "prerequisite_capability_id": ""
  }
}

중요한 점은 다음과 같다.

• steps가 실행 계획이다.
• experience_request는 실행 불가능한 의미 관찰 객체다.
• experience_request.dispatch_allowed는 항상 false다.
• typed action이 없는 Experience effect만으로 기기 명령을 만들 수 없다.
• admission을 위해 별도 LLM 호출을 추가하지 않는다.

2.2 deterministic 입장과 결속

prepare_experience_router_policy()와 compile_experience_workflow() 계층은 다음을 검증한다.

1. 사용자가 결과를 실제로 위임했는가
2. 단일 명령이나 일반 대화가 아닌 coordination이 필요한가
3. 시간 관계가 기존 event, 앞선 plan step, clock delay 중 무엇인가
4. desired effect가 canonical effect catalog에 존재하는가
5. 각 effect를 제공할 정확한 capability operation 또는 skill provider가 있는가
6. plan의 step ID와 dependency가 유효한가
7. consent, side effect, terminal evidence가 충족되는가
8. 현재 live tier가 해당 provider를 허용하는가

검증이 끝나면 compact Goal contract를 workflow state에 저장한다.

{
  "experience_id": "exp-...",
  "goal_summary": "주방 이동과 청정을 순서대로 완료한다",
  "success_criteria": [
    "target_location_reached",
    "air_cleaning_active"
  ],
  "plan_binding": {
    "plan_id": "native_room_clean_workflow",
    "step_ids": ["step_move", "step_clean"]
  },
  "decision_budget": {
    "max_decisions": 3,
    "max_replans": 1
  }
}

Goal contract는 계획을 새로 만들지 않는다. 어떤 기존 step들이 한 사용자 목표에 속하는지와 어떤 terminal evidence가 있어야 성공인지 기록한다. max_decisions는 Supervisor 판단 총량, max_replans는 실제 plan 변경 총량을 각각 제한한다.

2.3 실행 시점

활성화된 기존 step은 기존 compiler를 그대로 통과한다.

Planner typed step
  -> Cloud task/workflow request
  -> On-device ForegroundService
  -> DeviceAgent submitWorkflow
  -> TaskManager queue
  -> executor

DeviceAgent가 받는 payload의 핵심 형태도 바뀌지 않는다.

{
  "method": "submitWorkflow",
  "queue": "workflow",
  "dispatch": true,
  "forceTaskManager": true,
  "subTasks": [
    {
      "taskMethod": "setMoveTo",
      "cloud_step_id": "step_move",
      "wait_policy": "completed"
    },
    {
      "taskMethod": "startBasicAirClear",
      "cloud_step_id": "step_clean",
      "wait_policy": "completed"
    }
  ]
}

Experience correlation ID와 effect binding이 추가될 수는 있지만, 실행 method와 완료 판정 권한은 TaskManager 계약이 소유한다.

2.4 callback과 재판단

TaskManager callback은 workflow_state.py에서 workflow와 step에 다시 결속된다.

{
  "event_name": "COMPLETED",
  "workflow_id": "wf-...",
  "step_id": "step_move",
  "task_method": "setMoveTo",
  "requires_cloud_decision": false
}

정상 이벤트는 LLM을 다시 호출하지 않는다.

Supervisor가 열리더라도 decision budget 안에서 continue, ask, replan, complete 중 하나만 선택한다. 정상 진행 callback마다 Planner를 반복 호출하지 않는다.

3. 기존 Planner를 해치지 않는 보호 계약

Experience 통합의 가장 중요한 품질 기준은 Experience 성공률보다 기존 Planner 비간섭성이다.

불변조건

1. Experience는 route family가 아니다. 기존 owner 선택을 유지한다.
2. Planner step이 실행 권위다. Goal이나 effect만으로 device action을 만들지 않는다.
3. Composer는 device step을 합성하지 못한다. 현재 허용 범위는 검증된 cloud content provider로 제한된다.
4. 일반 명령은 기존 owner fallback을 사용한다. 단일 ODL, SCH, FRG, DQR, DEF는 Experience 최소 조건에 미달해도 원래 route로 실행 또는 응답한다.
5. 비입장 요청은 plan을 변경하지 않는다. not_admitted면 Experience metadata를 실행 경로에서 제거한다.
6. 정상 callback은 재계획을 열지 않는다. TaskManager dependency가 다음 step을 deterministic하게 진행한다.
7. 재계획은 bounded하다. 실패, 차단, 사용자 입력, 의미 변화 같은 decision event와 예산 안에서만 수행한다.
8. 미확인 결과는 성공으로 바꾸지 않는다. terminal evidence가 없으면 완료라고 말하지 않는다.

남아 있는 실제 위험

candidate로 잘못 입장한 요청에서 activation이 실패하면 안전을 위해 device dispatch가 억제될 수 있다. 즉 false admission은 기존 Planner의 정상 명령을 막을 수 있는 실제 회귀 위험이다.

이를 막기 위해 다음 세 가지를 함께 본다.

• 일반 명령 negative set의 not_admitted 비율
• candidate activation 실패 시 owner fallback과 dispatch 결과
• 기존 family/flow/task method 회귀

현재 로컬 15개 경계 세트의 최근 반복 실행에서는 positive admission과 negative rejection이 각각 100%, 요청 오류는 0건이었다. 전체 pass는 LLM의 세부 effect와 coordination 출력 변동 때문에 80.0~86.67% 범위였으므로, 제품 기본 활성화는 아직 No-Go다.

4. 대표 예시

예시 A. 일반 대화

사용자: 안녕

DEF 응답
Experience: not_admitted
device request: 0

대화 한 번으로 완결되므로 Goal contract나 TaskManager가 필요하지 않다.

예시 B. 단일 기기 명령

사용자: 주방으로 이동해줘

ODL -> move_to_room
Experience: not_admitted
owner fallback: ODL 유지

단일 capability 명령을 Experience로 올리지 않는다.

예시 C. 기존 plan의 여러 단계를 하나의 목표로 보존

사용자: 주방으로 이동했다가 안방을 청정하고 스테이션으로 복귀해줘

step_move_kitchen
  -> step_move_bedroom
  -> step_clean_bedroom
  -> step_return_station

Planner가 네 개의 typed step과 dependency를 만든다. Experience는 after_planned_step, sequencing, waiting과 성공 effect를 보존한다. TaskManager가 각 완료 callback으로 다음 step을 해제한다.

예시 D. 이미 진행 중인 작업이 끝난 뒤 다른 Agent로 연결

사용자: 청정이 끝나면 오늘 중요한 뉴스를 요약해서 들려줘

prerequisite: stationary_purify
temporal_relation: after_existing_event
follow-up provider: FRG freshness_answer_composition
coordination: waiting + cross_agent

여기서 청정은 새로 시작할 명령이 아니다. 현재 청정 task의 terminal callback이 후속 FRG step을 해제해야 한다. active task나 terminal event ID가 없으면 청정을 대신 시작하지 않고 안전하게 대기 또는 차단한다.

예시 E. 외부 이벤트, 동의, 촬영

사용자: 엄마가 오면 반갑게 인사하고 동의를 받은 뒤 사진을 남겨줘

필요 의미는 다음과 같다.

after_existing_event
  -> presence/arrival observation
  -> greeting
  -> consent
  -> photo

이 요청은 Experience 후보지만, 현재 사람 도착 event provider와 동의·촬영 terminal 계약이 모두 grounded되지 않으면 실행하지 않는다. Planner가 임의로 “엄마가 왔다”고 가정하거나 동의 없이 촬영해서는 안 된다.

예시 F. 시간 지연과 기기 workflow

사용자: 삼십 분 뒤에 거실로 이동해서 나이트 모드를 켜고 끝나면 복귀해줘

clock_delay / SCH ownership
  -> move_to_room
  -> set night mode
  -> return_to_station

Planner는 시간 조건과 실행 dependency를 구조화하고, 지속 시간 대기는 TaskManager 또는 schedule subsystem이 소유한다. Cloud LLM이 30분을 직접 세지 않는다.

5. 데이터 소유권

이 구분이 무너지면 다음 문제가 생긴다.

• LLM이 실제 완료되지 않은 작업을 완료라고 판단
• Cloud가 device wait와 timeout을 중복 소유
• Goal Composer가 catalog 밖의 action을 생성
• 정상 progress callback마다 모델 호출
• 일반 명령이 Experience gate에 막힘

6. 호출량과 지연 방어

따라서 Experience Goal을 추가한다고 모든 명령이 두 번 계획되거나 모든 callback이 LLM으로 올라가지는 않는다. 비용과 지연은 admission false positive, Supervisor 호출 빈도, replan 빈도를 별도 지표로 관리해야 한다.

7. 현재 구현과 다음 Gate

현재 확인된 범위

• Main Router 한 응답에서 기존 plan과 Experience 의미 증거 생성
• 일반 명령과 단일 capability 명령의 non-admission
• canonical effect catalog와 provider grounding
• 기존 plan step/dependency 결속
• existing event, planned step, clock delay 시간 관계
• 선행 capability를 새 action으로 잘못 만드는 경로 억제
• 정상 callback의 deterministic 처리
• Supervisor 판단 총량과 plan 변경 총량의 분리된 budget
• 제한된 content provider와 activation gate

2026-08-03 재계획 budget 검증

기존에는 루트에서 제한 없이 pytest를 실행하면 docs/strategy/short-term/planner_refactor_snapshot_* 아래 freeze 사본의 동일한 test module 이름 때문에 collection mismatch가 발생했다. 현재는 pytest.ini의 testpaths = test로 정식 테스트 경계를 고정했으며, 루트 명령 자체로 전체 회귀가 완주된다. 이는 테스트 대상을 축소한 것이 아니라 보관용 사본을 실행 대상에서 분리한 것이다.

아직 No-Go인 범위

• 임의 외부 이벤트를 안정적으로 관찰하는 범용 provider
• 모든 기기 capability의 terminal effect 계약
• 사람 동의가 필요한 foreground interaction의 반복 실기기 E2E
• result binding으로 다음 방이나 다음 행동을 고르는 범용 selector
• full tier 제품 기본 활성화

제품 활성화 전에는 다음을 통과해야 한다.

1. 일반 family/flow/task method 전체 회귀
2. Experience positive와 near-negative 반복 측정
3. admission false positive로 인한 기존 명령 차단 0건
4. callback correlation과 terminal evidence 실기기 반복 검증
5. Supervisor/replan 호출량과 P95 지연 계측
6. feature flag rollback 검증

소스 기준

gemini/a2a/planner/experience_admission.py
gemini/a2a/runtime/orchestrator.py
gemini/a2a/runtime/experience_workflow.py
gemini/a2a/runtime/experience_goal_composer.py
gemini/a2a/runtime/experience_effects.py
gemini/a2a/runtime/experience_supervisor.py
gemini/a2a/runtime/task_manager.py
gemini/a2a/runtime/workflow_state.py
gemini/a2a/registry/experience_effect_catalog.v1.json

관련 문서

• Experience Runtime Validation Closure 2026-08-05
• Experience Goal Usability Playbook
• Experience Goal Academic Deep Dive
• A2A Experience Workflow: 설계 이론과 현재 구현
• Experience Goal Composer Live Slice 2026-08-02
• A2A Planner Deep Dive
• Device Task Flow
• A2A Experience Supervisor
• TaskManager Callback Completion
• A2A Text E2E Console