// llm_wiki_definition

LLM 위키란 무엇인가

LLM 위키는 LLM이 직접 entity와 relation을 추출하고 그래프로 연결해 영구 누적·재인덱싱하는 지식 시스템입니다. 질문 시점에만 retrieval하는 RAG와 달리, 도메인 지식이 시간에 따라 진화·누적되는 구조입니다. 이 문서는 정의·아키텍처·실증 사례를 한 페이지에 정리합니다.

● 정의 / 아키텍처 / 실증 ● 최종 업데이트 2026-05-14 ● 김생근 · habix.ai
🌌 라이브 LLM 위키 체험 → 📖 관련 인사이트 읽기

// 01 · comparisonLLM 위키 vs RAG

많은 글이 LLM 위키를 "더 똑똑한 RAG"라고 부르지만, 두 시스템은 지식의 수명주기 자체가 다릅니다. RAG는 질문이 들어올 때마다 chunk를 즉석에서 retrieval하는 휘발성 검색 레이어이고, LLM 위키는 entity와 relation을 사전에 추출해 graph DB에 영구 누적하는 지식 기층(substrate)입니다.

축RAGLLM 위키
지식 수명주기 질문 시점 즉석 retrieval · 휘발성 · 응답 끝나면 사라짐 영구 누적 + 재인덱싱 · graph DB에 entity·relation 보존 · 시간 누적
구조 chunk → embedding → vector top-k entity·relation 그래프 + 멀티 retriever 라우팅 (universe.habix.ai의 Producer/Consumer + Agentic RAG 3-router가 실증)
언제 쓰는가 단발성 QA · 문서 검색 · 사전 지식 적은 일회성 질의 도메인 지식이 누적·진화하는 1인/팀 context · 외장된 도메인 뇌
그림 1 — RAG(chunk → vector top-k, 휘발성)와 LLM 위키(entity·relation 그래프, 영구 누적)의 구조 차이

한편 "AI 위키"라는 표현은 두 가지 의미로 혼용됩니다. 사람이 직접 편집하는 wiki에 AI 기능을 얹은 것(Notion AI, Confluence AI 등)을 가리키기도 하고, 본 문서가 다루는 LLM 위키와 동의어로 쓰이기도 합니다. 본 페이지는 후자, 즉 LLM이 entity·relation을 자동으로 추출·관리하는 시스템을 가리킵니다.

// 02 · context왜 지금 LLM 위키인가

2024~2025년을 지나며 retrieval 패러다임에는 세 가지 균열이 생겼습니다. 첫째, Anthropic이 Contextual Retrieval에서 보였듯 단순 vector top-k의 정답률 한계가 분명해졌습니다. chunk가 원 문맥에서 단절되는 순간 retrieval의 정밀도가 30~50% 떨어진다는 측정이 반복적으로 보고되었습니다.

둘째, Neo4j의 GraphRAG Manifesto가 정리한 대로, retrieval은 vector 단일 경로에서 graph traversal + 의미 검색의 하이브리드로 이동하고 있습니다. entity·relation을 명시적으로 보존하는 쪽이 multi-hop 질의에서 압도적으로 강하기 때문입니다.

셋째, Andrej Karpathy가 Software 3.0 / LLM-as-OS 논의에서 강조한 흐름 — LLM이 단순 호출 대상이 아니라 지식을 직접 구성·유지하는 substrate가 되는 방향 — 이 LLM 위키의 본질과 직접 닿아 있습니다. 이 세 흐름이 합쳐져 "LLM이 직접 위키를 운영하는 시대"가 빠르게 현실이 됩니다.

// 03 · architectureProducer/Consumer 분리 아키텍처를 적용한 LLM 위키

PRODUCER Ingest extract embed CONSUMER Query vector cypher text2cy
// graph 1 — Producer (ingest·embed) → Consumer (3-router query) 의 데이터 흐름

LLM 위키가 규모를 가지려면 ingest(Producer)와 query(Consumer)가 반드시 분리되어야 합니다. universe.habix.ai는 이 분리를 기준선으로 설계되었습니다.

Producer — 사전 ingest 파이프라인

wiki 원본(노트·문서·블로그)을 받아 LLM이 entity와 relation을 추출하고 Neo4j graph DB에 노드·엣지로 적재합니다. embedding은 ingest 시점에 1회만 계산되어 vector index에 저장되며, 이후 변경분만 incremental 재인덱싱됩니다. 이 분리 덕분에 재인덱싱 비용은 데이터 규모와 무관하게 거의 0에 수렴합니다.

Consumer — Agentic RAG 3-router 질의 레이어

FastAPI /query 엔드포인트가 들어온 질문을 라우터 LLM에 넘기고, 라우터는 셋 중 하나의 retriever를 선택합니다: VectorRetriever(의미 기반 fuzzy), VectorCypherRetriever(의미 진입 후 그래프 traversal), Text2CypherRetriever(자연어 → Cypher 정밀 질의). 답변 LLM은 선택된 retriever의 결과를 받아 응답을 합성합니다.

// 04 · live proof실전 사례: universe.habix.ai

universe.habix.ai는 위 정의가 그대로 작동하는 라이브 LLM 위키입니다. 한 사람의 도메인 지식이 5개 도메인 그래프로 누적되어, 자연어 질의로 multi-hop 응답을 만드는 구조입니다. 개념을 글로만 설명하기보다, 직접 질의해 보는 쪽이 빠릅니다.

그림 2 — universe.habix.ai 실측 인터랙션: 5개 도메인 그래프 회전·줌·노드 탐색

