RAG를 넘어서: 안드레이 카파시의 'LLM Wiki'로 LLM이 스스로 키우는 지식베이스 패턴 분석

들어가며: 왜 지금 "LLM Wiki"인가

LLM에게 문서를 다루게 하는 가장 흔한 방식은 RAG(Retrieval-Augmented Generation)입니다. 파일 묶음을 업로드해 두면, 질문할 때마다 LLM이 관련 조각(chunk)을 검색해서 답을 만들어 줍니다. NotebookLM, ChatGPT 파일 업로드, 그리고 대부분의 RAG 시스템이 이 구조입니다. 잘 작동하지만 한 가지 본질적인 한계가 있습니다. 매 질문마다 LLM이 지식을 처음부터 다시 발견한다는 점입니다. 축적이 없습니다.

Andrej Karpathy가 공개한 짧은 아이디어 문서 "LLM Wiki"는 바로 이 지점을 정조준합니다. 핵심 주장은 단순하면서도 강력합니다. 질의 시점에 원문을 매번 검색하는 대신, LLM이 지속적으로 유지되는 위키(persistent wiki)를 점진적으로 쌓아 올리게 하자는 것입니다. 이 글은 해당 문서의 모든 섹션을 원문 흐름 그대로 따라가며 꼼꼼히 분석하고, 마지막에 한글로 전체 패턴을 정리합니다.

이 문서의 성격을 먼저 짚어 둘 필요가 있습니다. 원문은 스스로를 "아이디어 파일(idea file)"로 규정합니다. 즉, 그대로 가져다 자신의 LLM 에이전트(OpenAI Codex, Claude Code, OpenCode/Pi 등)에 붙여 넣어 쓰라고 의도된 문서입니다. 구체적인 구현이 아니라 고수준의 발상을 전달하는 것이 목적이며, 세부 사항은 사용자와 에이전트가 협업하며 채워 나가도록 설계되어 있습니다. 그래서 문서 전체가 의도적으로 추상적입니다.

배경: RAG의 "재발견" 문제와 Memex의 계보

RAG의 한계를 조금 더 분해해 보겠습니다. 다섯 개의 문서를 종합해야 답할 수 있는 미묘한 질문을 던졌다고 합시다. RAG 시스템은 매번 관련 조각을 찾아 와 그 자리에서 짜 맞춥니다. 한 번 종합한 결과가 어디에도 남지 않으므로, 같은 종류의 질문이 다시 와도 LLM은 같은 수고를 처음부터 반복합니다. 원문은 이를 "쌓이는 것이 없다(Nothing is built up)"는 한 문장으로 요약합니다.

LLM Wiki의 발상은 사실 새로운 것이 아니라 오래된 비전의 부활에 가깝습니다. 원문은 이 아이디어가 Vannevar Bush가 1945년에 제시한 Memex와 정신적으로 맞닿아 있다고 밝힙니다. Memex는 문서들 사이에 연상적 연결(associative trail)을 갖춘, 개인이 직접 큐레이션하는 지식 저장소였습니다. 이는 오늘날의 웹보다 오히려 LLM Wiki에 더 가까운 구상이었습니다. 사적이고, 능동적으로 큐레이션되며, 문서들 사이의 연결이 문서 자체만큼이나 가치 있는 형태였기 때문입니다. 다만 Bush가 풀지 못한 문제가 하나 있었는데, 그 연결과 유지보수를 누가 하느냐였습니다. 이 글의 결론부에서 다시 다루겠지만, 바로 그 빈자리를 LLM이 메운다는 것이 이 패턴의 핵심 통찰입니다.

핵심 아이디어: 위키는 "축적되는 산출물"이다

원문에서 가장 중요한 단락입니다. 새 소스를 추가할 때 LLM이 하는 일이 RAG와 어떻게 다른지를 보면 차이가 분명해집니다. RAG는 나중에 검색하려고 소스를 색인(index)할 뿐입니다. 반면 LLM Wiki에서 LLM은 소스를 읽고, 핵심 정보를 추출해, 기존 위키에 통합합니다. 엔티티 페이지를 갱신하고, 주제 요약을 수정하며, 새 데이터가 기존 주장과 충돌하는 지점을 표시하고, 진화하는 종합(synthesis)을 강화하거나 반박합니다. 지식은 한 번 컴파일된 뒤 계속 최신 상태로 유지되는 것이지, 질문할 때마다 다시 도출되는 것이 아닙니다.

