LLM Wiki 완전 가이드: Claude Code로 쌓이는 AI 지식 베이스 만들기

이 문서는 무엇인가

글, 논문, 회의록을 ChatGPT나 NotebookLM에 자주 넣어 보셨다면, 아마 같은 일을 겪으셨을 겁니다. 같은 자료를 며칠 뒤에 다시 물어보면 AI가 처음부터 다시 읽는다는 것입니다. 예전에 던진 질문과 AI가 정리해 준 결론은 다음 대화에서는 사라집니다.

Andrej Karpathy가 GitHub에 공개한 gist의 제목은 LLM Wiki입니다. 이 gist는 다른 방식을 제안합니다. LLM이 모은 자료를 계속 업데이트되는 markdown wiki로 정리하게 하고, 여러분은 자료를 찾고 질문하는 역할을 맡으며, 정리·상호 참조·기록 같은 잡일은 모두 LLM에게 맡기는 방식입니다.

이 지침은 그 gist를 직접 해 볼 수 있는 단계로 나누어 설명하며, Claude Code로 시연합니다.

이 문서를 읽는 방법

처음 읽는다면 처음부터 “15분 만에 첫 Wiki 만들기”까지 읽고 따라 해 보실 것을 권합니다. 그러면 바로 사용할 수 있습니다. 이후 장은 사용하면서 필요할 때 다시 찾아 보시면 됩니다.

원문의 내용과 이 지침의 설계

Karpathy의 gist는 스스로를 idea file이라고 설명합니다. 개념만 기술할 뿐이며, 구체적인 디렉터리 구조, 페이지 형식, 도구는 여러분과 여러분의 LLM Agent가 함께 정해야 한다는 것입니다.

따라서 이 지침은 두 종류의 내용으로 나뉩니다:

• 원문의 개념: 3계층 구조, Ingest·Query·Lint 세 가지 작업, index.md와 log.md 두 특수 파일. 각 장에서 gist 출처를 표시합니다.
• 구현 설계: 폴더 이름, Schema 템플릿, 프롬프트. 이는 제가 정리한 방식 중 하나이며, 그대로 사용하셔도 되고 여러분의 분야에 맞게 조정하셔도 됩니다.

시연 환경

• LLM Agent로 Claude Code를 사용하고, wiki 폴더에서 실행합니다.
• 읽는 쪽으로 Obsidian을 사용하여, LLM이 방금 어떤 페이지를 수정했는지 열어 봅니다.
• Wiki 자체가 markdown을 담은 git repository입니다.

저도 Obsidian과 Notion을 함께 쓰고 있습니다. 이 지침의 절차는 특정 소프트웨어에 묶여 있지 않으며, LLM이 그 markdown 파일을 읽고 쓸 수 있다면 작동합니다.

다음 단계

먼저 아무것도 설치할 필요는 없습니다. 한동안 모아 두었지만 여기저기 흩어져 있는 주제를 하나 꺼내 보십시오. 예를 들어 특정 프레임워크에 관한 글, 지금 읽고 있는 책, 어떤 고객의 회의록 등이 있습니다. 다음 장에서 이 주제로 RAG와 LLM Wiki의 차이를 비교해 보겠습니다.

출처: Andrej Karpathy의 LLM Wiki gist(2026-11-05 확인).

RAG가 지식을 누적하지 않는 이유

문서 열 개를 NotebookLM이나 ChatGPT의 파일 업로드 기능에 넣고, 다섯 개의 문서를 종합해야 답할 수 있는 질문을 던졌다고 해 봅시다. 그러면 AI는 파일에서 관련 조각을 찾아 와서 답변을 조합합니다.

다음 날 비슷한 질문을 하면 AI는 또다시 처음부터 찾고 처음부터 조합합니다. 전날 조합한 결론은 어디에도 남아 있지 않습니다.

RAG의 방식

RAG(Retrieval-Augmented Generation, 검색 증강 생성)의 흐름은 다음과 같습니다:

1. 문서를 조각으로 나누고 인덱스를 만듭니다.
2. 질문하면 시스템이 가장 관련 있는 몇 개의 조각을 찾아냅니다.
3. 그 조각들과 질문을 함께 LLM에 넘겨 답변을 생성합니다.

