LLM Wiki란 무엇인가: 개인 지식저장소를 LLM으로 키우는 방법과 장단점

핵심 요약

LLM Wiki는 LLM을 단순한 답변 도구가 아니라, 지식을 계속 쌓고 고치는 편집자로 쓰는 방식입니다.

핵심은 원문 소스, 위키, 스키마를 분리하고, `index.md`와 `log.md`로 누적 관리하는 구조를 만드는 것입니다.

RAG처럼 매번 다시 검색하는 것이 아니라, 시간이 지날수록 더 정돈되고 연결된 개인 지식저장소를 만든다는 점에서 가치가 큽니다.

목차

참고한 자료: LLM-Wiki 관련 참고 링크

LLM Wiki와 개인 지식저장소를 보여주는 블로그 헤더 이미지

LLM Wiki란 무엇인가

LLM Wiki는 말 그대로 LLM이 문서를 “답변”하는 데 그치지 않고, 위키 자체를 만들고 유지하는 방식입니다. 사용자는 원문을 모으고 질문을 던지고, LLM은 그 원문을 읽어 위키 페이지를 작성하고 갱신합니다. 그래서 이 구조는 검색형 도구보다 편집형 도구에 더 가깝습니다.

Andrej Karpathy의 아이디어를 한 문장으로 줄이면 이렇습니다. 지식은 매번 다시 찾는 것이 아니라, 시간이 지날수록 더 잘 정리되도록 축적해야 한다는 것입니다. 그 축적의 결과물이 바로 LLM Wiki입니다.

이 방식이 흥미로운 이유는 위키를 “문서 모음”이 아니라 “살아 있는 코드베이스”처럼 다룬다는 점입니다. Obsidian을 IDE처럼 열어두고, LLM을 프로그래머처럼 쓰며, 위키를 지식의 저장소이자 작업 공간으로 운영합니다. Karpathy가 비유한 바처럼, Obsidian은 IDE, LLM은 프로그래머, 위키는 코드베이스에 가깝습니다.

왜 지금 LLM Wiki가 주목받는가

사람들이 이 방식을 주목하는 이유는 간단합니다. 지식이 쌓이는 문제를 해결해 주기 때문입니다. 단순한 Q&A는 한 번으로 끝나지만, 진짜 개인 지식저장소는 어제 본 글, 오늘 읽은 기사, 다음 주에 다시 참고할 노트가 서로 연결되어야 합니다. 여기서 가장 큰 비용은 검색이 아니라 유지보수입니다.

Karpathy의 글에서 강조되는 핵심도 비슷합니다. 위키를 만드는 것보다 더 어려운 것은 북키핑(bookkeeping)입니다. 링크를 갱신하고, 기존 주장과 새 주장 사이의 모순을 표시하고, 요약을 최신 상태로 유지하는 일은 사람이 하면 금방 지칩니다. LLM Wiki는 그 지루한 작업을 LLM에게 넘겨서, 지식이 커질수록 더 관리하기 쉬운 구조를 만들자는 제안입니다.

그래서 이 방식은 연구자, 독서 노트가 많은 사람, 개인 프로젝트를 오래 끌고 가는 사람, 팀 문서를 계속 갱신해야 하는 사람에게 특히 잘 맞습니다. 지식이 시간에 따라 쌓일수록 효과가 커지는 방식이기 때문입니다.

RAG와 무엇이 다른가

많은 분이 처음에 떠올리는 질문은 이겁니다. “그럼 그냥 RAG 아닌가요?” 겉으로 보면 비슷해 보이지만, 사고방식은 꽤 다릅니다. RAG는 질문이 들어올 때마다 원문에서 관련 조각을 다시 찾아 답합니다. 반면 LLM Wiki는 원문을 읽은 뒤 그 내용을 위키 페이지로 흡수해 두고, 다음 질문부터는 정리된 위키를 중심으로 다룹니다.

즉, RAG는 검색 중심이고 LLM Wiki는 축적 중심입니다. RAG는 “지금 필요한 조각을 꺼내는 방식”에 강하고, LLM Wiki는 “쌓인 지식을 정리된 형태로 유지하는 방식”에 강합니다. 그래서 두 방식은 경쟁 관계라기보다 목적이 다릅니다.