원문은 이 차이를 한 문장으로 못 박습니다.

the wiki is a persistent, compounding artifact.

여기서 "compounding"이라는 단어가 핵심입니다. 위키가 복리처럼 불어나는 산출물이라는 뜻입니다. 교차 참조(cross-reference)는 이미 만들어져 있고, 모순은 이미 표시되어 있으며, 종합은 지금까지 읽은 모든 것을 이미 반영하고 있습니다. 소스를 추가할 때마다, 질문을 던질 때마다 위키는 더 풍부해집니다. 질의 시점에 모든 것을 재구성하는 RAG와 달리, LLM Wiki는 그 비용을 한 번만 치르고 결과를 자산으로 남깁니다.

역할 분담도 명확합니다. 위키는 사람이 거의 쓰지 않습니다. LLM이 쓰고 유지합니다. 사람은 소싱(sourcing), 탐색(exploration), 좋은 질문 던지기를 담당하고, 요약·교차 참조·정리·장부 정리 같은 궂은일(grunt work)은 전부 LLM이 맡습니다. Karpathy는 자신의 실제 작업 방식을 인상적인 비유로 설명합니다. 한쪽에는 LLM 에이전트를, 다른 쪽에는 Obsidian을 띄워 두고, LLM이 대화를 바탕으로 편집하면 자신은 실시간으로 링크를 따라가고 그래프 뷰를 확인하며 갱신된 페이지를 읽습니다.

Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.

이 비유는 단순한 수사가 아니라 작업 모델 전체를 압축합니다. 위키를 "코드베이스"로 본다는 것은, 위키가 일회성 출력이 아니라 지속적으로 리팩터링·유지보수되는 살아 있는 자산임을 뜻합니다. Obsidian은 그것을 들여다보고 탐색하는 편집 환경(IDE)이고, LLM은 그 안에서 실제로 코드를 쓰는 프로그래머이며, 사람은 방향을 정하는 역할을 맡습니다.

원문은 이 패턴이 적용될 수 있는 맥락을 여러 예시로 제시합니다. 단순 나열을 넘어 각 맥락이 왜 이 패턴과 잘 맞는지 함께 보겠습니다.

• 개인(Personal): 목표·건강·심리·자기계발을 추적하는 용도입니다. 일기, 아티클, 팟캐스트 노트를 정리해 시간에 따라 자신에 대한 구조화된 그림을 쌓아 갑니다.
• 연구(Research): 한 주제를 수 주에서 수 개월에 걸쳐 깊게 파고드는 경우입니다. 논문·아티클·리포트를 읽으며 진화하는 논지(thesis)를 갖춘 포괄적 위키를 점진적으로 구축합니다.
• 책 읽기: 챕터를 읽을 때마다 정리하면서 인물·주제·플롯 갈래와 그 연결 관계를 페이지로 만들어 갑니다. 원문은 Tolkien Gateway 같은 팬 위키를 예로 듭니다. 자원봉사자 공동체가 수년에 걸쳐 수천 개의 상호 연결된 페이지를 쌓아 올린 그런 위키를, 책을 읽으며 개인적으로 만들 수 있다는 것입니다. 교차 참조와 유지보수는 LLM이 합니다.
• 비즈니스/팀: Slack 스레드, 회의록, 프로젝트 문서, 고객 통화로 채워지는 내부 위키를 LLM이 유지합니다. 사람이 갱신을 검토하는 형태(human in the loop)도 가능합니다. 팀의 누구도 하기 싫어하는 유지보수를 LLM이 대신하므로 위키가 최신 상태를 유지합니다.
• 그 밖에 경쟁 분석, 실사(due diligence), 여행 계획, 강의 노트, 취미 심화 학습 등 시간에 걸쳐 지식을 축적하며 흩어지지 않게 정리하고 싶은 모든 영역에 적용됩니다.

아키텍처: 세 개의 계층

원문은 시스템을 세 계층으로 나눕니다. 이 구분이 LLM Wiki를 "디시플린 있는 위키 관리자"로 만드는 골격입니다.

