LLM을 활용해 개인 지식 베이스를 만드는 한 가지 패턴 by 안드레 카파시

^{source https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f}

이 문서는 아이디어를 설명하기 위한 파일이다. 그대로 복사해서 당신이 쓰는 LLM 에이전트(OpenAI Codex, Claude Code, OpenCode / Pi 등)에 붙여 넣도록 만들어졌다. 목표는 큰 방향의 아이디어를 전달하는 것이고, 구체적인 구현은 당신과 에이전트가 함께 맞춰 가며 만들어 가면 된다.

핵심 아이디어

대부분의 사람들이 LLM과 문서를 다루는 방식은 RAG에 가깝다. 파일 묶음을 업로드하면, 질문 시점에 LLM이 관련 청크를 찾아서 답을 생성하는 식이다. 이 방식도 작동은 한다. 하지만 질문할 때마다 LLM이 지식을 처음부터 다시 발견해야 한다. 다섯 개 문서를 엮어야 겨우 답할 수 있는 미묘한 질문이 들어오면, 그때마다 관련 조각을 다시 찾고 다시 짜 맞춰야 한다. 축적되는 게 없다. NotebookLM, ChatGPT 파일 업로드, 그리고 대부분의 RAG 시스템이 이런 식으로 동작한다.

여기서 말하는 아이디어는 다르다. 원문 문서를 질문 시점에 그냥 불러오는 대신, LLM이 지속적으로 유지되는 위키를 조금씩 구축하고 관리한다. 이 위키는 구조화되고 서로 링크된 Markdown 파일 모음이며, 당신과 원본 소스 사이에 놓인다. 새 소스를 추가하면 LLM은 그걸 나중에 검색하기 위해 인덱싱만 해 두지 않는다. 직접 읽고, 핵심 정보를 뽑아내고, 기존 위키에 통합한다. 엔터티 페이지를 업데이트하고, 주제 요약을 다듬고, 새 데이터가 기존 주장과 충돌하는 지점을 기록하고, 계속 진화하는 종합 정리를 강화하거나 다시 점검한다. 지식은 질문할 때마다 다시 만들어지는 게 아니라, 한 번 정리되고 이후 계속 최신 상태로 유지된다.

핵심 차이는 이것이다. 위키 자체가 지속적으로 누적되는 산출물이라는 점이다. 교차 참조는 이미 걸려 있고, 모순은 이미 표시돼 있으며, 종합 정리는 지금까지 읽은 모든 내용을 이미 반영하고 있다. 소스를 하나 추가할 때마다, 질문을 하나 던질 때마다 위키는 더 풍부해진다.

직접 위키를 쓰는 일은 거의 없거나 아예 없다. 위키는 LLM이 쓰고 관리한다. 당신이 맡는 일은 소스를 모으고, 탐색 방향을 정하고, 좋은 질문을 던지는 것이다. 실제로 손이 많이 가는 일, 즉 요약하고, 연결하고, 분류하고, 장기적으로 쓸 만한 지식 베이스가 되도록 자잘한 관리 작업을 하는 일은 전부 LLM이 맡는다. 내 경우엔 한쪽에 LLM 에이전트를 띄워 두고, 다른 쪽에는 Obsidian을 켜 둔다. 대화를 바탕으로 LLM이 파일을 수정하면, 나는 실시간으로 결과를 훑는다. 링크를 따라가고, 그래프 뷰를 보고, 갱신된 페이지를 읽는다. Obsidian이 IDE라면, LLM은 프로그래머이고, 위키는 코드베이스인 셈이다.

이 패턴은 꽤 다양한 맥락에 적용할 수 있다. 예를 들면:

• 개인용: 목표, 건강, 심리, 자기계발 같은 주제를 추적하면서 일기, 기사, 팟캐스트 메모를 정리하고, 시간이 지나며 스스로에 대한 구조화된 그림을 쌓아 갈 수 있다.

• 리서치: 몇 주 혹은 몇 달에 걸쳐 한 주제를 깊게 파고들면서 논문, 기사, 보고서를 읽고, 점점 더 정교한 논지를 가진 종합 위키를 만들어 갈 수 있다.

