[AI] 1000개 블로그 글을 LLM Wiki로 만든 이야기 — Karpathy의 아이디어를 실전에 적용하다

[AI] Peterica의 AI공부와 비젼 정리

ㅁ 들어가며

블로그 글을 1000개 쓰면 뿌듯할 줄 알았다.

그런데 어느 날 내가 뭘 아는지 스스로 설명하지 못하는 자신을 발견했다. 글은 많은데, 체계가 없었다.

DevOps 글이 여기저기 흩어져 있고, Kubernetes 관련 글은 카테고리가 3개로 나뉘어 있었다.

"내가 Kubernetes에 대해 뭘 알고 있지?"라는 질문에 블로그 목록을 위아래로 스크롤하는 것 말고는 방법이 없었다.

그러던 중 Andrej Karpathy가 공유한 LLM-Wiki 아이디어를 봤다. 

 

핵심은 간단했다.

 "RAG처럼 매번 원본을 검색하지 말고, LLM이 위키를 만들고 유지보수하게 하라."

이 글에서는 이 아이디어를 987개 블로그 글에 실제로 적용한 과정을 정리한다.

 

ㅁ LLM-WIKI의 핵심

Karpathy의 LLM Wiki는 LLM이 단순히 문서를 검색하는 도구가 아니라, 원본 데이터(raw sources)를 읽어 스스로 구조화된 Markdown 위키를 생성·유지하며 지식을 누적(compound)시키는 시스템 패턴으로, immutable한 소스 계층과 LLM이 관리하는 wiki 계층, 그리고 동작 규칙을 정의하는 schema 계층으로 구성되며, 새로운 문서가 들어올 때마다 요약·개념화·상호연결을 수행해 기존 지식을 업데이트하고 모순을 검출함으로써 “질문할 때마다 다시 찾는 RAG”가 아니라 “한 번 컴파일하고 계속 발전하는 지속적 지식 아티팩트”를 만든다는 점이 핵심이다.

 

ㅁ 포스트 목록 ≠ 지식 위키

먼저 구분해야 할 것이 있다.

포스트 목록은 글의 나열이다. 제목, 날짜, 카테고리로 정렬된 INDEX.md는 "어떤 글이 있는지"를 보여줄 뿐, "내가 무엇을 이해하고 있는지"는 보여주지 못한다.

지식 위키는 여러 글에서 추출한 개념을 재합성한 것이다. 예를 들어 "Kubernetes 네트워킹"이라는 개념 페이지는 Service, Ingress, CNI에 대한 8개 포스트를 읽고 합성한 결과물이다. 개별 글의 요약이 아니라, 글들 사이의 관계와 패턴을 정리한 것이다.

Karpathy는 이것을 3계층으로 설명한다:

Raw Sources (원본)  →  Wiki (합성 지식)  →  Schema (구조 규칙)

내 프로젝트에서는 이렇게 매핑했다:

Karpathy Layer	구현	역할
Raw Sources	posts/ (987개 md)	원본, 수정 안 함
Wiki	concepts/, entities/, moc/	LLM이 합성한 지식 페이지
Schema	SCHEMA.md	위키 구조·규칙

 

 

ㅁ 전체 아키텍처

ㅇ 파이프라인 6단계

987개 포스트를 위키로 변환하는 과정은 6단계이다:

 

Step 1. 카테고리 재정리

  - 69개 카테고리를 12개 MOC(Map of Content)로 통합했다.

  - LLM이 생성한 카테고리는 "DevOps", "CI/CD", "Infrastructure" 처럼 같은 주제를 다른 이름으로 분류하는 경우가 많았다.

  - Python 스크립트(wiki_categorize.py)로 매핑 테이블을 만들어 일괄 정리했다.

 

Step 2. MOC 페이지 생성

  - 12개 카테고리 각각에 대한 진입점 페이지를 자동 생성했다.

  - MOC-DevOps, MOC-Kubernetes, MOC-LLM 등.

  - 각 MOC에는 해당 카테고리의 포스트 목록과 상위 태그가 포함된다.

 

Step 3. 위키링크 삽입

  - 987개 포스트 md 파일에 [[MOC-DevOps]], #kubernetes 같은 Obsidian 호환 링크를 자동 삽입했다.

 

