← Docs hub

Experience Goal Usability Playbook

실사용 목표, 사용자 여정, 수용 기준

문서 역할
Experience의 프로젝트 의미와 AS-IS/TO-BE는 Experience Goal: 명령 수행에서 결과 위임으로에서 먼저 본다. 이 문서는 그 구조가 사용자 부담, 신뢰, 복구성, 결과 위임 경험으로 어떻게 측정되어야 하는지 다룬다.

Experience Goal의 제품 가치는 “한 문장에서 더 많은 명령을 추출한다”가 아니다. 사용자가 원하는 결과를 한 번 위임하면 시스템이 실행 상태를 관찰하고, 필요한 시점에만 질문하며, 성공 증거가 확인될 때까지 목표를 잃지 않는 데 있다.

이 문서에서 실사용 근거는 사용자 연구가 이미 완료됐다는 뜻이 아니다. 현재 코드에 존재하는 effect catalog, provider live tier, TaskManager callback, Supervisor budget을 기준으로 다음을 구분한다.

• 지금 제한적으로 제공할 수 있는 경험
• 통제된 실기기 검증 뒤 제공할 수 있는 경험
• 계약은 있으나 반복 E2E가 필요한 경험
• 현재는 사용자에게 약속하면 안 되는 경험

관련 이론과 구조는 Experience Goal Academic Deep Dive, 기존 Planner와의 결합은 Experience Goal과 기존 Planner 통합 구조에서 본다. 현재 실기기 callback, failure UX, 회귀 결과와 제품 Go/No-Go는 Experience Runtime Validation Closure 2026-08-05를 최신 기준으로 한다.

1. 사용자가 실제로 겪는 문제

복합 경험을 개별 명령으로만 제공하면 사용자는 시스템 내부 순서를 기억해야 한다.

사용자:
  "주방으로 가"
  -> 도착을 기다림
  "청정 시작해"
  -> 완료를 기다림
  "오늘 뉴스 알려줘"
  -> 끝나면
  "스테이션으로 돌아가"

이 방식은 API 관점에서는 단순하지만 사용자 관점에서는 다음 부담을 만든다.

Experience Goal은 이 부담을 결과 위임, 상태 보존, 증거 기반 완료, 제한 재계획으로 줄이는 것을 목표로 한다.

2. 핵심 사용성 목표

사용성 핵심 문장

한 번 말한다.
시스템이 기다린다.
실제 상태를 확인한다.
필요할 때만 다시 묻는다.
증거가 있을 때만 완료라고 말한다.

3. 현재 제공 범위

3.1 Readiness ladder

기본 live tier가 content_only라는 것은 R2·R3 provider가 catalog에 있어도 자동으로 실행된다는 뜻이 아니다. 실기기 안전성과 terminal evidence가 확인된 tier만 운영 설정으로 단계적으로 열어야 한다.

3.2 현재 증거로 닫을 수 있는 결과

현재 catalog는 다음 15개 effect를 정의한다.

observation:
  air_quality_observed
  battery_state_observed

device/location:
  air_cleaning_active
  air_cleaning_stopped
  target_location_reached
  station_reached
  quiet_environment
  reduced_visual_stimulation
  audio_muted
  audio_restored

interaction/content:
  vital_interaction_ended
  supportive_conversation_delivered
  rest_guidance_delivered
  fresh_information_delivered
  story_session_started

vital_interaction_ended는 바이탈 측정 성공을 뜻하지 않는다. 사용자가 완료하거나 취소하여 상호작용이 끝났다는 terminal evidence만 의미한다. 이런 의미 제한이 사용자에게 거짓 성공을 말하지 않게 한다.

4. 대표 실사용 여정

4.1 잠깐 쉬고 싶은 순간

사용자: "잠깐 편하게 쉬게 도와줘."

중요한 점은 “편하게”를 고정 API 목록으로 치환하지 않는 것이다. Planner는 목표를 해석하고 catalog에 있는 provider만 선택한다. non-motion provider가 닫혀 있으면 안내만 제공하고, 실행하지 않은 환경 변경을 했다고 말하지 않는다.

