LLM Wiki로 도메인 지식을 복리로 쌓는 법: 부동산 위키 구축 실전기

원본 아이디어: Andrej Karpathy, llm-wiki.md (2026년 4월)
결과물 열람 환경: Obsidian

---

왜 RAG 대신 위키인가

LLM으로 문서를 다루는 가장 흔한 방법은 RAG(Retrieval-Augmented Generation)다. 파일을 업로드하면 LLM이 질문마다 관련 청크를 꺼내 답을 만든다. 간단하고 빠르지만 결정적인 약점이 있다. 지식이 쌓이지 않는다.

같은 질문을 다시 물어도 LLM은 처음부터 다시 문서를 뒤진다. 다섯 개 글을 종합해야 답할 수 있는 미묘한 질문에서는 그때마다 조각을 새로 맞춰야 한다. NotebookLM, ChatGPT 파일 업로드, 대부분의 RAG 시스템이 이 방식이다.

Karpathy가 제안한 LLM Wiki 패턴은 다르다. 새 소스를 넣으면 LLM이 즉시 읽고, 핵심을 추출하고, 기존 위키에 통합한다. 모순은 지금 표시되고, 교차 참조는 이미 걸려 있고, 종합 판단은 읽은 모든 것을 반영한다. 지식은 매번 재발견되는 것이 아니라 누적된 아티팩트로 자라난다.

Karpathy의 표현을 빌리면:

"Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."

이 글은 그 아이디어를 부동산 블로그 지식 베이스에 직접 적용한 경험을 기록한다. 구체적으로 어떤 구조를 만들었는지, 어떤 결정이 효과적이었는지, 앞으로 어떤 유지 비용이 들 것인지를 다룬다.

---

프로젝트 구조: 세 레이어

Karpathy가 제시한 아키텍처는 세 레이어다.

raw/         ← 원본 소스. LLM이 읽기만 하고 절대 수정하지 않는다.
wiki/        ← LLM이 생성·유지하는 구조화된 지식 파일들
AGENTS.md    ← LLM에게 위키 구조와 작업 절차를 알려주는 스키마

이 저장소는 이 구조를 그대로 따르되, 부동산 도메인에 맞게 wiki/ 아래를 다시 나눴다.

wiki/
  source-notes/   ← 블로그 글 하나당 요약·맥락 메모
  market-themes/  ← 시장 테마 허브 (수요 집중, 금리-가격 관계 등)
  policies/       ← 정책·세금·대출 허브
  finance/        ← 자금 계획·수익성 허브
  strategies/     ← 실거주·투자 전략 허브
  analyses/       ← 질의 응답·비교·종합 분석
  regions/        ← 지역별 시장 (미완성)
  players/        ← 필자·기관 (미완성)

이 분류는 처음부터 완벽하게 잡은 것이 아니다. 초기 ingest를 몇 번 하면서 자연스럽게 생긴 카테고리다. 새 소스를 넣을수록 어떤 허브 페이지가 필요한지 윤곽이 잡혔다.

---

핵심 설계 결정: AGENTS.md와 스킬의 분리

이 프로젝트에서 가장 효과적이었던 설계 결정 하나를 꼽자면 AGENTS.md를 최소화하고, 반복 워크플로를 별도 스킬 파일로 분리한 것이다.

문제: AGENTS.md 비대화

LLM Wiki를 처음 시작하면 모든 규칙을 AGENTS.md 하나에 넣고 싶어진다. 워크플로 단계, 파일 형식, 작성 규칙, 태그 어휘, 예외 처리... 결국 수백 줄짜리 스키마가 된다.

문제는 토큰 낭비다. 에이전트가 모든 작업마다 이 파일 전체를 컨텍스트에 올린다. 지금 ingest를 하는데 lint 체크리스트까지 읽을 필요는 없다.

해결책: 최소 AGENTS.md + 스킬 포인터

현재 AGENTS.md는 30줄이 채 안 된다.

# AGENTS.md

## Core Rules
- raw/ 수정 금지
- wiki/ 변경 시 index.md 업데이트
- 작업 후 log.md에 항목 추가
- 충돌 주장은 삭제하지 말고 차이를 기록
- 원본 텍스트를 길게 복사하지 말고 요약·통합