Step 4. Concept/Entity 생성

  - 이 단계가 핵심이다.

  - Local LLM(qwen3:8b)이 MOC별 포스트 메타데이터를 읽고,
     "이 글들의 공통 주제는 무엇인가?"를 추출하여 개념(Concept) 페이지와 기술(Entity) 페이지를 생성한다.

 

Step 5. 크로스링크

  - 모든 페이지 간 [[]] 상호 참조를 보강하고, 위키 진입점(_index.md)을 생성한다.

 

Step 6. Obsidian 설정

  - 그래프 뷰 색상 그룹, 커뮤니티 플러그인 설정 등.

 

ㅇ 위키 페이지 4계층

최종 산출물은 4가지 유형의 페이지로 구성된다:

유형	수량	역할	예시
MOC	12	카테고리 진입점	MOC-DevOps, MOC-Kubernetes
Concept	122	여러 포스트에서 합성한 지식	"CI/CD 파이프라인 설계", "컨테이너 네트워킹"
Entity	61	기술/도구 정의 + 사용 경험	Docker, Jenkins, Terraform
Post	987	블로그 원본	개별 블로그 글

 

 

ㅁ 토큰 절약 — Local LLM 하이브리드 전략

987개 포스트에서 개념을 추출하려면 LLM 호출이 대량으로 필요하다.

클라우드 API를 쓰면 비용이 많이 든다.

그래서 3계층 하네스(Harness) 구조를 설계했다.

Claude Main (Opus) ─── 오케스트레이터, 계획·평가만
    ├── Python 스크립트 ─── Steps 1-3, 5-6 (LLM 불필요)
    └── Local LLM (qwen3:8b) ─── Step 4 벌크 생성 (무료)
         └── Codex ─── confidence=low 건만 재생성 (제한적)

 

핵심 절약 전략: 요약 기반 생성

포스트 전문을 LLM에 넘기면 건당 평균 500자.

하지만 이미 요약·태그·키워드가 posts.jsonl에 있으므로, 이 메타데이터만 전달하면 건당 80자. 84% 토큰 절감이다.

포스트 전문 입력: 500자 × 8건 = 4,000자
요약+태그+키워드: 80자 × 8건 = 640자  → 84% 절감

qwen3:8b는 Ollama로 로컬에서 무료로 실행한다.

Codex는 품질이 낮은 건(confidence=low)에만 선별 사용했다.

 

ㅇ 대형 MOC 배치 분할

DevOps(147건), Kubernetes(142건), LLM(151건) 같은 대형 MOC는 한 번에 LLM에 넣으면 타임아웃이 발생했다.

60건씩 배치를 분할하여 해결했다.

MAX_POSTS_PER_BATCH = 60
batches = [posts[i:i + MAX_POSTS_PER_BATCH]
           for i in range(0, len(posts), MAX_POSTS_PER_BATCH)]

최종 결과: 122 Concepts + 61 Entities, Rubric 평가 183/183 (100%) PASS.

 

ㅁ 위키링크 정합성 — 발견과 교정

위키를 생성한 후 Obsidian에서 열어보니, 링크가 대량으로 깨져 있었다.

 

원인:
  LLM이 관련 포스트를 [[722]] 같은 숫자 ID로 참조했는데,

  실제 포스트 파일명은 0722-Linux-ssh-keygen-명령어를-사용하여-SSH-키를-생성.md였다.

  Obsidian은 파일명(stem) 기준으로 링크를 해석하므로, [[722]]를 클릭하면 빈 파일이 생성되었다.

해결:

  포스트 ID → 파일명 매핑 JSON을 생성하고, 정규식으로 815건의 숫자 링크를 일괄 교정했다.

# [[722]] → [[0722-Linux-ssh-keygen-명령어를-사용하여-SSH-키를-생성]]
new_content = re.sub(r"\[\[(\d+)\]\]", replacer, content)

 

두 번째 문제:  카테고리 오분류로 인한 무관한 참조.

SSO 글이 "프롬프트 엔지니어링" entity에 연결되어 있었다.

근본 원인은 posts.jsonl의 category 필드 자체가 오염된 것이었다.

LLM MOC 151건 중 41건(27.2%)이 오분류. 이를 키워드 기반으로 재분류하고,