Karpathy의 gist는 NotebookLM, ChatGPT의 파일 업로드, 그리고 대부분의 RAG 시스템이 이렇게 동작한다고 지적합니다. 질문할 때마다 LLM은 원본 문서에서 지식을 다시 발견하며, 아무것도 누적되지 않습니다.

LLM Wiki의 방식

LLM Wiki는 시점을 앞으로 당깁니다. 새 자료를 넣을 때마다 LLM이 먼저 읽고 핵심을 뽑아낸 뒤, 그 내용을 이미 존재하는 wiki에 통합합니다. 관련 페이지를 업데이트하고, 요약을 고치며, 새 자료가 기존 설명과 모순되는 부분을 표시합니다.

지식은 한 번만 정리하면 되고 이후 계속 최신 상태를 유지하므로, 질문할 때마다 다시 추론할 필요가 없습니다. gist는 이 차이를 한 문장으로 설명합니다. wiki는 지속적으로 쌓이는 결과물이며, 상호 참조는 이미 구축되어 있고, 모순은 이미 표시되어 있으며, 통합된 결론에는 읽은 모든 자료가 반영되어 있다는 것입니다.

비교표

언제 여전히 RAG를 써야 할까

LLM Wiki가 RAG를 대체하려는 것은 아닙니다. 다음 두 경우에는 RAG가 더 적합합니다:

• 자료 양이 매우 많고 특정 조각만 찾으면 되는 경우: 예를 들어 고객 응대 챗봇이 수천 건의 문서에서 특정 규정 하나를 찾는 경우에는 문서를 하나의 전체적인 이해로 통합할 필요가 없습니다.
• 자료를 여러분이 직접 누적하지 않는 경우: 예를 들어 공개 문서 라이브러리를 조회만 하면 되고, 그것을 직접 관리하며 정리된 버전을 유지할 필요가 없는 경우입니다.

gist는 index.md 같은 목차 방식이 약 100개 소스, 수백 페이지 규모에서 잘 작동하며 별도의 embedding 검색을 만들 필요가 없다고 설명합니다. 이 규모를 넘어서면 검색 도구를 더하는 방법을 뒤의 장에서 소개합니다.

제가 전에 쓴 글 중에는 N8N, Google Drive, Pinecone으로 고객 응대 챗봇을 만든 글이 있습니다. 전형적인 RAG 사례이므로 이 지침과 함께 읽어 보시면 좋습니다: N8N과 Google Drive, RAG로 기업 전용 Line 고객 서비스 AI 챗봇 만들기 (繁體中文)

다음 단계

앞 장에서 고른 주제로 돌아가서, LLM에게 가장 자주 반복해서 묻는 질문 세 가지를 적어 보십시오. 세 질문의 답이 모두 여러 문서를 종합해야 하는 것이라면, 그 주제는 LLM Wiki로 만들기에 적합합니다.

출처: Andrej Karpathy의 LLM Wiki gist의 The core idea 및 Indexing and logging 절(2026-11-05 확인). 대조표의 “해야 할 일” 행은 이 지침이 정리한 내용입니다.

3계층 구조

LLM이 wiki를 장기적으로 유지 관리하게 하려면 먼저 “누가 무엇을 바꿀 수 있는지”를 분명히 나눠야 합니다. 원본 자료와 정리된 페이지가 같은 폴더에 섞여 있으면, LLM은 정리하면서 원문까지 고쳐 버리기 쉽습니다. 몇 주만 지나면 어느 것이 원문이고 어느 것이 LLM의 해석인지 구분할 수 없게 됩니다.

gist는 전체 시스템을 세 개의 계층으로 나눕니다.

세 계층의 역할

Raw sources: 변경할 수 없는 원본 자료

이 계층은 여러분의 단일 진실 공급원(source of truth)입니다. LLM은 여기서 읽기만 하고 수정하지 않습니다. 이렇게 하면 두 가지 이점이 있습니다. wiki 페이지의 어떤 설명이든 원본 자료로 돌아가 확인할 수 있고, LLM이 잘못 정리하더라도 원문이 남아 있어 다시 시작할 수 있습니다.

