안드레이 카파시 LLM Wiki 공개: 문서 업로드보다 오래 남는 지식 베이스

한눈에 보기

1. 2026년 4월 4일 공개된 LLM Wiki gist, 제품 소개보다 작업 패턴 제안
2. 파일 업로드형 RAG보다 지속 갱신형 위키 계층을 두는 지식 관리 방식을 추천
3. 원문 소스, LLM이 유지보수하는 위키, 규칙을 담는 스키마의 3계층
4. NotebookLM의 출처 기반 답변, Obsidian의 로컬 보관, 카파시식 누적 편집 구조의 차이
5. 인물 소개: 안드레이 카파시, OpenAI 공동창립 멤버·Tesla AI 총괄 출신·현재 Eureka Labs 창업자
6. 결론: 연구·독서·팀 위키에는 강점, 검증 규칙과 운영에 대한 방향성 없이는 정리가 안됨

서론

문서를 많이 다루는 사람의 LLM 활용법은 대체로 비슷하다. 파일을 올리고, 질문할 때마다 관련 조각을 찾고, 그때그때 답을 만든다. 빠르고 편리하지만 한계도 있다. 문서 여러 개에 흩어진 맥락을 매번 다시 찾게 되고, 지난번에 어렵게 만든 분석이 다음 질문에서 그대로 자산이 되지 못하는 경우가 적지 않다.

안드레이 카파시가 2026년 4월 4일 공개한 gist LLM Wiki는 바로 이 지점을 겨냥한다. 그는 파일 업로드형 RAG를 부정하지 않는다. 다만 질문마다 자료를 다시 끌어오는 구조보다, LLM이 중간층의 위키를 계속 고쳐 쓰며 지식을 누적시키는 편이 더 강력할 수 있다고 본다. 즉, 문서 더미와 사용자 사이에 지속적으로 갱신되는 구조화 위키를 둔다는 발상이다.

이번 글은 제목별 핵심을 다시 풀고, 카파시의 개인 사이트·GitHub·Eureka Labs 자료를 더해 인물 맥락을 확인했다. 여기에 Google의 NotebookLM 도움말과 Obsidian Web Clipper 공식 문서를 붙여, 이 아이디어가 기존 도구와 어떻게 다른지도 대조했다. 질문은 하나다. 이 제안이 새로운 형태의 어플리케이션 방향성을 설명하는 것인지, 아니면 LLM 시대 지식 관리 습관의 방향 전환인지 확인하는 과정이다.

 

 

1. 안드레이 카파시는 누구인가

1. 현재는 2024년 Eureka Labs 창업자, AI 네이티브 교육 플랫폼 추진 중에 있음
2. 주요 이력은 OpenAI 공동창립 멤버, Tesla AI 총괄, 2023년부터 2024년까지 OpenAI 복귀
3. 교육 상징: Stanford CS231n 설계와 강의 주도, 유튜브 Zero to Hero 시리즈 운영
4. 개발자 자산으로는 대표적으로 micrograd, nanoGPT, llm.c, arxiv-sanity 같은 학습형 프로젝트 축이 있음

카파시는 대중적으로는 OpenAI 공동창립 멤버, Tesla AI 총괄, 딥러닝 교육자로 널리 알려져 있다. 그런데 개인 사이트를 보면 더 선명한 특징이 하나 보인다. 그는 늘 복잡한 AI 개념을 손으로 만져 볼 수 있는 형태로 바꾸는 데 강하다. Stanford의 CS231n, 최근 유튜브 강의, 소규모 구현 저장소가 모두 같은 흐름이다.

또 다른 축은 지식 정리다. 사이트에는 arxiv-sanity 같은 연구 정리 도구가 주요 프로젝트로 여전히 소개돼 있다. 이번 LLM Wiki도 이 연장선으로 읽히기 쉽다. 논문과 자료를 찾고 정리하던 도구에서 한 걸음 더 나아가, 이제는 LLM이 사람이 읽은 내용을 장기적으로 정리하고 연결하는 위키 편집자로 움직이는 그림을 제안한 셈이다.

2. LLM Wiki를 제목별로 정리

원문 제목 구조를 세로 카드형으로 다시 그린 도식이다. 전체 패턴을 먼저 잡기 쉽게 만들었다.

1. The core idea

1. 기존 방식: 파일 업로드 뒤 질의 시점마다 관련 조각 재조합
2. 제안 방식: LLM이 중간층 위키를 지속 갱신하며 지식 누적
3. 핵심 차별: 답변용 검색보다 장기 보존형 합성 결과물 축적