첫째, 원천 소스(Raw sources)입니다. 사용자가 큐레이션한 소스 문서 모음으로, 아티클·논문·이미지·데이터 파일 등이 여기 속합니다. 중요한 성질은 불변(immutable)이라는 점입니다. LLM은 여기서 읽기만 할 뿐 절대 수정하지 않습니다. 이것이 진실 소스(source of truth)입니다.

둘째, 위키(The wiki)입니다. LLM이 생성한 마크다운 파일들의 디렉터리로, 요약·엔티티 페이지·개념 페이지·비교·개요·종합이 들어갑니다. 이 계층은 전적으로 LLM이 소유합니다. 페이지를 만들고, 새 소스가 들어오면 갱신하며, 교차 참조를 유지하고 전체 일관성을 지킵니다. 사람은 읽고, LLM은 씁니다.

셋째, 스키마(The schema)입니다. Claude Code의 CLAUDE.md나 Codex의 AGENTS.md 같은 문서로, 위키가 어떻게 구조화되어 있는지, 규약이 무엇인지, 소스를 수집하거나 질문에 답하거나 위키를 유지보수할 때 어떤 워크플로를 따라야 하는지를 LLM에게 알려 줍니다. 원문은 이 파일을 가장 중요한 설정 파일로 봅니다.

스키마의 역할을 원문은 이렇게 설명합니다.

it's what makes the LLM a disciplined wiki maintainer rather than a generic chatbot.

즉, 스키마가 있어야 LLM이 범용 챗봇이 아니라 규율 있는 위키 관리자가 됩니다. 같은 LLM이라도 스키마가 없으면 매번 즉흥적으로 행동하지만, 스키마가 있으면 일관된 규약과 워크플로를 따릅니다. 그리고 이 스키마는 고정된 것이 아니라, 사용자와 LLM이 도메인에 무엇이 잘 맞는지 알아 가며 함께 진화시키는(co-evolve) 문서입니다.

운영(Operations): Ingest, Query, Lint

위키를 실제로 굴리는 세 가지 작업이 정의됩니다.

Ingest(수집)

새 소스를 원천 모음에 넣고 LLM에게 처리하라고 지시하는 흐름입니다. 원문이 제시하는 예시 흐름은 다음과 같습니다. LLM이 소스를 읽고, 사용자와 핵심 takeaway를 논의한 뒤, 위키에 요약 페이지를 쓰고, 인덱스를 갱신하며, 위키 전반의 관련 엔티티·개념 페이지를 갱신하고, 로그에 항목을 추가합니다. 원문은 하나의 소스가 10~15개의 위키 페이지를 건드릴 수 있다고 말합니다. 이 수치가 패턴의 성격을 잘 드러냅니다. 단순 색인이 아니라 위키 전체에 파급되는 통합 작업이라는 뜻입니다.

수집 방식에는 선택지가 있습니다. Karpathy 본인은 소스를 하나씩 수집하며 깊이 관여하는 방식을 선호합니다. 요약을 읽고, 갱신 내용을 확인하며, 무엇을 강조할지 LLM을 안내합니다. 하지만 감독을 줄이고 여러 소스를 한꺼번에 일괄 수집(batch-ingest)할 수도 있습니다. 원문은 어느 한쪽을 강제하지 않고, 자신의 스타일에 맞는 워크플로를 개발해 스키마에 문서화해 두라고 권합니다. 그래야 다음 세션에서도 같은 방식이 재현됩니다.

Query(질의)

위키에 대해 질문을 던지는 작업입니다. LLM은 관련 페이지를 검색해 읽고, 인용과 함께 답을 종합합니다. 답의 형식은 질문에 따라 마크다운 페이지, 비교 표, 슬라이드 덱(Marp), 차트(matplotlib), 캔버스 등 다양할 수 있습니다.

여기서 원문은 가장 중요한 통찰 하나를 강조합니다.

good answers can be filed back into the wiki as new pages.

좋은 답은 새 페이지로 위키에 다시 편입될 수 있다는 것입니다. 사용자가 요청한 비교, 분석, 발견한 연결 관계는 그 자체로 가치가 있으므로 채팅 기록 속으로 사라지게 두어서는 안 됩니다. 이렇게 하면 탐색(질의)의 결과도 수집된 소스와 똑같이 지식베이스 안에서 복리로 불어납니다. Query가 단순히 위키를 소비하는 행위가 아니라, Ingest와 마찬가지로 위키를 키우는 행위가 되는 것입니다. 이는 앞서 "compounding artifact"라고 한 성질이 질의 측면에서도 작동함을 보여 줍니다.