• 책 읽기: 장을 읽을 때마다 정리하고, 등장인물, 테마, 플롯, 연결 관계를 페이지로 쌓아 갈 수 있다. 다 읽고 나면 훌륭한 동반 위키가 생긴다. Tolkien Gateway 같은 팬 위키를 떠올리면 된다. 캐릭터, 장소, 사건, 언어를 다루는 수천 개의 상호 링크된 페이지가 수년간 자원봉사자 손으로 쌓였다. 읽는 동안 LLM이 교차 참조와 유지 보수를 맡아 준다면, 그와 비슷한 것을 개인 차원에서도 만들 수 있다.

• 비즈니스/팀: Slack 스레드, 회의 녹취, 프로젝트 문서, 고객 통화 기록을 받아 먹으며 LLM이 유지하는 내부 위키를 만들 수 있다. 사람은 중간에 검토자로 들어갈 수도 있다. 팀에서 아무도 하고 싶어 하지 않는 유지 보수 작업을 LLM이 대신하니 위키가 최신 상태로 남는다.

• 경쟁사 분석, 실사, 여행 계획, 강의 노트, 취미 깊게 파기 등 시간이 지나며 지식이 누적되는 어떤 주제에도 적용할 수 있다. 흩어진 메모가 아니라 정리된 구조로 쌓고 싶다면 잘 맞는다.

아키텍처

구성은 세 층으로 나뉜다.

Raw sources — 엄선해 모아 둔 원본 소스 문서들이다. 기사, 논문, 이미지, 데이터 파일 등이 여기에 들어간다. 이 층은 불변이다. LLM은 여기서 읽기만 하고, 수정하지 않는다. 즉, 당신의 최종적인 source of truth다.

The wiki — LLM이 생성한 Markdown 파일 디렉터리다. 요약 페이지, 엔터티 페이지, 개념 페이지, 비교 페이지, 개요, 종합 정리 등이 여기에 들어간다. 이 층은 LLM이 전적으로 책임진다. 페이지를 만들고, 새 소스가 들어오면 업데이트하고, 교차 링크를 관리하고, 전체 일관성을 유지한다. 당신은 읽고, LLM은 쓴다.

The schema — 위키 구조, 규칙, 워크플로를 LLM에 알려 주는 문서다. 예를 들면 Claude Code의 CLAUDE.md, Codex의AGENTS.md 같은 파일이 여기에 해당한다. 위키를 어떤 방식으로 조직할지, 어떤 컨벤션을 따를지, 소스를 ingest할 때와 질문에 답할 때, 유지 보수를 할 때 어떤 절차를 밟을지 정의한다. 이 파일이 핵심 설정이다. 이게 있어야 LLM이 그냥 범용 챗봇이 아니라, 규율 있게 움직이는 위키 관리자가 된다. 실제로는 당신과 LLM이 함께 써 나가며, 도메인에 맞게 계속 발전시키게 된다.

운영 방식

Ingest. 새 소스를 raw collection에 넣고, LLM에게 처리하라고 지시한다. 예를 들어 이런 흐름이 가능하다. LLM이 소스를 읽고, 당신과 핵심 내용을 짚고, 위키에 요약 페이지를 쓰고, 인덱스를 업데이트하고, 관련된 엔터티와 개념 페이지를 전반적으로 수정하고, 마지막으로 로그에 항목을 추가한다. 소스 하나가 위키 페이지 10~15개를 건드릴 수도 있다. 내 취향은 소스를 한 번에 하나씩 ingest하면서 계속 관여하는 쪽이다. 요약을 읽고, 업데이트를 확인하고, 무엇을 더 강조할지 LLM에 방향을 준다. 물론 여러 소스를 한꺼번에 덜 감독하면서 배치 ingest할 수도 있다. 자기 스타일에 맞는 워크플로를 정하고, 그걸 schema에 문서화해 두면 이후 세션에서도 그대로 이어 갈 수 있다.

Query. 위키를 대상으로 질문한다. LLM은 관련 페이지를 찾고, 읽고, 인용을 붙여 답을 종합한다. 답의 형태는 질문에 따라 달라질 수 있다. Markdown 페이지일 수도 있고, 비교 표일 수도 있고, 슬라이드 덱(Marp), 차트(matplotlib), 캔버스일 수도 있다. 여기서 중요한 포인트는 좋은 답변은 다시 위키에 새 페이지로 저장할 수 있다는 점이다. 비교 정리, 분석, 새롭게 발견한 연결점 같은 것들은 가치가 있는데, 채팅 기록 속에서 사라지게 둘 이유가 없다. 이렇게 하면 탐색 과정에서 나온 결과도, ingest한 소스처럼 지식 베이스 안에서 계속 누적된다.

