카르파시의 LLM Wiki 핵심 개념과 구축법

2026년 4월, Andrej Karpathy가 X에 올린 LLM wiki 글 하나가 개발자 커뮤니티를 뒤흔들었습니다.

내용은 단순했습니다. LLM 에이전트를 활용해 개인 지식 베이스를 자동으로 구축하고 유지할 수 있다는 것이었습니다.

해당 게시물은 1,600만 뷰를 넘겼고, 연결된 GitHub Gist는 며칠 만에 별 5,000개를 돌파했습니다.

이 포스트에서는 그 패턴의 전체 구조를 분석하고, Claude Code와 Obsidian을 활용해 직접 구현하는 방법을 단계별로 안내해 드리겠습니다.

기본 구조는 다음 세 층으로 나뉩니다.

raw/ — 원본 소스 (절대 수정하지 않음)
wiki/ — LLM이 생성하는 마크다운 지식 페이지
CLAUDE.md — 전체 시스템을 지휘하는 스키마 파일

핵심 작업은 수집(ingest), 질의(query), 검사(lint) 세 가지입니다.

이 방식은 복잡한 RAG 파이프라인 없이, 폴더와 마크다운 파일만으로 개인 또는 팀 규모의 지식 관리를 가능하게 해 줍니다.

왜 지식 베이스는 항상 무너질까요

개발자라면 누구나 경험해 보셨을 겁니다.

처음에는 의욕적으로 만들기 시작한 Notion 데이터베이스, 수백 개의 북마크 폴더, 그럴싸하게 시작했던 Obsidian 볼트

결국 셋 다 먼지만 쌓이게 됩니다.

문제는 도구가 아닙니다. 유지 관리 비용이 문제입니다.

지식 베이스 구축은 사실 세 단계로 이루어집니다.

수집 — 어렵지 않습니다
정리 — 꽤 힘듭니다
유지 — 규모가 커지면 사실상 불가능합니다

새로운 글 하나를 추가한다고 상상해 보세요. 읽어야 하고, 요약해야 하고, 기존 개념들과 연결 고리를 만들어야 하며, 관련 페이지를 업데이트하고, 기존 내용과 충돌이 없는지 확인해야 합니다.

이걸 매번 꼼꼼히 하는 사람은 사실상 없습니다.

Karpathy가 발견한 것은 간단하지만 강력한 사실입니다.

LLM은 바로 이런 종류의 단순 반복 작업을 매우 잘합니다.

문서를 읽고, 핵심 개념을 파악하고, 요약을 생성하고, 교차 참조를 만들고, 인덱스를 업데이트하고, 모순을 탐지하는 일

이 모든 것을 지칠 줄 모르고, 일관되게, 거의 비용 없이 처리할 수 있습니다.

인간이 할 일은 무엇을 넣을지 결정하는 것뿐입니다. 나머지는 LLM이 처리해 줍니다.

실제로 Karpathy의 특정 연구 주제 위키는 이 방식을 통해 약 100개의 문서, 40만 단어 규모로 성장했습니다.

대부분의 박사 논문보다 긴 분량이지만, 그가 직접 쓴 글은 거의 없습니다.

3-Layer 아키텍처 상세 분석

디렉토리 구조는 의도적으로 단순하게 설계되어 있습니다.

my-research/
├── raw/                    # 1층: 절대 수정 불가 원본 소스
│   ├── articles/
│   ├── papers/
│   ├── repos/
│   ├── data/
│   ├── images/
│   └── assets/
├── wiki/                   # 2층: LLM이 생성하는 마크다운 페이지
│   ├── index.md            # 전체 콘텐츠 목록 (수집할 때마다 갱신)
│   ├── log.md              # 추가 전용 작업 기록
│   ├── overview.md
│   ├── concepts/           # 개념 페이지
│   ├── entities/           # 엔티티 페이지
│   ├── sources/            # 소스 요약 페이지
│   └── comparisons/        # 비교 분석 페이지
├── outputs/                # 날짜별 리포트, 프레젠테이션
├── CLAUDE.md               # 3층: 스키마 설정 파일
└── .gitignore

