← Docs hub

Experience Goal: 명령 수행에서 결과 위임으로

이 문서는 SK-Intellix에서 Experience가 왜 필요한지 처음 접하는 사람에게 설명하는 기준 문서다. 구현 상세보다 먼저 기존 구조가 어디까지 해결했고, 무엇이 남았으며, Experience가 그 빈칸을 어떻게 메우는지를 AS-IS와 TO-BE로 비교한다.

한 줄 정의
Experience는 새로운 명령 family나 두 번째 Planner가 아니다. 사용자가 위임한 결과와 성공 기준을 기존 A2A Planner의 계획, TaskManager의 실행 사실, 여러 Agent의 결과에 결속해 끝까지 유지하는 목표 연속성 계층이다.

1. 30초 메시지

SK-Intellix는 이미 다음 질문에 답하는 계층을 갖추고 있다.

그러나 이 계층들을 모두 지나도 한 가지 질문이 남는다.

여러 단계와 Agent를 거친 뒤에도, 사용자가 처음 원한 결과는 무엇이며 언제 달성됐다고 말할 수 있는가?

Experience Goal은 바로 이 질문을 담당한다.

기존 실행 중심
  요청 이해 -> 계획 -> 실행 -> 응답

Experience 목표 중심
  사용자 결과 위임
    -> 실행 가능한 계획에 결속
    -> 실제 상태와 callback 관찰
    -> 필요한 경계에서만 질문·복구·재계획
    -> 증거가 있을 때만 목표 완료

핵심 변화는 기능 수가 늘어나는 것이 아니다. 시스템의 책임 단위가 한 번의 응답이나 하나의 task에서 사용자가 위임한 결과로 확장되는 것이다.

2. 왜 지금 Experience인가

Experience는 초기 음성 라우터에 바로 추가할 수 있는 장식 계층이 아니다. 아래 기반이 차례로 갖춰져야 의미가 생긴다.

A2A Routing
  -> Context-Aware
  -> Semantic Planner
  -> TaskManager Runtime
  -> Experience Goal

따라서 Experience는 기존 계층을 교체하지 않는다. 앞선 네 계층이 만든 능력을 사용자 결과 단위로 통합하는 마지막 의미 계층이다.

3. AS-IS: 잘 실행하지만 결과를 오래 보존하지 못한다

여기서 AS-IS는 현재 전체 시스템이 무능하다는 뜻이 아니다. 기존 owner 경로와 Experience가 적용되지 않은 실행 단위의 구조적 한계를 뜻한다.

3.1 상호작용의 기본 단위가 turn 또는 task다

단일 명령과 명확한 복합명령에는 강하다.

"안방으로 이동해"
"거실로 가서 청정하고 복귀해"

하지만 사용자가 기능 이름 대신 상위 결과를 위임하면, 한 번의 대화 응답이나 고정된 workflow만으로는 충분하지 않을 수 있다.

"오늘 너무 피곤해. 잠깐 편하게 쉴 수 있게 도와줘."
"청정이 끝나면 오늘 중요한 소식만 알려줘."

3.2 task 완료와 사용자 결과 완료가 섞일 수 있다

이동 task가 끝났다고 휴식 준비가 끝난 것은 아니다. 청정 task가 끝났다고 뉴스 브리핑까지 끝난 것도 아니다.

Task completed
  != Workflow completed
  != User goal achieved

3.3 Agent 전환 때 원래 목적이 약해질 수 있다

ODL이 청정을 수행한 뒤 FRG가 정보를 찾고 DEF가 답변을 구성할 수 있다. 각 Agent의 결과가 맞더라도 “왜 이 순서로 수행하는가”와 “어떤 결과까지 전달해야 하는가”가 공통 상태로 남지 않으면 전체 경험은 분절된다.

3.4 실패 뒤 사용자가 다시 감독해야 한다