## Repeated Workflows
- ingest: .cursor/skills/real-estate-wiki-ingest/SKILL.md
- query:  .cursor/skills/real-estate-wiki-query/SKILL.md
- lint:   .cursor/skills/real-estate-wiki-lint/SKILL.md

이게 전부다. 핵심 불변 규칙만 남기고, 워크플로 상세는 해당 스킬 파일로 포인터를 던진다.

스킬 파일은 그 작업이 필요할 때만 읽힌다. ingest를 요청하면 ingest 스킬만, lint를 요청하면 lint 스킬만 로드된다. 각 스킬은 다시 실제로 필요한 참조 파일(reference.md, wiki-conventions.md, tag-vocabulary.md)로만 연결된다.

AGENTS.md (30줄)
  └─ ingest 스킬 SKILL.md (28줄)
       └─ reference.md     ← 워크플로 단계 + 소스 노트 템플릿
       └─ wiki-conventions.md ← 작성 규칙
       └─ tag-vocabulary.md   ← 태그 목록

이 구조의 장점:

1. 컨텍스트 효율: 작업마다 필요한 파일만 읽힌다. 불필요한 토큰 소비가 없다.
2. 수정 용이성: ingest 워크플로를 바꾸고 싶으면 ingest 스킬만 편집하면 된다. AGENTS.md는 건드리지 않아도 된다.
3. 에이전트 판단 유도: 스킬 파일의 description 필드가 "언제 이 스킬을 쓸지"를 명시하므로 에이전트가 스스로 올바른 워크플로를 선택한다.
4. 세션 간 일관성: 새 대화 세션을 시작해도 에이전트가 AGENTS.md → 스킬 → 참조 파일 순서로 읽으면 동일한 절차를 따른다.

반복 워크플로를 별도 파일로 분리하지 않고 AGENTS.md 하나에 모두 넣었다면, 매 작업마다 전체 스키마를 읽는 낭비가 생겼을 것이다. 위키가 커질수록 이 차이는 누적된다.

---

세 가지 워크플로: Ingest, Query, Lint

Ingest: 지식의 입력구

새 블로그 글을 raw/sources/에 넣고 "ingest해줘"라고 요청하면 다음 단계가 자동으로 실행된다.

1. wiki/source-notes/에 요약 페이지 생성
2. 관련 허브 페이지 업데이트 (새로 만들거나 기존 페이지에 통합)
3. index.md 업데이트
4. log.md에 작업 기록 추가

하나의 블로그 글이 평균 3~5개 파일에 영향을 준다. 허브 페이지가 쌓일수록 새 소스가 기존 지식을 강화하거나 수정하는 밀도가 높아진다. Karpathy가 말한 "복리 효과"가 실제로 느껴지는 지점이다.

이 프로젝트에서는 블로그 글 50편 이상을 ingest했다. 초반에는 대부분 새 페이지를 만드는 작업이었지만, 30편을 넘어서면서부터는 기존 허브 페이지를 더 풍부하게 만드는 작업이 더 많아졌다.

Query: 지식의 출력구

위키가 채워지면 직접 질문할 수 있다.

"신혼부부는 어떤 아파트를 골라야 하나요?"

에이전트는 index.md를 먼저 읽어 관련 페이지를 찾고, 그 페이지들을 참조해 답을 만들며, 분석 결과가 재사용 가치가 있으면 wiki/analyses/에 파일로 저장한다. 이 저장소에는 wiki/analyses/newlywed-apartment-selection.md가 이렇게 생성됐다.

질문의 답이 위키에 다시 쌓인다는 점이 중요하다. 다음 번 비슷한 질문에는 이 분석이 출발점이 된다.

Lint: 지식의 유지관리

위키가 커지면 모순, 끊긴 링크, 고아 페이지, 공백 주제가 생긴다. Lint는 이것들을 주기적으로 점검한다.

이 저장소에서 lint를 실행한 결과 발견된 대표적 문제들:

• 소스 노트 대부분의 Published: 필드가 비어 있음 (시간 민감 주장 추적 약화)
• 개발 호재 분석 소스 노트가 존재하지 않는 raw 경로를 참조
• 정책·대출 임계값 관련 페이지에 검증 시점 명시 부재
• wiki/regions/와 wiki/players/가 비어 있음

