지난 몇 년 동안 목회자와 연구자들이 AI를 활용하는 방식은 대체로 비슷했습니다.
질문을 던지고, 답을 받고, 다음 질문을 던집니다. 대화가 끝나면 그 대화 안에서 얻은 통찰도 함께 사라집니다. 필요하면 다시 묻고, AI는 다시 처음부터 찾습니다.
편리하지만 어딘가 허전한 방식이었습니다. 지식이 쌓이지 않기 때문입니다.
올해 봄, 안드레 카파시가 짧은 글 하나를 공개했습니다. 제목은 「LLM Wiki」. 거창한 논문도, 새로운 모델 발표도 아니었습니다.
그런데 이 글이 개발자 커뮤니티에서 상당한 반향을 일으켰습니다.
AI를 '답변 기계'가 아니라
'나의 지식을 관리하는 사서'로 쓰자는
발상의 전환이 담겨 있었기 때문입니다.
이 글에서는 그 아이디어가 무엇인지, 그리고 목회와 성경 연구에 어떻게 옮겨 올 수 있을지 정리해 보려 합니다.
안드레 카파시, 누구인가
카파시는 OpenAI의 창립 멤버였고, 이후 테슬라에서 자율주행 AI 부문을 이끌었습니다. 스탠퍼드에서 딥러닝 강의를 맡아 수많은 개발자를 길러냈고, 지금은 특정 회사에 속하기보다 AI 교육과 연구, 그리고 개인 프로젝트에 집중하고 있습니다.
"바이브 코딩(vibe coding)"이라는 표현을 처음 쓴 사람이기도 합니다. 코드를 한 줄씩 직접 쓰는 대신 AI에게 의도를 말하고 결과를 다듬어 가는 방식을 가리키는 말인데, 지금은 업계 표준 용어처럼 굳어졌습니다.
그가 주목받는 이유는 단순히 경력 때문이 아닙니다. 그는 기술을 과장하지 않고, 실제로 자기 손으로 써 본 것만 이야기하는 사람으로 알려져 있습니다.
그래서 그가 "이렇게 써 보니 좋더라"라고 말하면 사람들이 귀를 기울입니다.
지금까지의 방식, RAG의 한계
AI에게 내 문서를 읽히는 가장 흔한 방법은 RAG(검색 증강 생성)입니다. 문서를 잘게 쪼개 저장해 두고, 질문이 들어오면 관련된 조각을 찾아 AI에게 건네주는 구조입니다. 실무에서 널리 쓰이고 있고, 잘 만들면 충분히 유용합니다.
문제는 이 방식이 매번 '처음부터' 시작한다는 데 있습니다.
어제 AI가 열 개의 문서를 읽고 정리해 준 내용은 오늘 질문에 아무런 영향을 주지 않습니다. 오늘도 다시 검색하고, 다시 읽고, 다시 요약합니다. 조각난 문서 사이의 관계, 예컨대 "이 논문의 주장이 저 책의 3장과 충돌한다"는 식의 통찰은 어디에도 남지 않습니다.
카파시는 이 지점을 정확히 짚었습니다.
검색은 잘 되는데,
이해는 누적되지 않는다.
목회자의 서재를 떠올려 보십시오
설교 준비를 할 때마다 주석 다섯 권을 처음부터 다시 펼치는 것과, 지난 10년간 정리해 둔 나만의 주석 노트를 펼치는 것은 전혀 다른 경험입니다.
RAG는 전자에 가깝습니다.
카파시의 제안: AI가 위키를 직접 쓰게 하라
카파시의 제안은 이렇습니다. 문서를 조각내서 검색하는 대신, AI에게 마크다운으로 된 위키를 통째로 맡기자는 것입니다.
새 자료가 들어오면 AI가 읽고, 관련 위키 페이지를 새로 쓰거나 기존 페이지를 고칩니다. 페이지들끼리 링크를 걸고, 목차를 갱신하고, 모순이 생기면 표시합니다. 시간이 지날수록 위키는 두꺼워지고 정교해집니다.
핵심은 '누적'입니다. AI가 오늘 이해한 것이 내일의 출발점이 됩니다. 같은 질문을 다시 던지면 AI는 원자료를 뒤지는 대신 이미 정리된 위키 페이지를 읽습니다.
더 빠르고, 더 일관되고, 무엇보다
내가 그 지식의 성장 과정을
눈으로 볼 수 있습니다.
카파시는 이것을 위해 특별한 소프트웨어를 만들지 않았습니다.
· 마크다운 파일이 담긴 폴더 하나
· Claude Code 같은 코딩 에이전트
· 위키를 열람하기 위한 Obsidian
이것이 전부였습니다. 이미 있는 도구를 다르게 조합했을 뿐입니다.
어떻게 작동하는가
구조는 세 단계로 요약됩니다.
자료를 넣습니다. 논문, 기사, 책의 발췌, 회의 메모, 무엇이든 원본 폴더에 그대로 둡니다
2. AI가 그 자료를 읽고 위키를 갱신합니다. 이미 있는 주제면 해당 페이지에 내용을 보강하고, 새로운 주제면 페이지를 만듭니다
3. 페이지 사이의 연결을 정리합니다. 개념 페이지, 인물 페이지, 출처 페이지가 서로 링크되고, 색인 페이지가 전체 지도를 유지합니다
여기에 더해진 두 가지 장치
하나는 '스키마' 문서입니다. 위키를 어떤 구조로 유지할지, 페이지 이름은 어떻게 붙일지, 요약은 어느 정도 길이로 쓸지를 적어 둔 규칙서인데, AI는 매번 작업 전에 이것을 읽습니다.
다른 하나는 정기적인 '점검(lint)' 입니다. 끊어진 링크, 서로 모순되는 서술, 오래되어 갱신이 필요한 페이지를 AI가 주기적으로 훑어 보고합니다.
사람이 손으로 하기엔 지루한 일이지만, 위키의 품질을 유지하는 데 결정적인 작업입니다.
사람은 큐레이터, AI는 사서
이 구조에서 가장 흥미로운 부분은 역할의 분담입니다. 카파시는 사람의 역할을 '큐레이터'로, AI의 역할을 '사서'로 설명합니다.
· 사람 — 무엇을 위키에 넣을지, 무엇을 물을지, 어떤 방향으로 지식을 키울지 결정합니다
· AI — 읽고, 요약하고, 분류하고, 연결하는 일을 맡습니다
이것은 AI에게 판단을 넘기는 구조가 아닙니다. 오히려 반대입니다. 사람이 판단에 집중할 수 있도록, 판단 이전의 반복 노동을 AI가 가져가는 구조입니다.
도서관에서 사서가 아무리 유능해도 어떤 책을 읽을지는 독자가 정하는 것과 같습니다.
목회자에게 이 비유는 특히 와닿을 것입니다.
본문을 어떻게 해석하고 무엇을 선포할지는
끝까지 사람의 몫이고, 그래야만 합니다.
원본은 그대로, 위키는 자란다
설계 원칙 가운데 꼭 기억해야 할 것이 하나 있습니다. 원본 자료에는 절대 손대지 않는다는 원칙입니다.
원본 폴더는 읽기 전용입니다. AI가 쓰고 고치는 것은 오직 위키 페이지뿐입니다.
이 원칙이 중요한 이유는 신뢰 때문입니다
AI가 요약을 잘못했거나 해석을 과하게 했을 때, 언제든 원본으로 돌아가 확인할 수 있어야 합니다. 위키 페이지마다 어느 원본에서 왔는지 출처가 남아 있고, 그 출처는 변하지 않습니다.
성경 연구에 비유하자면
본문은 고정되어 있고
주석만 계속 두꺼워지는 셈입니다.
주석이 아무리 쌓여도 본문을 대체하지는 않습니다.
그렇게 원본을 지키면서 위키만 키워 가면, 어느 순간 위키가 나 자신보다 내 자료를 더 잘 기억하는 상태에 이릅니다. 카파시가 말한 "쓸수록 똑똑해지는" 경험이 바로 그 지점입니다.
목회에 적용하면
저는 이 아이디어를 읽자마자 설교 준비 과정을 떠올렸습니다.
목회자는 매주 새 본문을 붙듭니다. 주석을 읽고, 원어를 살피고, 묵상을 기록하고, 설교문을 씁니다. 그 과정에서 생기는 통찰은 대부분 설교문 한 편에 갇힌 채 잊힙니다.
3년 전 같은 본문을 다뤘을 때 무엇을 발견했는지 기억하는 목회자는 많지 않습니다.
설교 준비에 옮겨 오면
LLM Wiki 구조를 여기에 적용하면 이렇게 됩니다. 원본 폴더에는 주석 발췌, 원어 자료, 그동안 쓴 설교문, 묵상 노트가 들어갑니다. AI는 이것을 읽고 성경 각 권, 각 장, 주요 주제별로 위키 페이지를 만듭니다.
"로마서 8장" 페이지에는 내가 읽은 주석의 핵심, 내가 했던 설교의 요지, 관련 본문으로의 링크가 정리됩니다.
다음에 로마서 8장을 다시 설교할 때,
나는 빈 화면이 아니라
나의 지난 연구 위에서 출발합니다.
주제별 연결도 가능해집니다
"은혜", "고난", "성령" 같은 주제 페이지가 자연스럽게 생기고, 서로 다른 본문에서 발견한 통찰이 한 페이지에 모입니다. 교인 심방 기록이나 강의 자료를 함께 넣으면 목회 전반의 지식이 하나의 체계로 묶입니다.
제가 개발해 사용 중인 '나만의 주석' 앱도 결국 이 방향을 향하고 있습니다. 개인의 성경 연구가 사라지지 않고 쌓이도록 하는 것입니다.
어떻게 시작할까
거창하게 시작할 필요가 없습니다. 폴더 하나면 됩니다.
raw 폴더에 원본 자료를 넣고, wiki 폴더를 비워 둡니다. 그리고 위키를 어떤 규칙으로 관리할지 적은 짧은 문서를 하나 만듭니다.
· 페이지는 성경 권별로 나눈다
· 각 페이지 상단에 출처를 표시한다
· 요약은 다섯 문장을 넘기지 않는다
이 정도면 충분합니다.
에이전트를 연결합니다
다음으로 Claude Code 같은 코딩 에이전트를 이 폴더에 연결합니다. 코딩 도구라는 이름이 붙어 있지만, 실제로는 폴더 안의 파일을 읽고 쓰는 데 능한 범용 에이전트입니다.
새 자료를 raw에 넣고 "이 자료를 읽고 위키를 갱신해 달라"고 요청하면 됩니다. 처음 몇 번은 결과를 꼼꼼히 살피며 규칙 문서를 다듬으십시오. 규칙이 자리를 잡으면 이후는 거의 자동입니다.
자라는 모습을 눈으로 봅니다
마지막으로 Obsidian으로 wiki 폴더를 엽니다. 마크다운 파일을 그대로 읽어 주고, 페이지 사이의 링크를 그래프로 보여 줍니다.
위키가 자라는 모습을 눈으로 확인하는 것만으로도 꾸준히 이어 갈 동기가 생깁니다. 한 달만 해 보시면 왜 카파시가 이 방식을 두고 그렇게 들뜬 어조로 글을 썼는지 알게 되실 것입니다.
마무리: 기술은 도구, 사역은 목적
LLM Wiki는 새로운 기술이 아닙니다. 이미 있는 도구를 다르게 배치한 '방식'입니다.
그래서 오히려 오래갈 것이라 생각합니다. 모델이 바뀌고 도구가 바뀌어도, 지식을 원본과 정리본으로 나누고 정리본을 AI에게 맡긴다는 구조는 그대로 남을 것입니다.
목회자에게 이 방식이 주는 약속은 분명합니다. 매주 흘려보내던 연구가 쌓이고, 쌓인 것이 서로 연결되고, 그 위에서 더 깊은 말씀을 준비할 수 있다는 것입니다.
기술이 목회를 대신하는 것이 아니라,
목회자가 본문과 성도에게 더 집중할 수 있도록
뒤에서 받쳐 주는 구조입니다.
저는 이것을 '지식이 쌓이는 만큼 말씀을 더 깊이 나누는' 도구라고 부르고 싶습니다.
한 분이라도 이 글을 읽고 폴더 하나를 만들어 보신다면, 이 글의 목적은 충분히 이룬 셈입니다.
손하람 목사
참고: Andrej Karpathy, "LLM Wiki" (GitHub gist, 2026)
이 글은 손하람 목사의 창가에 2026. 9. 19에 올린 글을 옮긴 것입니다.