LLM Wiki 실전 가이드: RAG의 한계를 넘는 누적 지식 베이스 구축과 운영 패턴

최근 LLM을 문서와 연동할 때 표준처럼 쓰이던 RAG(Retrieval-Augmented Generation)의 한계를 느끼는 엔지니어들이 늘고 있습니다. 문서를 잘게 쪼개어 벡터 DB에 넣고 질의할 때마다 검색하는 방식은 간단하지만, **“매번 처음부터 새로 읽고 조합해야 하며, 질문을 거듭해도 지식이 스스로 누적되지 않는다”**는 구조적 한계가 있기 때문입니다.

이 문제를 해결하기 위해 Andrej Karpathy가 제안한 아이디어가 바로 LLM Wiki입니다. LLM Wiki는 검색기가 아니라, 사람이 던져 넣은 원본 자료를 바탕으로 LLM이 마크다운 위키를 지속해서 작성·갱신·교차 검증하며 지식을 복리처럼 쌓아가는 패턴입니다.

이번 글에서는 Karpathy의 원안 개념을 짚고, 이를 실제 개인 리서치 및 팀 DevOps/엔지니어링 환경에서 안정적으로 운영할 수 있도록 확장한 디렉토리 설계, 도메인·프로젝트 하이브리드 분리 패턴, 3대 실전 시나리오, 그리고 Lint 운영 전략을 상세히 정리해 보겠습니다.

1. RAG vs LLM Wiki: 지식이 머무는 위치의 차이

RAG와 LLM Wiki의 가장 큰 차이는 지식의 종합(Synthesis)이 일어나는 시점입니다.

[전통적인 RAG 방식]
원문 수집 -> 청킹 & 벡터 임베딩
질문 발생 -> 청크 유사도 검색 -> 매번 프롬프트 안에서 새로 종합 (질문 끝나면 휘발)

[LLM Wiki 방식]
원문 수집 -> LLM이 읽고 종합(Synthesis) -> 상호 링크된 마크다운 위키 갱신 (지식 영구 누적)
질문 발생 -> 이미 잘 정돈된 wiki 인덱스와 개념 페이지를 읽고 답변 -> 새 통찰은 위키에 재환류

구분	RAG	LLM Wiki
지식이 위치하는 곳	원문 청크(Chunk) + 벡터 임베딩	정제되고 상호 링크된 마크다운 페이지
종합(Synthesis) 시점	질의(Query)할 때마다 매번 실행	수집(Ingest) 및 유지보수(Lint) 주기
지식 누적 효과	없음 (매번 제로베이스에서 검색)	강력함 (페이지가 갱신되며 복리로 축적)
시스템 비유	도서관 사서에게 매번 책 조각 찾아오기	전문 편집자가 위키백과를 지속 편찬하기

소프트웨어 엔지니어링 관점에서 비유하자면 다음과 같습니다.

raw/ 원본 자료 = 소스코드
LLM = 컴파일러
wiki/ 마크다운 = 컴파일된 실행 파일/바이너리
lint = 지속적 품질 검증을 위한 테스트 스위트
질의(Query) = 사용자 입력을 처리하는 런타임

핵심 3계층과 3대 오퍼레이션

LLM Wiki는 명확한 3개 계층 위에서 동작합니다.

Raw (불변의 소스): 사람이 수집한 불변의 원본 자료 (LLM은 오직 Read만 가능)
Wiki (가공된 지식): LLM이 스키마 규칙에 맞춰 작성하고 상호 링크한 마크다운 문서
Schema (작업 헌법): LLM의 작업 규칙, 템플릿, 제약 사항을 정의한 설정 파일 (CLAUDE.md 또는 AGENTS.md)

그리고 이 구조를 순환시키는 3대 오퍼레이션이 존재합니다.

Ingest: 새 소스를 읽어 요약하고, 관련 개념/엔티티 페이지를 갱신하며 인덱스에 반영
Query: 위키의 카탈로그를 탐색하여 인용 가능한 출처와 함께 답하고, 가치 있는 답변을 다시 위키로 환류
Lint: 모순된 주장, 오래된 정보, 깨진 링크, 지식 공백을 주기적으로 점검(Health Check)

2. 권장 디렉토리 구조: 기본형 설계

