SK-Intellix Architecture Rationale and Benefits
이 문서는 SK-Intellix 위키에 정리된 주요 아이디어가 왜 필요했고, 구축하면 어떤 이점을 얻는지 설명한다.
구조도와 계약만 보면 “무엇을 만들 것인가”는 보이지만, “왜 이 방식이어야 하는가”와 “도입 효과가 무엇인가”가 약해질 수 있다. 이 문서는 그 배경과 이점을 고정한다.
1. 왜 이 문서가 필요한가
현재 SK-Intellix는 단순 음성 명령 처리에서 아래 방향으로 확장하고 있다.
단일 음성 명령
-> context-aware 판단
-> Agent/Skill 기반 계획
-> 복합제어
-> On-device / DeviceAgent TaskManager 실행
-> Memory / Personalization
-> 업체와 검증 가능한 계약
이 변화는 기능을 많이 붙이는 작업이 아니다. 사용자 발화, 현재 맥락, 기기 상태, 실행 결과, 실패 이유를 하나의 운영 구조로 묶는 작업이다.
2. 현재 구조가 필요해진 배경
| 배경 문제 | 기존 방식의 한계 | 필요한 변화 |
|---|---|---|
| Speech/STT 노이즈 | 짧거나 깨진 발화를 단순 family 분류로 처리하면 오분류가 많다. | STT_NULL/recoverability와 context-aware 판단이 필요하다. |
| 세션 맥락 단절 | 현재 발화만 보면 이전 질문, active workflow, pending slot을 잃는다. | voice_context, memory, workflow state를 함께 봐야 한다. |
| 복합명령 증가 | “A 하고 B 한 뒤 C 해줘”를 단일 action으로 처리하기 어렵다. | steps, depends_on, input_from, wait_policy가 필요하다. |
| Cloud가 모든 것을 판단하면 비용 증가 | task마다 LLM을 다시 부르면 지연/토큰/불안정성이 커진다. | 정상 workflow는 로컬에서 진행하고 예외만 Cloud replan한다. |
| DeviceAgent 조건 판단 우회 위험 | Cloud가 직접 native method를 호출하면 기존 안전 조건을 건너뛸 수 있다. | DeviceAgent TaskManager가 validation/policy/executor를 책임져야 한다. |
| 업체 전달 모호성 | “이렇게 구현해달라”는 말만으로는 API/event/reason/test 기준이 불명확하다. | contract, acceptance checklist, evidence template이 필요하다. |
| 장기 개인화 요구 | 매번 같은 선호/패턴을 새로 추론하면 경험이 불안정하다. | short/mid/long memory와 promotion policy가 필요하다. |
| proactive 확장 요구 | 사용자 발화가 없으면 planner가 깨어나지 않는다. | sensor/state/policy signal을 proactive turn으로 받아야 한다. |
3. Context-aware를 하면 무엇이 좋아지는가
Context-aware의 핵심은 “LLM에게 더 많은 정보를 주는 것”이 아니다. 현재 발화를 중심에 두고, 필요한 맥락만 보조 증거로 써서 오판을 줄이는 것이다.
| 이점 | 설명 | 예시 |
|---|---|---|
| 발화 복구율 증가 | 짧은 응답이나 slot fragment를 이전 workflow와 연결할 수 있다. | 사용자가 “내일”, “7시에”, “거실”만 말해도 active schedule/device workflow의 slot으로 해석 |
| STT_NULL 오판 감소 | 깨진 발화와 살아 있는 의도를 분리한다. | noisy text라도 public lookup/device target이 살아 있으면 통째로 버리지 않음 |
| follow-up 감소 | 이미 알고 있는 context를 다시 묻지 않는다. | 이전 턴에서 방/시간/작업 대상이 수집됐으면 재질문하지 않음 |
| 개인화 기반 응답 | 단기/중기/장기 memory를 통해 반복 선호를 반영한다. | 사용자가 자주 쓰는 방 이름, 선호 모드, 루틴 후보 활용 |
| 불가능한 plan 사전 차단 | device_context로 배터리/위치/queue/capability를 보고 처음부터 불가능한 실행을 줄인다. | 배터리 부족/지도 없음/이동 불가 상태면 실행 plan보다 clarification/reject |
| 복합명령 안정성 증가 | 이전 step 결과를 뒤 step에 명시적으로 연결한다. | input_from=step_1, depends_on=step_2로 cloud-only/mixed/device workflow 표현 |
4. A2A Planner를 쓰는 이유
Planner는 단순 selector가 아니다.
| 기존 selector 관점 | Planner 관점 |
|---|---|
| family 하나를 고른다. | 여러 step과 의존성을 만든다. |
| agent를 선택하면 끝난다. | agent/skill 실행 결과를 다음 step으로 넘긴다. |
| 복합명령을 쪼개기 어렵다. | steps[], depends_on, input_from으로 표현한다. |
| 실패 시 처리 경계가 흐리다. | event/replan gate로 정상 진행과 예외 판단을 나눈다. |
구축 이점:
- Cloud-only 작업과 device 작업을 같은 plan 구조로 표현할 수 있다.
- FRG -> FRG -> DEF 같은 순수 Cloud 작업도 표현 가능하다.
- ODL -> ODL -> ODL 같은 device 순차 실행도 표현 가능하다.
- FRG -> DEF -> ODL 같은 mixed workflow도 표현 가능하다.
- 후속 task/event가 들어왔을 때 어떤 step의 결과인지 trace할 수 있다.
5. Agent & Skills 구조의 이점
Agent/Skill 분리는 역할을 나누는 작업이다.
| Agent/Skill | 도입 이점 |
|---|---|
STT_NULL guard |
깨진 입력을 무리하게 실행하지 않는다. |
DEF |
일반 대화/요약/최종 응답 합성을 specialist와 분리한다. |
FRG |
외부 정보/추천/검색을 freshness-aware 경로로 보낸다. |
SCH |
알람/타이머/예약 workflow를 일반 대화와 분리한다. |
DQR |
제품/기기 설명과 실행 명령을 분리한다. |
ODL |
device action과 live state query를 온디바이스 실행 경로로 보낸다. |
UNS |
지원 불가 실행을 안전하게 종료한다. |
STM/ETR |
session-owning realtime mode를 일반 turn과 분리한다. |
구축 이점:
- prompt가 한 곳에서 모든 책임을 떠안지 않는다.
- family별 실패 원인을 분리해서 개선할 수 있다.
- agent runtime, benchmark, validation을 family별로 나눠 관리할 수 있다.
- 장기적으로 새로운 agent를 추가해도 전체 router 구조를 크게 흔들지 않는다.
6. 복합제어 구조의 이점
복합제어는 단순히 여러 명령을 한 번에 보내는 것이 아니다. 실행 순서와 결과 의존성을 명시하는 것이다.
| 필드 | 해결하는 문제 | 이점 |
|---|---|---|
depends_on |
물리적 순서가 필요한 실행 | 이전 step 완료 전 다음 step 실행 방지 |
input_from |
이전 결과를 다음 판단에 써야 하는 경우 | 검색 결과/상태 조회 결과를 다음 step에 명시 전달 |
execution_target |
Cloud와 device 실행 경계 혼동 | Cloud-only/device-only/mixed workflow 분리 |
wait_policy |
언제 다음 step으로 넘어갈지 모호함 | submitted/completed/event/user input 대기 기준 분리 |
예:
거실로 갔다가 안방으로 이동해서 청정해줘
이 발화는 아래처럼 바뀐다.
step_1: 거실 이동
step_2: 안방 이동, depends_on=step_1
step_3: 안방 청정, depends_on=step_2
이점:
- 이동 완료 전 청정을 시작하는 오류를 막는다.
- 중간 실패 시 어느 step에서 실패했는지 알 수 있다.
- Cloud가 정상 진행마다 LLM을 다시 돌리지 않아도 된다.
- UI/notification에 “현재 어떤 step 수행 중인지” 표시할 수 있다.
7. DeviceAgent TaskManager를 두는 이유
Cloud나 On-device Bridge가 직접 native function을 호출하면 빠르게 보일 수 있지만, 장기적으로는 위험하다.
| 직접 호출 방식의 문제 | TaskManager 방식의 이점 |
|---|---|
| 기존 DeviceAgent 조건 판단을 우회할 수 있다. | validation/policy/executor를 한 경로로 모은다. |
| Cloud/MQTT/App/예약 명령이 각자 다른 실행 경로를 만든다. | multi-source ingress를 공통 task/workflow API로 수용한다. |
| 실패 이유가 자연어/로그에 흩어진다. | reason_code, reason_params, requires_cloud_decision으로 구조화한다. |
| callback 기준이 불명확하다. | onTaskEvent로 상태와 trace field를 표준화한다. |
| 업체 인수 기준이 모호하다. | API, event, evidence 단위로 검증 가능하다. |
구축 이점:
- Cloud A2A뿐 아니라 MQTT server, app remote, local voice, schedule/internal policy까지 같은 실행 프레임워크를 쓸 수 있다.
- safety/policy/condition check가 중앙화된다.
- 실패/차단/일시중단 이벤트를 재계획 가능한 구조로 만들 수 있다.
- 업체 구현 범위와 테스트 증거를 명확히 요구할 수 있다.
8. Memory / Personalization의 이점
메모리는 단순 대화 저장소가 아니다. 다음 turn 판단을 안정화하는 context layer다.
| 계층 | 이점 |
|---|---|
| Short-term | 현재 session, active workflow, pending slot을 이어간다. |
| Mid-term | 하루/일주일 단위 반복 패턴과 최근 선호를 반영한다. |
| Long-term | 명시 확인된 선호/루틴/기기 사용 패턴을 유지한다. |
구축 이점:
- 같은 정보를 반복해서 묻지 않는다.
- 사용자의 반복 패턴을 기반으로 더 자연스러운 제안을 할 수 있다.
- 장기 profile과 일회성 context를 분리해 오염을 줄인다.
- 삭제/보존/민감정보 정책을 DB schema 수준에서 관리할 수 있다.
9. Vendor Handoff를 구조화하는 이점
업체에게 필요한 것은 설명이 아니라 구현 가능한 계약이다.
| 산출물 | 이점 |
|---|---|
| API contract | 어떤 method와 field를 구현해야 하는지 명확하다. |
| Reason contract | 실패/차단을 Cloud/앱/운영자가 해석 가능하다. |
| Acceptance checklist | 완료 판정 기준이 모호하지 않다. |
| Test evidence template | 업체 제출물이 재현 가능한 증거가 된다. |
| Open questions | 구현 전에 닫아야 할 결정을 추적한다. |
구축 이점:
- “다 구현했다”는 주장과 실제 동작 증거를 분리할 수 있다.
- Cloud/On-device/DeviceAgent 사이 payload 불일치를 조기에 잡는다.
- 업체 회의에서 설명이 아니라 체크리스트 기반으로 진행할 수 있다.
10. 검증 구조의 이점
검증은 마지막에 하는 일이 아니라 구조 설계의 일부다.
| Evidence level | 의미 | 이점 |
|---|---|---|
| L0 | 문서 설계 | 아이디어와 책임 경계를 공유 |
| L1 | source 연결 | 실제 구현 위치 확인 |
| L2 | build/lint/static scan | 문서와 site 생성 가능성 확인 |
| L3 | dry-run/unit fixture | 계약/로직의 기본 동작 확인 |
| L4 | integration test | On-device/DeviceAgent 연결 확인 |
| L5 | ADB/logcat/real-device artifact | 제품 동작 증명 |
구축 이점:
- “문서가 있음”과 “제품에서 동작함”을 구분한다.
- 다음 작업 우선순위를 evidence gap 기준으로 잡을 수 있다.
- 배포 전 민감정보 스캔과 curated stage로 공유 범위를 통제한다.
11. 전체적으로 얻게 되는 효과
이 구조를 구축하면 아래 효과를 얻는다.
| 효과 | 설명 |
|---|---|
| 판단 품질 향상 | 발화, context, device state, memory를 함께 보고 오분류를 줄인다. |
| 복합명령 처리 | 순차/의존/mixed workflow를 plan으로 표현한다. |
| 실행 안정성 | 실제 기기 실행은 DeviceAgent TaskManager의 policy와 condition 아래에서 진행한다. |
| 비용 절감 | 정상 task event마다 Cloud LLM을 다시 호출하지 않는다. |
| 장애 대응력 | 실패/차단/일시중단 reason을 구조화해 replan 가능하게 만든다. |
| 업체 협업성 | 구현 범위와 인수 기준을 API/event/evidence로 전달한다. |
| 운영 투명성 | source, test, artifact, gap이 문서와 연결된다. |
| 확장성 | Cloud A2A 외 MQTT/App/예약/로컬 음성 유입도 같은 execution framework로 확장할 수 있다. |
12. Reactive / Proactive를 함께 가져가는 이유
Reactive는 사용자가 명시적으로 말했을 때 정확히 반응하는 능력이고, proactive는 기기가 상태 변화를 감지하고 적절한 제안/확인/실행 후보를 만드는 능력이다.
| 구분 | Reactive만 있을 때 | Proactive까지 있을 때 |
|---|---|---|
| 사용자 경험 | 사용자가 먼저 알아차리고 말해야 한다. | 기기가 중요한 상태 변화를 먼저 제안할 수 있다. |
| 루틴 | 반복 명령을 매번 말해야 한다. | 반복 패턴을 recommendation/schedule 후보로 만들 수 있다. |
| 위험 대응 | 사용자가 모르면 대응이 늦다. | battery/air quality/anomaly 같은 signal을 조기 처리할 수 있다. |
| 메모리 학습 | 명령 결과 중심으로만 쌓인다. | 수락/거절 feedback이 preference policy로 돌아간다. |
자세한 운영 구조는 Reactive and Proactive Operation을 기준으로 본다.
13. 로보틱스로의 진화를 위한 설계 근거
13.1 목표는 LLM 자동화가 아니라 embodied closed loop다
로보틱스 관점에서 중요한 것은 자연어를 잘 생성하는 능력보다, 목표가 물리 행동으로 이어지고 그 결과가 다시 다음 판단의 근거가 되는가다.
사용자 목표 / 환경 변화
-> Sense: speech, speaker, sensor, device state
-> Understand: context와 capability로 의미 고정
-> Plan: typed step, dependency, condition
-> Act: TaskManager와 domain executor가 수행
-> Observe: progress, reason, terminal evidence
-> Adapt: continue, ask, bounded replan, complete
이 폐루프가 닫히지 않으면 A2A는 여러 LLM을 연결한 대화 시스템에 머문다. 반대로 물리 완료와 실패 이유가 다시 Planner와 Experience Goal에 돌아오면, 사용자 목표를 유지하면서 현실 상태에 맞게 행동을 조정하는 로봇 실행 시스템으로 발전할 수 있다.
13.2 적용한 기술 프레임
| 기술 프레임 | SK-Intellix 적용 | 설계 효과 |
|---|---|---|
| 계층적 계획 | A2A가 상위 목표와 typed step을 만들고 TaskManager가 실행 lifecycle을 소유 | LLM의 의미 추론과 실시간 실행을 분리 |
| Capability grounding | Planner는 catalog에 존재하는 skill·task method·조건만 계획 | 존재하지 않는 행동 생성과 발화별 rule 확장을 억제 |
| Sense-Plan-Act-Observe loop | device context를 읽고 plan을 실행한 뒤 callback을 다시 workflow state에 반영 | open-loop 명령 전달을 상태 기반 폐루프로 전환 |
| Goal·Feedback·Result·Cancel | TaskManager task/workflow/event/reason 계약 | 장기 실행을 단순 API return이 아닌 관리 대상 action으로 표현 |
| Event-driven orchestration | 정상 callback은 로컬 상태 전이, 의미 경계만 Cloud 판단 | 지연·토큰 비용·네트워크 의존성 감소 |
| Bounded replanning | 실패, 차단, 사용자 개입, effect 미달에만 제한 재판단 | 무한 재계획과 불필요한 LLM 호출 방지 |
| Android-aligned layering | Manager/API → DeviceAgent → TaskManager → domain → HAL/hardware | AOSP 자원과 제품 기능의 책임·보안·교체 경계 유지 |
| Evidence-driven validation | 명령 수락, task 완료, 물리 완료를 별도 evidence로 관리 | 데모 응답과 실제 제품 동작을 구분 |
이 프레임은 특정 대표 발화를 외우게 하는 방식이 아니다. 새 기능은
capability metadata -> typed contract -> executor -> terminal observation의
세로 경로를 완성해 추가한다. 따라서 같은 capability를 음성, 앱, MQTT,
스케줄, proactive trigger가 공유할 수 있다.
13.3 단계적으로 만드는 이유와 누적 이점
| 진화 단계 | 이전 단계의 한계 | 추가하는 구조 | 누적 이점 |
|---|---|---|---|
| Voice Command | 한 발화와 한 응답 중심 | family routing과 specialist | 책임 분리와 회귀 측정 |
| Context-Aware Agent | 현재 위치·작업·사용자 상태를 모름 | bounded context, freshness, provenance | 되묻기와 불가능한 계획 감소 |
| Semantic Planner | 단일 intent로 순서·조건을 보존하지 못함 | typed step, dependency, wait policy | 복합·조건부 목표 표현 |
| Managed Action Runtime | Cloud가 장기 실행과 자원 충돌을 직접 관리하기 어려움 | TaskManager queue, policy, resource, cancel | 안정적인 장기·복합 실행 |
| Closed-loop Robot | command ACK를 완료로 오인 | domain callback과 physical predicate | 실제 상태에 근거한 다음 행동 |
| Experience Supervisor | 각 workflow가 끝나면 상위 사용자 목적이 소실 | goal, effect, observation, bounded replan | 여러 기능을 목적 중심 경험으로 구성 |
앞 계층을 다음 계층으로 교체하지 않는 것이 중요하다. Context는 Planner의 근거지만 실행 권한이 아니고, Planner는 계획을 소유하지만 물리 상태의 source of truth가 아니다. TaskManager는 실행을 소유하지만 사용자 의도를 새로 해석하지 않는다. Experience Goal은 상위 목적을 유지하지만 두 번째 Planner나 새로운 route family가 아니다.
13.4 로보틱스 준비도를 주장하기 위한 Gate
| Gate | 성공 기준 | 부족할 때 발생하는 문제 |
|---|---|---|
| World state | 위치·도킹·배터리·공간·센서·active task에 freshness와 source가 있음 | 과거 위치를 현재 사실로 오인 |
| Capability model | input, precondition, side effect, resource, completion이 typed metadata로 정의됨 | 발화별 예외 규칙과 잘못된 기능 생성 |
| Managed execution | queue, timeout, cancel, pause/resume/preempt, conflict policy가 일관됨 | 복합 task 교착과 사용자 개입 유실 |
| Terminal evidence | capability별 물리 완료 predicate와 reason이 있음 | 명령 전송 성공을 작업 완료로 오인 |
| Bounded adaptation | 재계획 trigger, 횟수, 비용, 안전 범위가 제한됨 | 토큰 폭증, 반복 실행, 예측 불가능성 |
| Compensation | 중간 실패 시 stop, return, rollback, ask 중 안전한 수렴 정책이 있음 | 부분 실행 후 위험 상태 방치 |
| Real-device proof | 정상·실패·취소·PUI 개입을 반복한 로그와 artifact가 있음 | fixture 성공을 제품 성공으로 오인 |
현재 SK-Intellix는 로보틱스 실행 backbone을 구축 중인 단계로 표현하는 것이 정확하다. Planner와 TaskManager의 책임 분리, typed workflow, 일부 callback 폐루프는 확보했지만, 모든 capability의 물리 완료와 자원 충돌, 장시간 자율 수행을 일반화한 상태는 아니다. 그러므로 로드맵의 완료 판정은 문서나 빌드가 아니라 capability별 실기기 evidence로 닫는다.
14. 관련 문서
- SK-Intellix Wiki Structure Map
- SK-Intellix Book Shelf
- SK-Intellix Book First-Cut Gate
- Reactive and Proactive Operation
- Speech-LLM Context-Aware A2A Architecture
- A2A Planner and Routing
- Cloud·On-device·TaskManager Closed Loop
- Planner Research Reading List
- DeviceAgent TaskManager 기준 사양서
- DeviceAgent Capability Composition Guide
- DeviceAgent / SoC Category
- Source and Evidence Catalog