LLM Wiki 개념 - AI가 읽는 지식 베이스란 무엇인가 [LLM Wiki 1]
AI 에이전트를 업무에 활용하면 문서와 지식을 어떻게 관리할지가 새로운 문제로 등장합니다. 사람이 읽기만 하면 되던 문서와 달리, LLM이 질의 시점에 검색해서 읽을 수 있어야 하기 때문입니다. LLM Wiki는 이 조건에 맞춰 지식 베이스를 설계하는 방법론입니다. 이 글에서는 LLM Wiki가 무엇인지, 왜 필요한지, 어떤 구조로 구성되는지를 정리합니다.
1. 일반 위키의 한계
Confluence나 Notion 같은 위키는 사람 독자를 전제로 설계되었습니다. 화면 UI에서 읽고, 하이퍼링크를 클릭하고, 검색창에 키워드를 입력합니다. 이 구조는 LLM이 문서를 읽을 때 세 가지 한계를 보입니다.
첫째, 컨텍스트 윈도우는 유한합니다. 문서가 600개라고 전부 프롬프트에 넣을 수는 없습니다. 토큰 비용과 응답 지연이 늘고, 관련 없는 문서가 섞이면 오히려 답변 품질이 떨어집니다. 모델이 필요한 순간에 필요한 문서만 찾아서 가져올 수 있어야 합니다.
둘째, 맥락이 문서 안에 없습니다. 회의록에 “지난번 결정대로 진행하기로 했다”라고 적혀 있으면 사람은 어느 결정인지 검색해서 찾습니다. LLM도 마찬가지로 링크를 따라갈 수 있어야 하는데, 일반 위키의 문서는 이런 연결이 암묵적이거나 UI 클릭에만 존재하는 경우가 많습니다.
셋째, 갱신 주기 관리가 필요합니다. 사람이 읽는 위키는 조금 오래돼도 읽는 사람이 상식으로 보정할 수 있습니다. LLM은 오래된 문서와 최신 문서를 구분하지 못한 채 둘 다 사실로 답합니다. 그래서 문서마다 갱신 시점과 신뢰도가 기계적으로 표시되어야 합니다.
2. LLM Wiki의 정의
LLM Wiki는 LLM이 질의 시점에 검색해 읽을 수 있게 구조화된 마크다운 지식 베이스입니다. Karpathy가 2026년 초에 제안한 패턴으로, 핵심 주장은 지식을 매번 모델이 다시 유추하게 하지 말고 섭취(ingest) 시점에 한 번 정리해서 위키로 컴파일하는 것입니다.
이 관점에서 RAG와 LLM Wiki를 구분해 볼 수 있습니다. RAG는 원문 코퍼스를 그대로 두고 질의 시점에 검색해 조각을 가져옵니다. 원문은 흩어져 있고, 정리는 질의할 때마다 모델에게 맡깁니다. LLM Wiki는 그 반대로, 섭취 시점에 사람과 에이전트가 원문을 정리해서 교차 참조와 모순 표시가 포함된 문서로 만들어 둡니다. 질의 시점에는 검색만 하면 됩니다.
| 구분 | RAG | LLM Wiki |
|---|---|---|
| 정리 시점 | 질의할 때마다 | 섭취할 때 한 번 |
| 원문 상태 | 흩어진 원문 그대로 | 정리된 문서로 컴파일 |
| 문서 간 연결 | 검색 결과로만 만나는 조각 | 위키링크로 미리 연결 |
| 모순 처리 | 모델이 그때그때 판단 | 문서에 모순 표시로 남음 |
| 갱신 | 원문 교체 | 문서 갱신 + 이력 기록 |
둘은 대체재가 아니라 계층 관계입니다. RAG가 원문 검색 계층이라면 LLM Wiki는 그 위에 있는 정리된 지식 계층입니다.
3. 마크다운 파일을 쓰는 이유
LLM Wiki의 기본 재료는 데이터베이스가 아니라 평범한 마크다운 파일입니다. 이 선택에는 세 가지 이유가 있습니다.
첫째, 토큰 효율입니다. 마크다운은 텍스트 그 자체라서 HTML이나 JSON보다 같은 정보를 담는 데 토큰이 적게 듭니다. 태그가 곧 노이즈가 되는 LLM 입력에서 이는 비용 문제와 직결됩니다.
둘째, 도구 독립성입니다. 파일이면 git으로 버전 관리가 되고, grep으로 찾을 수 있고, 어떤 에디터로도 열 수 있습니다. 특정 SaaS가 서비스를 종료해도 지식은 남습니다. Obsidian 같은 도구는 이 파일 묶음을 보여주는 뷰어일 뿐입니다.
셋째, LLM 친화 메타데이터입니다. 각 문서는 YAML frontmatter로 제목, 갱신일, 신뢰도를 가질 수 있습니다. 사람 눈에는 크게 보이지 않지만 에이전트는 이 메타데이터로 문서의 신선도와 신뢰도를 기계적으로 판단할 수 있습니다.
4. 구조의 뼈대
운영 중인 LLM Wiki의 디렉터리는 대략 다음과 같이 구성됩니다.
1
2
3
4
5
6
7
8
9
10
wiki/
index.md # 전체 문서의 목차
log.md # 위키 변경 이력
SCHEMA.md # 이 위키의 규칙
concepts/ # 재사용 가능한 개념 문서
runbooks/ # 운영 절차 문서
queries/ # 질의 결과를 남긴 문서
raw/ # 원문 스냅샷 (수정 금지)
evaluations/ # 검색 품질 측정 기록
goals/ # 목표 관련 문서
각 파일은 frontmatter와 본문, 위키링크로 구성됩니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
---
title: 쿠버네티스 어드미션 컨트롤
created: 2026-05-02
updated: 2026-08-01
type: concept
tags: [kubernetes, security]
sources: [k8s-docs]
source_status: official
confidence: high
---
# 쿠버네티스 어드미션 컨트롤
... 본문 ...
관련: [[pod-security-admission]], [[kubernetes-api-server]]
지켜야 하는 규칙은 다음과 같습니다. [[위키링크]]는 반드시 실제 파일로 풀려야 하고 깨진 링크는 커밋 게이트에서 차단합니다. 원문은 raw/에 불변으로 보존하고 정리본에만 수정합니다. 의미 있는 변경은 log.md에 기록합니다. 문서 이름은 소문자-하이픈으로 통일합니다. 이 규칙들은 사람이 놓쳐도 에이전트와 스크립트가 강제할 수 있다는 점이 LLM Wiki의 차별점입니다.
5. 사람 위키와 다른 점
LLM Wiki는 기존 위키에 다음 세 가지를 추가합니다.
검색 계층이 명시적입니다. 사람 위키의 검색은 UI 부가기능이지만 LLM Wiki에서는 본체에 해당합니다. BM25 같은 키워드 검색과 임베딩 검색을 조합한 하이브리드 검색, 그리고 그 품질을 측정하는 평가셋이 위키의 구성 요소로 존재합니다. 검색 품질이 떨어지면 지식이 있어도 활용할 수 없기 때문입니다.
갱신이 이벤트가 아니라 파이프라인입니다. 새 문서가 들어오면 분류하고, 링크를 걸고, 인덱스에 등록하는 작업이 사람의 기억이 아니라 절차로 수행됩니다. 이 파이프라인의 상태가 위키의 건강 상태를 결정합니다.
신뢰도가 문서 단위로 관리됩니다. 공식 문서 기반인지, 실험 결과인지, 추정인지를 frontmatter의 source_status와 confidence로 구분합니다. LLM이 근거 없는 답을 했을 때 어떤 문서를 근거로 답했는지 역추적할 수 있는 구조입니다.