LLM 위키(LLM wiki)를 한 단계 업그레이드하는 10가지 방법

원본: https://www.youtube.com/watch?v=b6sQIuPSbzE · 업로드: 2026-04-10 · 길이: 19m · 채널: Onchain AI Garage

들어가며

지난 영상에서는 Claude Code와 Obsidian을 이용해 LLM 기반 위키(LLM-powered wiki)를 만드는 방법을 소개했다. 그 결과물은 고급 트레이딩 기법에 대한 지식이 쌓여 있는 트레이딩 전용 위키였다. 단순한 텍스트 기반 위키 그 자체로도 쓸 만했지만, 오늘은 이것을 한 단계 더 발전시켜서 시각적이고(visual), 상호작용이 가능하며(interactive), 실제 업무에 실질적인 도움이 되는 도구로 탈바꿈시켜 보려 한다.

먼저 지난 영상을 봐주고 댓글을 남겨준 모든 분들에게 감사 인사를 전한다. 반응이 정말 뜨거웠고, 무엇보다 안드레이 카파시(Andrej Karpathy) 본인이 직접 긍정적인 댓글을 남겨주었다는 점이 큰 힘이 되었다. 이 위키 아이디어 자체가 카파시의 제안에서 출발한 것이기 때문에, 원작자로부터 괜찮다는 확인을 받은 셈이다.

LLM 위키와 RAG의 차이

본격적인 이야기를 시작하기 전에, 댓글과 트위터에서 반복적으로 들어온 질문 하나를 짚고 넘어가고 싶다. “LLM 위키와 RAG(Retrieval Augmented Generation, 검색 증강 생성)는 도대체 뭐가 다른가?”라는 질문이다. 많은 사람들이 둘을 같은 것으로 생각하고 있었는데, 실제로는 상당히 다른 개념이다.

RAG는 먼저 문서를 임베딩(embedding), 즉 숫자 벡터(vector)로 변환해서 저장해 둔다. 질문이 들어오면 그 질문 역시 벡터로 변환한 뒤, 수학적인 유사도 계산을 통해 가장 비슷한 문서 조각을 찾아오는 방식이다.

반면 LLM 위키는 모델 자신이 목차(table of contents)를 직접 읽고, 제목과 요약만 보고도 어떤 페이지가 관련 있는지 골라내는 방식이다. 임베딩도, 벡터도, 별도의 데이터베이스도 필요 없다. 말 그대로 LLM이 사람처럼 위키를 뒤져보는 셈이다.

그럼 각각 언제 써야 할까? LLM 위키는 잘 큐레이션된 문서 수백 개 규모의 지식베이스에 적합하다. 반면 RAG는 수천에서 수만 건에 이르는 대규모 문서 집합, 예를 들어 프랍 트레이딩 회사의 전체 고객 데이터베이스처럼 방대한 자료를 다룰 때 위력을 발휘한다. 또 하나 중요한 차이는, LLM 위키는 지식이 시간이 지나면서 누적된다는 점이다. 매 질의마다 새로 처음부터 뒤지는 RAG와 달리, 위키는 지난 영상에서 이야기한 린팅(linting) 과정을 통해 LLM이 스스로 내용을 최신 상태로 유지한다.

요약하면, 한 분야에 깊게 파고들면서 지식을 쌓아가고 싶다면 LLM 위키가 좋고, 방대한 코퍼스(corpus)를 가로질러 빠르게 답만 얻으면 되는 상황이라면 RAG가 정답이다. 그래서 LLM 위키는 흔히 “지식 베이스(knowledge base)“라고도 불린다. 트레이딩 전략, 개인 목표 관리, 취미 기록처럼 자신만의 연구 도메인을 다룰 때 가장 빛을 발한다.

오늘 소개할 10가지 기능

그동안 필자는 이 위키에 더 많은 지식을 채워 넣는 작업을 해왔다. 트랜스크립트, 차트, 시각 자료, ICT(Inner Circle Trader) 관련 고급 트레이딩 서적 등을 대거 추가해서 훨씬 탄탄한 위키가 되었다.

이번 영상에서는 이 위키를 강화할 열 가지 방법을 라이브로 시연해 본다. 실패할 수도 있지만, 관심이 가는 항목부터 골라 봐도 좋다. 전체 목록은 다음과 같다.

1. 그래프 뷰(Graph View) — 모든 페이지와 상호 링크를 시각화한 인터랙티브 노드 지도
2. 캔버스(Canvas) — 위키 페이지를 드래그해서 공간적으로 배치하고 연결할 수 있는 무한 화이트보드
3. 데이터뷰(Dataview) — 프론트매터(front matter)에서 자동 생성되는 실시간 테이블과 대시보드
4. 마크슬라이드(MarkSlides) — 마크다운 문서를 슬라이드 프리젠테이션으로 변환
5. 엑스칼리드로우(Excalidraw) — 손으로 그린 느낌의 다이어그램과 스케치를 위키 페이지에 임베드
6. 차트 뷰(Charts View) — 노트에 들어 있는 데이터로부터 막대·파이·레이더·트리맵 차트 생성
7. 머메이드 다이어그램(Mermaid diagrams) — 마크다운으로 작성하는 플로우차트와 의사결정 트리(Obsidian 기본 지원)
8. MCP 서버(MCP server) — 위키를 도구로 노출해, Claude 외 다른 AI도 검색·읽기 가능
9. 트레이드 저널 크로스 레퍼런싱(Trade journal cross referencing) — 실제 트레이드 로그를 개념 페이지와 자동 연결
10. 스페이스드 레퍼티션 익스포트(spaced repetition export) — Anki 연계 플래시카드로 위키 내용을 암기 학습

앞의 일부는 Obsidian의 기본 기능이고 일부는 커뮤니티 플러그인이다. 마지막 세 개는 직접 만들어야 한다. 영상 마지막에는 전체 코드를 오픈소스로 공개한 깃허브 저장소도 소개한다.

1. 그래프 뷰와 2. 캔버스 — 기본 시각화

그래프 뷰는 사이드바의 버튼만 누르면 바로 열린다. 위키 안의 모든 개념이 서로 어떻게 연결되어 있는지 한눈에 들어오는 인터랙티브 그래프가 나타난다. 캔버스도 마찬가지로 기본 기능이다. “새 캔버스”를 누른 다음, 예를 들어 “Drawn Liquidity”를 가운데 두고, “Fair Value Gap”, “Failure Swings” 같은 카드를 그 주변에 배치하고 화살표로 연결해 간다. 색을 바꾸면 더 보기 좋아진다. 개념 간 관계를 공간적으로 파악하기에 아주 적합한 화이트보드 뷰다.

3. 데이터뷰 — 살아 있는 대시보드

데이터뷰(Dataview)는 커뮤니티 플러그인이다. 설정 → 커뮤니티 플러그인에서 설치 후 활성화하면 된다. Claude가 이 플러그인을 이용해 “위키 대시보드” 페이지를 자동으로 만들어 주었는데, 프론트매터에서 실시간으로 테이블이 생성된다. 신뢰도(confidence)가 낮아 보완이 필요한 페이지, 페이지별 소스 개수, 태그별 개념 분류, 최근 업데이트된 항목까지 모두 자동으로 표시된다. 새 소스를 추가하면 즉시 대시보드가 갱신된다.

