SK-Intellix Knowledge Category Map
이 문서는 SK-Intellix 위키의 지식 분류 기준을 정의한다. 핵심은 A2A가 최상위가 아니라 SK-Intellix 내부의 큰 카테고리 중 하나라는 점이다.
1. 최상위 분류 원칙
문서를 기능 이름이 아니라 책임 경계로 나눈다.
| 분류 기준 | 설명 |
|---|---|
| 제품/시스템 관점 | SK-Intellix 전체를 설명하는 최상위 개요 |
| Cloud 판단/계획 | A2A planner, router, runtime orchestration |
| 온디바이스 연결 | Cloud 응답을 기기 실행 요청으로 바꾸는 bridge |
| DeviceAgent/SoC 실행 | 실제 task queue, callback, reason, domain execution. SoC 실행 프레임워크화까지 이 분류 안에서 관리 |
| 메모리/개인화 | 이전 맥락, 사용자 특성, DB/sync/delete 정책 |
| 검증/품질 | benchmark, unit, dry-run, ADB, evidence |
| 업체 전달 | API 계약, 인수 기준, 제출 evidence, open question |
| 운영/위키 | llmwiki 저장소, 전역 Codex 규칙, build/lint/server |
2. 현재 카테고리
| 코드 | 카테고리 | 시작 문서 | 역할 |
|---|---|---|---|
INTELLIX |
전체 제품/엔지니어링 허브 | SK-Intellix Engineering Hub | 모든 자료의 최상위 목차 |
A2A |
Cloud A2A / Planner | A2A Category, A2A Hub | 발화를 route/plan/task로 바꾸는 Cloud 지능 계층 |
ONDEVICE |
On-device Bridge | On-device Bridge Category | Cloud와 실제 기기 사이 payload/token/task 연결 |
DEVICEAGENT |
DeviceAgent / SoC TaskManager | DeviceAgent / SoC Category, SoC TaskManager Framework | queue, workflow, callback, reason_code, 기기 domain 실행, multi-source ingress, 장기 프레임워크화 기준 |
MEMORY |
Memory / Personalization | Memory Category | pair/session/day/week/profile memory와 DB/sync |
VENDOR |
Vendor Handoff | Vendor Category | 업체 구현/검증/인수 기준 |
VALIDATION |
Validation / Evidence | Validation Category | 테스트, benchmark, evidence, gap audit |
OPERATIONS |
Wiki / Codex Operations | Operations Category | 전역 wiki root, Codex 창 간 공유, build/lint 운영 |
책처럼 읽는 전체 순서는 SK-Intellix Book Shelf를 기준으로 보고, 1차 책자 정리를 끊는 기준은 SK-Intellix Book First-Cut Gate를 기준으로 본다. 카테고리별 repo/source/test/evidence 연결은 SK-Intellix Source and Evidence Catalog를 기준으로 본다. 기존 docs/a2a/ 문서를 장기적으로 분리하는 기준은 SK-Intellix Document Migration Roadmap을 따른다.
3. 현재 파일 위치 정책
지금은 기존 문서가 docs/a2a/에 많이 남아 있다. 이건 실패가 아니라 URL 안정성을 위한 과도기 정책이다.
| 문서 상태 | 정책 |
|---|---|
| 이미 배포/공유된 A2A 문서 | 기존 URL 유지 |
| 새로 생기는 최상위 분류 문서 | docs/sk-intellix/에 작성 |
| 특정 도메인이 커지는 경우 | 이후 docs/ondevice/, docs/deviceagent/, docs/memory/, docs/vendor/로 단계 분리 |
| 기존 문서 이동 | 링크와 검증 비용을 감당할 수 있을 때만 수행 |
4. 분류 예시
| 문서 | 카테고리 | 이유 |
|---|---|---|
planner-routing.md |
A2A |
route family와 planner 판단 구조 |
device-task-flow.md |
A2A, ONDEVICE, DEVICEAGENT |
Cloud plan이 device task로 내려가는 교차 경계 |
contracts.md |
ONDEVICE 중심 |
Cloud/On-device/DeviceAgent payload 경계 |
deviceagent-taskmanager-api-contract.md |
DEVICEAGENT, VENDOR |
업체가 구현해야 할 TaskManager API |
soc-taskmanager-framework/ |
DEVICEAGENT, VENDOR |
Cloud LLM 전용이 아닌 SoC 실행 프레임워크 기준 |
memory-db-sync.md |
MEMORY |
DB schema, sync cursor, delete/retention |
vendor-test-evidence-template.md |
VENDOR, VALIDATION |
업체 제출 증거 양식 |
global-wiki-operations.md |
OPERATIONS |
wiki 저장/빌드/전역 Codex 운영 |
5. 작성 규칙
새 문서를 만들 때는 아래 중 하나를 먼저 고른다.
SK-Intellix 전체
A2A
On-device Bridge
DeviceAgent / SoC
Memory / Personalization
Vendor Handoff
Validation / Evidence
Operations
카테고리를 고른 뒤 문서 상단에 다음을 명확히 적는다.
이 문서는 어느 계층의 책임인가?
입력/출력/상태/이벤트가 무엇인가?
어느 repo/file/test가 근거인가?
완료로 보려면 어떤 evidence가 필요한가?