실제 운영을 고려한 LLM Wiki의 기본 디렉토리 구조는 다음과 같습니다.

my-wiki/
├── CLAUDE.md            # (또는 AGENTS.md) 스키마: LLM 작업 규칙 및 프롬프트 제약
├── raw/                 # 불변 원본 (사람이 넣고, LLM은 읽기만 수행)
│   ├── articles/
│   ├── papers/
│   ├── transcripts/
│   └── assets/          # 이미지, 다이어그램, 첨부 파일
├── wiki/                # LLM이 직접 작성하고 유지보수하는 지식 영역
│   ├── index.md         # 전체 페이지 목차 + 한 줄 요약 (검색 진입점)
│   ├── log.md           # 수집/질의/lint 감사 이력 (Append-only 로그)
│   ├── concepts/        # 핵심 기술 및 도메인 개념 페이지
│   ├── entities/        # 인물, 팀, 회사, 시스템, 오픈소스 프로젝트
│   ├── sources/         # 원본 문서 1건당 생성되는 구조화 요약 페이지
│   └── syntheses/       # 비교 분석, 아키텍처 결정, 종합 결론 페이지
└── outputs/             # 질의 결과 리포트, Marp 슬라이드 등 파생 산출물 보관

각 요소별 핵심 역할

index.md: LLM이 검색을 수행할 때 가장 먼저 읽는 최상위 카탈로그입니다. Karpathy 방식의 묘미는 복잡한 벡터 DB 없이도, LLM이 수백 개 문서의 요약 목록이 담긴 index.md를 훑고 필요한 마크다운만 선택적으로 열어보게 만드는 데 있습니다.
log.md: 추가 전용(Append-only) 작업 기록 파일입니다. 언제 어떤 문서를 ingest했고, 어떤 질문을 처리했으며, 어떤 페이지가 수정되었는지 감사 추적(Audit Trail)을 남깁니다.
outputs/: 위키 본문을 오염시키지 않으면서 특정 질문에 대한 심층 분석 보고서나 발표용 슬라이드(Marp)를 보관하는 공간입니다.
Obsidian의 역할: Obsidian은 이 디렉토리를 열어보는 **‘뷰어이자 IDE’**로 사용합니다. 사람이 모든 문서를 손으로 타이핑하는 대신, Graph View로 연결 관계를 확인하거나 Dataview로 메타데이터를 모니터링하는 인터페이스로 삼습니다.

3. raw 폴더의 5대 원칙과 파일 작성 규칙

raw/ 폴더는 지식 베이스의 **“진실의 원천(Source of Truth)”**입니다. 이 폴더의 신뢰성이 무너지면 위키 전체가 흔들립니다.

raw 운영의 5대 원칙

불변성 (Immutability): 사람은 자료를 추가만 하고, LLM은 절대 수정하거나 삭제할 수 없습니다. 위키 내용이 꼬이거나 오염되더라도 원본으로부터 언제든 다시 위키를 컴파일(재생성)할 수 있어야 합니다.
재현성 (Reproducibility): 모든 wiki/ 페이지는 raw/의 문서들을 기반으로 결정론적으로 재구성될 수 있어야 합니다.
근거성 (Traceability): wiki/에 기록되는 모든 핵심 주장과 데이터는 반드시 원본 raw/... 경로로 링크가 역추적되어야 합니다. 이는 LLM의 환각(Hallucination)을 걸러내는 가장 강력한 장치입니다.
마찰 최소화 (Frictionless): 복잡한 전처리 없이 던져 넣을 수 있어야 합니다. 웹 클리퍼 마크다운, PDF, 회의 트랜스크립트, 슬랙 스레드 export 등을 원형 그대로 저장합니다.
수집 기준: “나중에 주장의 근거로 다시 열어볼 가치가 있는가?“를 기준으로 보관합니다.

권장 파일명 및 메타데이터 형식

raw 문서의 파일명은 YYYY-MM-DD_출처_제목.md 형식을 권장하며, 상단에 간단한 Frontmatter를 두면 LLM이 맥락을 파악하기 훨씬 수월해집니다.

