LLM Wiki · 한국어 번역

원문: LLM Wiki · 영문 원문 원저자가 명시한 의도 그대로 — **“본인의 LLM 에이전트에게 복사해 붙여 넣어 같이 작업하라”**는 패턴 글입니다. 직역에 가깝게 옮기되, 한국어로 자연스럽게 읽히도록 다듬었습니다.

LLM으로 개인 지식 베이스를 만드는 패턴입니다.

이 글은 아이디어 문서입니다. 본인의 LLM 에이전트(OpenAI Codex, Claude Code, OpenCode / Pi 등)에 그대로 복사해 붙여 넣어 쓰도록 설계됐습니다. 이 글의 역할은 큰 그림의 아이디어를 전달하는 것이고, 구체적인 부분은 본인의 에이전트가 본인과 같이 빌드해 나갈 겁니다.

핵심 아이디어

대부분의 사람들이 LLM과 문서를 다루는 경험은 RAG(질문이 들어올 때마다 외부에서 검색해 답을 만드는 방식)의 모습을 닮아 있습니다. 파일 모음을 업로드하면, LLM이 질의 시점에 관련 청크를 검색해서 답을 만들어 줍니다. 작동은 합니다. 하지만 LLM은 매 질문마다 지식을 처음부터 다시 발견하고 있는 셈입니다. 누적이 없습니다. 다섯 개 문서를 종합해야 답할 수 있는 미묘한 질문을 던지면, LLM은 매번 관련 조각을 찾아서 다시 짜맞춰야 합니다. 아무것도 쌓이지 않습니다. NotebookLM, ChatGPT 파일 업로드, 대부분의 RAG 시스템이 이런 방식입니다.

여기서 말하는 아이디어는 다릅니다. 질의 시점에 원본 문서에서 그냥 검색하는 대신, LLM이 영속적인 위키를 점진적으로 빌드하고 유지보수합니다. 본인과 원본 소스 사이에 자리잡은, 구조화되고 서로 링크된 마크다운 파일 모음입니다. 새 소스를 추가하면 LLM은 그걸 단순히 인덱싱해 두지 않습니다. 읽고, 핵심 정보를 뽑아내고, 기존 위키에 통합합니다. 엔티티 페이지를 갱신하고, 주제별 요약을 다시 쓰고, 새 데이터가 기존 주장과 충돌하는 지점을 표시하고, 진화하는 종합을 강화하거나 도전합니다. 지식은 한 번 컴파일된 뒤 계속 최신 상태로 유지되는 것이지, 질의마다 다시 도출되는 게 아닙니다.

이게 핵심 차이입니다. 위키는 영속적이고 누적되는 산출물입니다. 상호 참조가 이미 거기 있습니다. 모순은 이미 표시돼 있습니다. 종합은 본인이 읽은 모든 것을 이미 반영하고 있습니다. 위키는 본인이 소스를 추가할 때마다, 질문을 던질 때마다 점점 풍부해집니다.

본인이 위키를 직접 쓰는 일은 거의 없습니다. LLM이 전부 쓰고 유지보수합니다. 본인은 소스 발굴, 탐색, 좋은 질문 던지기를 맡습니다. LLM은 모든 잡일을 합니다. 요약, 상호 참조, 정리, 부기 — 지식 베이스가 시간이 지나도 실제로 쓸모 있게 유지되도록 하는 작업 전부입니다. 실제 운영에서 저는 LLM 에이전트를 한쪽에 띄우고 Obsidian을 다른 쪽에 띄워 둡니다. LLM은 대화를 바탕으로 편집을 하고, 저는 결과를 실시간으로 둘러봅니다. 링크를 따라가고, 그래프 뷰를 확인하고, 갱신된 페이지를 읽습니다. 옵시디언은 IDE, LLM은 프로그래머, 위키는 코드베이스입니다.

이 패턴은 다양한 맥락에 적용할 수 있습니다. 몇 가지 예:

