LLM 위키를 두고 흔히 이런 말이 나옵니다. “어차피 AI가 알아서 정리해주는 것 아닌가.” 반은 맞습니다. 그리고 이 반만 맞는 말이 위키를 잘못 만들게 하는 가장 큰 원인입니다.
LLM 위키는 도구가 아니라 운영 방법론입니다. 한 번 방식을 세워두면 자료를 넣고, 꺼내 쓰고, 점검하는 과정이 반복되면서 지식이 쌓입니다. 다만 오해하면 안 되는 점이 있습니다. 이것은 자동으로 굴러가는 파이프라인이 아니라, 사람이 규칙을 쥔 반자동 운영입니다. 그렇게 쌓은 한 덩어리를 블로그에도, 강의에도, 책에도 다시 꺼내 씁니다. 만드는 곳은 하나인데 쓰는 곳은 여럿입니다. 이 글은 그 운영 방법론이 무엇으로 이루어지는지, 잘 세우려면 무엇을 정해야 하는지, 그리고 그 과정에서 AI가 맡는 몫과 사람이 맡는 몫이 어디서 갈리는지를 짚습니다.
Contents
위키는 왜 운영 방법론인가
LLM 위키는 AI 연구자 앤드레이 카파시(Andrej Karpathy)가 2026년 4월 공개한 운영 방법론입니다. 특정 앱이 아니라, LLM이 원시 자료를 읽고 구조화된 마크다운 위키로 누적하고 정제하고 유지하는 방식입니다. 사람은 자료를 모으고 질문을 던지고, LLM이 요약과 교차 참조와 정리를 전담합니다. 1945년 배니버 부시가 상상했던 ‘메멕스’, 곧 개인이 모든 지식을 연결해 보관하는 기계를, 유지보수를 맡아줄 AI가 등장하면서 실현한 형태입니다.
이것을 방법론이라 부르는 이유는 구성과 절차가 정해져 있기 때문입니다. 먼저 구성은 세 계층입니다. 첫째는 원시 자료입니다. 손대지 않는 진실의 출처이고, AI는 이것을 읽기만 합니다. 둘째는 위키 페이지입니다. AI가 전적으로 소유하며 요약과 개념과 비교가 쌓이는 곳입니다. 셋째는 스키마, 곧 규칙을 적은 설정 파일입니다. 페이지를 어떻게 나누고 출처를 어떻게 남길지 정하는 계약입니다.
이 세 계층 위에서 세 가지 작업이 반복됩니다. 넣기(Ingest)는 자료를 읽고 논의한 뒤 요약 페이지와 관련 페이지, 목차와 로그를 갱신하는 입력입니다. 자료 한 건이 페이지 열에서 열다섯 개를 건드립니다. 꺼내기(Query)는 목차를 먼저 읽고 본문을 정독해 출처와 함께 답을 만드는 과정이며, 좋은 답은 다시 새 페이지로 편입됩니다. 점검(Lint)은 모순과 외톨이 페이지, 낡은 주장과 빈틈을 주기적으로 찾아 보강하는 정합성 관리입니다. 구성과 절차가 고정되어 있으니 한 번 방식을 세워두면 계속 돌아갑니다. 단, 매 단계에서 무엇을 넣고 무엇을 고칠지는 사람이 판단합니다. 방법론이라는 말의 실제 내용이 여기 있습니다.
검색이 아니라 누적 — 방법론이 필요한 이유
왜 굳이 방법론까지 세워야 할까요. 그냥 그때그때 검색하면 되지 않을까요. 여기서 RAG(검색 증강 생성)와의 차이가 드러납니다.
RAG는 질문이 들어올 때마다 벡터 스토어에서 관련 조각을 그때그때 찾아옵니다. 누적이 없어, 여러 문서를 묶어야 하는 질문이면 매번 조각을 새로 꿰맞춥니다. 위키는 자료를 넣는 순간 요약과 교차 참조와 모순 표시를 끝내 둡니다. 한 번 컴파일해 두고 최신 상태로 유지하는, 쌓일수록 단단해지는 영속 산출물입니다. 도서관에 비유하면 RAG는 질문할 때마다 서가를 처음부터 뒤지는 사서이고, 위키는 미리 주제별로 분류하고 색인까지 붙여 둔 서가입니다.
위키가 RAG보다 효율적이라는 측정도 있지만, 대개 단일 벤더가 낸 값이라 정량 근거로는 아직 약합니다. 수치보다 구조의 차이로 이해하는 편이 정확합니다.
여기서 짚어야 할 것은 사람이 위키를 포기하던 진짜 이유입니다. 읽기나 사고가 아니라 유지보수였습니다. 새 자료가 들어올 때마다 기존 노트와 연결하고, 요약을 갱신하고, 어긋나는 내용을 정리하는 일이 사람 손으로는 번거로웠습니다. 그래서 노트는 쌓이기만 하고 죽은 창고가 되었습니다. LLM 위키가 달라진 지점은 바로 이 유지보수를 AI가 거의 공짜로 처리한다는 데 있습니다. 80년 묵은 메멕스 구상이 이제야 실현 가능해진 것도, 긴 컨텍스트와 파일을 직접 읽고 쓰는 에이전트, 마크다운 평문 노트 앱이 동시에 성숙했기 때문입니다.
한 번 세워 여러 곳에서 쓴다
방법론으로 세워 두면 가장 큰 이득이 출력 단계에서 나옵니다. 위키는 저장소가 아니라 정제된 생산 원천입니다. 한 번 정리한 페이지는 후크와 문체만 바꿔 여러 매체로 분기합니다.
같은 주제 페이지 하나에서 블로그 글이 나오고, 강의 슬라이드가 나오고, 책 원고의 한 꼭지가 나옵니다. 채널마다 요구가 다를 뿐 근거는 같습니다. 블로그는 검색 유입과 소제목 구조를, 페이스북은 후크와 반응을, 강의는 비교와 실습 소재를, 책은 깊이와 경험을 우선합니다. 그런데 그 밑을 받치는 사실과 수치와 출처는 한 번 정리한 위키에서 그대로 끌어옵니다. 매번 처음부터 자료를 찾는 비용이 사라지는 것입니다.
여기서 한 걸음 더 들어가면 ‘합성 계층’이라는 개념이 나옵니다. 위키 페이지는 두 종류로 나뉩니다. 개념 페이지는 외부 사실과 데이터와 출처를 담고, 경험 페이지는 본인의 1인칭 현장 기록을 담습니다. 둘을 섞지 않고 따로 둡니다. 그리고 글을 쓸 때 둘을 한자리에서 결합합니다. 책의 독창성과 강의의 신뢰성은 개념에서도 경험에서도 나오지 않습니다. 전문가의 견해와 자신의 경험이 겹치는 지점, 곧 합성이 일어나는 자리에서 나옵니다. 이 구조가 있어야 원소스 멀티유즈가 단순 복사가 아니라 재생산이 됩니다.
그리고 그 재생산의 결과가 다시 위키로 돌아옵니다. 글을 쓰다 발견한 새 통찰과 연결은 대화 기록에 묻어두지 않고 새 페이지로 편입합니다. 콘텐츠를 만들수록 위키가 자라고, 위키가 자랄수록 다음 콘텐츠가 빨라지는 순환이 만들어집니다. 방법론이라는 말이 가장 잘 드러나는 지점이 여기입니다.
잘 만드는 법 — 방법론을 세우는 다섯 결정
그렇다면 잘 세운 위키와 그렇지 않은 위키는 무엇이 다를까요. 다섯 가지 결정에서 갈립니다.
첫째, 스키마입니다. 폴더 구조의 의미, 페이지 명명 규칙, 공통 섹션, 출처 표기, 모순 처리 방식을 설정 파일에 적습니다. 이 규칙은 AI가 규율 있는 관리자처럼 행동할 가능성을 높입니다. 규칙을 적어둔다고 AI가 매번 정확히 따르지는 않으므로, 뒤의 점검이 이 빈틈을 메웁니다. 처음부터 완성할 필요는 없습니다. 첫 자료를 넣으며 드러난 규칙을 누적해, 위키와 규칙을 함께 키우는 공진화가 핵심입니다.
둘째, 무엇을 넣을지입니다. 재사용과 종합 가치가 있는 큐레이션된 자료만 넣습니다. 일회성 자료는 제외합니다. 아무거나 넣으면 위키가 아니라 창고가 됩니다. 넣는 자료의 품질이 결과를 좌우한다는 원칙이 여기서 나옵니다. 리서치 노트를 바로 정식 페이지로 올리지 않고, 같은 주제가 여러 건 모이고 다시 쓸 일이 분명할 때만 승격하는 기준도 같은 맥락입니다.
셋째, 단건이냐 일괄이냐입니다. 카파시는 한 번에 하나씩 넣고 요약을 직접 확인하는 단건 방식을 권합니다. 한꺼번에 몰아 넣으면 품질과 강조점 통제가 약해집니다. 속도를 얻는 대신 통제를 잃는 거래입니다.
넷째, 개념과 경험의 분리입니다. 앞서 말한 합성 계층이 작동하려면 둘이 처음부터 다른 페이지에 있어야 합니다. 경험 페이지에 외부 통계를 섞으면, 나중에 경험만 골라 쓰려 할 때 다시 분리해야 하는 비용이 생깁니다.
다섯째, 점검과 규모 관리입니다. 정기적으로 모순과 고아 페이지와 낡은 주장을 점검합니다. 구조 점검은 자동으로, 의미 점검은 AI로, 시각 점검은 그래프뷰로 나눠 봅니다. 규모가 약 100개 소스, 5만에서 10만 토큰을 넘어서면 목차 기반 탐색만으로는 후보를 좁히기 어려워지므로, 그때 검색 도구를 하이브리드로 얹습니다. 필요할 때만 복잡성을 더한다는 원칙입니다. 작으면 목차, 커지면 검색입니다.
그럼 무엇부터 시작할까요. 거창한 준비는 필요 없습니다. 규칙을 적을 문서 하나를 위키 폴더 맨 위에 만들고, 방금의 다섯 결정 중 폴더 구분·페이지 이름·공통 틀·출처 등급 네 가지만 먼저 적습니다. 그다음 자료를 한 건씩 넣으며 나머지 규칙을 채웁니다. 완벽한 설계도부터 그리려 하면 시작을 못 합니다. 규칙 문서 한 장에서 출발하는 것으로 충분합니다.
“AI가 알아서 만든다”의 진실
이제 처음의 명제로 돌아옵니다. “어차피 AI가 알아서 만든다.” 이 말의 절반은 사실입니다. 나머지 절반이 문제입니다.
AI가 실제로 잘하는 일이 있습니다. 자료를 요약하고, 페이지끼리 연결하고, 낡은 내용을 갱신하는 유지보수입니다. 사람이 위키를 포기하게 만들던 바로 그 부담을 AI가 거의 공짜로 처리합니다. 여기까지는 “알아서”가 맞습니다.
그런데 앞서 본 다섯 가지 결정을 다시 보면, 그중 어느 것도 AI가 알아서 정해주지 않습니다. 스키마를 설계하는 것, 무엇을 넣을지 고르는 것, 단건으로 통제할지 정하는 것, 개념과 경험을 나누는 것, 점검의 기준을 세우는 것은 모두 사람의 판단입니다. AI는 규칙 안에서 실행할 뿐, 규칙 자체를 대신 만들어주지 않습니다.
한계도 분명합니다. AI는 근거 없는 질문에 사실이 아닌 답을 지어낼 때가 있습니다. 그래서 모순과 빈틈을 사람이 확인하는 마지막 단계가 필요하고, 자료를 한 번에 하나씩 넣고 요약을 직접 확인하는 편이 안전합니다. 자료가 약 5만에서 10만 토큰을 넘으면 탐색이 어려워지고, 무엇보다 넣는 자료의 품질이 결과 전체를 좌우합니다. 좋은 자료를 넣으면 좋은 위키가 되고, 아무 자료나 넣으면 정돈된 형태의 창고가 됩니다. AI 모델이 좋아진다고 이 문제가 사라지지 않습니다. 입력이 나쁘면 아무리 성능이 좋아도 출력이 나쁩니다.
그래서 “AI가 알아서 만든다”를 정확히 고쳐 쓰면 이렇습니다. AI는 방법론을 굴리는 힘이지, 방법론을 설계하는 주인이 아닙니다. 유지보수는 AI의 몫이고, 방향은 사람의 몫입니다.
장점은 조건부다
한 가지 더 정직하게 짚을 것이 있습니다. 이 방법론의 장점은 무조건이 아니라 조건부입니다.
첫째, 자료를 자주 재사용하는 사람이어야 합니다. 작가나 강사처럼 같은 자료를 책과 강의와 글로 반복 활용하면 재검색 비용 절감이 큽니다. 가끔 쓰는 사람에게는 이득이 작습니다. 둘째, 자료가 어느 정도 쌓여 있어야 합니다. 방법론 자체도 첫 한두 달은 자산 정리와 집중 인제스트에 투입해야 운영 단계에 들어간다고 봅니다. 그 전에는 장점이 오히려 마이너스입니다. 셋째, 계속 점검해야 합니다. 방치한 위키는 낡은 근거를 제공해 도움이 아니라 해가 됩니다. 유지 비용이 지속됩니다.
반대 경우도 있습니다. 자료가 약 100소스 이하이고 재사용 빈도가 낮다면, 구축과 유지의 오버헤드가 이득을 넘어설 수 있습니다. 이때는 그냥 폴더 검색이 낫습니다. 그래서 “제대로 된 장점”은 자주 재사용하고, 자료를 축적했고, 초기 투자를 감수한 사람에게서 나옵니다. 이 전제를 빼고 장점만 말하면 과장이 됩니다.
방법론의 방향은 사람이 정한다
정리해 봅니다. LLM 위키는 도구가 아니라 운영 방법론이고, 그 방법론은 세 계층과 세 작업으로 굴러갑니다. 한 번 세워 두면 블로그와 강의와 책으로 갈라져 나가고, 그 산출물이 다시 위키로 돌아오는 순환을 이룹니다. 잘 세우는 일은 모델을 고르는 문제가 아니라 규칙과 자료를 정하는 문제입니다.
그러니 기준을 옮겨야 합니다. “어떤 AI가 더 똑똑한가”보다 “나는 어떤 규칙을 세우고 무엇을 넣을 것인가”를 먼저 물어야 합니다. 그리고 그 앞에 “나는 이 자료를 자주 다시 쓸 사람인가”를 물어야 합니다. 잘 세운 위키와 그렇지 않은 위키의 차이는 모델 성능이 아니라, 사람이 정한 규칙과 넣은 자료의 질에서 갈립니다. 방법론은 AI가 굴리고, 그 방향은 사람이 정합니다. 위키를 세운다는 것은 결국, AI에게 맡길 일과 내가 쥐고 있어야 할 일을 나누는 일입니다.
