2026년 4월 2일, 안드레이 카파시(Andrej Karpathy)가 X(구 트위터)에 짧은 글 하나를 올렸다. 제목은 LLM Knowledge Bases. OpenAI 공동 창립자이자 테슬라 AI 디렉터를 거친, 그리고 2025년 초 바이브코딩(Vibe Coding)이라는 용어를 세상에 던진 당사자가 이번에는 코드가 아니라 지식을 다루는 방법에 대해 이야기했다. 이 글은 GitHub Gist로 공개된 아이디어 파일과 함께 공유되었고, 이틀 만에 AI 커뮤니티 전체에 폭넓은 반향을 일으켰다.
카파시가 직접 밝힌 핵심 문장은 이렇다. "최근 내 토큰 처리량의 상당 부분이 코드를 조작하는 데 쓰이는 것이 아니라, 지식을 조작하는 데 쓰이고 있다." 바이브코딩의 창시자가 코드 생성을 넘어 지식 관리 쪽으로 무게 중심을 옮겼다는 선언은, AI를 활용하는 모든 실무자에게 다음 단계가 무엇인지를 시사한다.
이 글에서는 카파시가 공개한 LLM 지식 기반 위키의 구조와 핵심 아이디어를 분석하고, 바이브코딩에서 시작해 컨텍스트 엔지니어링을 거쳐 지식 컴파일로 이어지는 진화의 맥락을 짚는다. 그리고 바이브코딩과 AI를 다루는 개발자·크리에이터가 이 패러다임에서 어떤 통찰과 영감, 실행 아이디어를 가져갈 수 있는지 구체적으로 풀어본다.
1. 카파시가 제시한 LLM 지식 기반 위키의 구조
1.1 기존 RAG와 무엇이 다른가
- 대부분의 LLM 기반 문서 활용 경험은 RAG(Retrieval-Augmented Generation) 패러다임을 따른다. 문서를 업로드하면 벡터 임베딩으로 변환하고, 질문 시점에 유사도 검색으로 관련 청크를 찾아 답변을 생성하는 방식이다. NotebookLM, ChatGPT 파일 업로드, 대다수의 기업용 RAG 시스템이 이 구조를 쓴다.
- 이 방식의 한계는 축적이 없다는 점이다. 매번 질문할 때마다 LLM이 처음부터 관련 조각을 찾아 조합해야 하고, 다섯 개 문서를 교차 종합해야 하는 미묘한 질문에서는 매번 같은 탐색을 반복한다. 지식이 쌓이지 않는다.
- 카파시의 접근은 근본적으로 다르다. 원본 문서에서 질의 시점에 검색하는 대신, LLM이 점진적으로 구조화된 위키를 빌드하고 유지한다. 새 소스가 추가되면 LLM은 그것을 읽고, 핵심 정보를 추출하며, 기존 위키에 통합한다. 엔티티 페이지를 업데이트하고, 주제 요약을 수정하고, 새 데이터가 기존 주장과 모순되는 부분을 표시하며, 진화하는 종합 결과를 강화하거나 도전한다.
- 핵심 차이는 위키가 영속적이고 복리로 성장하는 산출물이라는 점이다. 교차 참조는 이미 만들어져 있고, 모순은 이미 표시되어 있으며, 종합은 그때까지 읽은 모든 것을 반영한다.
1.2 세 개의 계층 아키텍처
- 원시 소스(raw/): 사용자가 직접 수집한 문서 컬렉션이다. 논문, 기사, 이미지, 데이터 파일 등을 넣는다. 이 계층은 불변이며 LLM은 읽기만 할 뿐 수정하지 않는다. 진실의 원천(source of truth) 역할을 한다.
- 위키(wiki/): LLM이 생성하고 관리하는 마크다운 파일 디렉터리이다. 요약, 엔티티 페이지, 개념 페이지, 비교 문서, 개요, 종합 분석이 여기에 쌓인다. LLM이 이 계층을 전적으로 소유한다. 페이지를 만들고, 새 소스가 들어오면 업데이트하며, 교차 참조를 유지하고, 전체 일관성을 관리한다. 사용자는 읽기만 한다.
- 스키마: LLM에게 위키 구조, 규칙, 워크플로를 알려주는 문서이다. Claude Code의
CLAUDE.md나 Codex의AGENTS.md같은 파일이 이 역할을 한다. 이 파일이 LLM을 일반적인 챗봇이 아니라 규율 있는 위키 관리자로 만들어 주며, 사용자와 LLM이 함께 진화시킨다.
핵심 포인트: 카파시의 아키텍처는 원시 소스(불변) → LLM 컴파일(위키) → 스키마(규칙)의 3계층으로 나뉜다. RAG처럼 질의 시점에 매번 검색하는 것이 아니라, 소스가 추가될 때마다 위키를 점진적으로 갱신하므로 지식이 복리로 축적된다.
1.3 세 가지 핵심 운영 모드
- 수집(Ingest): 새로운 소스를 raw/ 디렉터리에 넣고 LLM에게 처리하라고 지시한다. LLM은 소스를 읽고, 핵심 내용을 논의하며, 위키에 요약 페이지를 작성하고, 인덱스를 업데이트하며, 관련 엔티티·개념 페이지를 수정하고, 로그에 기록을 남긴다. 하나의 소스가 10~15개 위키 페이지에 영향을 줄 수 있다.
- 질의(Query): 위키에 질문을 던지면 LLM이 관련 페이지를 찾아 읽고 종합 답변을 제공한다. 답변은 마크다운 페이지, 비교 테이블, Marp 슬라이드 덱, matplotlib 차트 등 다양한 형식으로 출력된다. 중요한 통찰은 좋은 답변이 다시 위키에 새 페이지로 저장된다는 점이다. 질문에서 얻은 분석과 연결이 채팅 히스토리에 사라지지 않고 지식 기반에 축적된다.
- 검수(Lint): 주기적으로 LLM에게 위키 건강 점검을 요청한다. 페이지 간 모순, 새 소스로 대체된 낡은 주장, 인바운드 링크 없는 고아 페이지, 언급되었지만 자체 페이지가 없는 중요 개념, 누락된 교차 참조, 웹 검색으로 채울 수 있는 데이터 공백 등을 찾는다.
2. 바이브코딩에서 지식 컴파일까지 – 카파시 사고의 진화
2.1 네 단계의 패러다임 변화
카파시가 LLM 활용 방식에 대해 공개적으로 발언한 궤적을 추적하면, 분명한 진화 경로가 보인다.
| 시점 | 개념 | 핵심 변화 |
|---|---|---|
| 2025년 2월 | 바이브코딩 | 코드의 존재를 잊고 AI에게 맡기기. 결과만 중요 |
| 2025년 6월 | 컨텍스트 엔지니어링 | 프롬프트보다 맥락 설계가 중요하다는 선언 |
| 2025년 12월 | 에이전틱 엔지니어링 | 인간이 1% 미만의 코드를 쓰고 AI 에이전트를 지휘 |
| 2026년 4월 | LLM 지식 기반 | 코드를 넘어 지식 자체를 컴파일하고 관리 |
- 바이브코딩(2025년 2월)은 코드를 일회성 소모품으로 취급하는 발상이었다. 자연어로 원하는 것을 설명하면 AI가 코드를 쓰고, 개발자는 결과만 확인한다. 코드 리뷰도 최소화한다. 이 개념은 폭발적으로 확산되어 2025년의 프로그래밍 문화를 바꿔놓았다.
- 컨텍스트 엔지니어링(2025년 6~7월)은 카파시가 "프롬프트 엔지니어링보다 컨텍스트 엔지니어링을 선호한다"고 밝히면서 주목받았다. 단순히 질문을 잘 하는 것이 아니라, LLM에게 제공하는 전체 맥락을 정교하게 설계하는 것이 핵심이라는 통찰이다.
- 에이전틱 엔지니어링(2025년 12월~2026년 1월)은 바이브코딩의 규율 있는 후속 단계였다. 인간이 거의 코드를 쓰지 않되, AI 에이전트를 구조적으로 지휘하고 감독하는 방식이다.
- 그리고 LLM 지식 기반(2026년 4월)은 아예 코드를 넘어선다. LLM이 관리하는 것이 소프트웨어가 아니라 지식 자체다. 마크다운이 프로그래밍 언어가 되고, 위키가 코드베이스가 되며, LLM이 컴파일러가 되는 구조다.
핵심 포인트: 바이브코딩 → 컨텍스트 엔지니어링 → 에이전틱 엔지니어링 → 지식 컴파일로 이어지는 카파시의 궤적은 LLM 활용의 무게 중심이 '코드 생성'에서 '지식 관리'로 이동하고 있음을 보여준다.
2.2 컴파일러 비유의 함의
- 카파시의 시스템을 소프트웨어 빌드 파이프라인에 비유하면 이렇다.
raw/는 소스 코드, LLM은 컴파일러, 위키는 실행 파일, 헬스 체크는 테스트 스위트, 질의는 런타임이다. - 이 비유가 강력한 이유는, 소프트웨어에서 소스 코드를 매번 인터프리팅하는 대신 컴파일해서 최적화된 바이너리를 만드는 것처럼, 원시 문서를 매번 검색하는 대신 사전에 종합·구조화해 두는 것이 효율적이라는 직관을 전달하기 때문이다.
- VentureBeat의 분석에 따르면, 기존 벡터 DB와 RAG가 "매우 빠른 지게차가 있는 정리되지 않은 거대한 창고"라면, 카파시의 마크다운 위키는 "옛 책을 설명하는 새 책을 끊임없이 집필하는 수석 사서가 운영하는 도서관"과 같다.
3. 이 아키텍처가 작동하는 이유와 커뮤니티 반응
3.1 유지보수 비용의 제로화
- 지식 기반을 유지하는 것에서 힘든 부분은 읽기나 사고가 아니라 장부 정리(bookkeeping)이다. 교차 참조 업데이트, 요약 최신화, 새 데이터가 오래된 주장과 모순되는지 표시, 수십 페이지 간 일관성 유지. 인간은 유지보수 부담이 가치보다 빠르게 커지면 위키를 포기한다.
- LLM은 지루해하지 않고, 교차 참조 업데이트를 잊지 않으며, 한 번에 15개 파일을 건드릴 수 있다. 유지보수 비용이 사실상 제로에 가깝기 때문에 위키가 유지된다.
- 카파시는 이 점을 바네바 부시(Vannevar Bush)의 메멕스(Memex) 개념(1945년)과 연결한다. 메멕스는 문서 사이에 연상적 경로(associative trails)가 있는 개인 지식 저장소라는 비전이었다. 부시가 해결하지 못한 부분이 바로 "누가 유지보수를 하느냐"였는데, LLM이 그 역할을 맡는다.
3.2 주요 커뮤니티 반응
- 스텝 앙고(Steph Ango, Obsidian CEO): 개인 볼트는 깨끗하게 유지하고, 에이전트가 생성한 콘텐츠는 별도의 "지저분한 볼트"에서 작업한 뒤 검증된 결과만 가져오라고 제안했다. 지식 출처의 오염 방지(contamination mitigation) 개념이다.
- 엘비스 사라비아(Elvis Saravia, DAIR.AI): "나도 LLM 지식 기반 구축에 몰두하고 있다. LLM은 데이터가 적절히 구조화되면 큐레이팅과 연결 발견에 탁월하다"고 확인했다.
- 렉스 프리드먼(Lex Fridman): 유사한 셋업을 쓰며, "동적 HTML과 JS로 데이터를 정렬·필터하고 시각화를 대화식으로 탐색한다. 7~10마일 달리기 중 음성 모드로 상호작용할 임시 미니 지식 기반을 생성하기도 한다"고 덧붙였다.
- 커뮤니티 전반의 핵심 논쟁: LLM이 두 개념 사이에 허구의 연결을 만들어내면(할루시네이션), 그 잘못된 링크가 위키에 남아 이후 질의에 영향을 줄 수 있다는 신뢰성 우려가 제기되었다. 대응 방안으로는 앙고의 볼트 분리, 카파시의 헬스 체크, 그리고 모든 위키 문서를 raw/ 소스에 역추적 가능하게 연결하는 방법이 논의된다.
| 비교 항목 | 벡터 DB/RAG | 카파시 마크다운 위키 |
|---|---|---|
| 데이터 형식 | 불투명한 벡터(수학) | 사람이 읽을 수 있는 마크다운 |
| 연결 방식 | 의미 유사도(최근접 이웃) | 명시적 연결(백링크/인덱스) |
| 감사 가능성 | 낮음(블랙박스) | 높음(직접 추적 가능) |
| 지식 축적 | 정적(재인덱싱 필요) | 능동적(린팅으로 자가 치유) |
| 적합 규모 | 수백만 건의 문서 | 100~10,000건의 고신호 문서 |
4. 바이브코딩·AI 실무자가 얻을 수 있는 통찰과 아이디어
4.1 코드에서 지식으로 – 역할의 전환
- 바이브코딩에서 개발자는 프롬프트를 쓰고 결과를 수락했다. 에이전틱 엔지니어링에서는 에이전트를 지휘했다. 지식 기반 패러다임에서 개발자의 역할은 큐레이터이자 질문자로 바뀐다. 어떤 소스를 수집할지, 어떤 질문을 던질지, 컴파일된 지식을 어떻게 검증할지를 결정하는 것이 핵심 역량이 된다.
- 이 전환은 AI 코딩 도구(GitHub Copilot, Cursor, Claude Code 등)의 대화가 코드 생성에 집중되어 있던 것을 넘어, 도메인 지식의 깊이가 병목이라는 인식의 변화를 반영한다. 무엇을 만들지를 깊이 이해하는 것이, 코드를 쓰는 것보다 어려운 문제가 된다.
- 실무적으로 이는 AI를 활용하는 사람이 "프롬프트 잘 치는 사람"에서 "최고의 지식 시스템을 가진 사람"으로 경쟁력의 축이 이동함을 뜻한다.
4.2 마크다운이 AI 시대의 프로그래밍 언어가 되는 이유
- 카파시 워크플로의 모든 단계에서 마크다운이 사용된다. 원시 문서도 마크다운, 위키도 마크다운, 출력물도 마크다운(혹은 Marp 같은 마크다운 파생 포맷)이다.
- 마크다운은 사람이 읽고 쓸 수 있고, LLM이 대량으로 학습한 포맷이며, Git으로 버전 관리가 되고, 어떤 도구에도 종속되지 않으며, 일반 텍스트이므로 수십 년 후에도 사용 가능하다.
- 바이브코더에게 이 점이 시사하는 바는 크다. 프로젝트 컨텍스트를
CLAUDE.md,AGENTS.md,GEMINI.md같은 마크다운 파일로 정리해 두면, 그것이 곧 AI 에이전트에 대한 프로그래밍이 된다. 코드를 짜지 않아도 마크다운으로 에이전트의 행동을 프로그래밍하는 셈이다.
4.3 실무 적용 아이디어 7가지
- 개인 연구 위키 구축: 관심 주제에 대한 기사, 논문, 유튜브 트랜스크립트를 raw/에 모으고, LLM에게 주제별 위키를 컴파일하게 한다. 카파시는 하나의 연구 주제에 대해 약 100개 문서, 40만 단어 규모의 위키를 운영 중이다.
- 바이브코딩 프로젝트의 컨텍스트 유실 해결: 바이브코딩의 가장 큰 고충 중 하나는 세션이 끝나면 맥락이 사라지는 것이다. 프로젝트별 위키를 운영하면 아키텍처 결정, 디버깅 이력, 설계 원칙이 영속적으로 유지되어 새 세션에서 LLM이 처음부터 다시 맥락을 파악할 필요가 없다.
- 경쟁 분석 시스템: 경쟁사 웹사이트, 제품 변경 이력, 채용 공고, 보도자료를 raw/에 넣으면 LLM이 기업 프로필, 기능 비교 매트릭스, 채용 트렌드, 전략 방향 분석이 담긴 경쟁 정보 위키를 컴파일한다.
- 팀 내부 지식 기반: 슬랙 스레드, 회의 녹취, 프로젝트 문서, 고객 통화 기록을 수집해 LLM이 유지관리하는 팀 위키를 운영한다. 아무도 하고 싶어 하지 않는 문서 정리를 LLM이 대신한다.
- 독서·학습 동반자: 책을 읽으면서 각 장을 소스로 넣으면 캐릭터, 주제, 줄거리 연결이 정리된 위키가 만들어진다. 톨킨 게이트웨이 같은 팬 위키를 개인 수준에서 자동 구축하는 셈이다.
- 크리에이터 콘텐츠 아카이브: 유튜브 스크립트, 블로그 포스트, 팟캐스트 노트를 모아 LLM에게 주제별·키워드별 위키를 만들게 하면, 과거 콘텐츠에서 재활용할 소재와 아직 다루지 않은 주제 공백을 자동으로 발견할 수 있다.
- 기술 실사(Due Diligence): 대상 기업의 공개 저장소, 문서, 블로그, 기술 스택 증거를 수집해 아키텍처 패턴, 기술 부채 신호, 팀 전문성 분포를 위키로 종합한다. 한 분석가는 이 방식으로 실사 기간을 2주에서 3일로 단축했다고 보고했다.
핵심 포인트: 카파시의 패턴은 연구뿐 아니라 바이브코딩 프로젝트의 맥락 유지, 경쟁 분석, 팀 지식 관리, 콘텐츠 기획 등 AI를 활용하는 거의 모든 영역에 적용 가능하다. 핵심은 LLM에게 장부 정리를 위임하고, 인간은 큐레이션과 질문에 집중하는 분업이다.
5. 주의해야 할 한계와 균형 잡힌 시각
5.1 호르메시스 문제 – 직접 쓰지 않으면 사고가 깊어지는가
- Extended Brain 뉴스레터의 심층 분석은 독일 사회학자 니클라스 루만(Niklas Luhmann)의 제텔카스텐(Zettelkasten)과 카파시 시스템을 비교하며 중요한 경고를 던진다. 루만은 원천 자료를 자신의 말로 다시 쓰는 행위 자체가 사고의 핵심 메커니즘이라고 보았다. 번역이 잘 안 되는 지점, 자신의 표현이 무너지는 지점이 바로 진짜 이해가 일어나는 순간이다.
- 생물학에서 말하는 호르메시스(hormesis)와 같다. 근육은 저항을 만나야 성장하고, 면역 체계는 도전에 노출되어야 학습한다. 어려운 아이디어를 자기 말로 표현하려 할 때 느끼는 마찰은 비효율이 아니라, 통합이 실제로 일어나고 있다는 신호다.
- 카파시의 시스템은 설계상 이 마찰을 제거한다. LLM이 유창하고 정돈된 종합 문서를 쓰고, 사용자는 그것을 읽는다. 이때 사용자는 주제를 이해한다고 느낄 수 있지만, 자신의 개념적 아키텍처에 지식을 구축하는 호르메틱 작업을 하지 않았을 수 있다.
5.2 실용적 대응 방안
- 하이브리드 접근: LLM이 연결과 구조를 발견하게 하되, 핵심 종합은 직접 쓴다. LLM의 위키를 "지도(map)"로 활용하고, 실제 "영토를 걷는 것(walking the territory)"은 자신이 한다.
- 모순의 보존: 헬스 체크에서 LLM이 모순을 해결하게 하는 대신, 모순을 표면화하고 그 상태로 남기게 한다. "당신의 코퍼스에서 긴장 관계에 있는 세 가지가 있다" – 그 긴장이 사고의 선물이다.
- 볼트 분리: Obsidian CEO 앙고의 제안처럼 인간이 큐레이션한 지식과 AI가 컴파일한 지식을 물리적으로 분리해, 어떤 지식이 어디서 왔는지 항상 추적 가능하게 한다.
- 할루시네이션 추적: 모든 위키 문서를 원시 소스(raw/)에 역링크로 연결해, 모든 주장이 출처까지 추적 가능하도록 만든다.
6. 도구 생태계와 시작 방법
6.1 핵심 도구 스택
| 도구 | 역할 | 비고 |
|---|---|---|
| Obsidian | 위키 프론트엔드(읽기·그래프 시각화) | 로컬 파일 기반, 무료 개인 사용 |
| Obsidian Web Clipper | 웹 기사를 마크다운으로 변환 | 브라우저 확장 프로그램 |
| Claude Code / Codex | LLM 에이전트(컴파일·질의·린트 실행) | 터미널 기반 에이전틱 코딩 도구 |
| qmd | 마크다운 파일 검색 엔진 | BM25/벡터 하이브리드, CLI + MCP 서버 |
| Marp | 마크다운 기반 슬라이드 덱 | Obsidian 플러그인으로 사용 가능 |
| Dataview | Obsidian 플러그인, 프론트매터 쿼리 | YAML 메타데이터 기반 동적 테이블 |
| Git | 위키 버전 관리 | 컴파일 히스토리, 롤백, 협업 |
6.2 최소 실행 단계
- Obsidian과 Web Clipper를 설치한다. Obsidian은 무료이며 로컬 파일 기반이다.
- 프로젝트 폴더 안에
raw/,wiki/,output/디렉터리를 만든다. - 관심 주제에 대한 기사 10개를 raw/에 클리핑한다.
- LLM 에이전트(Claude Code, Codex 등)에게 컴파일 프롬프트를 제공한다. 핵심 지시는 raw/의 모든 파일을 읽고, 주요 개념을 식별하며, 개념당 하나의 마크다운 문서를 wiki/에 작성하고, 위키링크로 연결하며, INDEX.md를 업데이트하라는 것이다.
- 첫 컴파일을 실행한다. 이후에는 새로 추가된 raw/ 파일만 증분 빌드하면 되므로 빠르다.
- 위키에 질문을 던져 본다. "X와 Y의 핵심 차이는 위키 기준으로 무엇인가?" 같은 질문으로 시작한다.
- 주기적으로 헬스 체크를 실행해 모순, 누락된 링크, 빈약한 문서, 고아 개념을 찾는다.
핵심 포인트: 카파시의 40만 단어 위키를 하루 만에 복제할 필요는 없다. 기사 10개와 하나의 컴파일 프롬프트로 시작해, 구조화된 출력이 개별 기사를 따로 읽는 것보다 더 깊은 통찰을 주는지 확인해 보는 것이 첫걸음이다.
7. 마무리
위에서 살펴본 안드레이 카파시의 LLM 지식 기반 위키와 그것이 바이브코딩·AI 실무자에게 주는 통찰의 핵심 내용을 정리하면 다음과 같습니다.
핵심 요약:
- 카파시의 LLM 지식 기반은 RAG의 "매번 검색" 패러다임 대신 LLM이 점진적으로 구조화된 마크다운 위키를 컴파일하고 유지하는 방식이다
- 바이브코딩(2025) → 컨텍스트 엔지니어링 → 에이전틱 엔지니어링 → 지식 컴파일(2026)로 이어지는 진화는 LLM 활용의 무게 중심이 코드에서 지식으로 이동하고 있음을 보여준다
- 위키는 원시 소스(불변) · 컴파일된 위키(LLM 소유) · 스키마(규칙) 3계층으로 구성되며, 수집·질의·검수 세 가지 운영 모드로 작동한다
- 마크다운은 사람이 읽을 수 있고, LLM이 학습한 포맷이며, Git 버전 관리가 가능해 AI 시대의 범용 인터페이스 역할을 한다
- 할루시네이션과 사고의 깊이 약화(호르메시스 문제)는 실질적 한계이며, 볼트 분리·소스 역추적·직접 쓰기의 하이브리드 접근으로 보완해야 한다
- 기사 10개와 컴파일 프롬프트 하나로 시작할 수 있으며, 규모는 필요에 따라 점진적으로 확장하면 된다
이 패러다임을 실무에 도입할 때 가장 중요한 판단 기준은 "LLM에게 장부 정리를 위임하되, 핵심 사고와 판단은 자신이 직접 하는가"이다. 카파시의 시스템이 제시하는 것은 지식의 자동 생성이 아니라, 인간이 더 좋은 질문을 더 빠르게 던질 수 있는 구조적 토대다. 바이브코딩으로 코드를 생성하고 있다면, 그 다음 단계로 지식 기반을 구축하는 것이 자연스러운 진화 경로가 될 것이다.