안녕하세요! 요즘 ChatGPT에 PDF 올려서 질문하거나, NotebookLM으로 자료 정리해보신 분들 많으실 것 같습니다.

저도 처음에는 문서 넣고 질문하면 답해주는 기능만으로도 꽤 신기하다고 생각했는데요. 쓰다 보면 묘하게 아쉬운 순간이 있습니다.

"어제 이 문서들로 정리했던 내용, 오늘 다시 이어서 발전시킬 수 없나?"

"매번 비슷한 질문을 할 때마다 AI가 처음부터 다시 읽고 다시 요약하는 느낌인데?"

"좋은 답변이 나왔는데 이걸 그냥 대화창에 흘려보내는 게 맞나?"

이런 불편함을 해결하기 위해 안드레 카파시(Andrej Karpathy)가 제안한 개념이 바로 LLM Wiki입니다.

이름만 보면 뭔가 거창한 프레임워크나 새로운 서비스 같지만, 실제로는 특정 제품이 아닙니다. 카파시가 GitHub Gist에 올린 하나의 아이디어 파일에 가깝습니다. 그리고 그 내용은 꽤 단순하면서도 강력합니다.

LLM에게 문서를 매번 검색하게 하지 말고, 아예 살아있는 위키를 만들고 유지보수하게 하자.

도대체 이게 기존 RAG나 NotebookLM과 뭐가 다르길래 많은 개발자들이 관심을 가지는 걸까요?

기존 방식의 아쉬움

우리가 지금까지 LLM으로 문서를 다루는 방식은 대부분 비슷합니다.

PDF를 올립니다. 
V
문서를 넣습니다.
V
질문합니다.
V
그러면 LLM이 관련 있어 보이는 부분을 찾아 답변합니다.

이런 방식은 흔히 RAG(Retrieval-Augmented Generation)라고 불립니다. 쉽게 말하면, LLM이 모르는 내용을 외부 문서에서 검색해서 답변하게 만드는 방식입니다.

물론 RAG는 굉장히 유용합니다. 하지만 카파시가 지적한 문제는 여기에 있습니다.

1. 매번 처음부터 다시 찾는다

RAG는 질문이 들어올 때마다 관련 문서 조각을 다시 검색합니다. 오늘 물어본 질문도, 내일 비슷하게 물어본 질문도, 그때그때 다시 찾아서 답을 만듭니다.

그러다 보니 이전에 만들어낸 좋은 요약이나 분석이 자연스럽게 쌓이지 않습니다. 대화창 안에서는 똑똑해 보이지만, 대화가 끝나면 지식도 같이 증발해버리는 느낌이죠.

2. 좋은 답변이 지식베이스로 남지 않는다

가끔 LLM과 대화하다 보면 꽤 괜찮은 정리가 나올 때가 있습니다.

문서 5개를 비교해서 나온 결론이라든지, 어떤 개념을 쉽게 설명한 문단이라든지, 여러 자료 사이의 모순을 짚어낸 답변 같은 것들 말이죠!

그런데 이런 답변은 보통 채팅 기록에만 남습니다. 나중에 다시 쓰려면 복사해서 따로 저장하거나, 다시 질문해야 합니다.

지식이 쌓이는 게 아니라, 좋은 답변이 계속 흘러가버리는 구조입니다.

3. 사람이 관리하는 위키는 금방 낡는다

그럼 직접 Obsidian이나 Notion에 정리하면 되지 않을까요?

가능은 합니다. 하지만 문제는 유지보수입니다.

처음에는 열심히 정리합니다. 링크도 달고, 태그도 붙이고, 문서도 예쁘게 나눕니다. 그런데 자료가 30개, 50개, 100개가 넘어가면 슬슬 귀찮아집니다.

새 자료가 들어왔을 때 기존 페이지를 수정해야 하고, 관련 개념끼리 링크를 걸어야 하고, 오래된 설명을 최신 내용으로 바꿔야 합니다.

솔직히 말해서 이 작업, 사람이 꾸준히 하기 어렵습니다.

LLM Wiki의 핵심 아이디어

LLM Wiki의 핵심은 간단합니다.

원본 자료와 사용자 사이에 LLM이 관리하는 Markdown 위키를 하나 더 두는 것입니다.

기존 방식이 이런 느낌이었다면,

사용자 질문 → 원본 문서 검색 → LLM 답변

LLM Wiki는 이런 구조에 가깝습니다.

원본 자료 → LLM이 정리한 Wiki → 사용자 질문

중요한 차이는 질문할 때마다 원본을 처음부터 뒤지는 것이 아니라, LLM이 미리 읽고 정리해둔 위키가 계속 남는다는 점입니다.

즉, LLM Wiki는 검색 시스템이라기보다는 지식 컴파일 시스템에 가깝습니다.

