llm-wiki: Karpathy의 방법론으로 흩어진 정보를 지식 그래프로 키우는 에이전트 스킬

읽을거리&정보공유
, , , , , ,
1

llm-wiki: Karpathy의 방법론으로 흩어진 정보를 지식 그래프로 키우는 에이전트 스킬
llm-wiki: Karpathy의 방법론으로 흩어진 정보를 지식 그래프로 키우는 에이전트 스킬1536×1024 255 KB

llm-wiki 소개

논문, 블로그 글, 트윗, 메모처럼 매일 접하는 정보는 대개 한 번 읽고 흩어집니다. 필요할 때마다 다시 검색하고 같은 자료를 또 읽지만, 정작 그 사이의 연결은 머릿속에만 남습니다. llm-wiki는 이런 파편화된 정보를 한 번 정제해 두고 계속 이어 붙이는 개인 지식 베이스로 바꾸는 에이전트 스킬입니다. 핵심 차이는 같은 질문에 매번 처음부터 답을 만들어 내지 않고, 지식을 한 번 컴파일해 지속적으로 유지 한다는 점입니다.

이 스킬은 Andrej Karpathy가 제안한 llm-wiki 방법론을 바탕으로 합니다. 자료를 받아 분석한 뒤, 엔티티 페이지·주제 페이지·출처 요약을 자동으로 생성하고 [[양방향 링크]] 로 서로 연결합니다. 결과물은 모두 로컬 마크다운이라 Obsidian 에서 그대로 열 수 있고, 별도의 인터랙티브 지식 그래프 HTML 로도 탐색할 수 있습니다.

llm-wiki 는 특정 도구에 묶이지 않고 Claude Code, Codex, OpenClaw, Hermes 등 여러 에이전트 플랫폼에서 동작합니다. 설치 후에는 "지식 베이스를 초기화해줘", "이 글을 정리해줘: " 처럼 자연어로 지시하면 스킬이 수집·분석·정리·연결을 대신 수행합니다.

llm-wiki가 지식을 쌓는 방식

llm-wiki가 지식을 쌓는 4단계 파이프라인 다이어그램
llm-wiki가 지식을 쌓는 4단계 파이프라인 다이어그램1536×1024 253 KB

자료를 받아들이는 과정은 두 단계로 나뉩니다. 먼저 내용을 분석하고, 그 결과를 바탕으로 페이지를 생성합니다. 긴 글은 사고를 이어 가는 방식으로 처리하며, 스크립트가 분석 결과의 형식을 자동 검증하기 때문에 성능이 약한 모델을 써도 깨진 데이터가 만들어지지 않도록 설계되어 있습니다. 또한 URL 도메인에 따라 가장 적합한 추출 방식을 자동으로 고릅니다.

생성된 위키 페이지에는 사실의 출처를 구분하는 신뢰도 표시 가 붙습니다. EXTRACTED(원문에서 추출), INFERRED(추론), AMBIGUOUS(모호), UNVERIFIED(미검증)로 표기되어, 어떤 내용이 검증이 필요한지 한눈에 알 수 있습니다. 같은 자료를 중복 처리하지 않도록 SHA256 기반 중복 제거와 쓰기 통과(write-through) 캐시, 자가 복구 안전망도 갖추고 있습니다.

지식 베이스가 커지면 일관성 관리가 중요해집니다. llm-wiki 는 고아 페이지, 깨진 링크, 인덱스 불일치를 탐지하는 상태 점검 스크립트를 제공하며, AI 수준의 모순·교차 참조 검사도 수행합니다. 가치 있는 대화를 그대로 지식 베이스 페이지로 만드는 대화 결정화(Conversation Crystallization) 기능과, 세션마다 에이전트가 지식 베이스를 자동으로 인식하게 하는 SessionStart 훅 기반 컨텍스트 주입도 포함되어 있습니다.

llm-wiki의 디지털 풍경 그래프

llm-wiki 의 특징적인 결과물은 자체 완결형 HTML 로 만들어지는 디지털 풍경 그래프(Digital Landscape Graph) 입니다. 동양적 편집 디자인의 3단 레이아웃 위에 노드들이 배치되며, 검색, 커뮤니티 범례, 포커스 필터, 계층화된 노드 표현, 호버 미리보기, 클릭 후 읽기, Shift 다중 선택, 캔버스 확대·축소, 미니맵 내비게이션이 모두 ** 오프라인에서** 동작합니다. HTML 파일을 더블클릭하면 브라우저에서 바로 지식 그래프를 둘러볼 수 있습니다.

llm-wiki가 지원하는 자료와 플랫폼

지원하는 입력 자료는 다음과 같습니다.

분류 자료 방식
핵심 PDF, Markdown, 텍스트, HTML 외부 의존성 없이 직접 수집
선택 웹 글, X(트위터), 위챗, 유튜브, 즈후 어댑터로 자동 추출, 실패 시 수동 대체
수동 샤오훙수 내용을 직접 붙여넣기

