들어가며: 책에서 보고 궁금해진 단어 “LLM Wiki”

『클로드 올인원 with 코워크, 코드, 디자인』이라는 책을 읽다가 ‘LLM Wiki’라는 단어를 봤습니다. 처음 보는 단어는 아니었습니다. 이전에 들어봤던 단어인데, 그때는 이해하지 않은 상태로 이런게 있구나 하고 그냥 지나쳤습니다.
이번에 갑자기 호기심이 생겨 이 단어의 출처인 Andrej Karpathy의 gist를 찾아 읽고, 나만의 언어로 이해한 내용을 정리해 글로 쓰고자 합니다.

개념: LLM Wiki란?

LLM Wiki는 내가 모은 자료를 LLM이 읽고 정리해서, 나만 보는 백과사전 한 권으로 계속 만들어 나가는 방식입니다. 위키백과처럼 문서들이 서로 링크로 이어져 있고, 새 자료가 들어올 때마다 관련된 문서들이 최신 정보로 수정됩니다.

기존 위키백과와 다른 점은, 편집을 사람이 아닌 LLM이 맡아서 유지보수 비용이 거의 들지 않는다는 점입니다. 사람이 관리하는 위키는 문서가 늘어날수록 손이 못 미쳐 방치되기 쉽지만, LLM은 지치지 않고 매번 관련 문서를 찾아 고칩니다. 다만 이게 완전히 저절로 굴러가는 건 아니라서, 나중에 다시 다룰 "점검(lint)" 과정이 따로 필요합니다.

RAG(Retrieval-Augmented Generation, 검색 증강 생성)

RAG는 질문이 들어오면 자료에서 관련 있는 부분을 먼저 찾아온 뒤, 그 내용을 참고해 답을 만드는 방식입니다. LLM이 원래 몰랐던 내용도 자료만 붙여주면 답할 수 있게 해줍니다. NotebookLM, ChatGPT 파일 업로드 등이 여기에 해당됩니다.

잘 작동하지만, 질문할 때마다 LLM이 자료를 처음부터 다시 뒤져서 답변해 줍니다. 즉 파일 자체는 남아 있어도, 그 파일을 읽고 이해한 결과는 남지 않습니다. 이게 실제로는 세 가지 문제로 이어집니다.

• 매번 같은 일을 반복합니다. 어제 'LLM Wiki'라는 개념을 이해하려고 자료 5개를 붙여서 좋은 답을 받았어도, 오늘 비슷한 질문을 하면 LLM은 그 5개 자료를 또 처음부터 읽고 관련 부분을 다시 찾아야 합니다.
• 답이 매번 달라질 수 있습니다. 그날 어떤 자료를 붙였는지, 질문을 어떻게 던졌는지에 따라 결과가 달라져서, 어제 받은 좋은 답을 오늘도 똑같이 받는다는 보장이 없습니다.
• 여러 자료를 엮어야 하는 질문일수록 약해집니다. 다섯 개 문서를 종합 해야 나오는 통찰이나, "A 자료와 B 자료가 서로 다른 얘기를 하네" 같은 발견은 그 대화창을 벗어나면 사라집니다. 자료는 계속 쌓이는데, 그 자료에 대한 이해는 깊어지지 않습니다.

LLM Wiki는 무엇이 다른가

LLM Wiki는 질문할 때 정리하지 않고, 자료를 넣을 때 백과사전을 만들듯 미리 정리를 해둡니다. 새 자료가 들어오면 LLM이 그걸 읽고, 관련된 기존 문서들을 찾아가서 고칩니다. 문서에 새 사실을 덧붙이고, 요약 문서를 다시 쓰고, 예전에 적어둔 내용과 어긋나는 부분이 있으면 표시해 둡니다.

