Andrej Karpathy는 왜 LLM Wiki를 말했나

문제는 AI가 멍청해서가 아니다

AI와 오래 일해본 사람은 비슷한 피로를 느낀다. 모델의 답변 품질이 부족해서가 아니다. 진짜 피로는 매번 같은 맥락을 다시 설명해야 하는 데서 온다.

새 대화를 열면 AI는 이전 대화에서 어떤 결정을 했는지 모른다. 왜 A안이 아니라 B안을 골랐는지, 어떤 제약 때문에 특정 구조를 선택했는지, 지난주에 이미 검토한 자료가 무엇인지도 모른다. 우리는 다시 프로젝트 배경을 설명하고, 다시 파일을 올리고, 다시 판단 근거를 정리한다.

이 반복을 한두 번 할 때는 큰 문제가 아니다. 하지만 연구, 글쓰기, 제품 기획, 팀 운영처럼 긴 호흡의 작업에서는 상황이 달라진다. 매번 컨텍스트를 다시 주입하는 시간이 쌓이고, 중요한 결정의 이유는 채팅 기록 속에 흩어진다. AI는 똑똑한데, 작업 공간은 매번 초기화된다.

Andrej Karpathy가 LLM Wiki를 말한 출발점은 바로 여기에 있다. 핵심 문제는 LLM의 지능 부족이 아니라 작업 맥락의 휘발성이다. 모델은 한 번의 질문에는 잘 답하지만, 우리가 쌓아온 지식을 장기적으로 정리하고 유지하는 방식은 아직 약하다.

RAG는 매번 다시 찾는다

지금까지 문서 기반 AI 활용의 대표 방식은 RAG였다. RAG는 Retrieval-Augmented Generation의 줄임말이다. 쉽게 말하면, 질문을 받았을 때 관련 문서 조각을 검색해서 LLM에게 함께 넣어주고 답하게 하는 방식이다.

RAG는 유용하다. 회사 문서, 논문, 매뉴얼, 고객 상담 기록처럼 LLM이 원래 알지 못하는 자료를 답변에 반영할 수 있다. 환각도 줄일 수 있다. "근거 문서를 보고 답하라"는 구조를 만들 수 있기 때문이다.

하지만 Karpathy가 지적한 한계는 분명하다. 일반적인 RAG는 질문할 때마다 원문에서 관련 조각을 다시 찾고, 그 조각들을 즉석에서 조합해 답한다. 어제 비슷한 질문을 했어도, 오늘 다시 검색하고 다시 조립한다. 이전에 만든 좋은 비교, 판단, 연결 구조가 지식 베이스 안에 남지 않는다. Karpathy는 이런 방식을 "매 질문마다 지식을 처음부터 다시 발견하는 것"에 가깝다고 설명한다.¹

이것은 검색 시스템으로는 괜찮지만, 지식 축적 시스템으로는 부족하다. 검색은 "어디에 무엇이 있는가"를 찾는다. 축적은 "내가 무엇을 알고 있고, 왜 그렇게 판단했는가"를 남긴다. 둘은 비슷해 보이지만 완전히 다른 작업이다.

LLM Wiki의 핵심 발상

LLM Wiki의 발상은 단순하다.

원문 자료를 매번 검색해서 답변을 만들지 말고, LLM이 원문을 읽어 지속적으로 갱신되는 Markdown 위키를 만들게 하자는 것이다.

여기서 중요한 전환이 일어난다. AI는 더 이상 답변만 생성하는 도구가 아니다. AI는 지식 베이스를 관리하는 편집자가 된다. 새 자료가 들어오면 요약하고, 관련 개념 페이지를 갱신하고, 기존 주장과 충돌하는 부분을 표시하고, 필요한 내부 링크를 만든다. 질문에 대한 좋은 답변이 나오면 그 답변도 위키 페이지로 저장할 수 있다.

