SK-Intellix Domain Reading Order
이 문서는 SK-Intellix 위키의 도메인 간 읽는 순서와 도메인 내부 문서 배열 규칙을 정의하는 기준점이다. 문서가 저장된 폴더 순서나 작성 날짜가 아니라, 독자가 이해하고 판단하는 논리 순서로 자료를 연결한다.
핵심 원칙
먼저 시스템이 왜 필요한지 이해하고, 다음으로 구조와 계약을 확인하며, 실제 소스와 증거를 본 뒤 운영·로드맵으로 끝낸다. 구현 기록이나 최신 테스트 결과를 개요보다 먼저 읽게 하지 않는다.
1. 왜 다시 정리했는가
기존 위키는 도메인 분류 자체는 갖추고 있었지만 다음 문제가 있었다.
- 일부 허브는 질문별 링크와 구현 문서가 한 표에 섞여 있었다.
- 일부 허브는 대표 문서만 연결해 실제 존재하는 자료가 노출되지 않았다.
- 최신 검증 보고서가 처음 읽는 문서보다 먼저 배치된 경우가 있었다.
- A2A와 TaskManager는 링크가 과밀했지만 On-device, Validation, Operations는 자료량에 비해 진입점이 빈약했다.
- SoundFlow/Audio와 Experience처럼 독립된 논리가 필요한 영역이 다른 도메인의 부속 자료처럼 보였다.
- URL 안정성을 위해
docs/a2a/에 남아 있는 문서의 논리 소유권이 화면에서 명확하지 않았다.
2026-08-05 감사 범위는 docs/a2a/와 docs/sk-intellix/의 Markdown 215개다.
파일을 이동하지 않고 허브와 읽기 순서를 다시 연결하는 방식으로 정리한다.
2. 모든 도메인에 적용하는 7단계
각 도메인 landing page는 아래 순서를 기본으로 사용한다.
| 단계 | 독자의 질문 | 문서 유형 |
|---|---|---|
0 · Orientation |
이 도메인은 무엇이고 어디까지 책임지는가? | category hub, executive overview |
1 · Why / Product |
왜 필요하고 AS-IS에서 무엇이 달라지는가? | PRD, before/after, rationale |
2 · Architecture |
구성요소와 책임 경계는 무엇인가? | system design, deep dive, diagram |
3 · Contract / Data |
어떤 입력·출력·상태·event가 오가는가? | API, schema, callback, data flow |
4 · Implementation |
실제 소스와 연결 지점은 어디인가? | source map, wiring, worklog |
5 · Validation |
무엇이 검증됐고 어떤 증거가 부족한가? | test plan, benchmark, audit, closure |
6 · Operations / Roadmap |
어떻게 운영·전달하고 다음에 무엇을 하는가? | runbook, vendor guide, backlog, roadmap |
모든 도메인이 일곱 단계를 억지로 채울 필요는 없다. 다만 문서가 존재한다면 이
순서대로 배치하고, 단계가 비어 있으면 자료 없음이 아니라 현재 공백으로
명시한다.
3. 전체 도메인 읽기 Spine
처음 접하는 독자는 다음 순서로 읽는다.
제품과 목표
-> 입력과 사용자
-> 판단과 계획
-> 연결과 실행
-> 플랫폼과 하드웨어
-> 검증과 전달
| 순서 | 도메인 | 핵심 질문 | 시작 문서 |
|---|---|---|---|
| 01 | CORE |
SK-Intellix는 무엇이며 전체 시스템은 어떻게 발전했는가? | Engineering Hub |
| 02 | SPEECH |
사용자 음성이 어떤 텍스트와 기능 후보가 되는가? | Speech Recognition Module |
| 03 | SPEAKER_IDENTITY |
누가 말했으며 어떤 권한·개인화를 적용할 수 있는가? | Speaker Identity Service |
| 04 | A2A |
누가 처리하고 무엇을 어떤 순서로 수행해야 하는가? | A2A Category |
| 05 | EXPERIENCE |
여러 단계 뒤에도 사용자의 상위 결과를 어떻게 보존하는가? | Experience Goal Category |
| 06 | ONDEVICE |
Cloud plan을 기기 계약으로 어떻게 변환하고 correlation을 유지하는가? | On-device Bridge |
| 07 | TASKMANAGER |
실제 task는 언제 시작·대기·완료·실패하는가? | DeviceAgent / SoC |
| 08 | FRAMEWORK_SDK |
제품 API와 service hub를 어떤 안정 계약으로 노출하는가? | Framework / SDK |
| 09 | AOSP_BSP |
그 계약이 Android image, HAL, driver에 어떻게 반영되는가? | AOSP / BSP |
| 10 | AUDIO |
실제 음향 입력과 SoundFlow/Kardome 품질은 어떻게 검증되는가? | Audio / SoundFlow |
| 11 | MEMORY |
대화·사용자 상태를 어떤 수명과 범위로 기억하는가? | Memory / Personalization |
| 12 | POC |
독립 실험과 도구를 제품 근거로 어떻게 전환하는가? | PoC Lab |
| 13 | VALIDATION |
설계·구현·실기기 증거를 어떻게 구분하고 판정하는가? | Validation / Quality |
| 14 | VENDOR |
외부 업체에 무엇을 설명하고 어떤 산출물을 받는가? | Vendor Handoff |
| 15 | OPERATIONS |
문서·콘솔·배포·운영 환경을 어떻게 유지하는가? | Operations |
이 순서는 조직도나 저장소 순서가 아니다. 한 사용자 발화가 물리 실행과 증거로 닫히는 순서이며, 필요한 경우 독자는 자신의 역할에 맞는 도메인부터 시작한다.
4. 역할별 빠른 진입
| 독자 | 먼저 읽기 | 다음 읽기 | 마지막 확인 |
|---|---|---|---|
| 의사결정자 / PM | Engineering Hub | Experience Goal, Architecture Rationale | Validation |
| Cloud Planner | A2A Category | Planner 구조·계약·Experience | benchmark와 runtime closure |
| On-device 개발자 | On-device Bridge | Contract/Data Flow | TTS lifecycle·APK release·E2E |
| DeviceAgent 개발자 | DeviceAgent / SoC | TaskManager 구조·lifecycle·API | executor closure·실기기 validation |
| Platform 개발자 | Framework / SDK | AOSP / BSP | boot·HAL·SELinux·release evidence |
| Speech / Audio 담당 | Speech | Audio / SoundFlow | E2E log·decoder·실기기 evidence |
| Identity / Memory 담당 | Speaker Identity | Memory | privacy·delete·traceability |
| QA / SQA | Validation | 도메인별 contract와 test plan | 실제 artifact와 release gate |
| 업체 / 협력사 | Vendor Handoff | 담당 도메인의 구조와 contract | acceptance·evidence template |
| 위키 운영자 | Operations | Document Finder | build·lint·sensitive scan·deploy |
5. 도메인별 내부 읽기 순서
5.1 A2A
Category
-> Product PRD / Before-After
-> System Overview
-> Planner / Semantic Boundary
-> Contract / Device Task Flow
-> Source / Scenario
-> Benchmark / Baseline
-> Backlog / Research
상세 링크는 A2A Category와 A2A Knowledge Hub에서 본다.
5.2 Experience
AS-IS / TO-BE
-> Usability
-> Existing Planner Integration
-> Workflow Foundations
-> Supervisor
-> Academic Deep Dive
-> Live Slice / Runtime Closure
Experience는 A2A의 새 route family가 아니라 여러 도메인의 결과를 보존하는 sidecar다. Experience Goal Category에서 경계를 확인한 뒤 Experience Goal AS-IS/TO-BE를 읽는다.
5.3 On-device Bridge
Category
-> End-to-End Data Flow
-> Contract Matrix
-> Device Task Flow
-> Callback Completion
-> Source Map
-> TTS Lifecycle / APK Release
-> Validation
상세 링크는 On-device Bridge에서 본다.
5.4 DeviceAgent / TaskManager
Category / Strategic Transition
-> Architecture / Design Policy
-> API / MQTT / AAR Contract
-> MainApi Insertion / Executor Wiring
-> Lifecycle / Scheduling / PUI
-> Closure Matrix / Audits / Live E2E
-> Monitor / Vendor Workbook / Roadmap
상세 링크는 DeviceAgent / SoC와 SoC TaskManager Framework에서 본다.
5.5 Framework / AOSP
Framework Hub
-> System Design
-> SDK Contract
-> TaskManager Integration
-> QCS6490 Platform Brief
-> QSSI / UM / HAL / Driver
-> Release Evidence
-> Transformation Roadmap
상세 링크는 Framework / SDK와 AOSP / BSP에서 본다.
5.6 Speech / Audio
Speech Category
-> Product Voice Architecture
-> On-device Source / Dictionary
-> Cloud Fallback / Rewrite
-> TTS / State Lifecycle
-> E2E Log Analysis
-> SoundFlow / Acoustic Evidence
-> Field Runbook / Vendor Request
상세 링크는 Speech Recognition Module과 Audio / SoundFlow에서 본다.
5.7 Identity / Memory
Identity Entry
-> Enrollment / Speaker Context Contract
-> Privacy / Authority
-> Memory Management
-> TaskManager Integration
-> Test / Evidence Audit
-> Service Roadmap
상세 링크는 Speaker Identity와 Memory / Personalization에서 본다.
5.8 Validation / Vendor / Operations
Validation Policy
-> Contract / Traceability
-> Unit / Benchmark
-> Integration / Real Device
-> Gap / Release Gate
-> Vendor Acceptance
-> Wiki Build / Publish
상세 링크는 Validation, Vendor, Operations에서 본다.
6. 문서 배치 규칙
새 문서나 기존 문서를 허브에 연결할 때 다음 규칙을 따른다.
Primary domain은 하나만 지정한다.- 파일 경로보다 문서의 책임과 독자 질문을 우선한다.
- 도메인 허브에서 반드시 7단계 중 하나에 배치한다.
- 최신 검증 보고서는 구조·계약 문서 뒤에 둔다.
- worklog는 구현 가이드보다 뒤에 둔다.
- roadmap은 현재 상태와 검증 공백을 설명한 뒤에 둔다.
- cross-domain 문서는 각 허브에 중복 링크할 수 있지만 primary owner는 하나다.
- 기존 공개 URL은 이동하지 않고 논리 링크만 고친다.
- 문서가 추가되면 coverage test와 Domain Document Map을 함께 갱신한다.
7. 문서 책임 구분
| 문서 | 책임 |
|---|---|
| Category Map | 어떤 도메인이 존재하는지 정의 |
| 현재 문서 | 도메인과 도메인 내부를 어떤 순서로 읽는지 정의 |
| Domain Document Map | 각 파일의 primary/related domain과 이동 후보 관리 |
| Document Finder | 검색어에서 적절한 도메인으로 진입 |
| Book Shelf | 전체 자료를 책의 장과 부록으로 구성 |
| Source and Evidence Catalog | 문서 주장과 repo/source/test 근거 연결 |
| Engineering Activity | 최근 변경과 검증 이력 확인 |
8. 완료 기준
정보구조 정리는 링크 수가 많다고 끝난 것이 아니다.
- 모든 대상 문서가 하나 이상의 도메인 허브 또는 하위 허브에 노출된다.
- 각 도메인에서 첫 문서와 최신 검증 문서가 구분된다.
- 제품·설계·구현·검증 문서가 논리 순서대로 배치된다.
- 도메인 간 이동 경로가 한 단계 안에서 제공된다.
- 링크와 실제 파일 존재를 자동 테스트한다.
- build, lint, sensitive scan, canonical URL 검증을 통과한다.