---
source_url: https://example.com/blog/distributed-tracing
captured: 2026-10-26
type: article           # article | paper | transcript | adr | incident-postmortem
domain: infra           # ai | infra | security | backend
project: payments-v2    # 특정 프로젝트 연관 시 기재
---

4. 도메인 vs 프로젝트 구성: 하이브리드 패턴

위키가 커지면 단일 폴더 구조로는 지식이 뒤섞입니다. 구조 설계에는 크게 세 가지 패턴이 있습니다.

패턴 비교

[패턴 A: 도메인 중심]
raw/
├── ai/papers/
├── infra/runbooks/
└── security/articles/
* 장점: 개념별로 지식이 모여 재사용성이 높음
* 단점: "특정 프로젝트나 릴리즈에서 무엇을 결정했는가?"를 추적하기 어려움

[패턴 B: 프로젝트 중심]
raw/
├── project-payments/ (requirements, adr, postmortems)
└── project-search/
* 장점: 프로젝트 라이프사이클 종료 후 아카이브가 쉽고 권한 격리가 명확함
* 단점: Kafka, Redis 같은 동일 기술 개념이 프로젝트마다 중복 생성됨

[패턴 C: 하이브리드 패턴 (적극 권장)]
raw/
├── domains/              # 지속적인 기술 영역 (ai, infra, backend)
│   ├── ai/
│   └── infra/
├── projects/             # 생명주기가 있는 프로젝트/제품
│   ├── payments-v2/
│   └── search-revamp/
└── inbox/                # 미분류 임시 수집함 (Ingest 시 LLM이 분류 제안)

하이브리드 패턴에서 wiki/ 디렉토리는 다음과 같이 매핑됩니다.

wiki/
├── domains/ai/...         # 범용 기술 개념 및 방법론 비교
├── projects/payments-v2/  # 프로젝트별 아키텍처 결정, 릴리즈 히스토리
└── shared/entities/       # 공용 엔티티 (사내 인프라 클러스터, 팀, 외부 벤더)

지식 연결 및 승격(Promotion) 규칙

단방향 링크 원칙: projects/payments-v2/의 ADR 문서는 domains/infra/kafka-partitioning.md 개념 페이지를 링크로 참조합니다. 프로젝트 폴더 안에 Kafka 개념을 중복 서술하지 않습니다.
지식 승격 규칙: 특정 프로젝트를 진행하며 검증된 모범 사례(Best Practice)나 인프라 튜닝 팁은 프로젝트 종료 시 domains/ 상위 지식으로 승격(Promote)하여 전사 자산화합니다.

5. 실전 시나리오 기반 활용 3선

시나리오 1. 기술·논문 리서치 지식 베이스 (개인 연구)

수많은 AI 논문과 기술 문서를 읽고 나면 머릿속에서 흩어지기 쉽습니다. LLM Wiki는 지속 가능한 문헌 리뷰(Literature Review) 시스템이 됩니다.

Raw 저장소: raw/domains/ai/papers/2026-10-20_deepseek_v3.pdf.md, Arxiv 요약본

Ingest 프롬프트 예시:

raw/domains/ai/papers/2026-10-20_xxx.md 문서를 ingest해줘.
1. sources/ 하위에 핵심 기여도와 벤치마크를 요약한 페이지를 생성해줘.
2. concepts/ 하위의 관련 개념(예: MoE, Multi-head Latent Attention) 페이지를 찾아 최신 내용을 보강해줘.
3. 만약 기존 위키 내용과 상충하는 주장이나 성능 수치가 있다면 '충돌 및 논쟁점' 섹션에 명시해줘.
4. index.md와 log.md를 갱신해줘.

질의(Query) 예시:
- “최근 수집한 논문들을 바탕으로 MoE 라우팅 알고리즘의 트레이드오프를 표로 정리해줘.”
- “내가 수집한 논문들 중 아직 커버하지 않은 기술적 공백(Gap)은 무엇인가?”

시나리오 2. 팀 엔지니어링 & DevOps 지식 베이스 (프로젝트 기반)

개발팀의 장애 보고서(Postmortem), 아키텍처 결정 기록(ADR), 온콜 인수인계 문서는 시간이 지나면 방치되기 일쑤입니다.