4.2 진행 중인 청정이 끝난 뒤 브리핑

사용자: "청정 끝나면 오늘 주요 뉴스만 짧게 알려줘."

정상 청정 progress는 LLM 재호출 없이 deterministic하게 줄인다. 완료 event가 왔을 때만 다음 provider를 연다. 사용자는 청정 상태를 계속 지켜보거나 다시 호출할 필요가 없다.

4.3 방해를 줄이는 야간 준비

사용자: "삼십 분 뒤에는 소리랑 화면을 줄여서 조용히 쉴 수 있게 해줘."

모델이 “조용함”이라는 단어만 보고 임의 기능을 생성하면 안 된다. 현재 capability와 context에서 실제 제공 가능한 effect의 조합만 계획한다.

4.4 이동·바이탈·복귀

사용자: "안방으로 가서 바이탈사인을 시작하고 끝나면 복귀해줘."

이 여정은 Experience Goal이 필요한 대표 이유를 보여준다. 음성 session보다 상호작용이 길고, 사람의 완료·취소가 다음 단계의 조건이기 때문이다.

4.5 공기 상태를 보고 필요한 경우에만 청정

사용자: "지금 공기 상태를 보고 필요하면 청정해줘."

사용자 가치가 큰 목표지만 현재는 부분 준비 상태다.

범용 result binding과 조건 정책이 닫히기 전에는 “공기 상태를 봤고 필요해서 청정했다”는 전체 목표 성공을 주장하면 안 된다. 현재는 공기 상태를 설명하거나, 사용자에게 청정 시작 여부를 확인하는 단계까지가 안전하다.

4.6 일반 대화는 그대로 대화로 끝낸다

사용자: "오늘 좀 힘들었어."

이 발화는 DEF 응답으로 끝나야 한다. “힘들다”를 휴식 Goal로 자동 승격해 화면, 소리, 청정을 변경하면 사용자 통제감을 해친다.

잘못된 경험:
  감정 표현 -> 임의 기기 실행

올바른 경험:
  공감 응답 -> 사용자가 도움을 위임할 때만 Goal admission

4.7 단일 명령은 복잡하게 만들지 않는다

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

이 요청은 기존 ODL singleton 경로가 처리한다. Goal lifecycle, Supervisor, 추가 질문을 열지 않는다. Experience Goal의 성능은 더 많은 발화를 입장시키는 비율이 아니라, 필요한 발화만 입장시키는 정밀도로 평가해야 한다.

5. 사용자에게 보여줄 상태와 문구

내부 contract나 raw context를 그대로 TTS로 읽지 않는다.

상태 설명의 최소 원칙

1. 현재 단계
2. 기다리는 이유
3. 사용자가 해야 할 일이 있는지
4. 실패했다면 완료된 부분과 남은 부분

이 네 가지보다 많은 내부 파라미터를 읽는 것은 디버깅에는 유용해도 사용자 경험에는 불필요하다.

6. 사용자 스토리와 수용 기준

Story A. 결과 위임

사용자로서 여러 단계를 순서대로 다시 말하지 않고 최종 결과를 한 번에 요청하고 싶다.

수용 기준:

• Planner가 기존 catalog capability만 사용한 typed plan을 만든다.
• 단계 의존성이 보존된다.
• 음성 session 종료 뒤에도 active workflow가 유지된다.
• terminal evidence가 없는 step은 완료 처리하지 않는다.

Story B. 진행 이해

사용자로서 기기가 멈춘 것인지, 기다리는 것인지, 내 입력이 필요한지 알고 싶다.

수용 기준:

• active, waiting, blocked, waiting_user 상태가 사용자 문구로 구분된다.
• 대기 이유가 event, delay, consent 중 하나로 설명된다.
• 디버그용 ID와 raw context는 TTS에 노출하지 않는다.

Story C. 안전한 취소

사용자로서 중간에 마음이 바뀌면 남은 작업까지 확실히 멈추고 싶다.

수용 기준:

