Shann Holmberg는 에이전트가 쓸모 없는 근본 이유는 지식을 보관하지 않기 때문이라고 주장합니다. 모든 대화가 0에서 시작하고, 매번 비즈니스 맥락·목소리·목표를 재설명해야 하며, 결과는 늘 제네릭합니다. 해법은 에이전트와 사용자 사이에 앉는 Knowledge Layer — Karpathy의 LLM Wiki 패턴을 따르는 두 레이어 시스템입니다. 20분 셋업, 매일 스스로 개선, 오픈소스.
원문: AI Knowledge Layer (and why your agents are useless without it) — Shann Holmberg · 구현체: shannhk/llm-wikid
핵심 문제 — 에이전트는 매번 0에서 시작한다
대부분의 팀이 겪는 패턴:
- 모델과 하네스(harness)에만 돈·관심이 쏠림
- 막상 에이전트는 당신이 누구인지, 무엇을 해왔는지, 어떤 톤·제약으로 일하는지 전혀 모름
- Claude·ChatGPT·Cursor·Copilot이 아무리 강력해도 컨텍스트가 매번 휘발되면 결과는 제네릭
Karpathy는 최근 “토큰 예산 대부분을 코드가 아니라 지식 관리로 옮기고 있다” 고 말했습니다. 이 기사는 그 시프트를 누구나 재현할 수 있는 인프라로 내려 놓은 구현입니다.
왜 RAG가 아닌가 — Compiled vs Retrieved
RAG는 매 쿼리마다 문서를 청크로 나누고 벡터 검색으로 답을 재유도합니다. 지식이 누적되지 않고, 매번 stateless로 처음부터 합성합니다.
Karpathy의 관찰:
약 100편 / 400K 단어 규모가 되면, 한 번 컴파일된 위키가 Q&A에서 RAG를 능가한다.
이유:
- 교차 참조가 미리 계산되어 있어 쿼리 시점에 그래프 탐색이 필요 없음
- 답이 파일로 다시 떨어지면 다음 쿼리가 더 풍부한 기반 위에서 시작
- 벡터 유사도의 노이즈가 아니라 구조화된 링크로 연결 — 컨텍스트 윈도우 사용이 훨씬 효율적
- 지식이 복리로 성장한다 (compound), stateless가 아니다
두 레이어 아키텍처
| 레이어 | 역할 | 특성 |
|---|---|---|
raw/ — 원시 인박스 | 잘라 넣은 웹 페이지, PDF, 트윗, 영상, 아이디어, 북마크 | 처리 없음. 스테이징 영역. 지저분해도 됨 |
wiki/ — 컴파일된 위키 | 개념·엔티티·출처·시너시스로 정리된 교차 링크 노트 | AI가 유지·갱신. [[wikilinks]]로 그래프 형성 |
에이전트가 raw/를 읽어 wiki/로 컴파일하는 것이 핵심 동작입니다. 한 번 들어간 원재료는 여러 번 위키 페이지를 업데이트합니다.
7단계 인제스트 파이프라인
- Sort clippings — URL 타입으로 자동 분류 (유튜브/논문/트윗/블로그 등)
- Resolve content —
yt-dlp(영상), X API(트윗),scrapling(웹), 직접 PDF 리딩으로 전체 본문 확보 - Media extraction — 이미지 다운로드, 영상 자막 추출
- Classify & compile — 포맷별 추출 (트랜스크립트는 화자, 논문은 메서드·파인딩)
- Cross-linking — 관련 페이지 간
[[wikilinks]]자동 생성 - Bias checking — 반대 논거와 데이터 공백 섹션 추가
- Re-indexing —
qmd설치 시 검색 갱신
4가지 핵심 커맨드
| 커맨드 | 기능 |
|---|---|
/wiki-ingest | raw/의 원재료를 wiki/ 페이지로 컴파일 |
/wiki-query [질문] | 리서치 질문 → 출처 달린 답변 반환 → 다시 outputs/에 파일링 |
/wiki-explore [주제] | 웹 검색·커뮤니티 시그널로 능동적 리서치 |
/wiki-lint | 모순·고아 페이지·깨진 링크 헬스 체크 |
핵심 디자인: 모든 /wiki-query 답변이 outputs/에 파일링되어 다음 쿼리의 재료가 됩니다. 질의가 지식을 소비하는 것이 아니라 기여합니다.
폴더 구조 (인제스트 후)
raw/ # 지저분한 인박스
clippings/ # URL 타입별 자동 정렬
ideas/ # 반쯤 형성된 생각
bookmarks/ # 클리핑된 컨텐츠
articles/ # 출판된 글
papers/ # 연구 PDF
assets/images/ # 다운로드된 미디어
x-archive/ # 트위터 아카이브
wiki/ # AI가 유지하는 컴파일 결과
index.md # TLDR 포함 마스터 카탈로그
log.md # 추가 전용 체인지로그
concepts/ # 교차 아이디어
entities/ # 도구·사람·프로젝트
sources/ # 원재료 정리
syntheses/ # 교차 분석
outputs/ # 파일링된 쿼리 답변
sops/ # 문서화된 프로세스
품질 컨트롤 — “AI가 잘못 이해하면?”
Karpathy 패턴의 약점을 시스템적으로 메우는 장치들:
explored: true/false플래그 — 페이지는 기본값false. 사람의 리뷰만true로 바꿀 수 있음 → 검증 상태가 투명- Confidence 태깅 —
high/medium/low/uncertain. 다수 출처 = high, 단일 언급 = low - Source tracing — 모든 주장은 특정 출처 페이지로 링크됨. 근거 없는 단언 금지
- Bias 섹션 — 모든 개념·출처 페이지에 반대 논거·데이터 공백 섹션 — 에코 챔버 방지
- Git 통합 —
raw/·wiki/를 바꾸는 모든 작업이 자동 커밋·푸시 → 완전한 되돌림 가능, 멀티 에이전트 협업 안전
셋업 (20분)
git clone https://github.com/shannhk/llm-wikid.git my-wiki
cd my-wiki
# my-wiki 폴더를 Obsidian vault로 오픈
claude --dangerously-skip-permissions
에이전트는 CLAUDE.md(시스템 스키마)를 읽고 모든 워크플로를 그곳에서 실행합니다. Obsidian은 뷰어, LLM은 메인테이너 역할.
선택 도구:
yt-dlp— 유튜브 트랜스크립트scrapling— 웹 스크레이핑- X API — 트윗·스레드 가져오기
qmd— 전문 검색 인덱싱 (BM25 + 벡터 + LLM 리랭킹)
스케일링 전략
| 위키 규모 | 접근 |
|---|---|
| 0–300 페이지 | 파일 기반 + 인덱스 TLDR 스캔 |
| 300–500 페이지 | qmd 기본 검색 |
| 500+ 페이지 | PostgreSQL / Supabase 검토 |
왜 지금 중요한가
모델이 아무리 똑똑해져도 당신에 대한 영구적 이해가 없으면 에이전트는 제네릭 툴에 머뭅니다. 하네스가 LLM을 “폰 노이만 아키텍처"로 감싸 CPU를 완성했다면, Knowledge Layer는 그 위에 영구 스토리지 + 개인화된 운영체제를 올리는 작업입니다.
핵심 비대칭:
- RAG = 매번 답을 다시 합성 → 지식이 누적되지 않음
- Knowledge Layer = 한 번 컴파일 → 매 쿼리가 기반을 두껍게 만듦
컴파일된 지식은 복리로 쌓인다. 에이전트는 매일 똑똑해진다.
robots.txt·llms.txt가 바깥 세계를 에이전트 친화적으로 바꾸는 작업이라면, Knowledge Layer는 당신의 내부 맥락을 에이전트 친화적으로 바꾸는 작업입니다. 양쪽이 합쳐질 때 에이전트는 비로소 당신의 에이전트가 됩니다.
실행 우선순위
shannhk/llm-wikid클론 → 20분 셋업raw/에 지난 30일치 클리핑 50개 투입/wiki-ingest실행하여 컴파일된 구조 확인/wiki-query로 첫 답을 받고outputs/에 파일링되는 흐름 체감/wiki-lint주 1회로 헬스 체크- 100편 돌파 후 RAG와의 체감 차이 비교
핵심 결론
- 에이전트가 유용해지려면 모델 바깥의 지속 가능한 지식 레이어가 필요하다
- RAG는 쿼리 시점 합성, LLM Wiki는 사전 컴파일된 그래프 — 100편 스케일에서 후자가 유리
- 두 레이어(
raw/+wiki/) + 7단계 파이프라인 + 4개 커맨드로 구현 가능 - 품질은
explored플래그, confidence 태깅, bias 섹션, Git 커밋으로 확보 - 당신이 매일 쌓는 지식이, 내일 당신의 에이전트가 된다