Lint. 주기적으로 LLM에게 위키 상태를 점검하라고 시킨다. 예를 들어 이런 걸 보면 된다. 페이지끼리 모순되는 내용이 있는지, 더 최근 소스 때문에 낡아 버린 주장이 남아 있는지, 들어오는 링크가 없는 orphan 페이지가 있는지, 자주 언급되지만 독립 페이지가 없는 중요한 개념이 있는지, 빠진 교차 참조가 있는지, 웹 검색으로 메울 수 있는 데이터 공백이 있는지. LLM은 어떤 질문을 더 조사해 보면 좋을지, 어떤 소스를 더 찾아오면 좋을지도 잘 제안한다. 위키가 커질수록 이런 작업이 전체 건강을 유지해 준다.

인덱싱과 로깅

위키가 커질수록 LLM과 사람이 길을 잃지 않게 도와주는 특수 파일 두 개가 있다. 둘은 역할이 다르다.

index.md는 내용 중심이다. 위키 안의 모든 것을 한눈에 보여 주는 카탈로그다. 각 페이지에 링크, 한 줄 요약, 필요하면 날짜나 source 개수 같은 메타데이터를 붙여 둔다. 보통 엔터티, 개념, 소스 같은 카테고리별로 정리한다. LLM은 ingest할 때마다 이 파일을 업데이트한다. 질문에 답할 때는 먼저 index를 읽고 관련 페이지를 고른 다음, 그 안으로 들어가 본다. 규모가 중간 정도일 때(~100개 소스, ~수백 개 페이지) 이 방식이 생각보다 꽤 잘 먹히고, 임베딩 기반 RAG 인프라 없이도 충분히 굴러간다.

log.md는 시간 순이다. 어떤 일이 언제 일어났는지 적어 두는 append-only 기록이다. ingest, query, lint pass가 모두 여기에 남는다. 유용한 팁 하나를 들자면, 각 항목을 일관된 접두사로 시작하게 하면 된다. 예를 들어 ## [2026-04-02] ingest | Article Title 같은 형식이다. 그러면 로그를 간단한 unix 도구로도 쉽게 다룰 수 있다. grep "^## \[" log.md | tail -5를 치면 최근 5개 항목이 바로 나온다. 이 로그는 위키가 어떻게 진화해 왔는지 보여 주는 타임라인이자, 최근에 어떤 작업이 있었는지 LLM이 파악하는 데도 도움이 된다.

선택 사항: CLI 도구

어느 시점이 되면, LLM이 위키를 더 효율적으로 다룰 수 있게 도와주는 작은 도구를 직접 만들고 싶어질 수 있다. 가장 먼저 떠오르는 건 위키 페이지용 검색 엔진이다. 규모가 작을 때는 index 파일만으로 충분하지만, 커지기 시작하면 제대로 된 검색이 필요해진다. qmd는 괜찮은 선택지다. Markdown 파일을 대상으로 하는 로컬 검색 엔진이고, hybrid BM25/vector search와 LLM re-ranking을 모두 온디바이스에서 지원한다. CLI도 있고(LLM이 셸로 호출 가능), MCP 서버도 있다(LLM이 네이티브 툴처럼 사용 가능). 더 단순한 걸 직접 만들어도 된다. 필요가 생기면 LLM이 대충 돌아가는 naive search 스크립트를 함께 vibe-code해 줄 수도 있다.

팁과 트릭

• Obsidian Web Clipper는 웹 기사를 Markdown으로 바꿔 주는 브라우저 확장이다. 소스를 raw collection으로 빠르게 가져오는 데 아주 유용하다.

