카파시의 LLM Wiki, 한 줄씩 깊이 읽기

원문(영어) · 한글 번역 · 전문 해설 · “누구나 이해하는” 파인만식 설명을 한 문서에 담았습니다.

원문 출처: Andrej Karpathy, LLM Wiki — gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

---

이 문서를 읽는 법

이 글은 카파시의 원문을 섹션별로 따라가면서, 각 대목마다 세 겹으로 풀어 설명합니다. 어려우면 파인만 콜아웃만 따라 읽어도 전체 그림이 잡히도록 설계했습니다.

“ 원문 + 번역

카파시가 쓴 영어 원문과, 그에 대응하는 한글 번역을 함께 둡니다. 원문 속 전문 용어에는 [^각주]를 달아 문서 맨 아래 용어집에서 풀이합니다.

■ 한 겹 더 — 전문 분석

그 문장이 기술적으로 무엇을 의미하는지, 소프트웨어 공학·정보과학의 관점에서 해석합니다. 배경 지식이 있는 독자를 위한 층입니다.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

같은 내용을 일상 비유로 다시 풉니다. 전문 용어를 모르는 사람도 “아, 그런 얘기였구나” 하고 무릎을 칠 수 있게 하는 것이 목표입니다. (“파인만식”이란 물리학자 리처드 파인만의 신조 — “쉽게 설명하지 못한다면, 제대로 이해한 게 아니다”에서 따왔습니다.)

---

한눈에 보기 (TL;DR)

카파시의 주장은 한 문장으로 압축됩니다.

“LLM에게 문서를 매번 검색시키지 말고, LLM이 직접 관리하는 살아있는 위키를 짓게 하라.”

기존 방식(RAG¹)은 질문할 때마다 원본 문서를 새로 뒤져 답을 만듭니다. 매번 처음부터입니다. 반면 LLM 위키는 새 자료가 들어올 때마다 LLM이 그것을 읽고, 요약하고, 기존 페이지들을 고치고, 연결고리를 잇습니다. 지식이 한 번 정리되면 계속 최신 상태로 유지됩니다.

핵심 대비를 표로 보면:

	기존 RAG 방식	LLM 위키 방식
지식의 형태	흩어진 원본 조각(chunk)	정리된·연결된 위키 페이지
답할 때	매번 처음부터 검색·조합	이미 정리된 페이지를 읽음
시간이 지나면	그대로 (축적 없음)	복리로 풍부해짐
인간의 역할	파일 업로드	소스 선별 · 질문 · 방향 설정
LLM의 역할	검색·생성	요약·연결·정리·유지보수 전부
비유	매 시험마다 도서관을 새로 뒤지기	갈수록 두꺼워지는 나만의 정리노트

이 한 장의 그림을 머리에 넣고 본문으로 들어가면, 나머지는 전부 “그럼 그 위키를 어떻게 짓고, 어떻게 관리하느냐”의 각론입니다.

---

0. 들어가며 — 이것은 “아이디어 파일”이다

“ 원문 + 번역

# LLM Wiki A pattern² for building personal knowledge bases using LLMs. This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

번역 — # LLM 위키 LLM을 활용해 개인 지식 베이스를 구축하는 하나의 패턴. 이 문서는 “아이디어 파일”입니다. 여러분이 쓰는 LLM 에이전트(OpenAI Codex, Claude Code, OpenCode/Pi 등)에 그대로 복사·붙여넣기 하도록 설계되었습니다. 목적은 큰 그림(상위 개념)을 전달하는 것이며, 구체적인 세부 구현은 여러분의 에이전트가 여러분과 협업하며 만들어 갑니다.

카파시는 첫 문장부터 두 가지를 못박습니다. 첫째, 이것은 패턴이다 — 정해진 제품이나 코드가 아니라, 상황에 맞게 변형해 쓰는 재사용 가능한 설계 양식입니다. 둘째, 이 글의 독자는 사람만이 아니다 — LLM 에이전트가 읽고 자기 행동 지침으로 삼도록 쓰인, 일종의 기계도 읽는 선언문입니다.

■ 한 겹 더 — 전문 분석

“Pattern(패턴)”은 소프트웨어 공학의 디자인 패턴에서 온 말입니다. 일회성 해법이 아니라, 비슷한 문제에 반복 적용할 수 있는 검증된 구조라는 뜻이죠. 또 이 문서가 “copy-paste 해서 에이전트에 넣으라”고 한 것은, 글 자체가 LLM을 위한 메타 프롬프트(시스템 지침) 역할을 하도록 의도됐다는 의미입니다. 그래서 추상적 규범만 던지고, 디테일은 런타임에 사람과 에이전트가 함께 채우는 “의도 중심(intent-driven)” 접근을 취합니다.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

이 문서는 요리 레시피가 아니라 “요리 철학” 입니다. 레시피는 “양파 1개를 0.5cm로 썰어 3분 볶으세요”처럼 정해져 있죠. 반면 철학은 “재료의 단맛을 끌어내려면 천천히 익혀라” 같은 원칙만 줍니다. 그 원칙을 받아 실제 메뉴를 짜는 건 주방장(=당신의 LLM)의 몫이고요. 그리고 재밌는 점 — 이 “철학서”는 사람이 읽으라고만 쓴 게 아니라, 주방장 로봇에게 직접 읽히라고 쓴 글입니다. 그래서 통째로 복사해 AI에게 건네면, AI가 “아하, 나는 이런 식으로 일하면 되는구나” 하고 알아듣습니다.

---

1. 핵심 개념 — ‘검색’에서 ‘컴파일’로

1-1. 기존 방식(RAG)의 한계: 매번 처음부터

“ 원문 + 번역

Most people’s experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks³ at query time⁴, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There’s no accumulation.

번역 — 대부분의 사람이 LLM으로 문서를 다루는 경험은 RAG처럼 보입니다. 파일 묶음을 업로드하면, LLM이 질문하는 시점에 관련된 조각(chunk)들을 끄집어내 답을 만들어내죠. 이 방식도 작동은 합니다. 하지만 LLM은 매 질문마다 지식을 맨바닥에서 다시 발견해야 합니다. 축적이 없습니다.

“ 원문 + 번역

Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.

번역 — 문서 다섯 개를 종합해야 풀리는 미묘한 질문을 던져 보세요. LLM은 매번 관련 조각을 찾아 짜맞춰야 합니다. 쌓이는 게 없습니다. NotebookLM, ChatGPT 파일 업로드, 그리고 대부분의 RAG 시스템이 바로 이렇게 작동합니다.

카파시가 겨누는 RAG의 약점은 휘발성입니다. 어렵게 다섯 문서를 엮어 답을 만들어도, 그 “엮은 결과”는 어디에도 저장되지 않습니다. 다음에 비슷한 질문이 오면 또 처음부터 다섯 문서를 찾아 엮어야 하죠.

■ 한 겹 더 — 전문 분석

RAG는 본질적으로 상태 없는(stateless) 구조입니다. 매 질의가 독립적이라, 직전에 수행한 값비싼 “종합(synthesis)” 연산이 다음 질의로 이어지지 않습니다. 게다가 종합은 보통 컨텍스트 윈도우⁵ 안에서 그때그때(in-context) 일어나기 때문에, 세션이 끝나면 통째로 사라집니다. 즉 RAG는 단기 기억만 있고 장기 기억이 없습니다.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

RAG는 시험 때마다 도서관을 처음부터 뒤지는 학생입니다. 문제가 나올 때마다 서가로 달려가 책 다섯 권을 찾고, 필요한 페이지를 펼쳐 읽고, 머릿속에서 짜맞춰 답안을 씁니다. 답안을 제출하고 나면? 그 고생해서 엮은 내용은 머리에서 증발합니다. 다음 문제가 비슷해도 또 서가로 달려가 같은 책 다섯 권을 다시 찾습니다. 똑똑하긴 한데, 같은 노동을 영원히 반복하는 셈이죠. “공부가 쌓인다”는 느낌이 전혀 없습니다. 밑 빠진 독에 물 붓기입니다.

1-2. 다른 발상: 지속되는 위키를 짓는다

“ 원문 + 번역

The idea here is different. Instead of just retrieving from raw documents at query time, the LLM incrementally builds and maintains a persistent wiki⁶ — a structured, interlinked collection of markdown⁷ files that sits between you and the raw sources.

번역 — 여기서 제안하는 발상은 다릅니다. 질문할 때마다 원본 문서에서 정보를 끄집어내는 데 그치지 않고, LLM이 지속되는 위키를 점진적으로 짓고 유지하게 합니다. 이 위키는 여러분과 원본 자료 사이에 놓인, 구조화되고 서로 연결된 마크다운 파일들의 집합입니다.

“ 원문 + 번역

When you add a new source, the LLM doesn’t just index it for later retrieval. It reads it, extracts the key information, and integrates it into the existing wiki — updating entity⁸ pages, revising topic summaries, noting where new data contradicts old claims, strengthening or challenging the evolving synthesis. The knowledge is compiled once and then kept current, not re-derived on every query.

번역 — 새 자료를 추가하면, LLM은 그것을 나중에 찾아보려고 색인만 해두지 않습니다. 읽고, 핵심을 뽑아, 기존 위키에 통합합니다 — 개체(entity) 페이지를 갱신하고, 주제 요약을 손보고, 새 데이터가 옛 주장과 충돌하는 지점을 표시하고, 발전 중인 종합을 보강하거나 반박합니다. 지식은 한 번 컴파일된 뒤 최신 상태로 유지되며, 질문마다 다시 도출되지 않습니다.

여기가 글 전체의 분수령입니다. 핵심 동사는 integrate(통합) 입니다. 단순히 “저장”하는 게 아니라, 새 정보가 들어올 때마다 기존 지식 전체가 조금씩 다시 짜입니다. 특히 “새 데이터가 옛 주장과 충돌하는 지점을 표시한다” 는 대목은, AI를 단순 검색기가 아니라 모순을 의식하는 사고 파트너로 끌어올립니다.

