RAG 다음 단계: LLM Wiki

LLM을 개인 지식관리나 리서치에 활용할 때 가장 흔한 구조는 RAG(Retrieval-Augmented Generation)다.

문서들을 저장해 두고, 사용자가 질문하면 관련 문서 조각을 검색한 뒤 LLM에게 전달한다.

Documents
   ↓
Chunking
   ↓
Embedding / Index
   ↓
Retrieval
   ↓
LLM
   ↓
Answer

이 방식은 효율적이다.

하지만 한 가지 구조적인 문제가 있다.

매번 지식을 다시 조립해야 한다.

100개의 문서를 읽고 5개의 자료를 연결해 어떤 결론을 만들었다고 하더라도, 다음 질문에서는 다시 검색하고 다시 조합해야 한다.

LLM 입장에서는 이전에 수행했던 분석이 하나의 지식 구조로 축적되지 않는다.

Karpathy가 공개한 LLM Wiki 아이디어는 바로 이 문제를 다르게 접근한다.

핵심은 단순하다.

원본 문서를 검색하는 것에 그치지 않고, LLM이 지속적으로 관리하는 Markdown Wiki를 중간 계층에 둔다.

즉,

Raw Sources
      ↓
     LLM
      ↓
Persistent Wiki
      ↓
     Query

라는 구조다.

이 Wiki는 단순한 요약 저장소가 아니다.

새로운 자료가 들어올 때마다 기존 지식과 비교하고, 관련 문서를 업데이트하고, 모순을 기록하고, 새로운 연결을 만들어내는 지속적으로 진화하는 지식베이스다.

---

1. RAG와 LLM Wiki의 가장 큰 차이

일반적인 RAG에서는 원본 자료가 지식의 중심이다.

질문
 ↓
원본 문서 검색
 ↓
관련 Chunk 추출
 ↓
LLM이 즉석에서 종합
 ↓
답변

예를 들어 AI Agent에 대해 100개의 글을 저장했다고 하자.

사용자가 다음 질문을 한다.

MCP와 Agent Skill은 어떤 관계인가?

RAG 시스템에서는 매번 MCP와 Agent Skill 관련 문서를 검색하고 LLM이 새롭게 관계를 정리한다.

반면 LLM Wiki에서는 이미 다음과 같은 페이지가 존재할 수 있다.

wiki/
├── ai-agent.md
├── mcp.md
├── agent-skill.md
├── tool-use.md
├── context-engineering.md
└── agent-architecture.md

그리고 각 문서는 서로 연결된다.

# MCP

MCP는 LLM Agent가 외부 도구와 데이터를
표준화된 방식으로 연결하기 위한 프로토콜이다.

관련 개념:

- [Agent Skill](agent-skill.md)
- [Tool Use](tool-use.md)
- [Context Engineering](context-engineering.md)

새로운 MCP 관련 글이 들어오면 LLM은 단순히 source-103.md를 추가하는 것으로 끝내지 않는다.

기존의

mcp.md
agent-skill.md
tool-use.md
agent-architecture.md

등을 함께 수정할 수 있다.

즉 지식이 누적된다.

---

2. 이 구조는 사실상 ‘지식 컴파일’에 가깝다

이 구조를 개발 관점에서 보면 재미있는 비유가 가능하다.

Raw Source를 소스 코드라고 생각해보자.

Raw Sources
   =
Source Code

LLM은 컴파일러 역할을 한다.

LLM
 =
Compiler

그리고 Wiki는 컴파일된 지식이다.

Wiki
 =
Compiled Knowledge

전체 흐름은 다음과 같다.

Articles
Papers
Videos
Meetings
Documents
     │
     ▼
┌───────────────┐
│      LLM      │
│ Knowledge     │
│ Compiler      │
└───────────────┘
     │
     ▼
┌────────────────────┐
│ Persistent Wiki    │
│                    │
│ Concepts           │
│ Entities           │
│ Comparisons        │
│ Relationships      │
│ Synthesis          │
└────────────────────┘