4. 마크슬라이드 — 마크다운이 곧 슬라이드

마크슬라이드(MarkSlides)도 커뮤니티 플러그인이다. 카파시 본인이 이 플러그인을 언급한 적이 있다고 한다. 프론트매터에 marp: true를 추가하고, 마크다운 안에 ---로 슬라이드 경계만 표시하면 된다. 이 포맷팅 작업은 LLM에게 맡기면 몇 초 만에 끝난다. 슬라이드 프리뷰 버튼을 누르면 위키 항목이 곧바로 슬라이드로 변환된다. 화려하진 않지만, 몇 초 만에 만들 수 있다는 점이 가장 큰 매력이다.

5. 엑스칼리드로우 — 손그림 다이어그램

엑스칼리드로우(Excalidraw)는 설명이 필요 없는 인기 플러그인이다. 설치하고 “New Drawing”을 누르면 도형·텍스트·이미지 삽입 같은 기본 도구가 제공된다. 차트 이미지를 붙여넣고 그 위에 직접 주석을 달 수도 있다. 이렇게 만든 주석은 위키 안에 그대로 저장되며, AI 에이전트도 이 주석을 읽고 답변에 활용할 수 있다. 정적 이미지에 비해 가장 큰 장점은 드로잉이 수정 가능하고, 위키 내부에 그대로 살아 있어서 지식베이스가 커져도 동기화가 유지된다는 점이다.

6. 차트 뷰 — 데이터 시각화

차트(Charts) 플러그인은 노트 안의 데이터로 실시간 차트를 그려 준다. Claude에게 “위키 애널리틱스 페이지”를 만들게 했더니 파이 차트(페이지별 신뢰도 분포), 카테고리별 분류, 소스별 페이지 수, 전략 비교용 레이더 차트, 가장 자주 언급되는 단어의 워드 클라우드, 위키 전체 구조를 보여주는 트리맵까지 한 페이지에 모아 주었다. 라인·영역·컬럼·산점도 등 지원 차트 종류도 다양하다.

7. 머메이드 다이어그램 — 플러그인 없이

머메이드(Mermaid)는 Obsidian이 기본으로 지원한다. LLM에게 “이 주제를 플로우차트로 만들어 달라”고만 하면 된다. 예를 들어 “주간 고점·저점에 있는가?”로 시작되는 트레이드 진입 판단 플로우차트가 깔끔하게 생성된다. 다이어그램을 개별 파일로 저장해서 다른 곳에서도 재사용할 수 있다.

8. MCP 서버 — 위키를 API로

MCP(Model Context Protocol) 서버는 위키를 하나의 도구로 외부에 노출하는 역할을 한다. 이번엔 mcp-vault를 사용했는데, 원본 마크다운 파일 위에서 바로 동작하고 Obsidian이 실행 중일 필요도 없으며, BM25 검색까지 내장되어 있다. 설치는 1분도 걸리지 않았다.

MCP 이전에는 Claude Code만이 파일을 직접 읽을 수 있었지만, MCP를 붙이고 나면 ChatGPT 데스크톱, Cursor 등 MCP를 지원하는 거의 모든 AI 클라이언트가 같은 위키에 접근할 수 있다. 배경에서 돌면서 위키 폴더를 감시하고 search, read, write 같은 도구를 노출한다. 필자는 로컬 PC에서만 쓰고 있지만, 팀 단위로 협업한다면 원격 MCP 서버로 배포해서 API 형태로 공유할 수도 있다.

9. 트레이드 저널 크로스 레퍼런싱 — 이론과 실전의 연결

이 기능은 필자의 트레이딩 위키에 특화되어 있지만, 개인 경험이나 데이터를 기록하고 이론과 연결하는 어떤 영역에도 응용할 수 있다. Claude가 몇 초 만에 저널 템플릿을 만들어 주었다. “Gold Short” 같은 트레이드를 기록하면 진입가·세팅·결과가 저장되고, 대시보드에는 승률, 상품별·세션별 성과 기록이 자동으로 집계된다. 새 저널 항목을 추가할 때마다 실시간으로 갱신된다. 기록된 실전 결과가 개념 페이지와 교차 참조되면서, 이론이 실제로 얼마나 통하는지를 꾸준히 점검할 수 있다.

10. 스페이스드 레퍼티션 — 위키를 학습 도구로

마지막은 개인적으로 가장 재미있는 아이디어였다. 스페이스드 레퍼티션(Spaced Repetition) 커뮤니티 플러그인을 설치하면 된다. 플래시카드는 정해진 포맷이 필요하기 때문에 Claude에게 위키 페이지를 질문/답변 형식으로 재구성해 달라고 하면 된다. 이미 내용이 다 있는 상태라 10초도 채 걸리지 않았다.

그 결과 “ICT의 Optimal Trade Entry란 무엇인가?”, “ICT에 따르면 가격은 왜 움직이는가?” 같은 간격 반복(spaced repetition) 플래시카드가 만들어졌다. “다시”, “좋음”, “쉬움” 같은 피드백을 누르면 다음 노출 시점이 조정된다. CSV로 내보내서 Anki에서 복습할 수도 있고, Obsidian 안에서 그대로 사용할 수도 있다. 각 카드에는 출처 페이지(“ICT 개념”, “시장 구조”, “유동성”)까지 함께 표시된다. 위키의 지식을 그대로 사람의 기억으로 옮기는, 말 그대로 “인간 학습용 보조 장치”가 되는 셈이다.

마무리

정리하면, 오늘은 LLM 위키를 보다 시각적이고 상호작용적으로 확장하는 열 가지 방법을 살펴봤다. 대부분의 기능을 Obsidian 안에서 해결하는 것을 원칙으로 삼았지만, 더 나아가 얼마든지 자신만의 방식으로 확장할 수 있다. 모든 코드와 설정은 깃허브 tombi-studio/llm-wiki 저장소에 오픈소스로 공개되어 있다. 기본 디렉터리 구조, Claude 지침 파일, 각 플러그인의 설치 방법까지 포함되어 있어, AI 에이전트가 저장소를 읽기만 해도 유사한 환경을 재현할 수 있도록 설계했다(트레이딩 데이터는 본인의 것으로 채워 넣어야 한다).

이런 식의 지식 베이스는 개인뿐 아니라 기업이나 기관 단위에서도 상당한 수요가 있을 것이라고 본다. 질문을 던질수록, 사용할수록 점점 똑똑해지고 스스로 성장하는 지식 베이스 — 이것이 단순 검색 시스템과 구분되는 가장 큰 매력이다.

---

title: “LLM 위키(LLM Wiki)를 진짜 지식 베이스로 진화시키는 법 — RAG를 넘어서는 10가지 확장” source: “YouTube” channel: “Onchain AI Garage (@OnchainAIGarage)” upload: “2026-04-10”

LLM 위키(LLM Wiki)를 진짜 지식 베이스로 진화시키는 법

서론 — “또 하나의 RAG”가 아닌 이유

2026년 들어 개인 지식 관리 영역에서 가장 흥미로운 움직임 중 하나는, 안드레이 카파시(Andrej Karpathy)가 제안한 LLM 위키(LLM Wiki) 혹은 LLM Knowledge Base 패턴이다. 카파시는 X(트위터)에 “자신이 연구 관심사별로 관리하는 방법”이라며 이 접근법을 공개했고, VentureBeat는 이를 두고 “RAG를 우회하는, LLM이 직접 유지보수하는 진화형 마크다운 라이브러리”라고 요약했다(VentureBeat).

