LLM Wiki의 적용과 파생

🏷️ 정보 LLM KMS

LLM Wiki는 하나의 제품 이름이 아닙니다. 카파시가 제안한 것은 원본 자료를 바탕으로 LLM이 읽기 좋은 마크다운 위키를 누적해 관리하는 패턴입니다. 그 위에 에이전트 하네스형 볼트, Obsidian 플러그인, 독립형 데스크톱 앱, 도메인 전용 판단 시스템이 서로 다른 문제를 풀기 위해 붙었습니다.

그래서 "LLM Wiki를 도입할까"보다 먼저 정해야 할 질문은 세 가지입니다. 정보는 얼마나 자주 바뀌는가, 답변에 어느 정도의 근거가 필요한가, 시스템이 최종적으로 무엇을 결정해야 하는가입니다.

용도에 따른 구분

첫째는 정보의 변동성입니다. 글쓰기 원칙, 연구의 핵심 개념, 설계 결정의 배경처럼 천천히 바뀌는 지식은 위키가 잘 다룹니다. 서버 주소, 재고, 가격, 판매 수치, CRM 상태처럼 빨리 바뀌는 값은 위키 본문이 아니라 원천 시스템에서 조회해야 합니다.

둘째는 산출물의 성격입니다. "무엇과 무엇이 연결되는가"를 발견하는 일이면 LLM이 만든 개념 페이지와 그래프가 유용합니다. 반면 "이 기획을 진행할까"처럼 비용이 따르는 결정이면, 연결의 그럴듯함보다 데이터 계약과 재현 가능한 계산이 중요합니다.

정보와 산출물	맞는 형태	LLM이 맡을 일	사람이 지켜야 할 경계
느리게 변하는 개인·팀의 원칙	카파시 원안, 에이전트 하네스형 볼트	요약, 교차 연결, 맥락 주입	사실과 개인 의견 구분, 검토일 기록
논문·PDF·웹 클립이 많은 리서치	독립형 LLM Wiki 앱	문서 파싱, 출처 추적, 탐색용 그래프	생성 문서를 원문 증거로 착각하지 않기
기간이 정해진 조사·학습 묶음	출처 고정 노트북형	인용 답변, 브리프, 학습 자료	노트북을 영구 정본으로 키우지 않기
최신 문서를 즉시 찾아 답할 일	검색 우선 RAG형	관련 원문 조각 검색, 인용 답변	검색 결과를 장기 판단으로 자동 승격하지 않기
문서 사이의 숨은 구조·전역 주제	GraphRAG·온톨로지형	엔터티·관계·군집 탐색	자동 추출 관계를 사실 관계로 확정하지 않기
사용자 취향과 진행 중인 작업 상태	에이전트 메모리형	선호·작업 상태의 지속	메모리를 지식의 출처나 감사 로그로 쓰지 않기
이미 쓰는 Obsidian 노트의 탐색성	Obsidian 플러그인형	엔터티 추출, 링크 보완, 대화형 질의	원본 노트와 생성 위키를 분리
시장·운영·기획의 의사결정	도메인 판단형 위키	설명, 보고서 초안, 판단 로그 작성	수치·연결·상태는 결정론 도구가 갱신
여러 도구·조직에 지식을 전달	지식 번들·교환 포맷형	파일 생성과 읽기	포맷을 검색·추론 엔진으로 오해하지 않기
실시간 운영 사실	위키가 아닌 원천 시스템	조회 결과의 설명	위키에 복사해 정본처럼 쓰지 않기

1. 카파시 원안: 작은 정본을 오래 쓰는 위키

카파시의 원안은 raw/ 원본, LLM이 유지하는 wiki/, 규칙을 담은 CLAUDE.md를 분리합니다. 새 소스를 ingest하고, 위키로 질의하고, lint로 낡은 주장과 모순을 점검하는 구조입니다. 복잡한 검색 인프라보다 사람이 읽을 수 있는 합성 문서를 먼저 만든다는 점이 핵심입니다.

이 형태는 개인의 글쓰기 원칙, 반복되는 프로젝트 맥락, 팀의 설계 결정 배경처럼 원본 수가 많지 않고 변화가 느린 지식에 맞습니다. 에이전트가 작업을 시작할 때마다 같은 설명을 다시 듣지 않아도 되기 때문입니다.

반대로 수시로 달라지는 운영 정보에는 맞지 않습니다. 위키가 사실을 복제하는 순간 원천보다 늦어지고, 틀린 자신감이 생깁니다. 이 경우 위키에는 "어디를 조회해야 하는가"와 "왜 그렇게 판단하는가"를 남기고, 현재 값은 원천에서 읽어야 합니다.

2. 에이전트 하네스형 볼트: AutoVault에 가까운 방식

