LLM Wiki (unclejobs-ai fork, Korean addendum)

LLM Wiki (unclejobs-ai fork)

한줄요약

karpathy-llm-wiki의 포크 gist로, 파일은 두 개다. (1) 영문 원문 llm-wiki.md는 Karpathy 원본과 바이트 단위로 동일했고, (2) translate-en-to-ko-llm-wiki-2026-04-05.md는 전문 한국어 번역에 “역자 주석” 10개 절을 덧붙인 것이다. 번역 자체는 충실하며, 가치는 역자 주석의 실전 체크리스트(스키마 항목, frontmatter 예시, MCP, 한국어 운영, 비용 감각, git 전략, RAG 병행, 세션 간 컨텍스트, lint 프롬프트)에 있다. 다만 일부 수치는 원문과 어긋나거나 근거가 없다.

읽은 범위와 이전 노트 정정

gist API로 두 파일 전체(영문 11,985바이트, 한국어 25,011바이트)를 받아 끝까지 읽었다. 이전 노트는 “10개 노트의 세부 내용은 요약본에서 확인하지 못함”이라고 적었는데 이번에 모두 읽었고 아래 3절에 상세히 정리했다. gist 메타데이터: 설명은 “llm-wiki”, 생성 2026-04-05T05:33Z, 마지막 갱신 2026-08-30T10:00Z, 댓글 0개. 작성자 unclejobs-ai의 신원이나 번역 도구(사람/LLM)는 gist에 표기가 없어 알 수 없다.

1. 문제의식·배경: 포크가 필요했던 이유

원본 gist는 의도적으로 추상적인 idea file이다. 저자 스스로 “정확한 디렉터리 구조, 스키마 규약, 페이지 포맷, 도구는 도메인과 취향과 LLM에 달렸다”고 한다. 영어로 쓰인 이 문서를 한국어 사용자가 자신의 에이전트에 그대로 붙여 넣으려면 두 가지가 필요하다. 하나는 한국어 번역이고, 다른 하나는 “추상적이라 실전에서 바로 써먹기엔 빠진 조각”이다. 포크 작성자는 후자를 역자 주석 형태로 채웠다. 그 첫 문장이 이를 선언한다. “원문이 의도적으로 추상적이라 실전에서 바로 써먹기엔 빠진 조각들이 있습니다. 아래는 직접 구축해보면서 부딪히게 될 구체적인 사항들입니다.”

원본의 핵심 논지(RAG는 질의마다 재도출하지만 wiki는 compounding artifact다, 사람은 큐레이션과 질문, LLM은 bookkeeping, 3계층 raw/wiki/schema, Ingest/Query/Lint, index.md/log.md, qmd, Memex 비유)는 karpathy-llm-wiki에 상세히 정리했으므로 여기서는 반복하지 않고 포크 고유의 내용에 집중한다.

2. 영문 원본과의 비교

2.1 영문 파일: 동일

포크의 llm-wiki.md를 내려받아 Karpathy gist의 raw와 diff로 비교했더니 차이가 없었다(IDENTICAL). 2026-08-30 갱신은 영문 본문이 아니라 번역 파일이나 메타 쪽 변경으로 보인다(어느 파일이 바뀌었는지는 gist API에 revision별 정보를 따로 보지 않아 확인하지 못했다). 따라서 “포크가 원본을 개선했다”가 아니라 “원본을 그대로 두고 옆에 번역과 주석을 붙였다”가 정확하다.

2.2 한국어 번역의 특징

번역은 원문 구조를 절 단위로 그대로 따른다. 눈에 띄는 선택은 다음과 같다.