raw/projects/payments-v2/
├── adr/
│   └── 2026-05-10_adr-012-use-postgres-for-ledger.md
├── incidents/
│   └── 2026-08-14_postmortem-connection-pool-exhaustion.md
└── meetings/

Wiki 산출물: 서비스별 장애 패턴 사전, DB 튜닝 히스토리, 신규 입사자용 온보딩 가이드
실전 질의 예시:
- “결제 시스템에서 지난 6개월간 발생한 장애 5건의 공통 근본 원인은 무엇인가?”
- “원장 DB로 DynamoDB 대신 PostgreSQL을 선택했던 근거와 제약 사항은 무엇이었나? (출처 ADR 링크 포함할 것)”
DevOps 팁: 사내 기밀이나 개인정보가 포함될 수 있으므로, 프로젝트별 리포지토리를 분리하고 git submodule 또는 접근 권한(ACL)을 적용하는 것이 좋습니다.

시나리오 3. 경쟁사 및 제품 시계열 리서치

기술 동향, 경쟁 오픈소스 릴리즈 노트, 경쟁사 제품 변경점을 시계열로 분석할 때 유용합니다.

Raw 저장소: raw/domains/competitors/ 아래에 제품 릴리즈 로그, 채용 공고, 기술 블로그 아카이브
Wiki 산출물: 기능 매트릭스, 채용 기반 전략 분석, 사용자 불만 포인트
실전 질의 예시:
- “경쟁사 A가 최근 채용 공고에서 강조하는 인프라 스택의 변화와 그 의미는?”
- “경쟁 제품 대비 우리 오픈소스 도구가 제공하는 명확한 장단점을 Marp 슬라이드(outputs/presentation.md)로 작성해줘.”

6. 검색(Query) 파이프라인과 Lint 운영

5단계 검색 파이프라인

질의가 들어왔을 때 LLM은 다음과 같은 루프로 답변을 도출합니다.

질문 인입
  │
  ▼
① [index.md 확인] ─── 전체 카탈로그에서 어떤 wiki 페이지가 연관되어 있는가?
  │
  ▼
② [wiki 페이지 로드] ── 관련 개념/종합 페이지를 열고 링크 관계를 따라 확장 탐색
  │
  ▼
③ [필요 시 raw 교차 검증] ── 구체적 데이터나 근거 수치가 맞는지 raw 원본 대조
  │
  ▼
④ [답변 생성] ────────── 반드시 wiki/raw 출처 링크가 달린 감사 가능한 답변 생성
  │
  ▼
⑤ [지식 환류(Feedback)] ── 통찰력 있는 분석 답변은 wiki/syntheses/ 에 새 페이지로 영구 저장

질문의 결과가 단순 소비로 끝나지 않고 다시 위키의 자산이 되는 **‘복리 구조(Compounding Knowledge)’**가 핵심입니다.

Drift를 막는 4대 Lint 체크리스트

문서는 방치하면 반드시 현실과 괴리가 생깁니다(Drift). LLM에게 정기적으로 다음과 같은 Lint 작업을 지시합니다.

상충하는 주장 (Contradictions): A 문서에서는 지원한다고 했는데 B 문서에서는 미지원이라고 적힌 항목 검출
오래된 주장 (Stale Claims): 새로운 버전 릴리즈로 인해 무효화된 과거 런북 내용 검출
고아 페이지 (Orphan Pages): index.md에 등재되지 않았거나, 다른 문서로부터 단 하나의 인바운드 링크도 없는 고립 문서 탐색
근거 없는 주장 (Uncited Statements): wiki/ 본문 내용 중 raw/ 원본 링크가 누락된 문장 표시

7. 대규모 운영 시 한계와 대응 방안

Karpathy의 아이디어는 매우 우아하지만, 실제 운영 규모가 커지면 다음과 같은 현실적인 벽에 부딪힙니다.

