1. 한줄 결론
이 튜토리얼의 핵심은 문서를 매번 새로 검색하는 RAG식 사용법에서 벗어나, 원본 자료를 읽은 AI가 지속적으로 갱신되는 Markdown 위키를 만들게 하자는 것이다. Obsidian은 위키를 보는 IDE 역할을 하고, Claude Code나 Codex 같은 코딩 에이전트는 위키를 작성하고 정리하는 작업자 역할을 맡는다.
2. 문제 정의
영상은 현재 많은 사용자가 ChatGPT나 NotebookLM에 문서를 올려 질문하는 방식의 한계를 짚으면서 시작한다. 이런 방식은 질문이 들어올 때마다 관련 청크를 찾아 답변을 만들 수는 있지만, 그 과정에서 생긴 정리와 연결이 다음 질문을 위해 축적되지 않는다.
오늘 여러 문서에서 답을 찾았더라도 내일 비슷한 질문을 하면 AI는 다시 원본 문서 검색부터 시작한다. 단순 검색형 질문에는 충분할 수 있지만, 여러 문서의 개념을 반복적으로 연결해야 하는 연구, 학습, 기획, 업무 지식 관리에서는 비효율이 누적된다.
영상은 이 한계를 RAG의 병목으로 설명한다. RAG는 원본 파일에서 관련 조각을 가져와 답을 생성하지만, 연결 구조 자체를 장기적으로 유지하지는 않는다. 따라서 지식이 쌓이는 것이 아니라 질의마다 재계산되는 형태가 된다.
3. 튜토리얼 아키텍처
3.1 raw 계층
raw/ 폴더는 PDF, 웹 기사, 회의 노트, 텍스트 파일, Markdown 파일 같은 입력 소스를 보관하는 원본 자료 저장소다. 이 계층은 읽기 전용 source of truth로 취급된다. AI는 이 파일을 읽을 수 있지만 수정해서는 안 된다.
이 원칙은 위키가 잘못 정리되었거나 AI가 연결을 잘못 만들었을 때 검증 가능한 원본이 남아 있어야 한다는 점에서 중요하다.
3.2 wiki 계층
wiki/ 폴더는 AI가 생성하고 유지하는 Markdown 지식 베이스다. 인덱스 페이지, 개념 페이지, 엔티티 페이지, 요약 페이지, 비교 페이지, 주제별 연결 페이지가 만들어진다.
핵심은 원본을 그대로 저장하는 것이 아니라, 읽은 자료를 구조화된 페이지와 링크로 재조립한다는 점이다. 새 자료가 들어오면 AI는 기존 페이지를 업데이트하고, 새 개념이 있으면 페이지를 만들고, 관련 개념끼리 링크한다. 이미 존재하는 내용과 충돌하는 정보가 있으면 그 모순도 표시하도록 설계된다.
3.3 schema 또는 rules 계층
세 번째 계층은 AI에게 작업 규칙을 알려주는 스키마 파일이다. Claude Code에서는 claude.md가 그 역할을 하고, Codex에서는 AGENTS.md를 같은 역할로 사용할 수 있다고 설명된다.
이 파일에는 위키의 목적, 폴더 구조, 새 소스 수집 절차, 페이지 포맷 규칙, 질의응답 방식이 들어간다. AI가 알아서 잘 정리하기를 기대하는 것이 아니라, 어떤 구조로 읽고 정리하고 답해야 하는지를 명시한다.
3.4 개념적 비유
영상은 Karpathy의 비유를 사용한다. Obsidian은 IDE, LLM은 프로그래머, wiki는 코드베이스에 해당한다. 사용자는 위키를 직접 대부분 작성하지 않고 어떤 자료를 넣을지와 어떤 질문을 할지를 정한다. AI는 자료를 읽고, 파일을 만들고, 연결을 정리한다.
이 비유의 장점은 LLM Wiki를 단순 노트 앱이 아니라 유지보수되는 지식 코드베이스로 보게 만든다는 점이다. 코드베이스처럼 구조, 규칙, 리뷰, lint, 수정 이력이 중요해진다.
4. 실제 설정 절차
4.1 Obsidian 설치
먼저 Obsidian을 설치한다. Obsidian은 Markdown 파일을 로컬 폴더에서 관리하는 노트 앱이며, 이 튜토리얼에서는 위키를 시각적으로 탐색하는 도구로 쓰인다. Graph view가 Markdown 링크 구조를 노드와 연결로 보여주기 때문에 LLM Wiki의 성장 과정을 확인하기 좋다.
다만 Obsidian이 필수 엔진은 아니다. 실제 데이터는 폴더 안의 Markdown 파일이므로 VS Code나 일반 텍스트 편집기로도 볼 수 있다.
4.2 새 vault 생성
Obsidian에서 새 vault를 만들고 이름을 LLM wiki로 지정한다. vault는 사실상 로컬 폴더다. 영상에서는 Documents 아래에 단순하게 생성하는 방식으로 진행한다.
4.3 기본 폴더 생성
raw/: 원본 자료 저장소. AI가 읽지만 수정하지 않는다.wiki/: AI가 생성하고 유지하는 Markdown 위키.templates/: 선택 사항. 수동 노트 템플릿을 둘 수 있지만 영상 데모에서는 필수는 아니다.
4.4 규칙 파일 생성
vault 루트에 Claude Code용 claude.md 파일을 둔다. 사용자가 가장 먼저 바꿔야 할 항목은 purpose line, 즉 위키의 목적을 설명하는 한 줄이다. 데모에서는 일본 여행 계획을 목적으로 삼지만, 재생 에너지 연구, 독서 노트, 수업 자료, 업무 문서, 팟캐스트 지식 정리 등으로 바꿀 수 있다.
- 위키의 목적
raw/,wiki/,templates/의 역할- 새 소스를 넣었을 때의 ingest workflow
- 페이지 작성 규칙
- 모든 주장에 소스 참조를 남기는 규칙
- 관련 페이지를 링크하는 규칙
- 질문을 받을 때 raw보다 wiki를 먼저 참고하는 규칙
- 불확실한 내용은 불확실하다고 말하는 규칙
4.5 Web Clipper 설치
영상에서는 Obsidian Web Clipper를 Chrome에 설치한다. 웹 기사를 Markdown으로 저장하기 위한 보조 도구다. 웹 문서를 직접 Obsidian으로 저장하거나 다운로드한 뒤 raw/ 폴더로 옮길 수 있다.
4.6 첫 소스 추가
첫 자료는 도쿄 여행 관련 웹 기사다. Web Clipper로 Markdown 파일을 만들고 이를 raw/ 폴더에 넣는다. 소스는 Markdown일 필요가 없고, PDF, 텍스트 파일, Markdown 등 Claude Code가 읽을 수 있는 형식이면 충분하다.
4.7 코딩 에이전트 실행
터미널에서 vault 폴더로 이동한 뒤 Claude Code를 실행한다. 이후 새 소스를 읽고 위키를 업데이트하라는 요청을 보낸다.
I just added a new source to the raw folder. Please read it and update the wiki.Claude는 새 자료를 읽고 요약과 페이지 생성 계획을 보여준다. 사용자는 생성 범위를 승인하거나 조정할 수 있다. 영상에서는 계획이 적절하다고 보고 진행을 승인한다.
5. 데모에서 확인되는 동작
5.1 첫 번째 소스 ingest
도쿄 여행 기사를 넣은 뒤 Claude는 요약 페이지와 여러 동네별 페이지, 관련 개념 페이지를 만든다. Obsidian에서 wiki/ 폴더를 열면 Markdown 페이지들이 생성되어 있고, 각 페이지에는 다른 페이지로 향하는 링크가 포함된다.
Graph view에서는 하나의 원본 자료에서 파생된 노드와 링크가 보인다. 영상은 한 문서만으로도 연결 구조가 형성되는 모습을 보여주며, 20개 이상의 소스가 들어가면 이 구조가 훨씬 풍부해질 것이라고 설명한다.
5.2 두 번째 소스 ingest
두 번째 자료는 일본 음식 가이드다. 다시 raw/에 넣고 같은 ingest 요청을 한다. 중요한 점은 Claude가 새 페이지만 만드는 것이 아니라 기존 동네 페이지도 업데이트한다는 것이다.
음식 관련 정보가 특정 지역과 연결되면 기존 neighborhood 페이지에 음식 정보가 추가되고, 음식 관련 페이지와 동네 페이지 사이의 링크가 생긴다. 새 문서는 별도의 파일로만 쌓이지 않고 기존 지식 구조에 통합된다.
5.3 질의응답 데모
예시 질문은 음식이 좋고 주요 사찰에도 접근하기 좋은 숙소 지역을 묻는 형태다. Claude는 원본 문서를 처음부터 다시 뒤지는 방식이 아니라 이미 만들어진 동네, 음식, 사찰 관련 위키 페이지를 참고해 답을 구성한다.
이 장면은 튜토리얼의 핵심 시연이다. LLM Wiki는 질문 시점에 검색만 하는 시스템이 아니라, 미리 만들어진 정리와 링크를 활용해 교차 소스 답변을 더 빠르고 일관되게 만들도록 설계된다.
6. Lint와 유지관리
영상은 위키가 커질수록 lint workflow가 중요하다고 설명한다. 여기서 lint는 코드 lint와 유사한 개념으로, 지식 베이스의 구조와 품질을 점검하는 절차다.
- 서로 모순되는 주장
- 오래되었거나 갱신이 필요한 내용
- 아무 곳에서도 링크되지 않은 orphan page
- 깨진 링크
- 자주 언급되지만 전용 페이지가 없는 개념
- 소스 인용이 부족하거나 잘못된 주장
이 workflow는 LLM Wiki를 단순 생성물에서 유지관리 가능한 지식 시스템으로 바꾼다. 특히 초기에 리뷰와 lint를 자주 해야 AI가 잘못된 분류 방식이나 연결 습관을 반복하지 않는다.
7. RAG 대비 차이
| 항목 | 일반 RAG 사용 | LLM Wiki 사용 |
|---|---|---|
| 기본 동작 | 질문마다 원본 문서에서 관련 청크 검색 | 자료를 읽고 지속적 Markdown 위키로 통합 |
| 지식 축적 | 답변 과정이 다음 질문에 잘 남지 않음 | 페이지, 링크, 요약, 비교가 누적됨 |
| 다중 문서 연결 | 질문 시점마다 다시 연결해야 함 | 사전 연결된 wiki graph를 활용함 |
| 원본 보존 | 업로드된 문서가 검색 대상 | raw/가 읽기 전용 source of truth |
| 검증 방식 | 답변의 근거 확인이 도구별로 다름 | 페이지별 source reference와 lint를 규칙화 |
| 적합한 규모 | 단발성 문서 질의 | 개인 또는 팀 단위의 반복 지식 관리 |
영상의 주장은 RAG가 쓸모없다는 것이 아니다. 단순 retrieval에는 여전히 유용하지만, 반복적인 학습과 연구처럼 지식 연결이 계속 누적되어야 하는 상황에서는 LLM Wiki가 더 적합하다는 관점이다.
8. 활용 사례
- 학생과 연구자: 논문, 수업 자료, 리딩 노트를 개념별 위키로 축적할 수 있다.
- 교사: 수업 자료, 참고 문헌, 활동 아이디어를 연결된 지식 베이스로 만들 수 있다.
- 비즈니스 사용자: 회의 노트, 전략 문서, 고객 조사, 내부 보고서를 통합할 수 있다.
- 호기심 많은 독자: 책, 팟캐스트, 기사에서 얻은 지식을 장기적으로 연결할 수 있다.
특히 이 방식은 개인 지식 관리에 강하다. 원본은 로컬에 남고, 위키는 plain text Markdown으로 유지되며, 특정 SaaS의 내부 데이터베이스에 갇히지 않는다.
9. 한계와 실패 모드
- 대규모 기업 검색 엔진이나 거대 코퍼스용 시스템이라기보다, 수십에서 수백 개 정도의 개인 또는 소규모 자료에 더 적합하다.
- 결과 품질은 사용자가 넣는 소스의 품질에 크게 의존한다. 낮은 품질의 자료를 많이 넣으면 위키도 흐려진다.
- Claude Code, Codex, Cursor처럼 로컬 파일을 읽고 쓸 수 있는 코딩 에이전트가 필요하다.
- AI가 개념을 잘못 분류하거나 부정확한 연결을 만들 수 있다.
- 초기에 리뷰하지 않으면 잘못된 구조가 위키 전반에 퍼질 수 있다.
- 링크와 인용 규칙을 강하게 두지 않으면, 보기에는 그럴듯하지만 검증이 어려운 위키가 될 수 있다.
- 원본 자료가 갱신되었을 때 기존 wiki 페이지를 어떻게 갱신할지에 대한 운영 규칙이 필요하다.
따라서 LLM Wiki는 완전 자동 지식 관리가 아니라, AI가 초안을 만들고 사용자가 운영 규칙과 리뷰로 품질을 잡는 반자동 시스템에 가깝다.
10. 따라 하기 체크리스트
- Obsidian을 설치한다.
- 새 vault를 만들고 이름을
LLM wiki로 지정한다. - vault 루트에
raw/,wiki/,templates/폴더를 만든다. - Claude Code를 쓴다면 루트에
claude.md를 만든다. - Codex를 쓴다면 같은 역할의 규칙을
AGENTS.md에 작성한다. - 규칙 파일의 purpose line을 실제 지식 베이스 목적에 맞게 바꾼다.
raw/는 읽기 전용 source of truth로 명시한다.wiki/는 AI가 생성하고 갱신하는 Markdown 출력 폴더로 명시한다.- 페이지마다 summary, source reference, related links를 넣도록 규칙화한다.
- Obsidian Web Clipper를 설치해 웹 기사를 Markdown으로 저장한다.
- 첫 소스를
raw/에 넣는다. - 코딩 에이전트를 vault 디렉터리에서 실행한다.
- 새 소스를 읽고 wiki를 업데이트하라고 요청한다.
- 에이전트의 생성 계획을 검토하고 필요하면 범위를 조정한다.
- Obsidian graph view에서 링크 구조를 확인한다.
- 두 번째 소스를 넣고 기존 페이지가 업데이트되는지 확인한다.
- wiki 기반 질의응답을 테스트한다.
- 정기적으로 lint를 요청해 모순, 고아 페이지, 깨진 링크, 인용 누락을 점검한다.
11. Codex/AGENTS.md로 바꿔 적용할 때
영상은 Claude Code 기준으로 진행하지만, 같은 구조를 Codex에 적용할 수 있다. 핵심은 claude.md에 담긴 운영 규칙을 AGENTS.md로 옮기는 것이다.
# LLM Wiki Operating Rules
Purpose: 일본 여행 계획을 위한 개인 지식 위키를 유지한다.
Folders:
- raw/: 원본 자료. 읽기 전용 source of truth로 취급한다.
- wiki/: AI가 생성하고 갱신하는 Markdown 위키다.
- templates/: 선택적 템플릿 저장소다.
Ingest workflow:
1. raw/의 새 자료를 읽는다.
2. 핵심 개념, 장소, 인물, 주장, 비교 지점을 추출한다.
3. 기존 wiki 페이지가 있으면 먼저 업데이트한다.
4. 새 개념은 새 페이지로 만든다.
5. 관련 페이지끼리 Markdown 링크를 추가한다.
6. 모든 주요 주장에 원본 파일 참조를 남긴다.
7. 변경 요약을 작성한다.
Question answering:
- 질문에는 wiki/를 먼저 참고한다.
- 필요한 경우 raw/로 원문을 검증한다.
- 불확실한 내용은 불확실하다고 표시한다.
- 여러 소스가 충돌하면 충돌을 숨기지 않는다.
Lint workflow:
- 모순된 주장, 깨진 링크, 고아 페이지, 인용 누락, 전용 페이지가 필요한 개념을 점검한다.Codex로 운영할 때 특히 중요한 점은 파일 경계를 명확히 하는 것이다. raw/는 원본 보존 영역이고, wiki/는 Codex가 편집 가능한 산출 영역이다. 이 경계를 AGENTS.md에 적어 두면, 에이전트가 원본 자료를 실수로 수정하지 않도록 운영 규칙을 세울 수 있다.
또한 자연어 문장을 하드코딩된 명령 판별 규칙으로 만들기보다는, 작업자가 명시적으로 ingest, lint, answer 같은 작업 모드를 요청하고 Codex가 규칙 파일을 기준으로 수행하도록 두는 편이 안전하다. 이 튜토리얼의 취지는 키워드 트리거를 만드는 것이 아니라, 지속적으로 유지되는 지식 베이스의 구조와 운영 규칙을 세우는 데 있다.