예를 들어 한 스타트업 대표가 고객 인터뷰 30개, 경쟁사 분석 글 20개, 회의록 50개를 가지고 있다고 해보자. RAG 방식에서는 질문할 때마다 관련 조각을 찾아 답변한다. 반면 LLM Wiki 방식에서는 "가격 민감도", "온보딩 문제", "경쟁사 A의 강점", "고객 세그먼트별 불만" 같은 페이지가 점점 두꺼워진다. 새 인터뷰가 들어올 때마다 관련 페이지가 갱신된다. 시간이 지나면 위키는 대표의 머릿속 판단 구조를 설명하는 지도에 가까워진다.

이 차이가 LLM Wiki의 핵심이다. 지식이 대화창에서 사라지지 않고, 파일로 남는다. 그리고 그 파일은 다음 질문의 기반이 된다.

제품이 아니라 패턴이다

LLM Wiki는 특정 앱 이름이 아니다. Notion, Obsidian, Claude Code, Cursor 같은 제품 중 하나를 뜻하지도 않는다. Karpathy의 원문도 구현체가 아니라 아이디어 파일에 가깝다. 각자의 도메인과 도구에 맞게 에이전트와 함께 구체화하라는 패턴이다.¹

대표 구조는 세 층으로 나뉜다.

첫째, raw/는 원본 저장소다. 웹 문서, 논문, PDF, 회의록, 유튜브 transcript, 책 챕터가 여기에 들어간다. 이 자료는 수정하지 않는다. 위키의 주장이 의심스러울 때 돌아갈 수 있는 증거층이다.

둘째, wiki/는 LLM이 관리하는 지식층이다. 개념 페이지, 인물 페이지, 프로젝트 페이지, 비교 페이지, 소스 요약 페이지가 들어간다. 인간이 직접 모든 페이지를 쓰는 것이 아니라, LLM이 원문을 읽고 요약·연결·갱신한다.

셋째, schema는 운영 규칙이다. Claude Code를 쓴다면 CLAUDE.md, Codex 계열을 쓴다면 AGENTS.md 같은 파일이 이 역할을 한다. 여기에는 페이지 작성 규칙, 출처 표기 방식, 업데이트 원칙, 모순 처리 방식, 사람이 검토해야 하는 조건을 적는다. 이 파일이 없으면 AI는 매번 임기응변으로 움직인다. 이 파일이 있으면 AI는 위키 관리자로 행동한다.

즉, LLM Wiki의 본질은 도구 조합이 아니라 역할 분리다. 인간은 자료를 고르고 방향을 정한다. LLM은 정리하고 연결하고 갱신한다. 원문은 증거로 남고, 위키는 해석으로 자란다.

세 가지 작업: ingest, query, lint

LLM Wiki는 한 번 만들어두는 노트가 아니다. 계속 돌아가는 운영 루프다. 이 루프는 세 가지 작업으로 이해하면 쉽다.

Ingest는 자료를 넣는 작업이다. 새 글이나 회의록을 raw/에 넣고 AI에게 처리하게 한다. AI는 원문을 읽고 요약 페이지를 만들며, 관련 개념 페이지를 갱신하고, index와 log를 업데이트한다. 중요한 점은 하나의 자료가 하나의 요약 파일로만 끝나지 않는다는 것이다. 좋은 ingest는 기존 위키의 여러 페이지를 동시에 바꾼다.

Query는 위키에 질문하는 작업이다. "이 주제에 대해 내가 아는 것은 무엇인가?", "A와 B의 차이는 무엇인가?", "최근 회의록에서 반복되는 고객 불만은 무엇인가?" 같은 질문을 던진다. AI는 원문 전체를 무작정 뒤지는 것이 아니라, 먼저 위키의 index를 보고 관련 페이지를 읽은 뒤 답을 합성한다. 그리고 가치 있는 답변은 다시 위키에 저장할 수 있다.

Lint는 위키를 점검하는 작업이다. 소프트웨어 개발에서 lint가 코드의 오류와 스타일 문제를 잡듯이, LLM Wiki의 lint는 지식 베이스의 건강 상태를 확인한다. 오래된 주장, 서로 충돌하는 페이지, 출처 없는 문장, 링크가 없는 고아 페이지, 중요하지만 독립 페이지가 없는 개념을 찾아낸다.

이 세 가지가 돌아가면 위키는 단순한 저장소가 아니라 살아 있는 시스템이 된다. 자료가 들어오고, 질문이 쌓이고, 점검을 통해 구조가 정리된다.