• 용어: Ingest → “수집(Ingest)”, Query → “질의(Query)”, Lint → “점검(Lint)”, Operations → “오퍼레이션”, Raw sources → “원시 소스”, The schema → “스키마”. 처음 나올 때 영어 원어를 괄호로 병기한다. 한편 immutable은 “불변(immutable)”, source of truth는 “단일 진실 공급원(source of truth)“처럼 병기하거나 풀어 쓴다.
• 어투: 합쇼체와 해요체가 섞인 “~입니다/~죠”로, 원문의 구어적인 1인칭 서술(“Personally I prefer…”)을 “개인적으로는 ~하는 것을 선호합니다”로 옮겼다.
• 핵심 문장의 번역: “the wiki is a persistent, compounding artifact”는 “위키는 영속적이고 복리로 축적되는 산출물입니다”로, “Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase”는 “Obsidian은 IDE이고, LLM은 프로그래머이고, 위키는 코드베이스입니다”로 직역했다. “You read it; the LLM writes it”은 “여러분은 읽고, LLM은 씁니다”다.
• 원문에 없는 추가: 번역문 중간에 약간의 풀이가 섞인다. 예컨대 “Memex(1945)“에 “바네바 부시(Vannevar Bush)의 메멕스”라는 한글 표기를 달고, “연상적 경로”를 풀어 쓴다. 의미를 바꾸는 오역이나 누락은 발견하지 못했다. 코드·URL·명령어(grep "^\[" log.md | tail -5, qmd 링크, Tolkien Gateway 링크)는 그대로 보존됐다.

즉 번역은 신뢰할 만하지만, 이 노트처럼 정확한 인용이 필요할 때는 영문을 기준으로 삼는 편이 안전하다. 한국어에서 “Lint”가 “점검”으로 번역되어 있어 도구 이름 lint와 의미가 겹친다는 점만 유의하면 된다.

3. 역자 주석 10개 절: 실제 내용

각 절의 실질 내용을 옮기고, 원문과 맞는지 평가를 괄호로 붙였다.

3.1 Obsidian과 LLM 에이전트의 실시간 연동

• Obsidian vault를 에이전트의 작업 디렉터리로 직접 잡는다. Claude Code라면 vault 루트에서 세션을 열고, Codex도 마찬가지다. 그러면 LLM의 파일 수정을 Obsidian이 감지해 실시간 반영하므로 별도 동기화가 필요 없다.
• 주의점 셋: .obsidian/ 설정 디렉터리는 LLM이 건드리지 않게 스키마에 명시, 커뮤니티 플러그인 Linter로 LLM이 쓴 마크다운의 포맷(trailing space, heading style)을 정규화, Templater로 페이지 템플릿을 미리 만들어 “이 템플릿대로 써”라고 지시. (평가: 실용적이고 정확하다. 이 vault 자체가 이 구성이라 즉시 적용 가능하다.)

3.2 스키마(CLAUDE.md)에 넣을 것

최소한 다음 다섯 가지를 권한다.

1. 디렉터리 구조(raw/, wiki/, wiki/entities/, wiki/concepts/, wiki/sources/)
2. 페이지 템플릿(엔티티/소스 요약/개념 페이지 각각의 frontmatter 스키마와 필수 섹션)
3. 네이밍 규칙(파일명 kebab-case, 내부 링크는 [[위키링크]]와 [마크다운 링크]() 중 택일)
4. 수집 워크플로(새 소스가 오면 이 순서로 처리하라는 체크리스트)
5. 금지 사항(“원시 소스는 절대 수정하지 마라”, “위키 페이지에 원문을 통째로 복붙하지 마라”)

스키마를 처음부터 완벽하게 만들 필요 없이 LLM과 반복하며 다듬으라고 덧붙인다. 소스 요약 페이지 frontmatter 예시는 다음과 같다.

---
title: "Attention Is All You Need 논문 요약"
type: source
source_url: https://arxiv.org/abs/1706.03762
author: Vaswani et al.
date_ingested: 2026-04-05
date_published: 2017-06-12
tags: [transformer, attention, deep-learning]
related: [[transformer]], [[self-attention]], [[seq2seq]]
---

엔티티/개념 페이지는 type: entity 또는 type: concept으로 구분하고 source_count 필드로 “해당 개념이 몇 개 소스에서 언급됐는지” 추적하면 Dataview에서 “가장 많이 등장하는 개념 TOP 20” 같은 뷰를 만들 수 있다고 한다. (평가: 좋은 출발점이다. 다만 예시의 related: [[transformer]], [[self-attention]], [[seq2seq]]는 따옴표가 없어 일반적으로 YAML에서 중첩 시퀀스 뒤에 쉼표가 이어지는 형태가 되어 유효하지 않거나 의도한 링크 속성으로 인식되지 않는다. Obsidian 속성에서 링크를 쓰려면 related: ["[[transformer]]", "[[self-attention]]"]처럼 따옴표 안에 넣는 것이 일반적이다. 이 지적은 YAML 파서를 돌려 검증한 것이 아니라 일반 규칙에 따른 판단이다.)