Wiki: LLM이 소유하는 계층

wiki는 markdown 파일로 가득 찬 폴더입니다. LLM은 페이지를 만들고, 새 자료가 들어오면 페이지를 업데이트하며, 페이지 간 링크를 관리하고, 내용의 일관성을 유지합니다. 여러분은 읽는 역할을 맡습니다.

gist는 소프트웨어 개발에 빗대어 설명합니다. Obsidian은 IDE, LLM은 엔지니어, wiki는 코드베이스입니다. 여러분은 Obsidian을 열어 살펴보고, LLM은 대화를 바탕으로 파일을 수정하며, 여러분은 그 결과를 실시간으로 확인합니다.

Schema: LLM을 체계적인 관리자로 만드는 문서

Schema는 LLM에게 이 wiki의 구조, 이름 짓기 규칙, 그리고 새 자료를 받았을 때, 질문에 답할 때, 점검할 때 따라야 할 절차를 알려 주는 문서입니다. Claude Code는 CLAUDE.md를, Codex는 AGENTS.md를 읽습니다.

Schema가 없으면 LLM은 그저 일반적인 챗봇이어서, 대화할 때마다 다른 방식으로 정리합니다. Schema가 있으면 새 세션마다 같은 규칙에서 시작합니다. gist는 또한 이 문서를 사용하면서 점차 다듬어 여러분의 분야에 맞는 방식을 찾아야 한다고 강조합니다.

폴더 구조

이 지침에서 예시로 사용하는 구조입니다:

my-wiki/
├── CLAUDE.md          # schema
├── raw/               # sources, read-only
│   └── assets/        # downloaded images
└── wiki/              # owned by the LLM
    ├── index.md       # catalog of all pages
    ├── log.md         # append-only timeline
    ├── sources/       # one summary page per source
    ├── entities/      # people, products, organizations
    └── concepts/      # ideas and topics

sources, entities, concepts 세 하위 폴더는 이 지침의 설계입니다. gist는 wiki에 요약, 엔티티 페이지, 개념 페이지, 비교, 개요가 있을 것이라고만 언급하며 폴더 구성은 정하지 않습니다. 여러분의 분야가 이렇게 나뉘지 않는다면 적합한 방식으로 바꾸면 되며, 다만 Schema에 반드시 기록해 두십시오.

다음 단계

컴퓨터에 my-wiki라는 이름의 빈 폴더를 만드십시오. 아직 아무 파일도 넣지 마십시오. 다음 장에서는 이 빈 폴더에서 시작해 Claude Code로 전체 구조를 만들겠습니다.

출처: Andrej Karpathy의 LLM Wiki gist의 Architecture 및 The core idea 절(2026-11-05 확인). 폴더 구조는 이 지침의 설계입니다.

15분 만에 첫 Wiki 만들기

LLM Wiki를 실제로 써 보면 어떤지 알고 싶다면 순서대로 따라 해 보십시오. 마치면 실제로 작동하는 wiki가 생기고, 첫 번째 자료도 넣게 됩니다.

1. 폴더 만들기

mkdir -p my-wiki/raw/assets my-wiki/wiki/{sources,entities,concepts}  # 1. Folders
cd my-wiki
touch CLAUDE.md wiki/index.md wiki/log.md                             # 2. Empty files
git init                                                              # 3. Version history

git init은 의도적으로 넣은 단계입니다. wiki는 markdown을 담은 repository이므로, LLM이 수정을 마칠 때마다 git diff로 어떤 페이지가 바뀌었는지 확인하고, 마음에 들지 않으면 되돌릴 수 있습니다.

2. 최소 버전의 Schema 작성하기

CLAUDE.md를 열고 아래의 짧은 내용을 먼저 붙여 넣으십시오. 전체 템플릿은 다음 장에 있으며, 지금은 LLM이 가장 기본적인 규칙만 알면 됩니다:

# My Wiki

이것은 LLM이 관리하는 개인 지식 베이스이며, 주제는 다음과 같습니다: <주제>

## 디렉터리