Onchain AI Garage 채널의 이번 영상 「10 Easy Ways to Enhance Your LLM Wiki or Knowledge Base」은 이 패턴을 한 발 더 밀고 나간다. “마크다운 위키를 만들었다”에서 멈추지 않고, Obsidian 생태계의 플러그인과 MCP(Model Context Protocol) 서버를 결합해 위키를 시각적이고, 상호작용 가능하며, 다른 AI 도구와도 연결되는 작업 환경으로 확장하는 방법을 소개한다.

이 글에서는 영상에서 다룬 10가지 확장법을 단순 나열하는 대신, (1) LLM 위키가 왜 RAG와 다른 문제를 푸는지, (2) 어떤 확장이 실제로 “지식의 복리 효과(compounding)“를 만드는지, (3) 실무에 옮기려면 어떤 점을 조심해야 하는지를 정리한다.

본론 1 — LLM 위키 vs RAG: 다른 문제, 다른 도구

많은 사람들이 LLM 위키와 RAG(Retrieval Augmented Generation, 검색 증강 생성)를 같은 것으로 오해한다. 그러나 둘은 동작 방식도, 사용 목적도 다르다.

RAG는 문서를 벡터 임베딩(vector embedding)으로 변환해 저장하고, 질문 또한 임베딩으로 변환한 뒤 수학적 유사도 기반으로 관련 청크(chunk)를 꺼내오는 구조다. 반면 LLM 위키는 LLM 자신이 목차와 요약만 읽고 사람처럼 관련 페이지를 고른다. 벡터 DB도, 임베딩 파이프라인도 없다.

MindStudio는 이 차이를 다음과 같이 설명한다. “RAG는 매 질의마다 지식을 처음부터 다시 찾아낸다. 축적되는 것이 없다. 반면 LLM 위키는 LLM이 먼저 구조화된 지식 베이스를 쌓아두고, 그 위에서 추론한다”(MindStudio 해설). Atlan의 비교 문서도 동일한 결론을 제시한다 — “LLM 위키는 토큰 효율성과 단순성 측면에서, 대략 100200개 문서, 5만10만 토큰 수준의 작고 안정적인 개인 규모 지식 베이스에서 RAG를 능가한다. 하지만 수만 건의 문서를 가로질러 검색해야 하는 대규모 환경에서는 여전히 RAG가 유리하다”(Atlan: LLM Wiki vs RAG).

실무적으로 이 분기점은 중요하다. “깊게 한 도메인을 파고들며 지식을 누적”할 것인가, 아니면 “얕고 넓게 대규모 코퍼스를 검색”할 것인가. 전자라면 LLM 위키, 후자라면 RAG다. 영상에서 소개된 트레이딩 위키, 개인 연구 노트, 학습 로그, 제품 매뉴얼 정리 같은 사례는 모두 전자에 해당한다.

본론 2 — 기본기: 그래프, 캔버스, 데이터뷰

영상의 10가지 기능 중 앞의 세 가지(그래프 뷰, 캔버스, 데이터뷰)는 “이미 만든 위키를 눈으로 보게 해주는” 도구다.

• 그래프 뷰(Graph View): 노드와 링크로 위키 전체 구조를 시각화. 개념 간 연결이 얼마나 촘촘한지, 고립된 페이지가 있는지 한눈에 파악된다.
• 캔버스(Canvas): 페이지 카드를 드래그해서 자유롭게 배치하는 무한 화이트보드. 공간적 사고가 필요한 전략 설계에 유용하다.
• 데이터뷰(Dataview): 커뮤니티 플러그인. 프론트매터(front matter)의 YAML 메타데이터를 읽어 실시간 테이블·대시보드를 생성한다. 영상에서는 “신뢰도(confidence) 낮은 페이지”, “태그별 개념 집계”, “소스 수”, “최근 업데이트” 대시보드를 자동 생성했다.

Obsidian Mate의 2026년 추천 플러그인 리스트도 Dataview, Templater, Excalidraw, Tasks, Calendar, Obsidian Git을 “2026년 필수 플러그인”으로 꼽는다(Obsidian Mate — Best Plugins 2026). 흥미로운 점은, 2025년 8월 Obsidian v1.9.10 릴리스에 도입된 Bases 플러그인이 대시보드 용도에서 Dataview를 부분적으로 대체하기 시작했다는 것이다. 영상에서는 Dataview를 기준으로 설명했지만, 2026년 현재 새로 시작하는 사용자라면 Bases도 함께 검토할 만하다.

본론 3 — 시각화 레이어: 엑스칼리드로우, 차트, 머메이드, 슬라이드

중간 네 가지 기능은 지식의 “형태”를 바꿔주는 레이어다. 텍스트로 남겨진 개념이 다이어그램·차트·슬라이드로 변환되면, 이해의 속도가 눈에 띄게 달라진다.

• 엑스칼리드로우(Excalidraw): 손그림 스타일의 드로잉을 위키 안에 저장·편집. 차트 이미지를 불러와 직접 주석을 다는 흐름이 특히 강력하다. Excalidraw 공식 저장소는 “드로잉은 계속 편집 가능하고 위키 내부에 그대로 살아 있다”는 점을 핵심 가치로 내세운다(zsviczian/obsidian-excalidraw-plugin).
• 차트 뷰(Charts View): 노트 안의 데이터로 파이·바·레이더·트리맵·워드 클라우드 등을 즉시 그려준다. 위키 자체의 메타 통계(페이지 수, 카테고리 분포, 소스 출처) 시각화가 대표 사용처다.
• 머메이드(Mermaid) 다이어그램: 마크다운 코드 블록으로 플로우차트와 의사결정 트리를 작성하는, Obsidian의 기본 기능. LLM에게 “이 개념을 플로우차트로 그려라”고 지시하는 것만으로 충분하다.
• 마크슬라이드(MarkSlides): 위키 항목을 바로 슬라이드 프리젠테이션으로 변환. 카파시 본인이 언급한 적이 있다고 한다.

여기서 주목할 점은 **“AI에게 포맷 변환을 맡긴다”**는 워크플로우다. 엑스칼리드로우 드로잉을 수동으로 그리는 대신, 개념 페이지를 던지면 LLM이 머메이드나 마크슬라이드용 포맷으로 재작성한다. 위키는 “원본(source of truth)“이고, 시각화는 “LLM이 그때그때 다시 생성할 수 있는 파생물”이 된다. 이렇게 보면 위키의 가치는 “시각화 결과물”이 아니라 원본 마크다운의 정확성과 링크 구조에 있다.

본론 4 — 자동화 레이어: MCP 서버, 트레이드 저널, 스페이스드 레퍼티션

마지막 세 가지 기능은 영상 제작자가 직접 구현해야 하는 **“자동화 레이어”**다. 여기서부터 위키는 단순한 메모장이 아니라 외부 AI 도구와 연결되는 살아 있는 시스템이 된다.

