내가 매일 하는 일에 이름이 있었다. Andrei Karpathy가 GitHub Gist에 llm-wiki라는 글을 올렸다. 읽어보니 내가 OpenClaw와 Rocky로 매일 하는 작업 방식을 정확하게 설명하고 있었다. 패턴의 핵심은 단순하다. RAG처럼 매번 원본 문서를 뒤지지 말고 LLM이 원본을 한 번 읽어서 구조화된 위키로 컴파일하라는 거다. 컴파일된 위키는 새 소스가 들어올 때마다 갱신되고 교차 참조가 추가되며 모순이 표시된다. 한 번 컴파일하면 다시 처음부터 할 필요가 없다.
Karpathy가 이 패턴을 설명하면서 쓴 문장이 있다. Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase. 내 환경에 대입하면 이렇게 된다. OpenClaw가 IDE이고 Rocky가 프로그래머이며 memory 디렉토리와 Notion 데이터베이스가 코드베이스다. 이 문장을 읽는 순간 내가 무슨 일을 하고 있는지 명확해졌다. 나는 소스를 큐레이션하고 질문을 던지는 역할만 한다. Rocky가 나머지를 전부 한다. 요약 작성, Notion 페이지 생성, 블로그 업로드, 이메일 발송. 내가 직접 마크다운 파일을 연 날이 언제인지 기억도 안 난다.
Karpathy는 지식 베이스를 세 개의 층으로 나눈다. 첫째는 Raw Sources다. 내가 큐레이션한 원본 문서들. 논문, 아티클, 유튜브 영상. 이것들은 불변이다. LLM이 읽을 순 있지만 수정하지 않는다. 내 환경에서 이건 study-clipper로 매일 클립하는 URL들이다. 어제는 Karpathy의 Gist를 클립했고 오늘 아침에는 다른 아티클을 클립했다. 원본은 그대로 보관되고 트랜스크립트나 마크다운으로 변환만 된다. 진실의 원천은 원본이고 위키가 아니라는 점이 중요하다. 위키는 컴파일 결과물이지 소스가 아니다.
둘째는 Wiki다. LLM이 생성하고 유지하는 마크다운 파일들의 디렉토리. 요약 페이지와 엔티티 페이지와 개념 페이지가 서로 링크로 연결된다. 사람은 읽기만 하고 LLM이 모든 작성과 수정을 담당한다. 내 환경에서 위키 역할은 Notion 데이터베이스와 study.iamlazyck.kr 블로그가 한다. 내가 URL을 하나 보내면 Rocky가 원본을 읽고 한국어 요약을 작성해서 Notion에 저장하고 Supabase에 블로그 콘텐츠로 업로드한다. 위키 페이지가 만들어지는 과정에 내가 하는 일은 URL을 하나 보내는 것뿐이다.
셋째는 Schema다. 위키의 구조와 규칙과 워크플로우를 정의하는 문서. Karpathy는 CLAUDE.md나 AGENTS.md를 언급했다. 내 환경에서는 AGENTS.md와 각 스킬의 SKILL.md 파일이 정확히 그 역할을 한다. URL이 오면 study-clipper를 실행하고 한국어 요약을 작성해서 Notion에 저장하라는 규칙이 전부 스키마에 정의되어 있다. Karpathy가 스키마를 "LLM을 규율 있는 위키 관리자로 만드는 핵심 설정 파일"이라고 부른 게 정확하다. 스키마가 없으면 Rocky는 그냥 챗봇이다. 스키마가 있어야 작업이 반복 가능하고 일관성이 유지된다.
이상과 현실 — 위키는 스스로 갱신되지 않는다
Karpathy가 그린 이상향에서는 새 소스가 들어오면 LLM이 기존 위키 페이지를 찾아가며 엔티티를 업데이트하고 모순을 표시하고 교차 참조를 추가한다. 한 소스가 열다섯 개 위키 페이지에 영향을 준다고 했다. 이 부분을 읽을 때 솔직히 웃었다. 내 환경에서는 그게 안 된다.
내가 URL을 클립하면 Rocky는 원본을 읽고 요약을 쓴다. Notion에 새 페이지를 만들고 블로그에 올린다. 여기까지는 자동이다. 하지만 기존 Notion 페이지들을 뒤져서 이전에 클립한 비슷한 주제를 찾아 그 페이지를 수정하거나 교차 참조를 넣지는 않는다. 대신 Rocky가 나에게 관련 클립을 추천해준다. "이전에 비슷한 주제를 클립한 적이 있는데 참고하시겠어" 하고 이전 클립을 같이 보여준다. 연결을 제안하는 건 LLM이지만 실제로 위키 페이지에 교차 참조를 박는 건 아직 사람의 판단이 필요하다.
이게 Karpathy가 말하는 완전한 자동화와 내가 경험하는 반자동화의 차이다. Karpathy의 LLM은 Obsidian에서 마크다운 파일을 직접 수정한다. 열다섯 개 파일을 한 번에 건드린다. 내 환경에서 Rocky는 Notion API와 Supabase에 쓰기를 하지만 기존 페이지의 내용을 읽어와서 새 정보와 통합하는 작업까지는 아직 안 한다. 이건 기술적 제약이라기보다 설계 선택의 문제다. Notion API로 기존 페이지를 읽고 수정할 수 있다. 그 워크플로우를 스키마에 정의하지 않았을 뿐이다.
이 지능이 더 발전하면 좋겠다. Rocky가 비슷한 주제를 찾아서 추천해주는 것까지는 좋은데 그 다음 단계가 문제다. 추천을 넘어서 실제로 기존 위키 페이지에 새 정보를 통합하는 단계까지 가려면 아직 시간이 필요하다. 완전히 자동 갱신되는 위키를 원하지만 지금 당장은 아니다. 기술이 더 성숙해야 하고 Rocky가 내 Notion 페이지들을 자유롭게 읽고 수정할 수 있는 권한 구조도 정리해야 한다. 지금은 반자동이 적절한 시점이다.
Karpathy가 말한 분업에 동의한다. 인간은 소스를 큐레이션하고 분석 방향을 정하고 좋은 질문을 던진다. LLM이 나머지를 전부 한다. 요약과 교차 참조와 분류와 정리. 이 분업이 작동하는 이유는 LLM이 지루한 작업을 지루해하지 않기 때문이다. 사람은 위키를 포기한다. 교차 참조를 업데이트하고 요약을 최신화하고 수십 페이지의 일관성을 유지하는 게 피곤해서다. LLM은 그런 일을 한 번에 열다섯 개 파일을 건드리면서도 처리한다. 유지보수 비용이 제로에 수렴한다는 말이 추상적으로 들리지 않았다. 매일 경험하는 일이니까.
Vannevar Bush가 80년 전에 꿈꾼 것
Karpathy는 이 패턴이 Vannevar Bush의 Memex (1945)와 정신이 같다고 했다. 개인이 큐레이션하는 지식 저장소. 문서 간 연결이 문서 자체만큼 가치 있다는 비전. Bush가 해결하지 못한 건 누가 유지보수를 하느냐였다. 80년 전에는 답이 없었다. 지금은 LLM이 답이다.
Memex라는 단어를 처음 들은 건 아니다. 세컨드 브레인이라는 개념을 공부하다가 여러 번 마주쳤다. 하지만 Karpathy가 연결 짓는 방식은 달랐다. Bush의 비전에서 빠져있던 퍼즐 조각이 바로 유지보수 담당자였다. Bush는 연결의 가치는 알았지만 그 연결을 누가 계속 업데이트할 것인지까지는 상정하지 못했다. 연결을 만드는 것과 연결을 유지하는 것은 다른 문제다.
내가 매일 하는 일을 돌아보면 Karpathy가 그린 패턴의 반쯤 완성된 버전을 살고 있다. 원본을 수집하고 LLM이 위키를 쌓고 스키마가 규칙을 정하는 구조까지는 같다. 갈 길은 위키가 스스로 갱신되는 지점이다. Rocky가 기존 Notion 페이지를 읽어와서 새 정보와 통합하고 교차 참조를 자동으로 넣는 단계까지 가면 완성이다. 아직 중간쯤이지만 방향은 맞다.
Karpathy가 이 문서를 의도적으로 추상적으로 썼다는 점이 마음에 들었다. 구체적인 구현은 각자의 환경에 맞게 하라는 태도다. 디렉토리 구조도, 페이지 포맷도, 도구도 전부 선택 사항이다. 본인에게 필요한 걸 골라 쓰면 된다. 그래서 이 글을 읽는 누구든 자기 버전의 LLM Wiki를 만들 수 있다. 이미 Obsidian을 쓰고 있다면 거기에 LLM 에이전트만 연결하면 된다. Notion을 쓰고 있다면 API를 열어두면 된다. 중요한 건 도구가 아니라 원본과 위키와 스키마를 분리하는 구조적 사고다.
The wiki stays maintained because the cost of maintenance is near zero.