AI시대: AI가 스스로 유지보수하는 LLM Wiki 구축

작성자:

AI를 매일 사용하고, 많은 결과물들을 만들어 내는데, 사실 그 모든것들을 지식화 하기는 어렵습니다. 좋은 답변을 받아도 내일이면 같은 컨텍스트를 다시 설명해야 하고, 대화는 길어지고, 파일은 늘어나고, 정리해둔 메모는 어딘가에 묻힙니다.

Andrej Karpathy는 이 문제를 한 문장으로 정리했습니다.

“Nothing is built up.”

이 문제를 해결하는 방법 중 하나로 RAG(Retrieval-Augmented Generation)가 주목을 받았습니다. 하지만 RAG 기반 시스템도 질문마다 원본 문서에서 관련 조각을 검색하고, 그 자리에서 답변을 만듭니다. 여러 문서를 종합해야 하는 질문도 매번 처음부터 찾고, 엮고, 답합니다. 아무것도 축적되지 않는 거죠. 마치 소스코드를 매번 인터프리트하는 것과 같습니다.

Karpathy는 다른 방식을 제안했습니다. LLM을 단순한 질의응답 도구가 아니라 지식 데이터베이스인 위키의 유지보수 에이전트로 쓰는 것입니다. 새 자료를 넣을 때 LLM이 읽고, 요약하고, 개념 페이지를 갱신하고, 연결을 만들어 wiki에 통합합니다. 소스코드 컴파일처럼 한 번 처리하면, 이후 모든 질문은 이미 정제된 지식에서 출발합니다. 지식이 누적해서 쌓이는 구조가 만들어 진거죠.

제가 보기에도 충분히 유의미한 제안이라고 느꼈고, 실제 제 개인 지식 베이스를 구축해 보았습니다. 이 글에서는 그 구축과정을 정리했습니다. 그리고 이 글 자체도 이미 구축된 LLM Wiki에서 관련 페이지들을 읽고 추출하였습니다. 글을 발행하고 나면 다시 LLM Wiki에 보관되고 통합될 예정입니다. 다시 말해, LLM Wiki가 쓴 LLM Wiki 구축기입니다.

목 차

1. LLM Wiki란 무엇인가

LLM Wiki란?

LLM Wiki는 Andrej Karpathy가 2026년 4월 제안한 개인 지식 베이스 구축 패턴입니다. 특정 제품이나 앱이 아니라, AI Agent가 Markdown 파일로 구성된 Wiki 를 직접 작성하고 유지보수하는 방식(패턴)입니다.

구성요소는 단순합니다.

구성요소역할예시
마크다운 편집기Vault 보기·편집Obsidian
LLM 에이전트Wiki 작성·유지보수Claude Code, Codex
버전관리파일 이력·동기화Git / GitHub
웹 클리퍼자료 수집Obsidian Web Clipper

이 네 가지가 전부이고, 복잡한 벡터 DB나 임베딩 파이프라인이 필요 없습니다. Markdown 파일을 AI Agent가 직접 읽고 쓰는 구조이기 때문입니다.

RAG와의 근본 차이

RAG는 기본적으로 질문 시점에 작동합니다. 사용자가 물으면 벡터 DB에서 관련 조각을 찾고 이를 바탕으로 LLM이 답변을 생성합니다. 답변은 그 자리에서 소비되고 사라집니다. 다음 질문에서 같은 작업을 반복합니다.

LLM Wiki는 Ingest(통합) 시점에 작동합니다. 새 자료가 들어올 때 LLM이 읽고, 핵심을 Wiki 페이지로 만들고, 관련 Concept(개념)과 Entity(엔티티)를 갱신하고, Cross-reference(상호참조)를 연결합니다. 이후 질문은 이미 정제된 Wiki를 읽는 것으로 시작합니다. 상호참조는 이미 연결돼 있고, 모순도 이미 표시돼 있고, 통합은 이미 모든 소스를 반영합니다.

3계층 구조

LLM Wiki는 크게 세 개의 레이어로 구성됩니다.