• MCP 서버 (mcp-vault): 위키를 MCP(Model Context Protocol) 도구로 노출한다. 영상에서는 원본 마크다운 위에서 바로 동작하고 BM25 검색까지 내장한 mcp-vault를 사용했다. 이전에는 Claude Code만 파일에 접근할 수 있었지만, MCP 이후에는 ChatGPT 데스크톱, Cursor, Claude Desktop 등 MCP를 말하는 모든 클라이언트가 같은 위키를 공유할 수 있다. 클로드 플러그인 마켓플레이스에서도 Obsidian 마크다운 연동 스킬이 확산 중이다(claude-plugins.dev — obsidian-markdown).
• 트레이드 저널 크로스 레퍼런싱: “이론 페이지 ↔ 실전 로그”를 자동으로 연결한다. 트레이딩 외에도 일기, 실험 로그, 운동 기록, 제품 QA 로그 같은 모든 “경험 기반 도메인”에 이식 가능한 패턴이다.
• 스페이스드 레퍼티션(Spaced Repetition): 커뮤니티 플러그인을 이용해 위키 페이지를 간격 반복 플래시카드로 자동 변환. 필요하면 Anki용 CSV로 내보낼 수 있다. 위키의 지식을 실제 인간의 장기 기억으로 이전시키는, 아주 드물게 시도되는 “학습용 출력” 레이어다.

유사한 접근을 Claude + Obsidian 조합으로 구현한 오픈소스 프로젝트도 점점 늘고 있다(AgriciDaniel/claude-obsidian). 2026년 현재 이 생태계는 확실히 임계점을 넘은 상태다.

핵심 인사이트

1. LLM 위키의 진짜 가치는 “복리”에 있다. RAG는 매 질의마다 바닥에서 다시 시작하지만, LLM 위키는 LLM이 지속적으로 정리·갱신·린팅(linting)하면서 지식이 누적된다. 시간이 지날수록 사용자에게 유리해지는 몇 안 되는 구조다.
2. 시각화는 파생물, 마크다운이 원본이어야 한다. 엑스칼리드로우·머메이드·슬라이드는 LLM이 언제든 다시 생성할 수 있다. 그래서 투자 우선순위는 원본 노트의 품질에 있다. 예쁜 그림부터 만들려는 유혹은 경계해야 한다.
3. MCP 서버가 “지식 베이스의 USB-C”다. 위키를 한 번만 MCP로 노출해 두면, 그 위에 어떤 AI 클라이언트를 붙이든 같은 지식에 접근할 수 있다. 이는 특정 LLM 벤더에 잠기지 않는 (vendor-neutral) 지식 인프라가 된다.
4. 이 패턴이 맞지 않는 경우도 분명히 있다. 수만 건의 문서를 가로질러 검색해야 하는 엔터프라이즈 환경에서는 여전히 RAG가 답이다. 영상의 접근은 “개인~소규모 팀, 깊이 있는 한 도메인”이라는 조건 안에서 최적이다.
5. “AI가 만들어주는 플래시카드”는 과소평가된 학습 파이프라인이다. 위키 → Spaced Repetition → 인간 기억까지 이어지는 사이클은, LLM 시대에도 (아니, LLM 시대라서 오히려) 인간의 기저 지식을 지켜내는 가장 실용적인 방법 중 하나다.

더 알아보기

• Andrej Karpathy — llm-wiki gist (원본 제안)
• VentureBeat — Karpathy shares ‘LLM Knowledge Base’ architecture that bypasses RAG
• MindStudio — What Is the Karpathy LLM Wiki Pattern?
• Atlan — LLM Wiki vs RAG Knowledge Base
• Obsidian Mate — Best Obsidian Plugins 2026
• zsviczian — obsidian-excalidraw-plugin (GitHub)

토론: “시각화와 자동화 레이어를 얹은 LLM 위키는, 개인·소규모 팀의 지식 관리에서 RAG를 대체할 수 있는가?”

논제: 영상에서 제안한 “Obsidian + 10가지 확장” 기반의 LLM 위키 패턴이, 개인 및 소규모 팀의 장기 지식 축적 도구로서 RAG보다 우월한가?

원본: YouTube — 10 Easy Ways to Enhance Your LLM Wiki or Knowledge Base · Onchain AI Garage · 2026-04-10

---

Round 1

🟢 Pro — “지식은 ‘축적되는 시스템’에서만 복리로 자란다”

Pro의 첫째 주장은 **“복리(compounding)의 존재 여부”**다. RAG는 본질적으로 매 질의마다 원본 문서 위에서 처음부터 유사도 계산을 다시 한다. 축적되는 것은 인덱스뿐이며, “지식 자체”가 시간이 지남에 따라 더 풍부해지거나 정교해지지는 않는다. 반면 LLM 위키는 LLM이 주기적으로 린팅(linting)·요약·링크 갱신을 수행하면서 위키 자체가 더 깔끔해지고, 모순이 제거되고, 개념 간 연결이 촘촘해진다. 오늘 쓴 5분의 시간이 한 달 뒤의 답변 품질로 돌아오는 구조다.

Pro의 둘째 주장은 **“투명성(transparency)과 수정 가능성(editability)“**이다. RAG 시스템에서 “왜 이 청크가 검색되었는가?”를 설명하려면 임베딩 공간의 코사인 유사도를 해석해야 한다. 사람은 그 공간에 개입할 방법이 거의 없다. 반면 마크다운 위키는 사람이 직접 열어 읽고, 고치고, 링크를 추가할 수 있는 “정직한 텍스트”다. MindStudio는 이를 두고 “구조화된 텍스트에 대한 LLM의 추론 능력이 커지면서, 벡터 DB라는 복잡성 자체가 중간 규모 데이터셋에서는 불필요해졌다”고 평가한다(MindStudio).

Pro의 셋째 주장은 **“MCP 서버가 벤더 중립성을 만든다”**는 점이다. 위키를 mcp-vault 같은 MCP 서버로 한 번 노출해 두면, Claude Code, ChatGPT 데스크톱, Cursor 등 어떤 클라이언트에서도 같은 지식을 쓸 수 있다. 임베딩 모델에 종속된 RAG 파이프라인은 벤더나 모델이 바뀌면 재임베딩 비용이 드는 반면, 마크다운은 포맷 자체가 불멸에 가깝다.

🔴 Con — “개인 규모에서 잘 돈다고 해서 ‘대체’가 되는 건 아니다”

Con의 첫째 주장은 **“스케일 한계는 기술이 아니라 수학이다”**이다. 카파시 본인조차 이 패턴이 잘 도는 규모를 “100개 안팎의 문서, 40만 단어 수준”으로 못박았다. Atlan 역시 “LLM 위키가 RAG를 능가하는 지점은 5만10만 토큰, 100200개 문서 수준”이라고 적는다. 문서 수가 그 이상으로 늘면 컨텍스트 윈도우에 목차와 요약을 다 태울 수조차 없게 되고, **“LLM이 목차를 읽고 관련 페이지를 고른다”**는 전제 자체가 무너진다(Atlan — LLM Context Window Limitations 2026).

Con의 둘째 주장은 **“유지보수 비용이 숨어 있다”**는 점이다. LLM 위키는 “LLM이 알아서 린팅해 준다”고 말하지만, 실제로는 사람이 린팅 프롬프트를 설계하고, 결과를 검토하고, 잘못된 요약을 수정해야 한다. 문서 수가 수십 개에서 수백 개로 늘면 그 메타-작업(meta-work) 자체가 본업을 잡아먹는다. 반면 잘 구축된 RAG 파이프라인은 임베딩 재생성만 스크립트로 처리하면 되므로, “많은 문서 × 적은 사람 손”이라는 조합에서 훨씬 유리하다.