Lint(점검)

코드 린팅에서 이름을 빌려 온 작업입니다. 주기적으로 LLM에게 위키의 건강 상태를 점검하게 합니다. 원문이 점검 대상으로 드는 항목은 다음과 같습니다.

• 페이지 간 모순(contradictions)
• 최신 소스가 대체해 버린 낡은 주장(stale claims)
• 들어오는 링크가 없는 고아 페이지(orphan pages)
• 언급은 되었으나 자기 페이지가 없는 중요한 개념
• 누락된 교차 참조
• 웹 검색으로 메울 수 있는 데이터 공백(data gaps)

원문은 LLM이 조사할 새로운 질문과 찾아볼 새로운 소스를 제안하는 데 능하다고 덧붙입니다. Lint는 위키가 커질수록 건강을 유지하게 해 주는 장치입니다. Ingest가 위키를 키우고 Query가 위키를 활용한다면, Lint는 위키를 정비합니다.

인덱싱과 로깅: index.md와 log.md

위키가 커질 때 LLM(과 사람)이 길을 잃지 않도록 돕는 두 개의 특별한 파일이 있습니다. 둘은 목적이 다릅니다. 이 둘의 차이는 다차원적이므로 표로 정리하는 편이 명확합니다.

index.md에 대해 원문은 주목할 만한 주장을 합니다. 이 방식이 중간 규모(소스 약 100개, 페이지 수백 개)에서 놀랍도록 잘 작동하며, 임베딩 기반 RAG 인프라가 필요 없다는 것입니다. 질의가 들어오면 LLM이 인덱스를 먼저 읽어 관련 페이지를 추린 뒤 해당 페이지로 파고듭니다. 벡터 데이터베이스와 청킹 파이프라인을 구축하는 대신, 잘 관리된 목차 파일 하나로 검색 문제를 상당 부분 해결할 수 있다는 실용적 통찰입니다.

log.md에 대해서는 유용한 팁이 하나 제시됩니다. 각 항목을 일관된 접두사로 시작하게 하면 로그가 단순한 유닉스 도구로 파싱 가능해진다는 것입니다. 예를 들어 항목을 ## [2026-04-02] ingest | Article Title 형식으로 적으면, 다음 한 줄로 최근 5개 항목을 뽑을 수 있습니다.

grep "^## \[" log.md | tail -5

이 명령은 log.md에서 ## [로 시작하는 줄(즉 각 로그 항목의 헤더)만 골라낸 뒤, 마지막 5줄을 출력합니다. 핵심은 데이터 포맷을 일관되게 유지하면 별도 도구 없이도 기계가 읽을 수 있는 기록이 된다는 점입니다. 로그는 위키가 어떻게 진화해 왔는지에 대한 타임라인을 제공하고, LLM이 최근에 무엇을 했는지 이해하도록 돕습니다.

선택 사항: CLI 도구

위키가 어느 규모를 넘어서면, LLM이 위키를 더 효율적으로 다루도록 돕는 작은 도구를 만들고 싶어질 수 있습니다. 가장 분명한 것은 위키 페이지에 대한 검색 엔진입니다. 소규모에서는 인덱스 파일로 충분하지만, 위키가 커지면 제대로 된 검색이 필요해집니다.

원문은 qmd를 좋은 선택지로 듭니다. 마크다운 파일을 위한 로컬 검색 엔진으로, BM25/벡터 하이브리드 검색과 LLM 재순위(re-ranking)를 모두 온디바이스(on-device)에서 수행합니다. CLI를 제공하므로 LLM이 셸로 호출할 수 있고, MCP 서버도 제공하므로 LLM이 네이티브 도구처럼 사용할 수도 있습니다. 물론 더 단순한 것을 직접 만들 수도 있습니다. 필요가 생기면 LLM의 도움을 받아 소박한 검색 스크립트를 즉석에서 만들어 쓰면 됩니다. 이 섹션 전체가 "선택 사항"으로 분류된다는 점이 중요합니다. 인덱스 파일만으로 충분하다면 검색 엔진은 없어도 됩니다.

팁과 트릭

원문은 실제 운용에 도움이 되는 도구와 습관을 모아 둡니다. 대부분 Obsidian 생태계와 관련됩니다.