my-research/
├── raw/                    # 1층: 절대 수정 불가 원본 소스
│   ├── articles/
│   ├── papers/
│   ├── repos/
│   ├── data/
│   ├── images/
│   └── assets/
├── wiki/                   # 2층: LLM이 생성하는 마크다운 페이지
│   ├── index.md            # 전체 콘텐츠 목록 (수집할 때마다 갱신)
│   ├── log.md              # 추가 전용 작업 기록
│   ├── overview.md
│   ├── concepts/           # 개념 페이지
│   ├── entities/           # 엔티티 페이지
│   ├── sources/            # 소스 요약 페이지
│   └── comparisons/        # 비교 분석 페이지
├── outputs/                # 날짜별 리포트, 프레젠테이션
├── CLAUDE.md               # 3층: 스키마 설정 파일
└── .gitignore

1 Layer: 원본 소스 (`raw/`)

수집한 모든 자료—논문, 기사, 코드 저장소, 데이터셋, 이미지—를 보관하는 공간입니다.

LLM은 이 파일들을 읽기만 할 뿐, 절대 수정하지 않습니다.

위키의 모든 주장은 반드시 이 폴더의 파일로 추적될 수 있어야 합니다.

검증의 기반이 되는 불변 레이어입니다.

웹 기사를 마크다운으로 변환해 raw/articles/에 바로 저장하려면 Obsidian Web Clipper 브라우저 확장 프로그램을 활용하시면 편리합니다.

2 Layer: 위키 (`wiki/`)

LLM이 생성하고 관리하는 마크다운 페이지들입니다. 유형별로 정리됩니다.

concepts/ — 개념 페이지 (예: attention-mechanism.md, rag.md)
entities/ — 엔티티 페이지 (예: openai.md, anthropic.md)
sources/ — 수집된 문서당 하나씩 생성되는 요약 페이지
comparisons/ — 개념 비교 페이지 (예: rag-vs-fine-tuning.md)

두 개의 구조적 핵심 파일이 있습니다.

index.md: 전체 콘텐츠 목록. LLM은 위키를 탐색할 때 이 파일을 가장 먼저 읽습니다.
log.md: 추가 전용 작업 로그. 모든 수집, 업데이트, 발견된 모순을 기록합니다.

이 디렉토리는 LLM이 대부분 쓰고, 인간이 대부분 읽는 공간입니다.

3 Layer: 스키마 (`CLAUDE.md`)

시스템 전체에서 가장 중요한 파일입니다.

위키의 구조, 명명 규칙, 페이지 템플릿, 작업 흐름을 정의합니다.

일반적인 LLM을 규율 있는 지식 관리자로 변환하는 역할을 합니다.

Karpathy가 주로 Claude Code를 에이전트로 사용하기 때문에 파일명이 CLAUDE.md이지만, 파일 접근이 가능한 어떤 LLM 에이전트에도 동일한 원칙이 적용됩니다.

세 가지 핵심 작업

Karpathy는 컴파일러 비유를 즐겨 사용합니다.

raw/는 소스 코드, LLM은 컴파일러, wiki/는 실행 파일, lint는 테스트, query는 런타임에 해당합니다.

수집 (Ingest)

새 소스를 raw/에 추가하고 LLM에게 처리를 요청합니다.

> raw/articles/에 새 기사를 추가했어. 수집해줘.

> raw/articles/에 새 기사를 추가했어. 수집해줘.

LLM은 다음 순서로 작업합니다.

문서를 읽고 핵심 내용 파악
wiki/sources/에 요약 페이지 생성
관련 위키 페이지 10~15개 연쇄 업데이트
필요 시 새로운 개념 또는 엔티티 페이지 생성
index.md 갱신
log.md에 변경 내역과 주목할 발견 사항 기록

단일 수집 작업 하나가 지식 그래프 전체에 파급 효과를 미치며 수십 개 페이지를 건드릴 수 있습니다.

질의 (Query)

위키를 대상으로 질문합니다. LLM은 index.md를 탐색한 뒤 관련 페이지를 읽고, [[위키링크]] 인용과 함께 답변을 합성합니다.

> 희소 검색과 밀집 검색의 핵심 차이점은 뭐야?

> 희소 검색과 밀집 검색의 핵심 차이점은 뭐야?

전체 문서를 무차별적으로 컨텍스트에 로드하는 대신, 인덱스를 통해 필요한 페이지만 선별해 읽습니다.

가치 있는 답변은 새로운 위키 페이지로 저장되어 지식이 축적됩니다.

검사 (Lint)

주기적으로 위키의 건강 상태를 점검합니다. LLM이 확인하는 항목은 다음과 같습니다.