Con의 셋째 주장은 **“영상이 보여준 10가지는 지식 저장이 아닌 ‘시각화 도구’에 가깝다”**는 것이다. 그래프 뷰, 캔버스, 엑스칼리드로우, 차트, 슬라이드, 플래시카드 — 이들 중 다수는 지식의 품질 자체를 올리지는 않는다. 예쁜 그림이 쌓일수록 “보기 좋은 것과 정확한 것”을 혼동할 위험이 있고, 관리 대상만 늘어난다. RAG 쪽 생태계는 이미 “평가(evaluation)·정확도 측정·검색 품질” 같은 냉정한 지표를 축적해 왔지만, LLM 위키 진영에는 아직 그런 평가 문화가 부재하다.

---

Round 2

🟢 Pro (재반론) — Con의 세 주장에 대해

Con의 첫째(스케일 한계)에 대한 재반론. Con은 “100~200개 문서”라는 숫자를 인용하지만, 이는 2025년 초 기준의 보수적 추정치다. 2026년 현재 상용 모델의 유효 컨텍스트 윈도우는 1M 토큰을 넘어섰고, 긴 컨텍스트에서의 추론 능력도 눈에 띄게 향상되었다. 더 중요한 지점은, **“위키 전체를 매번 컨텍스트에 넣을 필요가 없다”**는 것이다. 영상에서 이미 보여주었듯 MCP 서버는 위키 폴더를 감시하면서 search·read라는 도구를 LLM에 제공한다. LLM은 필요할 때 필요한 페이지만 읽는다 — 이는 사실상 RAG의 “선택적 검색” 장점을 마크다운 위에서 재현하는 것이며, 임베딩이라는 중간층이 빠졌을 뿐이다.

Con의 둘째(유지보수 비용)에 대한 재반론. Con은 린팅 비용이 “사람 손”을 요구한다고 말하지만, 이것은 RAG 파이프라인의 운영 비용과 비교되어야 한다. RAG는 임베딩 모델 선택, 청크 크기 튜닝, 하이브리드 검색 도입, 리랭커(reranker) 학습, 질의별 평가 지표 관리를 계속해야 한다. apxml.com은 “RAG 답변 품질은 청크 크기·인덱싱·검색 알고리즘 설계에 크게 의존하며, 이 중 어느 하나가 최적이 아니면 환각(hallucination)으로 이어진다”고 명확히 적는다(apxml — Managing Context Length). 반면 LLM 위키의 유지보수는 자기 자신이 읽는 문서를 다듬는 일 — 즉 사용자 본인의 이해도를 직접 올리는 작업이다. 비용이라기보다 학습이다.

Con의 셋째(시각화와 품질 혼동)에 대한 재반론. Con은 그래프·캔버스·슬라이드를 “보기 좋은 것”이라고 깎아내리지만, 이는 영상에서 제시된 10가지 중 MCP 서버, 트레이드 저널 크로스 레퍼런싱, 스페이스드 레퍼티션의 성격을 간과한다. 이 세 가지는 지식 → 검증 → 기억이라는 닫힌 루프를 만든다. 이론 페이지는 실전 로그에 의해 반증 가능해지고, 플래시카드는 그 지식을 사람의 장기 기억으로 옮긴다. 이것은 “시각화”가 아니라 평가(evaluation)의 사람 버전이다.

🔴 Con (재반박) — Pro의 세 주장에 대해

Pro의 첫째(복리)에 대한 재반박. Pro는 “위키는 시간이 지날수록 정교해진다”고 주장하지만, 이것은 사용자가 꾸준히 문서를 추가·편집할 때만 성립하는 조건부 명제다. 실제 개인 지식 관리 도구의 사용 패턴을 보면 대부분의 사용자는 초기 한 달에 집중적으로 쌓고, 이후 방치된다. 방치된 LLM 위키는 “오래된 요약”과 “죽은 링크”의 박물관이 되며, 오히려 LLM을 잘못된 결론으로 유도하기 쉽다. RAG는 이런 면에서 오히려 정직하다 — 문서를 업데이트하면 임베딩이 갱신되고, 업데이트하지 않으면 그 상태 그대로일 뿐이다. “복리”라는 단어는 사용자가 성실하다는 전제 위에서만 성립한다.

Pro의 둘째(투명성)에 대한 재반박. Pro는 “마크다운은 사람이 읽을 수 있다”는 점을 투명성이라고 부르지만, 이는 검색 결정의 투명성과는 다른 층위다. LLM이 “목차를 읽고 페이지 A를 골랐다”고 할 때, 그 선택이 왜 페이지 B가 아니었는지는 여전히 블랙박스다. 반면 RAG에서는 청크 단위로 유사도 점수를 확인할 수 있고, 리랭커의 점수 분포까지 로그로 남길 수 있다. Pro가 말하는 투명성은 “원본 텍스트가 사람이 읽을 수 있다”는 수준에 머무를 뿐, 검색·선택 메커니즘의 설명 가능성은 LLM 위키 쪽이 오히려 더 취약하다.

Pro의 셋째(MCP 벤더 중립성)에 대한 재반박. MCP는 분명 매력적인 표준이지만, Pro가 말하는 “한 번만 노출하면 어디서든 쓴다”는 이상은 현실과 거리가 있다. MCP 클라이언트마다 도구 호출 규약, 권한 모델, 파일 락(file lock) 처리 방식이 미묘하게 다르고, 여러 AI가 동시에 같은 위키를 쓰면 쓰기 충돌과 일관성 붕괴가 발생한다. RAG는 읽기 전용 시스템이라 이런 문제를 애초에 피한다. “벤더 중립성”이라는 이상은 실제 구현에서 “누가 쓰기 권한을 가지느냐”는 새로운 중앙화 문제를 끌어들인다.

---

Round 3

🟢 Pro — Con의 Round 2 재반박에 대한 재반론

Con의 첫째 재반박(방치 위험)에 대해. Con은 “사용자는 방치하기 마련이다”라고 말한다. 하지만 이는 모든 지식 관리 도구에 공통된 인간적 한계이지, LLM 위키만의 약점이 아니다. 오히려 LLM 위키는 이 문제를 가장 직접적으로 완화하는 구조를 가지고 있다. 영상에서 소개된 Dataview 대시보드는 “신뢰도 낮은 페이지”, “오래 업데이트되지 않은 페이지”를 자동으로 띄우고, 린팅 프롬프트는 LLM에게 정기적으로 “모순된 주장과 죽은 링크를 찾아라”고 시킬 수 있다. 이는 RAG에서는 사실상 불가능한 능동적 자기 관리 루프다. Con이 든 “박물관화” 시나리오는 LLM 위키의 결함이 아니라, 이 도구를 소극적으로 쓸 때의 사용 실패다.

