옵시디언에 노트는 부지런히 쌓는데, 다시 열어보는 건 몇 개뿐이지 않나요. 그 노트를 클로드 코워크가 직접 읽고 정리하고 연결해, 쌓을수록 똑똑해지는 지식으로 바꾸는 방법이 있습니다.
저 역시 클로드 코워크와 옵시디언으로 자료를 관리하면서 같은 벽에 부딪혔습니다. 리서치한 자료는 계속 쌓이는데, 막상 글을 쓰거나 강의를 준비할 때 그 원천 자료를 어떻게 다시 찾아 참조할지가 매번 숙제였습니다. 새 자료가 들어올 때마다 기존 노트와 연결하고 요약을 정리하는 뒤처리가 사람 손으로는 번거로워, 노트는 쌓이기만 하고 죽은 창고가 되곤 했습니다. 이 글은 그 문제를 푸는 이야기입니다. 옵시디언 볼트를 클로드 코워크가 직접 읽고 정리해, 쌓아 둔 자료를 원천 소스째 다시 꺼내 쓰는 방식, 그것이 LLM 위키입니다. 설명을 풀어가면서 제 경험도 조금씩 꺼내 보겠습니다.
Contents
LLM 위키는 검색이 아니라 누적이다
LLM 위키를 한 줄로 말하면, AI가 내 자료를 읽고 스스로 정리하고 연결해서 관리하는 나만의 위키백과입니다. 새 앱을 깔라는 말이 아닙니다. AI에게 자료 정리를 맡기는 운영 방식입니다. AI 연구자 앤드레이 카파시(Andrej Karpathy)가 2026년 4월 공개했습니다. 사람은 자료를 모으고 질문을 던지는 일만 하고, 요약·연결·정리는 AI가 전담합니다. 1945년 배니버 부시가 상상했던 ‘메멕스'(개인이 모든 지식을 연결해 보관하는 기계)를, 정리를 맡아줄 AI가 등장하면서 비로소 실현한 셈입니다.
자주 쓰는 RAG(검색 증강 생성)와 비교하면 차이가 분명합니다. RAG는 질문이 들어올 때마다 자료 더미에서 관련 조각을 그때그때 찾아옵니다. 미리 정리해 두지 않으니, 여러 문서를 묶어야 하는 질문이면 매번 조각을 새로 꿰맞춥니다. 위키는 자료를 넣는 순간 요약·연결·모순 정리를 끝내 둡니다. 도서관에 비유하면, RAG는 질문할 때마다 서가를 처음부터 뒤지는 사서이고, 위키는 미리 주제별로 분류하고 색인까지 붙여 둔 서가입니다. 한 번 정리해 두고 계속 최신 상태로 유지하는, 쌓일수록 단단해지는 지식입니다.
규모로 나누면 선택이 쉬워집니다. 경계가 분명한 개인 지식, 약 100개 자료 이하라면 위키가 맞습니다. 대규모이거나 실시간이거나 여러 사람이 함께 쓰는 지식이라면 RAG입니다. RAG를 버리라는 뜻이 아닙니다. 작으면 위키, 커지면 위키와 검색을 함께 쓰는 하이브리드입니다.
왜 옵시디언과 코워크인가
핵심 비유는 하나입니다. 옵시디언(Obsidian, 메모를 마크다운 파일로 저장하는 노트 앱)은 작업실, AI는 그 안에서 일하는 작업자, 위키는 작업 결과물입니다. 프로그래머가 코드를 다루듯, AI가 지식을 다룹니다.
코워크(Cowork)는 내 컴퓨터의 파일을 직접 읽고 쓰는 AI 도구입니다. 옵시디언 노트가 평범한 텍스트 파일이라, 따로 연동 작업 없이 코워크가 그대로 읽고 씁니다. 저는 일정 관리부터 글쓰기, 강의 준비, 리서치까지 옵시디언 볼트 하나에서 운영하는데, 코워크가 이 볼트를 통째로 읽고 쓰기 때문에 도구를 옮겨 다닐 일이 없습니다. 일반 챗봇과의 차이는 네 가지입니다. 일반 챗은 그때 올린 파일만 잠깐 보고, 대화가 끝나면 사라지며, 결과가 대화창 글에 그칩니다. 코워크는 내 노트 폴더를 직접 읽고, 노트로 영구 보관하고, 워드·PPT 같은 파일로도 만들어 내고, 노트와 규칙 파일로 맥락을 이어갑니다.
3계층으로 시작한다
세팅은 단순합니다. 폴더 두 개와 파일 하나면 시작합니다.
raw는 불변 원천입니다. AI가 읽기만 하고 수정하지 않는 진실의 출처입니다. wiki는 AI가 전적으로 소유하는 마크다운 페이지로, 요약·개념·비교가 여기 쌓입니다. CLAUDE.md는 스키마이자 계약으로, 페이지 명명·공통 섹션·출처 표기·모순 처리 규칙을 정의합니다.
CLAUDE.md가 핵심입니다. 이 파일이 AI를 규율 있는 위키 관리자로 만듭니다. 처음부터 완성하지 않습니다. 첫 자료를 넣으며 드러난 규칙을 누적해, 위키와 규칙을 함께 키웁니다. 저는 볼트 안에 ‘LLM 위키’ 폴더 하나를 만들어 이 구조를 두고, 따로 있던 리서치 노트 폴더까지 원천 자료로 등록해 두었습니다. 여기에 내용 목차 역할의 index.md와 시간 기록용 log.md를 빈 파일로 둡니다.
Ingest·Query·Lint 세 작업으로 굴린다
운영은 세 작업의 반복입니다.
Ingest는 넣기입니다. 자료를 정독하고, 쓰기 전에 핵심을 먼저 논의하고, 페이지를 작성하고, 관련 페이지에 링크를 걸고, 목차와 기록을 갱신합니다. 자료 한 건이 페이지 10~15개를 건드립니다. 카파시는 한 번에 하나씩 넣고 요약을 직접 확인하는 단건 방식을 권합니다. 한꺼번에 몰아 넣으면 품질 통제가 약해집니다. 저는 리서치 노트를 바로 위키로 올리지 않고, 같은 주제가 세 건 넘게 모이고 다시 쓸 일이 분명할 때만 정식 위키 페이지로 승격합니다.
Query는 끌어내기입니다. 목차를 먼저 읽어 후보를 좁히고, 본문을 정독해 출처와 함께 답을 만듭니다. 핵심은 재편입입니다. 좋은 답과 새로 발견한 연결을 대화 기록에 묻어두지 않고, 새 페이지로 편입해 누적합니다.
Lint는 점검입니다. 모순, 외톨이 페이지, 낡은 주장, 빠진 개념을 주기적으로 찾아 보강합니다. 구조 점검은 자동, 의미 점검은 AI, 시각 점검은 그래프뷰로 나눠 봅니다.
세 작업을 스킬 3종 세트로 고정한다
세 작업을 매번 손으로 지시하면 절차가 흔들립니다. 작업마다 스킬(반복 절차를 고정해 두는 코워크 기능)을 하나씩 붙여 두면 같은 품질로 반복됩니다. 저는 다음 세 가지를 한 묶음으로 씁니다.
첫째, wiki-ingest는 넣기 담당입니다. 리서치 노트나 웹 자료, 메모를 읽어 위키 페이지로 만듭니다. 개념 페이지와 경험 페이지를 나눠 만들고, 출처와 갱신일을 규칙대로 붙이고, 목차와 링크를 자동으로 정리합니다. “이 자료 위키에 넣어줘” 한마디면 페이지가 생기고 연결까지 끝납니다.
둘째, wiki-activate는 활용 담당입니다. 쌓인 위키를 읽어 답을 만들거나, 블로그·강의·책 원고로 풀어냅니다. 사실 이 글도 제 위키에 쌓아 둔 페이지 여섯 개를 wiki-activate로 읽어 작성했습니다. 위키 밖 지식을 섞지 않도록 막는 옵션이 있어, 답을 내 위키 범위 안으로 묶을 수 있습니다.
셋째, wiki-audit는 점검 담당입니다. 위키가 커지면 같은 내용이 겹치거나, 서로 어긋나거나, 오래된 페이지가 생깁니다. 중복·충돌·신선도·구조를 점검해 보고서로 보여주고, 병합이나 삭제 같은 위험한 작업은 확인을 받은 뒤에만 처리합니다.
세 스킬은 Ingest·Query·Lint 세 작업과 그대로 짝을 이룹니다. 넣을 때 wiki-ingest, 꺼내 쓸 때 wiki-activate, 건강을 볼 때 wiki-audit입니다. 작업을 기억해 두지 않아도, 스킬 이름만 부르면 절차가 매번 같게 돌아갑니다.
한 번 정제하면 비용이 사라진다
위키는 저장소가 아니라 정제된 생산 원천입니다. 한 번 정리한 페이지는 블로그·강의·책으로 후크와 문체만 바꿔 분기합니다. 실제로 저는 위키 페이지 하나에서 블로그 글과 강의 슬라이드가 동시에 갈라져 나오는 걸 자주 경험합니다. 그 산출물에서 나온 새 통찰은 다시 위키로 돌아옵니다. 콘텐츠를 만들수록 위키가 자라고, 위키가 자랄수록 다음 콘텐츠가 빨라집니다.
주의할 지점도 분명합니다. AI는 근거 없는 질문에 사실이 아닌 답을 지어낼 때가 있습니다. 자료가 약 5만~10만 토큰을 넘으면 탐색이 어려워집니다. 넣는 자료의 품질이 결과를 좌우합니다. 한 측정에서 위키가 RAG 대비 토큰 약 95% 절감, 응답 약 70배 향상을 보고했지만, 단일 업체 수치이므로 그대로 받아들이기보다 조건을 확인하는 편이 안전합니다.
기준을 옮기면 됩니다. 노트를 더 많이 쌓는 것이 목표가 아닙니다. 쌓은 노트를 AI가 유지하게 만들어, 저장할수록 똑똑해지는 구조로 바꾸는 것입니다.