- `raw/`: 원본 자료, 읽기 전용, 수정 불가
- `wiki/`: 여러분이 관리하는 페이지
- `wiki/index.md`: 모든 페이지의 목차, ingest할 때마다 업데이트
- `wiki/log.md`: 시간순으로 한 작업 기록, 뒤에만 추가할 수 있음

## 규칙

- 모든 wiki 페이지는 한국어로 작성
- 페이지 사이의 링크는 `[[페이지 이름]]` 사용
- 페이지를 추가하거나 수정한 뒤에는 반드시 `wiki/index.md`를 업데이트하고 `wiki/log.md`에 항목을 하나 추가

3. 첫 번째 자료 넣기

정리하고 싶은 글을 하나 골라 markdown으로 저장한 뒤 raw/에 넣으십시오. 글이 웹에 있다면 브라우저 확장 프로그램(예: Obsidian Web Clipper)으로 markdown으로 변환하거나, 그냥 복사해서 붙여 넣어도 됩니다:

cat > raw/first-article.md   # Paste the article, then Ctrl+D

4. Claude Code를 실행하고 첫 번째 Ingest 실행하기

claude   # Start in the my-wiki folder

그다음 입력합니다:

raw/first-article.md를 읽고, CLAUDE.md의 규칙에 따라 wiki에 정리하십시오.
먼저 읽은 핵심 세 가지를 알려 주고, 그다음 페이지 작성을 시작하십시오.

Claude Code는 먼저 핵심 내용을 여러분과 논의하고, 확인을 받은 뒤 요약 페이지와 관련 개념 페이지를 만들고, index.md를 업데이트하며, log.md에 항목을 하나 추가합니다.

5. 결과 확인하기

git status --short   # Which files changed
git diff             # What exactly changed
cat wiki/log.md      # The new log entry

확인할 것은 세 가지입니다: wiki/sources/ 아래에 새 요약 페이지가 생겼는지, wiki/index.md에 해당 항목이 추가되었는지, log.md의 마지막 줄이 ## [날짜] ingest | 글 제목 형식인지.

마음에 들면 git add -A && git commit -m "ingest: first-article"을 실행하십시오. 마음에 들지 않으면 Claude Code에 고칠 부분을 알려 주고, 수정이 끝나면 diff를 다시 확인하십시오.

자주 발생하는 상황

다음 단계

한 가지만 해 보실 것을 권합니다. 같은 주제의 두 번째 자료를 넣고 4단계를 반복하십시오. 첫 번째와 두 번째 git diff를 비교해 보면, 두 번째에는 LLM이 새 페이지를 추가하는 데서 그치지 않고 기존 페이지도 수정한 것을 볼 수 있을 것입니다. 이것이 LLM Wiki가 단순한 요약 도구와 다른 점입니다.

출처: Andrej Karpathy의 LLM Wiki gist의 Operations 및 Indexing and logging 절(2026-11-05 확인). 명령어와 Schema 내용은 이 지침의 설계입니다.

Schema 잘 작성하기

Schema는 전체 시스템에서 가장 중요한 파일입니다. LLM 자체에는 기억이 없어서 새 세션마다 처음부터 시작하며, CLAUDE.md를 통해서만 이 wiki가 어떤 모습인지, 이번에 어떤 절차를 따라야 하는지 알 수 있습니다.

gist는 Schema를 핵심 설정 파일이라고 부릅니다. 이 파일은 LLM을 일반 챗봇이 아니라 체계적인 wiki 관리자로 만들어 줍니다. 또한 이 문서는 여러분과 LLM이 사용하는 과정에서 함께 다듬어 가는 것이라고 강조합니다.

Schema에 담아야 할 내용

전체 템플릿

아래 내용은 그대로 복사해 CLAUDE.md로 사용할 수 있습니다. 「주제」와 「페이지 유형」은 여러분의 분야에 맞게 바꾸십시오:

# My Wiki

이것은 LLM이 관리하는 지식 베이스이며, 주제는 <주제>입니다.
당신은 wiki를 정리하고 관리하며, 저는 자료를 고르고 질문합니다.

## 디렉터리 구조

