LLM-Wiki 3폴더 아키텍처: Karpathy 패턴의 활용 시나리오와 커뮤니티 확장

2026년 4월, Andrej Karpathy는 단 하나의 GitHub Gist로 AI 커뮤니티에 새로운 화두를 던졌다. 코드도, 라이브러리도, SaaS 제품도 아닌 — 단순한 "아이디어 파일" 하나가 RAG(Retrieval-Augmented Generation) 중심의 지식 관리 패러다임에 근본적인 의문을 제기하기 시작했다. LLM-Wiki는 개인 지식을 LLM이 직접 컴파일하고 유지·관리하는 새로운 방식으로, 정보를 사후에 검색하는 것이 아니라 사전에 구조화하고 연결하는 패러다임 전환을 의미한다.

LLM-Wiki란 무엇인가

LLM-Wiki는 Karpathy가 공개한 개인 지식 관리 패턴이다. 핵심은 단순하다: 원시 소스 문서들을 LLM이 직접 읽고 이해하여, 상호 연결된 마크다운 파일들의 위키로 변환·유지하는 것이다. 이는 기존의 RAG처럼 쿼리 시점에 임시로 문서를 검색하는 방식과 근본적으로 다르다.

Karpathy는 자신의 X(구 Twitter) 게시물에서 이렇게 설명했다.

"LLM 지식 베이스 — 최근 내가 매우 유용하게 활용하고 있는 것: LLM을 사용해 다양한 연구 주제에 대한 개인 지식 베이스를 구축하는 것. 이 방식으로, 최근 내 토큰 처리량의 상당 부분이 코드 조작보다 지식 조작으로 흘러가고 있다."

실제로 그는 단일 연구 주제에 대해 약 100개의 문서와 40만 단어 이상의 위키를 직접 한 줄도 작성하지 않고 구축했다고 밝혔다.

3폴더 아키텍처

LLM-Wiki의 구조는 극도로 단순하다. 세 개의 디렉토리와 하나의 인덱스 파일로 구성된다.

knowledge-base/
├── raw/          # 원시 소스 자료 (논문, 기사, 코드, 이미지 등)
├── wiki/         # LLM이 컴파일한 마크다운 문서들
└── index.md      # 모든 wiki 문서의 인덱스 (단일 컨텍스트 창 내 수용)

raw/에는 논문 PDF, 웹 기사, GitHub 링크, 데이터셋, 이미지 등 모든 원시 자료를 저장한다. wiki/는 LLM이 소스를 읽고 직접 작성·유지하는 개념 문서들로, 개념당 1개 파일이 원칙이다. index.md는 전체 위키 맵으로, 단일 컨텍스트 창에 들어갈 크기로 유지되며 LLM이 가장 먼저 읽는 파일이다.

LLM은 새 소스가 추가될 때마다 index.md를 먼저 확인하고, 관련 wiki 문서들을 로드한 뒤 통합 작업을 수행한다. 벡터 DB도, 임베딩 파이프라인도, 별도 검색 인프라도 불필요하다.

RAG와의 근본적 차이

LLM-Wiki가 RAG와 다른 핵심은 컴파일 타임 vs. 쿼리 타임 지식 조립의 차이다.

⤢✕

비교 항목	RAG	LLM-Wiki
지식 조립 시점	쿼리 타임 (동적)	컴파일 타임 (사전)
상태 지속성	무상태(Stateless)	유상태(Stateful)
지식 복합화	없음 (쿼리마다 독립)	있음 (지식이 누적·연결)
인프라 요구	벡터 DB, 임베딩 모델	마크다운 파일 디렉토리
모순 감지	어려움	LLM이 직접 감지·기록
소규모 지식 효율	오버킬 경향	최적 (토큰 95% 절감 가능)

RAG의 핵심 한계는 무상태성이다. 각 쿼리는 독립적으로 동작하며 지식이 누적되지 않는다. 반면 LLM-Wiki는 새로운 소스가 추가될 때마다 기존 지식과 통합되고, 모순이 발견되면 기록되며, 연결 관계가 강화된다.

LLM이 위키를 유지하는 방법

새 문서를 추가할 때 LLM이 수행하는 작업 흐름은 다음과 같다.

⤢✕