중간 단계가 실패하면 사용자가 이미 끝난 단계와 남은 요청을 기억해 다시 설명하기 쉽다. 시스템이 task 단위 사실만 알고 상위 목표를 잃으면, 부분 성공을 보존한 복구가 어렵다.

3.5 context는 계획 입력이지만 목표의 성공 기준은 아니다

공기질, 위치, 배터리, 진행 작업을 Planner가 볼 수 있어도, 그 값이 왜 중요한지와 어떤 변화가 성공인지가 Goal에 결속되지 않으면 context는 일회성 참고 정보에 머문다.

4. 구조적 공백: 시스템은 방법과 사실을 알지만 목적의 연속성이 없다

기존 계층별 책임은 올바르다. 문제는 책임을 합쳐야 할 때 생긴다.

이 공백을 Planner가 모두 소유하게 하면 Planner가 장기 runtime과 물리 사실까지 추정하게 된다. 반대로 TaskManager가 소유하게 하면 실행 계층이 사용자 의미와 대화 정책까지 판단하게 된다.

Experience는 두 계층을 합치지 않고 다음 결속만 추가한다.

Goal
  <-> Planner의 grounded plan
  <-> TaskManager의 authoritative event
  <-> Agent output의 semantic evidence

5. TO-BE: 사용자는 명령이 아니라 결과를 위임한다

TO-BE에서 Experience Goal은 다음 정보를 compact sidecar로 유지한다.

동작 원칙은 단순하다.

1. Main Router와 Planner가 기존 방식으로 owner와 grounded plan을 만든다.
2. 의미상 결과 위임이 필요한 요청만 Experience 후보가 된다.
3. deterministic gate가 capability, effect, consent, live tier를 검증한다.
4. TaskManager가 실제 실행과 callback의 권위를 가진다.
5. 정상 진행은 상태만 갱신하고 LLM을 다시 부르지 않는다.
6. 실패, 차단, 사용자 입력, 의미 변화에서만 제한된 판단을 연다.
7. terminal evidence가 닫힐 때만 사용자 목표를 완료한다.

6. AS-IS와 TO-BE 비교

7. 하나의 장면으로 보는 차이

사용자 발화

"오늘 너무 피곤해. 잠깐 편하게 쉴 수 있게 도와줘."

AS-IS에서 가능한 결과

• DEF가 공감과 휴식 안내를 제공하고 turn을 종료한다.
• 또는 실제 catalog에 없는 음악·명상 기능을 제안할 위험이 있다.
• 기기 상태를 조회했더라도 어떤 환경 변화가 휴식에 필요한지 계속 보존하지 않는다.

이 결과가 항상 틀린 것은 아니다. 짧은 대화만으로 사용자의 요구가 충족됐다면 DEF 종료가 가장 좋은 답이다. Experience의 목적은 모든 발화를 복합 workflow로 과승격하는 것이 아니다.

TO-BE에서의 판단

1. 의미 판단
   goal: 사용자가 짧게 휴식을 시작할 수 있도록 돕는다

2. 최소 충족 판단
   DEF의 짧은 안내만으로 충분한가?
   현재 환경 변화가 실제로 필요한가?

3. grounded provider 확인
   지원되는 기능과 현재 device context만 사용
   지원되지 않는 음악 재생은 약속하지 않음

4. 실행이 필요하면
   night/quiet 관련 non-motion capability
   + 필요한 경우에만 조용한 청정
   + 짧은 휴식 안내

5. 관찰
   각 변경의 callback과 응답 전달 증거 확인

6. 종료
   필요한 effect가 닫히면 완료
   대화만으로 충분하면 기존 DEF 경로로 즉시 종료

중요한 변화는 “항상 더 많이 실행한다”가 아니다. 현재 상태와 사용 가능한 기능을 근거로 최소한의 개입을 선택하고, 실제 수행한 것만 완료로 말하는 것이다.

8. 여러 Agent를 하나의 결과로 묶는 예

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