그래서 질문이 들어오면, LLM은 여전히 관련 문서를 찾아 읽는 과정을 거치지만 — 흩어진 원자료 조각을 뒤지는 게 아니라 이미 정리되고 서로 연결된 위키 문서를 찾아 읽습니다. 이렇게 나온 좋은 답변이나 비교, 새로 발견한 연결점은 대화 속에 묻히지 않고 위키의 새 문서로 편입되어, 다음 질문에서도 다시 쓰일 자산이 됩니다.

이 구조에서 사람의 역할은 자료를 고르고, 탐구 방향을 정하고, 좋은 질문을 던지는 것입니다. 자료를 읽고 요약하고 교차 참조를 관리하는 잡일은 LLM이 전담합니다.

정리하면, LLM Wiki는 매번 새로운 채팅이나 세션에서 파일을 업로드해 그 안에서 답을 찾는 방식이 아닙니다. 미리미리 정보를 정리해두고 계속 최신으로 유지해서, 사용자의 질문에 답변을 해줍니다.

구조: LLM Wiki는 무엇으로 이루어지나?

보통 LLM에게 자료를 던져주면 질문할 때마다 처음부터 다시 찾아 조각을 맞춥니다. LLM Wiki는 다릅니다. 자료를 읽을 때 그 내용을 위키에 쌓아두고, 다음 질문부터는 정리된 위키를 바로 씁니다. 지식이 매번 새로 발견되는 게 아니라 쌓입니다.
이걸 가능하게 하기 위해 원자료(raw sources), 위키(정리된 문서 모음), 스키마(schema) 총 3개의 층 구조입니다.

1. 원자료(Raw sources) — 손대지 않는 원본

내가 모아둔 자료 그 자체입니다. 스크랩한 웹 기사, 논문 PDF, 회의록, 책 읽으며 남긴 메모, 이미지나 데이터 파일 같은 것들이 그대로 쌓여 있는 폴더입니다.
LLM은 여기서 자료들을 읽기만 할 뿐 한 글자도 수정하지 않습니다. 원본이 그대로 남아 있어야 나중에 "이 문장이 어디서 나온 얘기지?" 하고 되짚어볼 수 있고, 위키가 잘못 정리 됐을 때 처음부터 다시 만들 수도 있기 때문입니다.

2. 위키(Wiki) — LLM이 쓰고, 내가 읽는 곳

LLM이 원자료를 읽고 만들어낸 마크다운 문서들이 서로 링크로 이어져 쌓이는 계층입니다. 자료 하나하나의 요약 문서, 인물이나 조직 같은 개별 대상을 다루는 문서, 개념을 설명하는 문서, 여러 자료를 비교한 문서, 그리고 위키 전체의 지도 역할을 하는 개요 문서와 지금까지의 결론을 담은 종합 문서 같은 것들입니다.

이 층은 온전히 LLM이 관리합니다. 문서를 새로 만들고, 새 자료가 들어오면 고치고, 문서끼리의 참조를 관리하고, 앞뒤가 맞는지 챙기는 일을 전부 LLM이 합니다.

여기에는 개별 주제를 다루는 문서 말고도, 위키 전체를 훑는 역할을 하는 특별한 문서가 두 개 더 있습니다. 어떤 문서가 있는지 보여주는 목록인 index.md와, 언제 무슨 작업을 했는지 남기는 기록인 log.md입니다. 문서가 몇 개 없을 때는 없어도 그만이지만, 위키가 커질수록 LLM과 내가 이 안에서 길을 잃지 않게 해주는 파일들입니다.

3. 스키마(Schema) — LLM에게 주는 편집 지침

CLAUDE.md나 AGENTS.md 같은 파일 하나에, 이 위키가 어떻게 생겼고 LLM이 어떻게 일해야 하는지를 적어둔 문서입니다.

문서 종류는 무엇이 있는지, 제목은 어떤 규칙으로 짓는지, 새 자료가 들어오면 어떤 순서로 처리 하는지, 질문에 답할 때는 무엇부터 읽는지 같은 내용이 들어갑니다.

앞의 두 층과 달리 이 층은 사람과 LLM이 같이 만들어 갑니다. 처음부터 완벽하게 쓸 수 없고, 쓰다 보면 "이건 이렇게 하는 게 낫겠다" 싶은 게 생길 때마다 규칙으로 추가해 나가게 됩니다.