RAG가 필요할 때마다 지식을 해석하는 인터프리터형 접근이라면,

LLM Wiki는 미리 지식을 구조화하는 컴파일형 접근이라고 볼 수 있다.

물론 실제 컴파일러와 동일한 개념은 아니다.

하지만 시스템 설계 관점에서는 꽤 유용한 모델이다.

---

3. 시스템은 세 개의 계층으로 구성된다

LLM Wiki의 기본 구조에는 세 가지 핵심 레이어가 있다.

① Raw Sources

사용자가 수집한 원본 자료다.

예를 들면:

raw/
├── article-openai-agents.md
├── anthropic-agent-skills.md
├── mcp-spec.md
├── paper-context-engineering.pdf
└── assets/

여기에서 중요한 원칙이 있다.

LLM은 Raw Source를 수정하지 않는다.

원본 자료는 Source of Truth 역할을 한다.

raw = immutable

잘못된 요약이나 해석이 생겨도 원본을 다시 확인할 수 있기 때문이다.

---

4. 두 번째 계층은 LLM이 관리하는 Wiki다

Wiki는 사람이 직접 작성하는 공간이라기보다는 LLM이 유지보수하는 코드베이스에 가깝다.

예를 들어 다음과 같은 구조가 만들어질 수 있다.

wiki/
├── README.md
│
├── concepts/
│   ├── ai-agent.md
│   ├── context-engineering.md
│   ├── rag.md
│   └── agent-memory.md
│
├── technologies/
│   ├── mcp.md
│   ├── agent-skills.md
│   └── vector-database.md
│
├── companies/
│   ├── openai.md
│   ├── anthropic.md
│   └── google.md
│
└── comparisons/
    └── rag-vs-llm-wiki.md

LLM이 담당하는 작업은 상당히 많다.

새로운 자료를 읽으면 다음 작업을 수행한다.

요약
↓
개념 추출
↓
관련 페이지 탐색
↓
기존 주장과 비교
↓
페이지 수정
↓
Cross-reference 생성
↓
README 업데이트
↓
Git commit

하나의 자료가 들어오면서 10~15개의 문서가 동시에 수정될 수도 있다.

일반적인 개인 Wiki에서는 이런 유지보수가 가장 큰 부담이다.

LLM Wiki에서는 이 유지보수 자체를 Agent에게 맡긴다.

---

5. 세 번째 계층: AGENTS.md

실제로 가장 중요한 파일은 Wiki가 아닐 수도 있다.

Agent에게 지식베이스 관리 규칙을 알려주는 파일이다.

Codex라면:

AGENTS.md

Claude Code라면:

CLAUDE.md

형태로 둘 수 있다.

이 파일은 일종의 Knowledge Base Constitution 역할을 한다.

예를 들어 다음과 같은 규칙을 정의할 수 있다.

# Wiki Rules

## Source Rules

- raw/ 파일은 절대 수정하지 않는다.
- 모든 중요한 주장에는 Source를 연결한다.
- Source 없는 추론은 명시적으로 표시한다.

## Page Rules

각 페이지는 다음 구조를 사용한다.

1. Summary
2. Key Concepts
3. Relationships
4. Evidence
5. Open Questions
6. Sources

## Link Rules

Wikilink를 사용하지 않는다.

잘못된 예:

[[MCP]]

올바른 예:

[MCP](mcp.md)

## Update Rules

새로운 Source가 기존 주장과 충돌하면
기존 내용을 삭제하지 말고 contradiction을 기록한다.

이 파일의 품질에 따라 Wiki의 품질도 크게 달라질 수 있다.

결국 LLM Wiki 구축에서 중요한 것은 단순한 Prompt Engineering보다 Knowledge Governance다.

---

6. 가장 중요한 Operation: Ingest

새로운 자료가 들어오면 Agent는 단순 요약보다 더 많은 작업을 한다.

예를 들어 다음 자료가 추가됐다고 하자.

raw/anthropic-agent-skills-2026.md

Agent가 수행하는 흐름은 다음과 같다.

Source 읽기
     ↓