■ 한 겹 더 — 전문 분석

비유의 핵심은 인터프리터 vs. 컴파일러입니다. RAG는 질문이 올 때마다 원본을 한 줄씩 해석하는 인터프리터입니다. LLM 위키는 지식을 미리 “빌드”해 실행 파일로 만들어두는 컴파일러죠. 또 위키는 사용자와 원본 사이의 추상화 계층(미들웨어) 으로 작동합니다. 원본을 매번 파싱하는 대신, 이미 가공된 중간층을 두어 탐색 비용과 지연을 크게 낮춥니다.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

이제 그 학생은 공부하면서 “나만의 정리노트”를 계속 고쳐 쓰는 학생으로 바뀝니다. 새 책을 읽으면 그 자리에서 노트의 해당 챕터를 고칩니다. “어, 이 책은 3장에서 배운 것과 반대되는 주장을 하네?” 싶으면 노트 여백에 빨간 별표를 칩니다. 관련된 다른 페이지에는 “→ 7장도 같이 볼 것” 하고 화살표를 그어둡니다. 시험 날엔 책 다섯 권이 필요 없습니다. 노트 한 권만 펴면 됩니다. 그 노트는 공부할수록 두꺼워지고, 안에 연결선이 빼곡해지고, 점점 더 똑똑해집니다. “한 번 컴파일하고 최신으로 유지한다”는 말은 이겁니다 — 한 번 정리해 둔 노트를, 새 내용이 생길 때마다 덧칠만 하면 된다는 뜻이죠. 매번 백지에서 다시 쓰지 않습니다.

1-3. 위키는 ‘복리로 불어나는 자산’이다

“ 원문 + 번역

This is the key difference: the wiki is a persistent, compounding⁹ artifact. The cross-references¹⁰ are already there. The contradictions have already been flagged. The synthesis already reflects everything you’ve read. The wiki keeps getting richer with every source you add and every question you ask.

번역 — 이것이 결정적 차이입니다. 위키는 지속되고, 복리로 불어나는 산출물입니다. 상호 참조는 이미 거기 있습니다. 모순은 이미 표시돼 있습니다. 종합은 이미 여러분이 읽은 모든 것을 반영합니다. 위키는 자료를 더할 때마다, 그리고 질문을 던질 때마다 계속 풍부해집니다.

“이미(already)”가 세 번 반복되는 데 주목하세요. 질문을 던지는 순간, 연결고리도·모순 표시도·종합도 이미 만들어져 있습니다. 비싼 작업이 질의 시점이 아니라 미리 끝나 있다는 뜻입니다. 그리고 마지막 문장의 반전 — 위키는 자료를 넣을 때뿐 아니라 질문할 때도 자란다고 합니다. (질문에서 나온 좋은 답을 다시 위키에 넣기 때문인데, 자세한 건 3-2. 쿼리에서 다룹니다.)

■ 한 겹 더 — 전문 분석

“복리(compounding)”는 경제 용어를 빌려온 비유입니다. 지식이 선형적으로 쌓이는 게 아니라, 기존 지식과 연결되면서 가치가 더 빠르게 커진다는 뜻이죠. 노드(페이지)가 늘면 그 사이를 잇는 링크의 수는 더 가파르게 늘어납니다 — 이것이 네트워크 효과입니다. 그리고 “이미 거기 있다”는 표현은, 링크와 모순 검사 같은 비싼 연산이 빌드 타임(자료를 넣을 때) 에 끝나 있고, 쿼리 타임(질문할 때) 에는 거의 비용이 들지 않는다는 설계상의 이점을 가리킵니다.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

은행 이자를 떠올려 보세요. 돈을 넣어두면 이자가 붙고, 그 이자에 또 이자가 붙습니다. 가만히 둬도 눈덩이처럼 불어나죠. 이게 복리입니다. 지식도 똑같이 만들 수 있다는 겁니다. 노트에 새 사실 하나를 적는다고 칩시다. 그런데 그 사실이 이미 적어둔 다른 열 가지와 연결되면, 노트의 가치는 1만큼이 아니라 그 이상으로 뜁니다. 연결이 또 다른 연결을 낳거든요. “질문해도 노트가 두꺼워진다”는 말은 이런 겁니다 — 친구한테 설명해주려고 머리를 쥐어짜 좋은 비유를 만들었다면, 그 비유를 그냥 흘려보내지 말고 노트에 적어두라는 거죠. 그럼 그 비유도 자산이 됩니다.

1-4. 글은 LLM이 쓴다, 사람은 묻는다

“ 원문 + 번역

You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it. You’re in charge of sourcing, exploration, and asking the right questions. The LLM does all the grunt work¹¹ — the summarizing, cross-referencing, filing, and bookkeeping¹² that makes a knowledge base actually useful over time.

번역 — 위키를 직접 쓰는 일은 거의 없습니다 — LLM이 전부 쓰고 유지합니다. 여러분의 담당은 자료 고르기(sourcing), 탐색(exploration), 그리고 좋은 질문 던지기입니다. LLM은 모든 잡일(grunt work)을 합니다 — 요약, 상호 참조 걸기, 정리, 그리고 지식 베이스를 시간이 지나도 쓸모 있게 만드는 장부 정리(bookkeeping) 말입니다.

“ 원문 + 번역

In practice, I have the LLM agent open on one side and Obsidian¹³ open on the other. The LLM makes edits based on our conversation, and I browse the results in real time — following links, checking the graph view¹⁴, reading the updated pages. Obsidian is the IDE¹⁵; the LLM is the programmer; the wiki is the codebase.

번역 — 실제로 저는 한쪽에 LLM 에이전트를, 다른 쪽에 옵시디언을 띄워 둡니다. 대화에 따라 LLM이 문서를 편집하면, 저는 실시간으로 결과를 둘러봅니다 — 링크를 따라가고, 그래프 뷰를 확인하고, 갱신된 페이지를 읽으면서요. 옵시디언은 IDE, LLM은 프로그래머, 위키는 코드베이스입니다.

마지막 한 줄이 카파시 사상의 정수입니다. 지식을 “메모 더미”가 아니라, 끊임없이 리팩토링되고 빌드되는 소프트웨어 자산으로 보자는 겁니다. 사람의 역할은 “쓰기(writing)”에서 “감독·지휘(directing)”로 옮겨갑니다.

■ 한 겹 더 — 전문 분석

여기서 읽기/쓰기의 역할 분리가 명확해집니다. 사람은 읽기(검토·판단)만, LLM은 쓰기(생성·정리)만 맡습니다. 지식 관리 시스템(PKM)이 무너지는 가장 흔한 원인이 “사람의 입력 피로”인데, 그 쓰기 부담을 통째로 기계에 넘김으로써 시스템의 지속 가능성을 확보합니다. “옵시디언=IDE, LLM=프로그래머, 위키=코드베이스” 등식은, 지식을 코드처럼 다루자(Knowledge-as-Code) 는 선언입니다 — 버전 관리, 리팩토링, 일관성 검사 같은 공학 규율을 지식에 그대로 적용하는 것이죠.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

영화 감독을 떠올리세요. 감독은 카메라를 직접 들거나 조명을 직접 달지 않습니다. “이 장면은 이런 느낌으로” 라고 방향만 잡죠. 촬영·조명·편집 같은 손이 많이 가는 일은 전문 스태프가 합니다. 여기서 당신은 감독이고, LLM은 스태프 전원입니다. 당신은 “무엇을 읽을지 고르고, 무엇이 궁금한지 묻는” 머리 쓰는 일만 합니다. 요약하고, 링크 걸고, 폴더에 정리하고, 앞뒤 안 맞는 곳 고치는 노가다는 전부 LLM 몫입니다. 작업대 배치는 이렇습니다 — 왼쪽 화면엔 AI와의 대화창, 오른쪽 화면엔 옵시디언(노트 앱). AI가 왼쪽에서 “고쳤어요” 하면, 당신은 오른쪽에서 노트가 실제로 어떻게 바뀌었는지 눈으로 확인합니다. 마치 작가(AI)와 편집자(당신)가 나란히 앉아 원고를 다듬는 모습입니다.

1-5. 어디에 쓸 수 있나 — 다섯 가지 예시

원문은 이 패턴이 적용되는 맥락을 나열합니다. 번역하면 다음과 같습니다.

“ 원문 + 번역

• Personal: tracking your own goals, health, psychology, self-improvement — filing journal entries, articles, podcast notes, and building up a structured picture of yourself over time.
• Research: going deep on a topic over weeks or months — reading papers, articles, reports, and incrementally building a comprehensive wiki with an evolving thesis¹⁶.
• Reading a book: filing each chapter as you go, building out pages for characters, themes, plot threads, and how they connect. … Think of fan wikis like Tolkien Gateway …
• Business/team: an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls. Possibly with humans in the loop¹⁷ reviewing updates.
• Competitive analysis, due diligence, trip planning, course notes, hobby deep-dives — anything where you’re accumulating knowledge over time and want it organized rather than scattered.

번역

• 개인: 자기 목표·건강·심리·자기계발을 추적합니다. 일기, 기사, 팟캐스트 메모를 정리해, 시간이 흐르며 구조화된 자기 자신의 초상을 쌓아 갑니다.
• 연구: 한 주제를 몇 주~몇 달간 깊이 파고듭니다. 논문·기사·보고서를 읽으며, *진화하는 논지(thesis)*를 중심으로 포괄적인 위키를 점진적으로 짓습니다.
• 독서: 책을 읽어가며 각 장을 정리하고, 등장인물·주제·플롯 줄기와 그 연결을 페이지로 만듭니다. 톨킨 게이트웨이 같은 팬 위키를 떠올려 보세요 — 수천 개의 연결된 페이지를요.
• 비즈니스/팀: 슬랙 스레드, 회의록, 프로젝트 문서, 고객 통화로 공급받아 LLM이 관리하는 내부 위키. 갱신 내용은 사람이 검토(humans in the loop)할 수도 있습니다.
• 경쟁사 분석, 실사, 여행 계획, 강의 노트, 취미 심화 — 시간을 들여 지식을 쌓고, 흩어진 채가 아니라 정리된 형태로 갖고 싶은 모든 영역.

