← Docs hub

Experience Runtime Validation Closure 2026-08-05

문서 역할
이 문서는 Experience의 소개 문서가 아니라 현재 구현·실기기 증거·Go/No-Go를 판정하는 최신 검증 문서다. 왜 Experience가 필요하고 무엇이 달라지는지는 Experience Goal: 명령 수행에서 결과 위임으로에서 먼저 본다.

이 문서는 Experience Goal, 기존 A2A Planner, On-device Bridge, DeviceAgent TaskManager가 현재 어디까지 하나의 실행 계통으로 연결됐는지 판정하는 최신 기준 문서다.

기존 문서들이 이론, 설계, 사용성, 비용과 개별 실험을 설명한다면 이 문서는 다음 질문에 답한다.

사용자의 목표가 실제 기기 작업으로 내려가고, callback 증거를 받아 다음 단계와 완료 상태를 올바르게 결정하는가?

1. Executive Verdict

2026-08-05 기준 판정은 다음과 같다.

핵심 결론은 실행 backbone이 닫혔다는 것이다. Planner가 계획을 만들고, TaskManager가 실행하며, callback이 다음 step과 종료를 결정하는 경로는 실제 기기에서 확인됐다.

그러나 이것을 곧바로 “Experience가 모든 기기 목표를 자율 수행한다”는 의미로 확대하면 안 된다. 현재 실기기 검증은 기존 ODL owner workflow의 실행·관찰 backbone을 증명한다. Experience Goal의 device live tier는 이 backbone 위에서 effect, consent, terminal evidence가 모두 닫힌 capability만 별도로 승격해야 한다.

2. Experience의 의미

Experience Goal의 목적은 action 수를 늘리는 것이 아니다. 사용자가 위임한 결과가 여러 step, 긴 대기, 다른 Agent와 기기 callback을 지나도 사라지지 않게 하는 것이다.

명령형 시스템
  "무엇을 실행할까?"

Experience 시스템
  "사용자가 어떤 결과를 위임했으며,
   그 결과가 달성됐다는 증거는 무엇인가?"

따라서 Agentic함은 LLM 호출 횟수나 자율 행동 수로 측정하지 않는다.

이 구조에서 책임 있는 agency는 다음 식으로 표현할 수 있다.

Agency
  = Goal continuity
  + Grounded capability
  + Observable evidence
  + Bounded adaptation
  + User control

하나라도 빠지면 Experience는 과승격, 임의 action, false completion 또는 과도한 재계획으로 변한다.

3. 권한과 데이터 소유권

Experience는 기존 Planner 위에 또 하나의 Planner를 올리는 구조가 아니다.

실행 권위의 단방향성은 다음과 같다.

Experience desired effect
  -> 기존 Planner step과 provider에 결속
  -> TaskManager가 실행
  -> callback이 사실을 증명
  -> Supervisor가 필요할 때만 의미를 판단

Experience admission 자체는 dispatch_allowed=false다. 모델이 “조용한 환경”을 원한다고 해석해도 catalog와 기존 plan에 실제 provider가 없으면 action을 만들 수 없다.

4. Runtime State Machine

4.1 Goal과 workflow 상태

candidate
  -> rejected
  -> blocked
  -> activated
       -> active
       -> waiting_event
       -> waiting_user
       -> replanning
       -> completed
       -> cancelled
       -> failed

상태의 의미는 다음과 같다.

4.2 Step callback의 상태 전이

중요한 수정은 마지막 단일 device step의 COMPLETED 처리다. 이전에는 callback이 정상 수신돼도 “완료 event가 plan을 해제했다”는 이유로 이전 active 상태를 무조건 유지했다. 이제 pending device request, pending cloud step, next step이 없으면 completed와 complete_workflow로 닫힌다.

5. Callback Correlation과 Evidence

callback은 다음 식별자가 같은 실행 계통에 결속돼야 한다.

experience_id
  -> cloud_workflow_id
  -> plan_id
  -> step_id
  -> task_id
  -> event fingerprint

각 필드의 역할은 다르다.

COMPLETED는 하나의 task 또는 native workflow executor가 끝났다는 사건일 수 있다. Experience Goal의 완료는 별도다. 결속된 모든 step과 desired effect의 terminal evidence가 충족돼야 goal_status=completed가 된다.