에이전트 하네스형은 별도 위키 제품보다 파일 시스템과 작업 규칙을 먼저 둡니다. CLAUDE.md에는 폴더 구조, 작성 규칙, 승인 경계, 반복 워크플로를 적고, 스킬과 도구가 클리핑, 초안, 발행, 검토를 연결합니다.

이 방식의 장점은 지식 관리가 별도 취미가 아니라 실제 작업의 부산물이 된다는 점입니다. 글을 쓰고, 논문을 읽고, 피드백을 받을 때 결과가 볼트에 남습니다. 개인 연구, 블로그 운영, 교육 콘텐츠, 장기 프로젝트의 작업 맥락에 특히 적합합니다.

대신 하네스가 약하면 에이전트가 파일을 잘못 고치거나, 그럴듯한 요약을 사실처럼 누적할 수 있습니다. 쓰기 권한을 좁히고, 원본과 산출물을 분리하며, 사람이 검토할 지점을 명시해야 합니다. 하네스는 자동화 기능이 아니라 신뢰 경계를 설계하는 장치입니다.

3. Obsidian 플러그인형: 기존 노트에 탐색 레이어를 얹는 방식

Karpathy LLM Wiki 같은 Obsidian 플러그인은 이미 쌓인 노트를 읽어 엔터티·개념 페이지, 양방향 링크, 인덱스, 질의 화면을 만듭니다. 개인 볼트에서 "예전에 어디에 적었지"를 해결하려는 목적에 가장 잘 맞습니다.

이 유형은 Obsidian을 계속 주 작업 화면으로 쓰는 사람에게 유리합니다. 별도 앱으로 옮기지 않고도 노트, 생성 위키, 그래프, 질의를 한곳에서 다룰 수 있습니다. 반면 LLM이 만든 링크의 의미는 기본적으로 의미적 연관성입니다. 그것이 업무 우선순위나 시장성까지 뜻하지는 않습니다.

따라서 노트 전체를 바로 자동 유지보수 대상으로 삼기보다, 원본 노트는 보존하고 생성 결과를 별도 wiki/ 폴더에 격리하는 것이 안전합니다. 플러그인의 링크는 탐색 후보로 쓰고, 중요한 결론은 원문과 함께 다시 확인합니다.

4. 독립형 LLM Wiki 앱: 리서치 코퍼스를 컴파일하는 방식

nashsu/llm_wiki 같은 독립형 앱은 카파시의 3층 구조를 제품으로 구현한 경우입니다. PDF·Office 문서·이미지·웹 클립을 가져와 출처가 연결된 위키를 만들고, 문서 해시 캐시, 작업 큐, 그래프 분석, 리뷰 큐, 선택적 벡터 검색, MCP 서버까지 제공합니다.

이 유형은 논문, 보고서, 슬라이드, 웹 자료가 한꺼번에 쌓이는 리서치 작업에 잘 맞습니다. 문서의 원래 폴더 구조를 유지하고, 같은 파일을 반복 처리하지 않으며, 연결이 약한 주제와 출처를 찾아볼 수 있습니다. 문서 형식이 다양할수록 일반 Obsidian 플러그인보다 이점이 큽니다.

그러나 이 앱이 만든 엔터티 페이지와 그래프 통찰은 탐색 도구입니다. 출처 연결이 있어도 생성된 문장이 원문 검증을 대신하지는 않습니다. 자동 웹 리서치와 자동 ingest를 처음부터 켜면, 유용한 원문보다 요약과 연결이 더 빠르게 늘어날 수 있습니다. 작은 코퍼스에서 수동 ingest로 시작하는 편이 낫습니다.

5. 검색 우선 RAG: 합성보다 최신 원문이 중요한 경우

전통적인 RAG는 위키를 미리 쓰기보다 질문이 들어올 때 관련 문서 조각을 검색해 답변에 넣습니다. Smart Connections는 Obsidian 노트의 임베딩 인덱스를 갱신해 유사 노트를 보여주는 개인용 형태이고, RAGFlow는 복잡한 문서를 파싱해 검색·에이전트용 컨텍스트를 만드는 서비스형 엔진입니다.

이 유형은 최신 정책, 방대한 제품 문서, 자주 바뀌는 고객 지원 문서처럼 "지금 원문에 무엇이 쓰여 있는가"가 중요한 경우에 맞습니다. 수백 페이지의 위키를 업데이트하는 것보다 원문을 다시 검색하는 편이 더 정확합니다.

대신 검색 결과는 질문마다 달라지고, 시스템이 무엇을 배웠는지 장기적으로 축적하지는 않습니다. 반복되는 설계 결정, 개인의 관점, 주제의 변화 이력처럼 시간이 지날수록 더 좋은 합성이 필요한 지식에는 카파시형 위키나 판단 로그가 낫습니다.