개인: 본인의 목표, 건강, 심리, 자기 개선을 추적하기. 일기, 기사, 팟캐스트 노트를 정리하고, 시간이 지나면서 본인에 대한 구조화된 그림을 쌓아 나가기.
연구: 한 주제를 몇 주, 몇 달에 걸쳐 깊게 파기. 논문·기사·리포트를 읽으면서, 진화하는 논제를 가진 종합 위키를 점진적으로 빌드.
책 읽기: 한 챕터씩 정리하면서, 등장인물·주제·플롯·연결 관계 페이지를 만들어 나가기. 책을 다 읽을 때쯤이면 풍부한 동반 위키가 남습니다. Tolkien Gateway 같은 팬 위키를 떠올려 보세요. 등장인물·장소·사건·언어를 다루는 수천 개의 상호 연결된 페이지를, 자원봉사자 커뮤니티가 수년에 걸쳐 만든 결과물입니다. 같은 걸 본인이 책을 읽으면서 개인적으로 만들 수 있습니다. 상호 참조와 유지보수는 LLM이 합니다.
비즈니스/팀: LLM이 유지보수하는 사내 위키. Slack 스레드, 미팅 녹취록, 프로젝트 문서, 고객 통화로 데이터를 공급합니다. 사람이 루프 안에 들어가 업데이트를 리뷰할 수도 있습니다. 팀원 누구도 하고 싶어하지 않는 유지보수를 LLM이 하기 때문에, 위키는 최신 상태로 유지됩니다.
경쟁 분석, 실사(due diligence), 여행 계획, 강의 노트, 취미 딥다이브 — 시간이 지나며 지식을 누적하고, 흩어져 있기보다 정리돼 있길 원하는 것이라면 무엇이든 가능합니다.

아키텍처

세 개의 레이어가 있습니다.

원본 소스(Raw sources) — 본인이 큐레이션한 소스 문서 모음. 기사, 논문, 이미지, 데이터 파일이 여기 들어갑니다. 이것들은 불변(immutable)입니다. LLM은 여기서 읽기만 할 뿐 절대 수정하지 않습니다. 본인의 단일 진실 공급원(source of truth)입니다.

위키(The wiki) — LLM이 생성한 마크다운 파일들의 디렉터리. 요약, 엔티티 페이지, 개념 페이지, 비교, 개요, 종합. LLM이 이 레이어를 전적으로 소유합니다. 페이지를 만들고, 새 소스가 들어오면 갱신하고, 상호 참조를 유지하고, 전체의 일관성을 지킵니다. 본인은 읽고, LLM이 씁니다.

스키마(The schema) — Claude Code의 CLAUDE.md, Codex의 AGENTS.md 같은 문서. LLM에게 위키가 어떻게 구조화돼 있는지, 어떤 컨벤션을 따르는지, 소스를 인제스트(ingest)하거나 질문에 답하거나 위키를 유지보수할 때 어떤 워크플로우를 따라야 하는지 알려줍니다. 이것이 핵심 설정 파일입니다. LLM을 일반 챗봇이 아니라 규율 있는 위키 관리자로 만드는 자리입니다. 본인과 LLM은 시간이 지나면서 본인 도메인에 무엇이 잘 통하는지 알아 가며 이 스키마를 함께 진화시킵니다.

동작 방식

Ingest(투입). 새 소스를 원본 모음에 떨어뜨리고 LLM에게 처리하라고 합니다. 예시 흐름: LLM이 소스를 읽고, 핵심 시사점을 본인과 논의하고, 위키에 요약 페이지를 쓰고, 인덱스를 갱신하고, 위키 전반의 관련 엔티티·개념 페이지를 갱신하고, 로그에 항목을 덧붙입니다. 한 소스가 위키 페이지 10〜15개를 건드릴 수도 있습니다. 개인적으로 저는 소스를 한 번에 하나씩 인제스트하고 계속 관여하는 쪽을 선호합니다. 요약을 읽고, 갱신을 확인하고, LLM에게 무엇을 강조할지 가이드합니다. 하지만 감독을 덜 하면서 여러 소스를 한꺼번에 일괄 인제스트할 수도 있습니다. 본인 스타일에 맞는 워크플로우는 본인이 개발해서 스키마에 문서화해 두면 다음 세션에 그대로 이어집니다.

Query(질의). 본인이 위키에 대해 질문을 던집니다. LLM이 관련 페이지를 검색하고, 읽고, 인용을 포함해 답을 종합합니다. 답의 형태는 질문에 따라 달라질 수 있습니다. 마크다운 페이지, 비교 표, 슬라이드 덱(Marp), 차트(matplotlib), 캔버스. 중요한 통찰 하나: 좋은 답은 새 페이지로 위키에 다시 정리해 둘 수 있습니다. 본인이 요청한 비교, 분석, 새로 발견한 연결 — 이런 것들은 가치가 있고, 채팅 기록 속으로 사라져서는 안 됩니다. 이렇게 하면 본인의 탐색이 인제스트된 소스와 똑같이 지식 베이스 안에서 복리로 쌓입니다.