• Obsidian Web Clipper: 웹 아티클을 마크다운으로 변환하는 브라우저 확장입니다. 소스를 원천 모음에 빠르게 넣을 때 유용합니다.
• 이미지 로컬 다운로드: Obsidian 설정에서 첨부 폴더 경로(예: raw/assets/)를 고정하고, "Download attachments for current file"을 단축키(예: Ctrl+Shift+D)에 바인딩해 둡니다. 아티클을 클리핑한 뒤 단축키를 누르면 이미지가 로컬 디스크로 내려받아집니다. URL이 깨질 위험 없이 LLM이 이미지를 직접 참조할 수 있게 해 줍니다. 다만 원문은 한 가지 한계를 명시합니다. LLM은 인라인 이미지가 포함된 마크다운을 한 번에 네이티브로 읽지 못하므로, 텍스트를 먼저 읽은 뒤 참조된 이미지를 따로 열어 보는 우회가 필요합니다. 다소 번거롭지만 충분히 쓸 만하다고 평가합니다.
• 그래프 뷰(graph view): 위키의 형태를 보는 가장 좋은 방법입니다. 무엇이 무엇과 연결되어 있는지, 어떤 페이지가 허브인지, 어떤 페이지가 고아인지를 한눈에 보여 줍니다. 앞서 Lint에서 다룬 "고아 페이지" 점검과 직접 맞닿는 도구입니다.
• Marp: 마크다운 기반 슬라이드 덱 포맷으로, Obsidian 플러그인이 있습니다. 위키 콘텐츠에서 바로 발표 자료를 생성할 때 유용합니다.
• Dataview: 페이지 프런트매터(frontmatter)에 대해 질의를 실행하는 Obsidian 플러그인입니다. LLM이 위키 페이지에 YAML 프런트매터(태그, 날짜, 소스 수)를 추가하면, Dataview가 동적 표와 목록을 생성해 줍니다.
• 위키는 그냥 git 저장소: 위키는 마크다운 파일들의 git 저장소일 뿐입니다. 따라서 버전 관리, 브랜칭, 협업을 공짜로 얻습니다.

마지막 항목은 특히 음미할 만합니다. 앞서 "위키는 코드베이스"라는 비유가 단순한 수사가 아님을 여기서 확인할 수 있습니다. 위키가 정말로 git 저장소이므로, 소프트웨어 개발에서 쓰던 도구와 습관이 그대로 지식 관리에 적용됩니다.

왜 작동하는가

원문의 결론부는 이 패턴이 작동하는 이유를 정확히 짚습니다. 지식베이스 유지의 고된 부분은 읽기나 사고가 아니라 장부 정리(bookkeeping)입니다. 교차 참조를 갱신하고, 요약을 최신으로 유지하며, 새 데이터가 옛 주장과 충돌할 때 이를 표시하고, 수십 개 페이지에 걸쳐 일관성을 지키는 일입니다. 사람이 위키를 포기하는 이유는 명확합니다. 유지보수 부담이 가치보다 빨리 커지기 때문입니다.

그런데 LLM은 이 약점이 없습니다. 지루해하지 않고, 교차 참조 갱신을 잊지 않으며, 한 번에 15개 파일을 건드릴 수 있습니다. 원문의 표현을 빌리면, 위키가 유지되는 이유는 유지보수 비용이 거의 0에 가깝기 때문입니다. 사람이 위키를 포기하게 만들던 바로 그 비용 구조가 LLM에 의해 무너지는 것입니다.

그래서 역할 분담은 다음과 같이 정리됩니다. 사람의 일은 소스를 큐레이션하고, 분석의 방향을 정하고, 좋은 질문을 던지고, 그것이 무엇을 의미하는지 생각하는 것입니다. 나머지 전부는 LLM의 일입니다.

이 대목에서 앞서 배경으로 다룬 Memex가 다시 등장합니다. Vannevar Bush가 1945년에 그린 비전은 사적이고 능동적으로 큐레이션되며 문서 간 연결이 문서만큼 가치 있는 지식 저장소였습니다. 그가 풀지 못한 단 하나의 문제가 "누가 유지보수를 하는가"였는데, LLM Wiki는 바로 그 자리를 LLM으로 채웁니다. 80년 묵은 구상이 이제야 실현 가능해진 셈입니다.

한 가지 단서: 이것은 구현이 아니라 패턴이다