task submitted != task completed
task completed != workflow completed
workflow completed != goal achieved

이 구분은 바이탈사인 같은 human-in-the-loop 동작에서 특히 중요하다. 앱을 열었다는 사실은 측정 성공이 아니다. 현재 effect도 vital_interaction_ended까지만 정의하며, 실제 완료 또는 취소 event가 없으면 다음 step을 열지 않는다.

6. Failure UX는 실행 계약이다

실패 설명은 TTS 문구를 꾸미는 후처리가 아니다. 원시 기기 사건을 사용자 이해와 재계획 판단에 동시에 사용할 수 있는 구조화된 계약이다.

failure_reason:
  ux_reason_code: DEVICE_LOCATION_NOT_FOUND
  category: position_not_found
  user_message: 거실 공간은 기기에서 찾지 못했어요. 다른 공간 이름을 말씀해 주세요.
  raw_reason_code: position_not_found
  step_id: step_move_living_room
  task_method: setMoveTo
  step_purpose: 거실 이동
  target_name: 거실
  replan_action: ask_user
  retryable: false
  recoverability: user_recoverable
  suggested_action: CHOOSE_ANOTHER_ROOM

6.1 의미 계층

6.2 현재 매핑

Console의 DEVICE RESPONSE · LIVE 카드는 사용자 메시지와 함께 FAILURE CODE, FAILED STEP, NEXT ACTION을 분리해 표시한다. raw reason은 operator용 trace에 남지만 TTS가 내부 key나 영문 context를 읽지 않는다.

7. 2026-08-05 실기기 Evidence

검증은 로컬 shim, 실제 On-device Agent, DeviceAgent TaskManager, 실제 callback을 연결해 수행했다. Experience mode는 shadow, live tier는 content_only였다. 따라서 아래 physical workflow는 기존 ODL plan과 TaskManager backbone의 실기기 증거이며, full Experience device tier의 제품 승인 증거는 아니다.

7.1 Context 수신

실기기 질의에서 다음 범주의 planning context를 확인했다.

• 등록 공간 목록과 room/position mapping
• 현재 위치와 도킹 여부
• 배터리 잔량과 저전력 여부
• 이동·청정 상태
• TaskManager busy와 active task 수
• 공기질 availability와 요약 상태

응답은 사용자에게 등록 공간 이름을 자연어로 설명했고 내부 field 이름이나 raw parameter를 TTS로 노출하지 않았다.

7.2 단일 청정 시작과 정지

청정 시작과 정지를 각각 실행해 같은 종료 계약을 확인했다. 이 검증에서 발견된 단일-step 종료 결함을 수정하고 회귀 테스트를 추가했다.

7.3 이동 후 스테이션 복귀

대표 검증 발화:

욕실로 이동했다가 스테이션으로 복귀해줘

관찰된 실제 event 순서:

STARTED
  -> WORKFLOW_STEP_STARTED  setMoveTo
  -> WORKFLOW_STEP_COMPLETED setMoveTo
  -> WORKFLOW_STEP_STARTED  returnToStation
  -> WORKFLOW_STEP_COMPLETED returnToStation
  -> COMPLETED              native workflow

Cloud workflow는 첫 callback에서 완료되지 않았고, 복귀 dependency가 풀린 뒤 두 번째 step을 실행했다. 최종 callback 뒤에만 completed로 닫혔다.

7.4 사전 실패와 runtime 실패

등록되지 않은 공간은 Planner가 device dispatch 전에 차단하고 구체적인 공간 실패 설명을 반환하는 경로를 확인했다.

runtime failure는 실제 기기에 의도적으로 장애를 만들지 않고 reducer 계약 테스트로 검증했다.

합성 callback 통과와 실제 기기 통과를 같은 수준으로 표현하지 않는다. 전자는 Cloud reducer 계약의 증거이고, 후자는 DeviceAgent와 물리 실행을 포함한 증거다.

7.5 이미 만족된 목표와 단계 결과

스테이션으로 복귀해줘를 스테이션 도킹 상태에서 다시 실행해 멱등성 경계를 검증했다.

