도구는 위키를 대체하지 않는다
LLM Wiki의 핵심은 도구가 아니다. 핵심은 raw/, wiki/, logs/, index.md, CLAUDE.md 또는 AGENTS.md로 이루어진 운영 구조다. 이 구조가 먼저 안정되어야 한다. 도구는 그다음에 붙인다.
좋은 확장은 위키의 기본 원칙을 흐트러뜨리지 않는다. 원문은 수정하지 않고, 위키는 해석과 정리의 공간으로 두며, 모든 중요한 변경은 로그와 인덱스에 남긴다. 이 원칙 위에 수집 도구, 검색 도구, 시각화 도구, 출력 도구, 자동화 도구를 하나씩 붙이면 된다.
도구를 많이 붙인다고 좋은 위키가 되는 것은 아니다. 반대로 도구가 하나도 없으면 운영 비용이 커진다. 기준은 단순하다.
자료 수집이 번거로우면 클리퍼를 붙인다.
위키가 커져 찾기 어려우면 검색 도구를 붙인다.
연결 상태가 보이지 않으면 그래프와 Dataview를 쓴다.
보고서와 발표 자료를 자주 만들면 출력 도구를 붙인다.
반복 작업이 많아지면 MCP와 에이전트 기능으로 자동화한다.
확장은 "필요해졌을 때" 붙이는 편이 좋다. 처음부터 거대한 시스템을 만들려고 하면, 지식 관리가 아니라 도구 관리가 일이 된다.
Web Clipper: 웹을 raw로 들여오는 입구
가장 먼저 붙일 만한 도구는 Obsidian Web Clipper다. 웹 문서를 마크다운으로 저장해주는 브라우저 확장이다. LLM Wiki에서는 웹 클리퍼의 목적이 명확하다. 읽은 글을 예쁘게 보관하는 것이 아니라, 나중에 AI가 읽을 수 있는 원문 자료로 남기는 것이다.
권장 흐름은 이렇다.
웹 문서를 발견한다.
Obsidian Web Clipper로
raw/articles/또는inbox/에 저장한다.이미지가 중요한 문서라면 첨부파일을 로컬
assets/폴더로 내려받는다.AI 에이전트에게 ingest를 요청한다.
생성된 source-summary, concept, entity 페이지를 확인한다.
여기서 중요한 점은 클리핑한 문서를 곧바로 wiki/에 넣지 않는 것이다. 클리핑 문서는 원문에 가깝다. 따라서 raw/ 또는 inbox/에 들어가야 한다. wiki/는 AI가 원문을 읽고 정리한 결과가 들어가는 공간이다.
웹 문서에는 원격 이미지가 포함되는 경우가 많다. 시간이 지나면 이미지 URL이 깨지거나 접근이 막힐 수 있다. 그래서 중요한 도표, 제품 화면, 아키텍처 그림이 있는 글은 이미지를 로컬에 저장해두는 편이 안전하다. Obsidian에서는 첨부파일 폴더를 assets/로 지정하고, 현재 문서의 원격 첨부파일을 내려받는 단축키를 설정할 수 있다.1
이 작은 습관은 나중에 큰 차이를 만든다. 텍스트만 남은 문서는 절반의 자료가 될 수 있다. 특히 리서치, 제품 분석, 기술 문서에서는 이미지가 핵심 근거인 경우가 많다.
Dataview: 위키의 상태를 표로 보기
위키가 20페이지를 넘기면 감으로 관리하기 어려워진다. 어떤 페이지가 오래되었는지, 어떤 페이지의 신뢰도가 낮은지, 어떤 소스가 아직 처리되지 않았는지 한눈에 보고 싶어진다. 이때 Dataview가 유용하다.
Dataview는 Obsidian 안에서 마크다운 파일의 frontmatter를 쿼리해 표로 보여주는 플러그인이다. 쉽게 말해, 위키 파일들을 작은 데이터베이스처럼 다루게 해준다. 전제는 하나다. AI가 페이지마다 메타데이터를 꾸준히 써야 한다.
예를 들어 concept 페이지에 다음과 같은 frontmatter를 넣는다고 하자.
type: concept
confidence: low
source_count: 1
date_updated: 2026-05-19
tags: [wiki/concept]그러면 dashboard.md에 이런 Dataview 표를 만들 수 있다.
TABLE confidence, source_count, date_updated
FROM "wiki/concepts"
WHERE confidence = "low" OR source_count < 2
SORT date_updated ASC이 표는 "근거가 약한 개념 페이지"를 보여준다. Lint 장에서 다룬 출처 없는 주장, 낮은 신뢰도, 오래된 주장 찾기를 사람이 직접 뒤지지 않고 대시보드로 볼 수 있다.
또 다른 예시는 오래된 페이지 찾기다.
TABLE date_updated, source_count
FROM "wiki"
WHERE date_updated < date(today) - dur(90 days)
SORT date_updated ASC이 표는 90일 이상 갱신되지 않은 페이지를 보여준다. 모든 오래된 페이지가 문제는 아니다. 하지만 빠르게 변하는 주제라면 오래된 페이지는 점검 후보가 된다.
Dataview는 위키를 자동으로 고치지는 않는다. 대신 어디를 봐야 하는지 알려준다. 즉, Lint의 결과를 일상적으로 볼 수 있게 해주는 운영 대시보드다.
Graph View: 연결 중심 개념 찾기
Graph View는 위키를 노드와 링크의 형태로 보여준다. 각 페이지는 점이 되고, [[wikilink]]는 선이 된다. LLM Wiki에서는 이 기능이 단순히 보기 좋은 시각화가 아니다. 위키의 건강 상태를 보는 도구다.
그래프에서 먼저 볼 것은 세 가지다.
첫째, 허브 페이지다. 많은 페이지와 연결된 개념은 지식의 중심일 가능성이 높다. 예를 들어 스타트업 위키라면 고객 인터뷰, 가격 정책, 온보딩, 경쟁사 분석 같은 페이지가 허브가 될 수 있다. 허브 페이지는 잘 관리해야 한다. 허브가 부정확하면 연결된 페이지 전체가 흔들린다.
둘째, 고아 페이지다. 어디에서도 링크되지 않는 페이지는 두 가지 중 하나다. 아직 연결되지 않은 중요한 지식이거나, 만들었지만 쓸모가 없어진 페이지다. 고아 페이지는 삭제 대상이 아니라 검토 대상이다. AI에게 이렇게 요청할 수 있다.
Graph View에서 고립된 페이지 목록을 기준으로, 연결해야 할 후보 페이지와 삭제 또는 병합 후보를 제안해줘.
셋째, 클러스터다. 특정 주제 주변에 페이지들이 뭉쳐 있다면, 그 자체가 하나의 연구 영역이나 프로젝트 영역이 된다. 클러스터는 나중에 보고서, 강의안, 책의 장으로 전환하기 쉽다.
Graph View를 잘 쓰려면 AI에게 위키링크를 아끼지 말라고 지시해야 한다. 다만 모든 단어에 링크를 거는 것은 좋지 않다. 링크는 "다시 방문할 가치가 있는 개념"에 걸어야 한다. 그래프가 복잡해지는 것보다 더 나쁜 것은 의미 없는 링크가 많아지는 것이다.
Marp와 Markdown 출력: 위키를 결과물로 바꾸기
LLM Wiki의 가치는 저장에만 있지 않다. 축적한 지식을 다시 꺼내 쓸 수 있어야 한다. 이때 Markdown 출력 도구가 중요해진다.
가장 실용적인 도구 중 하나가 Marp다. Marp는 마크다운으로 슬라이드를 만드는 도구다. 위키의 개념 페이지, 비교 페이지, synthesis 페이지를 바탕으로 발표 자료를 빠르게 만들 수 있다. Karpathy의 LLM Wiki 설명에서도 질의 결과를 마크다운 페이지뿐 아니라 슬라이드나 차트 같은 출력물로 전환할 수 있다고 언급된다.2
예를 들어 wiki/synthesis/rag-vs-llm-wiki.md가 있다면, AI에게 이렇게 요청한다.
이 synthesis 페이지를 15분 발표용 Marp 슬라이드로 바꿔줘. 청중은 비개발자 기획자이고, 기술 용어는 간단히 설명해줘. 각 슬라이드는 한 메시지만 담아줘.
그러면 outputs/slides/rag-vs-llm-wiki.md 같은 파일을 만들 수 있다. 보고서도 같은 방식이다.
wiki/concepts/의 고객 피드백 관련 페이지와wiki/decisions/의 최근 의사결정 기록을 바탕으로, 2페이지짜리 월간 제품 리포트를 작성해줘.
여기서 중요한 규칙은 출력물을 wiki/와 분리하는 것이다. 발표 자료, 보고서, 제안서, 블로그 초안은 대개 특정 시점의 산출물이다. 계속 갱신되는 지식층과 성격이 다르다. 그래서 outputs/ 또는 deliverables/ 폴더에 두는 것이 좋다.
위키는 살아 있는 지식이고, 출력물은 그 지식의 스냅샷이다.
로컬 검색: index만으로 부족해질 때
초기에는 index.md만으로 충분하다. AI가 index를 읽고 관련 페이지를 찾아 답할 수 있다. 하지만 위키가 수백 페이지를 넘고, 원문까지 많아지면 단순 인덱스만으로는 부족해진다.
이때 로컬 검색 도구를 붙인다. 가장 단순한 방법은 grep, ripgrep 같은 명령어다.
rg "고객 인터뷰" wiki raw
rg "confidence: low" wiki
rg "TODO|검토 필요|모순" wiki조금 더 나아가면 마크다운 전용 검색 도구를 쓸 수 있다. 예를 들어 qmd는 마크다운 파일을 대상으로 키워드 검색, 벡터 검색, 하이브리드 검색을 제공하고, MCP 서버로도 연결할 수 있는 로컬 검색 도구로 소개된다.3
검색 도구를 붙일 때의 핵심은 "원문 검색 + 위키 검색"을 구분하는 것이다.
wiki/검색: 이미 정리된 지식에서 답을 찾는다.raw/검색: 근거 원문을 확인한다.logs/검색: 언제 어떤 작업이 있었는지 추적한다.
AI에게도 이 구분을 알려줘야 한다.
먼저
wiki/index.md와 관련 위키 페이지를 읽고 답하라. 답변의 근거가 약하거나 원문 확인이 필요하면 그때raw/를 검색하라. 원문에서 확인한 내용은 출처와 함께 표시하라.
이 규칙이 없으면 AI는 매번 raw를 뒤지거나, 반대로 위키만 보고 확신할 수 없는 답을 할 수 있다.
MCP: 에이전트에게 도구 손을 달아주기
MCP(Model Context Protocol)는 AI 에이전트가 외부 도구와 연결되는 표준 방식이다. 쉽게 말해, AI가 파일 시스템, 검색 도구, Obsidian, Slack, 데이터베이스 같은 도구를 안전한 인터페이스로 호출하게 해주는 연결 방식이다.
LLM Wiki에서 MCP가 유용한 이유는 명확하다. AI가 단순히 대화만 하는 것이 아니라, 실제 위키 파일을 읽고, 검색하고, 만들고, 수정하고, 현재 열린 Obsidian 문서를 확인할 수 있기 때문이다.
예를 들어 Obsidian MCP 플러그인을 쓰면 Claude Code 같은 에이전트가 vault 파일 목록을 보고, 특정 파일을 읽고, 새 파일을 만들고, 현재 열린 파일을 가져오는 작업을 할 수 있다. 관련 플러그인들은 Obsidian vault를 MCP 서버처럼 노출해 Claude Code나 Claude Desktop 같은 클라이언트가 접근하도록 만든다.4
가능한 흐름은 이렇다.
사용자가 Obsidian에서 회의록을 연다.
Claude Code가 MCP로 현재 열린 파일을 읽는다.
회의록을
raw/meetings/로 분류한다.관련 프로젝트 페이지와 의사결정 기록을 갱신한다.
index.md와log.md를 업데이트한다.변경 내용을 사용자에게 요약해 검토를 요청한다.
이 구조의 장점은 사용자가 파일 경로를 매번 설명하지 않아도 된다는 것이다. AI가 현재 작업 맥락을 도구를 통해 가져올 수 있다.
다만 MCP는 강력한 만큼 권한 관리가 중요하다. vault 전체에 읽기·쓰기 권한을 주는 도구라면, 민감 정보가 있는 폴더는 분리하거나 제외해야 한다. 팀 위키에서는 더 조심해야 한다. AI가 직접 수정할 수 있는 영역과 제안만 할 수 있는 영역을 구분해야 한다.
Agent Skills: 반복 워크플로를 명령으로 만들기
도구가 많아질수록 사용자는 다시 피곤해질 수 있다. 그래서 반복되는 작업은 Agent Skills 또는 커스텀 명령으로 묶는 것이 좋다.
예를 들어 다음 네 가지 명령을 만들 수 있다.
/ingest-web
- inbox의 새 웹 클리핑을 읽는다.
- source-summary를 만든다.
- 관련 concept/entity 페이지를 갱신한다.
- index와 log를 업데이트한다.
/query-save
- 질문에 답한다.
- 답변이 재사용 가치가 있으면 wiki/synthesis/에 저장한다.
- index와 log를 업데이트한다.
/lint-weekly
- 고아 페이지, 낮은 신뢰도 페이지, 오래된 페이지를 찾는다.
- 병합 후보와 보강 후보를 제안한다.
- outputs/lint-YYYY-MM-DD.md에 보고서를 남긴다.
/export-slides
- 지정한 synthesis 페이지를 Marp 슬라이드로 바꾼다.
- outputs/slides/에 저장한다.이런 명령은 특별한 기술이 아니라 운영 규칙의 포장이다. 이미 앞 장들에서 만든 ingest, query, lint 규칙을 반복 실행 가능한 형태로 만든 것이다.
Agent Skills를 설계할 때는 한 가지 원칙을 지켜야 한다. 자동화는 "검토 가능한 단위"로 멈춰야 한다. 특히 ingest와 lint는 여러 파일을 바꿀 수 있으므로, 변경 전후 요약과 수정 파일 목록을 반드시 보여줘야 한다.
좋은 자동화는 사람을 배제하지 않는다. 사람이 판단해야 할 지점에서 멈춘다.
확장 순서: 작은 위키에서 팀 위키까지
처음부터 모든 도구를 붙일 필요는 없다. 다음 순서면 충분하다.
1단계는 기본 위키다. raw/, wiki/, index.md, log.md, CLAUDE.md만 둔다. 수동으로 ingest하고 결과를 확인한다.
2단계는 수집 확장이다. Web Clipper와 inbox/를 붙인다. 웹 자료, PDF, 회의록이 자연스럽게 들어오게 만든다.
3단계는 관찰 확장이다. Dataview와 Graph View로 위키 상태를 본다. 낮은 신뢰도, 오래된 페이지, 고아 페이지를 찾는다.
4단계는 검색 확장이다. rg나 qmd 같은 로컬 검색 도구를 붙인다. 위키가 커져도 필요한 페이지를 빠르게 찾게 만든다.
5단계는 출력 확장이다. Marp, 보고서 템플릿, 블로그 템플릿을 붙인다. 위키가 결과물 생산의 원천이 된다.
6단계는 자동화 확장이다. MCP, Agent Skills, 파일 감시, 정기 lint를 붙인다. 이 단계부터는 반드시 권한과 리뷰 프로세스를 함께 설계해야 한다.
도구 확장의 목표는 하나다. 위키를 더 자주 쓰게 만드는 것이다. 수집이 쉬워지고, 찾기가 쉬워지고, 점검이 쉬워지고, 결과물로 바꾸기 쉬워지면 위키는 살아남는다.
LLM Wiki는 완성품이 아니라 운영체제다. 기본 구조 위에 필요한 도구를 붙이되, 원칙은 계속 같아야 한다. 원문은 증거로 남기고, 위키는 지식으로 정리하며, AI는 반복 작업을 맡고, 인간은 방향과 판단을 맡는다.
참고
1LLM-Wiki Obsidian Setup Guide
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.