• 이미지는 로컬로 다운로드해 두자. Obsidian Settings → Files and links에서 “Attachment folder path”를 고정 디렉터리(예: raw/assets/)로 설정한다. 그다음 Settings → Hotkeys에서 “Download”를 검색해 “Download attachments for current file”에 단축키를 지정한다(예: Ctrl+Shift+D). 기사를 클리핑한 뒤 이 단축키를 누르면 이미지가 전부 로컬 디스크로 내려받아진다. 이건 선택 사항이지만 꽤 쓸모 있다. URL이 깨질 수 있는 외부 이미지에 기대지 않고, LLM이 로컬 이미지를 직접 보고 참조할 수 있기 때문이다. 참고로 LLM은 인라인 이미지가 들어간 Markdown을 한 번에 자연스럽게 읽지는 못한다. 보통은 먼저 텍스트를 읽고, 그다음 참조된 이미지 일부 혹은 전부를 따로 보게 해서 추가 맥락을 얻는 식으로 우회한다. 조금 번거롭긴 하지만 충분히 실용적이다.

• Obsidian의 graph view는 위키의 형태를 한눈에 보는 데 가장 좋은 방법이다. 무엇이 무엇과 연결돼 있는지, 어떤 페이지가 허브인지, 어떤 페이지가 orphan인지 바로 보인다.

• Marp는 Markdown 기반 슬라이드 덱 포맷이다. Obsidian 플러그인도 있다. 위키 내용을 바로 발표 자료로 만들 때 유용하다.

• Dataview는 페이지 frontmatter를 대상으로 쿼리를 돌리는 Obsidian 플러그인이다. LLM이 위키 페이지에 YAML frontmatter를 붙인다면(tags, dates, source counts 등), Dataview로 동적인 표와 목록을 만들 수 있다.

• 위키는 결국 Markdown 파일로 이루어진 git repo일 뿐이다. 버전 히스토리, 브랜치, 협업 기능이 그냥 따라온다.

왜 이 방식이 먹히는가

지식 베이스를 유지하는 데서 가장 번거로운 부분은 읽거나 생각하는 일이 아니다. 자잘한 관리다. 교차 참조를 갱신하고, 요약을 최신 상태로 유지하고, 새 데이터가 기존 주장과 충돌하는 지점을 표시하고, 수십 개 페이지 사이의 일관성을 맞추는 일 말이다. 사람이 위키를 버리는 이유는 대개 유지 비용이 가치보다 더 빨리 커지기 때문이다. LLM은 지루해하지 않고, 교차 링크 업데이트를 빼먹지도 않으며, 한 번에 15개 파일을 건드리는 것도 어렵지 않다. 유지 비용이 거의 0에 가까워지니 위키도 계속 살아남는다.

사람의 일은 소스를 큐레이션하고, 분석 방향을 정하고, 좋은 질문을 던지고, 그게 무슨 의미인지 생각하는 것이다. 나머지는 전부 LLM의 몫이다.

이 아이디어는 정신적으로는 Vannevar Bush의 Memex(1945)와 닿아 있다. 개인이 큐레이션하는 지식 저장소이자, 문서 사이에 연상적 경로를 만드는 장치라는 점에서 그렇다. Bush가 그린 비전은 오늘날의 웹보다 오히려 여기에 더 가까웠다. 사적이고, 능동적으로 큐레이션되며, 문서 자체만큼이나 문서 사이의 연결이 중요한 구조였다. 그가 해결하지 못했던 문제는 누가 이걸 계속 관리하느냐였다. 그 유지 보수를 LLM이 맡을 수 있다.

Note

이 문서는 의도적으로 추상적으로 써 두었다. 특정 구현을 설명하는 문서가 아니라, 패턴 자체를 설명하는 문서다. 정확한 디렉터리 구조, schema 규칙, 페이지 포맷, 툴링은 모두 당신의 도메인, 취향, 사용하는 LLM에 따라 달라질 수 있다. 위에서 언급한 모든 요소는 선택 사항이고 모듈식이다. 쓸모 있는 것만 고르고, 아닌 것은 버리면 된다. 예를 들어 소스가 텍스트뿐이라면 이미지 처리 같은 건 전혀 필요 없을 수 있다. 위키 규모가 작다면 index 파일만으로 충분하고, 별도 검색 엔진은 필요 없을 수 있다. 슬라이드 덱에는 관심 없고 Markdown 페이지만 원할 수도 있다. 전혀 다른 출력 형식을 원할 수도 있다. 이 문서를 쓰는 가장 좋은 방법은 당신의 LLM 에이전트에게 보여 주고, 함께 당신에게 맞는 버전으로 구체화해 나가는 것이다. 이 문서의 역할은 오직 패턴을 전달하는 데 있다. 나머지는 LLM이 알아서 맞춰 갈 수 있다.