raw 사람이 큐레이션한 원본.
웹 글, PDF 논문, 블로그 글, 세션 로그. LLM은 읽기만 하고 수정하지 않습니다.
불변(Immutable)입니다.
wiki LLM이 생성하고 유지하는 마크다운 파일들.
Sources, Concepts, Entities, Synthesis, Projects 폴더로 구성됩니다.
사람은 읽고 검토만 합니다.
schema CLAUDE.md, AGENTS.md 등 LLM이 따라야 할 규칙을 담은 설정 파일. 
Ingest 절차, Frontmatter 표준, 인용 규칙, 삭제 규칙을 명시합니다.
사람과 LLM이 함께 진화시킵니다.

4가지 작업

다음의 네 가지 작업이 루프를 돌면서 Wiki가 복리로 성장합니다.

Ingest 새 소스를 wiki에 통합합니다.
LLM이 원본을 읽고, 요점을 보고하고, Sources 페이지를 만듭니다.
관련 Concepts와 Entities를 동시에 갱신합니다.
Query Wiki에 질문합니다.
LLM이 index.md를 먼저 읽고 관련 페이지를 탐색하여 인용과 함께 답변합니다.
좋은 답변은 Synthesis 페이지로 저장됩니다.
Synthesis 여러 소스를 묶어 종합 페이지를 만듭니다.
제 경우는 블로그 초안의 원재료가 됩니다.
Lint Wiki 건강을 점검합니다.
Broken wiki link, Orphan 페이지, Stale claim, Frontmatter 오류, 누락된 Cross-reference를 검출하고, 심각도별(🔴🟡🟢)로 보고합니다.

2. 나만의 위키: 활용 계획

Wiki를 만들 때 가장 먼저 정해야 할 것은 사실 도구가 아니라 무엇을 넣을 것인가입니다. 다루고자 하는 도메인이 명확하지 않으면, Wiki는 금방 단순한 파일 저장소가 됩니다.

제 Wiki의 도메인 범위는 기본에 블로그에 발행했던 글들을 기반으로 우선 아래와 같이 네 가지로 잡았습니다.

  • AI, 소프트웨어 개발: AI 에이전트 엔지니어링, Claude Code, MCP, LLM Wiki
  • AI Transformation (AX) 전략: AI 도입, 조직 설계, 코드 리뷰, 개발자 역할 변화
  • 선행 기술: 전기차(EV), 로봇, Mac 환경, 소프트웨어 아키텍처
  • 블로그 백본: ckarch.kr 콘텐츠 소스 정리

실제로 들어가는 자료는 아래와 같은 종류를 생각중이고, 향후 운영해 가면서 확장할 예정입니다.

  • 블로그 글 : 본인이 쓴 ckarch.kr 글 전체. 제 관점과 경험의 1차 소스입니다. Obsidian Web Clipper로 저장합니다.
  • 외부 글, 뉴스 : AX, AI 코딩, 조직 관련 외부에서 수집한 글. Obsidian Web Clipper로 저장합니다.
  • 논문 : PDF형태로 저장합니다. 통합할때 첫 페이지에서 제목, 저자, 연도를 읽어 파일명을 자동 표준화합니다
  • LLM 대화 세션 : Claude, ChatGPT 등 대화 기록. 생각의 흐름과 의사 결정 과정의 원본입니다.
  • 메모, 노트 : 직접 쓴 생각이나 아이디어를 저장합니다.

역할 원칙은 단순합니다. 사람은 큐레이션과 방향 설정, LLM은 지식의 정리, 연결, 유지를 담당합니다. 인간이 Wiki를 포기하는 이유는 유지보수 부담이 정보의 가치보다 빠르게 커지기 때문입니다. 하지만, LLM은 지치지 않습니다.

3. 구축 계획

Obsidian

실제 파일은 마크다운이기 때문에 어떤 에디터나 에이전트로도 접근 가능하지만, 원활한 관리를 위하여 Obsidian을 사용합니다. Obsidian은 뷰어이자 IDE 역할을 하고, 그래프뷰를 통해 Wiki 전체의 연결망을 시각화할 수 있습니다.

