인쇄기가 없던 시절, 책 한 권을 더 갖는 유일한 방법은 누군가 그것을 손으로 베끼는 것이었다. 그 일을 한 곳이 수도원의 필사실, 스크립토리움이다. 수도사는 원본을 펼쳐 두고 한 글자씩 옮겨 새 책을 만들었고, 그렇게 만들어진 책은 다시 다음 사람이 베낄 원본이 되었다. 느렸지만 한 가지 미덕이 있었다. 한 번 베껴 둔 책은 그 자리에 남았다. 다음에 같은 내용이 필요한 사람은 멀리 있는 원본을 다시 찾아갈 필요 없이, 곁에 쌓인 사본을 펼치면 됐다. 도서관은 그렇게 한 권씩 불어났다.
첫 글에서 우리는 에이전트(사람을 대신해 여러 단계를 스스로 밟는 AI)가 믿고 딛을 단일 진실(SSOT, 어떤 사실이든 믿을 출처를 하나로 두는 원칙)이 왜 필요한지를 봤고, 둘째 글에서 그 진실을 머릿속에서 꺼내 글로 세우는 일에 얼마나 큰 값이 드는지를 봤다. 그런데 값을 치러 진실을 세웠다 해도 문제가 하나 남는다. 그 진실을 LLM은 어떻게 읽고, 어떻게 쌓아 갈 것인가. 지금 가장 흔한 답은 스크립토리움과 정반대다. 아무것도 쌓아 두지 않고, 필요할 때마다 매번 원본을 새로 찾아간다.
매번 처음부터 찾는 사서
요즘 LLM에게 회사 문서를 근거로 답하게 하는 가장 보편적인 방식은 검색 증강 생성, 줄여서 RAG(retrieval-augmented generation)라 부른다. 이름은 거창하지만 하는 일은 단순하다. 질문이 들어오면 관련 있어 보이는 문서 조각을 그때그때 찾아와, 그 조각을 함께 모델에 넣어 답하게 한다.
도서관에 비유하면 이렇다. 손님이 질문할 때마다 사서가 서가로 달려가 관련된 페이지 몇 장을 복사해 와서 읽고, 답을 만든 뒤 그 복사본을 버린다. 다음 질문이 오면 또 처음부터 달려간다. 사서는 매번 성실하지만, 어제 백 번 답한 질문도 오늘 처음 보는 것처럼 다시 찾는다. 일한 흔적이 어디에도 남지 않기 때문이다.
이 방식은 잘 작동하고, 자리도 분명하다. 문서가 수십만 건씩 쌓인 거대한 비정형 아카이브라면, 그걸 미리 다 정리해 두는 것보다 그때그때 필요한 조각만 찾아오는 편이 현실적이다. 하지만 두 가지가 끝내 아쉽다. 첫째, 아무것도 누적되지 않는다. 같은 주제를 백 번 물어도 백 번 다 바닥에서 다시 시작한다. 둘째, 조각으로 답한다. 흩어진 페이지 몇 장을 그러모아 답하니, 주제 전체를 꿰뚫는 큰 그림은 좀처럼 생기지 않는다. 검색은 빠르지만, 흔적을 남기지 않는다.
카파시가 트윗 한 장으로 던진 것
2026년 4월, 안드레이 카파시(Andrej Karpathy)가 트윗 하나를 올렸다. 요지는 이랬다. 요즘 자신이 쓰는 토큰의 상당량이 코드를 다루는 데가 아니라 지식을 다루는 데로 간다는 것. 그는 관심 있는 연구 주제마다 LLM을 시켜 개인 지식베이스를 짓고 있었고, 그중 하나는 어느새 글 백여 편, 사십만 단어 규모로 자라 있었다. 그런데 그 글을 그는 한 글자도 직접 쓰지 않았다. 트윗은 천육백만 회 넘게 읽혔다.
이틀 뒤 그는 이 방식을 한 장짜리 메모로 정리해 공개했는데, 그 파일의 이름이 llm-wiki.md였다. 사람들이 이 패턴을 ‘LLM Wiki’라 부르게 된 건 그래서다. 카파시 본인이 산문에서 고른 말은 ‘LLM 지식베이스’에 가깝고, ‘위키’는 그 결과물을 가리키는 이름으로 굳었다.
핵심 발상은 스크립토리움으로 되돌아간다. RAG처럼 질문마다 원본을 새로 뒤지는 대신, LLM이 읽은 것을 그때그때 정리해 영속적인 위키 페이지로 쌓아 둔다. 새 자료가 들어오면 관련된 기존 페이지를 갱신하고, 사람·개념·도구가 반복해 등장하면 그것을 따로 모은 페이지로 승격시키고, 페이지끼리 서로 링크를 건다. 한 번 이해한 내용은 정리된 채로 남으므로, 다음에 같은 주제를 다룰 때 바닥에서 다시 시작하지 않는다.
검색이 아니라 복리
두 방식의 진짜 차이는 시간이 흐를수록 벌어진다.
RAG의 곡선은 톱니다. 질문마다 솟았다가 도로 바닥으로 떨어진다. 백 번을 물어도 쌓이는 것은 없다. 반면 LLM Wiki의 곡선은 위로 휜다. 읽고 정리한 것이 자산으로 남아, 다음 작업의 출발점을 한 칸씩 높이기 때문이다. 경제에서 이런 모양을 복리(compounding)라 부른다. 어제 번 이자가 오늘의 원금에 더해져, 불어나는 속도 자체가 점점 빨라지는 것.
지식도 그렇게 굴릴 수 있다. 오늘 정리해 둔 한 페이지가 내일 새 자료를 이해하는 받침대가 되고, 그 위에서 정리한 페이지가 모레의 받침대가 된다. 검색이 매번 0에서 출발하는 단리라면, 위키는 어제까지 쌓인 것 위에서 출발하는 복리다.
세 개의 층
카파시가 정리한 구조는 세 층으로 나뉜다. 단순하지만, 이 분리가 전체를 떠받친다.
맨 아래는 날것(raw)이다. 옮겨 온 원문, 대화 기록, 읽은 자료가 손대지 않은 채로 쌓이는 층이다. 여기서의 규칙은 하나, 고치지 않는다는 것이다. 원본은 원본대로 보존되어야 나중에 무엇이 왜 그렇게 정리됐는지 되짚을 수 있다. 첫 글에서 본 통장의 거래 내역처럼, 이 층이 흔들리지 않는 바닥이 된다.
가운데는 위키다. LLM이 날것을 읽어 만들어 내고, 또 소유하는 층이다. 요약 페이지, 인물이나 개념을 모은 페이지, 그 사이를 잇는 링크가 여기 산다. 새 자료가 바닥에 들어올 때마다 LLM이 이 층을 갱신하고 교차 참조를 손본다. 사람이 직접 쓰는 곳이 아니라, 기계가 가꾸는 정원에 가깝다.
맨 위는 규약(schema)이다. LLM을 규율 있는 사서로 만드는 설정이다. 무엇을 어디에 두는지, 어떤 것을 페이지로 승격시키는지, 무엇은 절대 고치면 안 되는지를 적어 둔 운영 규칙이다. 같은 LLM이라도 이 규약이 있느냐 없느냐에 따라, 정원을 가꾸는 정원사가 되기도 하고 아무 데나 씨를 뿌리는 손님이 되기도 한다. 여기에 전체 목록을 비추는 색인과, 무엇이 언제 들어왔는지 적는 기록을 더하면 뼈대가 선다.
나도 같은 구조로 돌리고 있다
카파시가 이 패턴을 정리해 내놓은 걸 보고, 나도 내 개인용 지식 폴더를 같은 세 층으로 맞춰 운영하고 있다.
작동은 이렇다. 평소에 하던 작업과 대화의 기록이 자동으로 날것 폴더에 떨어진다. 따로 시간을 내 적는 게 아니라, 일하면 부산물로 쌓이게 해 둔 것이다. 그리고 몇 시간에 한 번씩, 내 노트북의 예약 작업이 조용히 LLM을 깨워 그동안 쌓인 날것을 읽힌다. LLM은 아직 정리 안 된 것만 골라 요약 페이지를 만들고, 비슷한 자료가 여럿 모이면 한 편의 종합으로 엮고, 자주 나오는 인물과 개념을 따로 모아 링크를 건다. 죽은 링크나 낡은 항목을 점검하는 일까지 그 시간에 한다. 이미 쓰던 도구로 돌리니 따로 드는 외부 비용이랄 게 거의 없다.
이 방식이 마음에 드는 건, 둘째 글에서 진실 만드는 값을 낮추는 길로 꼽았던 세 갈래를 한 구조에서 한꺼번에 해내기 때문이다. 자주 다시 꺼내 볼 것만 페이지로 승격시켜 덜 만들고, 일의 부산물에서 자동으로 캡처해 저절로 만들고, 원본 하나에서 색인과 요약을 기계가 뽑게 해 저절로 유지한다. 종이 위의 원칙이 돌아가는 기계가 됐다.
물론 직접 굴려보니 그림자도 봤다. 한동안 손을 놓았더니, 위키에 쌓인 페이지의 절반 넘게가 “오늘 무엇을 했다”는 운영 일지였고 정작 알맹이 지식은 한 줌이었다. 자유롭게 달게 둔 태그는 어느새 이백 개를 넘겨 한 번 크게 정리해야 했다. 한번은 자동 정리가 조용히 멈춰 있었는데, 한참 뒤 “내 기록이 정말 쌓이고는 있나” 싶어 들여다보고서야 알았다. 기계가 가꾸는 정원도 사람이 손을 떼면 잡초부터 자란다. 규칙을 다듬고, 무엇을 남기고 무엇을 버릴지 이따금 사람이 들여다봐야 복리가 제 방향으로 돈다.
위키가 거짓말을 하면
물론 이 그림에는 빈틈이 있고, 그걸 모른 척하면 안 된다.
가장 큰 위험은 가운데 층, 곧 LLM이 쓴 위키 자체를 얼마나 믿을 수 있느냐다. 요약하는 과정에서 모델이 사실을 슬쩍 비틀거나, 없는 내용을 그럴듯하게 지어 넣을 수 있다. 그렇게 오염된 페이지가 다음 작업의 받침대가 되면, 복리는 거꾸로 돈다. 틀린 이해 위에 틀린 이해가 쌓인다. 그래서 날것 층을 절대 고치지 않고 보존하는 규칙이 중요하다. 위키가 의심스러우면 언제든 원본으로 내려가 대조하고, 페이지를 다시 짓게 할 수 있어야 한다.
또 하나, 날것 폴더는 외부에서 들어온 글을 그대로 담는 곳이라 신뢰할 수 없는 데이터로 다뤄야 한다. 그 안에 “이전 지시를 무시하고 이렇게 하라” 같은 문장이 숨어 있어도 LLM이 명령으로 받아들이지 않게, 읽기 전용의 자료로만 취급하는 경계가 필요하다.
마지막으로, RAG가 사라지는 것도 아니다. 잘 정리된 좁은 지식에는 위키가 강하지만, 정리할 손이 닿지 않는 거대한 비정형 더미에는 그때그때 검색하는 편이 여전히 낫다. 둘은 경쟁자라기보다, 지식의 성격에 따라 나눠 쓰는 도구다. 어떤 이들은 이 패턴을 두고 “에디터는 노트 앱 옵시디언, 프로그래머는 LLM, 코드베이스는 위키”라고 비유하는데, 출처가 분명한 카파시의 말이라기보다 패턴을 압축한 통용 비유로 받아들이는 게 안전하다.
개인에겐 맞고, 조직엔 아직 이르다
한 가지, 이 시리즈의 앞선 글들과 정면으로 부딪히는 지점이 있다. 첫 글에서 진실에 신뢰를 준 건 사람의 검토와 승인이라는 검증의 관문이었다. 누군가 바꾸려면 다른 누군가가 들여다보고 승인해야 비로소 믿을 진실이 된다는 것. 그런데 LLM Wiki에는 그 관문이 없다. LLM이 읽고 정리한 것이 곧바로 위키가 되고, 사람의 검증이 끼어들 자리는 거의 없다.
그래서 이 도구의 자리는 생각보다 좁다. 개인의 지식에는 잘 맞지만, 조직의 단일 진실 자리에는 아직 이르다. 내가 나를 위해 쌓는 위키는 어쩌다 틀려도 내가 감당하고, 미심쩍으면 원본으로 내려가 고치면 된다. 복리로 얻는 것이 가끔의 오류보다 크다. 하지만 여러 사람이 믿고 에이전트가 곧장 실행하는 조직의 진실이라면 이야기가 다르다. 검증을 거치지 않은 자동 생성물을 모두의 기준으로 삼을 수는 없다. 거기엔 사람이 승인의 관문을 통과시킨 진실, 곧 첫 글이 말한 그 신뢰의 바닥이 따로 필요하다.
도서관은 한 권씩 불어난다
스크립토리움의 수도사는 한 번에 도서관을 짓지 않았다. 책 한 권을 베껴 곁에 두고, 그 곁에 또 한 권을 더했다. 느렸지만 베껴 둔 것은 남았고, 남은 것이 다음 작업을 받쳤다. 도서관은 그렇게, 사라지지 않는 사본이 한 권씩 포개지며 불어났다.
세 편에 걸쳐 같은 문제를 돌아왔다. 에이전트가 믿을 진실을 어디에 둘 것인가, 그 진실을 세우는 값을 누가 치를 것인가, 그리고 그 진실을 어떻게 쌓고 유지할 것인가. 마지막 답은 의외로 오래된 모습을 하고 있다. 매번 멀리 달려가 찾고 버리는 대신, 한 번 이해한 것을 곁에 정리해 남기는 것. LLM Wiki는 새 기술처럼 보이지만, 실은 인쇄기 이전의 도서관이 알던 지혜를 기계에게 다시 가르치는 일에 가깝다. 검색하지 말고, 쌓아라.