핵심 주장 추출
     ↓
기존 Wiki 검색
     ↓
관련 개념 찾기
     ↓
기존 주장과 비교
     ↓
새 페이지 생성 또는 기존 페이지 수정
     ↓
Cross-reference 업데이트
     ↓
README 업데이트
     ↓
Git Commit

Git commit은 예를 들어 다음과 같이 만들 수 있다.

ingest: Anthropic Agent Skills architecture

- added agent-skills.md
- updated ai-agent.md
- updated mcp.md
- added skill-vs-tool comparison
- linked Anthropic architecture sources

이 Commit 자체가 지식베이스의 변경 기록이 된다.

---

7. log.md보다 Git History

초기 아이디어에서는 Wiki 변경 기록을

log.md

에 저장하는 방법이 제안됐다.

하지만 이후 버전에서는 Git 자체를 로그 시스템으로 사용하는 쪽으로 개선됐다.

그 이유는 명확하다.

여러 Agent가 동시에 작업하면 append-only 파일은 충돌하기 쉽다.

Agent A → log.md 마지막 줄 수정
Agent B → log.md 마지막 줄 수정

→ Merge Conflict

Git은 이미 변경 이력을 관리하기 위한 시스템이다.

따라서

git log --oneline -- wiki/

만 실행해도 Wiki의 전체 변화 과정을 확인할 수 있다.

특정 페이지 변화는

git log --follow -p wiki/mcp.md

로 추적할 수 있다.

이 설계는 꽤 중요하다.

별도의 지식 History 시스템을 만드는 대신 Git 자체를 Temporal Memory로 활용한다.

---

8. README.md는 Wiki의 Router 역할을 한다

Wiki가 커지면 Agent가 매번 모든 Markdown 파일을 읽을 수 없다.

따라서 Root에

README.md

를 둔다.

예를 들어:

# AI Engineering Wiki

## Agent Architecture

- [AI Agent](concepts/ai-agent.md)
  Agent architecture overview

- [Agent Memory](concepts/agent-memory.md)
  Persistent and temporary memory mechanisms

## Protocols

- [MCP](technologies/mcp.md)
  Model Context Protocol

## Retrieval

- [RAG](concepts/rag.md)
  Retrieval Augmented Generation

질문이 들어오면 Agent는 먼저 README를 읽는다.

Question
   ↓
README
   ↓
Relevant Pages
   ↓
Sources

이렇게 하면 수백 페이지 정도까지는 Vector DB 없이도 꽤 효율적인 탐색이 가능하다.

README는 사실상 LLM용 Knowledge Router 역할을 한다.

---

9. Wiki가 커지면 계층 구조를 만든다

처음부터 복잡한 디렉터리를 만드는 것은 권장되지 않는다.

초기에는 다음처럼 Flat 구조로 시작한다.

wiki/
├── README.md
├── mcp.md
├── rag.md
├── agent.md
├── context-engineering.md
└── agent-memory.md

페이지가 늘어나면서 자연스럽게 Cluster가 생긴다.

예:

agent.md
agent-memory.md
agent-tools.md
agent-planning.md
agent-evaluation.md

이 시점에 Agent가 다음 구조를 제안할 수 있다.

wiki/
└── agents/
    ├── README.md
    ├── architecture.md
    ├── memory.md
    ├── tools.md
    ├── planning.md
    └── evaluation.md

즉 Wiki 구조 변경 자체도 Agent가 관리한다.

이 작업을 원문에서는 Codebase의 Refactoring / Compaction과 유사하게 본다.

---

10. Wiki에도 기술 부채가 생긴다

지식베이스 역시 시간이 지나면 기술 부채와 비슷한 문제가 발생한다.

예를 들어:

중복 페이지
오래된 주장
서로 충돌하는 설명
고립된 페이지
너무 긴 문서
잘못된 분류
깨진 링크

따라서 LLM Wiki에서는 두 가지 유지보수 작업이 중요하다.

Lint

문제를 탐지한다.

contradiction
stale claim
orphan page
missing link
missing concept
source gap

Compact