■ 한 겹 더 — 전문 분석

다섯 예시를 관통하는 한 가지는 “시간에 걸친 축적” 입니다. 특히 비즈니스 사례는 조직의 암묵지(머릿속에만 있는 지식) 를 형식지(문서화된 지식) 로 바꾸는 고전적 지식경영 문제를 정확히 건드립니다. 슬랙·회의록처럼 가장 빨리 휘발되는 비정형 데이터를 LLM이 실시간으로 흡수해 정리하니까요. “humans in the loop”는 AI의 환각 위험을 사람이 최종 검토로 막는, 실무 시스템의 표준 안전장치입니다.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

공통점은 하나입니다 — “오래 쌓으면 보물이 되는데, 흩어지면 쓰레기가 되는” 것들이죠. 일기를 5년 치 모으면 나를 비추는 거울이 되지만, 여기저기 흩어진 메모는 그냥 잡동사니입니다. 논문 100편을 엮으면 한 편의 통찰이 되지만, 따로 놀면 그냥 PDF 더미고요. 그리고 톨킨 게이트웨이 이야기가 멋집니다. 반지의 제왕 팬들이 수년간 자원봉사로 만든, 등장인물·지명·언어가 수천 페이지로 엮인 거대한 백과사전이에요. 예전엔 수백 명이 수년을 갈아 넣어야 했던 그런 위키를, 이제 혼자서 책 읽으며 만들 수 있다는 겁니다 — 귀찮은 연결·정리는 AI가 다 해주니까요.

---

2. 아키텍처 — 세 개의 층

시스템은 세 층으로 이뤄집니다. 그림으로 먼저 보겠습니다.

┌──────────────────────────────────────────────────────────┐
│  ① 원시 소스 (Raw Sources)                                │
│     논문·기사·이미지·데이터  —  절대 안 바뀜 (불변)         │
│     "진실의 원천(Source of Truth)"                         │
└───────────────────────────┬──────────────────────────────┘
                            │  읽기만 함 (read-only)
                            ▼
┌──────────────────────────────────────────────────────────┐
│  ② 위키 (The Wiki)                                        │
│     요약·개체·개념·비교·종합 페이지  —  LLM이 읽고 씀       │
│     "사람은 읽고, LLM은 쓴다"                              │
└───────────────────────────▲──────────────────────────────┘
                            │  이 규칙대로 동작
┌───────────────────────────┴──────────────────────────────┐
│  ③ 스키마 (The Schema:  CLAUDE.md / AGENTS.md)            │
│     구조·규칙·작업 절차를 정의  —  사람과 LLM이 함께 진화   │
└──────────────────────────────────────────────────────────┘

“ 원문 + 번역

There are three layers:

번역 — 세 개의 층이 있습니다.

2-1. 제1층 — 원시 소스: 절대 손대지 않는 원본

“ 원문 + 번역

Raw sources — your curated collection of source documents. Articles, papers, images, data files. These are immutable¹⁸ — the LLM reads from them but never modifies them. This is your source of truth¹⁹.

번역 — 원시 소스 — 여러분이 엄선한 원본 문서 모음입니다. 기사, 논문, 이미지, 데이터 파일. 이것들은 *불변(immutable)*입니다 — LLM은 여기서 읽기만 할 뿐, 절대 수정하지 않습니다. 이것이 여러분의 *진실의 원천(source of truth)*입니다.

■ 한 겹 더 — 전문 분석

함수형 프로그래밍의 불변성(immutability) 개념을 지식 관리에 가져온 것입니다. 원본을 고정해두면, 나중에 LLM이 무언가를 잘못 요약했거나 환각을 일으켰을 때 언제든 원본으로 돌아가 대조·검증할 수 있습니다. 즉 원시 소스는 시스템 전체의 최후 검증 기준점입니다. “curated(엄선된)”라는 단어도 중요한데, 쓰레기가 들어가면 쓰레기가 나오므로(garbage in, garbage out) 무엇을 넣을지 고르는 인간의 판단이 여기서 개입합니다.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

원본 영수증이 든 서류함이라고 생각하세요. 가계부(=위키)는 영수증을 보고 정리하지만, 영수증 자체에는 절대 낙서하지 않습니다. 왜냐고요? 나중에 가계부에 계산 실수가 있는 것 같으면, 원본 영수증을 다시 꺼내 맞춰봐야 하니까요. 원본이 깨끗하게 보존돼 있어야 “진짜는 뭐였지?”를 확인할 수 있습니다. 그래서 이 서류함은 읽기 전용입니다. AI도 여기선 꺼내 읽기만 하고, 한 글자도 고치지 않습니다.

2-2. 제2층 — 위키: LLM이 짓고 다스리는 영역

“ 원문 + 번역

The wiki — a directory of LLM-generated markdown files. Summaries, entity pages, concept pages, comparisons, an overview, a synthesis. The LLM owns this layer entirely. It creates pages, updates them when new sources arrive, maintains cross-references, and keeps everything consistent. You read it; the LLM writes it.

번역 — 위키 — LLM이 생성한 마크다운 파일들의 디렉터리입니다. 요약, 개체 페이지, 개념 페이지, 비교, 개요, 종합. LLM이 이 층을 전적으로 소유합니다. 페이지를 만들고, 새 소스가 오면 갱신하고, 상호 참조를 유지하고, 전체를 일관되게 지킵니다. 여러분은 읽고, LLM은 씁니다.

■ 한 겹 더 — 전문 분석

이 층은 사람과 원본 사이의 완충 지대이자, 실시간으로 빌드되는 지식의 저장소입니다. 단순 요약을 넘어 비교(comparison) 와 종합(synthesis) 이 일어나는 곳, 즉 가치가 실제로 생산되는 공간이죠. “LLM이 전적으로 소유한다”는 선언은 책임 소재를 분명히 합니다 — 일관성 유지의 의무가 사람이 아니라 기계에 있습니다.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

1층 서류함의 영수증을 보고 AI가 직접 써내려가는 “가계부 겸 백과사전” 입니다. 여기엔 깔끔한 요약, 인물별·주제별 정리 페이지, “A안과 B안 비교표”, 전체 한눈에 보기 같은 게 들어갑니다. 그리고 이 공간의 주인은 전적으로 AI입니다. 페이지를 새로 만들고, 새 자료가 오면 고치고, “이건 저 페이지랑 연결” 하고 링크 걸고, 앞뒤 안 맞는 곳을 맞추는 일까지 — 전부 AI가 합니다. 당신은? 그냥 읽기만 합니다. 손대지 않아도 알아서 잘 정리돼 있습니다.

2-3. 제3층 — 스키마: AI를 ‘규율 있는 사서’로 만드는 규칙서

“ 원문 + 번역

The schema — a document (e.g. CLAUDE.md²⁰ for Claude Code or AGENTS.md for Codex) that tells the LLM how the wiki is structured, what the conventions are, and what workflows to follow when ingesting sources, answering questions, or maintaining the wiki. This is the key configuration file — it’s what makes the LLM a disciplined wiki maintainer rather than a generic chatbot. You and the LLM co-evolve²¹ this over time as you figure out what works for your domain.

번역 — 스키마 — LLM에게 위키가 어떻게 구성되는지, 규칙(convention)은 무엇인지, 자료를 흡수하거나 질문에 답하거나 위키를 관리할 때 어떤 절차를 따라야 하는지를 알려주는 문서(예: Claude Code용 CLAUDE.md, Codex용 AGENTS.md)입니다. 이것이 핵심 설정 파일입니다 — LLM을 평범한 챗봇이 아니라 규율 있는 위키 관리자로 만드는 것이 바로 이 파일입니다. 여러분과 LLM은 자기 분야에 무엇이 통하는지 알아가며 이 스키마를 시간을 두고 함께 진화시킵니다.

■ 한 겹 더 — 전문 분석

스키마는 시스템의 메타 거버넌스(상위 통치 규칙) 층입니다. 그때그때 즉흥적으로 프롬프트를 주는 대신, 지속되는 규칙 체계를 박아두어 행동을 재현 가능(reproducible) 하게 만듭니다. 이 파일이 컨텍스트에 늘 깔려 있으므로, 에이전트의 자유도를 일부 제약하는 대신 전문성과 일관성을 부여합니다. “함께 진화한다(co-evolve)”는 것은, 스키마가 처음부터 완벽할 필요 없이 운영하며 계속 다듬는 적응형 설정임을 뜻합니다.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

새 직원에게 주는 “업무 매뉴얼” 입니다. 아무 지시 없이 똑똑한 신입을 앉혀 두면, 일은 잘하는데 제멋대로 합니다. 파일을 자기 맘대로 된 폴더에 넣고, 보고서 양식도 그때그때 바뀌죠. 그런데 “우리 회사 문서는 이렇게 분류하고, 새 자료가 오면 이 순서로 처리하고, 보고는 이 양식으로” 라는 매뉴얼을 쥐여주면 — 같은 사람이 믿음직한 베테랑 사서처럼 일하기 시작합니다. 이 매뉴얼(CLAUDE.md)이 바로 “그냥 수다 떠는 챗봇”과 “규율 있는 위키 관리자”를 가르는 차이입니다. 그리고 한 번 쓰고 끝이 아니라, 일하다 보면 “아 이 규칙은 좀 바꾸자” 하고 당신과 AI가 같이 매뉴얼을 고쳐 갑니다.