카파시는 대부분의 문서형 LLM 활용이 RAG와 비슷하다고 본다. 파일을 올리고, 질문이 들어오면 관련 부분을 찾고, 매번 답을 조합하는 방식이다. 잘 작동하지만 빠진 것도 있다. 지식의 누적이다. 예를 들어 문서 다섯 개를 묶어 어렵게 만들어서 Indexing 이나 Vectorizing 을 통해 구성된 분석이 다음 질문에서 형태 그대로 유지한체 자산이 되지 못한다는 것이다.

그래서 대안은 중간에 위키를 두는 방식이다. 새 문서가 들어오면 LLM은 그것을 나중에 찾기만 하지 않는다. 핵심 내용을 읽고, 관련 페이지를 수정하고, 오래된 주장과 충돌하는 지점을 표시하고, 이미 있는 합성 결과를 다시 다듬는다. 질의 때마다 처음부터 다시 짜는 구조가 아니라 지식이 한 번 컴파일되고 계속 갱신되는 구조다.

2. Architecture

1. 원문 소스층: 기사, 논문, 이미지, 데이터 파일 같은 변경 금지 자료층
2. 위키층: LLM이 작성·수정하는 마크다운 페이지 집합
3. 스키마층: AGENTS.md나 CLAUDE.md처럼 규칙과 흐름을 정하는 운영 문서

구조는 세 층으로 단순하다. 첫째는 손대지 않는 원문 자료다. 둘째는 LLM이 쓰는 위키다. 셋째는 위키 구조와 작업 절차를 정하는 스키마다. 역할이 또렷하다는 점이 장점이다. 사람은 소스를 고르고 질문을 던지고, LLM은 위키를 유지보수한다.

특히 스키마 문서를 강조한 점이 중요하다. 이 제안은 “잘 알아서 정리해 달라”가 아니다. 어떤 페이지를 만들지, 어떤 링크 규칙을 쓸지, 새 소스가 들어왔을 때 무엇을 갱신할지를 스키마에 적어 LLM을 잡담형 챗봇이 아니라 규율 있는 위키 관리자로 만든다는 발상이다.

3. Operations

1. 소스 투입: 문서 추가, 요약 생성, 관련 페이지 수정, 로그 기록
2. 질의 처리: 위키 검색 뒤 답변 합성, 결과를 다시 위키 페이지로 편입
3. 점검 작업: 모순, 오래된 주장, 고아 페이지, 누락 개념 탐색

운영 파트에서 카파시는 ingest, query, lint라는 세 동작을 제시한다. 새 자료를 넣고, 질문하고, 정기적으로 건강 상태를 점검하는 흐름이다. 이 셋 중 특히 눈에 띄는 부분은 질의 결과를 위키에 다시 넣는 발상이다. 좋은 대화 결과도 보통 채팅창에 묻히는데, 그는 비교표나 분석 결과를 새 위키 페이지로 저장하라고 본다.

이렇게 하면 탐색 자체가 자산이 된다. 한 번 했던 분석이 다음 대화에서 사라지지 않고, 위키 안에서 더 많은 연결점을 만든다. 문서 모음이 아니라 자라나는 지식 시스템을 만들겠다는 뜻이다.

4. Indexing and logging

1. index.md 역할: 내용 중심 목록, 각 페이지 요약과 분류, 질의 출발점
2. log.md 역할: 시간순 기록, 투입·질의·점검 이력 보존
3. 실무 장점: 임베딩 인프라 없이도 중간 규모까지 탐색 가능, 최근 작업 추적 용이

색인과 로그를 분리한 점도 실용적이다. index.md는 현재 위키 안에 무엇이 있는지 보여 주는 내용 목록이고, log.md는 언제 무엇을 했는지 남기는 작업 기록이다. 전자는 길찾기용, 후자는 시간축용이다.

로그 제목 형식을 일정하게 맞추면 간단한 셸 도구로 최근 이력만 뽑아 보기 쉽다고 설명하는데, 이 대목에서 거대한 인프라보다 작고 읽기 쉬운 규칙을 선호하는 카파시의 취향이 드러난다.

5. Optional: CLI tools

1. 기본 입장: 작은 규모에서는 색인 파일만으로도 충분
2. 확장 시점: 페이지 수 증가 뒤 별도 검색 도구 필요성 상승
3. 제안 예시: 로컬 마크다운 검색 도구 qmd, CLI와 MCP 양쪽 활용 가능성

여기서 중요한 점은 카파시가 거창한 스택을 먼저 권하지 않는다는 사실이다. 위키가 아주 크지 않다면 index.md만으로도 출발이 가능하다고 본다. 다만 페이지 수가 늘면 더 좋은 검색 도구를 붙일 수 있고, 그 예시로 로컬 마크다운 검색 도구 qmd를 든다.

