techyoo 영상 **「LLM Wiki 하나로 GitHub이 2주 만에 뒤집힌 이유」**에서는 Andrej Karpathy가 공개한 **LLM Wiki 아이디어 파일**을 중심으로, 이 패턴이 무엇이고 RAG와 어떻게 다르며 실제로 어떤 방식으로 구현되는지 정리합니다. ## LLM Wiki는 제품이 아니라 패턴 영상에서 가장 먼저 강조하는 점은 **LLM Wiki가 특정 제품명이 아니라는 것**입니다. Karpathy가 공개한 것은 코드나 공식 프로젝트가 아니라 아이디어를 정리한 Markdown 파일에 가깝고, 이후 커뮤니티가 이를 각자의 방식으로 구현하면서 여러 저장소가 등장했습니다. 즉, LLM Wiki는 하나의 앱이라기보다: > **LLM이 지속적으로 유지·확장하는 개인 또는 팀 지식 위키를 만드는 설계 패턴** 으로 보는 것이 맞습니다. ## 3계층 구조 영상에서는 LLM Wiki를 크게 세 계층으로 설명합니다. ### 1. Raw Source PDF, 이메일, 회의록, 웹 문서 같은 원자료를 그대로 보관합니다. 원본은 가능한 한 수정하지 않고 **근거 자산**으로 유지합니다. ### 2. Wiki LLM이 원본을 읽고 개념별 Markdown 문서로 재구성한 계층입니다. 예: - transformer.md - attention.md - optimizer.md - project-a.md 단순 요약이 아니라 관련 개념끼리 링크를 연결하고 기존 페이지를 갱신합니다. ### 3. Schema / Agent Rules AI가 어떤 규칙으로 Wiki를 만들고 유지할지 정의하는 운영 문서입니다. 예를 들어: - 어떤 형식으로 문서를 만들지 - 제목 규칙 - 링크 규칙 - 원본 출처 표기 - 충돌 처리 - 업데이트 방식 등을 적습니다. ## 핵심 연산 3가지 LLM Wiki의 핵심은 세 가지 동작으로 요약할 수 있습니다. ### Ingest 새 원본 자료를 읽고 기존 Wiki에 흡수합니다. 새 페이지를 만들 수도 있고, 기존 페이지를 보강하거나 관련 링크를 추가할 수도 있습니다. ### Query 사용자 질문이 들어오면 Wiki를 읽고 답변합니다. 즉, 매번 원본 전체를 읽기보다 **이미 정리된 지식 계층**을 우선 활용합니다. ### Lint Wiki 내부의 충돌과 모순을 찾습니다. 예를 들어 한 페이지에서는 “A가 항상 더 낫다”고 쓰여 있는데 다른 페이지에서는 반례가 있다면 이를 검토 대상으로 올릴 수 있습니다. ## RAG와 가장 큰 차이 영상에서는 두 방식을 이렇게 비교합니다. ### RAG 질문이 들어올 때 관련 자료를 찾습니다. **Query-time Retrieval** ### LLM Wiki 자료가 들어올 때 미리 정리합니다. **Ingest-time Compilation** 쉽게 말해: - RAG → 질문할 때마다 도서관에서 책을 찾음 - LLM Wiki → 사서가 책이 들어올 때마다 요약 노트를 미리 갱신함 입니다. ## “지식 컴파일러”라는 관점 LLM Wiki를 이해하기 좋은 표현 중 하나가 **Knowledge Compiler**입니다. 원본 문서를 그대로 검색 대상으로 두는 것이 아니라, AI가 미리 읽고: - 핵심 개념 추출 - 관계 연결 - 요약 - 교차 참조 - 구조화 를 수행해 **AI가 더 쉽게 읽고 재사용할 수 있는 지식 형태로 컴파일**하는 방식입니다. ## Vector DB가 꼭 필요한 것은 아니다 이 패턴에서 흥미로운 부분은 초기에 Vector DB나 Embedding 없이도 운영할 수 있다는 점입니다. 다음과 같은 전통적인 파일 구조만으로도 가능합니다. - index.md - log.md - concepts/ - projects/ - sources/ - agents.md AI 코딩 에이전트가 이 파일들을 직접 읽고 탐색할 수 있기 때문입니다. 자료 규모가 작거나 중간 수준이라면 이 방식이 오히려 단순할 수 있습니다. ## 실제 구현 방법 3가지 영상에서는 대표적으로 세 가지 방식을 소개합니다. ### 1. 로컬 CLI Claude Code, Codex 같은 코딩 에이전트가 로컬 폴더를 직접 읽고 Wiki를 갱신합니다. 장점은 가장 단순하다는 점입니다. 별도의 서버나 DB 없이: **폴더 + Markdown + Agent 규칙** 만으로 시작할 수 있습니다. ### 2. Obsidian Obsidian Vault를 그대로 Wiki 저장소로 사용합니다. 장점은: - 사람이 읽기 쉬움 - 그래프 뷰 활용 - 링크 관계 확인 - Markdown 기반 - 로컬 저장 입니다. AI가 Ingest할 때 자동으로 링크를 추가하면 지식 그래프처럼 관계가 시각화됩니다. ### 3. MCP 서버 Wiki를 MCP 서버로 노출하면 Claude Desktop, Cursor 같은 외부 AI 도구에서도 동일한 지식베이스를 사용할 수 있습니다. 즉: **LLM Wiki → MCP → 여러 AI 클라이언트** 구조로 확장할 수 있습니다. ## 대표 구현체 영상에서는 커뮤니티 구현체로 다음 프로젝트를 소개합니다. - **nashsu/llm_wiki** → 데스크톱·Obsidian 스타일 - **SamurAIGPT/llm-wiki-agent** → Python CLI - **atomicmemory/llm-wiki-compiler** → TypeScript + MCP 모두 구현 방식은 다르지만 핵심 구조는 비슷합니다. ## Lint가 중요한 이유 지식베이스가 쌓이면 단순 검색보다 **일관성 유지**가 더 어려운 문제가 됩니다. 예를 들어: - 오래된 주장 - 서로 충돌하는 설명 - 중복 페이지 - 출처 불명확 - 잘못 연결된 개념 이 생길 수 있습니다. Lint는 이런 부분을 AI가 먼저 찾아 사람에게 검토 요청하는 역할을 합니다. 다만 영상에서도 강조하듯 **Lint가 모든 오류를 잡아준다고 가정하면 위험합니다.** ## 비판 지점 3가지 ### 1. 최종 신뢰 책임은 여전히 사람에게 있음 AI가 지식을 정리하더라도 그 내용이 사실인지 검증하는 책임은 남습니다. ### 2. 모순 탐지가 완벽하지 않음 충돌을 놓칠 수도 있고, 오히려 “문제 없음”이라는 잘못된 안도감을 줄 수 있습니다. ### 3. 대규모 확장성이 검증되지 않음 개인·팀 수준에서는 자연스럽지만 수만·수십만 문서 규모에서는 기존 검색 인프라가 더 적합할 수 있습니다. ## Karpathy의 중요한 단서 — Moderate Scale 영상은 Karpathy가 이 아이디어를 **moderate scale**에 적합한 패턴으로 본 점을 강조합니다. 즉: - 개인 지식 - 연구 노트 - 소규모 팀 문서 - 프로젝트 지식 - 콘텐츠 제작 자료 에는 잘 맞을 수 있지만, 대규모 기업 검색 전체를 곧바로 LLM Wiki로 대체하자는 주장은 아닙니다. ## RAG를 대체하는 기술이 아니다 이 영상의 가장 중요한 결론은: > **LLM Wiki는 RAG를 죽이는 기술이 아니라, RAG가 잘하지 못하는 ‘지식 유지·정리·축적’을 담당하는 보완 레이어** 라는 점입니다. 실제로는 다음과 같이 함께 쓸 수 있습니다. **Raw Source → RAG 검색** **정제된 Knowledge → LLM Wiki** **다중 클라이언트 연결 → MCP** **장기 유지 → Lint / Human Review** ## 누가 쓰면 좋은가? 특히 다음 사용자에게 잘 맞습니다. - 연구자 - 리뷰어 - 뉴스레터 제작자 - 기자 - PM - 기획자 - 개인 지식관리 사용자 - 장기 프로젝트 운영자 반대로 대규모 FAQ, 고객센터, 엔터프라이즈 검색처럼 문서가 매우 많고 즉시 최신 원문 검색이 중요하다면 RAG가 여전히 핵심입니다. ## 핵심 정리 LLM Wiki는 단순한 “AI 메모장”이 아니라 다음 구조를 가진 **지식 컴파일러 패턴**입니다. **Raw → Ingest → Wiki → Query → Lint** 그리고 구현은: **Local CLI / Obsidian / MCP** 중 하나로 시작할 수 있습니다. 핵심은 모델이 더 똑똑해지는 것이 아니라, **AI가 장기간 사용할 지식 자체를 미리 구조화하고 지속적으로 유지하는 계층을 만드는 것**입니다.