← Docs hub

Experience Goal-Directed Creative Motion Scenarios

목표를 따라 움직임을 새로 구성하는 Experience

결론
방향성은 소화할 수 있다. 다만 여기서 말하는 창의성은 LLM이 모터 명령이나 좌표를 임의로 만드는 것이 아니다. 사용자 목표와 현재 증거를 바탕으로, Catalog에 등록된 안전한 관찰·이동·상호작용 도구를 새 순서로 조합하고 결과에 따라 다음 수단을 바꾸는 능력이다.

현재 시스템은 이 구조의 핵심 계약을 갖췄다. move_to_room, return_to_station, station_location_diagnostics, station_signal_probe, rotate_in_place, vision_semantic_observation이 Planner에 노출되고 MR6 TaskManager의 typed method로 변환된다. 그러나 이동·회전·관찰·복귀를 한 trace로 끝내는 platform-signed physical E2E는 아직 승인 전이다. 따라서 이 문서는 현재 계약, 보강 후 가능, 연구 단계를 분리해 설명한다.

1. 무엇이 창의적인가

1.1 창의성의 위치

즉 동작 집합은 제한적이고, 목표를 푸는 조합은 생성적이다. 이 구조를 bounded generative orchestration으로 정의한다.

1.2 단순 매크로와의 차이

고정 매크로는 시작 전에 모든 step이 결정된다.

move A -> rotate -> observe -> move B -> return

Experience는 각 관찰 결과가 다음 선택을 바꿀 수 있다.

goal
  -> 현재 위치·스테이션 증거 관찰
  -> 신호가 있으면 즉시 복귀
  -> 신호가 없으면 미방문 공간 선택
  -> 이동 완료 후 정지
  -> 회전 또는 의미 관찰
  -> fresh evidence가 있으면 목표 평가
  -> 부족하면 다른 후보, 위험하면 질문, 달성하면 종료

문장별 if "스테이션" in utterance로 workflow를 고정하는 방식이 아니다. Planner는 goal과 effect를 해석하고, 계약 코드는 capability·argument·evidence·budget을 검증한다.

2. 현재 실행 재료

2.1 Cloud Capability Catalog

station_signal_probe에는 device_context.rooms를 후보 원장으로 사용하고, 미방문 후보로 move_to_room을 선택하는 adaptive search 계약이 있다. 재계획은 같은 후보를 반복하지 않고 budget 안에서만 진행해야 한다.

2.2 MR6 TaskManager binding

MR6 ObservationTaskExecutor는 이동 중 Vision 관찰을 거부한다. 기기를 정지시키고 관찰 자세가 준비된 뒤 fresh Vision 결과를 기다리며, 끝나면 관찰 자세를 해제한다. 따라서 “이동하면서 카메라를 계속 켜고 판단”이 아니라 이동 → 정지 → 자세 전환 → 단발성 의미 관찰이 현재의 안전한 primitive다.

2.3 권위 분리

3. 구현 상태 범례

M1이라고 해서 모든 시나리오가 제품 live라는 뜻은 아니다. 개별 primitive의 연결 상태와 전체 Experience의 physical acceptance는 별개다.

4. 대표 시나리오 포트폴리오

4.1 스테이션 위치 복구 탐색

“스테이션이 옮겨진 것 같아. 확인해보고 찾을 수 있으면 복귀해줘.”

현재 Vision 모델에는 스테이션 전용 class나 fiducial marker 계약이 확인되지 않았다. 따라서 카메라가 무엇인가를 봤다는 이유만으로 스테이션 위치를 확정하지 않는다. 도킹 신호·충전·AMR 위치가 최종 근거다.

4.2 등록 공간 의미 순찰

“등록된 방을 천천히 살펴보고 특이한 게 있으면 어디였는지 알려줘.”

map rooms
  -> 미방문 room 선택
  -> move_to_room
  -> stationary 확인
  -> vision_semantic_observation
  -> {object_class, confidence, observed_at_ms}만 저장
  -> 다음 room 또는 요약