모순 — 페이지 간 상충되는 주장
고아 페이지 — 다른 페이지에서 참조되지 않는 페이지
누락된 개념 — 언급은 됐지만 독립 페이지가 없는 항목
오래된 주장 — 최신 소스에 의해 무효화된 내용
미탐구 영역 — 추가 연구가 필요한 분야

코드 세계의 eslint와 유사한 개념입니다. 일정을 정해 자동으로 실행하거나, 필요할 때 수동으로 요청할 수 있습니다.

> 위키 전체를 검사해줘. 모순과 오래된 주장 위주로.

> 위키 전체를 검사해줘. 모순과 오래된 주장 위주로.

Claude Code로 설정하기

1단계: 디렉토리 구조 생성

mkdir -p ~/research/my-topic/{raw/{articles,papers,repos,data,images},wiki/{concepts,entities,sources,comparisons},outputs}
touch ~/research/my-topic/wiki/index.md
touch ~/research/my-topic/wiki/log.md

mkdir -p ~/research/my-topic/{raw/{articles,papers,repos,data,images},wiki/{concepts,entities,sources,comparisons},outputs}
touch ~/research/my-topic/wiki/index.md
touch ~/research/my-topic/wiki/log.md

2단계: Git 초기화

cd ~/research/my-topic
git init
echo "outputs/*.pdf" >> .gitignore

cd ~/research/my-topic
git init
echo "outputs/*.pdf" >> .gitignore

버전 관리는 필수입니다. 위키의 모든 업데이트가 추적 가능한 diff가 됩니다. 잘못된 수집을 되돌리고, 개념이 어떻게 진화했는지 확인하고, git log를 감사 기록으로 활용할 수 있습니다.

3단계: CLAUDE.md 스키마 작성

아래는 즉시 사용 가능한 템플릿입니다.

# 연구 위키: [주제]

## 프로젝트 구조

- `raw/` — 불변 원본 소스. 이 파일들은 절대 수정하지 않습니다.
- `wiki/` — LLM이 생성하고 관리하는 마크다운 페이지.
- `wiki/index.md` — 전체 콘텐츠 목록. 모든 작업 시 갱신.
- `wiki/log.md` — 추가 전용 작업 로그.
- `outputs/` — 생성된 리포트, 프레젠테이션, lint 결과.

## 페이지 유형 및 규칙

모든 위키 페이지는 YAML 프론트매터를 포함해야 합니다:

    ---
    title: 페이지 제목
    type: concept | entity | source-summary | comparison
    sources:
      - raw/papers/filename.md
    related:
      - "[[관련-개념]]"
    created: YYYY-MM-DD
    updated: YYYY-MM-DD
    confidence: high | medium | low
    ---

### 명명 규칙

- 파일명: kebab-case (예: attention-mechanism.md)
- 내부 참조: [[위키링크]] 형식 사용
- 소스 참조: 항상 raw/ 경로로 역추적 가능하게

## 워크플로우

### 수집 (Ingest)

1. raw/의 소스 문서 읽기
2. 사용자와 핵심 내용 논의
3. wiki/sources/[소스명].md 요약 생성
4. 필요에 따라 개념/엔티티 페이지 생성 또는 업데이트
5. wiki/index.md 갱신
6. wiki/log.md에 기록 추가

### 질의 (Query)

1. wiki/index.md를 읽어 관련 페이지 식별
2. 해당 페이지들을 읽고 답변 합성
3. [[위키링크]]로 출처 인용
4. 새롭고 가치 있는 답변이라면 새 위키 페이지로 저장 제안

### 검사 (Lint)

1. 모든 위키 페이지에서 모순 탐색
2. 고아 페이지 식별 (들어오는 링크 없음)
3. 언급됐지만 페이지 없는 개념 표시
4. 최신 소스에 의해 무효화된 주장 발견
5. 결과를 outputs/lint-YYYY-MM-DD.md에 저장

# 연구 위키: [주제]

## 프로젝트 구조

- `raw/` — 불변 원본 소스. 이 파일들은 절대 수정하지 않습니다.
- `wiki/` — LLM이 생성하고 관리하는 마크다운 페이지.
- `wiki/index.md` — 전체 콘텐츠 목록. 모든 작업 시 갱신.
- `wiki/log.md` — 추가 전용 작업 로그.
- `outputs/` — 생성된 리포트, 프레젠테이션, lint 결과.

## 페이지 유형 및 규칙