6. GraphRAG와 온톨로지: 관계 자체가 질문의 대상인 경우

GraphRAG는 문서에서 엔터티와 관계를 뽑아 그래프를 만들고, 서로 가까운 엔터티를 군집화해 커뮤니티 요약을 만듭니다. Microsoft GraphRAG의 전역 질의는 바로 이 커뮤니티 보고서를 활용합니다. "이 코퍼스 전체에서 반복되는 쟁점은 무엇인가", "두 분야를 잇는 다리는 무엇인가" 같은 질문에 강합니다.

온톨로지형은 출발점이 반대입니다. GraphRAG가 문서에서 관계를 발견한다면, 온톨로지형은 사람이나 조직이 먼저 허용할 타입과 관계를 정합니다. 예를 들어 출판 시장에서는 책, 저자, 시리즈, 독자군, 경쟁서를 구분하고, 어떤 관계가 유효한지 미리 정의합니다. 반복되는 업무 질의와 엄격한 데이터 결합이 많다면 이 편이 더 적합합니다.

둘은 경쟁하지 않습니다. GraphRAG는 탐색과 가설 생성에, 온톨로지는 정해진 업무 개체와 규칙을 지키는 데 맞습니다. 다만 자동 추출 그래프의 화살표는 관계 후보일 뿐입니다. 계약, 인과, 소유, 최신 상태 같은 강한 관계는 원천 데이터나 사람이 확정해야 합니다.

7. 에이전트 메모리: 사람을 기억하는 방식

에이전트 메모리는 문서를 위한 위키가 아니라, 에이전트가 다음 대화에서도 같은 사람과 일을 이어가기 위한 상태층입니다. Letta의 메모리 블록은 에이전트의 컨텍스트에 계속 보이는 구조화된 영역이고, Mem0 같은 시스템은 대화에서 장기 기억 후보를 골라 저장·검색합니다.

잘 맞는 내용은 글쓰기 톤, 승인 권한, 선호 도구, 진행 중인 프로젝트의 다음 작업, 자주 반복되는 제약입니다. AutoVault의 스타일 규칙과 작업 지시는 이 층과 가깝습니다.

논문 주장, 시장 수치, 계약 조건까지 메모리에 넣는 것은 좋지 않습니다. 메모리는 짧고 수정 가능해야 하며, 출처를 재검토해야 하는 지식은 파일·데이터베이스·티켓 같은 정본에 남아야 합니다. 메모리는 "어떻게 일할까"를 기억하고, 위키와 원천은 "무엇이 사실인가"를 보관합니다.

8. 출처 고정 노트북: 한 프로젝트를 깊게 읽는 방식

NotebookLM 같은 출처 고정 노트북은 영구 위키보다 연구용 바인더에 가깝습니다. 선택한 PDF, 웹 페이지, 동영상, 문서만 소스로 넣고, 답변의 인용을 해당 원문 위치로 되돌려 줍니다. 브리프, 학습 가이드, 오디오 개요처럼 같은 자료 묶음을 여러 방식으로 소비하는 데 강합니다.

이 방식은 특정 강연 준비, 한 권의 책, 한 건의 기획 조사, 팀의 분기 전략처럼 시작과 끝이 있는 리서치에 적합합니다. 볼트 전체의 오래된 문서와 새 문서를 한꺼번에 섞지 않으므로, 범위를 통제하고 검증하기 쉽습니다.

노트북을 회사나 개인의 영구 기억으로 쓰는 것은 피해야 합니다. 자료 묶음이 끝나면, 검토된 결론과 핵심 인용만 장기 위키나 보고서로 옮기는 편이 낫습니다. 노트북은 연구실이고, 위키는 정리된 서가입니다.

9. 지식 번들·교환 포맷: 지식을 옮길 수 있게 만드는 방식

OKF(Open Knowledge Format)는 LLM Wiki를 실행하는 제품이 아니라, 서로 다른 에이전트와 도구가 같은 지식 묶음을 읽을 수 있게 만드는 최소 규약입니다. Markdown 파일, YAML frontmatter, 선택적인 index.md와 log.md만으로 지식 번들을 만들며, 검색 엔진이나 데이터베이스를 강제하지 않습니다.

이 유형은 한 도구에 종속되지 않고 지식을 Git 저장소, Obsidian, 에이전트, 데이터 카탈로그 사이에 옮겨야 할 때 유용합니다. 특히 여러 팀이 같은 개념을 다른 도구에서 소비하거나, 시간이 지나도 지식의 구조를 보존해야 할 때 가치가 있습니다.