개발에 비유하면 원본 자료는 소스코드이고, 위키는 컴파일된 결과물입니다. 사용자는 매번 원본 전체를 해석하지 않고, 이미 정리된 구조를 바탕으로 더 빠르게 탐색하고 질문할 수 있습니다.

3계층 구조

카파시의 LLM Wiki는 크게 세 가지 계층으로 나눌 수 있습니다.

1. Raw Sources

첫 번째는 원본 자료입니다.

논문, 블로그 글, PDF, 회의록, 영상 자막, 이미지, 기존 노트 등이 여기에 들어갑니다.

여기서 중요한 점은 원본 자료는 바꾸지 않는다는 것입니다. LLM이 이 자료를 읽을 수는 있지만, 마음대로 수정해서는 안 됩니다.

쉽게 말하면 raw/ 폴더는 진실의 원천입니다.

wiki-project/
  raw/
    papers/
    articles/
    transcripts/
    assets/

2. Wiki

두 번째는 LLM이 만들어내는 Markdown 위키입니다.

여기에는 개념 페이지, 인물 페이지, 제품 페이지, 비교 문서, 요약 문서 등이 들어갑니다.

예를 들어 LLM 관련 논문들을 넣었다면 이런 페이지들이 생길 수 있습니다.

wiki/
  concepts/
    transformer.md
    attention.md
    rlhf.md
  entities/
    openai.md
    anthropic.md
  comparisons/
    rag-vs-llm-wiki.md
  index.md
  log.md

사람이 모든 문서를 직접 쓰는 것이 아니라, LLM이 원본 자료를 읽고 페이지를 만들고, 기존 페이지를 수정하고, 관련 페이지끼리 링크를 겁니다.

여기서 Obsidian을 쓰면 꽤 잘 어울립니다. Obsidian은 Markdown 파일을 보기 좋게 탐색하는 인터페이스가 되고, LLM은 그 뒤에서 위키를 유지보수하는 편집자가 됩니다.

3. Schema

세 번째는 스키마입니다.

여기서 말하는 스키마는 데이터베이스 스키마라기보다는, LLM에게 주는 작업 규칙에 가깝습니다.

Claude Code라면 CLAUDE.md, Codex라면 AGENTS.md 같은 파일이 이 역할을 할 수 있습니다.

이 파일에는 이런 규칙이 들어갑니다.

- 새 자료를 ingest할 때는 먼저 요약 페이지를 만든다.
- 관련 개념 페이지가 있으면 반드시 업데이트한다.
- 중요한 주장에는 출처를 남긴다.
- 모순되는 내용이 있으면 contradiction 섹션에 기록한다.
- 작업이 끝나면 log.md에 기록한다.

이 규칙이 중요한 이유는 LLM이 그냥 즉흥적으로 정리하지 않게 만들기 위해서입니다.

LLM에게 "자료 정리해줘"라고만 하면 매번 다른 방식으로 정리할 수 있습니다. 하지만 규칙 파일이 있으면 LLM은 같은 방식으로 읽고, 쓰고, 갱신할 수 있습니다.

LLM Wiki는 어떻게 굴러가나

LLM Wiki의 운영 방식은 크게 세 가지입니다.

1. Ingest

새 자료를 넣는 단계입니다.

예를 들어 새로운 논문 하나를 raw/papers/에 넣고 LLM에게 처리하라고 하면, LLM은 그 자료를 읽고 핵심 내용을 정리합니다.

그런 다음 단순히 요약 파일 하나만 만들고 끝나는 것이 아니라, 기존 위키 전체를 보면서 관련된 페이지를 업데이트합니다.

새로운 개념이 나오면 새 페이지를 만들고, 이미 있던 개념이면 기존 페이지에 내용을 추가합니다. 기존 주장과 충돌하는 내용이 있으면 모순도 표시합니다.

2. Query

질문하는 단계입니다.

기존 RAG는 질문이 들어오면 원본 문서 조각을 찾아 답합니다. 반면 LLM Wiki에서는 LLM이 먼저 index.md나 관련 위키 페이지를 읽고 답변합니다.

좋은 답변이 나오면 그것도 다시 위키에 저장할 수 있습니다.

예를 들어 "RAG와 LLM Wiki의 차이를 표로 정리해줘"라고 했을 때 나온 좋은 답변을 comparisons/rag-vs-llm-wiki.md로 저장하는 식입니다.

이렇게 되면 질문 자체도 지식베이스를 성장시키는 행동이 됩니다.

3. Lint

마지막은 점검 단계입니다.

개발에서 lint가 코드 스타일이나 오류를 잡아주는 것처럼, LLM Wiki에서도 주기적으로 위키를 점검할 수 있습니다.

예를 들면 이런 것들을 확인합니다.