모든 위키 페이지는 YAML 프론트매터를 포함해야 합니다:

    ---
    title: 페이지 제목
    type: concept | entity | source-summary | comparison
    sources:
      - raw/papers/filename.md
    related:
      - "[[관련-개념]]"
    created: YYYY-MM-DD
    updated: YYYY-MM-DD
    confidence: high | medium | low
    ---

### 명명 규칙

- 파일명: kebab-case (예: attention-mechanism.md)
- 내부 참조: [[위키링크]] 형식 사용
- 소스 참조: 항상 raw/ 경로로 역추적 가능하게

## 워크플로우

### 수집 (Ingest)

1. raw/의 소스 문서 읽기
2. 사용자와 핵심 내용 논의
3. wiki/sources/[소스명].md 요약 생성
4. 필요에 따라 개념/엔티티 페이지 생성 또는 업데이트
5. wiki/index.md 갱신
6. wiki/log.md에 기록 추가

### 질의 (Query)

1. wiki/index.md를 읽어 관련 페이지 식별
2. 해당 페이지들을 읽고 답변 합성
3. [[위키링크]]로 출처 인용
4. 새롭고 가치 있는 답변이라면 새 위키 페이지로 저장 제안

### 검사 (Lint)

1. 모든 위키 페이지에서 모순 탐색
2. 고아 페이지 식별 (들어오는 링크 없음)
3. 언급됐지만 페이지 없는 개념 표시
4. 최신 소스에 의해 무효화된 주장 발견
5. 결과를 outputs/lint-YYYY-MM-DD.md에 저장

도메인에 맞게 커스터마이즈하시면 됩니다. 머신러닝 위키라면 논문 인용과 벤치마크 추적 규칙을 추가하고, 경쟁 정보 위키라면 신뢰도와 소스 신선도 규칙을 더하시면 됩니다.

4단계: 소스 추가 후 실행

cd ~/research/my-topic
claude

cd ~/research/my-topic
claude

> raw/articles/에 기사 3개를 추가했어. 모두 수집해서
> 위키 페이지 만들고 인덱스 업데이트해줘.

> raw/articles/에 기사 3개를 추가했어. 모두 수집해서
> 위키 페이지 만들고 인덱스 업데이트해줘.

Obsidian을 프론트엔드로 활용하기

wiki/ 디렉토리를 Obsidian 볼트로 열면 즉시 강력한 시각화 도구를 얻게 됩니다.

그래프 뷰: LLM이 생성한 [[위키링크]]가 모두 그래프의 연결로 시각화됩니다. 위키가 성장할수록 어떤 개념이 중심에 있는지, 어디에 공백이 있는지가 한눈에 드러납니다.

백링크: 특정 페이지를 참조하는 모든 다른 페이지를 즉시 확인할 수 있습니다. 수동으로 관계 목록을 관리할 필요가 없습니다.

Dataview 쿼리: Dataview 플러그인을 설치하면 위키 페이지 전체를 구조적으로 조회할 수 있습니다.

TABLE type, confidence, updated
FROM "concepts"
WHERE confidence = "low"
SORT updated ASC

TABLE type, confidence, updated
FROM "concepts"
WHERE confidence = "low"
SORT updated ASC

이 쿼리는 신뢰도가 낮은 지식—즉 추가 연구가 필요한 영역—을 표면으로 끌어올립니다.

QMD 검색: Shopify CEO인 Tobi Lutke가 만든 QMD는 마크다운 파일을 위한 로컬 검색 엔진입니다.

BM25와 벡터 검색을 혼합하고 LLM으로 재순위화합니다. Karpathy도 대형 위키 탐색에 권장하며, CLI와 MCP 서버 형태 모두 지원됩니다.

LLM 위키 vs RAG: 어떤 상황에서 무엇을 쓸까요

비교 항목	RAG	LLM 위키
상태	무상태 — 각 쿼리가 독립적	유상태 — 지식이 시간과 함께 축적
인프라	벡터 DB, 임베딩 파이프라인, 검색 로직	`.md` 파일 폴더 하나
교차 참조	쿼리마다 임시 생성	LLM이 수집 시 미리 구축
유지 관리	임베딩 업데이트, 인덱스 재구축	LLM이 수집마다 자동 업데이트
쿼리당 토큰 비용	높음*	낮음
추적성	청크 수준 (손실 발생 가능)	`raw/`까지 역추적 가능
최적 규모	기업 (수백만 문서)	개인/팀 (위키 10만 토큰 미만)
모순 탐지	탐지 불가 — 충돌 청크 공존	lint 작업으로 자동 탐지