포맷은 답을 찾아주지 않습니다. 좋은 frontmatter와 링크 규약은 이식성만 보장합니다. 검색, 그래프, 메모리, 계산은 그 위에 목적에 맞게 따로 붙여야 합니다.

10. 도메인 판단형 위키: 연결보다 판정이 중요한 경우

기획·마케팅처럼 실제 돈과 일정이 걸린 분야에서는 일반 LLM Wiki만으로 부족합니다. 여기서는 책, 경쟁사, 고객, 판매, 가격 같은 데이터가 "관련 있어 보인다"가 아니라 정해진 기준으로 연결돼야 합니다.

이 유형은 원천 데이터, 결정론 도구, 사람이 읽는 마크다운을 나눕니다. 예를 들어 판매 시계열은 데이터 파일에 두고, 스크립트가 변화율·비교군·커버리지를 다시 계산하며, 위키에는 날짜가 붙은 판단과 그 근거만 남깁니다. 자사 커버리지, 경쟁만 존재하는 영역, 실제 공백도 같은 규칙으로 구분할 수 있습니다.

LLM은 여기서 사라지지 않습니다. 시장 책의 맥락을 읽고, 새 기획의 질문을 만들고, 계산 결과를 설명하고, 결론을 날짜 로그로 정리하는 역할을 합니다. 다만 숫자와 상태를 LLM이 자유롭게 다시 쓰지 않도록 하는 것이 핵심입니다.

같은 재료를 여러 층에서 쓰는 구조

가장 현실적인 구성은 하나의 거대한 위키가 아니라 층을 나누는 것입니다.

원문 PDF·웹 클립·회의 메모·운영 데이터
        ↓
노트북·RAG·GraphRAG·리서치 LLM Wiki
문서 탐색, 관계 후보, 출처 추적
        ↓  검토된 요약·인용·가설만 전달
도메인 판단 위키
원천 데이터, 결정론 계산, 날짜가 붙은 결정
        ↓
보고서·기획서·콘텐츠

에이전트 메모리 ── 작업 방식·선호·다음 행동만 유지
OKF 같은 포맷 ───── 각 층의 지식을 도구 밖으로 옮길 수 있게 함

앞단의 리서치 도구는 넓게 읽고 연결을 제안합니다. 뒷단의 판단 위키는 좁게 검증하고 결정합니다. 리서치 위키의 생성 페이지를 그대로 결정 시스템의 정본으로 옮기지 않는 것이 두 층을 함께 쓰는 조건입니다.

AutoVault에 맞는 조합

AutoVault는 이미 에이전트 하네스형 볼트로 출발했습니다. 따라서 볼트 전체에 또 하나의 자동 위키를 덮는 것보다 역할을 나누는 편이 낫습니다.

블로그 문체, 폴더 규칙, 발행 절차는 CLAUDE.md와 스킬에 둡니다. 이것은 에이전트 메모리와 하네스의 역할입니다.
논문·웹 클립·영상 대본처럼 특정 주제의 자료가 한꺼번에 생기면, 출처 고정 노트북이나 독립형 LLM Wiki로 짧게 조사합니다.
Obsidian 전체의 "비슷한 노트 찾기"가 필요할 때만 임베딩 기반 플러그인을 보조로 씁니다. 생성된 연결은 초안입니다.
게시할 글과 장기 노트에는 검토된 결론, 원문 링크, 날짜만 남깁니다. 이것이 장기 위키의 정본입니다.

이 조합에서는 한 도구가 모든 것을 기억하려 하지 않습니다. 하네스는 일을 안전하게 만들고, 노트북과 RAG는 원문을 찾게 하며, LLM Wiki와 GraphRAG는 관계를 제안하고, 사람이 검토한 파일과 데이터가 결론을 보존합니다.

도입 순서

처음부터 볼트 전체를 ingest하지 않는 편이 좋습니다. 특정 주제의 PDF·웹 클립 20~30개로 작은 프로젝트를 만들고, 다음 세 질문에 답하는지 확인합니다.

원문을 다시 찾기 어려웠던 질문에 출처와 함께 답하는가
사람이 놓친 연결을 하나 이상 발견하는가
생성 페이지가 원문보다 더 많아져 관리 부담을 만들지는 않는가

세 질문에 모두 긍정이면 리서치 위키를 넓힐 가치가 있습니다. 반대로 최종 판단의 근거가 수치·정책·현행 시스템에 있다면, LLM Wiki는 정본이 아니라 탐색 보조 도구로만 두는 것이 맞습니다.

참고: Karpathy llm-wiki gist / Karpathy LLM Wiki Obsidian 플러그인 / nashsu/llm_wiki / Microsoft GraphRAG / RAGFlow / Smart Connections / Letta 메모리 블록 / Mem0 / NotebookLM 도움말 / Open Knowledge Format