출처
- source_url: https://devopslog.tistory.com/229
- author: devopslog 블로그
- published: 2026-04-19
- raw: raw source:
devopslog-229-karpathy-llm-wiki
요약
DevOps 성향의 블로그 devopslog가 Andrej Karpathy의 LLM Wiki gist를 세 축 — RAG와의 차이, Karpathy가 제안한 수집·정리·유지 방법, 실전에서 바로 가져올 수 있는 팁 — 으로 정리한 해설글이다. 필자는 DevOps 관점에서 이 아이디어가 흥미로운 이유로, 운영 문서·장애 보고서·러닝 노트·회의록·런북은 시간이 갈수록 쌓이지만 가치가 자동으로 커지지 않고 오히려 오래될수록 흩어지고 서로 충돌하며 찾기 어려워진다는 문제를 든다.
RAG와 Karpathy식 위키의 차이를 표로 대비한다. RAG는 질문이 들어올 때마다 관련 문서를 다시 검색해 조합하며, 이전 질문에서 얻은 통찰이 시스템에 남지 않고 다중 문서 간 충돌 관계를 매번 다시 계산한다 — “그때그때 읽고 답하는 시스템”에 가깝다. 반면 Karpathy식 방식은 새 소스가 들어올 때마다 LLM이 핵심을 추출해 관련 개념·인물·비교 페이지를 갱신하고, 새 내용이 기존 주장과 충돌하면 그 차이를 기록하며, 질의 결과도 필요하면 위키의 새 페이지로 편입한다. 필자는 “RAG는 읽기 도구이고, LLM Wiki는 쓰기와 유지보수까지 포함한 지식 운영 체계”라고 요약한다.
지식 수집 방법으로는 원문(Karpathy 문서)이 제시한 3층 구조 — 수정하지 않는 raw sources(원본), LLM이 직접 관리하며 요약·개념·엔티티·비교·인덱스·통합 서술 페이지로 구성되는 wiki, 위키 구조·네이밍·ingest 절차·충돌 처리 원칙·로그 기록 방식을 규정하는 schema(CLAUDE.md, AGENTS.md 등) — 를 소개하고, Ingest(자료 읽고 위키에 통합, 문서 하나가 10개 이상 페이지를 건드릴 수 있음) → Query(질문에 답하고 가치 있는 답변을 새 페이지로 편입) → Lint(충돌 주장·오래된 내용·끊긴 링크·데이터 갭을 주기적으로 점검)의 운영 루프를 설명한다. index.md(모든 페이지의 링크·짧은 설명·카테고리별 정리, 약 100개 소스·수백 개 페이지까지 효과적)와 log.md(일관된 접두사로 유닉스 도구 분석이 쉬운 시간순 기록)의 역할도 정리한다.
실전 팁으로는 배치보다 하나씩 ingest하며 중간 결과를 검토할 것, Obsidian을 IDE처럼 써서 LLM이 수정하고 사람이 링크 구조·의미를 검토할 것, Web clipper와 로컬 이미지 저장으로 URL이 깨지는 문제에 대비할 것, 그래프 뷰로 허브/고립 페이지를 찾을 것, Marp·Dataview 등을 연결해 위키를 재사용 가능한 운영 자산으로 만들 것, git 저장소로 관리해 변경 이력·브랜치·롤백을 얻을 것을 제시한다. 이를 DevOps 시나리오에 구체적으로 매핑해, incident 티켓·Slack 스레드·postmortem으로부터 LLM이 원인·재발방지·영향범위를 정리하는 장애 대응 위키, 인증서 교체·배포 롤백·DNS 변경 같은 절차를 새 경험이 들어올 때마다 갱신하는 런북 위키, 서비스 의존성·팀 책임 범위·외부 벤더 정보를 구조화하는 아키텍처 지식베이스를 예로 든다. 필자는 “LLM에게 답만 시키지 말고 지식 운영을 맡겨라. 검색은 순간적으로 유용하지만, 축적되지 않으면 같은 일을 반복하게 된다”는 메시지로 마무리한다.
관련 위키
원문 보존 위치
원문 전체는 raw source: devopslog-229-karpathy-llm-wiki에 source_url과 함께 저장되어 있다.