문제를 실제로 수정한다.

merge
rewrite
split
delete
move
restructure

개발에 대응시키면 다음과 같다.

Wiki Lint
≈
Static Analysis

Wiki Compact
≈
Refactoring

상당히 개발자 친화적인 Knowledge Management 모델이다.

---

11. 질문 역시 지식이 된다

이 시스템의 중요한 특징 중 하나는 Query 결과도 Wiki에 다시 저장할 수 있다는 것이다.

예를 들어 사용자가 묻는다.

MCP와 Agent Skill 중 어느 것을 먼저 도입해야 하는가?

Agent가 기존 자료를 분석해 비교 문서를 만든다.

comparisons/
└── mcp-vs-agent-skills.md

다음 질문에서는 이 분석을 다시 처음부터 하지 않아도 된다.

Source
   ↓
Wiki

Question
   ↓
Analysis
   ↓
Wiki

Question
   ↓
Analysis
   ↓
Wiki

따라서 Source뿐 아니라 사고 과정에서 만들어낸 분석 결과 자체도 Knowledge Asset으로 축적된다.

이 부분이 일반적인 Chat History와 가장 큰 차이다.

---

12. 검색은 처음부터 Vector DB가 필요하지 않다

많은 개발자는 지식베이스라고 하면 바로 다음 스택을 떠올린다.

Embedding
Vector DB
Hybrid Search
Reranker
RAG Pipeline

하지만 LLM Wiki에서는 처음부터 이런 인프라가 필요하지 않을 수 있다.

초기에는

README
grep
ripgrep
find

정도로 충분하다.

예:

rg "MCP" wiki/

또는 Markdown 전용 Local Search Tool을 사용할 수도 있다.

원문에서는 qmd 같은 도구가 예로 언급된다.

Wiki가 커지면 다음 단계로 발전시킬 수 있다.

Stage 1

README + grep


Stage 2

BM25 search


Stage 3

BM25 + Vector Search


Stage 4

Hybrid Search + Reranker

즉 검색 인프라를 처음부터 과도하게 구축할 필요가 없다.

---

13. Git + Markdown이 중요한 이유

이 구조에서 Markdown과 Git은 우연한 선택이 아니다.

Markdown은:

LLM이 읽기 쉽다
LLM이 수정하기 쉽다
diff 확인이 쉽다
Git과 궁합이 좋다
Obsidian/GitHub에서 바로 렌더링된다

Git은:

Versioning
Diff
Rollback
Branch
Merge
History
Collaboration

을 제공한다.

따라서 별도의 Knowledge Management Database가 없어도 상당히 강력한 시스템을 만들 수 있다.

---

14. Obsidian의 역할

이 구조에서 Obsidian은 지식을 만드는 시스템이라기보다 Knowledge IDE에 가깝다.

원문의 표현을 개발자 관점으로 정리하면 다음과 같다.

Obsidian
=
IDE

LLM Agent
=
Programmer

Wiki
=
Codebase

Raw Sources
=
Input Data

AGENTS.md
=
Coding Rules

Git
=
Version Control

특히 Obsidian Graph View를 이용하면

Concept
 ↔
Entity
 ↔
Source
 ↔
Analysis

관계를 시각적으로 확인할 수 있다.

---

15. 실제로 구현한다면

가장 단순한 MVP는 다음 정도로 충분하다.

knowledge/
│
├── AGENTS.md
│
├── raw/
│   ├── source-001.md
│   ├── source-002.md
│   └── assets/
│
└── wiki/
    ├── README.md
    ├── mcp.md
    ├── rag.md
    └── agent-memory.md

Agent에게 다음 네 가지 Command만 정의해도 된다.

/ingest
/query
/lint
/compact

/ingest

새 Source 분석
→ Wiki 업데이트
→ Cross-reference
→ README 수정
→ Commit

/query

README 탐색
→ 관련 Wiki 탐색
→ 필요 시 Raw Source 확인
→ 답변 생성
→ 가치 있는 분석이면 Wiki 저장

/lint