---

3. 운영 — 인제스트 · 쿼리 · 린트

위키를 굴리는 세 가지 동작입니다. 넣고(ingest), 묻고(query), 점검한다(lint).

3-1. 인제스트 (Ingest) — 새 자료를 흡수시키기

“ 원문 + 번역

Ingest.²² You drop a new source into the raw collection and tell the LLM to process it. An example flow: the LLM reads the source, discusses key takeaways with you, writes a summary page in the wiki, updates the index, updates relevant entity and concept pages across the wiki, and appends an entry to the log. A single source might touch 10-15 wiki pages.

번역 — 인제스트. 새 자료를 원시 소스 폴더에 떨궈 넣고 LLM에게 처리하라고 시킵니다. 예시 흐름은 이렇습니다 — LLM이 자료를 읽고 → 핵심 요점을 여러분과 의논하고 → 위키에 요약 페이지를 쓰고 → 색인(index)을 갱신하고 → 위키 곳곳의 관련 개체·개념 페이지를 갱신하고 → 로그(log)에 기록 한 줄을 덧붙입니다. 자료 하나가 위키 페이지 10~15개를 건드릴 수 있습니다.

“ 원문 + 번역

Personally I prefer to ingest sources one at a time and stay involved … But you could also batch-ingest²³ many sources at once with less supervision. It’s up to you to develop the workflow that fits your style and document it in the schema for future sessions.

번역 — 저는 개인적으로 자료를 하나씩 넣고 과정에 직접 관여하는 편입니다 … 하지만 감독을 줄이고 *한꺼번에 여러 자료를 일괄 흡수(batch-ingest)*시킬 수도 있습니다. 자기 스타일에 맞는 작업 흐름을 만들어 스키마에 적어두는 것은 여러분의 몫입니다 — 다음 세션을 위해서요.

핵심은 “자료 하나가 10~15개 페이지를 건드린다” 입니다. 사람이 수작업으로 가장 먼저 포기하는 일이 바로 이 “관련된 모든 페이지 동시 갱신”인데, LLM은 이걸 한 번에 해치웁니다.

■ 한 겹 더 — 전문 분석

자료 하나의 유입이 시스템 전체에 연쇄 갱신을 일으킵니다. 데이터 공학에서 말하는 쓰기 증폭(write amplification) 과 비슷하죠 — 입력 1건이 내부 쓰기 다수로 번지는 현상입니다. 다만 여기서는 그 증폭이 축복입니다. 정보가 사일로(고립된 칸)에 갇히지 않고 관계 그래프 전체에 즉시 반영되니까요. “하나씩 vs. 일괄”은 정독 모드 vs. 빠른 적재 모드의 선택이며, 무엇을 택하든 스키마에 적어 두면 다음 세션의 에이전트가 그 규칙을 이어받습니다.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

도서관에 새 책 한 권이 들어왔을 때 사서가 하는 일을 떠올려 보세요. 그냥 서가에 꽂고 끝이 아닙니다. ① 책을 훑어 내용을 파악하고 → ② “이런 책이 들어왔어요” 하고 당신과 얘기하고 → ③ 요약 카드를 만들고 → ④ 도서 목록(색인)에 등록하고 → ⑤ 관련 주제 코너의 안내문도 고치고 → ⑥ “○월 ○일, 무슨 책 입고” 하고 일지에 적습니다. 책 한 권 들어왔을 뿐인데 도서관 곳곳 10~15군데가 바뀌는 거죠. 사람이라면 “에이, 목록 등록까지만 하자” 하고 나머지를 빼먹습니다. 바로 그 빼먹는 일들을 AI는 군말 없이 매번 다 합니다. 책을 한 권씩 천천히 넣을지(꼼꼼히), 박스째 쏟아 넣을지(빠르게)는 당신 마음입니다. 다만 “나는 이렇게 한다”를 매뉴얼에 적어두면 다음에도 똑같이 굴러갑니다.

3-2. 쿼리 (Query) — 질문하고, 그 답을 다시 저장한다

“ 원문 + 번역

Query. You ask questions against the wiki. The LLM searches for relevant pages, reads them, and synthesizes an answer with citations²⁴. Answers can take different forms depending on the question — a markdown page, a comparison table, a slide deck (Marp²⁵), a chart (matplotlib), a canvas.

번역 — 쿼리. 원본이 아니라 위키를 향해 질문합니다. LLM은 관련 페이지를 찾아 읽고, 출처(citation)를 붙여 답을 종합합니다. 답은 질문에 따라 여러 형태가 될 수 있습니다 — 마크다운 페이지, 비교표, 슬라이드 덱(Marp), 차트(matplotlib), 캔버스 등.

“ 원문 + 번역

The important insight: good answers can be filed back into the wiki as new pages. A comparison you asked for, an analysis, a connection you discovered — these are valuable and shouldn’t disappear into chat history. This way your explorations compound in the knowledge base just like ingested sources do.

번역 — 중요한 통찰은 이것입니다. 좋은 답은 새 페이지로 위키에 다시 넣을 수 있다. 당신이 요청한 비교, 어떤 분석, 새로 발견한 연결고리 — 이것들은 가치 있는 자산이며 채팅 기록 속으로 사라져선 안 됩니다. 이렇게 하면 여러분의 탐색도, 흡수한 자료와 똑같이 지식 베이스 안에서 복리로 불어납니다.

이것이 1-3절에서 예고한 반전입니다. 질문도 위키를 키웁니다. 보통 챗봇과의 좋은 대화는 창을 닫는 순간 증발하지만, 여기서는 그 결과물을 위키에 “도로 넣어” 영구 자산으로 만듭니다.

■ 한 겹 더 — 전문 분석

두 가지가 핵심입니다. 첫째, 추론 대상이 바뀝니다. LLM이 정제되지 않은 원본이 아니라 이미 1차 가공된 위키를 놓고 2차 추론을 하므로, 컨텍스트 비용이 줄고 답의 정합성이 올라갑니다. 둘째, 닫힌 루프(closed-loop) 입니다. 질의 결과를 다시 입력으로 환원해 시스템이 스스로 가치를 키웁니다. 기존 채팅 UI의 시간적 휘발성 — 세션이 끝나면 통찰이 사라지는 문제 — 을 정면으로 푸는 설계입니다.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

질문할 때 원본 책 더미가 아니라 잘 정리된 노트에게 묻는다는 게 1단계입니다. 당연히 답이 빠르고 정확하겠죠. 그런데 진짜 묘수는 2단계입니다. AI에게 “A안과 B안 비교해줘” 해서 멋진 비교표를 받았다고 칩시다. 보통은 그 표를 한 번 보고 채팅창과 함께 날려버립니다. 다음에 또 필요하면 처음부터 다시 시키고요. 카파시는 말합니다 — 그 표를 노트에 붙여 넣어라. 그러면 그 비교표는 이제 “내가 만든 자료”가 되어, 다음 질문의 재료로 다시 쓰입니다. 고생해서 얻은 답을 두 번 일하지 않게 보관하는 거죠. 질문할수록 노트가 두꺼워지는 비결이 이겁니다.

3-3. 린트 (Lint) — 위키 건강검진

“ 원문 + 번역

Lint.²⁶ Periodically, ask the LLM to health-check the wiki. Look for: contradictions between pages, stale claims²⁷ that newer sources have superseded, orphan pages²⁸ with no inbound links, important concepts mentioned but lacking their own page, missing cross-references, data gaps that could be filled with a web search. The LLM is good at suggesting new questions to investigate and new sources to look for. This keeps the wiki healthy as it grows.

번역 — 린트. 주기적으로 LLM에게 위키 건강검진을 시킵니다. 점검 항목 — 페이지 간 모순, 새 자료에 의해 낡아버린 주장(stale claims), 들어오는 링크가 하나도 없는 고아 페이지(orphan pages), 본문엔 자주 나오지만 제 페이지가 없는 중요 개념, 빠진 상호 참조, 웹 검색으로 채울 수 있는 데이터 공백. LLM은 다음에 파볼 질문이나 찾아야 할 새 자료를 제안하는 데도 능합니다. 이것이 위키가 커지면서도 건강을 유지하는 비결입니다.

■ 한 겹 더 — 전문 분석

린트는 시스템의 엔트로피 억제 장치입니다. 지식 베이스는 커질수록 노후화·단절·모순이 쌓입니다(엔트로피 증가). 소프트웨어의 정적 분석 도구(linter)가 코드의 잠재 결함을 잡아내듯, 여기서는 지식의 구조적 결함을 주기적으로 스캔합니다. 특히 LLM이 결손을 인지하고 다음 탐색 방향을 제안하는 대목은, AI가 수동적 정리 도구를 넘어 능동적 연구 파트너로 작동함을 보여줍니다.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

노트를 오래 쓰다 보면 반드시 곰팡이가 핍니다.

• 3장에선 “A가 맞다”, 9장에선 “A는 틀렸다” — 서로 싸우는 페이지가 생깁니다.
• 작년에 적은 내용이 올해 새 자료로 이미 틀린 얘기가 됩니다(낡은 주장).
• 아무도 링크를 안 건, 외톨이 페이지가 떠돕니다(고아 페이지).
• “양자역학”이란 단어는 50번 나오는데 정작 그걸 설명한 페이지는 없는 경우도요.

그래서 가끔 AI에게 “노트 건강검진 좀 해줘” 합니다. 그럼 AI가 싸우는 페이지를 찾아주고, 낡은 부분을 짚어주고, 외톨이를 연결해주고, 더 나아가 “이 부분은 자료가 부족하니 ○○를 더 찾아보면 어때요?” 하고 다음 공부거리까지 제안합니다. 마치 건강검진 의사가 “이 수치가 안 좋으니 운동하세요” 하는 것처럼요.