관련된 deep dive는 blog.habix.ai에서 Producer/Consumer 분리, Agentic RAG 3-router, Neo4j graph 운용 노트 형태로 이어 다룹니다.

🌌 universe.habix.ai 직접 체험하기 → 관련 글 더 읽기 AI Agent 강의 보기

// 05 · faq자주 묻는 질문

1. LLM 위키와 RAG의 근본 차이는 무엇인가?
RAG는 질문 시점에 chunk를 vector 유사도로 retrieval하는 즉석·휘발성 구조입니다. LLM 위키는 LLM이 entity와 relation을 사전에 추출해 graph DB에 영구 누적하고, 시간이 지날수록 지식이 진화·재인덱싱됩니다. 단발성 QA에는 RAG가, 도메인 지식이 누적되어야 하는 환경에는 LLM 위키가 맞습니다.
2. 기존 RAG 파이프라인에서 LLM 위키로 어떻게 이행하는가?
기존 chunk·embedding은 그대로 두고 그 위에 entity·relation 추출 단계를 Producer로 분리해 추가합니다. Neo4j 같은 graph DB에 노드·엣지를 적재한 뒤, retriever를 단일 vector top-k에서 vector·cypher·text2cypher 멀티 라우터로 확장하면 점진적 마이그레이션이 가능합니다.
3. Producer/Consumer 분리가 왜 필요한가?
Producer(ingest·indexing)와 Consumer(query·response)를 분리하면 embedding을 한 번만 계산해 재활용할 수 있고, indexing 비용을 query latency와 무관하게 백그라운드로 흘릴 수 있습니다. 위키가 커질수록 재인덱싱 비용이 0에 가까워야 운용이 가능하기 때문에 분리가 사실상 필수입니다.
4. Agentic RAG 3-router(VectorRetriever / VectorCypherRetriever / Text2CypherRetriever)는 언제 무엇이 선택되는가?
VectorRetriever는 의미 기반 fuzzy 질의(개념·요약)에, VectorCypherRetriever는 의미로 진입한 뒤 그래프 traversal로 관계를 따라가는 질의에, Text2CypherRetriever는 정밀한 구조적 질문(특정 entity의 속성·집계)에 선택됩니다. universe.habix.ai에서는 라우터 LLM이 질문 형태를 보고 셋 중 하나를 자동 라우팅합니다.
5. 1인 운영자에게 LLM 위키가 의미 있는 이유는?
1인이 다루는 도메인은 좁고 깊으며 시간에 따라 누적됩니다. 매번 새 문서를 던지는 RAG보다, 지식이 자동으로 entity·relation 그래프로 흡수되어 질의 가능한 형태로 누적되는 LLM 위키가 훨씬 적합합니다. 일종의 "외장된 도메인 뇌" 역할입니다.
6. LLM 위키를 직접 만들려면 어떤 스택이 필요한가?
최소 구성은 (1) entity·relation 추출용 LLM(Claude·GPT·Gemini), (2) graph DB(Neo4j 또는 Memgraph), (3) vector store(pgvector·Qdrant·Weaviate), (4) retriever 라우팅 레이어(LangGraph·LlamaIndex), (5) ingestion orchestrator(cron 또는 워크플로 엔진)입니다. universe.habix.ai는 Neo4j + Python FastAPI + Cypher retriever 조합으로 구성됩니다.
7. embedding 비용은 어느 정도인가?
Producer/Consumer 분리 구조에서 embedding은 ingest 시점에 1회만 계산하면 됩니다. 1024+ chunk 규모에서 OpenAI text-embedding-3-small 기준 1회 인덱싱 비용은 1달러 미만이며, 이후 재인덱싱은 변경분만 처리하기 때문에 운용 비용은 사실상 0에 수렴합니다.
8. 노션·옵시디언과 LLM 위키는 어떤 관계인가?
노션·옵시디언은 사람이 직접 편집하는 wiki이고, LLM 위키는 LLM이 entity·relation 추출·연결을 자동화하는 시스템입니다. 두 층은 보완 관계로, 옵시디언 vault를 source로 두고 LLM 위키가 그 위에 graph 인덱스를 얹는 구성이 가장 흔합니다.
9. LLM 위키와 일반 KG(Knowledge Graph)는 어떻게 다른가?
전통 KG는 사람이 ontology를 설계하고 entity·relation을 수기 입력하는 구조입니다. LLM 위키는 ontology를 LLM이 자동 유도하고, entity·relation 추출·정규화도 LLM이 수행하며 자연어 질의를 Cypher로 변환해 retrieval합니다. 결과적으로 도메인 변화에 대한 적응 비용이 한 자릿수 이상 낮습니다.
10. LLM 위키 콘텐츠는 학습 데이터로 노출되는가?
habix.ai의 LLM 위키 운영 정책은 ai-input(검색·답변 인용)은 허용하되 ai-train(학습 데이터 수집)은 비허용입니다. robots.txt와 Content-Signal 헤더로 명시하며, universe.habix.ai도 동일 정책을 따릅니다.
// next_step

읽기보다 직접 만져보는 게 빠릅니다

위 정의가 실제로 어떻게 작동하는지 라이브 LLM 위키에서 자연어로 질의해 보세요. 더 깊은 운용 노트는 blog.habix.ai 일일 발행 인사이트에서 이어 다룹니다.

🌌 universe.habix.ai 체험하기 → 📖 blog.habix.ai 인사이트 →
AI Agent 강의 상세 → · 강사 프로필 → · 컨설팅 문의 →