- `raw/`: 원본 자료입니다. 읽기 전용이며 절대 수정하거나 삭제하면 안 됩니다.
- `raw/assets/`: 원본 자료에 포함된 이미지입니다.
- `wiki/`: 당신이 관리하는 페이지입니다. 정리된 모든 내용은 여기에 둡니다.
- `wiki/index.md`: 모든 페이지의 목차입니다.
- `wiki/log.md`: 시간순 기록이며, 뒤에만 추가할 수 있습니다.
- `wiki/sources/`: 원본 자료 한 건당 요약 페이지 한 장입니다.
- `wiki/entities/`: 인물, 제품, 조직이며, 대상 하나당 페이지 하나입니다.
- `wiki/concepts/`: 개념과 주제이며, 개념 하나당 페이지 하나입니다.

## 페이지 형식

모든 페이지에는 frontmatter가 있어야 합니다:

```yaml
---
type: source | entity | concept
tags: []
sources: [] # 이 페이지의 근거가 되는 raw/ 파일
updated: YYYY-MM-DD
---
```

- 파일 이름은 소문자 영문과 하이픈을 사용합니다. 예: `retrieval-augmented-generation.md`
- 페이지 사이의 링크는 `[[파일 이름]]`을 사용하며, 확장자는 붙이지 않습니다.
- 모든 논점에는 어느 `sources/` 페이지에서 나왔는지 표시합니다.
- 요약 페이지의 마지막에는 항상 "기존 내용과의 관계" 절을 두고, 이 자료가 어떤 페이지를 보완, 수정 또는 반박하는지 명시합니다.

## Ingest: 새 자료를 받았을 때

1. `raw/`에서 지정된 파일을 읽습니다.
2. 먼저 핵심 3~5가지를 알려 주고, 제 답변을 받은 뒤에 계속 진행하세요.
3. `wiki/sources/`에 요약 페이지를 만듭니다.
4. 관련된 entities 및 concepts 페이지를 업데이트합니다. 대응하는 페이지가 없는 중요한 개념은 새 페이지를 만듭니다.
5. 새 자료가 기존 설명과 모순되면 양쪽을 모두 보존하고, 페이지에 모순을 명확히 표시합니다.
6. `wiki/index.md`를 업데이트합니다.
7. `wiki/log.md`에 항목을 하나 추가합니다.

## Query: 질문에 답하기

1. 먼저 `wiki/index.md`를 읽고 관련 페이지를 찾은 다음, 그 페이지들을 읽습니다.
2. 답변할 때 출처 페이지를 표시합니다.
3. 답변이 새로운 통합, 비교 또는 결론이라면 wiki 페이지로 저장할지 저에게 물어보세요.

## Lint: 점검

점검하고 보고하되, 수정하기 전에 먼저 저에게 물어보세요:

- 페이지 사이에 서로 모순되는 설명
- 새 자료로 대체된 낡은 설명
- 어떤 페이지에서도 링크되지 않은 고아 페이지
- 여러 번 언급되지만 독립된 페이지가 없는 개념
- 빠진 상호 링크
- 웹 검색으로 보완할 수 있는 자료의 공백

## log.md 형식

각 항목은 고정된 접두사로 시작합니다:

```text
## [YYYY-MM-DD] ingest | 자료 제목
## [YYYY-MM-DD] query | 질문 요약
## [YYYY-MM-DD] lint | 점검 범위
```

그 아래에 변경한 페이지를 1~3줄로 설명합니다.

Schema를 조정할 시점

이 템플릿은 출발점입니다. 실제로 사용하다 보면 아래와 같은 상황이 Schema를 다시 고쳐야 할 신호입니다:

• 같은 일을 LLM에게 매번 말로 바로잡고 있다면, 그 내용을 Schema에 적으십시오.
• 특정 유형의 페이지에 고정된 필드가 필요하다는 것을 알게 되면(예: 책의 저자와 출판연도), 페이지 형식에 추가하십시오.
• 자료 하나가 간단한 처리만 필요한 경우가 많다면, “가벼운 ingest” 절차를 따로 적으십시오.