Lint(점검). 주기적으로 LLM에게 위키의 건강 검진을 시킵니다. 살펴볼 것: 페이지 간 모순, 더 새로운 소스로 대체된 낡은 주장, 들어오는 링크가 없는 고립 페이지(orphan), 본문에 등장하지만 자기 페이지가 없는 중요 개념, 빠진 상호 참조, 웹 검색으로 채울 수 있는 데이터 공백. LLM은 새로 조사할 질문과 새로 찾을 소스를 제안하는 데 능숙합니다. 이 과정이 위키가 커져도 건강을 유지하게 합니다.

인덱싱과 로깅

위키가 커질수록 LLM(과 본인)이 위키를 탐색하는 걸 돕는 두 개의 특별 파일이 있습니다. 둘은 서로 다른 목적을 가집니다.

index.md는 콘텐츠 중심입니다. 위키 안에 있는 모든 것의 카탈로그. 각 페이지가 링크와 한 줄 요약으로 나열되고, 옵션으로 날짜나 소스 개수 같은 메타데이터가 붙습니다. 카테고리(엔티티, 개념, 소스 등)별로 정리됩니다. LLM이 인제스트할 때마다 갱신합니다. 질의에 답할 때 LLM은 먼저 인덱스를 읽어 관련 페이지를 찾고, 그 다음 페이지로 파고듭니다. 중간 규모(소스 100개 안팎, 페이지 수백 개 안팎)에서는 이게 놀라울 정도로 잘 작동하고, 임베딩 기반 RAG 인프라가 필요 없습니다.

