SK-Intellix Engineering Knowledge Hub
이 페이지는 SK-Intellix 전체 기술 자료의 최상위 진입점이다. A2A만 설명하는 페이지가 아니라 음성 입력, 사용자 context, Cloud 판단, 기기 실행, Android 플랫폼, 검증과 운영까지 연결한다.
MR7 모듈·기기 정책 상세 분석
모듈 환경 · 요소별 책임 · 51개 Manager · 정책 조건과 실행 경로 — quber/mr7 / 7695c9a8 기준, 확대 SVG 3장.
차기 모델 · OS와 원형 디스플레이
- 차세대 플랫폼 1안~3안 비교와 최종 권고 — Android·Linux ROS 분리 / 단일 칩 Linux·ROS / 단일 칩 Android·ROS의 장단점, 앱·마켓·운영·비용 판단.
- 원형 디스플레이 Android 포팅 상세 — 패널·논리 화면·시스템 UI·외부 앱 표시·인증 검토.
Android vs Linux·Qt — 장단점, 서비스 연동, 원형 디스플레이 포팅과 UX — Android 우선 권고와 Linux 전환 조건, Spotify 제품화 경로, 포팅·검증 책임.
처음이라면 여기서 시작
| 목적 | 시작 문서 | 얻는 것 |
|---|---|---|
| SoC 전체 모듈의 기존 구현 확인 | A1 SoC 전체 구조 — 1398d109 | 모든 앱·SDK·native 모듈과 실행 경로·소스 근거 |
| 전체 자료를 논리 순서로 읽기 | Domain Reading Order | 도메인 간 순서와 공통 7단계 문법 |
| 원하는 기술 영역부터 찾기 | Knowledge Category Map | 도메인별 책임과 대표 허브 |
| 프로젝트 단위로 찾기 | Project Portfolio | Platform, Audio, Voice, Agentic, Delivery 프로젝트 |
| 공개 가능한 기술 여정 보기 | 공개 AI 시스템 포트폴리오 | 문맥 기반 계획, 실행 생명주기, Experience Goal, 월드모델과 Framework/SDK 설계 |
| 파일명이나 키워드로 찾기 | Document Finder | 검색어와 primary domain 연결 |
| 최근 구현·검증 상태 확인 | Engineering Activity | 최신 기준선, 변경, 검증, 릴리즈 흐름 |
| SKIX SDK 장치 제어 리팩터링 확인 | SKIX Manager Main 장치 제어 리팩터링 분석 | main 이후 9개 커밋의 typed port·SDK Manager 전환, 잔존 경계와 실기기 검증 Gate |
| 부스터로보틱스 SDK 자체 검토 | 부스터로보틱스 SDK 검토 자료 | C++·Python SDK, Audio, DDS, Agent Framework와 지원 제약 |
| 자율주행·그리퍼 로봇의 모델 구성 검토 | 자율주행·그리퍼 로봇 모델 아키텍처 | 전문 지각·이동·조작 모델, ROS 2, Jetson Thor, 학습·검증·휴머노이드 확장 기준 |
| ONDEVICE 메모리 실기기 정밀 분석 | LMKD RSS 편차와 SWAP 3GB 분석 | 모델 로딩·native heap·DSP·zram 실측, 원인 후보와 해결방안 |
| E03 환경별 날짜별 발생 추이 확인 | E03 환경별 날짜별 발생 빈도 분석 | 검증·운영·개발 전체 E03 추이와 운영계 LMKD 상세 구간을 함께 비교 |
| SK_39 대기화면 v1.20.05 변경 확인 | SK_39 대기화면 테마 변경 요약 | Custom 발화·영문 명칭·Custom 불가 멀티턴과 지정 8행 재검증 기준 |
| SK_28 나이트모드 v1.20.05 변경 확인 | SK_28 나이트모드 변경 요약 | 기존 분기를 유지한 명령 2곳의 최소 수정과 테스트 결과 |
| 모바일에서 시작하는 보이스 프로필 개발 | 보이스 프로필 등록 제품 구현 기준서 | 스마트폰 trigger, A1 Registration App, OnDevice 등록·식별, Cloud Voice Sync/사용자 조회 기준 |
| A2A와 지식 검색의 실제 통합 방향 | A2A 지식 그래프·RAG 연동 설계 | 현재 구현, 네 처리 경로, 지식 그래프·RAG·계획 수립기의 책임과 단계별 도입 전략 |
| 화자·지식·개인화·실행의 미래 구조 | Experience Goal × Knowledge Graph | 메인 통합안 이후 다층 context와 지식 관계를 확장하는 목표 구조 |
| CPU STT + QNN 화자인식 최신 기기 판정 | QNN 화자 Companion 연동 및 실기기 검증 | 사용자 등록 시험 모드 준비 완료, CPU STT 약 6초, Genie 동시 상주는 CMA 차단 |
| CPU STT + QNN 화자인식 구현 상세 | CPU STT + QNN 화자인식 통합 구현 | feature 브랜치, hard join, 양자화 모델, release APK와 기기 Gate |
| 이전 PUI 화자 등록 PoC 확인 | PUI Launcher 화자 등록 Overlay 구현 설계 | 과거 PUI 진입 설계 근거. 최신 제품 진입점은 모바일 앱 전용 |
| 도메인 관계를 그림으로 보기 | Knowledge Graph | runtime spine과 문서 관계 |
모든 도메인은 다음 순서로 읽는다.
0 · 개요
-> 1 · 문제와 가치
-> 2 · 구조
-> 3 · 계약과 데이터
-> 4 · 구현과 소스
-> 5 · 검증과 증거
-> 6 · 운영과 로드맵
최신 테스트 보고서부터 읽지 않고, 먼저 책임과 계약을 이해한 뒤 증거를 확인한다.
왜 이 구조를 이 순서로 쌓는가
SK-Intellix의 목표는 LLM 기능을 많이 연결하는 데 있지 않다. 사용자의 자연어 목표가 현재 상태에 근거한 계획이 되고, Android와 기기에서 관리 가능한 행동으로 실행되며, 그 결과가 물리 완료 증거로 다시 판단 계층에 돌아오는 폐루프를 만드는 데 있다. 이것이 음성 비서에서 로보틱스 실행 시스템으로 진화하기 위한 최소 구조다.
Sense
-> Understand
-> Plan
-> Act
-> Observe
-> Adapt
| 구축 단계 | 먼저 해결하는 불확실성 | 이 단계에서 얻는 능력 | 로보틱스 관점의 의미 |
|---|---|---|---|
| Speech·Speaker·Context | 누가 무엇을 말했고 지금 상태가 어떤가 | 입력 품질, 사용자, 위치·배터리·공간·작업 상태를 근거로 판단 | 센서와 상태를 Planner-safe world snapshot으로 변환 |
| A2A Router·Semantic Planner | 누가 책임지고 어떤 순서로 수행할 것인가 | owner, skill, typed step, dependency, condition 생성 | 자연어 목표를 실행 가능한 capability plan으로 grounding |
| On-device Bridge | Cloud 계획을 어떻게 손실 없이 제품으로 전달할 것인가 | correlation, request/workflow 변환, local session 연결 | 판단 계층과 실시간 실행 계층의 계약 경계 |
| DeviceAgent TaskManager | 장기·복합 행동을 누가 안전하게 관리할 것인가 | queue, resource policy, timeout, cancel, executor, scheduling | 단순 함수 호출을 goal·feedback·result를 가진 action runtime으로 승격 |
| Domain·Framework·HAL | 실제 이동·청정·화면·센서를 누가 수행하는가 | 공통 capability가 Android service와 hardware까지 연결 | 계획이 물리 세계에 영향을 주는 embodiment 계층 |
| Callback·Evidence | 명령 수락과 실제 완료를 어떻게 구분하는가 | progress, reason, terminal event, physical predicate | 행동 결과가 다시 상태가 되는 closed-loop control |
| Experience Goal·Bounded Replan | 여러 단계 뒤에도 사용자 목적을 어떻게 유지하는가 | effect 관찰, 질문, 제한 재계획, 안전한 종료 | 한 번의 명령이 아니라 목표 중심의 적응 행동으로 확장 |
이 순서를 지키는 이유는 확률적 판단과 결정적 실행을 분리하기 위해서다. LLM은 목표와 의미를 해석하지만 모터·청정·도킹을 직접 제어하지 않는다. TaskManager는 의미를 새로 추론하지 않지만 policy, resource, lifecycle과 실제 완료를 소유한다. 정상 진행은 기기에서 이어가고, 실패·차단·정보 부족처럼 의미 판단이 다시 필요한 경계에서만 bounded replan을 사용한다.
이 구조가 주는 핵심 이점은 다음과 같다.
- 같은 이동·청정·화면·센서 capability를 음성, 앱, MQTT, 예약이 재사용한다.
- Cloud가 매 task event마다 LLM을 호출하지 않아 지연과 토큰 비용을 억제한다.
- 복합명령의 step, 의존관계, 대기 조건과 실패 이유를 관찰할 수 있다.
- 새 기능은 발화별 규칙이 아니라 catalog, contract, executor, evidence를 추가해 확장한다.
- 실기기 완료 증거가 있어야 성공으로 판정하므로 데모 성공과 제품 성공을 구분한다.
현재는 완성된 범용 로보틱스 middleware라고 주장하지 않는다. A2A owner·typed plan, 일부 device context, TaskManager queue·workflow·callback, Experience Goal의 제한적 admission은 기반으로 확보했다. 반면 capability별 terminal event, freshness가 보장된 world state, resource arbitration, pause/resume/preempt, 보상 동작과 장시간 실기기 반복 검증은 계속 닫아야 할 Gate다.
상세 근거는 Architecture Rationale, 실행 runtime은 DeviceAgent TaskManager 기준 사양서, 연구 프레임은 Planner Research Reading List, 실증 기준은 Validation에서 이어서 읽는다.
전체 도메인 지도
01 · 제품과 입력
| 도메인 | 먼저 볼 문서 | 책임 |
|---|---|---|
| Speech / STT | Speech Recognition Module · LLM 업무 목록과 역할·책임 · QNN 화자 Companion 실기기 검증 · CPU STT + QNN 화자인식 병렬 구현 | SenseVoice CPU STT, 기능 유지보수, 모델 학습·평가, MLOps, speaker embedding QNN HTP, fallback |
| Audio / SoundFlow | Audio and SoundFlow | processed PCM, AFE, Kardome, continuity, acoustic evidence |
| Speaker Identity | 보이스 프로필 등록 제품 구현 기준서 · Speaker Identity Service | 모바일 시작, A1 등록 UI, OnDevice Voice ID/Embedding, Cloud Registry, CPU 식별 |
Speech/NPU 전환 사전 의사결정은 Sherpa SenseVoice CPU → QNN HTP(v68) 전환 사전 분석에서 현재 모델, QCS6490/v68 호환성, 양자화 제약과 단계별 Gate를 확인한다.
보이스 프로필의 최신 제품 진입·등록·관리 기준은 보이스 프로필 등록 제품 구현 기준서에서 확인한다. 등록은 하이나무 앱 이벤트로만 시작하고 PUI 직접 진입은 제품 경로로 사용하지 않는다.
STT와 화자인식을 한 turn에서 함께 실행하는 구현 근거는
CPU STT + QNN 화자인식 병렬 실행 설계에서
SenseVoice CPU 유지, embedding QNN 이동, 결과 hard join, fallback, 통합 AAR,
latency·정확도 release gate를 확인한다. 이전 PUI와 setLauncherScreen 진입안은
PUI Launcher 화자 등록 연동 분석에서
과거 PoC 설계 근거로만 본다.
실제 별도 UID companion의 Binder/PFD 통과, 사용자 등록 시험 모드, Genie 동시 상주 CMA 차단 및 보드 변경 뒤 재활성화 Gate는 QNN 화자 Companion 연동 및 실기기 검증을 최신 기준으로 본다.
02 · 판단과 목표
| 도메인 | 먼저 볼 문서 | 책임 |
|---|---|---|
| Cloud A2A | A2A Category | route, owner, skill, typed plan, bounded replan |
| A2A × 지식 그래프·RAG · 중심 설계 | A2A 지식 그래프·RAG 연동 설계 | 현재 코드에서 가능한 검색·계획·실행 구조와 단계별 도입 기준 |
| Identity·Knowledge·Task · Extension | Experience Goal × Knowledge Graph | 화자·제품·환경·Memory context를 목표와 실행 증거에 연결하는 후속 구조 |
| Agent Engineering Strategy | 모델 진화 시대의 SKIX Agent Engineering 전략 | 모델 향상에 따라 줄일 scaffold와 유지할 제품 실행 책임 판정 |
| LLM Live | LLM Live | On-device/Cloud R&R, Gemini Live WebSocket, barge-in·세션 튜닝, 제품 명령 회귀 |
| Gemini Live Server 분석 | 서버 구성 · 2026-09-08 | Qwen·TTS 기본 배치, 기기 명령 왕복, 세션 정책, 운영 공백 |
| Experience Goal | Experience Goal Category | 상위 사용자 결과, effect, observation, 목표 연속성 |
| Memory / Personalization | Memory Category | pair, session, profile, sync, delete |
03 · 연결과 실행
| 도메인 | 먼저 볼 문서 | 책임 |
|---|---|---|
| On-device Bridge | On-device Bridge | Cloud 응답을 local task/workflow로 전달 |
| DeviceAgent / TaskManager | DeviceAgent / SoC · TaskManager 기준 사양서 | 대기열, 실행기, 콜백, 실패 사유, 완료 판정, 예약과 출시 검증 기준 |
| Framework / SDK | Framework and SDK | DeviceAgent API, peer agent, product framework |
04 · 플랫폼과 실험
| 도메인 | 먼저 볼 문서 | 책임 |
|---|---|---|
| AOSP / BSP / HAL | AOSP and BSP | image, vendor service, HAL, DTS, driver, sepolicy |
| PoC Lab | PoC Lab | 제품 병합 전 독립 실험과 evidence 후보 |
05 · 검증과 전달
| 도메인 | 먼저 볼 문서 | 책임 |
|---|---|---|
| Validation / Quality | Validation Category | baseline, benchmark, integration, real-device evidence |
| Vendor Handoff | Vendor Handoff | 업체 범위, API acceptance, 제출 evidence |
| Operations | Wiki and Codex Operations | build, lint, sensitive scan, Cloudflare release |
역할별 권장 경로
| 독자 | 읽는 순서 |
|---|---|
| 의사결정자 / PM | Engineering Hub → Architecture Rationale → Experience AS-IS/TO-BE → Validation |
| Cloud Planner 개발 | A2A → Planner Deep Dive → Contract → Benchmark |
| On-device 개발 | On-device Bridge → Data Flow → Source Map → Validation |
| DeviceAgent 개발 | DeviceAgent / SoC → TaskManager 기준 사양서 → TaskManager 이해 가이드 → API 계약 → 완료 계약표 |
| AOSP / HAL 업체 | Framework / SDK → AOSP / BSP → QCS6490 Vendor Brief → Vendor Handoff |
| Speech / Audio 담당 | 보이스 프로필 등록 제품 구현 기준서 → QNN 화자 Companion 실기기 검증 → CPU STT + QNN 화자인식 병렬 구현 → Speech → Audio / SoundFlow → Validation |
| QA / SQA | Validation → Requirements Traceability → 담당 도메인 계약 → 실기기 evidence |
| 위키 운영자 | Operations → Domain Reading Order → Document Map → 배포 |
한 번에 보는 Runtime Spine
사용자 음성 / 테스트 텍스트
-> Speech / STT
-> speaker · device · task · memory context
-> A2A owner / skill / typed steps
-> 필요한 경우 Experience goal sidecar
-> On-device Bridge
-> DeviceAgent TaskManager
-> domain executor / Android platform / hardware
-> callback · reason · semantic observation
-> continue / ask / bounded replan / complete
| 데이터 | 사실의 소유자 | 소비자 |
|---|---|---|
| recognized text | Speech / On-device Agent | A2A Router |
| device·task·memory·speaker context | 각 context provider | Planner |
| owner·skill·typed step | A2A Planner | Cloud runtime |
| goal·effect·observation 기준 | Experience sidecar | workflow state |
| task/workflow request | Cloud compiler / On-device Bridge | TaskManager |
| queue·실행 lifecycle | DeviceAgent TaskManager | executor, monitor |
| callback·reason·terminal evidence | DeviceAgent domain | workflow state, 제한 재판단 |
시스템 진화 로드맵
A2A Routing
-> Context-Aware
-> Semantic Planner
-> TaskManager Runtime
-> Experience Goal
| 단계 | 해결한 문제 | 새 능력 | 유지해야 하는 경계 |
|---|---|---|---|
| A2A Routing | 한 모델이 모든 요청을 직접 처리 | owner와 specialist 분리 | route 선택과 실제 실행 분리 |
| Context-Aware | 현재 기기·대화·사용자 상태를 모름 | planner-safe context 사용 | context는 action 권한이 아님 |
| Semantic Planner | 단일 intent로 복합 요청 보존 불가 | capability-grounded typed plan | Planner가 owner와 plan 소유 |
| TaskManager Runtime | Cloud가 장기 실행을 직접 관리할 수 없음 | queue, wait, timeout, callback | 실행 사실은 DeviceAgent 소유 |
| Experience Goal | 여러 단계 뒤 상위 목표가 소실됨 | effect, observation, goal continuity | 새 family나 두 번째 Planner가 아님 |
이 과정은 앞 계층을 교체하지 않는다. 각 단계가 이전 계층의 책임을 유지하면서 새로운 공백을 채운 누적 구조다.
경계를 섞지 않는 기준
| 연결 | 앞 계층 | 뒤 계층 |
|---|---|---|
| Audio → Speech | 신호와 acoustic evidence | 텍스트와 E2E 음성 처리 |
| Speech → A2A | recognized text와 입력 품질 | 의미 판단과 owner 선택 |
| Context → Planner | bounded fact, freshness, provenance | plan과 질문 결정 |
| Planner → On-device | typed plan과 request | transport와 local correlation |
| On-device → TaskManager | request 전달과 event relay | queue, executor, completion |
| TaskManager → Experience | callback 사실 | 목표 달성 의미와 제한 재판단 |
| DeviceAgent → AOSP/BSP | 제품 실행 API | platform service, HAL, hardware |
현재 위치와 증거
| 영역 | 현재 주장 가능한 것 | 남은 Gate |
|---|---|---|
| A2A Routing | family·owner·skill 분리와 회귀 측정 | holdout label policy 지속 관리 |
| Context-Aware | device·task·memory·speaker 일부 context 연결 | freshness, source, privacy, missing-field 계약 |
| Semantic Planner | catalog-grounded typed plan과 dependency | 전체 capability coverage와 반복 안정성 |
| TaskManager | MR6 queue·workflow·callback 핵심 경로 | capability별 terminal event, PUI cancel 반복 |
| Experience Goal | shadow admission과 제한 live slice | restricted/full-tier E2E, false admission, rollback |
최신 근거:
- Experience Runtime Validation Closure 2026-08-05
- Planner-TaskManager Validation and Token Ledger 2026-08-04
- A2A Baseline Readiness 2026-08-02
- A2A Success Criteria
- Source and Evidence Catalog
테스트와 관찰 도구
| 도구 | 확인하는 것 | 열기 |
|---|---|---|
| A2A Text Console | 입력, Planner 판단, step, device request, 응답 | A2A Text Console |
| TaskManager Monitor | queue, 현재 단계, callback, 완료·실패 | TaskManager Monitor |
| Validation Hub | 기준선, evidence level, 남은 gap | Validation Category |
| Document Finder | 도메인이나 문서명을 모를 때 탐색 | Document Finder |
전체 자료 탐색
- Domain Reading Order
- Knowledge Category Map
- Project Portfolio
- Engineering Activity
- Knowledge Graph
- Cross-Domain Integration Map
- Domain Document Map
- Source and Evidence Catalog
- SK-Intellix Book Shelf
- Wiki Structure Map
A2A 외 프로젝트
A2A 진화 로드맵과 직접 연결되지 않더라도 제품 기반을 구성하거나 독립적으로 검증 중인 프로젝트는 아래 shelf에서 관리한다.
| Shelf | 포함 프로젝트 | 열기 |
|---|---|---|
| Platform & Core | AOSP/BSP, QCS6490, Framework/SDK, DeviceAgent | Project Portfolio |
| Audio & Voice | Speech, SoundFlow/Kardome, audio continuity, PCM PoC | Project Portfolio |
| Identity & Personalization | Speaker Identity, memory, privacy | Project Portfolio |
| Delivery & Operations | validation, vendor handoff, training, wiki deployment | Project Portfolio |
| Personal Archive | 공개 가능한 개인 정리 문서 | 2026년 6월-7월 가계부 |
상단 Projects, Sessions, Graph는 각각 프로젝트 인덱스, 공개 가능한 세션
메타데이터, 인터랙티브 관계도로 연결된다. 이 페이지의 큐레이션은 해당 기능을
대체하지 않는다.