gist는 한 번에 자료 한 건씩 처리하고 전 과정에 참여할지, 아니면 여러 건을 한꺼번에 일괄 처리하고 개입을 줄일지를 직접 정한 다음, 선택한 절차를 Schema에 적으라고 권합니다. 그래야 다음 세션에서 LLM이 그 절차를 따릅니다.

다음 단계

위 템플릿을 복사해서 두 군데만 고치십시오. 주제와 페이지 유형입니다. 그다음 Claude Code에서 /memory를 입력해 CLAUDE.md가 로드되었는지 확인하십시오. 로드 방식과 경로 규칙은 Claude Code 가이드의 CLAUDE.md와 메모리 시스템을 참고하십시오.

출처: Andrej Karpathy의 LLM Wiki gist의 The schema 및 Operations 절(2026-11-05 확인). 템플릿 내용은 이 지침의 설계입니다.

Ingest: 소스 한 건 넣기

Ingest는 LLM Wiki에서 매일 하게 되는 작업입니다. 새 자료 한 건을 LLM에게 넘겨 wiki에 통합하도록 하는 것입니다. 이 단계를 얼마나 잘하느냐에 따라 wiki가 사용할수록 가치가 커지는지가 결정됩니다.

Ingest가 실제로 하는 일

gist가 설명하는 절차는 다음과 같습니다:

1. LLM이 소스를 읽고 여러분과 핵심 내용을 논의합니다.
2. wiki에 요약 페이지를 한 장 씁니다.
3. index.md를 업데이트합니다.
4. wiki 전반에 걸친 관련 엔티티 페이지와 개념 페이지를 업데이트합니다.
5. log.md에 기록 항목을 하나 추가합니다.

소스 하나가 동시에 10~15개의 페이지에 영향을 줄 수 있습니다. 이것이 사람이 wiki를 장기간 유지하기 어려운 이유이기도 합니다. 읽을 양이 많아서가 아니라, 매번 그만큼 많은 곳을 업데이트해야 하기 때문입니다.

한 건씩 할까, 여러 건을 한꺼번에 할까

gist의 저자 본인은 한 건씩 전 과정에 참여하는 방식을 선호합니다. 처음에도 이 방식을 권하며, Schema가 안정된 뒤에 일괄 처리로 쌓여 있던 많은 기존 자료를 처리하는 것이 좋습니다.

프롬프트 예시

한 건씩 처리할 때:

raw/rag-survey.md를 읽고, CLAUDE.md의 Ingest 절차에 따라 wiki에 정리하십시오.
먼저 읽은 핵심을 알려 주고, 제가 확인한 뒤에 페이지를 수정하기 시작하십시오.
이번 자료에서 특히 강조하고 싶은 점은 검색 전략의 비교입니다.

일괄 처리할 때:

raw/inbox/ 아래에 새 자료 12건이 있습니다.
CLAUDE.md의 Ingest 절차에 따라 한 건씩 처리하고, 각 건을 처리할 때마다 log.md에 항목을 하나씩 추가하십시오.
모두 끝나면 수정한 페이지와 모순이 있는 부분을 나열하십시오.

LLM이 제대로 했는지 확인하는 방법

LLM이 “완료했습니다”라고 말하는 것만 믿지 말고, git으로 실제 변경 사항을 확인하십시오:

git diff --stat      # Files touched and line counts
git diff wiki/       # Full content of the changes
git log --oneline -5 # Recent commits

네 가지를 확인하십시오:

• raw/를 수정했는지: git diff --stat raw/의 출력이 없어야 합니다.
• 요약 페이지에 “기존 내용과의 관계”가 있는지: 기존 페이지와 비교했는지 확인하는 지점입니다.
• index.md에 해당하는 새 항목이 있는지.
• log.md 마지막 항목의 형식: 예: ## [2026-11-05] ingest | RAG 연구 종합

모순은 보존하고, 조용히 덮어쓰지 않기

새 자료와 기존 페이지의 설명이 다를 때 가장 위험한 것은 LLM이 낡은 내용을 바로 새 내용으로 바꿔 버리는 것입니다. 어느 쪽이 맞는지 알 수 없게 되고, ‘이 관점이 뒤집힌 적이 있다’는 기록도 사라집니다.

