728x90
Research Deck
지식 자산화와 OKF
LLM-Wiki, Open Knowledge Format, RAG/GraphRAG, 지식경영, 메타데이터 표준을 연결한 심층 분석
조사일: 2026-07-18
사용 출처: 35개
한눈에 보는 지식 자산화
지식 자산화는 자료를 많이 넣는 일이 아니라, 원천과 답변 사이에 검증 가능한 편집 계층을 만드는 일이다.
- 원천 자료는 보존하고, LLM은 초안과 링크를 만든다.
- 사람은 출처, 권한, 최신성, 모순을 검토한다.
- 검증된 지식은 다음 답변과 자동화의 입력이 된다.
오늘의 질문
- 왜 지금 지식 자산화가 중요한가
- LLM-Wiki는 RAG와 무엇이 다른가
- OKF는 어떤 최소 포맷을 제안하는가
- 기존 표준과 연구 흐름에서 어디에 위치하는가
- 개인과 기업은 어떻게 다르게 시작하는가
- 조직은 어떤 아키텍처와 거버넌스로 시작해야 하는가
- 파일럿은 무엇을 측정해야 하는가
핵심 결론
지식 자산화의 승부처는 모델보다 포맷과 운영이다.
- 조직 지식은 카탈로그, 위키, 코드, 노트북, 사람의 기억에 흩어져 있다.
- LLM-Wiki는 원천과 답변 사이에 지속적으로 편집되는 지식 계층을 둔다.
- OKF는 이 지식 계층을 마크다운, YAML frontmatter, 링크로 교환 가능하게 만든다.
- 출처, 소유자, 최신성, 리뷰가 없으면 지식은 빠르게 오염된다.
문제는 컨텍스트 조립 비용이다
AI 에이전트가 막히는 지점은 대개 모델 지능이 아니라, 조직 맥락을 찾고 연결하는 비용이다.
- 데이터 정의는 카탈로그에 있다.
- 업무 규칙은 위키와 문서에 있다.
- 예외와 의도는 노트북, 코드 주석, 회의록, 사람의 기억에 남아 있다.
- 긴 컨텍스트 모델도 관련 정보가 중간에 묻히면 활용 성능이 흔들릴 수 있다.
RAG와 LLM-Wiki는 역할이 다르다
RAG
- 질문 시점에 관련 청크를 검색한다.
- 원문 근거를 빠르게 가져오는 데 강하다.
- 매번 같은 합성을 반복할 수 있다.
- 전역 질문과 모순 관리에는 별도 설계가 필요하다.
LLM-Wiki
- 소스가 들어올 때 지식을 편집한다.
- 요약, 링크, 엔티티, 모순 표시가 누적된다.
- 사람이 읽고 고칠 수 있는 마크다운 자산이 남는다.
- 운영 통제 없이는 드리프트와 오염이 생긴다.
LLM-Wiki의 기본 구조
Raw sources
기사, 논문, 회의록, 데이터 스키마를 불변 원천으로 보존한다.
The wiki
LLM이 요약, 엔티티, 비교, 모순, 교차참조 페이지를 갱신한다.
Schema / playbook
AGENTS.md나 CLAUDE.md 같은 규칙 파일이 구조, 인용, 린트 기준을 정한다.
LLM-Wiki 운영 루프
- Ingest | 새 소스를 읽고 관련 페이지를 갱신한다.
- Query | 위키를 탐색해 답변하고, 좋은 답변은 다시 지식으로 저장한다.
- Lint | 고아 페이지, 깨진 링크, 낡은 주장, 모순을 점검한다.
- Review | 도메인 owner가 사실성, 최신성, 권한을 승인한다.
- Reuse | 검증된 concept을 다음 답변, 분석, 자동화에서 재사용한다.
OKF는 최소 지식 단위를 정한다
---
type: BigQuery Table
title: Customer Orders
description: One row per completed customer order.
resource: canonical URI
tags: [sales, orders, revenue]
timestamp: 2026-05-28T14:30:00Z
---
# Schema
# Joins
# Examples
# CitationsOKF의 핵심 단위는 하나의 마크다운 파일인 Concept이고, 배포 단위는 concept들의 디렉터리 묶음인 Bundle이다.
OKF 문서의 실제 필드 계약
OKF의 상호운용성은 거대한 스키마가 아니라, 최소 필드와 관대한 consumer 규칙에서 나온다.
| 필드 | 상태 | 기술적 의미 |
|---|---|---|
type | required | concept의 종류를 나타내며, 소비자는 모르는 type도 깨지지 않고 처리해야 한다. |
title | optional | 사람에게 보이는 이름이다. 없으면 파일 경로나 concept id를 대체 표시할 수 있다. |
description | optional | 검색과 요약에 쓰이는 짧은 설명이다. |
resource | optional | BigQuery table, dashboard, API, 문서 같은 외부 canonical URI를 연결한다. |
tags | optional | 도메인, 제품, 민감도, 업무 맥락을 묶는 얕은 분류다. |
timestamp | optional | concept 갱신 또는 관측 시각으로 freshness 평가에 쓴다. |
| unknown keys | allowed | 도구별 확장을 위해 producer는 보존하고 consumer는 무시 가능해야 한다. |
출처: OKF SPEC
OKF Bundle은 폴더가 API가 된다
sales-knowledge/
index.md
log.md
datasets/orders_db.md
tables/orders.md
metrics/net_revenue.md
dashboards/executive_sales.md
policies/refund_policy.md- concept id는 보통 bundle 내부 경로에서
.md를 뺀 값으로 해석한다. index.md는 사람이 빠르게 읽는 진입점이며, 에이전트에는 progressive disclosure의 첫 페이지가 된다.log.md는 변경 이력, 관측, 리뷰 결정을 시간순으로 남긴다.- 링크는 단순 문서 링크가 아니라 concept 간 directed edge로 소비될 수 있다.
OKF Bundle에서 지식 그래프로
Bundle은 단순 문서 묶음이 아니라, 파일 경로와 링크를 이용해 그래프 인덱스로 바꿀 수 있는 교환 단위다.
Concept파일은 노드가 된다.- Markdown link와 wiki link는 edge 후보가 된다.
type,resource,tags는 필터와 facet이 된다.index.md는 탐색 시작점,log.md는 변경 이벤트가 된다.
OKF Concept 예시: BigQuery Table
---
type: BigQuery Table
title: sales.orders
description: Completed and refunded customer orders at line-item grain.
resource: bigquery://analytics.sales.orders
tags: [sales, revenue, finance-reviewed]
timestamp: 2026-07-18T09:00:00Z
owner: data-platform
freshness_sla: P1D
---
# Schema
- order_id: stable order key
- customer_id: joins to [[tables/customers]]
- net_amount: gross_amount - discounts - refunds
# Business Rules
- Exclude test orders where `is_test = true`.
- Refunds are negative rows, not updates to original order rows.
# Citations
- [[policies/revenue-recognition]]
- [[dashboards/executive_sales]]출처를 남긴 business rule이 있어야 에이전트가 “왜 이 쿼리가 맞는지”까지 설명할 수 있다.
Producer와 Consumer의 기술 계약
Producer
- YAML frontmatter를 보존한다.
- 알 수 없는 확장 필드를 삭제하지 않는다.
- concept id와 파일 경로를 안정적으로 유지한다.
- citation, source URI, review 상태를 누락하지 않는다.
- 생성된 요약과 원천 링크를 분리해 기록한다.
OKF가 일부러 하지 않는 것
OKF의 힘은 많은 것을 정하는 데 있지 않고, 도구 간 교환에 필요한 최소 표면만 정하는 데 있다.
- 고정 taxonomy를 정의하지 않는다.
- 저장소, 검색 엔진, 런타임, SDK를 강제하지 않는다.
- Avro, Protobuf, OpenAPI 같은 도메인 스키마를 대체하지 않는다.
- 기존 시스템 위에 사람이 이해하는 맥락과 에이전트 탐색성을 더한다.
출처: OKF SPEC
기존 표준과의 위치
OKF는 Semantic Web 계열 표준을 대체하기보다, 에이전트 친화적 작업 계층으로 해석하는 편이 안전하다.
| 계층 | 대표 표준/방식 | 역할 |
|---|---|---|
| 의미 그래프 | RDF, JSON-LD, DCAT | 웹 규모 상호운용성과 기계 추론 |
| 메타데이터 | Dublin Core, schema.org Dataset | 자원의 발견성과 설명 |
| 출처/계보 | W3C PROV-O | 생성 활동, 주체, 파생 관계 |
| 실행 명세 | OpenAPI, 데이터 스키마 | API와 데이터 구조의 공식 계약 |
| 작업 지식 | OKF | 사람이 읽고 에이전트가 탐색하는 지식 번들 |
OKF 필드를 기존 표준에 매핑하기
OKF는 표준 대체물이 아니라, 조직 내부 작업 지식을 표준으로 내보내기 쉬운 중간 표현으로 볼 수 있다.
| OKF 요소 | 가까운 표준 개념 | 매핑 의도 |
|---|---|---|
title | dcterms:title, schema:name | 사람이 읽는 표시명 |
description | dcterms:description, schema:description | 검색용 요약 설명 |
resource | dcat:accessURL, schema:url, OpenAPI server/path | 외부 canonical 자원 연결 |
timestamp | dcterms:modified, prov:generatedAtTime | 최신성, 생성/갱신 시각 |
tags | dcat:keyword, schema:keywords | 발견성과 필터링 |
| Markdown links | RDF triple 후보, prov:wasDerivedFrom 후보 | concept 관계와 계보 후보 |
log.md | PROV activity log | 변경, 승인, 파생 활동 기록 |
출처: Dublin Core, schema.org Dataset, DCAT, PROV-O, OpenAPI
GraphRAG와 RAPTOR는 소비자가 될 수 있다
- Source vault | 원천 문서, 논문, 스키마, 회의록을 보존한다.
- OKF bundle | 검토된 concept, link, citation, log를 제공한다.
- RAG index | 근거 청크와 concept을 함께 검색한다.
- GraphRAG / RAPTOR | 그래프 또는 계층 요약으로 전역 질문을 다룬다.
- Review loop | 가치 있는 답변을 다시 OKF concept으로 축적한다.
OKF는 검색 알고리즘이 아니라, 검색·그래프·요약 시스템이 읽을 수 있는 지식 패키지다.
Ingestion-to-Retrieval 파이프라인
기술적으로는 OKF repository가 검색 인덱스보다 앞단에 있는 검증 가능한 knowledge staging area가 된다.
- Ingest agent는 entity, citation, link, contradiction 후보를 만든다.
- Human review는 concept을 draft에서 approved로 승격한다.
- Vector index는 semantic recall을 담당한다.
- Graph index는 관계 질의와 전역 질문을 담당한다.
- Summary tree는 긴 문서군의 계층 요약과 drill-down을 담당한다.
출처: RAG paper, GraphRAG paper, RAPTOR, OKF SPEC
검색 방식별 구현 차이
OKF는 검색 알고리즘이 아니라, 검색 알고리즘이 소비할 수 있는 검증된 지식 표현이다.
| 방식 | 인덱스 객체 | Query-time 동작 | 강점 | 주요 실패 모드 |
|---|---|---|---|---|
| RAG | chunk embedding | 질문과 가까운 청크를 검색해 답변에 주입 | 빠른 근거 검색 | 전역 관계, 모순, 최신성 관리 약함 |
| GraphRAG | entity graph, community summary | 그래프 이웃과 커뮤니티 요약을 따라 답변 구성 | 전역 질문, 관계 설명 | 그래프 추출 품질에 민감 |
| RAPTOR | recursive summary tree | 계층 요약을 위에서 아래로 탐색 | 긴 corpus의 다층 요약 | 요약 드리프트와 근거 손실 |
| OKF + RAG | reviewed concept, citation, link | 승인된 concept를 우선 검색하고 원천으로 drill-down | 사람이 고칠 수 있는 지식 계층 | 운영/리뷰 없으면 지식 오염 |
출처: RAG paper, GraphRAG paper, Microsoft GraphRAG docs, RAPTOR, OKF SPEC
지식경영 관점의 의미
Socialization
회의, 고객 대화, 운영 경험에서 암묵지가 생긴다.
Externalization
LLM이 개념, 메트릭 정의, 의사결정, 플레이북으로 표현한다.
Combination
OKF의 링크, 인덱스, citation, schema가 명시지를 연결한다.
Internalization
에이전트 답변과 자동화가 다시 사람의 판단과 실행으로 들어온다.
Agent memory 연구와도 맞닿아 있다
- Memory stream | Generative Agents는 경험 기록, reflection, planning을 결합했다.
- Virtual context | MemGPT는 OS식 계층 메모리로 제한된 컨텍스트를 관리한다.
- Dynamic linking | A-MEM은 Zettelkasten식 링크와 memory evolution을 제안한다.
- Memory survey | agent memory는 저장, 조직화, 검색, 평가가 함께 필요한 영역이다.
LLM-Wiki에서 concept는 memory item, index/log/link는 memory organization, lint/review는 memory hygiene에 해당한다.
먼저 적용할 곳
- 데이터/분석 | 메트릭 정의, 테이블 스키마, 조인 경로, 대시보드 해석
- 연구/전략 | 논문, 경쟁사, 시장 리포트, 가설 변화 기록
- 제품/고객 | VOC, 인터뷰, 로드맵 결정, 실험 결과
- 운영/보안 | 런북, 사고 대응, 정책, 예외 승인
- 코드베이스 | 아키텍처 결정, 모듈 관계, 컨벤션, 세션 핸드오프
- 개인 지식 | 독서, 건강, 목표, 장기 프로젝트 노트
OKF 파일럿은 모든 문서를 바꾸는 일이 아니라, 재사용 가치가 큰 지식 자산을 고르는 일이다.
개인용과 기업용은 운영 강도가 다르다
개인용
- 목적: 기억 보강, 사고 확장, 장기 프로젝트 맥락 유지
- 단위: 독서 노트, 연구 메모, 건강/목표, 코드 세션 로그
- 승인: 본인이 곧 owner이자 reviewer
- 위험: 자기 확증, 오래된 결론, 프라이버시 노출
- 성공 기준: 다시 찾고, 연결하고, 다음 행동으로 이어지는가
기업용
- 목적: 공유 가능한 권위, 감사 가능성, 반복 업무 자동화
- 단위: 메트릭, 정책, 데이터셋, 고객/제품 지식, 런북
- 승인: domain owner, reviewer, 보안/법무 gate
- 위험: 권한 누출, 잘못된 권위, 조직적 지식 오염
- 성공 기준: 근거와 소유자가 있는 답변을 재사용하는가
개인용: 나만의 LLM-Wiki 사용처
- 독서/논문 | 핵심 주장, 반론, 연결 개념, 재사용 인용 정리
- 프로젝트 | 의사결정, 실험 로그, 막힌 지점, 다음 행동 저장
- 코드/학습 | 세션 핸드오프, 에러 패턴, 설계 이유, 명령어 기록
- 건강/생활 | 검진 기록, 루틴, 증상 변화, 질문 리스트 관리
- 커리어 | 성과 증거, 회고, 포트폴리오 소재, 면접 스토리 축적
- 관심사 조사 | 뉴스, 논문, 제품, 사람, 시장 신호를 topic별로 누적
개인용 지식 자산화의 핵심은 “완벽한 위키”가 아니라, 미래의 내가 다시 생각을 이어갈 수 있는 압축 맥락이다.
출처: Karpathy LLM Wiki, Hypomnema, Zettelkasten Method, A-MEM
개인용 Bundle 구조 예시
personal-knowledge/
index.md
log.md
reading/graph-rag.md
reading/okf-spec.md
projects/knowledge-assets-deck.md
decisions/2026-07-knowledge-format.md
health/questions-for-checkup.md
code/sessions/agent-docs-rendering.mdreading/은 원문 요약보다 내 질문과 재사용 가능한 인용을 중심으로 둔다.projects/는 목표, 결정, 실험, 다음 행동을 한 페이지에서 이어준다.decisions/는 왜 그렇게 판단했는지와 당시 근거를 남긴다.log.md는 하루 단위가 아니라 의미 있는 변경과 발견만 기록한다.
출처: Zettelkasten Method, A-MEM, OKF SPEC
개인용 운영 루프는 가볍게 유지한다
- Capture | 읽은 것, 들은 것, 떠오른 질문을 원천 링크와 함께 저장한다.
- Distill | LLM이 요약하되, 내 판단과 다음 질문을 별도 섹션으로 둔다.
- Link | 관련 프로젝트, 사람, 개념, 결정 페이지를 2-3개만 연결한다.
- Review | 주 1회 stale note와 열린 질문을 정리한다.
- Reuse | 글쓰기, 코딩, 의사결정, 상담 질문으로 다시 꺼낸다.
개인용은 리뷰 비용이 커지면 지속되지 않는다. 자동화보다 “다시 찾을 수 있는 리듬”이 먼저다.
출처: Karpathy LLM Wiki, MemGPT, A-MEM
기업용: 먼저 자산화할 지식
- 데이터 제품 | 메트릭 정의, 테이블 lineage, 조인 경로, 품질 이슈
- 고객/영업 | VOC, account context, 경쟁사 반응, 제안서 근거
- 제품/실험 | 로드맵 결정, 실험 결과, 릴리즈 노트, feature rationale
- 운영/보안 | 사고 런북, 정책 예외, 위험 승인, 감사 근거
- 연구/전략 | 시장 리포트, 논문, 특허, 경쟁 분석, 가설 변화
- 코드베이스 | 아키텍처 결정, 모듈 owner, API 계약, migration 상태
기업용은 “많이 모으기”보다 소유자와 권한이 분명하고 반복 답변에 쓰이는 지식부터 시작해야 한다.
출처: Google Cloud OKF Blog, Data Mesh Principles, DataHub AI-assisted data catalogs
기업용 Bundle 구조 예시
enterprise-knowledge/
index.md
log.md
metrics/net_revenue.md
datasets/orders.md
dashboards/sales_executive.md
policies/revenue_recognition.md
runbooks/data_incident.md
decisions/adr-042-metric-source-of-truth.mdmetrics/는 정의, 계산식, owner, 검증 쿼리, dashboard 연결을 포함한다.datasets/는 schema, freshness, lineage, ACL, 민감도 태그를 포함한다.policies/는 업무 규칙과 예외 승인 근거를 연결한다.decisions/는 현재 권위가 된 판단과 대체안을 함께 남긴다.
출처: OKF SPEC, DCAT, PROV-O, Data Mesh Principles
기업용 운영 모델은 role이 필요하다
기업용 지식 자산은 문서가 아니라 책임 경계가 있는 운영 객체다.
| 역할 | 책임 | 산출물 |
|---|---|---|
| Domain owner | concept의 업무 권위와 최신성 책임 | approved concept, review decision |
| Knowledge steward | 템플릿, 링크 품질, taxonomy 운영 | lint report, index policy |
| Security/Legal | 민감도, 보존, 외부 공유 제한 검토 | ACL rule, publish block |
| Platform team | ingest, search, graph, CI/CD 연결 | pipeline, index, monitor |
| Consumer team | RAG, 카탈로그, 문서 생성에서 재사용 | cited answer, workflow integration |
개인용에서 기업용으로 갈 때 바뀌는 것
성숙도는 도구 수가 아니라, 근거·소유자·권한·재사용 경로가 얼마나 명확한지로 올라간다.
| 단계 | 저장소 | 검증 | 소비 |
|---|---|---|---|
| Personal | 내 노트와 원천 링크 | 내가 읽고 고침 | 글쓰기, 학습, 회고 |
| Team | 공유 프로젝트 bundle | 동료 review와 PR | 팀 Q&A, 회의 준비, 온보딩 |
| Domain | owner가 있는 concept | SLA, lint, 승인 상태 | RAG, 카탈로그, dashboard 설명 |
| Enterprise | 권한과 감사가 있는 bundle | ACL, lineage, 보존 정책 | agent workflow, compliance, 자동화 |
선택 가이드: 어디서 시작할까
작게 시작하되, 소비 질문을 먼저 정하면 자산화 대상이 선명해진다.
| 상황 | 시작 bundle | 첫 성공 질문 | 주의점 |
|---|---|---|---|
| 개인 연구 | reading/, projects/ | “이 주제의 핵심 근거와 반론은?” | 요약만 쌓지 말고 내 판단을 남긴다. |
| 1인 개발 | code/sessions/, decisions/ | “지난번 왜 이 구조를 골랐지?” | 세션 로그가 실행 기록을 대체하지 않게 한다. |
| 팀 온보딩 | runbooks/, decisions/ | “새 팀원이 먼저 알아야 할 맥락은?” | 오래된 관행을 권위처럼 만들지 않는다. |
| 데이터 조직 | metrics/, datasets/ | “이 숫자의 정의와 근거 테이블은?” | ACL과 freshness를 처음부터 붙인다. |
| 전사 AI | policies/, products/, customers/ | “근거 있는 답변을 어디까지 자동화할 수 있나?” | publish gate와 audit log 없이 확대하지 않는다. |
권장 아키텍처
운영 가능한 지식 자산화는 원천 보존, 위키 합성, 표준 배포를 분리해야 한다.
- Source vault: 원천 자료는 변경 불가 또는 버전 고정으로 보존한다.
- Ingest agent: 요약, 엔티티, citation, 관계, 모순 후보를 생성한다.
- OKF repository: concept, index.md, log.md, Git review를 관리한다.
- Consumption layer: 검색, GraphRAG, 카탈로그, 문서 생성이 같은 번들을 읽는다.
- Governance layer: owner, freshness, 권한, 감사 로그를 적용한다.
출처: OKF SPEC, Knowledge Catalog repo, PROV-O, FAIR Principles
거버넌스 없이는 위키가 권위가 될 수 없다
LLM이 작성한 위키를 그대로 권위로 삼으면 지식 오염이 누적된다.
- 출처성: 본문 주장마다 citation 또는 원천 링크를 둔다.
- 소유권: concept별 owner와 reviewer를 둔다.
- 최신성: timestamp, stale 상태, freshness SLA를 둔다.
- 충돌 관리: 모순은 덮지 않고 별도 페이지나 issue로 분리한다.
- 권한 관리: 원천 자료의 민감도와 접근권한을 소비자까지 전파한다.
자동 린트 체크리스트
지식 저장소의 품질은 모델 평가만으로 유지되지 않는다. 저장소 자체의 린트와 리뷰가 필요하다.
| 체크 | 신호 | 자동 조치 | 사람 검토 |
|---|---|---|---|
| Broken link | [[...]] 대상 없음 | issue 생성, 배포 warning | owner가 삭제/수정/신규 concept 생성 |
| Stale timestamp | freshness SLA 초과 | stale badge, 검색 rank 하향 | 최신 원천 재검증 |
| Uncited claim | 주장 문장에 citation 없음 | PR comment 또는 lint fail | 근거 추가 또는 주장 삭제 |
| Orphan concept | inbound/outbound link 없음 | index 후보로 표시 | 유지/병합/삭제 결정 |
| Contradiction candidate | 유사 concept 간 상반 문장 | conflict page 생성 | authoritative source 선정 |
| ACL mismatch | 민감 원천에서 공개 bundle로 전파 | publish block | 보안/법무 승인 |
리스크는 운영 실패에서 더 자주 생긴다
LLM은 편집자이지 최종 권위가 아니다. 권위는 원천, 소유자, 리뷰 이력에서 나온다.
| 리스크 | 증상 | 완화책 |
|---|---|---|
| 합성 드리프트 | 요약 반복으로 원뜻이 흐려짐 | 원천 보존, citation, 정기 재검증 |
| 메모리 오염 | 틀린 문서가 다음 답변의 입력이 됨 | draft 격리, reviewer 승인 |
| 권한 누출 | 민감 지식이 넓게 배포됨 | bundle ACL, 민감도 태그 |
| 규모 폭증 | 페이지와 링크가 관리 부담을 키움 | index 정책, 고아 페이지 lint |
| 표준 과잉 | 기존 스키마를 억지로 대체 | OKF를 설명 계층으로 제한 |
평가 지표는 검색 정확도보다 넓어야 한다
Coverage
등록 비율
핵심 도메인 자산 중 OKF concept으로 등록된 비율
Provenance
근거 비율
citation이 있는 주장 비율
Freshness
최신성
SLA 안에서 갱신된 concept 비율
Conflict hygiene
충돌 처리
모순 후보 중 명시적으로 처리된 비율
Reuse
재사용
답변과 분석에서 참조된 concept 수
Human trust
신뢰
도메인 owner 승인 비율
지식 자산은 찾을 수 있고, 믿을 수 있고, 재사용되고, 갱신되어야 한다.
평가 데이터셋은 질문 유형으로 설계한다
질문을 기능별로 나누면 RAG 품질, 그래프 품질, 거버넌스 품질을 분리해 측정할 수 있다.
| 질문 유형 | 예시 | 기대 evidence | 지표 |
|---|---|---|---|
| Definition | “net revenue 정의가 뭐야?” | 승인 concept와 원천 citation | answer faithfulness, citation hit |
| Join path | “orders와 customers는 어떻게 조인해?” | table concept 간 link와 schema | path accuracy |
| Freshness | “이번 주 기준 최신 정책이야?” | timestamp, log, source modified time | freshness pass rate |
| Conflict | “두 문서의 환불 규칙이 달라?” | contradiction page 또는 issue | conflict detection recall |
| Global | “매출 대시보드가 왜 데이터와 달라?” | metric, dashboard, table, policy 연결 | multi-hop completeness |
| Permission | “민감 고객 필드를 보여줘도 돼?” | ACL tag, source sensitivity | policy compliance |
출처: RAG paper, GraphRAG paper, Lost in the Middle, FAIR Principles
90일 파일럿 로드맵
- 0-30일 | 도메인 1개, concept 30-50개, owner/reviewer, 민감도 정책 확정
- 31-60일 | 원천 수집, OKF 초안, citation, 링크, index/log, lint 워크플로
- 61-90일 | 검색/RAG/GraphRAG/카탈로그 연결, 실제 질문 20개로 평가
- 성공 기준 | 최신 정의와 근거를 3분 안에 재사용하고, 에이전트가 같은 concept을 참조
전사 표준화보다 작은 번들 하나를 끝까지 운영해 보는 것이 먼저다.
구현 백로그: 파일럿 산출물
파일럿은 플랫폼 구축이 아니라, 검증 가능한 지식 번들 하나를 운영 가능한 상태로 만드는 프로젝트다.
| 기간 | 산출물 | 기술 산출 | 완료 기준 |
|---|---|---|---|
| Week 1 | Source vault | 원천 URI, checksum, 민감도 태그 | 원천 50개 이상 등록 |
| Week 2 | OKF skeleton | index.md, log.md, type taxonomy 초안 | concept template 승인 |
| Week 3-4 | Ingest workflow | entity/link/citation 추출 PR | concept 30개, citation coverage 80% |
| Week 5 | Lint pipeline | broken link, stale, uncited claim check | PR에서 자동 실패/경고 |
| Week 6-7 | Retrieval integration | vector index, graph index, summary tree | 평가 질문 20개 실행 |
| Week 8-10 | Review operation | owner/reviewer SLA, issue flow | 승인 concept 20개 이상 |
| Week 11-12 | Consumption | 카탈로그/RAG/문서 생성 연결 | 실제 업무 답변 10건 재사용 |
출처 묶음 A: OKF와 LLM-Wiki
- Google Cloud OKF Blog | OKF의 문제의식, 설계 원칙, 예시
- OKF v0.1 SPEC | concept, bundle, frontmatter, link, index/log 규칙
- Google Knowledge Catalog repo | Knowledge Catalog와 샘플 구현 맥락
- Karpathy LLM Wiki | LLM-Wiki 패턴의 원문
- GeekNews LLM-Wiki 요약 | 한국어 요약과 커뮤니티 논점
- Hypomnema | LLM-native personal wiki 구현 사례
출처 묶음 B1: Retrieval과 GraphRAG
- RAG, Lewis et al. | 비모수 메모리를 결합한 지식 집약 NLP
- GraphRAG, Edge et al. | 전역 질문을 위한 그래프 기반 요약 접근
- Microsoft GraphRAG publications | GraphRAG 연구 흐름
- GraphRAG docs | 엔티티 그래프, 커뮤니티 요약, 검색 구조
- RAPTOR | 계층 요약 트리 기반 검색
출처 묶음 B2: Long Context와 Agent Memory
- Lost in the Middle | 긴 컨텍스트 활용 한계
- Generative Agents | 기억, reflection, planning 구조
- MemGPT | OS식 virtual context 관리
- LLM Agent Memory Survey | 에이전트 메모리 설계와 평가 개관
- A-MEM | Zettelkasten 기반 agentic memory
출처 묶음 C1: Knowledge Graph와 Linked Data
- Knowledge Graphs | 지식 그래프 개념, 스키마, 정체성, 맥락
- W3C RDF 1.1 | RDF 그래프와 데이터 모델
- W3C JSON-LD 1.1 | JSON 기반 Linked Data 직렬화
- W3C DCAT 3 | 데이터 카탈로그 상호운용성
- W3C PROV-O | 출처와 생성 활동 모델링
출처 묶음 C2: Metadata와 실행 명세
- Dublin Core Metadata Terms | 범용 메타데이터 속성
- schema.org Dataset | 데이터셋 구조화 설명
- Google Dataset structured data | 데이터셋 발견성 기준
- DCAT-US v3.0 | 공공 데이터 카탈로그 프로파일
- OpenAPI Specification | HTTP API의 기계 판독 명세
출처 묶음 D1: 지식경영과 정보 시스템 배경
- FAIR Principles | Findable, Accessible, Interoperable, Reusable 원칙
- SECI, Ba and Leadership | 암묵지와 명시지의 지식 창출 모델
- As We May Think | Memex와 연결된 지식 저장소 상상력
- Man-Computer Symbiosis | 인간-컴퓨터 협력 사고의 고전
- The Semantic Web | 기계가 의미를 읽는 웹의 비전
출처 묶음 D2: 데이터 제품과 리스크
- Data Mesh Principles | 도메인 소유권, 데이터 제품, 연합 거버넌스
- DataHub AI-assisted data catalogs | AI 기반 데이터 카탈로그의 맥락
- Zettelkasten Method | 연결 중심 개인 지식 관리
- AI model collapse | 생성물 재귀 사용의 품질 저하 위험
Deck Map
Markdown을 HTML 덱으로 렌더링하기 위한 페이지별 역할 지도
| 페이지 | 역할 | 밀도 | 검증 리스크 |
|---|---|---|---|
| 1-4 | 표지, 대표 이미지, 질문, 핵심 결론 | 낮음 | 메시지 선명도 |
| 5-8 | 문제, RAG/LLM-Wiki, 운영 루프 | 중간 | 개념 연결성 |
| 9-15 | OKF concept, 필드 계약, bundle, 예시, producer/consumer | 높음 | 코드/표 가독성 |
| 16-21 | 표준 매핑, GraphRAG/RAPTOR, ingestion-to-retrieval | 높음 | 이미지와 표 밀도 |
| 22-23 | 지식경영, agent memory, 적용 후보 | 중간 | 개념 반복 |
| 24-27 | 개인용 사용법, bundle 구조, 운영 루프 | 중간 | 사례 구체성 |
| 28-32 | 기업용 사용법, bundle 구조, role, 성숙도, 선택 가이드 | 높음 | 표 밀도 |
| 33-36 | 아키텍처, 거버넌스, 린트, 리스크 | 중간 | 이미지/표 균형 |
| 37-40 | 평가, 평가 데이터셋, 로드맵, 구현 백로그 | 높음 | 실행 항목 구체성 |
| 41 | 최종 권고 | 낮음 | dark 대비 |
| 42-49 | 출처 부록과 Deck Map | 중간 | 링크와 행 밀도 |
'관심있는 주제 > 탐구 노트' 카테고리의 다른 글
| 일정을 못 잡는 개발자를 위한 WBS 실전 가이드 (1) | 2026.07.25 |
|---|---|
| Ilya Sutskever가 추천했다고 알려진 30 Papers로 보는 AI의 큰 그림 (0) | 2026.07.12 |
| AI 기업 95%가 망한다는 말은 어디서 나왔을까: 살아남는 AI 기업의 조건 (1) | 2026.07.11 |