Lint는 직접 고치는 작업이 아니라 다음에 무엇을 해야 하는지 알려주는 작업이다. 이 점검 결과가 log.md에 남고, 다음 ingest와 구조 개선의 방향이 된다.

---

현재 규모와 구조

2026년 4월 15일 기준으로 이 저장소의 상태:

항목	수량
소스 노트 (wiki/source-notes/)	50개 이상
허브 페이지 (market-themes + policies + finance + strategies + analyses)	30개 이상
ingest 실행 횟수	40회 이상
lint 실행 횟수	3회
전체 YAML 프론트매터 추가	82개 페이지 일괄 처리
태그 어휘 (docs/tag-vocabulary.md)	신설 (한국어 태그 포함)

Obsidian의 그래프 뷰에서 허브 페이지가 중심에서 여러 소스 노트와 연결된 구조가 시각적으로 확인된다. 처음 몇 개 글을 ingest할 때는 고립된 섬들이었지만, 지금은 상당수가 2~3개 허브를 공유하며 연결돼 있다.

---

추후 유지 관리 예상

LLM Wiki의 유지 비용은 "처음에는 낮고, 규모가 커질수록 일정 주기의 정리가 필요해진다"는 패턴을 따른다.

단기 (지금~소스 100편)

• Ingest는 여전히 저비용: 새 글 하나가 들어오면 에이전트가 대부분을 알아서 처리한다. 허브 페이지가 이미 있으니 새 소스는 기존 구조에 통합된다.
• Published 날짜 역추적: 현재 소스 노트 대부분에 원본 발행일이 없다. 정책·금리 관련 주장은 날짜 맥락이 없으면 시간이 지날수록 신뢰도가 떨어진다. 역추적 작업이 필요하다.
• 정책 민감 페이지 재검증: DSR 단계, 세금 임계값, 보증 기관 조건 등은 제도 변경 시 빠르게 낡는다. 연 1~2회 관련 페이지를 점검하고 "검증 시점"을 업데이트해야 한다.

중기 (소스 100~300편)

• 지역 페이지 구축 필요: 현재 wiki/regions/가 비어 있다. 수도권·지방 시장 특성 분류가 없으면 일반론에 그치는 분석이 늘어난다. 지역별 소스를 의식적으로 수집하고 ingest해야 한다.
• 청약 허브 생성: 청약 제도는 단독 카테고리를 만들 만큼 소스가 쌓였지만 아직 허브가 없다. 소스 노트들은 기존 전략 허브에 흩어져 있다.
• 필자 추적 시작: 같은 주제를 다루는 두 소스가 다른 결론에 도달할 때, 필자의 관점 차이와 분석 시점 차이를 분리하는 것이 중요해진다. wiki/players/를 채우기 시작해야 한다.
• Index 파일 탐색 한계: index.md가 현재 110줄짜리 목록이다. 소스 300편을 넘어서면 에이전트가 index만으로 관련 페이지를 찾기 어려워진다. 로컬 검색 도구(qmd 등) 도입을 검토해야 한다.

장기 (소스 300편 이상)

이 수준에서는 위키 자체가 복잡한 시스템이 된다. Karpathy도 인정하듯, 규모가 커질수록 lint가 발견하는 문제가 늘고 일부는 수작업 판단이 필요해진다. 에이전트가 완벽히 자율적으로 운영하기 어려운 영역들이 생긴다.

현실적인 예상:

• 주요 정책 변화 직후에는 관련 페이지를 일괄 재검증하는 lint 패스가 필요하다
• 허브 페이지가 너무 길어지면 하위 페이지로 분할하는 재구조화 작업이 주기적으로 발생한다
• 서로 다른 필자의 상충되는 주장이 쌓이면 단순 병렬 기록이 아니라 판단을 담은 종합 분석이 필요해진다

---

유용한 사용 시나리오

시나리오 1: 부동산 공부 중인 실거주자

청약을 준비하는 사람이 매주 블로그 글 3~5편을 읽는다. 읽을 때마다 ingest하면 위키가 쌓인다. 6개월 후에는 "청약 가점 전략"을 물으면 자신이 읽은 모든 글을 종합한 답을 얻는다. 메모를 정리한 적 없어도 지식이 누적돼 있다.

시나리오 2: 매수 시점 결정이 필요한 투자자