Schema 템플릿에는 이미 양쪽을 모두 보존하고 모순을 명확히 표시하라고 적혀 있습니다. Ingest 후 diff를 볼 때는 이런 표시를 특히 찾아서, 어느 쪽을 채택할지 결정하십시오.

다음 단계

손에 있는 자료 중 가장 긴 것을 하나 골라 「한 건씩」 방식으로 Ingest를 한 번 해 보십시오. 마친 뒤 git diff --stat으로 몇 개의 페이지가 바뀌었는지 세어 보십시오. 요약 페이지 하나만 바뀌었다면, CLAUDE.md의 Ingest 절차 4단계가 명확하게 적혀 있는지 다시 확인하십시오.

출처: Andrej Karpathy의 LLM Wiki gist의 Operations 절 중 Ingest 단락(2026-11-05 확인). 프롬프트와 확인 항목은 이 지침의 설계입니다.

Query: 질문하고 답변을 wiki에 다시 저장하기

wiki를 만들고 나면 그 wiki에 바로 질문할 수 있습니다. 이 단계가 일반 채팅과 가장 크게 다른 점은, 좋은 답변을 대화 기록에만 두지 않고 wiki에 저장해 다음에 바로 인용할 수 있는 한 페이지로 만든다는 것입니다.

LLM이 답을 찾는 방법

gist의 방식에 따르면, LLM은 질문에 답할 때 다음과 같이 합니다:

1. index.md를 먼저 읽고 관련 가능성이 있는 페이지를 찾습니다.
2. 그다음 그 페이지들을 열어 내용을 읽습니다.
3. 통합한 뒤 답하고, 인용한 페이지를 표시합니다.

이 방식은 약 100개의 소스, 수백 페이지 규모에서 잘 작동하며, 별도의 embedding 검색을 만들 필요가 없습니다. index.md가 LLM의 지도이므로, Ingest할 때 반드시 잘 관리해야 합니다.

답변이 꼭 글일 필요는 없습니다

gist는 질문에 따라 답변의 형식을 다르게 고를 수 있다고 언급합니다:

프롬프트 예시

wiki에 언급된 세 가지 검색 전략을 비교하여 표로 보여 주고,
각 칸마다 출처 페이지를 표시하십시오.

wiki의 내용을 바탕으로, 제가 회사 내부에 RAG를 도입한다면 가장 큰 위험은 무엇입니까?
답변에는 근거가 되는 페이지를 표시하고, wiki의 현재 자료가 부족한 부분도 짚어 주십시오.

두 번째 프롬프트의 마지막 문장이 중요합니다. 자료가 부족한 부분을 짚어 달라고 요청하면, LLM이 자신의 지식으로 그럴듯해 보이지만 wiki에는 없는 내용을 채워 넣는 것을 막을 수 있습니다.

어떤 답변을 wiki에 다시 저장할까

모든 답변을 저장할 가치가 있는 것은 아닙니다. 아래 세 가지 경우에는 새 페이지로 저장하는 것을 권합니다:

• 여러 페이지를 통합한 결론: 다음에 다시 조합할 필요가 없습니다.
• 여러분이 시간을 들여 추가로 묻고 수정한 답변: 그 과정 자체가 가치입니다.
• 나중에 다시 인용할 비교나 분석.

단순히 사실 하나를 확인하거나 일회성 질문이라면 저장할 필요가 없습니다.

저장할 때의 명령:

방금의 비교를 wiki/concepts/retrieval-strategies.md로 저장하십시오.
페이지 형식에 맞춰 frontmatter를 추가하고, index.md를 업데이트하며, log.md에 query 기록을 추가하십시오.

저장한 뒤에는 이 페이지도 Ingest로 만들어진 페이지와 똑같이 링크가 있고, Lint 점검을 받으며, 다음 Query에서 인용될 수 있습니다. 이렇게 여러분의 질문도 wiki에 쌓이게 됩니다.

다음 단계

