[프로젝트] Memex — 스스로 자라는 개인 위키

“Obsidian is the IDE. Claude is the programmer. The wiki is the codebase.”

Memex 깃허브 보기

왜 만들었는가

대부분의 “LLM + 문서” 세팅은 질문할 때마다 지식을 새로 만들어낸다. RAG는 청크를 찾고, 모델이 답을 짜깁기하고, 끝나면 아무것도 남지 않는다. 같은 문서를 10번 질의하면 10번을 다시 발견한다.

Memex는 이 흐름을 뒤집는다(inverts this). 소스를 한 번 추가하면 Claude가 읽고, 영속적인 위키에 통합하고, 기존 페이지와의 모순을 표시하고, 인용을 연결하고, 그 결과를 git에 커밋한다. 10번째 질의쯤이면 위키 자체가 합성을 대신 해 준다 — 정리(bookkeeping)는 이미 끝나 있기 때문이다.

기반이 된 아이디어는 두 개다.

• Andrej Karpathy의 LLM Wiki 패턴 — LLM이 일회성 답변기가 아니라 지속적으로 갱신되는 위키의 사서(librarian) 역할을 해야 한다는 제안.
• Vannevar Bush의 1945년 Memex — “associative trail”로 인간 기억을 확장하는 가상의 기계. 이름의 출처.

핵심 패턴

projects/<slug>/    하나의 프로젝트 = 하나의 주제. 완전 격리.
  ├─ raw/           원본 소스. 불변(immutable). 4중 보호.
  │    │
  │    ▼  ingest
  ├─ wiki/          Claude가 유지하는 페이지들.
  │                 인라인 인용 [^src-*], 자동 상호참조,
  │                 모든 변경은 git 커밋.
  ├─ CLAUDE.md      프로젝트별 스키마
  └─ .settings.json 프로젝트별 모델(Opus/Sonnet/Haiku)

• 사람: 소스 큐레이션, 질문, 분석 방향, 프로젝트 경계 설정
• Claude: 요약, 상호참조, 인용, 모순 탐지, 정리 — 선택된 프로젝트 범위 안에서만
• 위키: 각 프로젝트 안에서 독립적으로 누적

사용한 기술

MCP가 노출하는 14개 툴은 read-only(list_pages, read_page, search, stats 등)와 mutating(add_raw_source, create_page, update_page, git_commit)으로 구분된다. 외부 클라이언트(Claude Code, Claude Desktop)가 이 툴들을 호출해 위키를 읽고/쓰고/커밋한다.

관련 개념과 레퍼런스

• Karpathy LLM Wiki: “LLM을 사서로 써라” — 단발성 채팅이 아니라, 모델이 직접 유지보수하는 영속적 노트가 결국 더 가치 있다는 주장. Memex의 직접적 출발점.
• MCP (Model Context Protocol): Anthropic이 공개한, LLM 클라이언트가 외부 도구/리소스에 접근하는 표준. stdio 기반의 서버를 띄우면 Claude Desktop이나 Claude Code가 자동으로 툴을 인식한다.
• Append-only knowledge graph: 위키의 각 페이지가 노드, 인용/링크가 엣지. 모든 변경이 git 커밋이라는 점에서 _content-addressable history_와 닮아 있다.
• Bush, V. (1945). As We May Think. The Atlantic. — Memex의 원전. “associative indexing”으로 인간의 기억을 확장한다는 제안.

어디에 어울리는가

• 한 주제(논문, 회사, 기술 스택)를 장기간 깊게 파야 할 때
• LLM에 매번 같은 자료를 다시 던지는 RAG 비용이 아까울 때
• 자료의 출처와 모순을 추적 가능한 형태로 남겨야 할 때 (git 히스토리)
• 클라우드에 자료를 올리고 싶지 않을 때 (로컬 우선, 텔레메트리 없음)