Claude Code용 LLM Wiki, RAG와 옵시디언을 대체할까

안드레이 카파시의 LLM Wiki가 등장하자 오래된 질문이 다시 떠올랐다. 옵시디언 노트를 RAG로 검색하면 충분한가, 아니면 Claude Code가 지식을 직접 편집하게 해야 하는가. 답은 어느 하나를 대체하기보다 역할을 나누는 데 가깝다.

LLM Wiki는 검색 인덱스가 아니라 편집된 지식층이다

카파시가 2026년 4월 공개한 LLM Wiki는 완성된 앱이 아니라 에이전트에게 전달하는 ‘아이디어 파일’이다. 원문을 검색해 매번 답을 만드는 대신 LLM이 원문을 읽고 마크다운 위키를 계속 고치는 것이 핵심이다.

구조는 세 층이다. 사람이 수집한 원문은 raw/에 보존한다. Claude Code가 만든 요약·개념·인물·비교 문서는 wiki/에 두고, CLAUDE.md에는 폴더 구조와 출처 표기법, 갱신 규칙, 작업 순서를 적는다.

RAG는 질문이 들어오면 관련 청크를 찾아 모델에 전달한다. 2020년 패트릭 루이스 연구진이 제시한 원형도 생성 모델과 외부 비매개 기억을 결합했다. LLM Wiki는 검색할 때가 아니라 자료를 넣을 때 해석과 연결 작업을 미리 수행한다.

둘은 경쟁 제품이라기보다 서로 다른 지연 비용을 택한다. RAG는 수집이 빠른 대신 질문할 때마다 검색과 합성이 필요하다. LLM Wiki는 수집 단계가 무겁지만 반복해서 질문할 때는 이미 정리된 문서를 활용한다.

옵시디언과 Claude Code를 함께 쓰는 구축 순서

가장 단순하게 구현할 때는 벡터 데이터베이스나 MCP 서버가 필요하지 않다. 먼저 옵시디언 Vault 안에 raw/, wiki/, CLAUDE.md를 만든다. 원본은 수정하지 않는다는 규칙도 CLAUDE.md에 명시한다.

자료 한 건을 raw/에 넣고 Claude Code를 Vault 경로에서 실행한다. 공식 문서에 따르면 Claude Code는 코드가 아닌 노트 폴더에서도 파일을 검색하고 편집할 수 있다. 다른 앱에서 바꾼 내용도 다음에 파일을 읽을 때 반영한다.

첫 입력은 구체적이어야 한다. 다음과 같은 작업을 요청할 수 있다.

1. 새 원문을 읽고 wiki/sources/에 출처 요약을 만든다.
2. 기존 wiki/index.md를 확인한다.
3. 관련 개념 페이지를 새로 만들거나 갱신한다.
4. 상충하는 주장은 덮어쓰지 말고 양쪽 출처를 남긴다.
5. 변경 내역을 wiki/log.md에 추가한다.

산출물은 요약 하나로 끝나지 않는다. 한 논문이 모델, 연구자, 평가 방법과 연결된다면 여러 페이지와 역링크가 함께 바뀐다. 옵시디언은 로컬 파일과 링크, 그래프 뷰를 제공하므로 결과를 검토하는 인터페이스가 된다. 지식을 이해하고 쓰는 주체는 Claude Code다.

카파시의 llm-wiki.md는 이 과정을 ingest, query, lint 작업으로 제시한다. 원문을 raw/에 보존하고 wiki/ 문서를 만든 뒤 고아 페이지와 모순을 점검한다. 개인 개발자는 이 구조부터 복제하고 실제 병목이 확인될 때 검색 엔진을 붙일 수 있다.

Claude Code의 기본 메모리와는 저장 대상이 다르다