log.md는 시간순입니다. 무엇이 언제 일어났는지에 대한 append-only(한 번 쓰면 고치지 않고 항목만 덧붙이는 방식) 기록입니다. 인제스트, 질의, lint 점검을 모두 여기 남깁니다. 유용한 팁: 각 항목이 일관된 prefix(예: ## [2026-04-02] ingest | Article Title)로 시작하면, 로그를 간단한 unix 명령어(grep 같은 텍스트 검색 도구)로 파싱할 수 있습니다. grep "^## \[" log.md | tail -5 한 줄로 최근 5개 항목을 볼 수 있습니다. 로그는 위키 진화의 타임라인을 보여주고, LLM이 최근 무엇을 했는지 이해하는 데 도움이 됩니다.

옵션: CLI 도구

어느 시점에는 LLM이 위키 위에서 더 효율적으로 동작하도록 돕는 작은 도구를 만들고 싶어질 수 있습니다. 가장 명백한 후보는 위키 페이지에 대한 검색 엔진입니다. 작은 규모에서는 인덱스 파일로 충분하지만, 위키가 커지면 제대로 된 검색이 필요해집니다. qmd가 좋은 선택지입니다. 마크다운 파일을 위한 로컬 검색 엔진으로, 검색 정확도를 끌어올리는 두 가지 방식(BM25/벡터 하이브리드 검색)과 LLM 재랭킹을 전부 본인 컴퓨터 안에서(온디바이스) 직접 처리합니다. CLI(LLM이 셸에서 호출할 수 있게)와 MCP 서버(LLM이 네이티브 도구처럼 쓸 수 있게)를 둘 다 제공합니다. 더 단순한 걸 직접 만들어도 됩니다. 필요할 때 LLM과 같이 단순한 검색 스크립트를 바이브 코딩하면 됩니다.

팁과 트릭

Obsidian Web Clipper는 웹 기사를 마크다운으로 변환해 주는 브라우저 확장 프로그램입니다. 소스를 원본 모음에 빠르게 넣을 때 매우 유용합니다.
이미지를 로컬에 다운로드해 두기. Obsidian Settings → Files and links에서 “Attachment folder path”를 고정 디렉터리(예: raw/assets/)로 설정합니다. 그 다음 Settings → Hotkeys에서 “Download”를 검색해 “Download attachments for current file”을 찾아 단축키(예: Ctrl+Shift+D)에 바인딩합니다. 기사를 클리핑한 뒤 단축키를 누르면 이미지가 전부 로컬 디스크로 떨어집니다. 옵션이지만 유용합니다. LLM이 URL이 깨질 가능성을 신경 쓰지 않고 이미지를 직접 보고 참조할 수 있게 됩니다. 참고로 LLM은 인라인 이미지가 박힌 마크다운을 한 번에 읽지 못합니다. 우회법은 LLM이 먼저 텍스트를 읽게 한 뒤, 참조된 이미지의 일부 또는 전부를 별도로 보게 해서 추가 컨텍스트를 얻는 방식입니다. 좀 거추장스럽지만 충분히 잘 작동합니다.
Obsidian의 그래프 뷰는 위키의 모양을 보는 가장 좋은 방법입니다. 무엇이 무엇과 연결돼 있는지, 어느 페이지가 허브이고 어느 페이지가 고립돼 있는지.
Marp는 마크다운 기반 슬라이드 덱 포맷입니다. Obsidian 플러그인도 있습니다. 위키 콘텐츠에서 곧바로 발표 자료를 만들 때 유용합니다.
Dataview는 페이지 프런트매터에 쿼리를 돌리는 Obsidian 플러그인입니다. LLM이 위키 페이지에 파일 맨 위 메타 정보(YAML 프런트매터 — 태그, 날짜, 소스 개수 같은 정보)를 추가해 두면, Dataview로 동적 표와 리스트를 생성할 수 있습니다.
위키는 그냥 마크다운 파일의 git 저장소입니다. 버전 이력, 브랜칭, 협업을 공짜로 얻습니다.

왜 이게 작동하는가

지식 베이스 유지의 지루한 부분은 읽기나 사고가 아닙니다. 부기(bookkeeping)입니다. 상호 참조 갱신, 요약 최신화, 새 데이터가 기존 주장과 충돌할 때 표시하기, 수십 개 페이지의 일관성 유지. 사람이 위키를 포기하는 이유는 유지보수 부담이 가치보다 빠르게 커지기 때문입니다. LLM은 지루해하지 않고, 상호 참조 갱신을 잊지 않고, 한 번에 15개 파일을 건드릴 수 있습니다. 유지보수 비용이 거의 0에 가깝기 때문에 위키가 유지보수된 상태로 남는 겁니다.

사람의 역할은 소스를 큐레이션하고, 분석의 방향을 잡고, 좋은 질문을 던지고, 이 모든 게 무엇을 의미하는지 생각하는 것입니다. LLM의 역할은 그 외 전부입니다.

이 아이디어는 정신적으로 바네바 부시(Vannevar Bush)의 메멕스(Memex, 1945)와 연결됩니다. 문서 사이의 연상 경로(associative trail)를 가진, 개인적이고 큐레이션된 지식 저장소가 그것입니다. 부시의 비전은 오늘날의 웹보다 이쪽에 더 가까웠습니다. 사적이고, 능동적으로 큐레이션되며, 문서 사이의 연결 자체가 문서만큼이나 가치 있는 것이었습니다. 그가 풀지 못한 부분은 누가 유지보수를 하느냐였습니다. 그건 LLM이 처리합니다.

노트

이 문서는 의도적으로 추상적입니다. 아이디어를 설명하는 것이지, 구체적인 구현을 설명하는 게 아닙니다. 정확한 디렉터리 구조, 스키마 컨벤션, 페이지 포맷, 도구 — 전부 본인의 도메인, 선호, 선택한 LLM에 따라 달라질 겁니다. 위에서 언급한 모든 것은 옵션이고 모듈형입니다. 쓸모 있는 것만 고르고, 아닌 것은 무시하세요. 예를 들어, 본인의 소스가 텍스트뿐이라면 이미지 처리는 전혀 필요 없습니다. 위키 규모가 작다면 인덱스 파일만으로 충분하고, 검색 엔진은 필요 없습니다. 슬라이드 덱에는 관심 없고 그냥 마크다운 페이지만 원할 수도 있습니다. 완전히 다른 출력 포맷을 원할 수도 있습니다. 이 글을 쓰는 옳은 방법은 본인의 LLM 에이전트와 공유해서, 본인 필요에 맞는 버전을 같이 인스턴스화하는 것입니다. 이 문서의 유일한 일은 패턴을 전달하는 것입니다. 나머지는 본인의 LLM이 알아낼 수 있습니다.