MOC 교차 검증(wiki_validate_refs.py)으로 30건의 무효 참조를 자동 제거했다.

 

최종: 792/792 (100%) 참조 정합.

 

 

ㅁ Obsidian 그래프 뷰 - 지식의 시각화

위키의 최종 시각화는 Obsidian의 그래프 뷰다. 4색 그룹으로 계층을 구분했다:

• 빨강: MOC (카테고리 허브, 12개)
• 청록: Concept (개념 페이지, 122개)
• 주황: Entity (기술/도구, 61개)
• 회색: Post (블로그 원본, 987개)

처음에는 Post가 MOC에 직접 연결되어 있어서 계층 구조가 안 보였다.

Post → Concept 역링크를 삽입하고, concept가 있는 포스트에서는 MOC 직접 링크를 제거하여,

MOC → Concept → Post 3계층 구조가 그래프에서 시각적으로 드러나게 만들었다.

 

 

ㅁ 순환 파이프라인 — 살아있는 위키

Karpathy Wiki의 핵심은 "한 번 만들고 끝"이 아니라 지속적으로 유지보수되는 것이다.

새 블로그 글 작성 → 스크래핑 → 요약·태깅
    ↓
wiki/INDEX.md 업데이트 (블로그 인덱스)
wiki/posts/ 에 md 생성 (포스트)
wiki/concepts/ 업데이트 (위키)
    ↓
Obsidian에서 지식 갭 발견 → 새 블로그 글 작성 → 반복

증분 파이프라인(run_incremental.sh)이 매일 자동 실행되어, 새 글이 추가되면 인덱스와 위키가 함께 업데이트된다.

이 글 자체도 작성 후 위키에 반영될 것이다.

 

 

ㅁ 배운 것

LLM의 bookkeeping 능력

Karpathy가 말한 대로, LLM은 "읽기나 사고"보다 "정리 작업(bookkeeping)"에서 가장 큰 가치를 발휘한다. 987개 글에서 공통 주제를 추출하고, 크로스 링크를 만들고, frontmatter를 채우는 작업을 사람이 했다면 며칠이 걸렸을 것이다. Local LLM으로 30분 만에 끝났다.

품질 검증은 자동화해야 한다

LLM이 생성한 결과물을 그대로 쓰면 안 된다. 카테고리 오분류(27.2%), 위키링크 깨짐(815건), 무관한 참조(30건) — 모두 자동 검증 스크립트로 잡았다. Rubric 기반 평가 + MOC 교차 검증의 조합이 효과적이었다.

토큰 절약은 설계의 문제다

"모든 것을 LLM에 넣으면 된다"는 접근은 비용과 품질 모두에서 실패한다. 어떤 단계에 LLM이 필요한지, 입력을 얼마나 줄일 수 있는지, 어떤 LLM을 쓸지를 미리 설계해야 한다. 이 프로젝트에서는 6단계 중 1단계만 LLM을 사용하고, 입력을 84% 줄이는 것으로 비용을 최소화했다.

 

 

ㅁ 마무리

987개의 글은 내가 걸어온 길의 기록이다.

LLM Wiki는 그 기록을 시스템으로 전환한 결과물이다.

Karpathy의 통찰처럼, 지식 시스템을 유지하는 것은 "읽고 생각하는 것"이 아니라 "정리하는 것"이 어렵다. LLM이 그 정리를 맡으면, 인간은 읽고 생각하는 것에 집중할 수 있다.

 

"좋은 AI 결과는 모델이 아니라, 설계된 시스템에서 나온다."

 

 

ㅁ 함께 보면 좋은 사이트

• Karpathy LLM Wiki: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
• 샘플 프롬프트 모음 — Claude Code 하네스 설계 실전 예시: https://peterica.tistory.com/1061
• 포트폴리오: https://peterica-website.vercel.app

 

 

ㅁ 사용 기술

• Python (httpx, selectolax) — 스크래핑·파이프라인
• Ollama + qwen3:8b — Local LLM 개념 생성
• Obsidian — 지식 위키 시각화
• Next.js 16 + react-force-graph-2d — 포트폴리오 그래프 뷰
• Claude + Codex — 하네스 오케스트레이션