Karpathy LLM Wiki - 개인 지식을 AI와 공유하는 새로운 방법

AI와 일하다 보면 반복되는 답답함이 있습니다. 어제 설명한 내용을 오늘 또 설명해야 합니다. 내 프로젝트 구조, 팀의 코딩 컨벤션, 자주 쓰는 용어들을 매번 처음부터 알려줘야 합니다. 모델은 능력이 있지만, 내 세계를 모릅니다.

Andrej Karpathy가 2026년 4월 공개한 LLM Wiki는 이 문제에 대한 하나의 답입니다. 핵심은 단순합니다. AI에게 컨텍스트를 주면 됩니다. 그것도 매번 설명하는 게 아니라, 미리 정리해두고 필요할 때 꺼내 쓰는 방식으로.

이 글은 KMS(Knowledge Management System) 시리즈의 첫 편입니다. LLM Wiki가 무엇인지, 실제로 어떻게 쓰이는지, 그리고 어디서 무너지는지를 다룹니다. 이후 편에서는 GraphRAG, 온톨로지, Agent Memory 방식을 차례로 비교합니다.

아이디어의 출발점: CLAUDE.md에서 Wiki로

카파시의 아이디어는 사실 새로운 것이 아닙니다. 개발자라면 이미 CLAUDE.md 또는 CURSOR.md 같은 파일을 써본 적 있을 겁니다. 프로젝트 루트에 두면, AI가 대화 시작 전에 그 파일을 읽고 "아, 이 프로젝트는 이런 구조구나"를 미리 파악합니다.

카파시는 이 패턴을 개인 지식 전체로 확장했습니다. 코드베이스 하나가 아니라, 내가 매일 다루는 모든 도메인에 대해 마크다운 파일을 써두는 겁니다. 그리고 AI와 대화할 때 관련 파일들을 컨텍스트로 넣으면, 모델은 그 내용을 읽고 전문가처럼 행동합니다.

my-wiki/
  aws-infra.md       ← 우리 인프라 구조, 서버 명명 규칙, 포트 정리
  team-norms.md      ← 코드 리뷰 기준, 브랜치 전략, 배포 절차
  domain-terms.md    ← 사내 전용어, 약어, 프로젝트 코드명
  personal-style.md  ← 내 글쓰기 톤, 자주 쓰는 프레임워크, 선호 패턴

구조 자체는 이렇게 단순합니다. 마크다운 파일 묶음입니다. 데이터베이스도 없고, 벡터 인덱스도 없습니다. 파일을 쓰고, 필요할 때 컨텍스트에 넣으면 끝입니다.

외부 기억으로서의 위키

이 개념을 에이전트 관점에서 정리한 곳이 있습니다. AAIF의 분석은 LLM Wiki를 "외부 기억(External Memory)"의 한 형태로 봅니다.

AI 에이전트의 기억은 크게 네 가지로 구분됩니다.

LLM Wiki는 두 번째, 외부 기억에 해당합니다. 모델을 재학습하지 않아도 되고, 복잡한 RAG 파이프라인 없이도 원하는 지식을 AI에게 줄 수 있습니다. 그리고 인간이 읽을 수 있는 형식이기 때문에 직접 편집하고 검증할 수 있습니다.

이것이 RAG나 파인튜닝과 구별되는 핵심입니다. 파인튜닝은 모델 가중치를 바꾸는 고비용 작업이고, RAG는 검색 인프라가 필요합니다. LLM Wiki는 텍스트 파일 하나로 시작합니다.

실제 도입 사례: 무엇이 효과가 있었나

개념이 좋아 보여도 실제로 써봐야 알 수 있습니다. 두 개의 솔직한 후기를 살펴봅니다.

Tom Nguyen — AWS 인프라 위키 77페이지

클라우드 엔지니어 Tom Nguyen은 자신의 후기에서 AWS 인프라 전체를 77페이지 위키로 정리했습니다. VPC 구조, IAM 정책 패턴, 사내 Lambda 네이밍 규칙까지 담았습니다. 결과는 절반의 성공이었습니다.

효과가 있었던 부분은 명확합니다. "우리 prod 환경 ALB 앞에 WAF 붙여줘"라고 하면, AI가 위키를 읽고 실제 리소스 명명 규칙에 맞게 코드를 작성했습니다. 매번 "우리 네이밍 컨벤션은 이렇고..."라고 설명하지 않아도 됐습니다.

실패한 부분도 솔직하게 적었습니다. 위키가 오래되면 현실과 어긋납니다. 인프라가 바뀌는데 위키가 따라가지 못하면, AI가 오래된 정보를 기반으로 잘못된 제안을 합니다. "정확한 위키는 오히려 아무것도 없는 것보다 나쁠 수 있습니다." 구식 정보가 틀린 자신감을 만들기 때문입니다.