---

4. 색인과 로그 — 위키를 길찾기

위키가 커지면 길을 잃습니다. 그래서 두 개의 특수 파일로 내비게이션을 만듭니다. 하나는 공간(무엇이 어디 있나), 하나는 *시간(언제 무슨 일이 있었나)*을 담당합니다.

4-1. index.md — 내용의 지도(목차)

“ 원문 + 번역

index.md is content-oriented. It’s a catalog of everything in the wiki — each page listed with a link, a one-line summary, and optionally metadata²⁹ like date or source count. Organized by category (entities, concepts, sources, etc.). The LLM updates it on every ingest. When answering a query, the LLM reads the index first to find relevant pages, then drills into them. This works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure³⁰.

번역 — index.md는 내용 중심입니다. 위키 안 모든 것의 목록(catalog)이죠 — 각 페이지마다 링크, 한 줄 요약, 그리고 선택적으로 날짜나 출처 수 같은 메타데이터가 붙습니다. 범주별(개체·개념·소스 등)로 정리됩니다. LLM은 인제스트할 때마다 이 파일을 갱신합니다. 질문에 답할 때 LLM은 먼저 색인을 읽어 관련 페이지를 찾은 뒤, 그 안으로 파고듭니다. 이 방식은 중간 규모(자료 ~100개, 페이지 수백 개)에서 놀랄 만큼 잘 작동하며, 임베딩 기반 RAG 인프라가 필요 없게 만듭니다.

마지막 문장이 강력합니다. 벡터 DB·임베딩 같은 무거운 검색 인프라 없이, 잘 관리된 목차 파일 하나로 수백 페이지를 충분히 다룬다는 주장입니다.

■ 한 겹 더 — 전문 분석

이것은 2단계 추론 라우팅입니다. 전체를 다 훑는 대신 [① 색인 스캔 → ② 타깃 페이지 진입]의 2단계로 좁혀 들어가, 컴퓨터과학의 인덱스 검색처럼 비용을 아낍니다. 더 큰 함의는 “적정 기술의 승리” 입니다. 컨텍스트 윈도우가 충분히 커진 지금, 소~중 규모에서는 복잡한 청킹·코사인 유사도·벡터 검색을 동원하는 것보다 사람도 읽을 수 있는 마크다운 목차 한 장이 오히려 더 정확하고 단순합니다. 다만 “중간 규모”라는 단서가 중요합니다 — 수천 페이지로 커지면 그때는 별도 검색 엔진이 필요합니다(5장 참조).

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

책 맨 앞의 목차입니다. 두꺼운 책에서 원하는 내용을 찾을 때, 500쪽을 1쪽부터 넘기지 않죠. 목차를 펴서 “아, 그 내용은 7장 213쪽” 하고 바로 그리로 갑니다. AI도 똑같이 합니다 — 질문을 받으면 먼저 목차(index.md)를 보고 “이건 3번, 12번 페이지를 봐야겠군” 하고 그 페이지만 펼칩니다. 놀라운 점은 이겁니다 — 사람들이 “검색하려면 거창한 검색 엔진(벡터 DB 어쩌고)이 필요하다”고 믿는데, 카파시는 “목차 한 장이면 수백 페이지까진 충분하다” 고 합니다. 동네 책 한 권 찾는 데 구글 같은 검색 서버를 지을 필요는 없잖아요? 딱 필요한 만큼만 쓰자는 실용주의입니다.

4-2. log.md — 시간의 기록(일지)

“ 원문 + 번역