중복
모순
오래된 주장
고립 페이지
깨진 링크
Source 부족
검사

/compact

중복 페이지 Merge
긴 페이지 Split
Directory 재구성
Stale 정보 제거
Cross-reference 수정

이 정도만으로도 상당히 강력한 개인 지식 시스템을 만들 수 있다.

---

16. 더 발전시키면 Agentic Knowledge Pipeline이 된다

이 구조를 자동화하면 다음 형태까지 발전할 수 있다.

Web
RSS
GitHub
YouTube
Papers
Slack
Meetings
   │
   ▼
Source Collector
   │
   ▼
raw/
   │
   ▼
Ingest Agent
   │
   ├─ Entity Extraction
   ├─ Concept Extraction
   ├─ Contradiction Detection
   ├─ Relationship Discovery
   └─ Source Verification
   │
   ▼
Wiki
   │
   ├─ README
   ├─ Concepts
   ├─ Entities
   ├─ Comparisons
   └─ Synthesis
   │
   ▼
Git

여기에 Scheduler를 붙이면 주기적으로

lint
compact
link check
stale claim check

를 실행할 수 있다.

결국 단순한 Wiki가 아니라 Agent가 유지보수하는 지식 운영 시스템이 된다.

---

17. RAG를 없애자는 아이디어는 아니다

중요한 점이 하나 있다.

LLM Wiki와 RAG는 경쟁 관계일 필요가 없다.

오히려 두 구조를 조합하는 것이 자연스럽다.

               ┌─ Wiki Search
Question ──────┤
               └─ Raw Source RAG
                       │
                       ▼
                      LLM

Wiki에는 이미 정리된 지식이 들어 있고,

Raw Source RAG는 다음 용도로 사용한다.

원문 검증
정확한 인용
세부 데이터 확인
새로운 정보 탐색

따라서 현실적인 구조는

Wiki + RAG

가 될 가능성이 높다.

Wiki가 Semantic Memory라면 Raw Source는 Evidence Store에 가까운 역할을 한다.

---

18. 이 아이디어의 진짜 핵심

표면적으로 보면 이 시스템은 단순하다.

Markdown
+
Git
+
LLM

뿐이다.

하지만 중요한 것은 저장 기술이 아니다.

기존 RAG에서는

Knowledge = Documents

였다.

LLM Wiki에서는

Knowledge =
Documents
+
Relationships
+
Synthesis
+
History
+
Questions
+
Analysis

가 된다.

즉 지식의 단위를 문서에서 지속적으로 업데이트되는 지식 구조로 바꾸는 것이다.

그래서 이 시스템의 핵심은 Wiki 자체라기보다 다음 개념에 있다.

LLM이 지식을 소비하는 Agent에서 지식을 지속적으로 유지보수하는 Agent로 바뀐다.

---

결론

LLM 시대의 개인 지식관리 시스템을 단순히

문서 저장
→ Embedding
→ Vector Search
→ 답변

으로만 생각할 필요는 없다.

한 단계 더 나아가면

Source
   ↓
LLM
   ↓
Structured Knowledge
   ↓
Continuous Maintenance
   ↓
Git History
   ↓
Accumulated Intelligence

구조를 만들 수 있다.

특히 Codex, Claude Code 같은 Coding Agent가 등장하면서 이 방식은 구현하기 훨씬 쉬워졌다.

Markdown Wiki는 일종의 코드베이스가 되고,

LLM Agent는 그 코드베이스를 관리하는 개발자가 된다.

그리고 인간은 직접 Wiki를 정리하는 대신,

좋은 자료를 찾고
좋은 질문을 하고
중요한 방향을 결정하는 것

에 집중한다.

결국 이 아이디어의 가장 흥미로운 지점은 LLM에게 더 많은 문서를 검색하게 하는 것이 아니라, 한 번 이해한 지식을 다시 잃어버리지 않게 만드는 것이다.

RAG가 LLM에게 외부 기억을 제공했다면,

LLM Wiki는 그 기억을 시간이 지날수록 구조화하고 축적하는 방법에 더 가깝다.