🖼️ 4컷 인포그래픽

💡 한 줄 결론

Karpathy가 제안한 LLM 기반 위키 워크플로우는 복잡한 인프라 없이 마크다운 파일만으로 개인 지식 베이스를 구축·누적하는 실용적 방법이며, Claude Code가 자동으로 구조화·분류·관계 구축을 수행해 소규모(약 100편, 50만 단어)에서는 벡터 DB나 RAG 없이도 충분히 작동한다.

📌 핵심 요점

1. 자동 구조화 원리: 원본 문서를 Claude Code에 투입하면 인덱스·태그·백링크가 연결된 위키 구조를 자동 생성하며, 수동 개입 없이 패턴을 식별해 관계를 맺는다.
2. 극단적 인프라 최소화: 폴더 구조는 raw/(원본)와 wiki/(정리 결과) 두 개만으로 충분하고, 임베딩 모델·벡터 DB·청킹 파이프라인이 전혀 필요 없다.
3. 토큰 절감과 복리 누적: 기존 AI 채팅의 ephemeral 한계를 넘어 지식이 복리로 누적되며, compact wiki 변환 시 토큰 사용량을 최대 95%까지 절감할 수 있다.
4. 의도적 모호성 전략: Karpathy는 프롬프트를 vague하게 공개해 개인화 커스터마이징 여지를 두었고, 전용 레포 없이 gist 하나로 충분히 구현 가능하다.
5. 규모 한계 존재: 약 100편·50만 단어 수준에서 검증되었으며, 수백만 건 엔터프라이즈 환경에서는 전통적 RAG·지식 그래프·LightRAG가 여전히 더 적합하다.

🧩 배경과 문제 정의

• Andrej Karpathy가 LLM 기반 개인 지식 베이스 구축 방식을 공유하며, PDF나 원문 자료를 Claude Code에 넣으면 자동으로 위키 구조를 만들어주는 워크플로우를 제안했다.
• 기존 AI 채팅은 대화가 끝나면 지식이 사라지는 ephemeral 특성이 있어, 누적 가능한 지식 시스템의 필요성이 대두되고 있다.
• Karpathy는 복잡한 벡터 데이터베이스나 임베딩 없이 마크다운 파일만으로도 소규모(약 100편, 50만 단어)에서는 충분히 작동하는 인덱스 기반 접근이 가능하다고 평가했다.
• 이 방식은 설정에 5분이면 충분하며, 토큰 사용량을 최대 95%까지 절감할 수 있다는 비용 효율성 측면에서도 주목받고 있다.

🕒 시간순 섹션별 상세정리

1. 유튜브 지식 그래프 시연 — 36개 영상의 자동 구조화 [00:00]

• 최근 36개 유튜브 영상의 자막을 Claude Code가 자동으로 분석해 노드·태그·백링크가 연결된 지식 시스템으로 구성한 결과를 시연한다.
• 각 영상 노드에는 태그, 영상 링크, 원문 파일, 요약, 핵심 takeaways가 포함되며, WAT 프레임워크·Claude Code·Perplexity·VS Code·Nano Banana·Naden N 등 도구별 백링크가 자동 생성되었다.
• 기법(bypass permissions mode, human review checkpoint)과 MCP 서버·RAG·vibe coding 같은 개념 역시 자동으로 관계가 맺어졌다.
• 수동으로 관계를 구축한 것이 아니라 Claude Code가 자체적으로 패턴을 식별해 구조화했다.

2. 개인 세컨드 브레인과 지식 시스템의 분리 운영 [01:13]

• 유튜브 지식 시스템 외에 개인적인 second brain 용도의 더 작은 볼트를 별도로 운영 중이다.
• 개인 브레인에는 UpAI, 유튜브 채널, 사업, 직원, 분기별 이니셔티브 등 개인·비즈니스 맥락이 담긴다.
• 두 볼트를 합치거나 분리해서 유지할 수 있으며, 다른 AI 에이전트에 컨텍스트로 연결하는 것도 가능하다.