이 차이가 분명하게 드러납니다. LLM-Wiki는 원문을 계속 다시 읽는 것이 아니라, 영속적 위키(persistent wiki)를 점진적으로 구축합니다. 새 소스가 들어오면 기존 위키를 고치고, 교차 참조를 보강하고, 토픽 페이지를 갱신합니다. 한마디로 “검색 결과를 답으로 쓰는 시스템”이 아니라 “지식을 계속 편집하는 시스템”입니다.

LLM Wiki의 원문 소스, 위키, 스키마 3계층을 설명하는 삽화

어떻게 쓰는가

실제 사용법은 생각보다 단순합니다. 가장 중요한 것은 “LLM이 무엇을 읽고 무엇을 고쳐야 하는지”를 분명히 해 주는 것입니다. 이를 위해 보통 세 가지 층을 둡니다.

1) 원문 소스(Raw sources)

원문 소스는 기사, 논문, 메모, 이미지, 데이터 파일처럼 실제 근거가 되는 자료입니다. 이 레이어는 가급적 불변(immutable)으로 두는 편이 좋습니다. LLM이 요약을 만들고 위키를 고쳐도, 원문은 그대로 남겨 두어야 나중에 무엇이 근거였는지 다시 확인할 수 있습니다. 이 층이 사실상의 source of truth입니다.

2) 위키(The wiki)

위키는 LLM이 직접 관리하는 마크다운 파일 모음입니다. 요약 페이지, 개념 페이지, 인물 페이지, 비교 페이지처럼 서로 연결된 문서들이 여기에 들어갑니다. 새 소스가 들어오면 LLM이 위키를 업데이트하고, 관련 항목에 백링크를 걸고, 오래된 주장을 정리합니다. 위키는 단순 보관함이 아니라 계속 다듬는 작업물입니다.

3) 스키마(The schema)

스키마는 LLM에게 위키의 규칙을 알려 주는 문서입니다. 예를 들면 AGENTS.mdCLAUDE.md 같은 파일이 여기에 해당합니다. 어떤 페이지를 어떻게 작성할지, 제목은 어떤 형식으로 둘지, 링크는 어떻게 연결할지 같은 규칙을 적어 두면 LLM이 일관성을 유지하기 쉬워집니다.

이 구조를 잘 쓰면 사용자는 “위키를 관리하는 사람”이 아니라 “좋은 질문을 던지는 사람”이 됩니다. 대신 LLM이 소스를 읽고, 페이지를 고치고, 링크를 정리하고, 요약을 최신화합니다. 사용자는 그 결과를 검토하고, 필요한 새 자료만 추가하면 됩니다.

어떤 구조로 만들면 좋은가

인상적인 부분은 디렉터리 구조보다 운영 흐름입니다. 대표적으로 index.mdlog.md가 중요합니다. index.md는 위키의 목차처럼 동작하고, log.md는 무엇을 읽었고 무엇을 바꿨는지 기록하는 시간순 기록입니다.

여기에 더해 실제 운영에서는 다음과 같은 흐름이 유용합니다.

  • 새 자료를 넣습니다.
  • LLM이 원문을 읽고 핵심을 추립니다.
  • 요약 페이지와 관련 페이지를 갱신합니다.
  • 인덱스를 갱신해 다음 탐색이 쉬워지게 합니다.
  • 로그에 변경 이력을 남깁니다.

이 구조의 장점은 쿼리할 때마다 원문을 전부 뒤지지 않아도 된다는 점입니다. 대신 위키가 이미 정리된 상태로 존재하므로, LLM은 더 빠르게 맥락을 잡고 더 잘 연결된 답을 만들 수 있습니다. 필요하면 Obsidian Web Clipper로 소스를 빠르게 넣고, 그래프 뷰로 고아 페이지나 허브 페이지를 점검할 수 있습니다.

장점과 한계

장점부터 보면, LLM Wiki는 지식이 누적될수록 더 강해집니다. 처음에는 단순한 노트처럼 보여도, 페이지가 연결되고 요약이 쌓이고 오래된 주장이 정리되면 점점 더 강한 개인 지식저장소가 됩니다. 또한 어떤 지식이 어디에 있는지 눈에 보이기 때문에, AI가 무엇을 알고 무엇을 모르는지 관리하기가 쉽습니다.