선택 어댑터는 설치 시 --with-optional-adapters 플래그로 활성화하며, 위챗 추출에는 uv, 웹 추출에는 bun 또는 npm, 인증이 필요한 세션에는 Chrome 디버그 모드(포트 9222)가 필요합니다. 플랫폼별 진입 문서는 저장소의 platforms/ 디렉토리에 정리되어 있습니다.

llm-wiki 설치 및 사용법

저장소 링크를 에이전트에게 주고 스스로 설치하게 하거나, install.sh 를 직접 실행합니다.

# Claude Code
bash install.sh --platform claude

# Codex
bash install.sh --platform codex

# OpenClaw
bash install.sh --platform openclaw

# Hermes
bash install.sh --platform hermes

기본 설치 시 핵심 파이프라인만 포함되고, 선택 추출기는 명시적으로 켤 때만 추가됩니다. 이미 설치한 경우 저장소 디렉토리에서 bash install.sh --upgrade 로 갱신할 수 있으며, Claude Code 기본 설치에서는 /llm-wiki-upgrade 명령도 사용할 수 있습니다. 핵심 기능을 쓰려면 에이전트가 셸 명령을 실행하고 로컬 파일을 읽고 쓸 수 있어야 합니다.

:github: llm-wiki 프로젝트 GitHub 저장소

더 읽어보기



이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다. :hugs:

:pytorch:파이토치 한국 사용자 모임:south_korea:이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일:love_letter:로 보내드립니다!
텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다. :smiley:

:wrapped_gift: 아래:down_right_arrow:쪽에 좋아요:+1:를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~ :star_struck:

2개의 좋아요
2

이거 실제로 구현하고 활용까지 해보신분 있을까요? 말만 들었을때는 좋아보였는데, 막상 구현하고 나니까 검색 속도는 당연히 기존의 방식들에 비해 느릴 수밖에 없는 구조이고, 위키 페이지에 내용이 누락되는 경우가 너무 많으며, 그럴 경우 결국 원본 페이지를 봐야해서 LLM wiki 자체의 필요성에 대한 의심이 계속 드네요. 정확성 자체는 좋은데, 그걸 위해 속도를 비정상적으로 포기해야해요. 저만 그런걸까요?

2개의 좋아요
3

저는 뉴스 스크랩 Knowledge Base 용도로 잘 쓰고 있습니다 샘플 Wiki 페이지와 함께 Github에 공개해 두었으니 필요하시면 참고하세요~ GitHub - alfadur7/llm-wiki-newsroom: An LLM-maintained knowledge wiki run by a multi-agent "newsroom" — local-first, API-key-free, a structured alternative to RAG. · GitHub

1개의 좋아요
4

말씀하신게 맞습니다. 따라서 외국 형님들 자료를 찾아보시면 BM25나 Vector로 검색속도를 업하려는 시도가 많이 보이실겁니다.
다들 LLM wiki관련해서 카파시가 얘기한것중에 언급이 덜한게 있는데 바로 이것을 수행하는 qmd입니다. 원문에 qmd라고 검색해보시면 찾아보실수있습니다.
지식 graph 구축은 특히 옵시디언 뷰그래프가지고 어그로를 끄는데 실제로 데이터가 많이 늘면 아무짝에 쓸모없는 예쁜 쓰레기에 불과합니다. qmd 기반의 구축으로 벡터 검색을 도입해야 데이터가 쌓이더라도 적당한 토큰 소모량으로 빠른 검색이 가능해지죠. qmd 검색이 기본적으로 한국어에 약하다는 공격을 받는데 임베딩모델을 qwen으로 바꾸거나 qmd대신 kqmd를 쓰면 어느정도 해결이 될것같습니다.

2개의 좋아요
5

ai 들은 bm25나 벡터DB 까지만 언급했었는데, qmd는 처음 보네요 감사합니다 시도해보겠습니다

6

카파시 원문에 optional에 언급되었어요. qmd가 sqlite에 bm25 , vector 결과물 찾고 저장해줍니다.
처음에는 좀 헉했습니다. 기본값은 0.3B짜리 임베딩 모델을 받는데, qwen으로 바꾸면 0.6B모델이고 이걸 다운받아서 로컬서 임베딩해줍니다. 임베딩에 큰 지식이 없어서 처음에는 당황했는데 이정도는 로컬로도 충분히 다 하네요.

1개의 좋아요
7

QMD에 대한 글 영업하고 갑니다 :dashing_away::dashing_away:

2개의 좋아요
8