에이전트 스키마: CLAUDE.md / AGENTS.md

이 파일이 단순 챗봇과 Wiki 메인테이너를 가르는 경계입니다. 다음과 같은 내용들을 포함하고 있습니다.

  • 디렉토리 구조와 raw, wiki 경계 규칙
  • Frontmatter 표준 (Type, Status, Canonical, Sources 등)
  • Ingest 워크플로우 단계별 절차
  • 인용 규칙 (출처 없으면 작성 금지)
  • 삭제 규칙 (rm 금지, archived 처리): 파일을 직접 삭제하지 않고 상태값만 바꿔 이력을 보존합니다
  • 블로그 글쓰기 스타일 (두괄식, 존대말, 분량)
  • 기기 별 운영 규칙
  • 새 세션 시작 루틴

Obsidian Web Clipper 템플릿

Chrome 브라우처 확장을 통해 Obsidian Web Clipper를 설치하면 탐색중인 웹페이지를 클릭 한 번에 마크다운 파일로 변환하여 저장할 수 있습니다.

템플릿저장 위치파일명 형식용도
기본raw/articles날짜-제목.md외부 글·뉴스
ckarch.krraw/blog-posts발행일-제목.md본인 블로그
LLM 세션raw/sessions날짜-제목.mdAI 대화

GitHub 연동

두 대의 서로 다른 Mac PC에서 작업을 하기 위해 GitHub을 이용해 동기화하기로 했습니다. GitHub 중심으로 각 PC에서 작업 전후 pull/push하는 방식으로 충돌을 방지합니다.

4. 구축 단계별 세부사항

사전 준비 및 첫 Ingest

Wiki 구축에 앞서 Claude와 장시간 이야기를 하며, Wiki 구축 방향에 대해 논의를 했고, 앞장에서 소개한 계획을 확정한 후 실제 실행은 Codex를 이용해 진행했습니다.

먼저 Obsidian 저장소인 Vault를 만들고, AGENTS.md를 작성했습니다. 그리고, 가장 먼저 Karpathy의 LLM Wiki gist와 seCall README를 Ingest했습니다. Karpathy 글은 패턴의 원형을 제공했고, seCall은 한국어권에서 Rust로 실제 구현한 참고 사례였습니다. 이 두 소스를 이용해서 두 개의 컨셉이 작성되었습니다.

블로그 기존 글 전체 Ingest

ckarch.kr 블로그 글 전체를 AI 코딩, AX 전략, AI 활용, 기술 일반, 테슬라 모델 Y, Mac 설정, 블로그 운영 등의 묶음으로 나눠서 Ingest를 했습니다.

각 글은 별도로 Source 페이지가 되었습니다. 여러 글이 같은 주제를 이야기 할때는 새 Concept 페이지가 만들어집니다. Source가 하나뿐인 주제는 추후 보강할 수 있도록 별도로 표시를 해 두었습니다.

특이한 점은 AX 전략과 AI 코딩 묶음에서 상호 참조가 엄청나게 연결됐습니다. 서로 다른 글에서 독립적으로 쓴 내용들이 같은 Concept 노드를 가리키고 있었습니다. 33편을 따로 쓸 때는 보이지 않던 패턴이, Ingest를 거치자 한눈에 드러나더군요. Concept 페이지 개수는 29개로 예상보다 적었습니다. Source가 하나뿐인 주장은 Concept으로 올리지 않고 [소스 필요] 슬롯으로 남겼기 때문입니다. Wiki는 처음부터 가득 채워지는 것이 아니라, 빈칸을 인식하면서 확장합니다.

논문, 외부 글 Ingest

논문의 경우 PDF 파일명을 먼저 표준화했습니다. Codex나 Claude Code가 첫 페이지를 읽고 발행년도-저자이름-제목축약.pdf 형식으로 rename을 제안하면 승인 후 진행하도록 했습니다. AX/조직 관련 외부 글도 7편 이상 Ingest했습니다.

현재 wiki 현황