토론에서도 자주 언급되듯이, 이런 방식은 데이터 소유권과 파일 우선 접근이 분명합니다. 지식이 특정 앱 안에 갇히지 않고, 마크다운과 이미지 파일로 남기 때문에 다른 도구로 옮기기 쉽습니다. 또 Claude, Codex 같은 도구를 바꿔 써도 동일한 파일 구조를 유지할 수 있어 AI 선택의 자유도 큽니다.

다만 한계도 분명합니다. 구조를 처음 잡는 일이 번거롭고, 소스와 위키가 많아질수록 관리 규칙이 흐트러질 수 있습니다. 또 모든 문제에 LLM Wiki가 맞는 것은 아닙니다. 정보가 자주 바뀌는 짧은 Q&A나 일회성 작업에는 오히려 과한 구조일 수 있습니다. 즉, 이 방식은 “지식이 축적되는 일”에 가장 잘 맞습니다.

또 하나 조심할 점은, 위키가 커질수록 LLM도 더 좋은 규칙을 필요로 한다는 점입니다. 그래서 단순히 파일을 많이 쌓는 것이 아니라, 교차 참조, 최신화, 모순 표시, 오래된 페이지 정리를 꾸준히 해야 합니다. 결국 위키의 품질은 최초 구축보다 유지 습관에서 갈립니다.

처음 시작하는 방법

처음부터 거대한 시스템을 만들 필요는 없습니다. 가장 작은 형태로 시작하면 됩니다. 예를 들어 오늘 읽은 글 3개와 내 메모 5개만으로도 충분합니다. 그 자료를 원문 폴더에 넣고, index.mdlog.md를 만들고, LLM에게 “이 위키를 유지하는 편집자” 역할을 주면 됩니다.

실전에서는 다음 순서가 무난합니다.

  • 주제 하나를 정합니다. 예: 연구, 독서, 제품 조사, 팀 회의.
  • 원문 자료를 모읍니다.
  • 스키마 문서를 만들어 LLM 규칙을 적습니다.
  • 위키 페이지를 5~10개 정도만 먼저 만듭니다.
  • 한 번의 ingest, 한 번의 query, 한 번의 lint를 돌려 봅니다.

여기서 중요한 건 완벽한 시스템이 아니라 “다음번에 더 좋아지는 시스템”입니다. LLM Wiki의 핵심은 한 번 잘 만드는 것이 아니라, 쓸수록 더 정리되고 더 연결되고 더 믿을 수 있게 변하는 데 있습니다.

자주 묻는 질문

Q. LLM Wiki는 RAG를 완전히 대체하나요?

A. 아닙니다. RAG는 질문 시 검색에 강하고, LLM Wiki는 축적과 유지보수에 강합니다. 목적이 다르므로 함께 쓸 수도 있습니다.

Q. 꼭 Obsidian을 써야 하나요?

A. 꼭 그렇지는 않습니다. 다만 Obsidian은 마크다운, 백링크, 그래프 뷰, Web Clipper 같은 기능이 좋아서 LLM Wiki와 궁합이 좋습니다.

Q. 어떤 사람에게 특히 잘 맞나요?

A. 연구자, 독서 노트를 많이 남기는 사람, 프로젝트를 오래 운영하는 사람, 팀 지식을 체계적으로 정리하려는 사람에게 특히 잘 맞습니다.

Q. 가장 중요한 운영 원칙은 무엇인가요?

A. 원문은 원문대로 남기고, 위키는 LLM이 편집하며, 스키마는 규칙으로 고정하는 것입니다. 이 경계가 흐려지면 위키의 신뢰성이 금방 떨어집니다.

Q. 처음부터 너무 크게 시작하면 안 되나요?

A. 권하지 않습니다. 작은 주제 하나로 시작해서 ingest, query, lint를 돌려보는 편이 훨씬 좋습니다. 작게 시작해야 규칙도 유지되고, 개선 포인트도 보입니다.

이 글이 마음에 드세요?

RSS 피드를 구독하세요!

댓글 남기기