이 시나리오는 raw 영상 전송 없이 공간별 semantic observation을 묶을 수 있다. 다만 현재 object class 범위, 오탐률, 관찰 결과와 room correlation의 physical E2E가 충분하지 않으므로 M3다. 사람 신원·얼굴·세부 사물 소유자를 추론해서는 안 된다.

4.3 공기질 기반 조용한 공간 선택

“공기 상태가 안 좋은 곳을 찾아서 조용히 청정하고 끝나면 돌아와.”

필요한 goal graph는 다음과 같다.

registered rooms
  -> per-room air quality observation
  -> worst eligible room selection
  -> move -> quiet cleaning -> terminal evidence -> return

현재 planning context에는 공기질이 있지만 공간별 fresh scan provider가 관리 capability로 닫혀 있지 않다. 따라서 현재 값 하나를 모든 방의 상태처럼 사용하면 안 된다. per_room_air_quality_scan과 room-correlated timestamp가 추가된 뒤 가능한 M3 시나리오다.

4.4 소리 방향 기반 응답 이동

“방금 부른 사람이 있는 쪽을 확인해서 너무 가까이 가지 말고 대답해줘.”

SoundFlow의 DoA는 후보 방향을 제공할 수 있지만 절대 위치나 사람 신원을 뜻하지 않는다. 다음 provider가 필요하다.

observe_sound_direction
  -> confidence / freshness / resource lock
  -> bounded rotation
  -> optional person-presence semantic observation
  -> safe approach distance policy
  -> TTS

현재 Cloud capability와 safe approach distance evidence가 없으므로 M3다. DoA를 좌표로 변환하거나 카메라 밖 사람을 확정하는 방식은 금지한다.

4.5 움직이는 프라이버시 브리핑

“내가 있는 곳으로 와서 가족 알림만 조용히 알려줘.”

사람 존재, 사용자 위치, 알림 privacy class, 안전 거리, TTS volume을 함께 다뤄야 한다. 현재 WSS semantic observation은 신원 없는 bounded event이고 Android 알림 연동도 제품 계약이 확정되지 않았다. 사용자 identity와 private notification provider가 생긴 뒤의 M3 시나리오다. 불확실하면 이동하지 않고 현재 위치에서 사용자 확인을 요청한다.

4.6 Adaptive Welcome & Care

“내가 돌아오면 집 상태를 보고 필요한 것만 해주고 나한테 와서 알려줘.”

Product Interaction, map, 배터리, 공기질, 사람 존재, 청정, TTS, 복귀를 목표 중심으로 결합한다. 현재 개별 기능과 대표 계약은 존재하지만 trigger부터 물리 실행·관찰·복귀까지 한 trace로 닫는 acceptance가 남아 있어 M2-M3다.

4.7 실패를 설명하는 자율 복구

“청정하고 돌아오되 길이 막히면 무리하지 말고 다른 방법을 찾아봐.”

이 시나리오의 핵심은 움직임보다 실패 수렴이다.

구조적 failure UX와 bounded replan은 M1-M2, 각 reason의 physical 반복 수용은 계속 닫아야 한다.

4.8 관찰을 포함한 휴식 Experience

“오늘 너무 피곤해. 조용하고 편하게 쉴 수 있게 도와줘.”

이 목표는 반드시 이동을 포함하지 않는다. DEF 안내만으로 충분하면 content-only로 종료한다. 현재 소음·조명·기기 위치·사용자 동의가 환경 변경의 필요성을 뒷받침할 때만 나이트 모드, 볼륨 최소화, 화면 자극 감소, 선택 청정 같은 provider를 추가한다.

창의성은 action 수가 아니라 불필요한 움직임을 하지 않는 판단에도 있다. 현재 content-only와 일부 non-motion effect는 M1, 이동을 포함한 자율 공간 선택은 공간별 관찰 provider가 추가된 뒤의 M3다.

4.9 사용자를 따라가는 엔터테인먼트 Experience

“내가 움직이면 적당히 따라오면서 오늘 있었던 일을 같이 정리해줘.”