3.3 MCP 서버: 위키를 LLM의 네이티브 도구로

원문이 qmd의 MCP를 한 줄로 지나간 부분을 “게임 체인저”라 평가한다. MCP(Model Context Protocol)로 위키 검색을 노출하면 LLM이 “셸로 스크립트를 실행”하는 대신 네이티브 도구로 직접 검색하므로 응답이 빠르고 에러 처리가 깔끔하다. Claude Code는 프로젝트 루트의 .mcp.json에 등록하면 되고 Codex도 비슷하다. “위키 규모가 50페이지를 넘어가면 진지하게 고려”하라고 한다. (평가: 50페이지라는 임계값은 근거가 제시되지 않았다. 원문은 index.md만으로 ~100 소스, 수백 페이지까지 잘 된다고 했으므로 포크의 숫자가 더 보수적이다. 어느 쪽도 실측이 아니다.)

3.4 한국어 위키 운영

• 검색: 한국어는 교착어라 형태소 분석 없이는 검색이 잘 안 되니 qmd의 한국어 토크나이징 지원을 확인하고, 안 되면 index.md에 영어 키워드를 병기.
• 파일명은 영어로: “Obsidian에서 한글 파일명은 URL 인코딩 문제, git 호환성 문제”가 있으니 영어 kebab-case 파일명 + 한국어 H1 제목을 권장.
• frontmatter에 한영 태그 병기: tags: [인공지능, artificial-intelligence]로 Dataview 쿼리 시 양쪽이 잡히게. (평가: 첫 항목은 Karpathy gist 댓글에서 한 구현자가 “토크나이저가 [^a-z0-9]+로 쪼개 한국어 등 비라틴 문자가 토큰 0개였다”고 보고한 것과 정확히 같은 종류의 문제라 타당하다. 두 번째 항목의 “URL 인코딩/git 호환성 문제”는 과장일 수 있다. Obsidian은 한글 파일명을 정상 처리하고, 실제 마찰은 macOS와 다른 OS 사이의 유니코드 정규화(NFC/NFD)나 외부 URL 링크에서 나타난다. 그래도 파일명을 영문으로 하고 제목을 한글로 두는 규약은 안전하고 이 vault가 이미 따르는 방식이다.)

3.5 소스 수집 실전 팁

원문이 Web Clipper만 언급한 것을 소스 유형별로 보충한다.

• YouTube: 자막 추출(yt-dlp --write-auto-sub 또는 브라우저 확장)로 .md 저장.
• PDF 논문/보고서: Obsidian에 끌어다 놓아도 LLM이 읽으려면 텍스트 추출이 필요. marker 같은 도구로 마크다운 변환이 낫다.
• 트위터/스레드: Thread Reader App으로 unroll 후 Web Clipper.
• 팟캐스트: Whisper로 transcript 생성 후 저장.
• 소스별 메타데이터(날짜, 저자, URL, 유형)를 frontmatter로 통일하면 Dataview로 “최근 30일 수집 소스”, “저자별 목록” 같은 뷰를 만들 수 있다. (평가: 이번 재조사에서 PDF를 pypdf로 텍스트 추출해 읽은 경험과 일치한다. 도구 이름은 작성자가 제시한 것이며 내가 설치해 검증하지 않았다.)

3.6 비용과 규모 감각

• 소스 1건 ingest는 소스 텍스트 + 기존 wiki 페이지 읽기 + 수정된 페이지 출력으로 “에이전트 세션 기준 수만~십수만 토큰”
• 질의 1건은 index 읽기 + 관련 페이지 2-5개 읽기 + 답변이라 상대적으로 가볍다.
• wiki 100페이지 이상이면 index만으로 탐색이 어려워지기 시작해 qmd 같은 검색 도입 시점.
• Claude Code Max Plan($200/월)이나 Codex라면 토큰 비용이 큰 문제 아니고, API 직접 호출이면 ingest 빈도를 조절. (평가: 모두 작성자의 대략적 감각이며 측정 근거가 없다. 요금제 가격은 시점에 따라 변하므로 인용하지 말 것. 방향성, 즉 ingest는 무겁고 query는 가볍다는 구분은 타당하다.)