• 서로 모순되는 페이지가 있는가?
• 오래된 주장이 최신 자료로 대체되어야 하는가?
• 링크가 하나도 걸리지 않은 고아 페이지가 있는가?
• 중요한 개념인데 별도 페이지가 없는가?
• 출처가 부족한 주장이 있는가?

이 과정이 없으면 LLM Wiki는 금방 그럴듯한 Markdown 더미가 될 수 있습니다. 그래서 ingest만큼이나 lint가 중요합니다.

RAG와 뭐가 다른가?

"그거 그냥 RAG랑 비슷한 거 아닌가요?"

반은 맞고, 반은 다릅니다.

LLM Wiki도 결국 필요한 정보를 찾습니다. 위키가 커지면 검색 도구나 벡터 검색을 붙일 수도 있습니다. 그러니 "RAG는 죽었고 LLM Wiki가 완전히 대체한다"라고 말하는 건 조금 과장입니다.

하지만 핵심 차이는 쓰기 경로(write path)에 있습니다.

RAG는 보통 질문이 들어왔을 때 검색하고 답합니다. 답변이 끝나면 그 결과는 시스템 내부의 지식으로 자연스럽게 남지 않습니다.

반면 LLM Wiki는 새 자료를 읽을 때마다 위키를 수정합니다. 질문에 대한 좋은 답변도 다시 파일로 저장할 수 있습니다. 즉, 지식이 계속 누적됩니다.

쉽게 말하면 이렇습니다.

RAG: 질문할 때마다 찾아서 답한다
LLM Wiki: 미리 읽고 정리해서 지식베이스를 키운다

검색을 잘하는 AI에서, 정리를 잘하는 AI로 역할이 바뀌는 것입니다.

Obsidian과는 뭐가 다른가?

Obsidian을 써보신 분들은 이런 생각이 들 수 있습니다.

"Markdown 파일 만들고 링크 거는 거면 그냥 Obsidian 아닌가?"

맞습니다. 겉으로 보면 Obsidian과 굉장히 비슷합니다. 실제로 카파시도 Obsidian을 함께 쓰는 방식을 이야기합니다.

하지만 역할이 다릅니다.

기존 Obsidian에서는 사람이 직접 노트를 쓰고, 링크를 걸고, 구조를 정리합니다. 그래서 부지런한 사람에게는 강력하지만, 귀찮아지는 순간 지식베이스가 멈춥니다.

LLM Wiki에서는 사람이 모든 노트를 직접 쓰지 않습니다.

사람은 자료를 고르고, 방향을 정하고, 중요한 판단을 합니다. LLM은 요약하고, 연결하고, 수정하고, 기록합니다.

즉, Obsidian은 IDE이고, LLM은 프로그래머이며, 위키는 코드베이스라는 비유가 꽤 잘 맞습니다.

어디에 쓸 수 있을까?

LLM Wiki가 가장 잘 맞는 상황은 지식이 오래 쌓여야 하는 경우입니다.

1. 장기 리서치

논문을 여러 개 읽거나, 특정 기술을 몇 주 이상 깊게 파야 할 때 좋습니다.

하나의 논문 요약에서 끝나는 것이 아니라, 논문들이 서로 어떻게 연결되는지, 어떤 개념이 반복해서 등장하는지, 어떤 주장이 서로 충돌하는지를 계속 축적할 수 있습니다.

2. 개인 지식관리

블로그 글, 책, 강의, 메모, 프로젝트 회고 등을 하나의 위키로 만들 수 있습니다.

단순히 "내 노트 검색"이 아니라, LLM이 내 자료를 바탕으로 개념 페이지를 만들고 서로 연결해주는 구조입니다.

3. 팀 내부 지식베이스

회의록, Slack 스레드, 프로젝트 문서, 장애 보고서 등을 모아 팀 위키로 만들 수도 있습니다.

다만 이 경우에는 권한 관리, 보안, 리뷰 절차가 훨씬 중요해집니다. 개인 위키처럼 막 돌리기에는 위험합니다.

4. 반복 질문이 많은 도메인

계속 비슷한 질문을 하게 되는 분야라면 LLM Wiki가 특히 유용합니다.

매번 처음부터 답을 만드는 것이 아니라, 이전에 정리한 지식을 바탕으로 더 나은 답을 만들 수 있기 때문입니다.

조심해야 할 점

좋아 보이는 아이디어일수록 조심해야 합니다.

LLM Wiki의 장점은 지식이 계속 쌓인다는 것입니다. 그런데 바로 그 점 때문에 위험도 커집니다.

1. 틀린 정보도 쌓인다

일반적인 채팅에서 LLM이 틀린 답을 하면 그 순간만 조심하면 됩니다.

하지만 LLM Wiki에서는 틀린 답이 Markdown 파일로 저장될 수 있습니다. 그리고 나중에 다른 페이지에 링크되고, 또 다른 답변의 근거로 쓰일 수 있습니다.