3. Karpathy의 LLM 위키 핵심 아이디어 분해 [01:40]

• Karpathy가 X에 올린 글은 며칠 만에 큰 반응을 얻었으며, 핵심은 "LLM으로 개인 지식 베이스를 구축하라"는 것이다.
• 데이터 수집 단계에서 원본 문서(PDF 등)를 Claude Code에 입력하면, Claude Code가 자동으로 정리·분류·관계 구축을 수행한다.
• Q&A 단계에서는 위키 전체를 탐색해 관련 자료를 찾고, 누락된 간극을 식별해 추가 연구로 메우는 것도 가능하다.
• Karpathy는 "fancy RAG 없이도 LLM이 인덱스 파일과 요약을 자동 유지보수하며, 소규모에서는 관련 데이터를 충분히 잘 읽어낸다"고 평가했다.
• 현재 기준 약 100편, 50만 단어 규모에서 테스트되었다.

4. 일반 AI 채팅과의 차이 — 지식의 복리 효과 [03:17]

• 기존 AI 채팅은 대화 종료 후 지식이 사라지는 ephemeral 방식이지만, 이 방식은 지식이 은행 이자처럼 복리로 누적된다.
• X 사용자들은 "드디어 AI가 모든 것을 기억하는 성실한 동료처럼 느껴진다"고 반응했다.
• 폴더 구조가 극도로 단순하다: 최상단 볼트 아래 raw/(원본)와 wiki/(정리 결과) 두 폴더만 있으면 된다.
• wiki 폴더 내에는 개별 위키 페이지, 인덱스 파일, 운영 로그가 포함된다.

5. 인덱스와 로그 구조, 그리고 토큰 효율성 [04:02]

• 인덱스에는 도구, 기법, 에이전트 팀, 서브에이전트, 권한 모드, WAT 프레임워크, 개념(MCP 서버·RAG·vibe coding), 소스(유튜브 영상), 인물, 비교 항목 등이 카테고리별로 정리된다.
• 로그는 운영 이력을 기록하며, 초기 36개 영상 일괄 처리 이후 새 영상을 추가할 때마다 업데이트된다.
• claude.md 파일을 통해 프로젝트 작동 방식, 검색 규칙, 업데이트 방법을 LLM에 지시한다.
• 한 X 사용자는 383개 파일과 100개 이상의 회의 녹취록을 compact wiki로 변환해 Claude 질의 시 토큰 사용량을 95% 절감했다.

6. Karpathy의 의도적 모호성과 gist 공개 [05:39]

• 전용 GitHub 레포나 복잡한 셋업이 없으며, Claude Code에 Karpathy의 아이디어를 읽고 구현하라고 지시하는 것만으로 충분하다.
• X 사용자들은 "2026년 AI 에이전트 소프트웨어는 고수준 아이디어만 주면 알아서 빌드하는 방식으로 만들어질 것"이라고 평가했다.
• Karpathy는 프롬프트를 의도적으로 vague하게 남겨 개인화 커스터마이징 여지를 두었으며, gist 형태로 아이디어 원문을 추가 공개했다.
• 호스트의 두 볼트(유튜브용·개인용)도 동일한 프롬프트에서 시작했으나 컨텍스트에 따라 구조가 다르게 형성되었다.

7. Obsidian 설치 및 볼트 생성 [06:00]

• Obsidian은 관계를 시각적으로 확인하기 위한 프론트엔드로, 필수는 아니지만 권장된다.
• obsidian.md에서 무료로 다운로드 후, 앱을 열어 새 볼트를 생성한다.
• 볼트 이름과 저장 위치를 지정하면 .obsidian 설정 폴더와 welcome.md가 자동 생성된다.
• VS Code에서 해당 폴더를 열고 터미널에서 Claude Code를 실행하는 것이 호스트의 선호 워크플로우다.

8. Claude Code에 프롬프트 적용 및 첫 결과 확인 [07:08]