3.7 git 활용 전략

• 수집 단위로 커밋: 소스 하나가 끝날 때마다 커밋하면 “이 소스가 위키에 어떤 변화를 줬는가”를 diff로 본다.
• 브랜치: 큰 주제 전환이나 실험적 재구조화는 브랜치에서.
• .gitignore에 .obsidian/workspace.json 같은 개인 설정 파일 제외. (평가: 한 번에 10-15페이지를 고치는 LLM 편집의 감사 가능성 문제에 대한 가장 실용적인 답이다. 이 vault처럼 git이 아닌 환경이라면 ingest 로그(log.md)와 researched 날짜로 대신 추적한다.)

3.8 RAG와의 병행

원문이 RAG를 대체재처럼 서술하지만 실은 보완재라는 주장이다. 위키가 1차 지식 레이어, 원시 소스 RAG가 2차 레이어다. 위키에서 답을 찾되 원문 확인이 필요하면 원시 소스를 RAG로 검색한다. “위키가 컴파일된 지식이라면 RAG는 원문 검증 도구”라는 비유가 붙는다. (평가: 원문에도 암시되는 부분이지만 명시한 것이 유용하다. 오류 복리 위험의 해소 경로이기도 하다.)

3.9 세션 간 컨텍스트: “위키가 해결하는 진짜 문제”

작성자가 보기에 LLM 위키가 푸는 가장 큰 실전 문제는 세션 간 컨텍스트 유실이다. 어제 2시간 판 분석도 새 세션에서는 처음부터 시작해야 하는데, 새 세션에서 “index.md를 먼저 읽어”라 지시하면 축적된 지식의 지도를 한 번에 파악한다. CLAUDE.md에 “세션 시작 시 index.md와 log.md를 먼저 읽어라”를 써 두면 자동화된다. 이것이 원문의 “축적이 없다”는 RAG 비판을 가장 직접적으로 푸는 메커니즘이라고 한다. (평가: 에이전트 메모리 관점에서 가장 통찰적인 절이다. 다만 Karpathy gist 댓글 중 한 사례(orcosto-lab)는 “wiki가 세션 시작에는 읽히지만 작업 도중에는 읽히지 않아 이미 적힌 교훈을 재진단했다”고 보고한다. 즉 시작 시 읽기 규칙만으로는 부족하고 실패 시그니처 같은 중간 트리거도 필요할 수 있다.)

3.10 점검(Lint) 실전 프롬프트

원문이 “주기적으로 요청하라”고만 한 부분을 바로 쓸 수 있는 프롬프트로 만들었다. 일곱 가지 항목을 순서대로 확인하고 보고하게 한다.

1. index.md에 등록됐지만 파일이 없는 항목(깨진 링크)
2. 파일은 있지만 index.md에 누락된 페이지
3. 다른 페이지에서 한 번도 링크되지 않은 고아 페이지
4. 둘 이상의 페이지에서 서로 모순되는 주장
5. 언급은 되지만 자체 페이지가 없는 주요 개념
6. source_count가 3 이상인데 요약이 1문단 이하인 빈약한 페이지
7. 최근 수집 소스가 기존 주장을 갱신했어야 하는데 반영 안 된 곳

각 항목에 대해 발견 사항과 구체적 수정 제안을 함께 보고하게 하고, 이 프롬프트를 스키마나 별도 lint-prompt.md에 저장해 “lint 돌려줘”로 호출하라고 한다. (평가: 1-3, 5는 결정론적 스크립트로 처리 가능한 항목이다(파일 목록과 링크 파싱). LLM에게 시킬 필요가 없고, 시키면 환각과 비용 위험이 있다. 4와 7만 LLM 판단이 필요하다. Karpathy gist 댓글의 “모순은 lint가 아니라 write time에 해결하라”는 논점과 함께 읽을 가치가 있다.)