한 번의 환각이 오래 살아남는 구조가 될 수 있는 것이죠.

2. 출처가 흐려질 수 있다

위키 페이지가 너무 깔끔하게 정리되어 있으면 진짜처럼 보입니다.

하지만 그 문장이 어느 원본 자료에서 나온 것인지 추적할 수 없다면 위험합니다.

그래서 중요한 주장에는 반드시 출처를 남겨야 합니다. 최소한 페이지 단위로라도 어떤 raw source에서 왔는지 기록해야 합니다.

3. 오래된 지식이 남을 수 있다

기술 문서는 금방 낡습니다.

작년에 맞았던 내용이 올해는 틀릴 수 있고, 어떤 라이브러리의 권장 방식이 바뀔 수도 있습니다.

LLM Wiki가 계속 유용하려면 오래된 주장을 찾아내고 갱신하는 lint 작업이 필요합니다.

4. 민감한 정보가 한곳에 모인다

개인 일기, 회사 문서, 회의록, 고객 정보 같은 것들이 한 위키에 모이면 굉장히 강력한 지식베이스가 됩니다.

동시에 굉장히 민감한 정보 덩어리도 됩니다.

특히 외부 LLM API를 사용한다면 어떤 자료를 넘길 것인지, 어떤 결과를 저장할 것인지 신중하게 정해야 합니다.

실제로 만든다면

처음부터 거창하게 만들 필요는 없습니다.

개인용으로 시작한다면 이런 정도면 충분합니다.

my-llm-wiki/
  AGENTS.md
  raw/
    articles/
    papers/
    transcripts/
    assets/
  wiki/
    index.md
    log.md
    concepts/
    entities/
    comparisons/

• raw/: 원본 자료가 들어가는 폴더
• wiki/: LLM이 만든 Markdown 페이지가 들어가는 폴더
• index.md: LLM이 검색 전 확인할 전체 목차
• log.md: 언제 어떤 자료를 넣었고, 어떤 페이지가 수정되었는지 기록하는 작업 일지
• AGENTS.md: LLM이 지켜야 할 규칙

그리고 이 폴더 전체를 Git으로 관리하면 좋습니다. LLM이 어떤 파일을 어떻게 바꿨는지 diff로 볼 수 있기 때문입니다.

여기서 중요한 건 화려한 도구가 아닙니다.

오히려 핵심은 지루할 정도로 단순한 규칙입니다.

• 원본은 수정하지 않는다.
• 위키는 Markdown으로 관리한다.
• 중요한 주장에는 출처를 남긴다.
• 변경 사항은 log에 적는다.
• 주기적으로 lint를 돌린다.
• LLM의 정리를 그대로 믿지 말고 검토한다.

결국 LLM Wiki의 구현 비밀은 대단한 벡터 데이터베이스가 아니라, LLM이 딴짓하지 못하도록 작업 공간을 잘 정리해주는 데 있습니다.

마무리

LLM Wiki는 RAG를 완전히 대체하는 새로운 정답이라기보다는, LLM을 사용하는 방식에 대한 관점 전환에 가깝습니다.

지금까지 우리는 LLM을 주로 검색기나 답변기로 사용했습니다.

문서를 넣고, 질문하고, 답을 받았습니다.

하지만 카파시의 LLM Wiki는 LLM을 지식 편집자로 사용하자고 말합니다.

사람은 자료를 고르고, 방향을 정하고, 판단합니다. LLM은 반복적인 정리와 연결, 갱신과 점검을 맡습니다.

그 결과 좋은 답변이 대화창에서 사라지지 않고, 파일로 남아 다음 질문의 기반이 됩니다.

이게 LLM Wiki의 가장 중요한 차이입니다.

단순히 더 잘 검색하는 것이 아니라, 지식이 쌓이도록 만드는 것.

개인적으로는 이 개념이 앞으로 개인 지식관리나 팀 문서화 방식에 꽤 큰 영향을 줄 수 있다고 생각합니다. 물론 출처 관리와 검증 없이 막 쓰면 그럴듯한 거짓말을 예쁘게 정리한 폴더가 될 수도 있습니다.

결국 중요한 건 AI에게 모든 판단을 넘기는 것이 아니라, AI가 잘할 수 있는 반복적인 편집 노동을 맡기고 사람은 더 중요한 판단에 집중하는 것입니다.

앞으로 개발자의 실력은 코드를 잘 짜는 것뿐만 아니라, AI가 유지보수할 수 있는 지식 환경을 잘 설계하는 능력까지 포함하게 될지도 모르겠습니다.

참고 자료

• Andrej Karpathy, LLM Wiki
• Andrej Karpathy X
• Hermes Agent LLM Wiki skill
• Data Science Dojo, LLM Wiki Pattern Tutorial
• Microsoft Learn, Retrieval-Augmented Generation overview