원문은 마지막 "Note" 섹션에서 자신의 성격을 다시 한번 분명히 합니다. 이 문서는 의도적으로 추상적이며, 아이디어를 설명할 뿐 특정 구현을 규정하지 않습니다. 정확한 디렉터리 구조, 스키마 규약, 페이지 포맷, 도구 선택은 모두 사용자의 도메인·취향·LLM 선택에 따라 달라집니다.

특히 위에서 언급한 모든 것이 선택적이고 모듈식(optional and modular)이라는 점을 강조합니다. 유용한 것은 취하고 그렇지 않은 것은 무시하면 됩니다. 원문이 드는 예시들은 이렇습니다. 소스가 텍스트뿐이라면 이미지 처리는 아예 필요 없습니다. 위키가 충분히 작다면 인덱스 파일만으로 족하고 검색 엔진은 필요 없습니다. 슬라이드 덱이 필요 없고 마크다운 페이지만 원할 수도 있습니다. 전혀 다른 출력 형식 집합을 원할 수도 있습니다.

올바른 사용법은 이 문서를 자신의 LLM 에이전트와 공유하고, 함께 협업하여 자신의 필요에 맞는 버전을 인스턴스화하는 것입니다. 문서의 유일한 임무는 패턴을 전달하는 것이며, 나머지는 LLM이 알아서 한다는 것이 원문이 스스로 내리는 결론입니다.

한글 정리: LLM Wiki 패턴 한눈에 보기

지금까지의 분석을 한국어로 압축해 정리합니다.

한 문장 요약. 질의 시점에 원문을 매번 검색하는 RAG 대신, LLM이 마크다운 위키를 지속적으로 쌓고 유지하게 하여 지식을 복리처럼 축적하는 개인 지식베이스 패턴입니다.

RAG와의 핵심 차이. 두 접근의 대비가 이 패턴의 정체성이므로 표로 정리합니다.

세 계층. 원천 소스(불변, 진실 소스) / 위키(LLM이 소유·생성) / 스키마(CLAUDE.md·AGENTS.md, LLM을 규율 있는 관리자로 만드는 설정).

세 작업. Ingest(소스를 읽어 10~15개 페이지에 통합) / Query(인용과 함께 답하고, 좋은 답은 새 페이지로 재편입) / Lint(모순·낡은 주장·고아 페이지·누락 참조·데이터 공백 점검).

두 내비게이션 파일. index.md(내용 카탈로그, 매 수집 시 갱신) / log.md(시간순 추가 전용 기록, 일관 접두사로 grep 가능).

작동하는 이유. 지식베이스의 진짜 부담은 사고가 아니라 장부 정리이며, LLM은 그 유지보수 비용을 거의 0으로 낮춘다. 사람은 큐레이션·방향·질문·의미 부여를, LLM은 나머지 전부를 맡는다. 이는 Vannevar Bush의 Memex(1945)가 풀지 못한 "누가 유지보수하는가"라는 질문에 대한 답이기도 하다.

실전 적용 메모. 모든 구성 요소는 선택적·모듈식입니다. 작게 시작하려면 (1) 원천 소스 폴더 하나, (2) LLM이 쓸 위키 폴더 하나, (3) 규약을 적은 스키마 파일 하나, (4) index.md와 log.md만으로 충분합니다. 검색 엔진(qmd), 이미지 처리, Marp 슬라이드, Dataview 표는 필요해질 때 더하면 됩니다. 핵심은 스키마에 자신의 워크플로를 문서화해 다음 세션에서도 재현되게 하는 것입니다.

이 글에서 다루지 못한 세부 주제

원문의 모든 섹션을 본문에 반영했습니다. 다만 다음 항목은 원문이 외부 도구·자료로 링크만 제공하고 상세 설명은 생략한 부분이므로, 이 글에서도 깊이 다루지 않았습니다. 필요하면 원문의 해당 링크를 직접 참고하시기 바랍니다.

• "Optional: CLI tools" 섹션의 qmd 내부 구현(BM25/벡터 하이브리드, LLM 재순위)의 상세 동작 원리
• "Tips and tricks" 섹션에서 언급된 Obsidian 플러그인(Web Clipper, Marp, Dataview)의 구체적 설치·설정 절차
• "The core idea"의 예시로 링크된 Tolkien Gateway 팬 위키의 구체적 구조