Con의 둘째 재반박(검색 투명성)에 대해. Con은 “LLM이 왜 페이지 A를 골랐는지는 블랙박스”라고 지적한다. 그러나 현대 LLM은 **사고 과정(thinking)**을 명시적으로 출력할 수 있다. “먼저 목차에서 X, Y 후보를 봤고, Y는 주제가 달라 보여 제외했으며, X의 요약을 읽고 해당 페이지를 열었다”는 식의 서술은 RAG의 코사인 점수보다 사람 입장에서 훨씬 설명 가능하다. RAG의 “이 청크가 0.87점이었기 때문에 선택됐다”는 설명은 수학적으로 투명해 보이지만, 정작 “왜 이 점수가 나왔는가”를 설명하지 못한다. 자연어 추적은 수치보다 약하지 않다 — 오히려 감사(audit)에 더 적합하다.

Con의 셋째 재반박(MCP 쓰기 충돌)에 대해. Con이 지적한 동시 쓰기 문제는 실재하지만, 이는 Git 기반 워크플로우로 이미 해결된 문제의 재발견이다. Obsidian 자체가 마크다운 파일을 그대로 쓰고, obsidian-git 플러그인으로 버전 관리를 할 수 있으며, 영상에서 언급된 오픈소스 저장소 구조 역시 Git을 전제로 한다. 충돌은 머지(merge)로, 이력은 커밋으로 해결된다. 이는 벡터 DB가 절대로 제공하지 못하는 의미 있는 diff 기능이다.

🔴 Con — Pro의 Round 2 재반론에 대한 재반박

Pro의 첫째 재반론(1M 컨텍스트 + MCP의 선택적 검색)에 대해. Pro는 “1M 토큰 + MCP 검색 도구”라는 조합으로 스케일 문제를 해결했다고 주장한다. 그러나 이것은 RAG 아키텍처의 우회적 재발견에 불과하다. MCP search 도구가 내부적으로 무엇을 하는가? mcp-vault는 BM25 검색을 내장한다고 영상에서 밝혔다. 즉, **“임베딩 대신 BM25라는 또 다른 검색 알고리즘을 붙인 RAG”**다. Pro가 “임베딩이라는 중간층이 빠졌다”고 말할 때, 실제로는 벡터 검색이 BM25로 바뀌었을 뿐 “검색 → 컨텍스트 주입 → 생성”이라는 RAG의 뼈대는 그대로다. “LLM이 목차를 읽고 사람처럼 판단한다”는 순수한 LLM 위키 비전은, 문서 수가 늘면 결국 검색 기반 RAG의 친척이 된다. unstructured.io 역시 “롱 컨텍스트 모델의 시대에도 RAG는 사라지지 않고, 오히려 선택적 검색을 위한 필수 계층으로 남았다”고 결론짓는다(Unstructured — RAG vs. Long-Context Models).

Pro의 둘째 재반론(린팅은 학습이다)에 대해. Pro는 “유지보수 = 학습”이라는 수사로 비용 문제를 덮으려 한다. 그러나 이것은 도구의 확장성과 개인의 학습 곡선을 혼동하는 주장이다. 한 사람의 연구 노트라면 린팅이 학습이 될 수 있다. 하지만 “소규모 팀”으로 확장되는 순간, 다른 사람의 도메인에 대해 린팅 프롬프트를 돌리는 일은 학습이 아니라 남의 지식 관리 노동이 된다. 팀 규모로 가면 이 비용은 기하급수적으로 늘어난다. 영상이 “개인 트레이딩 위키”에 머물러 있는 이유도 이것이다 — 확장 실험이 아직 존재하지 않는다.

Pro의 셋째 재반론(MCP + 저널 + 플래시카드 = 평가 루프)에 대해. Pro는 이 세 요소가 “닫힌 평가 루프”를 만든다고 주장한다. 하지만 그것은 트레이딩이라는 특수한 도메인이기 때문에 가능한 것이다. 트레이드는 숫자로 승/패가 결정되고, 플래시카드는 정답이 있는 개념 질문에만 통한다. 대부분의 지식 작업(제품 디자인, 전략 기획, 정책 리서치)은 그런 명확한 정답 신호가 없다. Pro가 든 사례는 가장 평가하기 쉬운 도메인을 고른 체리피킹이며, 영상의 10가지 기능이 일반 도메인에서도 같은 루프를 만든다는 보장은 없다.

---

🧭 종합

합의 지점

양측 모두 다음 두 가지에는 이견이 없었다.

첫째, 영상이 소개한 패턴은 개인·소규모·단일 도메인에 한해 실질적으로 잘 작동한다. 트레이딩 위키, 연구 노트, 학습 로그처럼 “한 사람이 한 주제를 깊게 파는” 상황에서 LLM 위키 + Obsidian 생태계는 RAG보다 단순하고 투명하며, 린팅 루프는 실제로 지식 품질을 시간에 따라 끌어올린다.

둘째, LLM 위키와 RAG는 같은 스펙트럼의 양 끝이지 대립항이 아니다. MCP의 search 도구가 내부적으로 BM25를 돌린다는 사실이 보여주듯, 규모가 커지면 LLM 위키도 어떤 형태의 검색 계층을 껴안게 된다. 반대로 RAG도 LLM이 직접 유지보수하는 요약 레이어(예: Context Augmented Generation, CAG)를 얹는 방향으로 진화 중이다. 두 진영은 결국 서로 닮아간다.

열린 질문

• LLM 위키의 “린팅 품질”을 어떻게 객관적으로 측정할 것인가? RAG에는 recall@k, faithfulness, answer relevance 같은 정량 지표가 있다. LLM 위키 진영에는 아직 표준 평가 방법이 없다.
• 팀 규모에서의 쓰기 충돌과 거버넌스. MCP 서버를 통해 여러 사람·여러 AI가 같은 위키를 편집할 때, 누가 무엇을 승인하는가? Git 기반 PR 리뷰 문화를 AI 에이전트에게까지 확장할 수 있는가?
• 카파시가 제시한 ~100개 문서 한계는 앞으로 어디까지 올라갈 것인가? 이는 단순히 컨텍스트 윈도우만의 문제가 아니라, 긴 컨텍스트에서의 LLM 추론 정확도가 결정할 문제다.

더 나아간 관점

이 토론에서 드러난 가장 중요한 통찰은 **“저장 방식(format)이 아니라 유지보수 주체(agency)가 진짜 차이”**라는 점이다. RAG는 “사람이 업로드하면 시스템이 검색한다”는 수동적 모델이고, LLM 위키는 “LLM이 스스로 정리하고, 사람은 방향만 잡는다”는 능동적 모델이다. 영상이 소개한 10가지 확장 중 정말로 파급력이 큰 것은 시각화가 아니라 “LLM이 직접 쓰는” 레이어 — 즉 린팅 루프, MCP, 트레이드 저널 크로스 레퍼런싱이다.

앞으로의 싸움은 “벡터 vs 마크다운”이 아니라 **“지식 베이스가 얼마나 자율적으로 자신을 다듬을 수 있는가”**에서 벌어질 것이다. 이 축에서 본다면, 영상의 LLM 위키 패턴은 승자가 아니라 가장 설득력 있는 초기 설계 중 하나다. 승부는 아직 열려 있고, 정답은 둘 중 하나가 아니라 “자율 유지보수 기능을 가진 하이브리드”일 가능성이 가장 높다. dev.to의 RAG/CAG 비교 글이 정확히 이 지점을 지적한다(RAG vs CAG 비교).