follow mode와 DEF 대화를 동시에 유지하려면 이동 lifecycle, 음성 resource, 안전 거리, 사용자 pause/cancel, 대화 turn state가 함께 관리돼야 한다. 단순 follow me와 대화는 각각 가능하더라도 결합 terminal과 resource arbitration이 닫혀 있지 않으므로 M3다.

4.10 표현적 움직임

“축하해주면서 기쁜 느낌으로 움직여줘.”

제자리 회전 하나를 감정 표현으로 사용하는 것은 가능하지만, LLM이 회전 각도와 이동 궤적을 자유 생성하는 choreography는 현재 범위가 아니다. 표현 동작은 사전에 검증된 motion phrase catalog, 속도·각도 envelope, 사람 거리, 즉시 cancel, 멀미·소음 기준을 갖춘 뒤에만 허용할 수 있는 M4다.

5. 쇼케이스 대표 Scene

Home Recovery Explorer

사용자에게 가장 분명한 Agentic 차이는 “정해진 경로 재생”이 아니라 예상과 다른 현실을 보고 방법을 바꾸는 것이다.

“스테이션을 옮긴 것 같은데, 어디 있는지 확인해서 찾으면 돌아가줘. 못 찾으면 어디까지 봤는지 알려줘.”

사용자에게 보이는 흐름

1. 기기는 현재 위치와 기존 스테이션 근거를 확인한다.
2. 현재 자리에서 새 도킹 신호를 관찰한다.
3. 신호가 없으면 등록 공간 중 아직 확인하지 않은 후보를 고른다.
4. 이동이 끝난 뒤 정지하고, 필요한 경우 방향을 바꿔 다시 관찰한다.
5. 신호가 확인되면 복귀를 실행하고 실제 도킹을 기다린다.
6. 찾지 못하면 “주방과 안방까지 확인했지만 신호를 찾지 못했어요”처럼 증거 범위를 설명하고 사용자의 도움을 요청한다.

화면에서 보여야 하는 것

GOAL        스테이션 위치 근거 확보 후 안전 복귀
OBSERVE     current station evidence · confidence · freshness
DECIDE      candidate=안방 · reason=unvisited
ACT         setMoveTo(안방)
EVIDENCE    movement.arrived
OBSERVE     probeDockingSignal=false
REPLAN      candidate=주방 · budget 1/3
COMPLETE    station reached / or ask_user

내부 sensor key 전체나 raw 이미지를 노출하지 않고, “왜 다음 공간을 선택했는지”와 “무엇이 실제로 확인됐는지”만 보여준다.

6. Planner가 만드는 것은 함수 호출 목록이 아니다

Planner output은 최소한 다음 의미 계약을 가져야 한다.

{
  "goal": "station safely located and reached",
  "required_effects": [
    "station_location_assessed",
    "station_signal_acquired",
    "station_reached"
  ],
  "candidate_policy": {
    "source": "device_context.rooms",
    "selection": "unvisited_only",
    "max_candidates": 3
  },
  "constraints": [
    "never_invent_coordinates",
    "observe_only_while_stationary",
    "never_update_map_without_confirmation"
  ],
  "completion": "terminal evidence for station_reached"
}

실제 task method와 parameter는 capability compiler가 만든다. LLM은 AMRMotor.rotate()나 StationRepositioning 같은 저수준 함수를 직접 호출하지 않는다.

7. 재계획 경계

LLM을 다시 부르는 경우

• terminal evidence가 required effect를 충족하지 못함
• 관찰 결과로 다음 후보를 의미적으로 선택해야 함
• 지원 수단이 여러 개이고 trade-off 비교가 필요함
• policy·privacy·사용자 동의가 필요함
• 원래 목표가 사용자 새 발화로 바뀜

LLM을 다시 부르지 않는 경우

• 정상 QUEUED, RUNNING, PROGRESS
• 같은 task의 반복 telemetry
• 이미 계약에 정의된 local retry
• dedup 가능한 동일 observation
• TaskManager가 판정할 수 있는 timeout·cancel 전파