왜 Markdown인가

LLM Wiki에서 Markdown이 자주 언급되는 이유는 특별한 마법이 있어서가 아니다. 오히려 단순하기 때문이다.

Markdown은 사람이 읽기 쉽고, AI도 다루기 쉽다. 폴더와 파일로 구성되기 때문에 특정 서비스에 갇히지 않는다. Git으로 버전 관리도 할 수 있다. Obsidian으로 열면 위키 링크와 그래프 뷰를 통해 지식의 연결 구조를 볼 수 있다. Claude Code나 Cursor 같은 에이전트는 파일을 직접 읽고 수정할 수 있다.

복잡한 데이터베이스 없이도 시작할 수 있다는 점이 중요하다. 처음부터 벡터 DB, 임베딩 파이프라인, 검색 서버를 준비할 필요가 없다. 작은 개인 위키나 팀 위키라면 폴더와 Markdown만으로도 충분히 강력하다. 실제로 블로그 글 수백 개를 LLM Wiki 구조로 바꾸어 개념 페이지와 기술 페이지를 생성한 사례도 있다. 이 사례에서 핵심은 글 목록을 만드는 것이 아니라, 흩어진 글에서 반복되는 개념을 뽑아 새로운 지식 지도로 재구성했다는 점이다.²

인간과 LLM의 역할 분담

LLM Wiki가 흥미로운 이유는 인간의 역할을 없애지 않기 때문이다. 오히려 인간이 해야 할 일을 더 분명하게 만든다.

인간은 무엇을 위키에 넣을지 결정한다. 어떤 자료를 신뢰할지 판단한다. 어떤 질문이 중요한지 정한다. 최종 결론을 받아들일지, 보류할지, 반박할지 결정한다. 이것은 AI에게 쉽게 넘길 수 없는 일이다.

LLM은 반복 작업을 맡는다. 원문을 요약하고, 관련 페이지를 찾고, 내부 링크를 만들고, index를 갱신하고, 모순을 표시하고, 오래된 내용을 점검한다. 사람이 귀찮아서 미루는 작업이다. 하지만 바로 그 작업이 지식 베이스를 살아 있게 만든다.

Karpathy가 말한 통찰은 여기에 있다. 지식 베이스 운영에서 가장 힘든 것은 읽기나 생각 자체가 아니라, 요약을 최신 상태로 유지하고, 링크를 고치고, 관련 페이지를 업데이트하는 관리 작업이다.¹ 사람은 이 작업을 오래 지속하기 어렵다. LLM은 이 작업을 지치지 않고 할 수 있다.

LLM Wiki가 전환점인 이유

LLM Wiki는 유행어가 아니다. AI 작업 방식의 방향을 바꾸는 패턴이다.

이전 방식은 AI에게 질문하고 답을 받는 것이었다. 답변이 좋으면 복사해두고, 아니면 버렸다. 대화는 많아졌지만 지식은 쌓이지 않았다.

LLM Wiki 방식은 다르다. AI와 나눈 좋은 대화, 읽은 자료, 내린 판단, 발견한 모순을 모두 위키에 편입한다. 질문은 답변으로 끝나지 않고 새 페이지의 씨앗이 된다. 자료는 저장으로 끝나지 않고 기존 지식과 연결된다. 위키는 내가 무엇을 알고 있는지, 무엇을 아직 모르는지, 왜 그렇게 생각하게 되었는지를 보여준다.

결국 LLM Wiki의 핵심 메시지는 간단하다.

AI에게 매번 물어보는 사람은 매번 처음부터 시작한다. AI와 함께 위키를 쌓는 사람은 어제의 지식 위에서 오늘의 질문을 시작한다.

다음 장부터는 이 차이를 더 구체적으로 살펴볼 것이다. RAG는 무엇을 잘하고, 무엇을 놓치는가. 그리고 왜 이제 우리는 검색 기반 답변을 넘어, 축적 기반 지식 운영으로 이동해야 하는가.

참고

¹Andrej Karpathy, LLM Wiki Gist

²1000개 블로그 글을 LLM Wiki로 만든 이야기