• Karpathy의 gist 전문을 복사해 Claude Code에 붙여넣고, "You are now my LLM wiki agent. Implement this exact idea file as my complete second brain."이라는 보조 프롬프트를 함께 전송한다.
• 실행 결과로 raw/와 wiki/ 폴더가 자동 생성되며, wiki 내부에는 analysis/, concepts/, entities/, sources/ 네 개의 하위 폴더가 기본 구성된다.
• claude.md, 인덱스, 로그 파일도 함께 생성된다.
• Karpathy는 "때로는 서브폴더 없이 아주 플랫하게 유지하는 게 낫다"고 했으나, 유튜브 지식 시스템처럼 도메인이 명확하면 하위 폴더 구조가 더 유용할 수 있다.

9. 첫 번째 소스 수집 — 웹 클리퍼로 원문 투입 [08:36]

• AI2027 사이트의 글을 첫 소스로 사용해 raw 폴더에 투입하는 과정을 시연한다.
• Obsidian Web Clipper 확장을 Chrome에 설치하면 웹 문서를 볼트의 특정 폴더에 직접 저장할 수 있다.
• 클리퍼에서 대상 폴더를 raw로 설정한 뒤 "Add to Obsidian"을 누르면 원문이 마크다운으로 들어온다.
• Claude Code에 "raw에 AI 2027을 넣었으니 ingest해 달라"고 요청하면, LLM이 원문을 읽고 위키에 맞게 분류·구조화를 시작한다.

10. 위키 수집 설정 및 초기 컨텍스트 제공 [10:01]

• 확장 프로그램 옵션에서 기본 폴더를 clippings에서 raw로 변경한다.
• AI 2027 기사를 수집하자 시스템이 핵심 요약을 반환한 뒤, 강조할 부분·목표·세분화 수준을 추가로 질문한다.
• 사용자는 "극도로 철저하게, AI 연구 중심 볼트"라는 컨텍스트를 제공해 프로젝트 방향을 명확히 설정한다.
• 이렇게 추가 컨텍스트를 주면 위키가 지속적으로 발전하는 구조를 갖게 된다.

11. 그래프 뷰로 위키 생성 과정 실시간 관찰 [11:06]

• Obsidian 그래프 뷰를 열면 위키 페이지들이 생성되며 노드와 관계가 실시간으로 시각화된다.
• AI 2027 기사 하나에서 약 25개의 위키 페이지가 파생되며, 주요 허브 인물(Eli, Thomas, Daniel)과 AI governance·OpenBrain·superhuman coder 등의 관계가 형성된다.
• 단일 기사 수집에 약 10분, 유튜브 자막 36개 일괄 수집에는 약 14분이 소요된다.
• 수집 완료 후 23개 위키 페이지, 6명 인물, 5개 조직, 1개 AI 시스템 페이지 등 체계적인 구조가 자동 생성된다.

12. 생성된 위키 탐색 및 관계망 확인 [12:19]

• 소스 페이지에서 태그·저자·주요 관계를 확인할 수 있다.
• OpenAI 노드 → Model Spec → LLM Psychology Model처럼 클릭 한 번으로 연관 페이지를 따라가며 탐색할 수 있다.
• 이 모든 구조가 단일 기사에서 자동으로 파생되었으며, 향후 다른 기사를 추가하면 compute scaling 등 공통 주제 간에도 새로운 관계가 형성될 것으로 예상된다.

13. 위키 활용 전략: 내부 질의와 외부 프로젝트 연동 [13:06]

• 위키를 볼트 내부에서 직접 질의할지, 외부 프로젝트에서 참조할지는 사용 목적에 따라 결정한다.
• YouTube 프로젝트는 볼트 내부에 유지하며, 필요 시 웹사이트로 변환하거나 다른 프로젝트에서 크롤링할 수 있다.
• 외부 프로젝트에서는 CLAWMD를 통해 위키 구조를 이해시키고, 인덱스·도메인 서브인덱스를 읽어 컨텍스트로 활용한다.
• 실행 비서 프로젝트(Herk 2)의 경우, 비즈니스 지식 위키 경로를 cloud.md에 명시해 필요할 때만 위키를 읽도록 설계했다.