인덱스 비대화: wiki/ 문서가 500~1,000개를 넘어가면 index.md 자체의 토큰 수가 커져 한 번에 LLM 컨텍스트에 싣기 부담스러워집니다.
- 대응: 최상위 인덱스는 도메인별 라우팅만 담당하게 하고(index-ai.md, index-infra.md), 서브 인덱스 체계로 계층화합니다.
검색 한계: LLM의 순수 텍스트 탐색만으로는 키워드 검색의 정확도를 따라가기 어렵습니다.
- 대응: 로컬 BM25(ripgrep 기반) 검색이나 경량 벡터 임베딩을 보조 도구로 붙여, LLM이 탐색할 후보군을 1차 필터링하는 하이브리드 검색을 구축합니다.
일관성 유지 비용: 여러 LLM 에이전트가 동시에 위키를 갱신하면 톤앤매너나 프론트매터 스키마가 어긋날 수 있습니다.
- 대응: CLAUDE.md 스키마 파일에 명확한 출력 제약과 Few-shot 예시를 강제해야 합니다.

8. 시작하기: 최소 실행 템플릿 (`CLAUDE.md`)

오늘 바로 로컬 폴더에서 시작해볼 수 있는 최소 스키마 템플릿입니다. 프로젝트 루트에 CLAUDE.md로 저장하고 에이전트를 실행해 보세요.

# LLM Wiki Operating Schema

당신은 이 지식 위키의 사서이자 편집자입니다. 아래 규칙을 엄격히 준수하세요.

## 핵심 규칙
1. `raw/` 디렉토리는 절대 수정하거나 삭제하지 마세요. (Read-only)
2. 모든 `wiki/` 페이지의 핵심 주장 끝에는 반드시 근거가 된 `raw/...` 링크를 표기하세요.
3. 새로운 지식을 수집(Ingest)할 때:
   - `wiki/sources/<filename>.md` 요약을 작성합니다.
   - 관련 `wiki/concepts/` 및 `wiki/entities/` 페이지를 찾아 내용을 누적 갱신합니다.
   - `wiki/index.md`에 새 문서를 한 줄 설명과 함께 등록합니다.
   - `wiki/log.md`에 `## [YYYY-MM-DD] ingest | <파일명>` 형태로 기록합니다.
4. 기존 위키 내용과 새로운 소스가 충돌할 경우 임의로 지우지 말고 "## 상충 및 변경 이력" 섹션에 두 관점을 모두 기록하세요.

마치며: 지식 베이스의 미래는 ‘엔지니어링’이다

지금까지 우리는 문서를 사람이 직접 쓰고, 검색은 검색 엔진이나 단순 RAG에 의존해 왔습니다. 하지만 문서의 양이 폭증하는 환경에서 진정한 생산성은 **“지식을 정리하고 관리하는 운영 루프”**를 시스템화하는 데서 나옵니다.

LLM Wiki에서 사람의 역할은 한 문장씩 글을 작성하는 노동자가 아니라, LLM이 지식을 올바르게 편집하도록 스키마(CLAUDE.md)를 설계하고, 원본 데이터를 큐레이션하며, Lint 결과를 검토하는 아키텍트로 전환됩니다.

지식이 금방 휘발되는 단순 챗봇이나 매번 제자리걸음인 RAG에 답답함을 느끼셨다면, 여러분의 로컬 터미널과 Obsidian 폴더 위에 나만의 LLM Wiki를 직접 구축해 보시길 권합니다.

1. RAG vs LLM Wiki: 지식이 머무는 위치의 차이#

핵심 3계층과 3대 오퍼레이션#

2. 권장 디렉토리 구조: 기본형 설계#

각 요소별 핵심 역할#

3. raw 폴더의 5대 원칙과 파일 작성 규칙#

raw 운영의 5대 원칙#

권장 파일명 및 메타데이터 형식#

4. 도메인 vs 프로젝트 구성: 하이브리드 패턴#

패턴 비교#

지식 연결 및 승격(Promotion) 규칙#

5. 실전 시나리오 기반 활용 3선#

시나리오 1. 기술·논문 리서치 지식 베이스 (개인 연구)#

시나리오 2. 팀 엔지니어링 & DevOps 지식 베이스 (프로젝트 기반)#

시나리오 3. 경쟁사 및 제품 시계열 리서치#

6. 검색(Query) 파이프라인과 Lint 운영#

5단계 검색 파이프라인#

Drift를 막는 4대 Lint 체크리스트#

7. 대규모 운영 시 한계와 대응 방안#

8. 시작하기: 최소 실행 템플릿 (CLAUDE.md)#

마치며: 지식 베이스의 미래는 ‘엔지니어링’이다#