Jim Liu — 6개월 글쓰기 보조 35페이지

글쓰기 보조 용도로 위키를 쓴 Jim Liu의 사례는 더 안정적이었습니다. 35페이지 분량에 자신의 글쓰기 톤, 자주 쓰는 논증 구조, 독자 페르소나를 정리했습니다. 6개월 사용 후에도 유효했습니다.

차이는 도메인의 변화 속도입니다. 인프라는 자주 바뀝니다. 글쓰기 스타일은 천천히 바뀝니다. 안정적인 도메인일수록 위키의 유효 기간이 깁니다.

한계와 실패 모드

LLM Wiki가 널리 퍼지면서 비판도 함께 나왔습니다. 솔직히 다뤄야 할 내용들입니다.

토큰 비용 문제

소프트웨어 엔지니어 Artem Zhutov는 질문 하나에 평균 44,000 토큰을 쓰고 있다고 측정했습니다. 위키 전체가 컨텍스트에 들어가기 때문입니다. 그는 결국 NotebookLM으로 이탈했습니다.

이것은 LLM Wiki의 구조적 한계입니다. 관련 파일만 선택적으로 넣으면 해결할 수 있지만, 그러면 어떤 파일을 넣을지 사람이 판단해야 합니다. 자동화하면 RAG와 비슷해집니다.

유지보수 포기

gpters 커뮤니티에는 "위키만 만들면 3일 만에 안 쓴다"는 후기가 여럿입니다. 위키는 글을 써야 유지됩니다. 바쁜 날이 이어지면 업데이트가 밀리고, 오래된 위키는 신뢰할 수 없게 됩니다.

HN 토론에서는 더 날카로운 지적도 나왔습니다. 위키를 계속 업데이트하면, 위키가 모델의 출력물을 정리한 것들로 채워지기 시작합니다. AI가 생산한 내용이 AI의 컨텍스트로 다시 들어가는 구조입니다. "위키가 유능한 타인의 백과사전이 되어버린다"는 표현이 이를 잘 요약합니다.

환각 누적

Mehul Gupta의 비판은 더 구조적입니다. 위키에 검증되지 않은 내용이 하나 들어가면, AI가 그것을 사실로 받아들이고 이후 추론에 반영합니다. 틀린 전제가 위키 전체에 스며들 수 있습니다.

이 문제는 위키를 AI로 자동 생성할 때 특히 심각합니다. 사람이 직접 쓴 위키라면 본인이 검증할 수 있지만, AI 요약으로 채운 위키는 오류를 감지하기 어렵습니다.

효과적인 LLM Wiki의 조건

그럼에도 잘 작동하는 사례들이 있습니다. 공통점을 정리하면 이렇습니다.

안정적인 도메인을 선택합니다. 자주 바뀌는 정보는 위키로 관리하기 어렵습니다. 팀의 코딩 철학, 내 글쓰기 톤, 프로젝트의 핵심 아키텍처 결정 배경 같은 것들은 변화가 느립니다. 반면 API 스펙, 환경 변수, 서버 목록은 공식 문서나 실제 시스템을 직접 참조하는 게 낫습니다.

파일을 작게 유지합니다. 하나의 파일이 길어지면 AI가 관련 없는 내용까지 읽습니다. 주제별로 파일을 쪼개고, 각 파일은 500단어 내외로 유지하는 것이 효과적입니다.

선택적으로 넣습니다. 모든 파일을 항상 넣지 않습니다. 지금 하는 작업과 관련된 파일만 컨텍스트에 포함합니다. Claude Code의 경우 CLAUDE.md가 이 역할을 합니다. 프로젝트별로 다른 컨텍스트를 자동으로 로드합니다.

업데이트를 작업 흐름에 붙입니다. 따로 시간 내서 위키를 업데이트하는 방식은 지속되지 않습니다. 어떤 작업을 마칠 때 "오늘 배운 것 중 위키에 넣을 게 있나?" 하고 짧게 확인하는 루틴이 더 오래 갑니다.

다음 편 예고: LLM Wiki는 사다리의 어디쯤 있나

LLM Wiki는 개인 수준에서 빠르게 시작할 수 있는 방법입니다. 하지만 팀 단위, 조직 단위로 가면 더 정교한 구조가 필요해집니다.

이 시리즈에서 다룰 방법론들을 미리 소개합니다.

다음 편에서는 Graph RAG를 다룹니다. 단순 벡터 검색(RAG)의 한계를 그래프 구조로 극복하는 방법, 그리고 LLM Wiki와 GraphRAG를 함께 쓰는 패턴을 살펴봅니다.

참고 자료: 카파시 LLM Wiki 원본 gist / AAIF Agent Memory 해석 / Tom Nguyen 후기 / HN 토론