Synthesis (종합)aidraftFri Apr 24

AI의 선용 — Ch.7 LLMWiki, 살아있는 성경 지식 그래프

별칭: Ch.7 LLMWiki · 지식 그래프 · Karpathy LLM Wiki · 21세기 종교개혁 도구 · Compilation vs RAG

#9Chapter#Part3실천#LLMWiki#Karpathy#Compilation#KnowledgeGraph#Obsidian#21세기종교개혁

AI의 선용 — Ch.7 LLMWiki, 살아있는 성경 지식 그래프

「예수께서 이르시되 내가 곧 길이요 진리요 생명이니」 — 요한복음 14:6 「오직 너희는 택하신 족속이요 왕 같은 제사장들이요 거룩한 나라요 그의 소유가 된 백성이니」 — 베드로전서 2:9

한 줄 정의

별도의 거대 인프라(Neo4j·벡터 DB·Pinecone) 없이, 마크다운 + git만으로 사역 지식이 누적·연결되는 살아있는 지식 그래프. Karpathy의 LLM Wiki 패턴을 교회 사역 도메인에 인스턴스화한 본 프로젝트 자체가 그 한 사례. 본 회차는 본 시리즈 ★ 회차이자 21세기 종교개혁의 도구 가능성을 제시.

요약

대부분의 사역자가 AI를 쓰는 방식은 RAG(검색 증강 생성) 에 가깝다. 자료를 던지고, 질의 시점에 답을 받고, 다음 질의에는 다시 처음부터 발굴한다. 누적되는 것이 ❌. "이번 주 청년부 메시지에 AI를 어떻게 쓸까"를 물어도, 다음 주에 같은 질문을 던지면 LLM은 다시 흩어진 자료를 엮어야 한다.

본 시리즈가 제안하는 길은 다르다. 질의 시점에 자료를 검색하지 않고, LLM이 점진적으로 구축·유지하는 지속형 위키를 만든다 — 사역자(여러분)와 raw 자료 사이에 놓이는, 구조화·상호연결된 마크다운 파일 모음. 새 source(설교·강의·논문·도구 매뉴얼)를 넣으면 LLM은 단순 인덱싱이 아니라, 기존 위키에 통합한다 — 사역 사례 페이지를 갱신하고, AI 도구 비교를 수정하며, 새 가이드가 기존 가드레일과 충돌하는 지점을 표시한다. 지식은 한 번 컴파일되고, 그 이후 최신 상태로 유지된다.

이것이 Compilation ≠ RAG의 핵심 차이. RAG는 매 질의마다 검색하지만, Compilation은 한 번 구조화하면 다음부터는 그래프 자체를 활용한다. 16세기 종교개혁이 인쇄술 + 성경 평신도 직독으로 가능했듯, 21세기에는 LLMWiki + 사역자 직접 운용으로 비슷한 변혁 가능성이 열린다. 루터가 구텐베르크 인쇄술을 활용했듯, 우리는 LLM을 활용한다.

본 회차는 본 시리즈 Part 3 첫 회차이자 ★ 강조 회차. 본 LLMWiki 자체가 본 회차의 살아있는 사례다. 65장 이상의 카드, wikilink 그래프, sources 불변, 11조 Canon, /wiki수집 슬래시 커맨드 — 모두 Ch.7의 구체적 구현. 본 회차를 읽고 사역자는 ① 왜 RAG로는 부족한지를 본다. ② Karpathy 패턴 7 Canon을 이해한다. ③ 자기 사역 영역에 어떻게 LLMWiki를 도입할지 가이드를 손에 쥔다. ④ 21세기 종교개혁의 작은 도구로서의 LLMWiki 비전을 본다.

본문 상세

1. RAG vs Compilation — 본질적 차이

1.1. RAG (Retrieval-Augmented Generation)의 한계

RAG 상세:

매 질의마다 vector DB에서 관련 chunk를 검색
LLM이 그 chunk들을 즉석에서 종합해 답변
누적 ❌ — 다음 질의에는 다시 처음부터

RAG의 좋은 점	RAG의 한계
새 source 즉시 검색 가능	매 질의마다 처음부터
인프라 표준화	인프라 거대 (Pinecone·Weaviate·Milvus)
큰 데이터셋도 OK	누적 학습 ❌
빠른 응답	종합·재구조화 ❌
기업 환경에 맞음	사역 도메인에는 무거움

→ 사역자에게 RAG는 "고급 검색"이지 "살아있는 지식"이 ❌.

1.2. Compilation 모델 — Karpathy LLM Wiki 패턴

Karpathy 패턴 상세:

3 계층: sources/(불변) + wiki/(LLM 관리) + WIKI_CLAUDE.md(스키마)
1 source → 10~15 wiki pages 갱신
질의 시점 검색 ❌ → 이미 컴파일된 위키에서 즉시 답변
모든 답변은 다시 위키에 환원 → 그래프 성장

비교	RAG	Compilation (LLMWiki)
인프라	Vector DB · 임베딩 모델	마크다운 + git만
비용	수백만 원/월	0원
누적	❌	✓
수정	어려움	쉬움 (텍스트 편집)
사람 검토	❌ (블랙박스)	✓ (모든 카드 사람이 봄)
신학 가드레일	어려움	자연스러움 (concept/3-layer-guardrail)
사역자 진입 장벽	매우 높음	낮음 (마크다운만 알면)

→ 사역 도메인에서 Compilation이 압도적.

2. Karpathy LLM Wiki 패턴 — 7 Canon (불변 7조)

Andrej Karpathy가 2026년 4월 GitHub Gist에 공개한 패턴. 본 LLMWiki의 최상위 설계 기준.

Canon 1: sources/는 불변

원천 자료 폴더. LLM은 읽기만. 절대 수정·삭제 ❌. 검증된 자료만 들어옴.

→ 상세 · 승격 절차

Canon 2: 파일명은 `YYYY-MM-DD_<kebab-slug>.<ext>`

추적성·정렬성·고유성. 한글 파일명 ❌, 슬러그(kebab-case)만.

Canon 3: wiki/에 index.md + log.md 필수

index.md: 전체 카탈로그 — 모든 질의의 출발점
log.md: append-only 시간순 기록 — 과거 항목 절대 수정 ❌

Canon 4: WIKI_CLAUDE.md = 관리자 모드 진입 스키마

LLM이 위키를 운영할 때의 행동 지침. SSOT는 LLMwiki_init 저장소.

Canon 5: Query는 index.md 먼저

→ drill-down. 모든 질의가 인덱스부터 시작.

→ 상세

Canon 6: 페이지 간 참조는 wikilink만

[type/slug](/type/slug/) 또는 [alias](/type/slug/) 형식. URL·상대경로 ❌.

→ 상세

Canon 7: sources/만 있으면 wiki/ 전체 재컴파일 가능

재컴파일 가능성 보증. 위키가 손상되어도 sources에서 다시 복구 가능.

→ 상세

3. 본 프로젝트 추가 — 11조 Canon

본 LLMWiki는 Karpathy 7 Canon에 신학·언어 가드레일 4 조 추가:

Canon	내용
8	신학·교리 표현 자동 승격 ❌ — A04.04 doctrine-sidecar 게이트
9	3중 가드레일 통과 필수 — 성경 권위 + 온누리 비전 + 사역 매뉴얼
10	AI 인격화 ❌ — "그분·존재·지능·인격·의지" 호명 ❌
11	기독교 언어 전용 — 타 종교 용어 혼용 ❌

→ 3중 가드레일 상세

4. 본 프로젝트 자체가 사례 — 살아있는 지식 그래프

4.1. 현재 상태 (2026-04-25)

카테고리	카드 수
synthesis (★ 9 Chapter)	9
concept	14
term	22
entity	8
procedure	4
case	4
합계	61

wikilink 그래프 형성됨 (허브 노드: synthesis ch1~9, term/imago-dei, term/holy-prompting, concept/3-layer-guardrail)
정적 사이트 배포: https://ai.llmwiki.kr (단일 본문 패널, 읽기 전용)

4.2. 컴파일 흐름 (실제 운영)

[외부 자료 폴더 (사용자 본인 또는 협력자)]
    ↓ /wiki수집 슬래시 커맨드 (procedure/wiki-collect-command)
[INPUT/9XXX/9XXXNN/<원본 폴더>/<slug>.md] (raw)
    ↓ 사용자 검토 + mv 수동 승격 (procedure/source-promotion)
[sources/{A_sermon|B_discipleship|C_ministry|D_ai-tools|E_research|F_news}/]
    ↓ A03.01 wiki-ingest 에이전트 + llmwiki-ingest 스킬 (procedure/wiki-ingest-pipeline)