층을 나누는 이유?

세 층을 나누는 이유는 누가 무엇을 소유 하는지 명확히 하기 위해서입니다.

원자료는 내가 고르고, 위키는 LLM이 쓰고, 스키마는 둘이 함께 다듬습니다.

이 경계가 흐려지면 문제가 생깁니다. LLM이 원본을 고치기 시작하면 무엇이 사실이고 무엇이 LLM의 해석인지 구분할 수 없게 되고, 내가 위키를 직접 손보기 시작하면 결국 사람이 관리하는 위키가 되어, 질문할 때마다 원자료에서 관련 부분을 다시 찾고 그걸 다시 종합해서 정리해야 하는 처음의 문제로 되돌아갑니다.

운영: LLM Wiki는 어떻게 굴러가는가?

LLM Wiki는 원자료, 위키, 스키마라는 구조로 이루어져 있습니다. 이 구조는 세 가지 동작으로 운영됩니다.

자료를 넣고(Ingest), 질문을 던지고(Query), 가끔 전체를 점검하는(Lint) 것입니다. 이 세 가지 동작이 맞물려 돌아가면서, 원자료, 위키, 스키마라는 세 층이 하나의 백과사전이 되어 갑니다.

자료 넣기 (Ingest)

새로운 자료 하나를 원자료 폴더에 넣고 LLM에게 처리하라고 시키면, LLM은 그 자료를 읽고, 핵심 내용이 뭔지 나와 이야기를 나눈 뒤, 그 자료를 요약하는 문서를 씁니다. 그러고 나서 인덱스를 갱신하고, 이 자료와 관련된 기존 문서들을 찾아가서 고치고, 마지막으로 로그에 처리 기록을 남깁니다.

Karpathy는 자료를 하나씩 넣으면서 그때그때 요약을 확인하고 방향을 잡아주는 방식을 선호한다고 말합니다. 하지만 감독을 덜 하며 여러 자료를 한 번에 몰아서 넣는 것도 가능합니다. 어느 쪽이 나에게 맞는 방식인지는 결국 써보면서 정해서, 스키마에 규칙으로 적어두면 됩니다.

질문하기 (Query)

질문을 던지면 LLM은 목록 문서를 먼저 훑어 어떤 문서를 볼지 고르고, 그 문서들을 읽어 답을 만듭니다. 앞서 RAG 부분에서 말했던 "매번 원자료를 처음부터 뒤지는" 과정과 다른 점은, 이미 정리되고 서로 연결된 위키 문서에서 출발한다는 것입니다. 답변의 형태도 자유롭습니다. 마크다운 문서일 수도, 비교 표일 수도, 슬라이드나 차트일 수도 있습니다.

좋은 답변은 다시 위키의 새 문서로 편입될 수 있습니다. 질문에 답하다가 얻은 비교나 통찰, 새로 발견한 연결점은 그 대화 안에서 사라지지 않고, 위키에 남아 다음 질문에서 다시 쓰일 자산이 됩니다.

점검하기 (Lint)

주기적으로 LLM에게 위키 전체를 건강검진 해달라고 시키는 단계입니다. 이때 LLM이 찾는 것들은 대략 이렇습니다.

• 문서와 문서 사이의 모순
• 새 자료가 들어오면서 낡아버린 예전 주장
• 어디서도 링크를 받지 못하는 고아 문서
• 분명 중요한데 아직 독립된 문서가 없는 개념
• 빠져 있는 상호 참조
• 웹 검색으로 채울 수 있는 데이터의 공백

자료 넣기(Ingest) 단계가 아무리 꼼꼼해도 위키가 커지면 어딘가는 어긋나기 마련이고, 점검하기(Lint) 단계가 그 어긋난 부분을 주기적으로 찾아 표시해주지 않으면 위키는 조용히 부정확해질 수 있습니다. LLM은 이 점검 과정에서 다음에 찾아볼 만한 자료나 던져볼 만한 질문을 먼저 제안해주기도 합니다.