"지금 수도권 시장이 변곡점인가?"라는 질문에 위키는 금리 흐름, 거래량 신호, 입주 물량, 경공매 지표를 한 페이지에 종합하여 답한다. 개별 블로그 글을 다시 찾아볼 필요 없이 축적된 신호들의 관계가 보인다.

시나리오 3: 특정 주제 심화 연구

"59형과 84형 아파트의 수익성 차이"에 대해 두 LLM(Claude, GPT)이 쓴 분석 글이 별도 소스로 ingest돼 있다. 위키는 두 분석의 공통점과 차이점, 각각이 유효한 조건을 나란히 기록한다. 한 소스만 읽었을 때와는 다른, 조건별 판단이 가능한 지식이 된다.

시나리오 4: 세션 간 맥락 유지

LLM 대화는 기본적으로 무상태(stateless)다. 새 대화 창을 열면 이전에 논의한 내용이 사라진다. 위키가 있으면 다르다. 에이전트는 새 세션이 시작돼도 index.md를 읽고 맥락을 복원한다. 지식이 대화 기록이 아니라 파일에 남아 있으므로 세션이 달라져도 이전 분석을 참조할 수 있다.

시나리오 5: 지인에게 설명하기

"전세대출 보증이 어떻게 작동해?"라는 질문을 받으면 위키 페이지 링크를 보내면 된다. 요약 설명을 매번 새로 쓸 필요가 없다. 위키가 이미 정리해 두었다.

---

Obsidian과 함께 쓰는 이유

결과물을 Obsidian에서 열람하면 텍스트 목록 이상의 것이 보인다.

• 그래프 뷰: 어떤 페이지가 허브인지, 어느 주제가 고아 상태인지 시각적으로 파악된다. Lint보다 빠르게 구조의 문제가 눈에 들어온다.
• Dataview 플러그인: YAML 프론트매터(type, status, updated, tags, source_count)를 쿼리하면 "최근 업데이트된 finance 페이지 목록" 같은 동적 테이블을 만들 수 있다.
• 백링크 패널: 특정 페이지가 몇 개의 다른 페이지에서 참조되는지 즉시 확인된다. 참조 수가 많은 페이지가 실질적인 지식 허브다.
• 검색: 전문 검색으로 특정 용어나 수치가 어느 페이지에 있는지 빠르게 찾는다.

Obsidian은 이 위키의 뷰어이자 탐색 인터페이스다. 에이전트가 파일을 만들고 수정하는 동안 Obsidian 창에서 변화를 실시간으로 확인할 수 있다.

---

시작하려는 사람에게

이 패턴을 따라 자신만의 도메인 위키를 만들고 싶다면:

1. 스키마부터 시작하라. AGENTS.md에 수집 범위와 불변 규칙을 5~7줄로 정리하는 것이 먼저다. 세부 워크플로는 나중에 스킬로 분리한다.

2. 소스 5~10편으로 구조를 먼저 잡아라. 초반에는 어떤 카테고리가 필요한지 모른다. 소수의 소스를 ingest하면서 자연스럽게 드러나는 허브 구조를 따라가는 것이 낫다.

3. 한 번에 하나씩 ingest해라. 배치 ingest는 가능하지만 단일 소스로 작업하면서 에이전트의 판단을 확인하는 것이 위키의 품질을 더 잘 통제할 수 있다.

4. Lint를 두려워하지 마라. Lint가 발견하는 문제는 위키가 성장했다는 증거다. 문제 목록은 다음 작업의 우선순위 목록이기도 하다.

5. 완벽한 구조를 기다리지 마라. 위키는 완성되는 것이 아니라 계속 진화하는 것이다. regions/와 players/가 비어 있어도 오늘 ingest는 가치 있다.

---

LLM Wiki는 "LLM이 모든 걸 해준다"는 아이디어가 아니다. 사람이 소스를 고르고, 질문을 던지고, 방향을 결정한다. LLM은 요약하고, 교차 참조하고, 파일을 유지하는 작업을 맡는다. 유지관리 비용이 사람에게서 LLM으로 이동하는 것이 이 패턴의 본질이다.

지식이 대화 기록에 증발하지 않고 파일로 남는다. 그 파일들이 서로 연결된다. 다음 질문은 이전 답을 출발점으로 삼는다. 이것이 복리다.

---

• Sonnet 4.6 작성