[wiki/{type}/*.md] (61장+)
    ↓ A04.04 doctrine-sidecar 게이트 (Canon 8·9·10·11)
[verified 카드 → article/{card-news|column|booklet|ppt}]
    ↓ A05.NN writers
[91 출력 문서/* 사역 현장 공급]

1 source → 10~15 wiki pages 갱신이라는 Karpathy 원칙이 본 프로젝트에서도 동작.

4.3. 4 가지 자체 인용 사례

9 Chapter 시리즈 = 9 Synthesis 카드가 도서 9장과 1:1 대응. wiki 카드 작성 → 도서 원고 보완 → wiki 카드 갱신 (양방향 학습)
온누리교회 자료 9001~9006 = 6 프로젝트 INPUT이 case/onpp-22-agents·case/next-gen-ai-lecture 등 4 case 카드로 컴파일
22 신학·기술 용어 = 한 회차에서 인용된 단어가 다른 회차에서도 같은 의미로 일관 유지
3중 가드레일 동심원 = concept 카드 1장 + Ch.6 회차 + Canon 9·10·11 = 같은 개념의 3 형태 표현

5. 21세기 종교개혁 도구로서의 LLMWiki

루터·구텐베르크의 1517 종교개혁이 가능했던 기술적 토대:

16세기	21세기
인쇄술 (구텐베르크 1450)	LLM + git + 마크다운
성경 독일어 번역 (루터 1522)	사역 자료 한국어 위키화
평신도 성경 직독	사역자 직접 위키 운용
사제 독점 신학 → 만인제사장직	신학교 독점 도구 → 사역자 도구화
한 책 1년 → 1주에 100부	한 자료 1주 → AI로 10분에 통합

본 LLMWiki가 21세기 종교개혁의 작은 도구가 될 수 있는 가능성:

인프라 비용 0 → 누구나 시작 가능
마크다운만 알면 운용 가능 → 사역자 진입 장벽 낮음
AI가 노가다 처리 → 사역자는 분별·기도에 집중
그래프가 누적 → 다음 세대에 자산으로 상속

도서 v4: "구텐베르크가 텍스트 대중화로 종교개혁을 이끌었듯, LLMWiki는 맥락 대중화로 21세기의 종교개혁이 된다."

6. Vannevar Bush의 Memex 정신적 후계

Vannevar Bush의 1945년 「As We May Think」 — Memex 비전:

모든 인류 지식이 연결된 거대 백과사전
한 사람이 자신만의 지식 그래프 구축
다음 세대에 그 그래프 상속

Bush가 풀지 못한 부분: "그 유지보수를 누가 할 것인가". 답: LLM.

LLM은 지루해하지 않고
한 번에 15개 파일 동시 갱신 가능
교차참조 갱신을 잊지 않음
유지보수 비용이 거의 0 → 위키가 유지됨

본 LLMWiki는 Memex 비전의 사역 영역 인스턴스화. 사역자가 성화 진행 중에 자기 사역의 Memex를 키워가는 시도.

7. LLMWiki vs Obsidian vs Notion

기존 도구와의 비교:

도구	본질	LLMWiki와의 차이
Obsidian	마크다운 노트 + 그래프 뷰	사람이 직접 작성. LLMWiki는 LLM이 작성
Notion	데이터베이스 + 페이지	UI 중심. LLMWiki는 파일 시스템 중심
Roam Research	wikilink 그래프	LLM 통합 약함. LLMWiki는 LLM 1급 시민
Wiki.js / DokuWiki	사람이 작성하는 위키	LLMWiki는 LLM 컴파일
RAG 시스템	벡터 검색	LLMWiki는 컴파일 (Compilation ≠ RAG)

→ LLMWiki는 Obsidian 인터페이스 (시각화) + LLM 작성 (자동) + git 버전 관리 (안정성) 의 결합.

8. 본 LLMWiki를 다른 사역에 적용하는 단계 (Bootstrap 가이드)

8.1. 유형 A — 순수 LLMWiki (지식 누적만)

# 새 디렉토리에서
init_llmwiki.md 파일 복사
Claude Code 시작 → 자동 부트스트랩
/wiki지침 → 표준 로딩
/wiki폴더 → 폴더 스켈레톤 생성
첫 source 투입 → llmwiki-ingest 스킬 호출

8.2. 유형 B — LLMWiki 서비스 (에이전트·스케줄러·저작·발행 포함)

본 프로젝트가 유형 B의 사례:

init_llmwiki_service.md 파일 복사
Claude Code 시작 → 부트스트랩
/wiki서비스 → 서비스 프로젝트 스캐폴드
A01~A07 7 그룹 에이전트 정의
스케줄러 등록

→ procedure/wiki-collect-command · procedure/source-promotion · procedure/wiki-ingest-pipeline

8.3. 다른 사역 영역 적용 예시

사역	LLMWiki 적용
청년부 1:1 양육	양육 매뉴얼·동반자 유형·핵심 성구를 wiki로
새가족 환영	새가족 Q&A·교회 소개·후속 양육 단계를 wiki로
설교 준비	본문 주석·예화·인용을 wiki로 (시간 갈수록 자산이 커짐)
청소년 사역	연령별 콘텐츠·교사 매뉴얼·게임을 wiki로
선교 사역	미전도 종족 정보·선교지 보고를 wiki로
회복 사역	트라우마 케이스·치유 방법·기도문을 wiki로

9. 본 회차의 ★ 의미

본 시리즈에서 Ch.7·Ch.8이 ★ 회차인 이유:

Ch.7 = 도구의 정점 — 본 시리즈가 가능한 기술적 토대
Ch.8 = 영성의 정점 — 도구를 쓰는 사람의 자질

둘은 한 짝. 본 회차의 도구가 아무리 정교해도 Ch.8의 영성 없이는 무용. 도서 v4 강조: "도구는 쓰는 사람의 내면을 확대한다."

사역 적용

본 LLMWiki를 자기 사역에 적용하는 4 주 가이드

1주차 — Karpathy Gist 읽기 + 본 프로젝트 둘러보기 (https://ai.llmwiki.kr) 2주차 — init_llmwiki.md 복사 + Claude Code 부트스트랩 + 첫 카드 1장 직접 작성 3주차 — 첫 source 1개 투입 + llmwiki-ingest 스킬 → 10~15 wiki 카드 자동 컴파일 검증 4주차 — Obsidian으로 그래프 보기 + 정적 사이트 배포 (선택, scripts/deploy.sh) 상시 — 새 자료 → /wiki수집 → 검토 → 승격 → ingest 사이클

본 회차 카드뉴스 5장 패턴

1. Persona: "사역 자료가 흩어져 답답한 사역자"
2. Context: RAG vs Compilation + Karpathy 7 Canon + 본 프로젝트 사례
3. Task: "왜 LLMWiki? 어떻게 시작?"
4. Format:
   - 슬라이드 1: 흩어진 사역 자료의 답답함
   - 슬라이드 2: RAG는 매번 처음부터, LLMWiki는 누적
   - 슬라이드 3: Karpathy 7 Canon 한 눈에
   - 슬라이드 4: 본 프로젝트 사례 (61 카드, 0원, 마크다운 + git)
   - 슬라이드 5: 4 주 시작 가이드 + ai.llmwiki.kr

한계와 주의사항

LLMWiki의 한계

수만 카드 규모에서는 검색 효율 ↓ → 일정 규모 이상에서 RAG 보조 필요
다국어 지원 약함 (현재 한국어 중심)
실시간 협업 약함 (git 기반이므로 동기화 필요)
모바일 편집 한계 (마크다운 + git이라 PC 중심)

도입 시 주의

첫 카드 작성이 가장 어려움 — 표준 만들기 전에는 카드 형식이 흔들림
카드 너무 짧으면 가치 ❌ (50줄 미만은 지양, 200~400줄 권장 — 본 회차도 점진적 확장 중)
wikilink 깨짐: type/slug 변경 시 모든 인용 갱신 필요. A03.02 wiki-linker 자동화
Canon 위반 자동 검출: A04.04 doctrine-sidecar가 핵심 (Canon 8·9·10·11)

운영자 책임

sources/ 불변 엄수 (Canon 1)
승격은 사람이 (Canon 8) — 자동화 ❌
재컴파일 가능성 검증 (Canon 7) — 정기적으로 sources에서 wiki 재생성 테스트

핵심 인용 / 명언

"위키는 지속적이고, 복리로 축적되는 아티팩트다." — Karpathy LLM Wiki Gist

"유지보수 비용이 거의 0에 가깝기 때문에 위키는 유지된다." — Karpathy

"구텐베르크가 텍스트 대중화로 종교개혁을 이끌었듯, LLMWiki는 맥락 대중화로 21세기의 종교개혁이 된다." — 도서 v4

「오직 너희는 택하신 족속이요 왕 같은 제사장들이요」 — 벧전 2:9 (만인제사장직, 종교개혁 핵심)

다음 회차로 가는 다리

Ch.7이 도구의 정점이라면, Ch.8은 영성의 정점이다. LLMWiki라는 정교한 도구가 어떻게 사용되느냐는 도구가 결정 ❌, 사용자의 영성이 결정한다. 30 에이전트가 협주하는 오케스트레이션 시스템에서 지휘자(사역자)의 영성이 곡 자체를 결정한다.

Ch.8 핵심 질문:

단일 AI → 30 에이전트 협주, 누가 지휘?
도구가 정교해질수록 영성의 책임이 커지는 이유
프롬프트 이전에 기도, 코드 이전에 분별
성화 진행 중인 사역자 vs 정체된 사역자의 도구 사용 차이

→ Ch.8 에이전트 오케스트레이션과 도구를 쓰는 사람의 영성 ★

AI의 선용 — Ch.7 LLMWiki, 살아있는 성경 지식 그래프

별칭: Ch.7 LLMWiki · 지식 그래프 · Karpathy LLM Wiki · 21세기 종교개혁 도구 · Compilation vs RAG

#9Chapter#Part3실천#LLMWiki#Karpathy#Compilation#KnowledgeGraph#Obsidian#21세기종교개혁

AI의 선용 — Ch.7 LLMWiki, 살아있는 성경 지식 그래프

「예수께서 이르시되 내가 곧 길이요 진리요 생명이니」 — 요한복음 14:6 「오직 너희는 택하신 족속이요 왕 같은 제사장들이요 거룩한 나라요 그의 소유가 된 백성이니」 — 베드로전서 2:9

한 줄 정의

요약

본문 상세

1. RAG vs Compilation — 본질적 차이

1.1. RAG (Retrieval-Augmented Generation)의 한계

RAG 상세:

매 질의마다 vector DB에서 관련 chunk를 검색
LLM이 그 chunk들을 즉석에서 종합해 답변
누적 ❌ — 다음 질의에는 다시 처음부터

RAG의 좋은 점	RAG의 한계
새 source 즉시 검색 가능	매 질의마다 처음부터
인프라 표준화	인프라 거대 (Pinecone·Weaviate·Milvus)
큰 데이터셋도 OK	누적 학습 ❌
빠른 응답	종합·재구조화 ❌
기업 환경에 맞음	사역 도메인에는 무거움

→ 사역자에게 RAG는 "고급 검색"이지 "살아있는 지식"이 ❌.

1.2. Compilation 모델 — Karpathy LLM Wiki 패턴

Karpathy 패턴 상세:

3 계층: sources/(불변) + wiki/(LLM 관리) + WIKI_CLAUDE.md(스키마)
1 source → 10~15 wiki pages 갱신
질의 시점 검색 ❌ → 이미 컴파일된 위키에서 즉시 답변
모든 답변은 다시 위키에 환원 → 그래프 성장

비교	RAG	Compilation (LLMWiki)
인프라	Vector DB · 임베딩 모델	마크다운 + git만
비용	수백만 원/월	0원
누적	❌	✓
수정	어려움	쉬움 (텍스트 편집)
사람 검토	❌ (블랙박스)	✓ (모든 카드 사람이 봄)
신학 가드레일	어려움	자연스러움 (concept/3-layer-guardrail)
사역자 진입 장벽	매우 높음	낮음 (마크다운만 알면)

→ 사역 도메인에서 Compilation이 압도적.

2. Karpathy LLM Wiki 패턴 — 7 Canon (불변 7조)

Andrej Karpathy가 2026년 4월 GitHub Gist에 공개한 패턴. 본 LLMWiki의 최상위 설계 기준.

Canon 1: sources/는 불변

원천 자료 폴더. LLM은 읽기만. 절대 수정·삭제 ❌. 검증된 자료만 들어옴.

→ 상세 · 승격 절차

Canon 2: 파일명은 `YYYY-MM-DD_<kebab-slug>.<ext>`

추적성·정렬성·고유성. 한글 파일명 ❌, 슬러그(kebab-case)만.

Canon 3: wiki/에 index.md + log.md 필수

index.md: 전체 카탈로그 — 모든 질의의 출발점
log.md: append-only 시간순 기록 — 과거 항목 절대 수정 ❌

Canon 4: WIKI_CLAUDE.md = 관리자 모드 진입 스키마

LLM이 위키를 운영할 때의 행동 지침. SSOT는 LLMwiki_init 저장소.

Canon 5: Query는 index.md 먼저

→ drill-down. 모든 질의가 인덱스부터 시작.

→ 상세

Canon 6: 페이지 간 참조는 wikilink만

[type/slug](/type/slug/) 또는 [alias](/type/slug/) 형식. URL·상대경로 ❌.

→ 상세

Canon 7: sources/만 있으면 wiki/ 전체 재컴파일 가능

재컴파일 가능성 보증. 위키가 손상되어도 sources에서 다시 복구 가능.

→ 상세

3. 본 프로젝트 추가 — 11조 Canon

본 LLMWiki는 Karpathy 7 Canon에 신학·언어 가드레일 4 조 추가:

Canon	내용
8	신학·교리 표현 자동 승격 ❌ — A04.04 doctrine-sidecar 게이트
9	3중 가드레일 통과 필수 — 성경 권위 + 온누리 비전 + 사역 매뉴얼
10	AI 인격화 ❌ — "그분·존재·지능·인격·의지" 호명 ❌
11	기독교 언어 전용 — 타 종교 용어 혼용 ❌

→ 3중 가드레일 상세

4. 본 프로젝트 자체가 사례 — 살아있는 지식 그래프

4.1. 현재 상태 (2026-04-25)

카테고리	카드 수
synthesis (★ 9 Chapter)	9
concept	14
term	22
entity	8
procedure	4
case	4
합계	61

wikilink 그래프 형성됨 (허브 노드: synthesis ch1~9, term/imago-dei, term/holy-prompting, concept/3-layer-guardrail)
정적 사이트 배포: https://ai.llmwiki.kr (단일 본문 패널, 읽기 전용)

4.2. 컴파일 흐름 (실제 운영)

[외부 자료 폴더 (사용자 본인 또는 협력자)]
    ↓ /wiki수집 슬래시 커맨드 (procedure/wiki-collect-command)
[INPUT/9XXX/9XXXNN/<원본 폴더>/<slug>.md] (raw)
    ↓ 사용자 검토 + mv 수동 승격 (procedure/source-promotion)
[sources/{A_sermon|B_discipleship|C_ministry|D_ai-tools|E_research|F_news}/]
    ↓ A03.01 wiki-ingest 에이전트 + llmwiki-ingest 스킬 (procedure/wiki-ingest-pipeline)
[wiki/{type}/*.md] (61장+)
    ↓ A04.04 doctrine-sidecar 게이트 (Canon 8·9·10·11)
[verified 카드 → article/{card-news|column|booklet|ppt}]
    ↓ A05.NN writers
[91 출력 문서/* 사역 현장 공급]

1 source → 10~15 wiki pages 갱신이라는 Karpathy 원칙이 본 프로젝트에서도 동작.

4.3. 4 가지 자체 인용 사례

9 Chapter 시리즈 = 9 Synthesis 카드가 도서 9장과 1:1 대응. wiki 카드 작성 → 도서 원고 보완 → wiki 카드 갱신 (양방향 학습)
온누리교회 자료 9001~9006 = 6 프로젝트 INPUT이 case/onpp-22-agents·case/next-gen-ai-lecture 등 4 case 카드로 컴파일
22 신학·기술 용어 = 한 회차에서 인용된 단어가 다른 회차에서도 같은 의미로 일관 유지
3중 가드레일 동심원 = concept 카드 1장 + Ch.6 회차 + Canon 9·10·11 = 같은 개념의 3 형태 표현

5. 21세기 종교개혁 도구로서의 LLMWiki

루터·구텐베르크의 1517 종교개혁이 가능했던 기술적 토대:

16세기	21세기
인쇄술 (구텐베르크 1450)	LLM + git + 마크다운
성경 독일어 번역 (루터 1522)	사역 자료 한국어 위키화
평신도 성경 직독	사역자 직접 위키 운용
사제 독점 신학 → 만인제사장직	신학교 독점 도구 → 사역자 도구화
한 책 1년 → 1주에 100부	한 자료 1주 → AI로 10분에 통합

본 LLMWiki가 21세기 종교개혁의 작은 도구가 될 수 있는 가능성:

인프라 비용 0 → 누구나 시작 가능
마크다운만 알면 운용 가능 → 사역자 진입 장벽 낮음
AI가 노가다 처리 → 사역자는 분별·기도에 집중
그래프가 누적 → 다음 세대에 자산으로 상속

도서 v4: "구텐베르크가 텍스트 대중화로 종교개혁을 이끌었듯, LLMWiki는 맥락 대중화로 21세기의 종교개혁이 된다."

6. Vannevar Bush의 Memex 정신적 후계

Vannevar Bush의 1945년 「As We May Think」 — Memex 비전:

모든 인류 지식이 연결된 거대 백과사전
한 사람이 자신만의 지식 그래프 구축
다음 세대에 그 그래프 상속

Bush가 풀지 못한 부분: "그 유지보수를 누가 할 것인가". 답: LLM.

LLM은 지루해하지 않고
한 번에 15개 파일 동시 갱신 가능
교차참조 갱신을 잊지 않음
유지보수 비용이 거의 0 → 위키가 유지됨

본 LLMWiki는 Memex 비전의 사역 영역 인스턴스화. 사역자가 성화 진행 중에 자기 사역의 Memex를 키워가는 시도.

7. LLMWiki vs Obsidian vs Notion

기존 도구와의 비교:

도구	본질	LLMWiki와의 차이
Obsidian	마크다운 노트 + 그래프 뷰	사람이 직접 작성. LLMWiki는 LLM이 작성
Notion	데이터베이스 + 페이지	UI 중심. LLMWiki는 파일 시스템 중심
Roam Research	wikilink 그래프	LLM 통합 약함. LLMWiki는 LLM 1급 시민
Wiki.js / DokuWiki	사람이 작성하는 위키	LLMWiki는 LLM 컴파일
RAG 시스템	벡터 검색	LLMWiki는 컴파일 (Compilation ≠ RAG)

→ LLMWiki는 Obsidian 인터페이스 (시각화) + LLM 작성 (자동) + git 버전 관리 (안정성) 의 결합.

8. 본 LLMWiki를 다른 사역에 적용하는 단계 (Bootstrap 가이드)

8.1. 유형 A — 순수 LLMWiki (지식 누적만)

# 새 디렉토리에서
init_llmwiki.md 파일 복사
Claude Code 시작 → 자동 부트스트랩
/wiki지침 → 표준 로딩
/wiki폴더 → 폴더 스켈레톤 생성
첫 source 투입 → llmwiki-ingest 스킬 호출

8.2. 유형 B — LLMWiki 서비스 (에이전트·스케줄러·저작·발행 포함)

본 프로젝트가 유형 B의 사례:

init_llmwiki_service.md 파일 복사
Claude Code 시작 → 부트스트랩
/wiki서비스 → 서비스 프로젝트 스캐폴드
A01~A07 7 그룹 에이전트 정의
스케줄러 등록

→ procedure/wiki-collect-command · procedure/source-promotion · procedure/wiki-ingest-pipeline

8.3. 다른 사역 영역 적용 예시

사역	LLMWiki 적용
청년부 1:1 양육	양육 매뉴얼·동반자 유형·핵심 성구를 wiki로
새가족 환영	새가족 Q&A·교회 소개·후속 양육 단계를 wiki로
설교 준비	본문 주석·예화·인용을 wiki로 (시간 갈수록 자산이 커짐)
청소년 사역	연령별 콘텐츠·교사 매뉴얼·게임을 wiki로
선교 사역	미전도 종족 정보·선교지 보고를 wiki로
회복 사역	트라우마 케이스·치유 방법·기도문을 wiki로

9. 본 회차의 ★ 의미

본 시리즈에서 Ch.7·Ch.8이 ★ 회차인 이유:

Ch.7 = 도구의 정점 — 본 시리즈가 가능한 기술적 토대
Ch.8 = 영성의 정점 — 도구를 쓰는 사람의 자질

둘은 한 짝. 본 회차의 도구가 아무리 정교해도 Ch.8의 영성 없이는 무용. 도서 v4 강조: "도구는 쓰는 사람의 내면을 확대한다."

사역 적용

본 LLMWiki를 자기 사역에 적용하는 4 주 가이드

본 회차 카드뉴스 5장 패턴

1. Persona: "사역 자료가 흩어져 답답한 사역자"
2. Context: RAG vs Compilation + Karpathy 7 Canon + 본 프로젝트 사례
3. Task: "왜 LLMWiki? 어떻게 시작?"
4. Format:
   - 슬라이드 1: 흩어진 사역 자료의 답답함
   - 슬라이드 2: RAG는 매번 처음부터, LLMWiki는 누적
   - 슬라이드 3: Karpathy 7 Canon 한 눈에
   - 슬라이드 4: 본 프로젝트 사례 (61 카드, 0원, 마크다운 + git)
   - 슬라이드 5: 4 주 시작 가이드 + ai.llmwiki.kr

한계와 주의사항

LLMWiki의 한계

수만 카드 규모에서는 검색 효율 ↓ → 일정 규모 이상에서 RAG 보조 필요
다국어 지원 약함 (현재 한국어 중심)
실시간 협업 약함 (git 기반이므로 동기화 필요)
모바일 편집 한계 (마크다운 + git이라 PC 중심)

도입 시 주의

첫 카드 작성이 가장 어려움 — 표준 만들기 전에는 카드 형식이 흔들림
카드 너무 짧으면 가치 ❌ (50줄 미만은 지양, 200~400줄 권장 — 본 회차도 점진적 확장 중)
wikilink 깨짐: type/slug 변경 시 모든 인용 갱신 필요. A03.02 wiki-linker 자동화
Canon 위반 자동 검출: A04.04 doctrine-sidecar가 핵심 (Canon 8·9·10·11)

운영자 책임

sources/ 불변 엄수 (Canon 1)
승격은 사람이 (Canon 8) — 자동화 ❌
재컴파일 가능성 검증 (Canon 7) — 정기적으로 sources에서 wiki 재생성 테스트

핵심 인용 / 명언

"위키는 지속적이고, 복리로 축적되는 아티팩트다." — Karpathy LLM Wiki Gist

"유지보수 비용이 거의 0에 가깝기 때문에 위키는 유지된다." — Karpathy

"구텐베르크가 텍스트 대중화로 종교개혁을 이끌었듯, LLMWiki는 맥락 대중화로 21세기의 종교개혁이 된다." — 도서 v4

「오직 너희는 택하신 족속이요 왕 같은 제사장들이요」 — 벧전 2:9 (만인제사장직, 종교개혁 핵심)

다음 회차로 가는 다리

Ch.8 핵심 질문:

단일 AI → 30 에이전트 협주, 누가 지휘?
도구가 정교해질수록 영성의 책임이 커지는 이유
프롬프트 이전에 기도, 코드 이전에 분별
성화 진행 중인 사역자 vs 정체된 사역자의 도구 사용 차이

→ Ch.8 에이전트 오케스트레이션과 도구를 쓰는 사람의 영성 ★

AI의 선용 — Ch.7 LLMWiki, 살아있는 성경 지식 그래프

한 줄 정의

요약

본문 상세

1. RAG vs Compilation — 본질적 차이

1.1. RAG (Retrieval-Augmented Generation)의 한계

1.2. Compilation 모델 — Karpathy LLM Wiki 패턴

2. Karpathy LLM Wiki 패턴 — 7 Canon (불변 7조)

Canon 1: sources/는 불변

Canon 2: 파일명은 YYYY-MM-DD_<kebab-slug>.<ext>

Canon 3: wiki/에 index.md + log.md 필수

Canon 4: WIKI_CLAUDE.md = 관리자 모드 진입 스키마

Canon 5: Query는 index.md 먼저

Canon 6: 페이지 간 참조는 wikilink만

Canon 7: sources/만 있으면 wiki/ 전체 재컴파일 가능

3. 본 프로젝트 추가 — 11조 Canon

4. 본 프로젝트 자체가 사례 — 살아있는 지식 그래프

4.1. 현재 상태 (2026-04-25)

4.2. 컴파일 흐름 (실제 운영)

4.3. 4 가지 자체 인용 사례

5. 21세기 종교개혁 도구로서의 LLMWiki

6. Vannevar Bush의 Memex 정신적 후계

7. LLMWiki vs Obsidian vs Notion

8. 본 LLMWiki를 다른 사역에 적용하는 단계 (Bootstrap 가이드)

8.1. 유형 A — 순수 LLMWiki (지식 누적만)

8.2. 유형 B — LLMWiki 서비스 (에이전트·스케줄러·저작·발행 포함)

8.3. 다른 사역 영역 적용 예시

9. 본 회차의 ★ 의미

사역 적용

본 LLMWiki를 자기 사역에 적용하는 4 주 가이드

본 회차 카드뉴스 5장 패턴

한계와 주의사항

LLMWiki의 한계

도입 시 주의

운영자 책임

핵심 인용 / 명언

다음 회차로 가는 다리

관련

같은 Part 3 회차

직전 Part 2

Karpathy 7 Canon (각각 별도 카드)

핵심 기술 용어

인물

운영 절차

외부 참조

AI의 선용 — Ch.7 LLMWiki, 살아있는 성경 지식 그래프

한 줄 정의

요약

본문 상세

1. RAG vs Compilation — 본질적 차이

1.1. RAG (Retrieval-Augmented Generation)의 한계

1.2. Compilation 모델 — Karpathy LLM Wiki 패턴

2. Karpathy LLM Wiki 패턴 — 7 Canon (불변 7조)

Canon 1: sources/는 불변

Canon 2: 파일명은 YYYY-MM-DD_<kebab-slug>.<ext>

Canon 3: wiki/에 index.md + log.md 필수

Canon 4: WIKI_CLAUDE.md = 관리자 모드 진입 스키마

Canon 5: Query는 index.md 먼저

Canon 6: 페이지 간 참조는 wikilink만

Canon 7: sources/만 있으면 wiki/ 전체 재컴파일 가능

3. 본 프로젝트 추가 — 11조 Canon

4. 본 프로젝트 자체가 사례 — 살아있는 지식 그래프

4.1. 현재 상태 (2026-04-25)

4.2. 컴파일 흐름 (실제 운영)

4.3. 4 가지 자체 인용 사례

5. 21세기 종교개혁 도구로서의 LLMWiki

6. Vannevar Bush의 Memex 정신적 후계

7. LLMWiki vs Obsidian vs Notion

8. 본 LLMWiki를 다른 사역에 적용하는 단계 (Bootstrap 가이드)

8.1. 유형 A — 순수 LLMWiki (지식 누적만)

8.2. 유형 B — LLMWiki 서비스 (에이전트·스케줄러·저작·발행 포함)

8.3. 다른 사역 영역 적용 예시

9. 본 회차의 ★ 의미

사역 적용

본 LLMWiki를 자기 사역에 적용하는 4 주 가이드

본 회차 카드뉴스 5장 패턴

한계와 주의사항

LLMWiki의 한계

도입 시 주의

운영자 책임

Canon 2: 파일명은 `YYYY-MM-DD_<kebab-slug>.<ext>`

Canon 2: 파일명은 `YYYY-MM-DD_<kebab-slug>.<ext>`