index.md와 log.md

앞의 세 동작을 보면 계속 같은 두 파일이 등장합니다. 자료를 넣을 때 갱신하는 인덱스와, 처리 기록을 남기는 로그입니다.

index.md는 내용 중심의 목록입니다. 위키의 모든 문서를 링크와 한 줄 요약으로 정리한 카탈로그로, 자료를 넣을 때마다 갱신되고 질문에 답할 때 가장 먼저 읽힙니다.

log.md는 시간 중심의 기록입니다. 자료를 넣고, 질문하고, 점검한 이력을 뒤에 계속 덧붙이기만 하는 파일입니다. 각 항목을 ## [2026-07-25] ingest | 자료 제목 처럼 일정한 형식으로 시작하면 grep이나 tail로 최근 기록만 뽑아볼 수 있습니다.

grep: 파일에서 특정 패턴이 들어간 줄만 뽑아내는 명령어
tail: 파일의 마지막 몇 줄만 보여주는 명령어

인덱스는 "지금 위키에 무엇이 있는가"에, 로그는 "지금까지 무슨 일이 있었는가"에 답하는 파일입니다.

정리

정리하면, Ingest가 지식을 쌓고, Query가 그 지식을 꺼내 쓰면서 다시 쌓고, Lint가 전체가 어긋나지 않게 지켜줍니다. 이 세 동작으로 LLM Wiki를 운영하고, 이를 통해 RAG의 한계인 답변이 지식으로 쌓이지 않는 문제를 풀어냅니다.

마무리: 나는 어떻게 사용할까?

여기까지 정리하고 나서 정작 "그래서 나는 뭘로 만들지?"라는 생각이 들었습니다.

Karpathy는 팀 위키, 몇 달짜리 연구 등의 예시를 들어줬는데 제 일상에 적용해보고자 찾아보니 아무것도 떠오르지 않았습니다.

많은 분들이 업무에 적용하시는 걸 보다 보니, 알바를 하고 있는 제게도 적용하면 좋을 예시가 하나 떠올랐습니다.

저는 B마트에서 크루로 일하고 있습니다. 입고, 출고, 재고 실사 같은 업무를 처음 배우던 시기에 업무 매뉴얼 같은 건 없었습니다. 선임 크루들이 옆에서 입으로 알려주시는 게 전부였고, 그게 저는 조금 불편했습니다. 다음 근무 때 쉽게 기억이 나지 않아서 다시 물어볼 때가 많더라고요.

그래서 배운 걸 잊지 않으려고 퇴근 후에 노션에 업무일지를 작성했습니다. 업무일지 덕분에 업무를 금방 익힐 수 있었습니다. 문제는 기록해두기만 했다는 것입니다. 일지가 쌓일수록 원하는 내용을 찾는 일은 오히려 더 어려워졌습니다. 잊지 않으려고 쓴 기록인데, 필요한 순간에 꺼내 보기 어려웠습니다.

LLM Wiki를 여기에 적용한다면 이런 흐름이 될 것 같습니다.

• Ingest: 교육받은 내용을 마크다운으로 남깁니다.
• Query: 업무 중에 헷갈리면 문서를 뒤지는 대신 그냥 물어봅니다. "Q. 출고 준비는 어떻게 해?"
• Lint: 새 업무를 배워 문서를 갱신했을 때, 기존 내용과 충돌하는 부분을 잡아냅니다. "Q. 재고 실사 문서에는 A로 되어 있는데 방금 추가한 내용은 B입니다. 어느 쪽이 현재 기준인가요?"

알바 업무를 예시로 들었지만, 개발자로 일하게 될 때에도 업무를 이런 식으로 정리하면 편할 것 같습니다. 왜 사람들이 업무에 LLM Wiki를 도입하는지 이제 알 것 같습니다.

출처

karpathy/llm-wiki.md | Gist