구축 시작 만 하루 만에 만들어진 숫자입니다. 블로그 33편, 논문 1편, 외부 글 7편 이상이 들어와서 만들어진 숫자입니다. Sources가 Concepts보다 많은 건 정상입니다. 소스 하나만 있는 주장은 Concept으로 올리지 않았기 때문입니다.

  • Sources: 45개
  • Concepts: 29개
  • Entities: 6개
  • Synthesis: 1개
  • Projects: 1개

Lint를 주기적으로 실행하며 구조적 오류 0건을 유지했습니다. 현재 [소스 필요] 슬롯은 41개로, 향후 외부 소스로 채울 대기 목록입니다.

5. Wiki 구축 진행방식

작업 환경

Wiki 구축 초기에는 MacBook에서 주로 작업을 했고, Wiki가 만들어 진 후 언제 어디서나 원활한 작업을 가능하게 하기 위 Mac mini까지 작업 환경에 추가하게 되었습니다.

기본적으로 MacBook에서 Ingest와 Web Clipping작업을 진행하고, 항상 켜저있는 Mac Mini는 Lint와 Query에 대응하게 하였습니다. 특히 Claude Code Channel 기능을 활용해 Telegram Bot을 연결하여 다른 PC나 모바일 환경을 통해 언제 어디서는 Wiki에 접근이 가능해 졌습니다.

두 기기 사이의 동기화는 GitHub을 이용합니다.

AI와의 협업 구조

Wiki를 구축하는 과정에서 겪은 가장 중요한 경험은 바로 도구의 역할 분리였습니다.

초기에는 역할 경계가 모호했습니다. LLM Wiki를 처음 구축해 보는 상황에서, Wiki를 어떻게 만들지 설계할 AI와 실제로 Wiki 구축을 실행할 AI의 구분을 명확하게 하지 않다보니까, 단순한 아이디어를 바로 구조에 반영해 버린다던가, 맥락이 꼬이면서 엉뚱한 이야기를 하게 되는 등 작업이 자꾸 원하지 않는 방향으로 진행되는 경우가 생겼고, 결국 역할이 섞이면 사람의 부담이 줄지 않는다는 것을 깨달았습니다.

그래서 다음과 같이 역할을 정의하고 작업을 진행했습니다.

사용자 : 방향과 큐레이션

도메인을 결정하고 소스를 큐레이션합니다. 어떤 글을 읽을지, 어떤 논문을 넣을지, 어떤 방향으로 Synthesis를 만들지 정합니다. Web Clipper로 raw를 수집하고, 결과를 검토하고, 좋은 질문을 던지는 역할입니다. wiki가 어떤 지식을 담을지 결정하는 일종의 편집장에 역할이 될것 같습니다.

Claude (claude.ai) : Wiki 설계

AGENTS.md, CLAUDE.md 초안 작성, 디렉토리 구조 및 운영 규칙 등을 함께 설계합니다. 이 외에도 Ingest 결과 품질 검토, Synthesis 바탕으로 블로그 글 초안 구조 개선, 새 스킬 작성도 여기서 합니다. 이 블로그 글의 줄거리도 Claude와 함께 설계했고, 재구성도 Claude가 진행했습니다. Wiki에 직접 접근하지는 않고 제 뒷단에서 작동하는 설계 파트너입니다.

Codex (MacBook) : Wiki 구축 및 Ingest/Synthesis/Lint 실행

AGENTS.md와 CLAUDE.md를 읽고 Ingest, Lint, Synthesis를 수행합니다. 주로 사용자의 요청에 의해 작업을 진행하고, 최대한 자율적으로 진행하도록 요구합니다. 작업 완료후 작업내용을 정리하여 보고하는 역할까지 합니다.

Claude Code (Mac Mini) : 상시 운영

Telegram Bot을 통해 다른 PC나 모바일로부터 접근할 수 있습니다. 주기적으로 Lint를 실행하고, 사용자의 Query에도 답을 하게 됩니다. 추후 자동 Source 수집 등으로 역할을 확대할 예정입니다.

요약하면:

  • 사용자 : 방향 설정
  • Claude.ai : 설계 및 검토
  • 작업 PC의 Codex / Claude Code : 작업 실행
  • 상시 서버의 Claude Code : 상시 운영