DeviceAgent terminal callback에는 다음 물리·의미 결과가 함께 있었다.

{
  "physicalCompletionObserved": true,
  "completedAreaId": "0",
  "outcome": "arrived",
  "current_room_name": "스테이션",
  "position_id": "0",
  "area_id": "0"
}

Cloud는 이 전체 객체를 다음 단계에 노출하지 않는다. return_to_station capability가 선언한 outcome, current_room_name, position_id, area_id만 step_results에 투영했다. 이는 이전 단계 결과를 후속 input_from이 사용할 수 있게 하면서 내부 필드의 무제한 전파를 막는 deny-by-default 경계다.

같은 live E2E에서 실행 안내의 공통 한국어 조사 처리도 확인했다. 복귀을 진행할게요는 복귀를 진행할게요로 교정됐으며, 이 변경은 route 판단 규칙이 아니라 TTS 문장 합성의 문법 보정이다.

8. Regression Closure

2026-08-05 집중 확대 회귀:

415 passed
15 subtests passed

범위:

• Experience admission positive/negative boundary
• Experience Goal compile과 effect grounding
• bounded Supervisor transition
• Router plan과 TaskManager request compile
• task event ingest와 callback reducer
• single-step/multi-step terminal closure
• failure reason과 사용자 응답 계약
• local shim과 trace contract
• 기존 main router response parsing

저장소 전체 회귀:

925 passed
49 skipped

전체 suite에서 처음에는 단일-step round-trip 테스트 1건이 과거 계약인 COMPLETED -> active를 기대해 실패했다. 실기기에서 확인한 terminal 의미와 일치하도록 pending continuation이 없는 경우 COMPLETED -> completed로 기대값을 갱신한 뒤 전체 suite가 통과했다. 이는 실패를 숨긴 것이 아니라 기존 테스트가 보존하던 결함 동작을 새 runtime contract로 교정한 것이다.

이 결과가 일반 Router의 1,000건 Gemini benchmark를 대체하지는 않는다. Router 정확도는 별도 고정 test set과 holdout으로 관리하며, 이 문서의 회귀는 Experience와 TaskManager 구조 변경이 코드 계약을 깨지 않았는지 확인하는 release gate다.

Non-interference 불변조건

1. Experience는 route family가 아니다.
2. 일반 대화는 DEF owner로 끝날 수 있다.
3. 단일 기기 명령은 ODL owner plan을 불필요하게 확장하지 않는다.
4. Experience admission이 거절되거나 blocked돼도 기존 owner 결과를 임의로 바꾸지 않는다.
5. Experience candidate가 활성화되지 않으면 candidate가 만든 side effect는 dispatch되지 않는다.
6. 정상 callback은 모델을 추가 호출하지 않는다.
7. 재계획은 명시적 decision event와 budget 안에서만 열린다.

9. 비용과 지연의 의미

Experience State를 유지한다고 작업 시간 내내 LLM을 호출하지 않는다.

초기 route/plan                 model call
Experience semantic grounding  필요한 mode에서만 model call
TaskManager 실행 대기          0
정상 progress callback         0
dependency 해제                0
terminal evidence 축약         0
failure/blocked/ambiguity       budget 안에서만 decision call

비용을 볼 때 서로 다른 세 수치를 섞지 않는다.

운영 최적화의 우선순위는 모델을 작은 모델로 무조건 바꾸는 것이 아니라 다음과 같다.

1. 일반 non-admission turn에는 Experience payload를 주입하지 않는다.
2. device context는 freshness와 scope를 유지한 compact snapshot으로 제한한다.
3. callback은 event allowlist와 dedup으로 줄인다.
4. 정상 dependency 진행은 deterministic reducer가 처리한다.
5. replan은 전체 plan 재생성보다 국소 repair를 우선한다.

10. 왜 룰베이스가 아닌가

시스템에는 deterministic validator와 state reducer가 존재한다. 이것은 발화별 hardcode와 다르다.

예를 들어 “편하게 쉬고 싶다”를 나이트 모드와 청정으로 고정 치환하지 않는다. Planner는 현재 context에서 의미 목표를 구성하고, catalog가 실제 제공 가능한 effect만 허용한다. 공기질이 양호하면 불필요한 청정을 만들지 않고, 해당 live tier가 닫혀 있으면 안전한 content 응답만 제공한다.