이 경계가 있어야 창의적 동작이 token과 latency를 무제한 소비하지 않는다. 전체 method 60개를 매번 prompt에 넣지 않고, 현재 goal과 live tier에 맞는 capability excerpt만 제공한다.

8. 안전·프라이버시 Guardrail

1. 좌표 비발명: 등록 공간과 DeviceAgent가 제공한 pose만 사용한다.
2. 정지 관찰: Vision은 이동 완료와 stationary evidence 뒤에만 실행한다.
3. semantic-only: raw frame, 얼굴 이미지, bbox, 음성 원문을 Planner에 기본 전달하지 않는다.
4. 후보 상한: 최대 후보 수, 최대 replan 수, 전체 timeout을 둔다.
5. resource lock: movement, camera, microphone, display의 충돌을 DeviceAgent가 차단한다.
6. human checkpoint: map 변경, 보안 모드, 민감 알림, 건강 판단은 사용자 확인을 요구한다.
7. 실제 완료: STARTED나 command ACK를 목표 완료로 인정하지 않는다.
8. 취소 우선: PUI·음성 cancel은 dependent step과 재계획보다 우선한다.
9. 설명 가능한 실패: reason code를 사용자 언어로 바꾸되 내부 key를 그대로 읽지 않는다.
10. 기존 Planner 보호: 일반 DEF와 단일 ODL은 불필요하게 Experience로 승격하지 않는다.

9. 출시 지표

숫자 목표는 physical rehearsal 데이터를 수집한 뒤 고정한다. 현재 계약 테스트 통과율을 제품 성공률로 대체하지 않는다.

10. 단계별 로드맵

P0 · 현재

• Cloud capability와 MR6 task method 정합 유지
• station diagnosis·probe·rotation·semantic observation의 단위·계약 회귀
• 미방문 후보, budget exhaustion, fail-closed 검증
• Console에 goal, candidate, evidence, replan reason 표시

P1 · Physical acceptance

• platform-signed APK에서 이동 → 정지 회전 → fresh 관찰 → 복귀 한 trace 수집
• positive·negative docking evidence 모두 재현
• 중간 PUI cancel과 low battery·busy·timeout 검증
• 실제 도착을 못 받은 경우 다음 step이 제출되지 않는지 확인

P2 · Observation-aware Experience

• 공간별 공기질 observation provider
• DoA를 bounded direction fact로 노출하는 provider
• observation과 room·workflow·step correlation 강화
• object class allowlist와 오탐 평가

P3 · Showcase composition

• Home Recovery Explorer rehearsal와 운영 UI
• Adaptive Welcome & Care의 trigger부터 복귀까지 full trace
• 실패 원인·방문 범위·남은 목표를 사용자 언어로 설명
• token, latency, battery, 불필요 이동을 함께 측정

P4 · Research

• 사전 검증된 expressive motion phrase catalog
• 사람 거리 기반 safe approach
• station marker 또는 전용 detector
• privileged map repositioning과 사용자 확인·rollback

11. 최종 판단

Experience가 지향해야 할 것은 “LLM이 로봇을 마음대로 움직인다”가 아니다.

현재 상태를 읽고
가능한 도구만 고르고
실제 결과를 기다리고
부족하면 다른 안전한 방법을 시도하고
그래도 안 되면 이유와 확인 범위를 설명한다.

이 방향은 현재 A2A Planner, Effect Catalog, Experience Supervisor, MR6 TaskManager의 책임 분리와 맞는다. 조합 창의성은 지원 가능한 방향이고, 물리 자유도는 DeviceAgent가 강하게 제한해야 한다. 지금 가장 가치 있는 다음 단계는 새 문장 규칙을 추가하는 것이 아니라, Home Recovery Explorer의 platform-signed physical trace를 닫고 필요한 observation provider를 하나씩 Catalog에 승격하는 것이다.

관련 문서

• Experience Catalog, Evidence, and Bounded Replan
• DeviceAgent Agentic I/O Coverage Matrix
• MR6 Station Relocation Evidence
• Experience Supervisor
• Experience Goal Usability Playbook
• Experience Runtime Validation Closure