log.md is chronological. It’s an append-only record³¹ of what happened and when — ingests, queries, lint passes. A useful tip: if each entry starts with a consistent prefix (e.g. ## [2026-04-02] ingest | Article Title), the log becomes parseable with simple unix tools — grep "^## \[" log.md | tail -5 gives you the last 5 entries. The log gives you a timeline of the wiki’s evolution and helps the LLM understand what’s been done recently.

번역 — log.md는 시간순입니다. 무엇이 언제 일어났는지를 덧붙이기만 하는(append-only) 기록이죠 — 인제스트, 쿼리, 린트 등. 유용한 팁 — 각 항목을 일관된 접두사로 시작하면(예: ## [2026-04-02] ingest | 기사 제목), 로그를 간단한 유닉스 도구로 파싱할 수 있습니다. grep "^## \[" log.md | tail -5 한 줄이면 최근 5개 항목이 나옵니다. 이 로그는 위키가 어떻게 진화해왔는지 타임라인을 보여주고, LLM이 최근 무슨 일을 했는지 파악하게 돕습니다.

■ 한 겹 더 — 전문 분석

log.md는 데이터베이스의 WAL(Write-Ahead Log, 선행 기록 로그) 이나 git 커밋 히스토리와 같은 역할입니다 — 무슨 변경이 언제 있었는지 시간순으로 격리 보관하죠. 일관된 접두사 규칙은 기계 가독성을 부여합니다. 사람이 읽는 마크다운에 최소한의 정형 구조를 심어, 복잡한 파서 없이 grep 한 줄로 상태를 뽑게 만드는 것이죠. 무엇보다 이 로그는 세션 간 컨텍스트 앵커입니다 — 새 대화 세션이 시작될 때 로그의 마지막 몇 줄만 읽혀도, 에이전트가 “직전까지 뭘 하고 있었는지”를 즉시 복원합니다.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

항해 일지입니다. “○월 ○일, 어디를 지남, 무슨 일 있었음”을 덧붙이기만 하고 절대 지우지 않는 기록이죠. 왜 필요할까요? 두 가지입니다. 첫째, 나중에 “내가 이 노트를 어떻게 키워왔지?” 하고 돌아볼 수 있습니다. 둘째 — 이게 더 중요한데 — AI의 기억은 대화창을 닫으면 리셋됩니다. 다음에 새 대화를 켜면 AI는 “어제 우리가 뭘 했더라?”를 모릅니다. 그때 이 일지의 마지막 다섯 줄만 보여주면, AI가 “아, 어제까지 이걸 하고 있었군요” 하고 바로 이어서 일합니다. 그리고 일지를 적을 때 [날짜] 종류 | 제목 같은 딱 정해진 양식으로 쓰면, 나중에 컴퓨터 명령어 한 줄로 “최근 5개만 보여줘”가 됩니다. 다이어리를 날짜 양식 맞춰 쓰면 검색이 쉬운 것과 같은 이치예요.

---

5. 선택적 확장 — CLI 도구

i 이 장은 “선택” 입니다

위키가 작을 땐 4장의 목차 파일만으로 충분합니다. 아래 내용은 위키가 수천 페이지로 커졌을 때 비로소 필요해지는, 있으면 좋은 도구 이야기입니다. 작게 시작하는 사람은 건너뛰어도 됩니다.

“ 원문 + 번역

At some point you may want to build small tools that help the LLM operate on the wiki more efficiently. A search engine over the wiki pages is the most obvious one — at small scale the index file is enough, but as the wiki grows you want proper search.

번역 — 어느 시점이 되면, LLM이 위키를 더 효율적으로 다루도록 돕는 작은 도구를 만들고 싶어질 것입니다. 가장 자명한 것이 위키 페이지를 훑는 검색 엔진입니다 — 작은 규모에선 색인 파일로 충분하지만, 위키가 커지면 제대로 된 검색이 필요해집니다.

“ 원문 + 번역

[qmd] is a good option: it’s a local search engine for markdown files with hybrid BM25³²/vector search and LLM re-ranking³³, all on-device³⁴. It has both a CLI³⁵ (so the LLM can shell out³⁶ to it) and an MCP server³⁷ (so the LLM can use it as a native tool). You could also build something simpler yourself — the LLM can help you vibe-code³⁸ a naive search script as the need arises.

번역 — qmd가 좋은 선택지입니다. 마크다운 파일용 로컬 검색 엔진으로, 키워드 기반 BM25 + 의미 기반 벡터 검색을 결합한 하이브리드 검색에 *LLM 재정렬(re-ranking)*까지, 전부 내 기기 안에서(on-device) 돌아갑니다. CLI(그래서 LLM이 셸 명령으로 호출 가능)와 MCP 서버(그래서 LLM이 자기 도구처럼 직접 사용 가능)를 둘 다 제공합니다. 더 단순한 걸 직접 만들어도 됩니다 — 필요해지는 순간 LLM의 도움을 받아 *’바이브 코딩(vibe-code)’*으로 소박한 검색 스크립트를 뚝딱 만들면 되니까요.

■ 한 겹 더 — 전문 분석

검색 전략을 규모에 맞춰 단계적으로 키우라는 조언입니다. ① 소규모: 색인 파일 정독 → ② 중·대규모: 하이브리드 검색 엔진. qmd가 온디바이스라는 점은 보안과 오프라인 영속성 면에서 의미가 큽니다 — 지식이 외부 클라우드로 새지 않으니까요. MCP(Model Context Protocol) 지원은 검색 엔진을 LLM의 “확장된 손발”로 붙이는 최신 표준입니다. 마지막의 바이브 코딩은, 거창한 설계 없이 필요한 순간 AI와 즉석에서 코드를 만들어 쓰는 현대적 개발 문화를 가리킵니다.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

노트가 다섯 권일 땐 목차만 봐도 찾습니다. 그런데 노트가 500권이 되면? 목차도 너무 길어 못 찾습니다. 그때 전용 사서(검색 엔진) 를 고용하는 겁니다. qmd라는 사서는 두 가지 방식으로 동시에 찾아줍니다 — ① “이 단어가 들어간 페이지”(키워드 검색), ② “이 뜻과 비슷한 페이지”(의미 검색). 예를 들어 “강아지”로 찾으면 ‘개’, ‘반려견’이 적힌 페이지도 같이 찾아주는 식이죠. 게다가 이 사서는 당신 책상 위에서만 일합니다(외부로 자료를 안 보냄). 그리고 AI가 이 사서에게 직접 “이거 찾아줘” 하고 시킬 수 있습니다. 더 좋은 건 — 마음에 드는 도구가 없으면 그 자리에서 AI한테 “간단한 검색기 하나 만들어줘” 하면 됩니다. 이게 ‘바이브 코딩’입니다. 미리 거창하게 설계할 필요 없이, 필요해진 순간 AI와 수다 떨듯 만들어 쓰는 거죠.

---

6. 실무 팁과 트릭

이 장은 카파시가 직접 쓰는 옵시디언 중심의 도구 팁들입니다. 자료를 넣고, 모양을 보고, 결과를 내보내는 실전 노하우입니다.

6-1. 자료 넣기 — 웹 클리퍼와 이미지 로컬 저장

“ 원문 + 번역

Obsidian Web Clipper is a browser extension that converts web articles to markdown. Very useful for quickly getting sources into your raw collection. Download images locally. … set “Attachment folder path” to a fixed directory (e.g. raw/assets/) … bind it to a hotkey … Note that LLMs can’t natively read markdown with inline images in one pass — the workaround is to have the LLM read the text first, then view some or all of the referenced images separately. It’s a bit clunky but works well enough.

번역 — 옵시디언 웹 클리퍼는 웹 기사를 마크다운으로 변환해 주는 브라우저 확장 프로그램입니다. 자료를 빠르게 원시 소스 폴더에 넣을 때 아주 유용합니다. 이미지는 로컬에 내려받으세요. 첨부 폴더 경로를 고정 디렉터리(예: raw/assets/)로 지정하고, 단축키에 연결해 둡니다. 한 가지 유의점 — LLM은 인라인 이미지가 박힌 마크다운을 한 번에(in one pass) 읽지 못합니다. 우회법은, LLM이 텍스트를 먼저 읽게 한 뒤, 참조된 이미지를 따로 보게 하는 것입니다. 좀 투박하지만 충분히 잘 됩니다.

■ 한 겹 더 — 전문 분석

두 가지 공학적 의도가 있습니다. 첫째, 유입 장벽 최소화 — 웹의 비정형 콘텐츠를 시스템 기본 포맷(마크다운)으로 즉시 변환해 인제스트 마찰을 줄입니다. 둘째, 링크 부패(link rot) 방어 — 원격 URL은 언젠가 깨지므로, 이미지를 로컬에 고정해 지식 베이스의 무결성을 지킵니다. 멀티모달 한계에 대한 우회법은 비동기 추론 파이프라인입니다 — [텍스트 파싱 → 필요한 이미지만 선별 호출]로 토큰 낭비를 막고 정확도를 챙깁니다.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

스크랩북 만들기입니다. 웹에서 좋은 글을 보면, 복잡한 광고·메뉴는 다 떼고 본문만 깔끔히 오려 노트에 붙이는 가위가 ‘웹 클리퍼’입니다. 그런데 사진은 따로 챙겨야 합니다. 웹의 사진은 남의 집에 걸린 그림이라, 그 집이 문을 닫으면(=사이트가 사라지면) 내 노트의 사진도 같이 증발합니다. 그래서 사진을 내 서랍(raw/assets/)에 복사해 둡니다. 단축키 하나면 글 속 사진이 전부 내 컴퓨터에 저장돼요. 마지막 팁 — AI는 아직 글과 사진을 한입에 같이 못 읽습니다. 그래서 “글 먼저 읽고, 그다음에 필요한 사진을 따로 보여주기”로 나눠 줍니다. 조금 번거롭지만, 글과 그림을 둘 다 이해시키는 확실한 방법이죠.

6-2. 모양 보기 — 그래프 뷰

“ 원문 + 번역

Obsidian’s graph view is the best way to see the shape of your wiki — what’s connected to what, which pages are hubs³⁹, which are orphans.

번역 — 옵시디언 그래프 뷰는 위키의 생김새를 보는 최고의 방법입니다 — 무엇이 무엇과 연결됐는지, 어떤 페이지가 *허브(hub)*인지, 어떤 게 외톨이인지를요.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

노트 전체를 별자리 지도처럼 보여주는 기능입니다. 페이지 하나하나가 별이고, 링크가 별을 잇는 선이죠. 선이 잔뜩 모이는 밝은 별(허브) 은 내 지식의 중심 주제이고, 아무 선도 없이 외따로 떠 있는 별은 연결을 까먹은 외톨이입니다. 지도를 쓱 보기만 해도 “아, 이 주제는 너무 빈약하네”, “여기는 잘 엮였네”가 한눈에 들어옵니다.

6-3. 내보내기와 자동화 — Marp · Dataview · Git

“ 원문 + 번역

Marp is a markdown-based slide deck format. … Useful for generating presentations directly from wiki content. Dataview⁴⁰ is an Obsidian plugin that runs queries over page frontmatter⁴¹. If your LLM adds YAML frontmatter to wiki pages (tags, dates, source counts), Dataview can generate dynamic tables and lists. The wiki is just a git⁴² repo of markdown files. You get version history, branching, and collaboration for free.

번역 — Marp는 마크다운 기반 슬라이드 덱 포맷입니다. 위키 내용에서 바로 발표 자료를 만들 때 유용합니다. **데이터뷰(Dataview)**는 페이지 프론트매터에 대고 질의를 돌리는 옵시디언 플러그인입니다. LLM이 위키 페이지에 YAML 프론트매터(태그·날짜·출처 수)를 달아두면, 데이터뷰가 동적 표와 목록을 자동 생성합니다. 위키는 그저 마크다운 파일들의 git 저장소일 뿐입니다. 그래서 버전 기록, 브랜치, 협업을 공짜로 얻습니다.

■ 한 겹 더 — 전문 분석

세 도구는 위키를 각기 다른 방향으로 확장합니다. Marp: 같은 텍스트를 발표용 뷰로 즉시 렌더링(포맷 변환 비용 0). Dataview: YAML 메타데이터를 심으면 평범한 노트 더미가 관계형 DB처럼 질의 가능해집니다 — 입력단(LLM이 메타데이터 규격화)과 출력단(자동 표 생성)이 맞물리죠. Git: 지식을 코드처럼 다루는 정점입니다. 에이전트가 브랜치를 따서 위키를 고치고, 사람이 검토 후 머지(merge)하는 Knowledge-as-Code 워크플로우가 가능해집니다. 셋 다 독점 포맷을 피하고 가장 단순·보편적인 마크다운에 얹힌다는 점이 핵심입니다.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

• Marp: 잘 정리된 노트를, 따로 파워포인트를 켜지 않고 그 자리에서 발표 슬라이드로 변신시킵니다. 노트가 곧 발표 자료가 되는 거죠.
• Dataview: 각 페이지 맨 위에 “분류표 딱지”(날짜·태그 같은)를 붙여두면, “올해 추가한 페이지만 표로 모아줘” 같은 게 자동으로 됩니다. 흩어진 노트가 엑셀 표처럼 정리되는 마법입니다.
• Git: 이 위키는 결국 평범한 텍스트 파일 묶음이라, 프로그래머들이 쓰는 ‘무한 되돌리기 + 백업 + 공동작업’ 시스템을 그대로 공짜로 씁니다. “어제 상태로 되돌려줘”가 언제든 가능하다는 뜻이에요.

---

7. 왜 이 방식이 통하는가 — 핵심 논거

여기가 글의 절정입니다. 카파시는 “왜 사람의 위키는 죽고, LLM의 위키는 사는가”를 단 몇 문장으로 갈라냅니다.

“ 원문 + 번역

The tedious part of maintaining a knowledge base is not the reading or the thinking — it’s the bookkeeping. Updating cross-references, keeping summaries current, noting when new data contradicts old claims, maintaining consistency across dozens of pages. Humans abandon wikis because the maintenance burden grows faster than the value.

번역 — 지식 베이스 유지에서 지긋지긋한 부분은 읽기나 생각하기가 아닙니다 — 장부 정리(bookkeeping) 입니다. 상호 참조 갱신, 요약 최신화, 새 데이터가 옛 주장과 어긋날 때 표시하기, 수십 페이지의 일관성 지키기. 사람이 위키를 포기하는 이유는, 유지보수 부담이 그 가치보다 더 빨리 커지기 때문입니다.

“ 원문 + 번역

LLMs don’t get bored, don’t forget to update a cross-reference, and can touch 15 files in one pass. The wiki stays healthy because the cost of maintenance is near zero. The human’s job is to curate sources, direct the analysis, ask good questions, and think about what it all means. The LLM’s job is everything else.

번역 — LLM은 지루해하지 않고, 상호 참조 갱신을 까먹지 않으며, 한 번에 15개 파일을 손볼 수 있습니다. 유지보수 비용이 거의 0이기 때문에 위키는 건강을 유지합니다. 사람의 일은 자료를 고르고, 분석을 지휘하고, 좋은 질문을 던지고, 그것이 무엇을 뜻하는지 생각하는 것입니다. LLM의 일은 그 나머지 전부입니다.

■ 한 겹 더 — 전문 분석

카파시의 진단은 인지 노동과 행정 노동의 분리입니다. 사람의 뇌는 패턴 인식·추론(읽기·생각하기)에 최적이라, 단순 정렬 노동(장부 정리)을 강요받으면 시스템 전체를 방치하게 됩니다. 그리고 이것은 한계 비용의 경제학이기도 합니다 — 노드가 늘수록 갱신해야 할 링크가 비선형적으로 폭증하므로, 유지보수 비용 곡선이 가치 곡선을 추월하는 순간 모든 인간 위키는 화석이 됩니다. LLM은 지루함·망각이 없고 한 번에 다수 파일을 수정하므로 그 비용을 0 근처로 수축시킵니다. 결론의 두 문장은 AI 시대 지적 분업의 좌표 — 사람은 의도(intent), 기계는 구현(implementation) — 를 압축합니다.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

왜 다들 노트 정리를 작심삼일로 끝낼까요? 공부가 싫어서가 아닙니다. 책 읽는 건 재밌어요. 생각하는 것도 좋고요. 정말 싫은 건 그 뒤치다꺼리 입니다 — “이 내용 어느 폴더에 넣지”, “저 페이지 링크도 고쳐야 하는데”, “예전 메모랑 안 맞네 수정해야지”… 이 잡일이 산더미처럼 쌓이면, 어느 날 “에라 모르겠다” 하고 노트를 덮어버립니다. 카파시의 한 줄 요약: “노트가 죽는 건 관리가 귀찮아서다.” 관리의 가치보다 관리의 수고가 더 빨리 커지는 순간 사람은 손을 놓습니다. 그런데 AI는 지루함을 모르고, 링크 고치는 걸 까먹지 않고, 한 번에 파일 15개를 동시에 손봅니다. 즉 그 ‘귀찮음’의 비용이 거의 0이 됩니다. 비용이 0이니 노트가 죽지 않습니다. 그래서 역할이 깔끔하게 갈립니다 — 당신은 “무엇을 읽고, 무엇을 묻고, 이게 무슨 의미인지 생각”하는 재밌는 일을, AI는 그 외 모든 뒤치다꺼리를 맡습니다.

7-1. 80년 전의 꿈 — 메멕스(Memex)

“ 원문 + 번역

The idea is related in spirit to Vannevar Bush’s Memex⁴³ (1945) — a personal, curated knowledge store with associative trails⁴⁴ between documents. … Bush’s vision was closer to this than to what the web became: private, actively curated, with the connections between documents as valuable as the documents themselves. The part he couldn’t solve was who does the maintenance. The LLM handles that.

번역 — 이 아이디어는 정신적으로 *바네바 부시의 메멕스(1945)*와 닿아 있습니다 — 문서들 사이에 *연상의 길(associative trails)*을 놓은, 사적이고 엄선된 개인 지식 저장소죠. 부시의 비전은 오늘날의 웹보다 오히려 이 시스템에 더 가깝습니다 — 사적이고, 능동적으로 큐레이션되며, 문서 사이의 연결이 문서 그 자체만큼 가치 있는 체계 말입니다. 그가 끝내 풀지 못한 것은 “그 유지보수를 누가 하느냐”였습니다. 이제 LLM이 그것을 해냅니다.

■ 한 겹 더 — 전문 분석

카파시는 자신의 제안에 80년의 역사적 정통성을 부여합니다. 메멕스는 하이퍼텍스트(클릭으로 문서를 잇는 개념)의 원형으로, 오늘날 옵시디언의 링크와 그래프 뷰가 바로 그 “연상의 길”의 후예입니다. 그가 짚는 통렬한 지점은, 대중화된 월드 와이드 웹이 광고·알고리즘·잡음의 바다로 변질되며 부시의 이상(사적이고 정제된 지식망)에서 오히려 멀어졌다는 것. 부시가 1945년 풀지 못한 단 하나의 병목 — 방대한 연결의 유지보수를 누가 하는가 — 이 마침내 LLM으로 해결된다는 선언으로 글이 닫힙니다.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

1945년, 2차 대전이 끝나갈 무렵 바네바 부시라는 과학자가 꿈을 적었습니다. “한 사람의 책상에, 자기가 읽은 모든 책과 메모가 들어 있고, 생각의 흐름을 따라 이 문서에서 저 문서로 휙휙 건너뛸 수 있는 기계가 있다면?” 그는 이걸 메멕스라 불렀습니다. 인터넷도 없던 시절의 상상이었죠. 재밌는 반전 — 우리가 만든 인터넷(웹) 은 사실 부시의 꿈과 좀 다르게 컸습니다. 광고와 가짜뉴스로 시끄러운 공용 광장이 됐죠. 부시가 진짜 원한 건 조용하고, 나만을 위해 엄선된, 연결이 보물인 개인 서재였습니다 — 바로 이 LLM 위키처럼요. 그런데 부시의 꿈엔 치명적 구멍이 하나 있었습니다. “그 수많은 연결을 대체 누가 일일이 잇고 관리하지?” 1945년엔 답이 없었습니다(사람이 손으로 해야 했으니까). 80년이 지나, 그 답이 나왔습니다 — LLM이 합니다. 이 한 문장으로 글이 끝납니다.

---

8. 맺으며 — 이 문서는 일부러 추상적이다

“ 원문 + 번역

This document is intentionally abstract. It describes the idea, not a specific implementation. … Everything mentioned above is optional and modular — pick what’s useful, ignore what isn’t. … The right way to use this is to share it with your LLM agent and work together to instantiate a version that fits your needs.

번역 — 이 문서는 일부러 추상적으로 썼습니다. 특정 구현이 아니라 아이디어를 설명합니다. 위에 언급한 모든 것은 선택이자 모듈입니다 — 쓸 만한 건 고르고, 아닌 건 무시하세요. 올바른 사용법은, 이 글을 당신의 LLM 에이전트와 공유해 당신 필요에 맞는 버전을 함께 구체화하는 것입니다.

☕ 🧑‍🍳 파인만의 부엌 — 쉬운 설명

마지막으로 카파시가 못박습니다 — “이건 정답지가 아니라 출발점이다.” 여기 나온 도구(옵시디언, qmd, Marp…)는 예시일 뿐, 안 맞으면 빼도 됩니다. 텍스트만 다룬다면 이미지 처리는 통째로 건너뛰고, 노트가 작으면 검색 엔진도 필요 없습니다. 가장 좋은 쓰는 법? 이 글 전체를 당신의 AI에게 보여주고 “이런 걸 만들고 싶어, 같이 설계하자” 고 말하는 것입니다. 그게 이 “아이디어 파일”의 진짜 용도입니다.

---

한 문장으로 다시

RAG는 매번 도서관을 새로 뒤지는 학생이고, LLM 위키는 공부하며 정리노트를 계속 키우는 학생이다. 노트를 키우는 귀찮은 뒤치다꺼리(장부 정리)를 AI가 공짜로 떠맡기 때문에, 80년 전 메멕스가 꿈만 꾸던 살아있는 개인 지식망이 비로소 가능해졌다. 당신은 읽고·묻고·생각하고, AI는 그 나머지 전부를 한다.

---

용어집 (주석)

■ 보는 법

본문 곳곳의 작은 숫자(예: RAG¹)를 누르면 이 풀이로 연결됩니다. 거꾸로 각 항목 끝의 ↩ 표시를 누르면 본문으로 돌아갑니다. 아래 풀이는 “처음 듣는 사람”을 기준으로 썼습니다.

1. 1
   RAG (Retrieval-Augmented Generation, 검색 증강 생성) — LLM이 답하기 전에, 먼저 외부 문서에서 관련 내용을 검색해 와서 그걸 참고해 답을 만드는 방식. “AI가 책을 펼쳐놓고 시험 보는 오픈북” 정도로 생각하면 된다. 카파시가 비판하는 건 RAG가 매번 처음부터 검색한다는 점이다. ↩
2. 2
   패턴 (Pattern) — 소프트웨어 공학의 ‘디자인 패턴’에서 온 말. 한 번 쓰고 버리는 해법이 아니라, 비슷한 문제마다 변형해 재사용하는 검증된 설계 틀을 뜻한다. ↩
3. 3
   청크 (Chunk, 조각) — 긴 문서를 검색하기 좋게 잘라 놓은 작은 텍스트 토막. RAG는 문서 전체가 아니라 이 조각 단위로 찾아 와서 답에 쓴다. ↩
4. 4
   쿼리 타임 (Query time, 질의 시점) — “사용자가 질문을 던지는 바로 그 순간”. 반대말은 빌드 타임(build time), 즉 “미리 준비해 두는 시점”. 카파시의 핵심은 비싼 일을 쿼리 타임이 아니라 빌드 타임에 끝내 두자는 것. ↩
5. 5
   컨텍스트 윈도우 (Context window) — LLM이 한 번에 “눈앞에 펼쳐 놓고 볼 수 있는” 텍스트의 최대 분량. 사람으로 치면 한 번에 기억할 수 있는 단기 기억의 크기. 이 창을 벗어난 내용은 잊힌다. ↩
6. 6
   지속성 (Persistent) — 세션이 끝나거나 전원이 꺼져도 사라지지 않고 남는 성질. 채팅 기록은 휘발성(사라짐), 디스크에 저장된 위키 파일은 지속성(남음). ↩
7. 7
   마크다운 (Markdown) — #으로 제목, -로 목록, [글자](링크)로 링크를 표현하는 아주 단순한 텍스트 서식 문법. 메모장으로도 열리고, 사람도 AI도 쉽게 읽고 쓴다. 이 문서도 마크다운으로 쓰였다. ↩
8. 8
   엔티티 (Entity, 개체) — 위키에서 하나의 독립된 대상에 부여하는 페이지. 인물·회사·개념·장소처럼 “이름 붙은 것” 하나하나가 엔티티가 된다. (예: ‘바네바 부시’ 페이지, ‘메멕스’ 페이지) ↩
9. 9
   복리 (Compounding) — 원금에 붙은 이자에 다시 이자가 붙어 눈덩이처럼 불어나는 것. 여기서는 지식이 서로 연결되며 가치가 가속도로 커진다는 비유. ↩
10. 10
    상호 참조 (Cross-reference) — 한 페이지에서 다른 페이지로 거는 연결(링크). “이 내용은 저기서도 다룸 →” 식의 안내. 위키를 그물처럼 엮는 실이다. ↩
11. 11
    잡일 (Grunt work) — 머리는 안 쓰지만 손이 많이 가는, 단순 반복의 고된 작업. 여기서는 요약·링크 걸기·분류 같은 정리 노동. ↩
12. 12
    장부 정리 (Bookkeeping) — 원래는 회계 기록을 꼼꼼히 맞춰 두는 일. 여기서는 위키의 앞뒤를 끊임없이 맞추는 유지보수 전반을 가리키는 비유. 카파시가 꼽는 “사람이 위키를 포기하는 진짜 이유”. ↩
13. 13
    옵시디언 (Obsidian) — 마크다운 파일을 노트로 관리하는 인기 앱. 노트 사이를 링크로 잇고, 그 연결망을 그래프로 보여주는 기능이 강점이라 이 위키 방식과 궁합이 좋다. ↩
14. 14
    그래프 뷰 (Graph view) — 옵시디언에서 노트(점)와 링크(선)를 별자리 지도처럼 시각화해 보여주는 화면. 어떤 노트가 중심이고 어떤 게 외톨이인지 한눈에 보인다. ↩
15. 15
    IDE (통합 개발 환경) — 프로그래머가 코드를 쓰고·고치고·실행하는 작업 공간 프로그램. 카파시는 “옵시디언=IDE, LLM=프로그래머, 위키=코드(결과물)”이라는 비유로, 지식을 코드처럼 다루자고 한다. ↩
16. 16
    논지/테제 (Thesis) — 연구가 내세우는 핵심 주장. “진화하는 논지”란, 자료가 쌓이며 주장 자체가 계속 다듬어진다는 뜻. 결론을 미리 정해 두지 않는다. ↩
17. 17
    HITL (Humans in the loop, 인간 개입형) — 자동 시스템의 중간에 사람이 끼어 결과를 검토·승인하는 방식. AI가 잘못 정리할 위험(환각)을 사람이 최종 점검으로 막는 안전장치. ↩
18. 18
    불변 (Immutable) — 한 번 정해지면 고치지 않는 성질. 원시 소스를 불변으로 두는 이유는, 나중에 “원본이 진짜 뭐였나”를 언제든 확인하기 위해서다. ↩
19. 19
    진실의 원천 (Source of Truth, SSOT) — 무언가 헷갈릴 때 최종적으로 믿고 돌아갈 기준이 되는 원본. 사본끼리 어긋나면 이 원천을 보고 바로잡는다. ↩
20. 20
    CLAUDE.md / AGENTS.md — AI 에이전트에게 “이 프로젝트에서 너는 이렇게 일해라”를 적어 두는 규칙 파일. AI가 작업을 시작할 때 자동으로 읽어, 매번 지시하지 않아도 정해진 방식대로 움직이게 한다. (각각 Claude Code, Codex용) ↩
21. 21
    공진화 (Co-evolve) — 둘이 서로 영향을 주며 함께 변해 가는 것. 여기서는 사람과 AI가 규칙 파일(스키마)을 운영하며 같이 다듬어 가는 과정. ↩
22. 22
    인제스트 (Ingest, 흡수/적재) — 새 자료를 시스템에 들여와 읽고·소화시켜 위키에 반영하는 일련의 처리 과정. 단순 업로드가 아니라 “먹어서 영양분으로 바꾸는” 쪽에 가깝다. ↩
23. 23
    배치 (Batch, 일괄) — 여러 건을 하나씩이 아니라 한꺼번에 모아 처리하는 방식. 반대는 한 건씩 처리(one at a time). ↩
24. 24
    출처 표기 (Citation) — 답의 각 내용이 어느 페이지/자료에서 나왔는지 근거를 밝히는 것. 나중에 사실 확인을 할 수 있게 해 준다. ↩
25. 25
    Marp — 마크다운으로 발표 슬라이드를 만드는 도구. 노트를 따로 옮기지 않고 그대로 프레젠테이션으로 변환할 수 있다. ↩
26. 26
    린트 (Lint) — 원래는 프로그램 코드의 잠재적 오류·나쁜 습관을 자동으로 찾아 주는 검사 도구. 여기서는 위키의 모순·낡은 내용·끊긴 링크를 점검하는 건강검진을 뜻한다. ↩
27. 27
    낡은 주장 (Stale claim) — 한때는 맞았지만, 더 새로운 자료가 나오면서 이미 틀렸거나 뒤처진 내용. 갱신하지 않으면 위키에 잘못된 정보로 남는다. ↩
28. 28
    고아 페이지 (Orphan page) — 어떤 다른 페이지에서도 링크가 걸려 있지 않아, 아무도 찾아오지 않는 외톨이 페이지. 존재는 하지만 사실상 묻혀 있는 상태. ↩
29. 29
    메타데이터 (Metadata) — “데이터에 대한 데이터”. 내용 자체가 아니라 그 내용에 딸린 정보(작성 날짜, 태그, 출처 개수 등). 책으로 치면 본문이 아니라 표지의 출판 정보 같은 것. ↩
30. 30
    임베딩 / 벡터 검색 (Embedding / Vector search) — 글의 의미를 숫자 좌표(벡터)로 바꿔, 뜻이 비슷한 글을 좌표가 가까운 것으로 찾아내는 검색 기술. 강력하지만 별도 인프라(벡터 DB 등)가 필요해 무겁다. 카파시는 “중간 규모까진 굳이 이게 필요 없다”고 본다. ↩
31. 31
    추가 전용 (Append-only) — 기존 내용을 고치거나 지우지 않고, 맨 뒤에 덧붙이기만 하는 기록 방식. 항해 일지나 회계 장부처럼 과거 기록의 무결성이 보장된다. ↩
32. 32
    BM25 — 검색어(키워드)가 문서에 얼마나·어떻게 등장하는지를 따져 관련도를 매기는 전통적 키워드 검색 알고리즘. “단어가 일치하는가”를 본다. (의미까지 보는 벡터 검색과 대비됨) ↩
33. 33
    재정렬 (Re-ranking) — 1차로 추려낸 검색 결과들을, LLM이 한 번 더 읽어보고 질문에 진짜 잘 맞는 순서로 다시 줄 세우는 후처리. 검색의 정확도를 끌어올린다. ↩
34. 34
    온디바이스 (On-device) — 외부 서버(클라우드)로 데이터를 보내지 않고 내 기기 안에서 처리하는 것. 개인정보·보안에 유리하고 오프라인에서도 작동한다. ↩
35. 35
    CLI (Command-Line Interface, 명령줄 도구) — 그래픽 버튼 대신 글자 명령어로 프로그램을 다루는 방식. AI 에이전트가 명령어 한 줄로 도구를 호출하기에 편하다. ↩
36. 36
    셸 아웃 (Shell out) — 프로그램이 운영체제의 *명령줄(셸)*을 통해 다른 외부 프로그램을 불러 실행하는 것. 여기서는 LLM이 검색 도구(qmd)를 명령어로 돌리는 것을 말한다. ↩
37. 37
    MCP (Model Context Protocol) — LLM이 외부 도구·데이터에 표준화된 방식으로 연결되도록 정한 규격. 이 규격을 따르면 검색 엔진 같은 도구를 LLM의 “내장 기능”처럼 자연스럽게 붙여 쓸 수 있다. ↩
38. 38
    바이브 코딩 (Vibe-coding) — 엄밀한 사전 설계 없이, 필요할 때 AI와 주거니 받거니 하며 즉석에서 코드를 만들어 쓰는 요즘의 개발 스타일. “느낌(vibe) 가는 대로” 빠르게 만든다는 뉘앙스. ↩
39. 39
    허브 (Hub) — 링크가 유난히 많이 모이는, 그물의 중심 매듭 같은 페이지. 그 주제가 내 지식망의 핵심임을 보여준다. ↩
40. 40
    데이터뷰 (Dataview) — 옵시디언 플러그인. 각 노트에 달아 둔 메타데이터(태그·날짜 등)를 *질의(query)*해서, 조건에 맞는 노트들을 자동으로 표·목록으로 모아 보여 준다. 노트 더미를 엑셀 표처럼 다루게 해 준다. ↩
41. 41
    프론트매터 (Frontmatter) — 마크다운 파일 맨 위에 ---로 감싸 적는 메타데이터 블록(보통 YAML 형식). 그 문서의 태그·날짜·종류 등을 기계가 읽기 좋게 적어 둔다. ↩
42. 42
    깃 (Git) — 파일의 모든 변경 이력을 저장해 두는 버전 관리 시스템. “어제 상태로 되돌리기”, 여러 갈래로 나눠 작업하기(브랜치), 합치기(머지), 공동 작업이 가능하다. 마크다운 위키를 깃에 올리면 이 기능들을 공짜로 얻는다. ↩
43. 43
    메멕스 (Memex) — 1945년 과학자 바네바 부시가 논문 〈As We May Think〉에서 상상한 가상의 기계. 한 사람의 모든 책·기록을 담고, 생각의 흐름을 따라 문서 사이를 넘나들 수 있는 개인 지식 장치. 오늘날 하이퍼링크·위키의 사상적 조상으로 꼽힌다. ↩
44. 44
    연상의 길 (Associative trails) — 메멕스의 핵심 개념. 문서와 문서를 생각의 연상에 따라 잇는 경로. “이걸 읽다 보니 저게 떠올랐다”를 길로 남겨 두는 것 — 오늘날의 하이퍼링크가 바로 이것이다. ↩

---

■ 문서 정보

카파시의 LLM Wiki 원문을 섹션별로 번역하고, 각 대목에 ① 전문 분석과 ② 파인만식 쉬운 설명을 덧붙인 해설본입니다. 원문 인용은 핵심 문장 위주로 발췌했으며, 전체 원문은 상단의 gist 링크에서 볼 수 있습니다. 번역·해설의 강조나 비유는 이해를 돕기 위한 것으로, 원문에 없는 표현이 포함될 수 있습니다.