즉 LLM은 의미와 대안을 판단하고, deterministic 계층은 권한, 형식, 순서, 증거와 상한을 보장한다.

11. Observability Contract

운영자가 한 화면에서 확인해야 하는 질문은 다음과 같다.

1. 사용자의 원래 목표는 무엇인가?
2. 어떤 owner와 plan이 선택됐는가?
3. Experience는 admission됐는가, 왜 blocked됐는가?
4. 현재 TaskManager step은 무엇인가?
5. 어떤 callback이 다음 step을 열었는가?
6. 실패했다면 실제 원인, 사용자 설명, 다음 행동은 무엇인가?
7. 완료 주장은 어떤 terminal evidence에 근거하는가?
8. 추가 모델 호출과 replan budget은 얼마인가?

Text Console의 핵심 표시:

• Planner decision flight recorder
• device context snapshot
• Experience admission / activation / goal / grounding
• plan step과 dependency
• device task/workflow request
• live device response
• failure code / failed step / next action
• callback timeline과 terminal status
• model usage ledger

Task Monitor는 실제 queue, 실행 task, physical callback을 중심으로 본다. Text Console은 Planner와 Experience의 “왜”를, Task Monitor는 DeviceAgent의 “무엇이 실행됐는가”를 소유한다.

12. Release Gate

현재 Go

• 로컬 Text E2E 검증
• 기존 ODL single/multi-step TaskManager workflow
• callback 기반 dependency 진행
• terminal evidence 기반 Cloud workflow 종료
• Planner 사전 실패 설명
• runtime failure UX 계약
• Experience shadow 분석
• content_only 제한 검증

Pilot 조건부

• non-motion capability
• 명시적 consent가 필요 없는 가역 설정
• callback과 rollback이 반복 검증된 provider
• feature flag와 usage budget이 적용된 환경

현재 No-Go

• Experience full tier 제품 기본 활성화
• callback 없는 capability의 완료 주장
• 바이탈 측정 성공의 시간 기반 추정
• PUI 취소 실기기 반복 증거 없는 dependent workflow
• catalog 밖 action 생성
• 사용자 요청 없는 민감 센서·촬영·외부 연락
• 무제한 Supervisor loop
• stale context를 근거로 한 자동 action 확대

13. 남은 과업

제품 성숙도는 capability 개수를 세는 방식보다 효과-실행-증거 closure 비율로 관리한다.

Evidence closure coverage
  = terminal evidence까지 반복 검증된 provider 수
    / live 후보 provider 수

14. 읽기 순서

이 문서는 최신 판정을 소유한다. 배경은 다음 순서로 본다.

1. Experience Goal Academic Deep Dive - 이론, 형식 모델, 연구 가설
2. Experience Goal과 기존 Planner 통합 구조 - owner, plan, task, goal 책임 경계
3. A2A Experience Workflow - Goal contract, effect grounding, lifecycle
4. Experience Goal Usability Playbook - 사용자 여정, KPI, 수용 기준
5. A2A Experience Supervisor - 장기 운영 모델과 향후 자율성
6. TaskManager Live Monitor - 이전 실험과 비용 장부

15. 최종 의미

이번 closure에서 중요한 변화는 “복합명령 하나가 움직였다”가 아니다.

Planner의 약속
  -> TaskManager의 실행
  -> Device callback의 사실
  -> Workflow reducer의 상태
  -> Experience의 성공 의미
  -> 사용자가 이해할 수 있는 응답

이 연결이 생기면서 시스템은 답변 생성기에서 증거를 기다리고, 남은 목표를 보존하며, 실패 이유를 설명할 수 있는 실행 Agent로 이동한다.

다음 고도화의 기준도 기능 수가 아니다. 더 많은 행동을 허용하기 전에 각 행동의 전제, 취소, terminal evidence, 실패 설명과 rollback이 닫혀야 한다. 이것이 Experience Goal이 기존 Planner의 성능과 사용자 통제권을 해치지 않으면서 Agentic해지는 핵심 조건이다.