여기서 Experience는 ODL, FRG, DEF를 대체하지 않는다. 서로 다른 owner의 결과가 동일한 사용자 목표에 기여한다는 관계를 유지한다.

9. 프로젝트에 주는 의미

9.1 사용자 관점

• 기능명을 외우지 않고 결과를 말할 수 있다.
• 장시간 작업을 계속 지켜보거나 같은 말을 반복할 필요가 줄어든다.
• 실패했을 때 무엇이 끝났고 무엇이 남았는지 알 수 있다.
• 실행하지 않은 기능을 완료했다고 듣지 않는다.
• 취소와 확인이 필요한 시점을 예측할 수 있다.

9.2 제품 관점

• 음성 비서가 단순 command launcher에서 결과 위임형 companion으로 확장된다.
• 이동, 청정, 콘텐츠, 정보, 스케줄을 하나의 사용 장면으로 구성할 수 있다.
• 개별 기능 추가가 아니라 기능 간 관계와 시간 축이 제품 자산이 된다.
• 쇼케이스에서 “명령 여러 개를 실행했다”가 아니라 “상황을 이해하고 결과를 끝까지 책임졌다”는 메시지를 전달할 수 있다.

9.3 기술 관점

• Goal, Plan, Task, Response를 분리해 책임 경계를 유지한다.
• 기존 Planner와 TaskManager를 재작성하지 않고 sidecar 방식으로 확장한다.
• capability catalog 밖 행동과 증거 없는 완료를 차단한다.
• 정상 callback은 deterministic하게 처리해 토큰과 지연을 방어한다.
• 실패를 reason code와 semantic evidence로 연결해 재현성과 디버깅을 높인다.

9.4 QA·운영 관점

• 단순 명령 성공률 외에 Goal admission, effect grounding, terminal evidence를 검증할 수 있다.
• false admission과 legacy route 회귀를 별도 지표로 관리할 수 있다.
• Planner trace, TaskManager event, 사용자 응답을 동일 workflow ID로 추적할 수 있다.
• 제품에 열 수 있는 capability를 evidence 수준에 따라 단계적으로 승격할 수 있다.

10. Experience가 아닌 것

11. 현재 위치와 목표 상태

2026-08-05 기준으로 현재와 목표를 구분하면 다음과 같다.

현재 성과는 목표를 실제 실행 증거와 연결할 수 있는 backbone을 닫은 것이다. 아직 모든 Experience가 자율 실행 가능하다는 뜻은 아니다. live 범위는 capability별 증거가 닫힌 순서대로 확장해야 한다.

12. 성공을 어떻게 측정할 것인가

Experience의 성공은 “더 많은 행동을 만들었는가”가 아니라 다음 식으로 판단한다.

Experience quality
  = 목표 완결성
  + 현실 근거
  + 복구 가능성
  + 사용자 통제
  - 과승격
  - 거짓 완료
  - 불필요한 모델 호출

13. 문서 읽기 지도

이 문서를 공통 출발점으로 사용하고, 목적에 따라 아래 문서로 이동한다.

14. 발표용 최종 메시지

SK-Intellix의 A2A는 요청을 적절한 Agent에게 보내고, Context-Aware Planner는 실행 방법을 만들며, TaskManager는 현실의 실행을 책임진다. Experience Goal은 이 모든 계층 위에서 사용자가 위임한 결과가 사라지지 않게 한다.

그래서 시스템은 단순히 여러 기능을 연속 실행하는 것을 넘어, 왜 실행하는지, 무엇을 기다리는지, 언제 사용자가 개입해야 하는지, 어떤 증거로 끝났다고 말할지를 하나의 경험으로 관리할 수 있다.

관련 문서

• SK-Intellix Engineering Knowledge Hub
• SK-Intellix A2A Knowledge Hub
• A2A Before/After Impact Analysis
• Experience Runtime Validation Closure 2026-08-05