먼저 index.md를 읽어 전체 지식 구조를 파악하는 컨텍스트 로딩을 거치고, 관련 wiki 문서만 컨텍스트에 로드해 불필요한 토큰 낭비를 막는 선택적 로딩을 한다. 이어 새 개념 문서 생성, 기존 문서 보완, 모순 항목 기록으로 이뤄지는 통합 작업을 수행하고, 새 문서와 관계 정보를 index.md에 반영하는 인덱스 갱신을 거친다. 주기적 "헬스체크" 패스를 통한 자가 치유로 일관성을 유지하고 새 연결을 발견하는 단계까지 포함된다.

실용적 활용 시나리오

연구자·학자는 특정 연구 분야의 논문들을 raw/에 추가하면, LLM이 자동으로 개념 문서, 방법론 비교, 선행 연구 연결 관계를 위키로 구축한다. 논문 100편이 40만 단어짜리 살아있는 문헌 리뷰로 변환되는 식이다.

소프트웨어 개발자는 프로젝트 문서, RFC, 의사결정 기록(ADR), 코드 리뷰 메모를 통합해, LLM이 "왜 이 결정을 했는지"를 기억하고 설명할 수 있는 지식 베이스를 유지할 수 있다.

기술 블로거·콘텐츠 창작자는 읽은 기사, 트윗, 유튜브 자막을 소스로 제공하면 LLM이 테마별 인사이트를 구조화해 글쓰기의 든든한 지식 기반을 제공한다.

기업 지식 관리에서는 팀 내 Slack 대화, 회의록, 기술 문서를 통합해 RAG 인프라 없이 소규모 팀에서 즉시 활용 가능한 사내 위키를 구축할 수 있다.

Claude Code로 구현하기

Karpathy가 권장하는 에이전트는 Claude Code다. 파일 시스템 조작 권한과 긴 컨텍스트 창을 활용해 다음과 같이 동작한다.

# 기본 프롬프트 패턴 예시
"raw/에 새 논문을 추가했어. index.md를 읽고 관련 wiki 문서들을 
업데이트해줘. 새 개념이 있으면 wiki 문서를 만들고, 기존 내용과 
모순이 있으면 별도로 기록해줘."

Claude Code는 자율적으로 파일을 탐색, 읽기, 쓰기하며 위키를 유지한다. 사용자는 소스만 제공하고, LLM이 나머지를 처리한다.

한계와 적합한 규모

LLM-Wiki가 모든 상황에 적합한 것은 아니다. Karpathy 본인도 적정 규모를 명시했다. 적합한 규모는 약 100개 소스, 수백 페이지 분량의 집중된 지식 베이스이고, 부적합한 규모는 수만 개 문서, 실시간 업데이트가 필요한 엔터프라이즈 시스템이다. index.md가 단일 컨텍스트 창에 들어가야 하는 구조적 제약이 있고, 통합 작업마다 LLM 호출 비용이 발생하지만(단, 소규모에서는 RAG 대비 95% 절감 가능) 위키 품질이 사용하는 LLM의 이해·추론 능력에 직접 의존한다는 한계도 있다.

RAG는 대규모 문서 검색, 실시간 데이터 처리, 엔터프라이즈 규모에서 여전히 강점을 보인다. LLM-Wiki는 RAG를 완전히 대체하는 것이 아니라, 개인 또는 소규모 팀의 집중적 지식 관리에 특화된 보완적 패러다임이다.

LLM-Wiki v2와 커뮤니티 확장

Karpathy의 원본 Gist 이후, 커뮤니티에서 다양한 확장 패턴이 등장했다. LLM-Wiki v2는 agentmemory 프로젝트 교훈을 접목한 확장 버전으로 메모리 계층 분리, 중요도 기반 문서 압축을 추가했다. 자가 치유 위키는 주기적 헬스체크 패스로 일관성 검증 및 새 연결 관계를 자동 발견한다. 멀티 에이전트 위키는 소스 수집, 통합, 검증을 별도 에이전트가 분담하는 파이프라인이고, 하이브리드 접근은 대용량 소스는 RAG로, 핵심 개념은 LLM-Wiki로 관리하는 이중 구조다.

LLM-Wiki는 거창한 인프라가 아닌 단순한 마크다운 파일과 LLM의 조합으로 개인 지식 관리를 근본적으로 재정의한다. RAG의 무상태성 한계를 넘어 지식이 누적·복합화되는 유상태 패러다임을 제시하며, 특히 연구자나 개발자처럼 집중적인 지식 영역을 다루는 개인에게 즉시 활용 가능한 강력한 도구다.