즉, 이 문서는 특정 제품 홍보가 아니다. 작은 규칙으로 시작하고, 필요할 때 도구를 붙이는 점진 확장 패턴에 가깝다.

6. Tips and tricks

1. 소스 수집 팁: Obsidian Web Clipper 같은 마크다운 저장 도구 활용
2. 이미지 처리 팁: 첨부 파일 로컬 저장 뒤 LLM이 별도 이미지 확인 가능하도록 준비
3. 활용 팁: 그래프 뷰, Marp, Dataview, Git 저장소 구조 활용

팁 파트는 구체적이다. 웹 기사를 마크다운으로 저장하고, 이미지도 로컬에 내려받고, 그래프 뷰로 연결 구조를 보고, 필요하면 슬라이드나 Dataview 질의로 확장하라는 식이다. 여기서 보이는 메시지는 하나다. 위키를 문서 더미가 아니라 살아 있는 작업 공간으로 다루라는 것이다.

또 하나 눈에 띄는 대목은 이미지 처리다. 카파시는 LLM이 인라인 이미지를 한 번에 자연스럽게 읽기 어렵다는 현실도 적는다. 그래서 텍스트를 먼저 읽고, 필요하면 이미지를 별도로 보게 하는 식의 현실적 우회를 제시한다. 이상론보다 실제 사용 습관에 가깝다.

7. Why this works

1. 사람 병목: 교차 링크, 요약 갱신, 모순 표시 같은 유지보수 노동 회피 경향
2. LLM 강점: 여러 파일 동시 수정, 반복 작업 지속, 링크와 요약 정리 자동화
3. 인간 역할: 소스 선별, 질문 설정, 해석 판단, 의미 부여

카파시는 위키의 가장 지루한 부분이 읽기나 생각이 아니라 유지보수라고 본다. 링크 갱신, 요약 보정, 오래된 주장 표시, 관련 페이지 수정 같은 작업은 가치가 크지만 사람은 금방 지친다. 반면 LLM은 이런 반복 정리를 비교적 꾸준히 해낼 수 있다.

그래서 사람의 역할도 다시 나눈다. 사람은 소스를 고르고 질문을 설계하고 의미를 판단한다. LLM은 그 외의 정리 노동을 맡는다. 이 구분은 단순 자동화보다 협업 모델에 가깝다.

8. Note

1. 문서 성격: 구현 명세가 아닌 아이디어 패턴 문서
2. 가변 요소: 폴더 구조, 페이지 형식, 검색 도구, 출력 방식 전부 선택 사항
3. 적용 원칙: 도메인과 사용자 취향에 맞는 맞춤형 구체화 필요

마지막 노트에서 카파시는 이 문서가 추상적이라고 직접 밝힌다. 폴더 구조, 규칙, 도구, 출력 형식은 사용자와 도메인에 따라 달라져야 한다는 뜻이다. 이 문서는 완성품 사용법이 아니라, LLM과 함께 자신의 구조를 설계하기 위한 출발점이다.

그래서 LLM Wiki를 곧바로 설치형 제품처럼 보면 실망할 수 있다. 반대로 패턴 문서로 읽으면 상당히 실용적이다. 어떤 사람은 이미지가 필요 없고, 어떤 팀은 검색 엔진 없이 index만으로 충분할 수 있다. 결국 핵심은 틀이 아니라 원칙이다.

3. 유사 도구와 같이 보면 더 선명해지는 차이

1. NotebookLM 차이: 출처 기반 답변과 변환 기능 강점, 지속 편집형 위키 개념은 약한 편
2. Obsidian 차이: 로컬 저장과 사생활 보호 강점, 유지보수 노동은 사람 몫
3. 카파시식 차이: 소스와 사람 사이에 LLM 편집 계층을 두는 발상
4. 실무 분기: 빠른 답변은 NotebookLM, 장기 개인 볼트는 Obsidian, 누적 합성은 LLM Wiki 패턴

Google은 NotebookLM을 AI 기반 연구 보조 도구로 설명하며, PDF와 웹사이트, 유튜브, 오디오, 문서를 올리고 출처 기반 인라인 인용과 study guides, briefings, audio overviews, mind maps 같은 변환 기능을 제공한다고 안내한다. 이 설명은 강점과 한계를 동시에 보여 준다. 답변의 근거가 분명하고 변환 산출물도 풍부하지만, 기본 단위는 여전히 노트북 안의 소스와 질의다. 카파시가 말하는 지속 편집형 위키 계층과는 무게중심이 다르다.