wiki에 있는 내용으로, 최소 세 개의 페이지를 종합해야 답할 수 있는 질문을 하나 해 보십시오. 답변을 받으면 출처 페이지가 표시되어 있는지 확인하고, 답변이 보존할 가치가 있다면 위의 명령으로 새 페이지로 저장한 다음 git diff를 다시 확인하십시오.

출처: Andrej Karpathy의 LLM Wiki gist의 Operations 절 중 Query 단락 및 Indexing and logging 절(2026-11-05 확인). 프롬프트와 저장 판단 기준은 이 지침이 정리한 내용입니다.

Lint: 정기 점검

wiki를 몇 주 사용하다 보면 몇 가지 상황이 생기기 시작합니다. 같은 개념이 두 페이지에서 서로 다르게 설명되기도 하고, 어떤 결론이 새 자료로 이미 뒤집혔는데도 페이지는 예전 그대로이기도 하며, 작성이 끝난 뒤 아무도 링크하지 않는 페이지가 생기기도 합니다.

Lint는 정기적으로 LLM에게 wiki 전체를 점검하게 해서 이런 문제를 찾아내는 작업입니다.

점검 항목

gist가 나열한 점검 항목:

LLM은 다음에 어떤 새 질문을 연구하면 좋을지, 어떤 새 소스를 찾으면 좋을지도 잘 제안합니다.

프롬프트 예시

CLAUDE.md의 Lint 절차에 따라 wiki 전체를 점검하십시오.
모든 문제를 나열하되 심각도 순으로 정렬하고, 각 항목마다 관련 페이지를 표시하십시오.
아직 어떤 파일도 수정하지 마십시오. 제가 어떤 것을 처리할지 정할 때까지 기다리십시오.

Schema 템플릿에는 “점검하고 보고하되, 수정하기 전에 먼저 저에게 물어보세요”라고 적혀 있습니다. Lint의 수정 범위는 보통 크기 때문에, 목록을 먼저 확인한 뒤 어떤 항목을 고칠지 결정해야 하기 때문입니다.

명령어로 먼저 훑어보기

일부 항목은 LLM이 없어도 간단한 명령어로 찾을 수 있습니다. 아래는 고아 페이지를 찾는 방법입니다(페이지가 [[파일 이름]]으로 링크되어 있는 경우):

for f in $(find wiki -name '*.md' ! -name index.md ! -name log.md); do
  n=$(basename "$f" .md)
  grep -rlF "[[$n]]" wiki >/dev/null || echo "$f"   # No inbound link
done

출력되는 각 줄은 어떤 페이지에서도 링크되지 않은 파일입니다.

log.md는 각 항목에 고정된 접두사가 있으므로, 명령어로 최근 기록을 바로 볼 수도 있습니다:

grep "^## \[" wiki/log.md | tail -5   # Last 5 entries

얼마나 자주 할까

gist는 ‘정기적으로’라고만 말합니다. 우선 아래의 주기로 시작하고, 이후 여러분의 상황에 맞게 조정하십시오:

• Ingest를 5~10번 할 때마다 전체 Lint를 한 번 하십시오.
• 어떤 페이지의 내용이 여러분이 알고 있던 것과 다르다고 느껴지면, 그 주제에 대해 부분 Lint를 하십시오.

자동 예약 실행을 원하면 Claude Code의 headless 모드로 가능하며, 자세한 내용은 Claude Code 가이드의 자동화 장에 있습니다. 예약 실행 시에는 “보고만 하고 수정하지 않기”를 유지하는 것을 권합니다. 수정은 여러분이 목록을 확인한 뒤에 결정하면 됩니다.

다음 단계

지금 바로 위의 프롬프트로 Lint를 한 번 실행해 보십시오. 결과를 볼 때는 한 가지 종류의 문제만 골라 처리하십시오. 모순부터 처리하는 것을 권합니다. wiki가 잘못된 내용을 가장 쉽게 믿게 만드는 부분이기 때문입니다. 처리가 끝나면 log.md에 lint 기록을 한 줄 추가하십시오.

출처: Andrej Karpathy의 LLM Wiki gist의 Operations 절 중 Lint 단락 및 Indexing and logging 절(2026-11-05 확인). 프롬프트, 명령어, 주기 권장 사항은 이 지침이 정리한 내용입니다.