14. 핫 캐시와 토큰 최적화 [14:17]

• 핫 캐시(hot.md)는 가장 최근 대화나 작업 내용을 약 500자 분량으로 저장하는 요약 파일이다.
• 실행 비서 컨텍스트에서는 핫 캐시가 여러 위키 페이지를 크롤링하는 수고를 줄여준다.
• 반면 YouTube 자막 프로젝트처럼 최신 문맥이 중요하지 않은 용도에서는 핫 캐시가 불필요하다.
• 기존 context files 방식에서 위키 방식으로 전환한 후 실제 토큰 사용량이 감소했다.

15. 린팅을 통한 위키 품질 관리 [15:02]

• Karpathy는 LLM 기반 헬스 체크를 정기적으로 실행해 위키의 일관성을 점검한다.
• 불일치 데이터 탐지, 웹 검색으로 누락 정보 보완, 새로운 기사 후보 발굴 등을 자동으로 수행한다.
• 위키가 확장 가능하고 구조적으로 건강하게 유지되도록 돕는 핵심 유지보수 과정이다.
• 시스템이 "이해가 부족한 부분이 있으니 추가 자료를 달라"고 요청하기도 한다.

16. 위키 방식 vs Semantic Search RAG 비교 — 결론과 한계 [15:32]

• 위키는 인덱스를 읽고 링크를 따라가는 방식이어서 유사도 검색보다 관계 이해가 깊다.
• 인프라 측면에서 마크다운 파일만 있으면 되므로 임베딩 모델·벡터 DB·청킹 파이프라인이 필요 없다.
• 비용은 토큰 비용 외에 거의 발생하지 않으며, 유지보수는 린팅과 새 문서 추가로 충분하다.
• 수백 페이지 규모에서는 위키가 잘 작동하지만, 수백만 건 규모의 엔터프라이즈 환경에서는 전통적 RAG·지식 그래프·LightRAG 등이 더 적합하다.
• 현재(2026년 4월 기준) 모델 성능 기준에서의 평가이며, 모델이 발전하면 한계가 달라질 수 있다.

17. Semantic Search RAG vs Wiki 비교 [15:33]

• 인덱스를 읽고 링크를 따라가는 방식이 similarity search보다 관계 이해에 유리하다
• 인프라 측면에서 임베딩 모델·벡터 DB·청킹 파이프라인 없이 마크다운 파일만으로 구동 가능하다
• 비용은 토큰 비용뿐이고, 유지보수도 린트·정리·추가 컨텍스트 제공으로 충분하다
• 하지만 수백만 건 규모 엔터프라이즈 환경에서는 전통적 RAG 파이프라인이 여전히 더 적합하다

18. 마무리 및 후속 영상 안내 [17:22]

• 현재 모델 기준(2026년 4월)으로는 수백 페이지 규모까지는 wiki graph가 충분하다
• 그 이상 규모에서는 light RAG, knowledge graph 등 전통적 도구가 필요해진다
• 다음 영상에서는 Obsidian vault와 연동하는 개인 executive assistant 구축법을 다룬다

🧾 결론

• Karpathy의 LLM 위키 접근은 "AI가 모든 것을 기억하는 성실한 동료"를 현실적으로 만드는 경량 프레임워크로, 5분 설정으로 즉시 시작할 수 있는 실용성이 핵심 강점이다.
• Obsidian은 시각화 프론트엔드로 권장되지만 필수는 아니며, VS Code + Claude Code 조합만으로도 전체 워크플로우가 작동한다.
• 위키 품질 관리를 위해 LLM 기반 린팅·헬스 체크를 정기 실행해야 하며, 시스템이 스스로 누락 정보를 요청하는 구조로 설계되어 있어 장기 유지보수가 가능하다.
• 2026년 4월 현재 모델 성능 기준의 평가이므로, 향후 모델 발전에 따라 위키 방식의 적용 범위가 확대될 가능성이 열려 있다.
• 고수준 아이디어만 주면 AI 에이전트가 알아서 빌드하는 방식은 향후 소프트웨어 개발 패러다임의 방향성을 보여주는 사례로 평가된다.