RAG가 쿼리당 토큰 비용이 높은가?

저자는 RAG가 쿼리당 토큰 비용이 높다고 했지만, 꼭 그렇지만은 않은 것 같습니다.

LLM 위키는 말 그대로 LLM 모델을 써야하지만, RAG는 조회시에 Embedding 모델 위주로 사용되기 때문입니다.

또한 LLM 위키가 인덱스 및 요약본이 있어 전체 텍스트를 읽지 않아도 되어서 토큰 비용이 적다고 주장한 것 같지만, RAG도 OpenViking이나 Neo4j를 활용하면 요약본이나 태그를 활용하여 쿼리 비용을 낮출 수 있습니다.

RAG가 유리한 경우: 수백만 건의 문서가 있을 때 / 문서 변경이 잦아 위키 재수집이 비실용적일 때 / 초저지연 검색이 필요할 때 / 여러 팀이 다른 접근 권한으로 공유해야 할 때

LLM 위키가 유리한 경우: 소스 문서가 약 100~200개 미만일 때 / 각 수집이 향후 모든 쿼리를 향상시키는 복리 효과를 원할 때 / 모든 주장이 원본 소스로 추적 가능해야 할 때 / 폴더와 LLM 이외 인프라가 필요 없을 때

본질적으로 LLM 위키는 수동으로 구현한 추적 가능한 Graph RAG입니다. 그래프 데이터베이스, 엔티티 추출 파이프라인, 온톨로지 엔지니어링이 일절 필요 없습니다.

커뮤니티 구현체들

Karpathy 게시물 이후 일주일 만에 커뮤니티에서 다수의 구현체가 등장했습니다.

프로젝트	설명
llmwiki	문서 업로드 후 MCP로 Claude 연결해 위키 자동 생성
obsidian-wiki	Karpathy 패턴 기반 Obsidian 위키 구축 에이전트 프레임워크
second-brain	Obsidian용 LLM 기반 개인 지식 베이스
llm-wiki-compiler	마크다운 파일을 주제별 위키로 컴파일
CacheZero	`npm install` 하나로 패턴 구현
wiki-skills	Karpathy 패턴 구현을 위한 Claude Code 스킬 패키지
LLM Wiki v2	메모리 생애주기와 신뢰도 점수를 추가한 확장 패턴

실제 사용 결과

비즈니스 서적 3권(약 15만 5천 단어)에 패턴을 적용한 한 사용자는 챕터 수준의 세밀도로 210개의 개념 페이지와 약 4,600개의 교차 참조를 자동으로 생성했다고 보고했습니다.

특히 인상적이었던 점은 단순히 요약하는 것이 아니라, 사용자가 미처 발견하지 못했던 책들 간의 연결 패턴을 시스템이 스스로 식별해냈다는 것이었습니다.

LLM Wiki v2: 확장 패턴

개발자 rohitg00가 에이전트 메모리 시스템 구축 경험을 토대로 패턴을 확장했습니다. 주요 추가 기능은 다음과 같습니다.

메모리 생애주기: 신뢰도 점수, 대체 추적, 에빙하우스 망각 곡선 기반 보존 감소
통합 계층: 작업 메모리 → 에피소드 메모리 → 의미 메모리 → 절차 메모리
지식 그래프 구조: 유형화된 엔티티와 관계 카테고리 (“uses”, “depends on”, “contradicts”, “supersedes”)
멀티 에이전트 거버넌스: 병렬 에이전트를 위한 공유/사설 지식 범위

위키가 100~200페이지를 넘어서면 단순한 인덱스 탐색이 한계를 보이기 시작하는데, 이때 이러한 확장 기능이 유효해집니다.

지적 계보: Memex에서 LLM 위키로

Karpathy는 Gist에서 Vannevar Bush의 1945년 에세이 “As We May Think”를 명시적으로 언급합니다. 이 글에서 Bush는 Memex라는 가상의 기계 책상을 제안했습니다.

개인의 모든 책, 기록, 커뮤니케이션을 저장하고 연관 항목 사이에 탐색 “경로”를 만들 수 있는 장치였습니다.

Memex는 끝내 실현되지 못했습니다. 모든 교차 참조를 사람이 직접 만들어야 했기 때문입니다.

