OpenKB: 문서를 "검색하는 AI" 에서 "이해하는 Wiki"로
AI에게 문서를 주는 방식은 두 가지입니다. RAG는 질문할 때마다 문서를 처음부터 다시 읽습니다. 비용은 쌓이고, 지식은 남지 않습니다. OpenKB는 문서를 한 번 이해해서 Wiki로 만듭니다. 쓸수록 지식이 연결되고 축적됩니다. 벡터DB 없이 동작하고, 결과물은 Obsidian에서 바로 열립니다. 사내 문서를 AI와 함께 자산으로 만들고 싶다면, 이 글이 출발점입니다.
AI가 문서를 다루는 방식에 근본적인 변화가 시작됐습니다. 검색할 때마다 LLM이 문서를 다시 해석하는 전통적 RAG와, 문서를 한 번 컴파일해 영구적인 위키 지식베이스로 구조화하는 OpenKB — 둘 다 AI 기반 문서 처리 도구지만 설계 철학이 근본적으로 다릅니다.
1. OpenKB란?
OpenKB는 VectifyAI가 개발한 오픈소스 지식베이스 컴파일러입니다. 핵심 철학은 단순합니다:
"문서를 매번 재해석하지 말고, 한 번 이해해서 위키로 만들어라"
전통적인 RAG는 질문을 받을 때마다 문서를 검색하고 LLM이 실시간으로 답을 합성합니다. OpenKB는 반대로 접근합니다 — 문서 처리를 오프라인 컴파일 단계에서 먼저 완료하고, 질의 시점에는 이미 구조화된 위키에서 정보를 제공합니다.
2. 왜 RAG만으로는 부족한가?
✅ 매번 재합성하는 비용과 불일관성
전통적 RAG는 동일한 문서에 동일한 질문을 해도 매번 LLM이 새로 합성합니다. 토큰 비용은 계속 쌓이고, 답변 품질은 프롬프트와 컨텍스트 길이에 따라 달라집니다.
OpenKB는 컴파일을 한 번만 수행합니다. 이후 조회는 이미 생성된 위키 페이지를 읽는 것이기 때문에 비용이 선형적으로 증가하지 않습니다.
✅ 문서 간 관계가 사라지는 RAG의 맹점
청크(chunk) 기반 RAG는 문서를 조각냅니다. 이 조각들은 원래 문서의 맥락, 다른 문서와의 관계, 개념 간 연결고리를 잃어버립니다.
OpenKB의 PageIndex는 문서를 트리 구조로 인덱싱하여 벡터 없이도 논리적 계층과 참조 관계를 보존합니다. 컴파일된 위키는 자동으로 크로스레퍼런스를 생성하여 문서 간 지식망을 구성합니다.
✅ 쌓이지 않는 RAG 지식
RAG는 쿼리 단위로 소비됩니다 — 문서가 추가돼도 기존 지식은 재구성되지 않습니다. OpenKB는 새 문서가 추가되면 기존 위키에 통합·업데이트됩니다. 오래 운영할수록 지식이 축적되고 연결됩니다.
3. 내부 구조: OpenKB는 어떻게 동작하는가?
🎯 핵심 아키텍처 구성요소
-
PageIndex (벡터리스 문서 인덱싱): VectifyAI가 개발한 독자적인 인덱싱 기술로, OpenKB가 내부적으로 직접 호출합니다. OpenKB는 워크플로우 오케스트레이터이고, 실제 문서 이해는 PageIndex 패키지가 담당하는 구조입니다.
openkb add ./documents └─ indexer.py └─ PageIndexClient.add() ← pageindex 패키지 직접 호출 └─ JSON 트리 구성 → wiki 컴파일문서를 청크로 자르는 대신 목차(ToC)를 JSON 트리로 구성하고, LLM이 직접 추론하며 관련 노드를 탐색합니다. 벡터DB와 임베딩이 불필요하며, FinanceBench에서 98.7% 정확도를 기록해 벡터 RAG 대비 전문 문서 분석에서 높은 성능을 보였습니다. (논문: arxiv 2511.18177)
중요한 점은 원본 문서에 목차가 없어도 동작한다는 것입니다. 헤딩이나 구조가 없는 회의록, 평문 텍스트, 스캔 PDF도 LLM이 내용을 읽고 의미 기반으로 계층 트리를 직접 생성합니다. "목차를 읽는 것"이 아니라 **"목차를 만드는 것"**이 PageIndex의 핵심 역할입니다.
챕터 1 ├─ 섹션 1.1 ← LLM이 "이 노드가 질문과 관련 있나?" 추론 │ └─ 서브섹션 1.1.1 └─ 섹션 1.2 챕터 2 └─ ... -
Universal Format Converter (markitdown): PDF, Word, PowerPoint, Excel, HTML, 마크다운 — 포맷에 관계없이 단일 파이프라인으로 처리합니다. 이미지·표·차트의 멀티모달 처리도 포함됩니다.
-
Wiki Compiler: 문서를 소비해 개념 페이지, 요약, 크로스레퍼런스를 자동 생성합니다. 결과물은 순수 마크다운으로 저장되어 Obsidian 등 모든 마크다운 뷰어에서 바로 열립니다.
-
Health Check 레이어: 컴파일된 위키에서 모순(contradiction)과 정보 공백(gap)을 자동으로 식별합니다. 지식베이스의 품질을 지속적으로 모니터링합니다.
-
Multi-turn Chat: 컴파일된 위키 위에서 멀티턴 대화를 제공합니다. 세션을 재개(resumable)할 수 있어 이전 대화 맥락이 유지됩니다.
-
Watch Mode: 지정 폴더를 감시하다가 새 파일이 추가되면 자동으로 컴파일을 트리거합니다. 파일이 드롭되는 순간 위키가 업데이트됩니다.
4. 직접 해보기 (5분 시작 가이드)
1) 설치
pipx를 사용하면 PATH 충돌 없이 깔끔하게 설치됩니다:
brew install pipx
pipx install openkb
2) 환경변수 설정
OpenKB는 LiteLLM을 통해 모든 LLM 프로바이더를 지원합니다:
export OPENAI_API_KEY="sk-..."
# Anthropic, Azure, 로컬 Ollama 모두 가능
3) KB 초기화
작업 폴더를 만들고 KB를 초기화합니다:
mkdir my-kb && cd my-kb
openkb init
초기화가 완료되면 아래 구조가 생성됩니다:
my-kb/
├── raw/ # 원본 문서를 여기에 넣으면 자동 감지
├── wiki/
│ ├── index.md # 지식베이스 전체 개요
│ ├── log.md # 컴파일 작업 이력
│ ├── AGENTS.md # Wiki 스키마 & LLM 지침
│ ├── sources/ # 문서별 전문 변환 결과
│ ├── summaries/ # 문서별 요약
│ └── concepts/ # 문서 간 교차 합성 개념 페이지
└── .openkb/
├── config.yaml # 모델·언어 등 설정
└── chats/ # 멀티턴 대화 세션 저장
초기화 후 .openkb/config.yaml에서 출력 언어를 지정할 수 있습니다. 기본값은 영어(en)이므로 한국어 문서를 다룬다면 반드시 변경합니다:
# .openkb/config.yaml
language: ko # en(영어) → ko(한국어), ja, zh 등 지정 가능
model: anthropic/claude-sonnet-4-6
pageindex_threshold: 20
4) 문서 추가 & 컴파일
openkb add ~/documents
폴더 안의 PDF, Word, PPT 등을 자동으로 위키로 컴파일합니다.
5) 질문 & 채팅
openkb query "덱의 핵심 메시지는?" # 단일 질문
openkb chat # 멀티턴 대화
openkb chat --resume # 이전 세션 이어서
6) Watch Mode (자동 업데이트)
openkb watch
raw/ 폴더에 새 파일을 드롭하면 자동으로 위키가 업데이트됩니다.
5. Obsidian 연동: 지식그래프로 시각화
OpenKB의 출력은 순수 마크다운과 [[위키링크]] 형식입니다. Obsidian Graph View에서 즉시 열 수 있습니다.
회사 문서 수백 개를 컴파일하면 개념들이 어떻게 연결되어 있는지 그래프로 한눈에 볼 수 있습니다. RAG 시스템에서는 얻을 수 없는 지식 구조의 시각화입니다.
그래프 노드 키워드 추가하기
기본 컴파일은 문서의 주요 개념 중심으로 노드를 생성합니다. 인물명·고유명사 등 세부 키워드를 그래프에 추가하려면 아래 두 가지 방법을 사용합니다.
방법 1) pageindex_threshold 낮추기
.openkb/config.yaml에서 임계값을 낮추면 더 세밀한 단위로 노드가 생성됩니다:
pageindex_threshold: 5 # 기본값 20 → 낮출수록 더 많은 노드 생성
수치를 낮출수록 컴파일 시간과 LLM 비용이 증가하므로 적절한 균형이 필요합니다.
방법 2) 수동으로 wikilink 추가
wiki/summaries/ 내 파일에 직접 [[키워드]] 형식으로 링크를 삽입합니다:
<!-- wiki/summaries/문서명.md -->
[[홍길동]]이 제안한 전략은 ...
해당 키워드의 개념 페이지도 함께 생성하면 그래프에 연결 노드로 표시됩니다:
echo "# 홍길동" > wiki/concepts/홍길동.md
단, openkb add를 다시 실행하면 수동 편집 내용이 덮어써질 수 있으므로 Watch Mode 사용 시 주의가 필요합니다.
방법 3) GLiNER로 자동 추출 후 주입 (가장 체계적)
GLiNER는 경량 NER(Named Entity Recognition) 모델로, 문서에서 인물·조직·기술·지역 등의 고유명사를 자동으로 추출합니다. 이를 OpenKB 위키에 주입하는 스크립트를 만들면 수동 작업 없이 그래프 노드를 보강할 수 있습니다.
# GLiNER 설치
pip install gliner
동작 흐름:
wiki/summaries/*.md
└─ GLiNER (urchade/gliner_multi-v2.1)
└─ 엔티티 추출 (person / org / technology / location)
└─ 한국어 조사 제거 + 기술 접미어 정규화
└─ [[concepts/slug|엔티티명]] wikilink 자동 주입
└─ concepts/slug.md stub 파일 생성
실제 적용 결과, 회의록 요약에서 아래 엔티티가 자동으로 추출되어 그래프 노드로 추가됐습니다:
| 분류 | 추출된 엔티티 |
|---|---|
| 인물 | 매튜 섹스테드, Matthew Shacksted |
| 조직 | Tesoro/Accelerator, Parallel Works, NASA, DARPA, 국방부, 미국 정부 |
| 기술 | Hadoop, Nvidia, RK2, RKE2, Kubernetes, SUSE, AWS |
| 지역 | 라스베이거스, 애리조나 대학교, University of Arizona |
주의할 점은 한국어 조사(은/는/이/가/에서 등)가 엔티티에 붙어 추출되는 경우가 있어, 후처리 정규화가 필요합니다. 또한 기반, 플랫폼, 서비스 같은 기술 접미어도 함께 제거해야 깔끔한 노드 이름이 만들어집니다.
6. Wikilink vs. Graph DB
실습을 마쳤다면 한 가지 질문이 생길 수 있습니다 — "이게 Graph DB랑 뭐가 다른가?"
Obsidian의 wikilink 그래프와 Neo4j 같은 Graph DB는 둘 다 "그래프"지만 목적이 근본적으로 다릅니다.
| 항목 | Wikilink (Obsidian) | Graph DB (Neo4j 등) |
|---|---|---|
| 저장 | 파일시스템 마크다운 | 전용 그래프 엔진 |
| 관계 표현 | [[링크]] — 방향·타입 없음 |
(A)-[:관계타입]->(B) — 방향·타입 명시 |
| 쿼리 | 없음 (검색만) | Cypher/Gremlin로 복잡한 패턴 탐색 |
| 추론 | 불가 | "A와 2단계 이내로 연결된 모든 조직" 쿼리 가능 |
| 엣지 속성 | 불가 | 가중치·날짜·신뢰도 등 속성 부여 가능 |
| 규모 | 수천 노드 수준 | 수억 노드·엣지 처리 가능 |
| 사람 친화성 | 높음 (마크다운 그대로) | 낮음 (스키마 설계 필요) |
Wikilink = 사람이 탐색하는 지식 지도, Graph DB = 기계가 추론하는 관계 데이터베이스.
OpenKB + Obsidian은 문서를 빠르게 구조화해서 사람이 탐색하는 용도에 적합합니다. 관계 패턴을 쿼리해서 인사이트를 자동 도출해야 하는 단계가 되면 Graph DB로의 마이그레이션이 자연스러운 다음 단계입니다.
실무에서 어떤 차이가 생기나?
영업·지식 관리 실무를 기준으로 비교하면 차이가 명확해집니다.
Wikilink의 한계
[[삼성SDS]]링크를 걸어도 "삼성SDS와 연결된 모든 파트너사"를 쿼리할 수 없음- 관계 타입 없음 → 경쟁사인지, 파트너인지, 협력사인지 구분 불가
- 수천 노드를 넘으면 "이 고객을 참조하는 모든 문서"도 느려지기 시작
Graph DB가 가능한 것
(삼성SDS)-[:경쟁사]->(쿠버네티스벤더)— 제안서 작성 시 경쟁 구도 자동 파악- "이 고객사와 2단계 이내 레퍼런스 있는 영업담당자 추천" 같은 쿼리 가능
- 가중치·날짜·신뢰도 등 엣지 속성 부여로 관계의 질 표현 가능
언제 전환을 고려하나?
| 상황 | 적합한 도구 |
|---|---|
| 팀 10인 이하, 문서 수백 건 | Wikilink (OpenKB) |
| 파이프라인·고객 수백 건 이상, 관계 기반 인사이트 필수 | Graph DB |
Graph DB는 스키마 설계·운영 비용이 발생하므로 관계 기반 쿼리가 핵심 업무가 될 시점에 전환하는 것이 적합합니다.
7. RAG vs. OpenKB: 핵심 비교
| 항목 | 전통적 RAG | OpenKB |
|---|---|---|
| 처리 시점 | 쿼리 시 실시간 합성 | 컴파일 단계에서 사전 처리 |
| 지식 구조 | 청크 (파편화된 조각) | 위키 (연결된 지식망) |
| 문서 간 관계 | 청크 단위, 관계 손실 | 자동 크로스레퍼런스 |
| 쿼리 비용 | 매 쿼리마다 LLM 토큰 소비 | 컴파일된 위키 조회 |
| 지식 축적 | 쿼리 후 휘발 | 문서 추가 시 위키에 통합 |
| 벡터DB | 임베딩·벡터DB 필요 | PageIndex (벡터리스) |
| 출력 형식 | LLM 생성 텍스트 | 순수 마크다운 (Obsidian 호환) |
| 품질 검증 | 없음 | 내장 Health Check |
한 줄 요약: RAG = 문서에서 검색해 답하는 AI, OpenKB = 문서를 이해해서 위키를 만드는 AI.
8. 한계: 대규모 문서에는 아직 적합하지 않다
OpenKB는 현재 컴파일 결과를 파일시스템 마크다운으로만 저장합니다. DB나 전용 인덱스 백엔드가 없습니다.
| 규모 | 적합 여부 |
|---|---|
| 수백~수천 문서 | ✅ 적합 |
| 수만 문서 | ⚠️ 파일시스템 성능 저하 시작 |
| 100만 문서 이상 | ❌ 불가 (OS 파일 수 한계 + LLM 컴파일 비용 폭증) |
GitHub 로드맵에 "Database-backed storage engine" 과 "Scale to large document collections" 이 미완성 목표로 명시되어 있어, 개발팀도 현재 한계를 인지하고 있는 상태입니다.
대규모 문서가 필요한 환경이라면 RAG + 벡터DB(Qdrant, Weaviate) 조합이 현실적입니다. OpenKB는 핵심 참조 문서 수백 개를 구조화된 위키로 만드는 용도에 집중하는 것이 적합합니다.
다국어 출력 미지원
language 설정은 단일 언어만 지원합니다. 한국어(ko)로 설정하면 요약 내용은 한국어로 생성되지만, 컨셉 파일명은 영문 슬러그로 고정되어 Obsidian 그래프 뷰의 노드 레이블은 영문으로 표시됩니다. 한영 병행 출력도 현재는 불가능하며, 우회하려면 KB를 언어별로 분리 운영하거나 컴파일 후 별도 번역 스크립트를 추가해야 합니다.
9. 마치며
RAG는 여전히 유용합니다. 실시간 최신 문서, 대용량 비정형 데이터, 다양한 질의에 유연하게 대응해야 할 때는 RAG가 적합합니다.
하지만 반복적으로 참조하는 사내 지식, 누적되고 연결되어야 하는 문서, 팀이 함께 탐색해야 하는 지식베이스라면 OpenKB 방식이 더 적합합니다. 문서를 한 번 이해하고, 그 이해를 영구적으로 축적합니다.
AI가 문서를 단순히 "검색"하는 것이 아니라, **"이해하고 구조화"**해야 하는 조직이라면 OpenKB는 진지하게 검토할 가치가 있습니다.
참조
| # | 출처 | 내용 | 링크 |
|---|---|---|---|
| 1 | VectifyAI | OpenKB GitHub 저장소 | github.com/VectifyAI/OpenKB |
| 2 | VectifyAI | PageIndex GitHub 저장소 | github.com/VectifyAI/PageIndex |
| 3 | arxiv 2511.18177 | PageIndex 기술 논문, FinanceBench 98.7% 정확도 | arxiv.org/abs/2511.18177 |
| 4 | PageIndex 공식 문서 | PageIndex 개념 및 사용 가이드 | docs.pageindex.ai |