📈 투자·시사 포인트

• 마크다운 기반 지식 관리 도구의 부상: Obsidian·Notion 등 로컬 퍼스트 마크다운 에코시스템이 AI 에이전트와 결합하면서 개인 지식 관리 시장의 새로운 표준으로 자리잡을 가능성이 있다.
• RAG 인프라 산업에 대한 재평가 신호: 소규모·개인 사용자에게 벡터 DB·임베딩 파이프라인이 과잉 스펙일 수 있으며, LLM의 컨텍스트 처리 능력 향상이 전통적 RAG 수요를 일부 대체할 수 있다.
• "Vibe coding" 확산: Karpathy처럼 고수준 아이디어만 제시하고 AI가 구현하는 방식이 엔지니어링 생산성을 크게 높이고 있어, 개발 도구·에이전트 플랫폼 기업에게 긍정적 수혜 가능성이 있다.
• 토큰 비용 최적화 수요 지속: compact wiki 변환으로 95% 토큰 절감이 가능하다는 검증은, AI 비용 최적화 솔루션·캐싱 인프라 기업에게 실질적 수요 근거를 제공한다.
• 규모 확장 시 지식 그래프·LightRAG 수요 유지: 엔터프라이즈급 대규모 데이터 환경에서는 여전히 전통적 RAG·지식 그래프 기술이 필요하므로, 해당 영역 기술 보유사의 포지션은 유효하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 토큰 95% 절감 주장의 검증 한계: X 사용자 한 명의 사례로, 원본 문서 수·길이·질의 패턴에 따라 절감률은 크게 달라질 수 있다. 범용화 가능한 수치인지 추가 검증이 필요하다.
• 소규모 한계 기준의 불명확성: Karpathy가 "약 100편, 50만 단어"에서 테스트했다고 했으나, 이 한계를 넘어설 때 성능이 어떻게 저하되는지에 대한 정량적 임계값이 공개되지 않았다.
• 핫 캐스(hot.md) 500자 기준의 근거: 왜 약 500자인지, 더 늘리거나 줄일 때 토큰 절감 효율이 어떻게 변하는지에 대한 명확한 설명이 영상에 없다.

✅ 액션 아이템

• Karpathy의 원문 gist(https://gist.github.com/karpathy)를 직접 확인해 현재 버전과 영상 설명 간 차이점을 비교한다.
• Claude Code + Obsidian 볼트 조합으로 테스트 볼트를 생성하고, raw 폴더에 소스 3~5개를 투입해 자동 구조화 품질을 직접 검증한다.
• 동일한 질의를 일반 AI 채팅과 위키 인덱스 방식 각각에 수행해 실제 토큰 사용량과 응답 품질을 비교 기록한다.
• 핫 캐시 도입 전후로 실행 비서 프로젝트의 토큰 소비량을 측정해 효과를 정량화한다.

❓ 열린 질문

• 확장성 임계값은 어디인가? 50만 단어를 넘어 수백만 단어 규모가 되었을 때 인덱스 파일 자체가 컨텍스트 윈도우를 압박하는데, 샤딩이나 계층형 인덱스 없이도 작동하는가?
• 다중 에이전트 환경에서 위키 충돌은 어떻게 해결하는가? 여러 Claude Code 인스턴스가 동시에 같은 위키를 갱신할 때 파일 충돌·중복 생성 문제를 어떤 방식으로 제어할 것인가?
• 린팅 비용이 위키 유지비의 주요 비중을 차지하지 않는가? 정기 헬스 체크에 사용되는 토큰 비용이 실제 질의 토큰 절감분을 상회하는 시점이 올 수 있는가?