실제로 둘 다 구현해서 개인 볼트에 몇 달째 굴리고 있는데, 겪으신 것과 정확히 같은 벽에 부딪혔습니다. 위키 페이지 누락 때문에 결국 원본으로 돌아가게 되더군요. 그래서 저는 위키를 "내용 저장소"에서 "지도"로 강등시켰습니다 — 자동 생성 인덱스는 길찾기(어느 노트에 뭐가 있는지) 전용으로 두고, 내용 검색은 별도의 하이브리드 RAG(BM25+벡터+재정렬)에 맡겼습니다. 이렇게 분업하니 recall@5 93%가 나왔고, 위키 누락은 문제가 아니게 됐습니다. 어차피 지도에는 전문이 없어도 되니까요.

속도는 말씀대로 포기하는 게 맞다고 봤는데, 재정렬까지 로컬에서 돌려도 질문당 1회라 참을 만했습니다. 오히려 제게 더 아픈 건 속도가 아니라 "없는 답" 문제였습니다 — 볼트에 답이 없는 질문 10개를 던지면 10개 전부 아무 노트나 근거로 물고 나왔고, 재정렬 점수 컷을 넣고서야 잡혔습니다.

하나 조심하실 함정: 자동 생성한 인덱스 파일을 검색 색인에 같이 넣으면, 검색이 원본 대신 목록 파일을 찾아오는 메아리가 생깁니다. 인덱스는 색인에서 빼야 합니다. 결론적으로 저는 "위키 vs RAG"가 아니라 위키=항해, RAG=회수로 역할을 나눈 뒤에야 둘 다 쓸모가 생겼습니다.

2개의 좋아요
9

좋은 경험 공유 감사합니다. 지도로 강등시킨다는 아이디어는 좋아보입니다. 다만 한가지가 애매하다면, 사실 LLM Wiki가 처음 나오게 된 이유가 여러 문서를 읽고 형성된 누적된 이해를 또다른 문서로 저장하여 종합 관계를 매번 추론하지 않고 위키만 읽어도 해결되도록 하는 것으로 알고 있습니다. 제가 생각이 짧아서 잘은 모르겠지만, 지도로만 사용한다면 정통적인 검색 알고리즘들에 비해 메리트가 없어보일지도 모르겠다는 생각이 들기는 합니다.

10

말씀하신 지적이 정확합니다. 제가 "지도"라는 단어를 목차 수준으로 들리게 썼네요. 제가 뺀 건 위키의 종합 기능이 아니라 회수 대상 자격입니다.

위키가 원래 하던 일은 두 가지가 섞여 있었습니다.

  1. 여러 노트를 읽고 형성된 누적 이해를 압축해 저장하는 것
  2. 질문이 들어왔을 때 실제로 읽히는 텍스트가 되는 것.

제 볼트에서 문제를 일으킨 건 [2] 뿐이었습니다. 위키 페이지는 본질적으로 손실 압축본인데, 그게 동시에 검색 타깃이면 손실이 조용해집니다. 빠진 내용이 있다는 신호 자체가 안 나오고, 요약문은 항상 그럴듯하게 온토픽이라 '없는 답' 문제도 같이 악화됩니다. 그래서 위키에는 누적 이해를 그대로 남기되(관계·주장·왜 그렇게 결론냈는지), 근거 문장은 원본에서 가져오게 분리했습니다.

말씀하신 메리트도 그 남긴 쪽에 그대로 붙어 있습니다. BM25든 벡터든 결국 어딘가에 연속된 텍스트로 존재하는 것만 회수합니다. 그런데 "A 노트의 이 증상과 B 노트의 이 결정은 같은 원인의 다른 얼굴이다" 같은 문장은 어느 원본에도 없습니다. 이건 전통 검색이 구조적으로 못 가져오는 정보고, 위키만 갖고 있습니다. 제 인덱스 페이지에는 링크만이 아니라 이런 관계 문장이 들어갑니다. 질문마다 종합 추론을 다시 돌리지 않는다는 원래 목적도 여기서 유지됩니다.

실제 흐름은 이렇습니다. 질문 → 위키에서 프레임(무엇과 무엇이 얽혀 있는가) + 후보 노트 집합 → 그 집합에 RAG를 걸어 원문 회수 → 답변 근거는 원문 인용. 즉 위키를 추론 결과 캐시로 취급하고, 캐시는 항상 provenance를 달아 원본으로 검증받게 한 겁니다. 이렇게 안 하면 노트가 바뀌었을 때 위키가 조용히 낡는데, 그걸 알려주는 신호가 없다는 게 제가 겪은 가장 큰 위험이었습니다. 정리하면 위키는 여전히 "종합된 이해"를 저장합니다. 다만 그 이해가 답변의 최종 근거가 아니라 회수의 출발점이 되도록 역할을 한 칸 옮긴 것에 가깝습니다.

2개의 좋아요
11

깊은 내용 감사합니다. 제가 단편적으로만 이해했었네요. 아직 프로젝트 개선 중에 있었는데, 꼭 시도해봐야겠네요 ㅎㅎ

1개의 좋아요