Bush는 지식 탐색자들이 경로를 직접 구축하는 미래를 상상했지만, 실제로 이것을 규모 있게 수행하는 사람은 없었습니다.

LLM 위키는 바로 이 유지 관리 문제를 해결합니다. LLM이 수집마다 자동으로 교차 참조를 생성하고 업데이트합니다.

인간은 무엇을 읽을지, 어떤 질문을 던질지에 집중할 수 있습니다.

Karpathy 사고의 진화

LLM 위키는 Karpathy가 인간-AI 협업에 대해 생각해온 세 번째 단계입니다.

바이브 코딩 (2025년 2월) — AI가 생성한 코드를 줄줄이 검토하지 않고 신뢰하고 결과를 테스트합니다.
에이전트 엔지니어링 (2026년 1월) — 인간이 직접 코드를 작성하는 대신 AI 에이전트를 조율합니다.
LLM 지식 베이스 (2026년 4월) — AI가 코드만이 아니라 지식 자체를 관리합니다. 인간은 작가가 아닌 큐레이터입니다.

각 단계마다 더 많은 인지 노동이 LLM으로 이전되며, 인간은 판단과 방향 설정에 집중하게 됩니다.

비판과 한계

패턴에 대한 비판도 존재합니다. Hacker News 토론에서 제기된 주요 우려 사항들입니다.

“단순 반복 작업 자체가 학습이다”

파일링, 교차 참조 생성, 요약—Karpathy가 LLM에 위임하는 이 작업들이 바로 깊은 이해가 형성되는 과정이라는 반론이 있습니다. 이것을 LLM에 맡기면 포괄적인 위키는 갖게 되지만, 그 내용을 실제로 내재화하지 못할 수 있다는 것입니다.

반론: 위키는 사고를 대체하는 것이 아닌 참조 시스템입니다. Karpathy 본인도 소스를 읽고, LLM과 핵심 내용을 논의하며, 무엇을 포함할지 직접 판단합니다. LLM은 물류를 처리할 뿐, 통찰을 생산하지는 않습니다.

컨텍스트 창 품질 저하

위키가 컨텍스트에 맞지 않을 정도로 커지면 품질이 떨어진다는 보고가 여러 차례 나왔습니다. 100만 토큰 이상의 컨텍스트 창이 있음에도 실제로는 20~30만 토큰 부근에서 성능 저하가 시작됩니다.

완화책: 바로 이 때문에 인덱스/탐색 패턴이 중요합니다. 전체 위키를 로드하는 대신, LLM이 index.md(수천 토큰)를 읽어 관련 페이지만 선별해 로드합니다. 계층적 탐색이 무차별 컨텍스트 적재를 우회합니다.

모델 붕괴 위험

LLM이 반복적으로 다시 쓰면서 정보가 점진적으로 저하될 수 있다는 우려입니다. 각 재작성이 시간이 지남에 따라 누적되는 미묘한 오류를 도입할 수 있습니다.

완화책: 불변 raw/ 레이어가 안전망입니다. 위키의 모든 주장은 raw/의 소스로 역추적 가능해야 하며, lint 작업이 드리프트를 확인하고, Git이 언제 주장이 변경됐는지 파악하기 위한 전체 이력을 제공합니다.

복잡성 한계

이러한 시스템이 특정 복잡도를 넘어서면 에이전트도, 개발자도 전체를 충분히 파악하지 못하게 되어 결국 붕괴한다는 경고도 있습니다.

완화책: 이것은 실질적인 제약입니다. 이 패턴은 50~200개 소스 규모의 개인/팀 지식에 가장 적합합니다. 그 이상으로 성장하면 LLM Wiki v2의 확장 기능(하이브리드 검색, 멀티 에이전트 거버넌스)이나 본격적인 RAG 파이프라인이 필요할 수 있습니다.

권장 도구 스택

도구	용도
Claude Code	주 LLM 에이전트
Obsidian	위키 프론트엔드 (그래프 뷰, 백링크, 검색)
QMD	마크다운 시맨틱 검색 (BM25 + 벡터 + LLM 재순위)
Obsidian Web Clipper	웹 기사를 마크다운으로 변환해 `raw/`에 저장
Dataview	위키 프론트매터 전체를 구조적으로 쿼리
Marp	위키 페이지를 프레젠테이션 슬라이드로 변환
Git	버전 관리 및 변경 사항 추적