Obsidian Web Clipper도 대비점이 뚜렷하다. 공식 문서는 이 도구를 무료 브라우저 확장 기능으로 설명하고, 웹 콘텐츠를 로컬 볼트에 저장하며, 데이터 수집을 하지 않고 오픈소스라고 밝힌다. 즉, 소스 보관과 사생활 보호에는 강점이 있지만, 들어온 자료를 교차 링크하고 요약을 갱신하고 오래된 주장까지 정리하는 일은 기본적으로 사람이 해야 한다. 카파시의 제안은 바로 그 유지보수 부담을 LLM에게 넘기려는 쪽에 가깝다.

 

4. 안드레이 카파시다운 제안인 이유

1. 교육자 시선: 복잡한 개념을 작은 구조로 나누는 설명 습관
2. 연구 도구 시선: arxiv-sanity처럼 정보 과부하를 다루는 관심사
3. 구현자 시선: micrograd, nanoGPT, llm.c처럼 최소 단위 구조 선호
4. 현재 사업 시선: Eureka Labs의 AI 네이티브 학습 구조와 연결 가능성

이 gist는 카파시의 경력과 놀라울 만큼 잘 맞는다. 그는 늘 복잡한 개념을 손에 잡히는 구조로 바꾸는 데 강했다. Stanford 강의도 그랬고, 작은 구현 프로젝트도 그랬다. 동시에 arxiv-sanity처럼 정보가 넘치는 환경에서 무엇을 남기고 어떻게 찾을지 고민해 온 흔적도 있다.

그래서 LLM Wiki는 갑자기 튀어나온 아이디어라기보다, 교육자·연구 도구 제작자·AI 엔지니어라는 세 정체성이 만나는 지점처럼 보인다. 현재 Eureka Labs가 교육형 AI를 지향한다는 점까지 더하면, “지식을 읽고 정리하고 다시 가르치는 구조”에 대한 그의 관심이 한 흐름으로 이어진다.

결론

1. 사실 검증 문제: LLM이 오래된 주장과 새 자료를 잘못 합칠 위험
2. 구조 오염 문제: 스키마 규칙이 약하면 페이지 난립과 링크 혼선 발생
3. 과잉 자동화 문제: 사람이 핵심 판단을 놓치면 위키 품질 하락
4. 규모 확장 문제: 페이지 증가 뒤 검색과 점검 절차 추가 필요

이 아이디어는 강력하지만, 자동으로 진실한 위키가 생긴다는 뜻은 아니다. 가장 큰 위험은 잘못된 합성의 영속화다. 질문 한 번의 오류가 위키 페이지로 저장되면, 다음 대화에서 사실처럼 재활용될 수 있다. 그래서 이 구조는 오히려 검증 규칙이 더 중요하다.

또한 스키마가 약하면 페이지는 빠르게 늘어나지만 위키는 금방 흐려진다. 이름 규칙, 링크 규칙, 요약 형식, 로그 기록 방식이 초기에 없으면 LLM이 쓴 문서가 단기간에 읽기 어려운 숲이 될 수 있다. 결국 성패는 모델 성능보다 운영 규칙의 선명도에 더 가깝다.

 

안드레이 카파시의 LLM Wiki gist는 새로운 제품 발표라기보다, LLM 시대에 지식을 어떻게 쌓을지에 대한 운영 패턴 제안에 가깝다. 파일을 올리고 질문할 때마다 다시 찾는 방식에서 한 걸음 나아가, LLM이 위키를 계속 갱신하며 사람과 문서 사이의 중간 기억층을 만든다는 발상이다.

이 아이디어가 주목받는 이유는 카파시의 이력과도 맞물린다. 그는 늘 학습, 구현, 연구 도구를 연결해 왔고, 이번에도 그 세 축이 그대로 드러난다. NotebookLM이나 Obsidian과 비교해 보면 차이도 더 뚜렷하다. 하나는 출처 기반 응답에 강하고, 다른 하나는 로컬 저장에 강하며, 카파시의 제안은 누적 편집 구조에 강하다. 결국 LLM Wiki의 질문은 하나다. LLM을 검색 도구로만 쓸 것인가, 아니면 오래 남는 지식 편집자로까지 쓸 것인가.

참고 자료

• LLM Wiki - Andrej Karpathy, 2026년 4월 4일
• Andrej Karpathy - Andrej Karpathy 공식 사이트, 2026년 4월 6일 확인
• karpathy (Andrej) · GitHub - GitHub 프로필, 2026년 4월 6일 확인
• Introducing Eureka Labs - Eureka Labs, 2024년 7월 16일
• Learn about NotebookLM - NotebookLM Help, 2026년 4월 6일 확인
• Introduction to Obsidian Web Clipper - Obsidian Help, 2026년 4월 6일 확인