결국 영상 속 10가지 확장은 “LLM 위키가 RAG를 이겼다”는 선언이 아니라, **“지식 베이스에 자율성을 부여하는 실험의 첫 라운드”**로 읽는 것이 가장 건강하다.

So in the last video on these knowledge bases, I showed you how to build this LLM-powered wiki
using Claude code and using Obsidian. And the end result here was this trading-based wiki with a lot
of knowledge about advanced trading techniques. It's pretty nice, but in today's episode we're
going to try to enhance this. We're going to transform this from something that's just a
text-based wiki like you would see into something that's visual, interactive, and really helpful in
your everyday work. And a quick thank you to everyone who watched and left comments on this
video that I released on the LLM wiki. It was great to get such a strong reaction. Andre Karpathy
himself actually had a nice comment to the video as well, so that was really encouraging,
as I'm obviously building on his ideas, so it's good to know that I'm not screwing everything up.
So thank you again to everyone who watched that video and left comments. Before we really get
into it, I want to answer a question that I got several times in the comments,
and on Twitter. People were asking, what is the difference really between this LLM wiki and
RAG, Retrieval Augmented Generation, which is the usual way you do to retrieve information like this?
This gives you a breakdown of the difference. A lot of people thought they were the same thing,
but basically with RAG, your documents get converted into numbers, embeddings,
you've probably heard, or vectors. When you ask a question, your question also gets converted
into numbers, and then a math formula is used to find the document chunks that have the most
similar numbers.
So that's embeddings and RAG. The LLM wiki is very different, because you have the model itself
reading a table of contents and then picking relevant pages based on their titles and
summaries, so it is different. RAG uses math and embeddings to find relevant text. The wiki just
uses the LLM itself to find the relevant text. There's no embeddings, no vectors, no database.
So kind of where you would want to use one or the other. The LLM wiki is good for when you have
up to a couple hundred sources and curated. RAG is when you're curating a document,
getting into the thousands, tens of thousands of sources, a real massive database of text.
The wiki compounds over time the knowledge. RAG is re-derived on every query. Maintenance the LLM
keeps it current by that linting process we talked about in the last video. RAG uses an embedding
pipeline. So this wiki is good when it's kind of a focused topic, and you're not working with a huge
mass database of text. So that's why it's also called a knowledge base, right? Something like
trading strategies, something like that. So that's why it's also called a knowledge base, right?
Something like trading strategies, something like that. So that's why it's also called a knowledge base,
something like personal goalkeeping, something like a hobby. That's where you want to use an LLM
wiki, your own kind of research domain. RAG is really good for if you have a huge corpus or a
huge database of text or information, like here, a prop firm's entire customer database. That's
where you're going to need something like RAG to really search through all of that mathematically.
So basic point, if you're going deep into one domain and just want the knowledge to build up,
use this LLM wiki. If you're going wide,
across a massive corpus, and just need answers, use the RAG method. So I just wanted to answer
that because I got that question several times. So let's move on. So I've been hard at work trying
to build up this wiki with a lot more knowledge. I added a lot more transcripts and charts,
more visuals, pictures, books on ICT and advanced trading. So it'll be a lot more
robust of a wiki as we move forward. So here we go. We got 10 enhancements to our LLM wiki.
And I'm doing this live. So some of these might be a failure. But these are the 10 that I
kind of thought were interesting and would really enhance it. So you can skip ahead to
whichever one you think is relevant for your knowledge base. But we're going to be doing
number one graph view, which is going to be an interactive node map of all the pages and
cross links to canvas, which is going to be an infinite whiteboard where you drag wiki pages
into spatial layouts and connect them to build a visual strategy map. Three is data view,
live auto updating of tables and dashboards generated from your page front matter. Number
four is going to be mark slots.
Number five is excala draw, which is a hand drawn style diagram and sketches embedded inside the
wiki pages for visual explanations of trade setups. In my case, number six is going to be
charts view. And this renders bar charts, pie charts, radar charts, tree maps from data in
your notes. Seven is going to be mermaid diagrams, which are flow charts and decision trees written
in markdown that obsidian renders natively. No plugin is going to be needed for this.
A couple of these are native obsidian features, and a couple of them are plugins. And these last
three are actually something we're going to have to build ourselves. But once we're done with this,
by the end of this video, I'll show you my GitHub repo, which is going to have everything I built.
This will all be open source, so you can check it out yourself and try to implement it if you
find any part of this interesting. So number eight is an MCP server,
which is going to expose your wiki as a tool. So any AI can read search, right, not just cloud code.
This will be really great if you're using a lot of different AI tools, or if you're working with
teams, and other people need access to the knowledge base. Number nine, this is specific
for mine, but a trade journal cross referencing. So you log each trade, and then the LM cross
references results against concept pages and connects the theory to practice. So this will
be most useful if you're doing a trading based wiki like me, but you can definitely adapt this
to your own purposes. I can see how something like this could be useful in a lot of different areas.
Number 10. I thought this was a fun idea space repetition export using Anki,
which you may have heard, it's a very popular flashcard app. So we're gonna try to auto
generate flashcards from the wiki content in order to help them write memorize concepts.
So this will actually become a nice little educational tool as well, if you're trying
to learn something. Okay, so let's get started. So number one, the graph view, and this is pretty
simple. This is just a built in task you see here on the side, you just open graph view. And there
you go. You can see here on the side, you can see here on the side, you can see here on the side, you
can see all the concepts in this kind of interactive graph, you can see what is connected
to what else, what are their topic, it just gives you a nice visualization to see how everything is
connected. So the next one's also built in, you do create new canvas here. And from here, you can
create a canvas. And this is basically a whiteboard that you could show to how things are connected.
Like we'll put drawn liquidity here in the middle. And then you can add, like, fail fair value gaps,
you can add a card for that one, move it around, you could connect it, obviously.
So you have a visualization should go this way.
Add failure swings here. Same thing, move it up here, align it however you like. There we go.
So this creates a nice little visualization of how the concepts are connected. And you can change
these change the color to make it more visual and clear. So the next one's actually going to require
a plugin. So you go into settings down here, the gear icon, go into community plugins,
turn them on, browse. And then we're looking for data view here, they have a lot of different
things. And we're gonna test out a few but data view is the one we're looking for. So now that
that was enabled, Claude was able to create a dashboard page in the wiki that auto generates
live tables from the front matter. So created this. So once this is in place, it'll update
automatically with low confidence pages that need to be updated. And then you can create a dashboard
page here. And you can see here, this is the data view, wiki dashboard. And it gives you a lot of
this is all updated. Every time you add a source, it's updated live, but you can see low confidence
pages, it shows you the source count for each of these pages. So it can tell you which pages have
a lot of sources, which have few get all the concepts by tag. I confidence, you can see every
tag here, and the pages have things tagged and organize what's been recently updated. So this
is just a good way, a good overview of all your data sources, what's been updated recently, what's
kind of old summaries of all the sources that we have. It's just a good overview. So next one,
we're also going to the community plugins here, mark slides, and I believe Andre Karpathy himself
talked about this one. I'm going to install
mark slides here. He talked about this one as a enable it for good visualizations.
So in order to use this properly, you just need to add a mark true to the front map matter up here,
you can see it's clicked. And then you need to add these kind of dashes in the markdown file to
separate the slides. But your LM can do that in a second, it doesn't take long. And then you just
click this slideshow preview. And here we go, we got slides based on
the wiki entry here for drawing liquidity. Nothing too fancy, but you get the picture, it's
serves its purpose. These are very quick, just a second to make these little slideshows.
So the next one is Excala draw, it's called. So this is also a community plugin, Excala draw,
it's right here, so you don't even need there we go, install this and enable it. And this is a
drawing tool.
That helps with visualizations. So once this is enabled, you see here new drawing is where you
would start, there's a lot of different ways you can add shapes here, add text. Hello,
you can add in pictures. For this one, I added in this chart, just add in the picture,
and then you can annotate it from there, you can draw on it, you know, you can
add anything you want. And this would be really useful. If you have a chart like
this, and you want to annotate it, and then save it, and it becomes part of your wiki that your,
your agent or your LM can review and base its answers on these kind of annotations that you
have. And the key advantage here over just like static images is that Excala draw drawings are
editable, and they live inside the wiki itself. So it all stays in sync as your knowledge base
expands. Next is going to be charts view. And
this is going to create
active charts that are built based on your notes and data. So let's enable that. And you can see I
had Claude build this analytics page in the wiki. And this gives us a couple different charts, you
have pie charts here, this is showing the confidence in our the wiki analytics itself, pages
by category, you have a nice little charts data, source cover by the teacher, or what source it
was, page results, pop firm mentions. And there's obviously a bunch of different ways. So you can
see the different types of charts you can get here. And this could do a lot of different charts,
line charts, area column, radar, scattered charts, word clouds, there's a lot of different these are
only just a couple start out with. Here you go. I added a couple of different this is the radar
chart, you could see it's pretty nice, based on strategy comparison. And then this kind of word
cloud thing you got.
Seeing which words are most frequently brought up. And then you can have something like this tree map
structure with how the wiki is structured. So there's a lot of different ways you can play around
with this. But it's a nice little visualization. So the next is called mermaid diagrams. And this
is another native Obsidian visualization, you don't need to add any plugins or anything. But you
basically just tell your LM to create them. And you can see here, this is what it kind of looks
like. For our as a decision flowchart.
So you have these
nice little flowcharts tells you when you should take a trade is the week high or low? Yes, no. And
you get something like that. Here's another one over here. So these are nice little visualizations
of everything. And you could save these obviously, and use them separately. Like that. The next is
going to be the MCP server. And you can see Claude's doing some research, there's a couple different
ways you can do it depending on your setup. We're going to be using this MCP vault, I believe, which
works directly on your server. And you can see here, this is going to be the MCP vault, which works
directly on the raw markdown files doesn't require Obsidian to be running, and has a BM 25 search
built in. So pretty easy. There you go. Done. Just took less than a minute. So basically, this MCP
server turns the wiki into an API that any AI can connect to. Before I just had Claude code reading
the files directly and answering nothing else could access access it. But after the MCP, you
could use Claude code, chat GVD, desktop cursor. Since it runs in the background and watches the
wiki folder, it exposes tools like search, read and write. So any AI that speaks MCP, which is
pretty much everyone can use these tools. And the way I have this set up right now, it only works
locally on my PC using these different type of tools and AI tools. But you can deploy it if you
want if you want to host your wiki on a remote MCP server. Say you're working with a lot of different
teams and stuff like that. And you can see here, you can see here, you can see here, you can see here,
you can see here, you can see here, you can see here, you can see here, you can see here, you can see here,
you can see here, you can see here, you can see here, you can see here, you can see here, you can see here,
different people working on the same wiki, you could deploy it like that, and then just use the
MCP server to connect to it through the API. But since this is just a personal wiki, I'm not going
to go into that. So next, we're going to be building this trade journal cross referencing,
which connects the trades to the wikis theory. Like I said, this is specific for mine,
but you can imagine how you can adapt it to whatever your knowledge bases, anything where
you're able to journal your own experiences or data, and then able to cross references with the
theory.
This would be pretty useful. So right now, Claude is building this for me.
It did it very quickly. So this is what we have. So this is the template, the journal template that
we made. And like I said, I'll open source all of this. You can check it out at tombi studio on
GitHub slash LM wiki. And these are the templates. So you would add in your journal, all the details
here. We made a couple examples here, this is a gold short, the entry and everything like
else, the setup. Also built this nice little dashboard here, which has been having your record
and trades by instrument trades by session. So everything this will all
be automatically automatically updated as you add more journal entries.
So this is the one example that we had. For today's journal entry.
So the last one is going to be this flashcard version, which I think is a pretty good idea,
actually, space repetition, you're going to look for that in the community plugins, space repetition,
for flashcards. And you can enable it. So this, the flashcards require a specific format. So
you'll have to have Claude format the page with that to actually breaks down into questions and
answers. But it only took a minute, I did it because all the information is already here.
Claude didn't have to go and search for itself, it only took less than I don't know, 10 seconds or
so. So once you have it in this right format, you can just click on the side here, these cards. And
you can see here, you have a nice little flashcard in this. And this will be spaced repetition. So
what is ICT is optimal trade entry. And has the answer and you can choose to do get it good,
easy, and then I'll repeat in four days, if I didn't get it at all. It's going to repeat soon.
So why does price move according to ICT, it just creates these very easy
flashcards to kind of review the information in the wiki. Now, you can also export this to a CSV
file, and then actually play it in Anki itself. Or if you just want to stay in Obsidian, it might
just be easier. This works fine as a normal flashcard. And you can see here it has tells
you where this came from, right? ICT concepts, market structure and liquidity. So it came from
the whole wiki. And as you continue to build it out, you can add more flashcards to it. So I
thought this was really helpful. And I'll see you in the next video. Bye bye.
This is a fun little feature as well to try to actually learn these concepts and use the
knowledge base to enhance our own human learning. As we learn to use AI tools. Like I said earlier,
this is all available on my GitHub Studio, open source tombi studio, slash LLM dash wiki,
it's going to have everything, it's going to have the basic format, it's not going to have
all my trading data, because you have to put in your own data to get it. But it's gonna have all
the file structures correctly. The cloud file, do you need?
Everything works. instructions about how to get started with this, the directory structure,
and all the enhancements we talked about today, are going to be ready, you're gonna have to
install the plugins yourself. But you'll see the instructions on how to do that here.
And it's all designed for any AI agent just to read this repo and be able to easily recreate
what I did in this video. So give it a look at tombi studio slash LLM dash wiki. And there you go,
we broke
down 10 different ways to kind of enhance or visualize or get more out of your LM wiki
or knowledge base. There's a lot of other ways you can do this. I want to limit it
to 10 here and try to rely on stuff that was mostly inside Obsidian. But you could certainly
build this out yourself and add more features. And really customize it to the way you want to use it.
I definitely think there's a larger need for something like this in a lot of companies and
a lot of institutions.
knowledge base like this would be really helpful. And the way it builds and develops over time,
and actually gets smarter as you ask it more questions. And as you use it more, I think
it's a really cool feature. But that's going to be it for today's video. Please, if you
like this video, please leave a like, please subscribe, please leave a comment, let me
know how you're building out your knowledge bases or what kind of cool visualizations
you found. This is just a couple of the things I found in my research, I thought would be
helpful or interesting. But let me know what you find and what you've been doing. So that's
gonna be it for this video. Thank you for watching.