4. 포크가 원본에 더한 것·더하지 못한 것

항목	원본(Karpathy)	포크 역자 주석
철학과 구조	명시	번역으로 동일 전달
스키마 내용	”구조, 규약, 워크플로” 수준	5개 구체 항목 + frontmatter 예시
검색 규모 한계	”~100 소스, 수백 페이지까지 index로 충분"	"50페이지 넘으면 MCP 고려, 100페이지 넘으면 index 어려움”
한국어	해당 없음	검색(형태소), 파일명, 태그 병기
소스 유형	Web Clipper	YouTube, PDF, 트위터, 팟캐스트
비용	언급 없음	대략적 토큰 감각
git	한 줄	커밋 단위, 브랜치, .gitignore
RAG와의 관계	대체재처럼 서술	보완재로 병행
세션 간	암시	명시적 핵심 이점으로 서술
lint	항목 열거	실행 가능한 프롬프트

더하지 못한 것은 쓰기 경로의 안전장치다. 출처 없는 주장이 wiki에 들어가는 것을 막는 규칙(요약마다 원문 인용 강제, unverified 표식), 모순을 쓰기 시점에 해결하는 방식, 소스가 프롬프트 인젝션을 담고 있을 때의 방어는 포크에도 없다. Karpathy gist 댓글에서 구현자들이 이 영역을 활발히 논의하고 있다(karpathy-llm-wiki 7절).

5. 한계·비판적 평가

1. 번역 도구와 검수 여부가 불명이다. 파일명의 translate-en-to-ko-llm-wiki-2026-04-05는 번역 작업 이름처럼 보이고, 역자 주석은 “직접 구축해보면서 부딪히게 될”이라 말하지만 구체 사례(어떤 규모에서 무엇이 깨졌는지)는 없다. 경험담인지 일반론인지 구분하기 어렵다.
2. 수치의 근거 부재: 50페이지, 100페이지, 수만~십수만 토큰, $200/월 모두 측정이나 출처가 없다. 원문의 “수백 페이지까지 index”와도 어긋난다.
3. frontmatter 예시의 문법 오류 가능성(3.2의 평가 참조), 한글 파일명 문제의 과장 가능성(3.4).
4. lint 프롬프트가 결정론적으로 풀 수 있는 항목까지 LLM에 맡긴다. 비용과 환각을 키운다.
5. 포크의 지속성: 댓글 0개, 마지막 갱신 2026-08-30. 원본은 댓글 1,131개로 활발히 진화하는데 포크는 4월의 스냅샷에 가깝다. 원본 쪽 최신 논의(write-time 충돌 해결, 토크나이저, 검증 게이트)는 이 포크에 반영되지 않는다.
6. 보안 관점 누락: 외부 소스를 LLM이 읽어 wiki를 고치는 구조에서의 인젝션과 권한 문제, .obsidian 보호 이상의 쓰기 권한 경계가 없다.

7. 확인하지 못한 것

• gist의 revision 이력(어떤 파일이 2026-08-30에 바뀌었는지)과 unclejobs-ai 작성자 프로필.
• 역자 주석이 언급한 도구(marker, yt-dlp, Whisper, Thread Reader App, Linter/Templater 플러그인)의 실제 동작: 작성자 주장 그대로이며 검증하지 않았다.
• 번역의 모든 문장 대조: 구조와 핵심 문장은 대조했으나 문장 단위 전수 대조까지는 하지 않았다.

관련 노트

karpathy-llm-wiki wikiskill llm-agent-skill-memory-without-finetuning jev-as-a-judge-agent-evals new-sdlc-with-vibe-coding

출처

모두 2026-10-01에 직접 열람.

• unclejobs-ai, “llm-wiki” 포크 gist (llm-wiki.md 영문, translate-en-to-ko-llm-wiki-2026-04-05.md 한국어 번역 + 역자 주석): https://gist.github.com/unclejobs-ai/7af4a9e3446751b8e2c3bc66d23fa0ac (GitHub gist API로 전체 파일 수신)
• 비교 기준: Andrej Karpathy, “llm-wiki” gist raw (https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f), 영문 파일이 포크와 동일함을 diff로 확인