Claude Code에는 이미 CLAUDE.md와 auto memory가 있다. Anthropic 문서는 새 세션이 빈 컨텍스트로 시작하고 두 기능이 세션 사이의 지식을 옮긴다고 설명한다. CLAUDE.md는 사람이 작성한 규칙이며 auto memory는 Claude가 기록한 선호, 교정, 프로젝트 결정이다.

그러나 두 기능은 연구 자료 전체를 엮는 위키가 아니다. CLAUDE.md는 모든 세션에 필요한 빌드 명령과 코딩 관례를 담기에 적합하다. 공식 권장 분량도 파일당 200줄 미만이다. auto memory의 시작 인덱스 역시 200줄 또는 25KB까지만 자동으로 불러온다.

LLM Wiki는 더 넓은 지식을 필요할 때 파일 도구로 찾아 읽게 한다. Anthropic이 말하는 ‘just in time’ 컨텍스트 전략과 맞닿아 있다. 긴 자료를 전부 프롬프트에 넣지 않고 경로와 인덱스를 따라 필요한 문서만 연다.

세션 연속성도 구분해야 한다. claude --continue는 저장된 대화를 재개하고 auto memory는 일부 학습 내용을 다음 세션으로 옮긴다. LLM Wiki는 대화의 숨은 상태를 복원하지 않는다. 이전 결정이 문서에 기록돼야 다음 세션에서 다시 찾을 수 있다.

토큰 절감보다 검색 정확도와 유지비를 측정해야 한다

LLM Wiki를 토큰 절약 장치로 홍보하면 기대가 쉽게 어긋난다. 위키를 처음 만들거나 갱신할 때도 LLM이 원문을 읽어야 한다. 잘못 검색된 문서가 질문마다 주입되면 오히려 비용과 혼선이 늘 수 있다.

써본 사람들 사이에서는 단순한 폴더와 링크가 복잡한 지식 그래프보다 오래 버틴다는 반응이 있다. 사전 편집된 위키가 반복 탐색을 줄였다는 경험도 나온다. 공개된 대폭 절감 수치는 작업 유형과 모델, 캐시 조건이 달라 일반화하기 어렵다.

평가는 세 지표면 충분하다. 질문에 필요한 페이지가 상위에 잡히는지, 답의 문장마다 원문 근거를 추적할 수 있는지, 새 자료가 기존 판단을 제대로 수정하는지 확인한다. 토큰은 그다음에 비교해야 한다.

특히 코드 구조만 파싱해 함수명과 호출 관계를 모으는 방식은 카파시의 제안과 다르다. LLM Wiki의 가치는 LLM이 자료의 의미를 합성하는 데 있다. 모델을 빼면 저렴해지지만 코드와 결정의 맥락을 얻기 어려울 수 있다.

자료가 커질수록 위키 자체를 의심해야 한다

LLM이 쓴 페이지는 원문이 아니다. 한 번 들어간 오류가 다른 요약에 복제되면 위키 전체가 일관되게 틀릴 수 있다. 그래서 원문과 생성 문서를 분리하고 모든 주장에 출처 링크를 남겨야 한다.

초기에는 index.md와 grep만으로도 충분하다. 카파시는 약 100개 원문과 수백 페이지 정도의 중간 규모에서 이 접근이 작동한다고 설명했다. 범위가 커져 재현율이 떨어지면 BM25, 임베딩 검색, 재순위화를 붙여 RAG와 결합할 수 있다.

Claude Code 사용자가 옵시디언에서 떠날 이유는 없다. 옵시디언은 사람이 결과를 읽고 연결을 검사하는 화면으로 남는다. Claude Code는 편집자, RAG는 대규모 원문 검색기로 배치된다.

LLM Wiki가 유용한지는 멋진 그래프가 아니라 다음 수집 때 드러난다. 새 자료가 들어왔을 때 기존 페이지의 오류와 모순까지 고쳐진다면 지식이 축적된다. 요약 파일만 계속 늘어난다면 검색 가능한 쓰레기 산이 하나 더 생긴 것이다.