안녕하세요, Tom입니다. 이 블로그를 3개월 넘게 운영하면서 한 가지 답답한 점이 있었어요. 뉴스를 발행할 때마다 매번 제로에서 시작한다는 거예요. "지난달에 OpenAI가 뭘 발표했더라?", "Claude Code 버전이 지금 몇이지?" 같은 맥락이 전혀 축적되지 않더라고요. 107개 포스트를 발행했는데, 그 지식이 다음 포스트에 영향을 주지 못하는 구조였어요. 그러던 중 Andrej Karpathy가 4월 초에 공유한 LLM Wiki라는 개념을 보고, 이거다 싶었습니다. 오늘은 이 패턴이 뭔지 소개하고, 실제로 이 블로그에 적용한 과정을 공유할게요. ## Karpathy의 LLM Wiki란? Karpathy는 OpenAI 공동 창업자이자 Tesla AI 디렉터 출신인데, 이번에 공유한 건 코드가 아니라 하나의 아이디어 문서예요. GitHub Gist로 올린 마크다운 파일 하나인데, 핵심은 이거예요. "LLM이 매번 원본 문서를 뒤지는 대신, 점진적으로 위키를 구축하고 유지하게 하자." 보통 LLM으로 문서를 다룰 때 RAG(Retrieval-Augmented Generation) 방식을 쓰잖아요. 질문할 때마다 관련 문서 조각을 찾아서 답변에 끼워넣는 방식이요. NotebookLM, ChatGPT 파일 업로드, 대부분의 RAG 시스템이 이렇게 동작해요. 문제는 매번 처음부터 다시 탐색한다는 거예요. 지식이 쌓이질 않아요. LLM Wiki는 다릅니다. 새로운 소스가 들어오면 LLM이 그걸 읽고, 핵심을 추출하고, 기존 위키에 통합해요. 엔티티 페이지를 업데이트하고, 토픽 요약을 수정하고, 새 데이터가 기존 내용과 모순되면 그것도 표시해요. 한번 정리된 지식은 다시 정리할 필요가 없어요. 위키는 영구적이고, 복리로 쌓이는 자산이에요. ## 3-Layer 구조 Karpathy가 제안한 구조는 세 겹으로 되어 있어요. 첫 번째, Raw Sources. 원본 문서들이에요. 기사, 논문, 데이터 파일 같은 것들. LLM은 여기서 읽기만 하고 수정하지 않아요. 이게 진실의 원천이에요. 두 번째, Wiki. LLM이 생성하고 유지하는 마크다운 파일 모음이에요. 요약, 엔티티 페이지, 개념 페이지, 비교 분석 같은 것들. LLM이 이 레이어를 완전히 소유해요. 페이지를 만들고, 새 소스가 들어오면 업데이트하고, 교차 참조를 유지하고, 일관성을 맞춰요. 사람은 읽기만 하면 돼요. 세 번째, Schema. LLM에게 위키 구조, 규칙, 워크플로우를 알려주는 설정 문서예요. Claude Code에서는 CLAUDE.md가 이 역할을 해요. 이게 LLM을 "범용 챗봇"이 아닌 "규율 잡힌 위키 관리자"로 만들어주는 핵심이에요. ## RAG vs LLM Wiki, 뭐가 다른가? 둘 다 "LLM에게 외부 지식을 주는 방법"이지만, 접근이 근본적으로 달라요. | 항목 | RAG | LLM Wiki | | -------------- | ---------------------- | -------------------------- | | 지식 처리 시점 | 질문할 때마다 (실시간) | 소스 추가 시 (사전 컴파일) | | 축적 여부 | 없음 (매번 리셋) | 복리로 축적 | | 교차 참조 | 매번 재발견 | 이미 연결되어 있음 | | 모순 감지 | 어려움 | 자동 플래그 | | 인프라 | 벡터 DB, 임베딩, 청킹 | 마크다운 파일 | | 적합한 규모 | 수천~수만 문서 | 수백 문서 이하 | RAG가 쓸모없다는 얘기가 아니에요. 수천 개 문서, 실시간 업데이트가 필요한 대규모 시스템에서는 RAG가 맞아요. 하지만 개인 지식 베이스나 이 블로그처럼 수백 건 규모에서는 LLM Wiki가 훨씬 실용적이에요. VentureBeat 보도에 따르면 Karpathy 본인도 약 100개 기사, 40만 단어 규모에서 이 패턴을 쓰고 있다고 해요. 벡터 DB도, 임베딩 파이프라인도 없이 마크다운 파일만으로요. ## 실제 적용: 이 블로그에 위키를 달았다 얘기만 하면 재미없으니까, 실제로 이 블로그에 적용한 과정을 보여드릴게요. ### 현황 분석 먼저 기존 107개 포스트를 분석했어요. 태그 빈도, 소스 분포, 엔티티 출현 횟수를 전부 뽑았더니 이런 그림이 나왔어요. - 소스별: GitHub(28건), GeekNews(25건), OpenAI(21건), Original(15건), Google(12건), Anthropic(6건) - 가장 많이 다룬 엔티티: Claude(30회), Claude Code(21회), OpenCode(18회), OpenAI(15회) - 핵심 토픽: AI 코딩 도구(46건), 오픈소스 AI(21건), AI 에이전트(8건), AI 보안(8건) 3개월치 데이터가 이미 상당히 쌓여 있었는데, 이걸 체계적으로 정리한 적이 한 번도 없었던 거예요. ### 위키 구조 `content/wiki/` 디렉토리를 만들고, 세 가지 카테고리로 나눴어요. ``` content/wiki/ ├── index.md # 전체 카탈로그 ├── log.md # 활동 이력 ├── entities/ # 기업/제품 (10개) │ ├── openai.md │ ├── anthropic.md │ ├── claude-code.md │ ├── opencode.md │ └── ... ├── topics/ # 기술 트렌드 (6개) │ ├── ai-coding-tools.md │ ├── open-source-ai.md │ ├── ai-agents.md │ └── ... └── synthesis/ # 종합 분석 (예정) ``` 엔티티 페이지는 OpenAI, Anthropic, Google 같은 기업과 Claude Code, OpenCode, Gemini 같은 제품별로 만들었어요. 각 페이지에는 블로그에서 다룬 내용 요약, 타임라인, 관련 엔티티 링크가 들어있어요. 예를 들어 OpenAI 엔티티 페이지에는 1월 23일 PostgreSQL 스케일링 기사부터 4월 16일 Agents SDK 업데이트까지, 21건의 포스트가 시간순으로 정리되어 있어요. 3개월간 OpenAI가 뭘 했는지 한 페이지에서 볼 수 있게 된 거예요. 토픽 페이지는 "AI 코딩 도구", "오픈소스 AI", "AI 보안" 같은 주제별로 만들었어요. 여기에는 여러 엔티티에 걸친 트렌드와 핵심 인사이트가 정리되어 있어요. AI 코딩 도구 토픽에는 Claude Code가 3개월간 v2.1.16에서 v2.1.110까지 올라간 속도, OpenCode와의 가격 비교, 새로 등장한 프레임워크까지 46개 포스트의 핵심이 압축되어 있어요. ### 워크플로우 통합 가장 중요한 건 위키가 자동으로 최신 상태를 유지하는 거예요. `/publish` 커맨드에 위키 업데이트 단계를 추가했어요. ``` 기존: fetch-news → 선택 → publish → commit 변경: fetch-news → 선택 → publish + 위키 업데이트 → commit ``` 새 포스트를 발행하면 자동으로 관련 엔티티 페이지의 타임라인이 갱신되고, 토픽 페이지에 관련 포스트가 추가되고, 인덱스의 포스트 수가 업데이트돼요. 기존 위키에 없는 새로운 엔티티가 감지되면 새 페이지를 만들지 물어보기도 해요. 주기적으로는 `/wiki-lint` 커맨드로 위키 상태를 점검해요. 오래된 정보, 교차 참조 누락, 위키 페이지가 없는데 자주 언급되는 엔티티 같은 걸 잡아줘요. ## Before vs After 위키 적용 전후의 차이를 구체적으로 보여드릴게요. Before (위키 없이 뉴스 발행): "OpenAI가 Agents SDK를 업데이트했다"는 뉴스가 들어오면, 그 뉴스만 보고 포스트를 써요. "OpenAI가 이런 기능을 추가했다, 저런 기능을 추가했다" 정도의 팩트 나열이 되기 쉬워요. After (위키 맥락으로 발행): 같은 뉴스를 처리할 때, 위키에서 OpenAI 엔티티 페이지를 읽어요. "1월에 Codex 에이전트 루프를 공개했고, 2월에 macOS 앱을 출시했고, 3월에 Astral을 인수했다"는 맥락이 이미 정리되어 있으니까, "이번 Agents SDK 업데이트는 OpenAI가 3개월간 밟아온 에이전트 전략의 연장선"이라는 깊이 있는 분석이 가능해지는 거예요. 이게 바로 Karpathy가 말한 "지식의 복리 효과"예요. 같은 뉴스를 받아도 위키가 두꺼울수록 더 풍부한 글이 나와요. 사람이 특정 분야를 오래 취재할수록 기사 퀄리티가 올라가는 것과 같은 원리예요. ## 총평 솔직히 말하면, 아직은 위키를 막 구축한 단계라서 "체감 효과"를 말하기엔 이르다고 생각해요. 초기 107개 포스트를 기반으로 엔티티 10개, 토픽 6개를 만들었을 뿐이에요. 하지만 구조는 만들어졌어요. 앞으로 뉴스를 발행할 때마다 위키가 조금씩 두꺼워지고, 그 위키가 다음 포스트의 맥락이 되는 순환이 시작된 거예요. 2주 정도 이 구조로 운영해보고, 실제로 콘텐츠 퀄리티가 어떻게 달라지는지 후기를 가져오겠습니다. --- 참고: - Karpathy 원문: LLM Wiki Gist(https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) - VentureBeat: Karpathy shares LLM Knowledge Base architecture(https://venturebeat.com/data/karpathy-shares-llm-knowledge-base-architecture-that-bypasses-rag-with-an)

지식관리 태그 글 모음