• PUI, 음성, TaskManager 취소가 같은 workflow에 correlation된다.
• 실행 중 task와 아직 실행하지 않은 dependent step을 구분해 취소한다.
• 취소 뒤 Supervisor가 같은 plan을 자동 재시작하지 않는다.
• 사용자에게 취소 범위를 한 문장으로 알린다.

Story D. 실패 복구

사용자로서 일부 단계가 실패해도 성공한 부분을 반복하지 않고 이어가고 싶다.

수용 기준:

• reason code와 completed effect를 보존한다.
• 재계획은 max_replans 범위 안에서만 수행된다.
• 기존 성공 step을 다시 수행하려면 명시적 이유가 있어야 한다.
• 복구 불가능하면 남은 목표와 안전한 종료 상태를 설명한다.

7. KPI와 출시 Gate

아래 값은 현재 측정 결과가 아니라 pilot 목표값이다. 실제 baseline 측정 뒤 조정해야 한다.

7.1 안전·정합성 Gate

7.2 사용성 KPI

7.3 비용·지연 SLO

8. 사용성 검증 프로토콜

8.1 비교 조건

동일한 사용자 결과를 두 방식으로 수행한다.

A. 단계별 명령:
   이동 명령 -> 기다림 -> 실행 명령 -> 기다림 -> 후속 명령

B. Experience Goal:
   최종 결과 한 번 위임 -> 시스템 관찰 -> 필요한 경우에만 사용자 개입

8.2 기록 항목

• 목표 완료 여부
• 총 사용자 발화 수
• 목표 완료까지 걸린 시간
• 사용자가 기기 상태를 확인한 횟수
• 수정·취소·재시도 횟수
• 현재 단계 이해도
• 예상과 실제 결과 일치도
• 자동화 통제감과 신뢰도
• model call, token, p50/p95 latency

8.3 필수 경계 테스트

9. 제품 범위

Must

• Goal, plan, task 상태를 분리해 저장·표시
• canonical effect와 terminal evidence 검증
• cancel, timeout, consent, callback correlation
• 일반 대화와 단일 명령의 non-admission
• model call과 replan budget 계측

Should

• goal-aware 사용자 진행 카드
• 완료된 부분과 남은 부분을 구분한 실패 설명
• content-only와 non-motion tier별 feature flag
• 시나리오별 usability telemetry

Could

• 사용자 선호를 반영한 provider 선택
• 반복 루틴의 명시적 opt-in
• 접근성 수준에 맞춘 음성·화면 피드백 조절

현재 비범위

• 시스템이 사용자 요청 없이 장기 목표를 생성하는 무제한 자율성
• 공기질이나 바이탈 수치에 대한 의료적 진단
• 동의 없는 촬영·live view·외부 연락
• catalog 밖 Android UI 자동 조작
• 완료 event가 없는 interaction의 시간 기반 강제 성공

10. 구현 근거와 다음 검증

다음 실사용 검증 순서는 다음과 같다.

1. R1 content-only에서 일반 대화 비간섭과 응답 품질을 고정한다.
2. R2 non-motion에서 실제 상태 변경과 terminal evidence를 반복 검증한다.
3. PUI·음성 cancel이 dependent step까지 전파되는지 확인한다.
4. R3 movement·vital·story는 개별 capability와 복합 workflow를 분리 검증한다.
5. result binding이 닫히기 전까지 조건부 자율 실행은 shadow로만 평가한다.

11. 결론

Experience Goal의 성공은 “복합 명령을 몇 개 만들었는가”로 판단하면 안 된다.

사용자가 한 번 위임하고
시스템이 실제 상태를 관찰하며
불필요하게 다시 묻지 않고
원하면 즉시 멈출 수 있고
증거가 있을 때만 완료라고 말하는가

이 질문에 답할 수 있어야 Experience Goal이 구조적 기능을 넘어 실제 사용성 가치를 만든다.

함께 볼 최신 판정

• Experience Runtime Validation Closure 2026-08-05
• Experience Goal과 기존 Planner 통합 구조
• A2A Experience Workflow