이 구조를 통해 사람의 부담은 최소화되고, Wiki는 계속 성장할 수 있을 것 같습니다.

6. 첫 번째 루프 완성 : Synthesis에서 발행까지

Wiki를 구축한 후 Codex에게 현재 쌓인 지식을 기반으로 synthesis 후보를 제안해달라고 했고, Codex가 추천한 첫 번째 주제는 technology-experience-shift였습니다.

synthesis: technology-experience-shift를 중심으로 테슬라, Mac, AI 도구 전환 경험을 묶는 종합 글을 만들기 좋습니다.

Wiki를 통해 파악한 핵심 통찰은 기술 전환은 스펙을 이해하는 순간이 아니라, 직접 경험해본 뒤 기준이 바뀌는 순간에 일어난다는 것입니다. 제 경험을 보면, Tesla를 탄 뒤 내연기관이 달라 보이고, Mac을 쓴 뒤 Windows 선택 기준이 흔들리고, AI 코딩을 써본 뒤 개발자의 역할이 재정의됩니다. 세 경험이 같은 패턴을 가리켰습니다.

사실 이 부분을 확인할 때 약간 짜릿한 기분이 들기도 하더군요.

이후 만들어진 Codex에게 Synthesis 페이지를 기반으로 초안을 작성하게 했고, 이후 기존에 글쓰기에 도움을 받았던, Claude.ai와 함께 글쓰기를 마무리 할 수 있었습니다. 완성된 글은 아래에서 확인하실 수 있습니다.

이 글은 LLM Wiki를 구축하고, 기존 블로그 글들 및 참고 문헌들을 바탕으로 ‘기술 전환 경험’을 주제로 작성한 첫 번째 포스트입니다. LLM Wiki 구축 후기는 별도 글로 포스팅할 예정입니다. 참고 바랍니다. Tesla Model Y를 50일쯤 탄 뒤, 렌터카로 내연기관 차를 운전한 적이 있습니다. … 더 읽기
새로운 기술, 새로운 패러다임 — 경험이 기준이 된다

이렇게 완성된 글은 블로그에 발행이 되었고, 다시 해당 글을 Wiki에 Ingest했습니다.

“Wiki → Synthesis → 글 발행 → Ingest → Wiki” 루프가 처음으로 완성되었고, 이를 통해 지식이 복리로 쌓이는 지식 베이스가 성장해 나갈 것입니다.

향후 계획 및 맺음말

이제 막 첫번째 루프를 완성하였습니다. 당분간 다양한 자료를 Ingest 하여 지식의 폭을 키우고 모아둔 지식들을 활용하여 다양한 주제의 글을 Synthesis 해 나갈 생각입니다. 동시에 자료 수집, Lint 등 각종 자동화도 진행해야 할 것 같습니다.

사실, LLM Wiki는 거창한 시스템이 아닙니다. Markdown 파일들과 에이전트 스키마 하나면 됩니다. 시작하는 데 필요한 것은 Obsidian, AI Agent, 자료 몇개만 있으면 만들 수 있습니다. 복잡한 것은 도구가 아니라 무엇을 넣고, 어떻게 연결할 것인가라는 질문입니다.

Karpathy가 제안한 핵심은 단순합니다. LLM에게 지식 유지보수를 맡기면, 사람은 지치지 않고 지식을 쌓을 수 있습니다. Vannevar Bush가 1945년 Memex로 꿈꿨던 개인 지식 확장 기계가, LLM이라는 유지보수 에이전트를 만나 비로소 실현 가능해졌습니다.

제가 만든 Wiki는 이제 겨우 이틀째가 되었고, sources 45개, concepts 29개가 있습니다. 시작한 지 이틀 된 시스템입니다. 복리는 이제 막 시작됐습니다.

지식은 저장될 때보다 연결될 때 자산이 됩니다.

ChulJoo Kim (김철주)

※ 참고문헌

※ 관련 글

ckarch.kr © 2026 is licensed under CC BY-NC-SA 4.0 CC BY NC SA

댓글 남기기