2026년 최선의 로컬 AI 지식 베이스 아키텍처는 무엇입니까?

대부분의 사용자에게는 Obsidian + Smart Connections + Copilot for Obsidian + Ollama(채팅용 Llama 3.2 3B, 임베딩용 nomic-embed-text)가 권장됩니다. 16 GB Mac에서 약 50,000개 노트까지 확장됩니다. 문서가 많은 아카이브에는 AnythingLLM + Ollama 단일 앱(최대 약 100,000개 문서)을 사용하십시오. 엔지니어나 100,000개 이상 항목의 vault에는 캡처, 임베딩, 채팅 서비스를 분리한 Python + ChromaDB + Llama 3.2 3B 커스텀 스택을 구축하십시오. 하드웨어 최소 사양 16 GB RAM; 10,000개 항목부터 32 GB, 100,000개 이상부터 홈 서버. 캡처가 진정한 확장 병목입니다 — LLM을 최적화하기 전에 모바일 공유 시트, 웹 클리퍼, 이메일 전달을 설계하십시오.

홈/고급 로컬 LLM/로컬 AI로 개인 지식 베이스 구축하기: 2026 스택 가이드

Productivity & Knowledge Tools

로컬 AI로 개인 지식 베이스 구축하기: 2026 스택 가이드

최종 업데이트: 2026-05-08·15분 분량·Hans Kuepper 저 · PromptQuorum 창립자, 멀티 모델 AI 디스패치 도구 · PromptQuorum

언어 선택:

🇺🇸en 🇩🇪de 🇫🇷fr 🇯🇵ja 🇨🇳zh 🇪🇸es 🇧🇷pt 🇸🇦ar 🇰🇷ko

2026년 로컬 AI 지식 베이스는 5개 레이어 스택(캡처, 저장, 임베딩, 검색, 인터페이스)으로 이루어지며, 처음부터 설계하는 대신 세 가지 참조 아키텍처 중 하나를 선택해야 합니다. 매일 노트를 작성하고 vault 전체에서 시맨틱 검색을 원한다면 Obsidian + Smart Connections + Copilot for Obsidian + Ollama를 사용하십시오. 16 GB Mac M3 Pro 또는 동급 PC에서 약 50,000개 노트까지 깔끔하게 확장됩니다. 지식이 주로 문서(PDF, 내보내기, 웹 클립) 형태로 존재한다면 AnythingLLM + Ollama를 사용하십시오. 약 100,000개 문서까지 확장되고 캡처, RAG, 채팅을 하나의 앱으로 통합합니다. 항목이 100,000개를 초과하거나 다중 사용자 액세스 또는 특정 스키마 요구 사항이 있는 경우에만 Python + ChromaDB + Llama 3.2 3B 커스텀 스택을 구축하십시오 — 유지 관리 비용이 실제로 존재합니다. 세 가지 아키텍처 모두에서 진정한 병목은 캡처입니다. 지식의 대부분은 모바일에서 도착하며(웹 페이지, 스크린샷, 음성 메모, 전달된 이메일), 모바일 캡처 경로가 없는 스택은 검색 기능이 아무리 뛰어나도 먼지가 쌓입니다. 하드웨어 최소 사양: 16 GB RAM; 10,000개 항목 이상에서 32 GB 예산. 100,000개 항목 이상에서 임베딩을 홈 서버로 이동하십시오.

2026년에 로컬 AI 기반으로 구축한 개인 지식 베이스(PKB)는 다섯 가지 레이어로 구성됩니다: 캡처(웹 클리퍼, 이메일 전달, 모바일 공유 시트), 저장(Markdown vault 또는 문서 폴더), 임베딩(Ollama를 통한 로컬 모델), 검색(RAG), 인터페이스(채팅 또는 시맨틱 검색). 세 가지 아키텍처가 실제 사례의 약 95%를 커버합니다 — Obsidian 중심(노트 중심, 약 50,000개 항목까지 확장), AnythingLLM 중심(문서 중심, 약 100,000개 항목까지 확장), Python + ChromaDB 커스텀 스택(엔지니어 중심, 100만 개 이상 항목 확장). 하드웨어 최소 사양은 16 GB RAM 노트북이며, 10,000개 항목을 초과하면 32 GB를 계획하십시오. 가장 중요한 확장 결정은 LLM이 아니라 지식의 대부분이 도착하는 모바일에서 캡처 파이프라인이 일상적인 사용을 견딜 수 있는지 여부입니다.

핵심 요점

처음부터 설계하는 대신 세 가지 참조 아키텍처 중 하나를 선택하십시오. Obsidian 중심(노트 중심, ~50K 항목), AnythingLLM 중심(문서 중심, ~100K 항목), Python + ChromaDB 커스텀 스택(엔지니어 중심, 100만 개 이상). 아키텍처를 혼합하는 것은 거의 가치가 없습니다 — 통합 비용이 지배합니다.
로컬 AI PKB는 다섯 가지 레이어로 구성됩니다: 캡처, 저장, 임베딩, 검색, 인터페이스. 초보자의 실수는 대부분 LLM이 아닌 캡처 레이어에서 발생합니다. 항목이 모바일과 이메일에서 흐르지 않으면 아무리 스마트한 검색도 프로젝트를 구할 수 없습니다.
하드웨어 최소 사양: 16 GB RAM. 그 이하에서는 임베딩 모델 또는 채팅 모델 중 하나만 실행해야 합니다 — 둘 다는 불가능합니다. 16 GB에서 Llama 3.2 3B + nomic-embed-text를 동시에 실행할 수 있습니다. 32 GB에서 Qwen3 7B로 업그레이드하거나 여러 채팅 세션을 실행할 수 있습니다. 100,000개 항목 이상에서 임베딩을 홈 서버로 이동하십시오.
2026년 권장 모델: 채팅 — Llama 3.2 3B(기본값), Phi-4 Mini(8 GB 시스템), Qwen3 7B(32 GB+ 고품질); 임베딩 — nomic-embed-text(768차원, 빠름), mxbai-embed-large(1024차원, 더 정확), bge-m3(다국어).
캡처가 확장 병목이며 검색이 아닙니다. 지식 항목의 대부분은 모바일(웹 클립, 스크린샷, 음성 메모, 전달된 이메일)에서 도착합니다. LLM을 조정하기 전에 모바일 공유 시트 → vault 경로를 설계하십시오. iOS Shortcuts → Obsidian / Working Copy / a-Shell이 세 가지 실행 가능한 iOS 경로입니다.
동기화 방법이 모바일에서 무엇이 작동하는지를 결정합니다. Obsidian Sync는 임베딩 바이너리 인덱스를 깔끔하게 처리합니다; iCloud Drive는 플랫폼 간에 손상시킵니다; Git은 .gitignore 규율과 기기별 재인덱싱이 필요합니다. 플러그인보다 먼저 동기화를 선택하십시오.
백업은 선택이 아닙니다. 세 가지 레이어: vault 스냅샷(Time Machine, Backblaze, restic), 일반 텍스트 콘텐츠의 Git 기록, 깔끔한 재구성 경로로서의 분기별 임베딩 + 메타데이터 내보내기. 임베딩은 재생성 가능하지만 비용이 많이 듭니다 — vault가 10,000개 항목을 초과하면 함께 백업하십시오.

빠른 정보

다루는 아키텍처: Obsidian 중심, AnythingLLM 중심, Python + ChromaDB 커스텀 스택.
LLM 백엔드: Ollama(권장) — http://localhost:11434의 로컬 엔드포인트 뒤에서 채팅 및 임베딩 모델 실행.
2026년 권장 채팅 모델: Llama 3.2 3B(16 GB 시스템), Phi-4 Mini(8 GB), Qwen3 7B(32 GB+).
2026년 권장 임베딩 모델: nomic-embed-text(768차원, 빠름), mxbai-embed-large(1024차원, 정확), bge-m3(다국어).
항목 수 목표: Obsidian 약 50,000개 노트, AnythingLLM 약 100,000개 문서, Python + ChromaDB 커스텀 스택 100만 개 이상.
하드웨어 최소 사양: 16 GB RAM 노트북. 10,000개 항목 이상: 32 GB 권장. 100,000개 항목 이상: 64 GB 홈 서버.
모바일 캡처 경로(iOS): Shortcuts → Obsidian, Shortcuts → Working Copy(Git), Shortcuts → a-Shell. Android: Tasker 또는 HTTP Shortcuts.

어떤 아키텍처를 구축할까?

가장 강력하게 들리는 아키텍처가 아니라 지식이 이미 도착하는 방식과 일치하는 아키텍처를 선택하십시오. 이미 매일 노트를 작성한다면 Obsidian 중심으로 구축하십시오. 지식이 주로 문서(PDF, 내보내기, 웹 클립) 형태라면 AnythingLLM 중심으로 구축하십시오. 진정으로 100,000개 이상의 항목이 있거나 다중 사용자 액세스가 필요한 경우에만 Python + ChromaDB 커스텀 스택을 구축하십시오 — 유지 관리 비용이 실제로 존재하며 그 임계값 이하에서는 거의 가치가 없습니다.

📍 한 문장으로

노트 중심 워크플로우는 Obsidian + Smart Connections + Copilot + Ollama를 선택하고, 문서 중심 아카이브는 AnythingLLM + Ollama를 선택하며, 100K 이상 항목을 가진 엔지니어는 Python + ChromaDB 커스텀 스택을 선택합니다.

💬 쉽게 말하면

세 가지 경로, 하나의 목적지. 이미 노트 앱 안에서 생활한다면 Obsidian이 기존 습관을 AI 기능으로 감쌉니다. 주로 PDF와 웹 페이지를 축적한다면 AnythingLLM은 수집, 인덱싱, 채팅을 하나로 처리하는 단일 앱입니다. 코드를 작성하고 완전한 제어를 원한다면 Python + ChromaDB로 원하는 것을 정확히 구축할 수 있습니다 — 하지만 유지 관리는 직접 해야 합니다. 아키텍처에 맞추어 습관을 바꾸지 말고 기존 워크플로우와 일치하는 경로를 선택하십시오.

결정: 어떤 PKB 아키텍처?

Use a local LLM if:

•이미 Obsidian을 사용하거나 Markdown 파일을 사용한 노트 중심 워크플로우를 원함 → Obsidian 중심
•지식이 주로 PDF, 내보내기, 웹 클립, 이메일 파일임 → AnythingLLM 중심
•100,000개 이상의 항목, 커스텀 스키마 필요 또는 다중 사용자 액세스 → Python + ChromaDB 커스텀 스택
•캡처, 저장, RAG, 채팅을 관리하는 단일 앱을 원함 → AnythingLLM 중심
•청킹, 검색, 재순위 결정에 완전한 제어를 원함 → Python + ChromaDB 커스텀 스택

Use a cloud model if:

•모든 쿼리에 GPT-5.5 수준 추론이 필요하고 아카이브가 작음 → Notion AI 또는 커스텀 GPT를 사용한 ChatGPT(로컬 스택은 종합에서 약 70% 수준)
•16 GB+ RAM 또는 홈 서버가 없음 → 클라우드 PKB SaaS(Mem, Reflect)
•팀에 동시 다중 사용자 액세스가 필요하고 서비스를 호스팅하고 싶지 않음 → 클라우드 동급

Quick decision:

→노트 중심 사용자의 기본값: Obsidian + Smart Connections + Copilot + Ollama
→문서 중심 사용자의 기본값: AnythingLLM + Ollama
→100K 이상 항목을 가진 엔지니어: Python + ChromaDB 커스텀 스택 + Llama 3.2 3B

💡Tip: 단지 더 강력하게 들린다는 이유로 Python 커스텀 스택으로 시작하지 마십시오. 먼저 Obsidian 또는 AnythingLLM 중심으로 구축하고 두 달간 실행하면서 워크플로우와 맞지 않는 레이어를 찾은 다음, 그 레이어를 커스텀 구성 요소로 교체하는 것을 고려하십시오. "Python으로 처음부터" 시작하고 6개월 이상 지속된 모든 PKB 프로젝트는 결국 Obsidian 또는 AnythingLLM 형태의 디자인으로 수렴했습니다.

아키텍처 비교표

세 가지 참조 아키텍처는 대부분의 구축자에게 중요한 다섯 가지 축에서 차이가 납니다: 설정 복잡도, 항목 수 한계, 모바일 동기화, 캡처 유연성, 유지 관리 부담. 설정 복잡도는 제어력에 대략 선형적으로 증가하며 유지 관리 비용도 마찬가지입니다.

📍 한 문장으로

Obsidian은 약 50K 항목에서 중간 복잡도, AnythingLLM은 약 100K 항목에서 낮은 복잡도, Python + ChromaDB 커스텀 스택은 높은 복잡도이지만 100만 개 이상으로 확장됩니다.

💬 쉽게 말하면

AnythingLLM은 설정이 가장 쉽고 두 가지 "즉시 사용 가능한" 옵션 중 더 멀리 확장됩니다 — 하지만 문서 구성 방식에 대해 독단적입니다. Obsidian은 가장 표현력 있는 노트 작성 레이어와 활발한 플러그인 생태계를 제공하며, 설정 비용이 약간 더 높습니다. Python 커스텀은 한계가 없지만 모든 것을 직접 유지 관리해야 합니다: 청킹, 재순위, 중복 제거, 동기화, 백업. 항목 수만이 아니라 유지 관리 허용 수준으로 선택하십시오.

아키텍처	복잡도	최대 항목	모바일 동기화	적합 대상
Obsidian 중심	중간	~50,000개	예(Obsidian Sync; iCloud / Git 조건부)	매일 글쓰기 습관이 있는 노트 중심 사용자
AnythingLLM 중심	낮음	~100,000개	제한적(LAN / Tailscale을 통한 모바일 웹 UI)	문서 중심 PKB(PDF, 내보내기, 웹 클립)
Python + ChromaDB 커스텀	높음	100만 개 이상	수동(자체 API + 모바일 클라이언트 구축)	완전한 제어 + 다중 사용자를 원하는 엔지니어

💡Tip: 모바일 동기화는 가장 과소평가된 비교 축입니다. AnythingLLM은 기술적으로 Obsidian보다 설정이 쉽지만 모바일에서는 "Safari에서 LAN 웹 UI 열기"를 의미합니다 — 네이티브 경험이 아닙니다. Obsidian Mobile은 Obsidian Sync와 결합하면 오프라인 읽기가 가능한 거의 네이티브 iOS / Android 앱을 제공합니다. 모바일 캡처와 읽기가 중요하다면 표가 제안하는 것보다 Obsidian에 더 높은 가중치를 두십시오.

로컬 AI PKB의 다섯 가지 레이어

모든 로컬 AI PKB는 아키텍처와 관계없이 동일한 다섯 가지 레이어를 가집니다: 캡처, 저장, 임베딩, 검색, 인터페이스. 실패는 대개 한 레이어가 다른 레이어와 일치하지 않을 때 발생합니다 — 가장 일반적으로는, 아무도 사용하지 않는 손상된 캡처 파이프라인과 쌍을 이룬 정교한 검색 레이어입니다.

1
캡처
Why it matters: 항목이 시스템에 들어오는 방법입니다. 웹 클리퍼, 이메일 전달, 모바일 공유 시트, 음성 메모, 수동 붙여넣기. 초보자 구축에서 가장 많이 생략되는 레이어이며 시스템이 일상적인 사용을 견딜 수 있는지를 결정하는 레이어입니다. 모바일에서 캡처하는 데 5초 이상 걸리면 시스템에 먼지가 쌓입니다.
2
저장
Why it matters: 항목이 디스크에 저장되는 곳입니다. Markdown vault(Obsidian, Logseq), 문서 폴더 + 데이터베이스(AnythingLLM), 파일 시스템 + 매니페스트(Python 커스텀). 도구 변경에도 살아남는 저장 형식을 선택하십시오 — 일반 텍스트 Markdown이 가장 이식 가능하고 바이너리 데이터베이스가 가장 이식 가능하지 않습니다.
3
임베딩
Why it matters: 시맨틱 검색에 사용되는 항목의 벡터 표현입니다. 로컬 모델(Ollama를 통한 nomic-embed-text 또는 mxbai-embed-large)에 의해 생성됩니다. 임베딩 모델은 나중에 변경할 수 있지만 마이그레이션 비용은 "모든 것을 다시 임베딩"입니다 — 한 번 선택하고 유지하십시오.
4
검색
Why it matters: 쿼리 시간에 항목을 찾는 방법입니다. 상위-k 벡터 검색, 선택적 재순위, 선택적 메타데이터 필터(태그, 날짜, 출처). 순진한 상위-5와 조정된 상위-20-재순위의 품질 차이는 "유용함"과 "마법 같음"의 차이입니다.
5
인터페이스
Why it matters: 쿼리하고 읽는 방법입니다. 사이드바(Smart Connections), 채팅(Copilot, AnythingLLM), CLI(Python 커스텀), API. 대부분의 사용자는 기본적으로 채팅을 사용하지만 "관련 노트" 사이드바는 채팅이 할 수 없는 잊혀진 자료를 보여줍니다 — 무엇을 물어봐야 할지 모르기 때문입니다.

⚠️Warning: 실패하는 일반적인 구축 패턴: 가장 강력한 검색(재순위를 사용한 커스텀 하이브리드 검색)과 가장 스마트한 채팅 모델(Qwen3 7B)을 선택하고 캡처를 무시합니다. 3주 후 vault에 47개 항목이 있는데 모바일에서 아무것도 흐르지 않기 때문입니다. 수정은 항상 같습니다: 검색 단순화, 채팅 단순화, 캡처 수정, 그리고 가치의 80%는 항목이 시스템 안에 있다는 것에서 온다는 것을 받아들이십시오.

아키텍처 A: Obsidian 중심

Obsidian + Smart Connections + Copilot for Obsidian + Ollama는 2026년 노트 중심 워크플로우의 기본 아키텍처입니다. 16 GB Mac M3 Pro 또는 동급 PC에서 약 50,000개 노트까지 깔끔하게 확장되고, Obsidian Mobile을 통한 모바일 읽기를 지원하며, 미래의 어떤 도구로도 가져갈 수 있는 일반 텍스트 Markdown으로 모든 것을 유지합니다.

저장: 폴더("vault") 안의 Markdown 파일. 일반 텍스트, 단순 폴더, 데이터베이스 없음. 도구 마이그레이션에서 살아남습니다.
캡처: Obsidian Web Clipper(브라우저 확장), Obsidian Mobile 공유 시트(iOS / Android), Mailspike 또는 커스텀 IFTTT 레시피를 통한 이메일-to-Obsidian, 수동 붙여넣기.
임베딩: Smart Connections 플러그인 → http://localhost:11434/api/embeddings의 Ollama → nomic-embed-text(기본값) 또는 mxbai-embed-large(더 정확). 인덱스는 vault 내 .smart-env/에 저장됩니다.
검색: Smart Connections 사이드바(관련 노트 보기) + Copilot for Obsidian의 Vault QA 모드(채팅 쿼리를 위한 vault 전체 RAG). 둘 다 임베딩 인덱스 위에서 검색합니다.
인터페이스: Smart Connections 사이드바(수동적 발견) + Copilot 채팅 패널(능동적 쿼리) + Text Generator 템플릿(일일 요약과 같은 반복 가능한 워크플로우).
설정 시간: 약 30분(Ollama 설치, 모델 다운로드, 세 가지 플러그인 설치, 엔드포인트 구성, 초기 인덱스 구축 대기).
하드웨어: 최소 16 GB RAM(Llama 3.2 3B + nomic-embed-text 동시 실행). 10,000개 노트 이상에서 32 GB 권장. SSD 강력 권장 — 인덱스 재구성은 HDD에서 I/O 바운드입니다.
항목 한계: 실제로 약 50,000개 노트; 서브-초 증분 재인덱싱으로 20,000개까지 테스트됨. 50K+ 노트에서 초기 인덱스는 4-8시간이 걸리며 서브-vault를 고려해야 합니다.
적합 대상: 매일 글쓰기 습관이 있고 Markdown-first 선호도를 가지며 잊혀진 노트를 보여주는 "생각 동반자" 사이드바를 원하는 사용자.
부적합 대상: 지식이 주로 PDF와 웹 클립인 사용자(AnythingLLM 중심 사용); 올인원 단일 앱을 원하는 사용자(Obsidian 중심은 "Obsidian + 3개 플러그인 + Ollama"입니다).

💡Tip: 이 아키텍처의 플러그인 레이어 심층 분석(5개 플러그인, 설정 단계, vault 확장 수치)은 Obsidian + 로컬 LLM 플러그인 가이드를 참조하십시오. 이 페이지는 아키텍처를 다루고 플러그인 가이드는 설정을 다룹니다.

아키텍처 B: AnythingLLM 중심

AnythingLLM + Ollama는 올인원 옵션입니다: 캡처, 저장, RAG, 채팅이 단일 데스크탑 또는 자체 호스팅 앱에 통합되어 있습니다. 약 100,000개 문서(PDF, 웹 클립, 내보내기 혼합)까지 확장되며 지식이 노트보다 주로 문서 형태로 도착할 때 올바른 선택입니다.

저장: AnythingLLM 내부 데이터베이스(기본값은 SQLite; 다중 사용자 자체 호스팅에는 Postgres). 문서는 UI를 통해 수집됩니다; 원본은 동기화하는 폴더에도 남을 수 있습니다.
캡처: 앱 내 업로드(workspace에 PDF/파일 드래그), 웹 페이지용 브라우저 확장, 프로그래밍 방식 수집을 위한 공개 API(POST /api/v1/document/upload), 공식 통합 또는 커스텀 릴레이를 통한 이메일 전달.
임베딩: AnythingLLM은 구성한 임베딩 공급자를 사용합니다 — "Ollama" 선택 → http://localhost:11434 엔드포인트 → nomic-embed-text 모델. 임베딩은 내장 벡터 스토어(기본값은 LanceDB; ChromaDB / Pinecone 선택 가능)에 저장됩니다.
검색: workspace 전체 RAG. 구성 가능한 청크 크기, 상위-k 검색, 선택적 재순위. 여러 workspace를 통해 주제별 파티셔닝 가능(예: "업무", "읽기", "프로젝트").
인터페이스: AnythingLLM 웹 UI(데스크탑 및 모바일 브라우저에서 작동), 커스텀 프론트엔드용 공개 API, 다른 도구를 PKB에 연결하기 위한 OpenAI 호환 엔드포인트.
설정 시간: 약 15분(AnythingLLM Desktop 또는 Docker 설치, Ollama 연결, 문서 드래그).
하드웨어: 최소 16 GB RAM. 10,000개 문서 이상에서 32 GB 권장. AnythingLLM은 동일한 항목 수에서 Obsidian + 플러그인보다 메모리 효율적입니다 — 두 개가 아닌 단일 프로세스이기 때문입니다.
항목 한계: 단일 workspace에서 약 100,000개 문서; 검색 지연 시간을 약 1초 미만으로 유지하려면 50K에서 여러 workspace로 파티셔닝하십시오.
적합 대상: PDF가 많은 아카이브, 웹 클립 중심 캡처, 플러그인 스택보다 단일 앱을 선호하는 사용자. 또한 공유 PKB를 자체 호스팅하는 소규모 팀에 적합합니다.
부적합 대상: 노트 중심 글쓰기 표면을 원하는 사용자(Obsidian); 일반 텍스트 Markdown으로 저장소를 소유하고 싶은 사용자(AnythingLLM 벡터 스토어는 내부적입니다).

💡Tip: 여기서 사용하는 RAG 레이어의 단계별 설정(Ollama + AnythingLLM, 수집, 청킹 조정)은 30분 만에 PDF에서 로컬 RAG 설정 튜토리얼을 참조하십시오. 1,000개 이상 PDF로 RAG를 확장하는 방법은 1000개 PDF와 로컬로 채팅하기를 참조하십시오.

아키텍처 C: Python + ChromaDB 커스텀

Python + ChromaDB + Ollama 커스텀 스택은 진정으로 100,000개 이상의 항목, 다중 사용자 필요성, 또는 표준 도구로는 모델링할 수 없는 특정 스키마 요구 사항이 있는 경우에만 올바른 선택입니다. 유지 관리 비용이 실제로 존재합니다: 청킹, 중복 제거, 재순위, 동기화, 백업 — 모두 직접 관리해야 합니다.

ChromaDB 수집(Python 스키마)

“import chromadb, ollama, pathlib client = chromadb.PersistentClient(path="./chroma") coll = client.get_or_create_collection("kb") for p in pathlib.Path("vault").rglob("*.md"): text = p.read_text() emb = ollama.embeddings(model="nomic-embed-text", prompt=text)["embedding"] coll.upsert(ids=[str(p)], embeddings=[emb], documents=[text], metadatas=[{"source": str(p)}])”

재순위를 사용한 쿼리(스키마)

“q = "로컬 RAG 동기화에 대해 무엇을 작성했나요?" q_emb = ollama.embeddings(model="nomic-embed-text", prompt=q)["embedding"] hits = coll.query(query_embeddings=[q_emb], n_results=20) # pass hits["documents"] through a re-ranker, keep top 5 # send top 5 + question to Llama 3.2 3B via Ollama chat endpoint”

저장: 파일 시스템(출처별 폴더: notes/, pdfs/, web/, email/) + 메타데이터 매니페스트(SQLite 또는 JSONL). 검색 레이어를 다시 수집하지 않고도 변경할 수 있도록 소스 파일은 개방형 형식으로 유지됩니다.
캡처: 웹훅으로 트리거된 스크립트(웹 클리퍼 → HTTP 엔드포인트 → 파일 쓰기), 이메일 전달 → IMAP 폴러 → 파일 쓰기, 모바일 공유 시트 → Tailscale 엔드포인트 → 파일 쓰기. 각 캡처 경로는 소규모 Python 서비스입니다.
임베딩: ChromaDB(로컬 모드, 디스크에 지속) + OpenAI 호환 엔드포인트를 통한 Ollama 임베딩. watchdog 프로세스를 통한 파일 변경 시 재임베딩. ChromaDB는 HNSW 인덱싱으로 단일 머신에서 수백만 개의 벡터로 확장됩니다.
검색: ChromaDB 상위-k 유사도 + 재순위기(BGE Re-ranker 또는 로컬 Cohere 동급) + 메타데이터 필터(날짜 범위, 태그, 출처). 정확한 용어 매칭을 위한 청크의 BM25를 사용한 선택적 하이브리드 검색.
인터페이스: 소규모 FastAPI 서비스를 /v1/chat/completions OpenAI 호환 엔드포인트로 노출하거나, Streamlit / Gradio UI, CLI, 또는 세 가지 모두. 코드 없이 세련된 채팅 경험을 위해 앞에 Open WebUI를 두십시오.
설정 시간: 기능하는 v1에 약 1일; 데이터에 대한 청킹, 검색 품질, 캡처 파이프라인 조정에 약 2주 반복.
하드웨어: 개발용 32 GB RAM 노트북; 임베딩 서비스가 노트북과 경쟁하지 않도록 100,000개 이상 항목에서 64 GB RAM 홈 서버. 채팅 성능을 위해 500K 항목 이상에서 전용 GPU(RTX 4060 이상) 고려.
항목 한계: HNSW + 샤딩으로 실제로 100만 개 이상; 병목이 검색에서 캡처 파이프라인 신뢰성과 스키마 변경 시 재임베딩 비용으로 이동합니다.
적합 대상: 스택을 소유하고 싶은 엔지니어, 커스텀 스키마를 가진 팀(예: "각 항목에는 신뢰도 점수, 출처, 저자가 있음"), 또는 Obsidian이나 AnythingLLM의 엄격한 한계(각각 50K와 100K)에 도달한 사용자.
부적합 대상: 비-엔지니어; 유지 관리 비용을 과소평가하는 사람; 표준 옵션이 이미 사용 사례를 커버하는 사용자.

⚠️Warning: 커스텀 구축에서 가장 일반적인 실패 패턴: 스키마가 안정적이지 않아 모든 코드 변경 시 전체 아카이브를 다시 임베딩합니다. 약 5,000개 항목을 수집하기 전에 임베딩 모델 + 청크 크기를 고정하십시오. nomic-embed-text 768차원에서 mxbai-embed-large 1024차원으로 100K 항목 마이그레이션하는 데 몇 시간의 컴퓨팅이 걸리고 ChromaDB 컬렉션이 손상됩니다 — 차원을 혼합할 수 없습니다.

캡처 파이프라인: 웹, 이메일, 모바일, 음성

캡처 레이어는 PKB가 일상적인 사용을 견딜 수 있는지를 결정합니다. 지식의 대부분은 데스크탑 밖에서 도착합니다 — 모바일에서, 이메일에서, 음성 메모에서 — 먼저 데스크탑 앱을 열어야 하는 캡처 파이프라인은 피해지는 파이프라인입니다. 네 가지 주요 흐름을 위해 구축하고 항목의 80%가 모바일에서 도착할 것이라는 것을 받아들이십시오.

웹 클리퍼(데스크탑 + 모바일): Obsidian Web Clipper, AnythingLLM 브라우저 확장, 또는 현재 페이지를 캡처 엔드포인트로 POST하는 커스텀 북마크릿. 모바일 공유 시트 → 웹 클리퍼 확장 → vault.
이메일 전달: 전용 주소(예: kb@yourdomain.com) + IMAP 폴러 → 파일 쓰기. 보관하려는 이메일을 전달하면 폴러가 수집을 처리합니다. 검색에서 출처별 필터링을 위해 파일 이름에 출처 접두사를 사용하십시오.
모바일 공유 시트: 가장 많이 사용되는 캡처 경로. iOS 공유 → Obsidian(Markdown 파일 쓰기), iOS 공유 → Working Copy(Git에 커밋), iOS 공유 → 커스텀 Shortcut(캡처 API로 POST). Android: HTTP Shortcuts 또는 Tasker.
음성 메모: AudioPen 스타일 캡처는 2026년에 점점 보편화되고 있습니다. 전화로 녹음 → Whisper.cpp 또는 자체 호스팅 Whisper 서비스를 통해 로컬로 전사 → Markdown 파일로 전사 내용 쓰기 → 임베딩.
수동 붙여넣기: 폴백. 항상 작동하지만 절대 확장되지 않습니다. 롱테일 용도로 사용하십시오.
스크린샷 OCR: 스크린샷은 손실 캡처 형식입니다. iOS에서 Apple Live Text 또는 로컬 OCR 파이프라인(Tesseract, Apple Vision, EasyOCR)을 사용하여 텍스트를 추출하고 이미지와 추출된 텍스트가 있는 Markdown 파일을 쓰십시오.

💡Tip: 파이프라인을 설계하기 전에 기존 캡처 습관을 감사하십시오. 이미 저장하는 것을 살펴보십시오: 브라우저 북마크, 스크린샷, 전달된 이메일, 음성 메모. PKB 캡처 레이어는 그러한 기존 흐름을 반영해야 합니다 — 스크린샷을 지속적으로 찍는다면 OCR 경로를 구축하고, 이미 이메일을 자신에게 전달한다면 이메일 전달을 구축하십시오. 새로운 습관을 추가하는 것("이제 모든 기사를 수동으로 KB에 복사 붙여넣기할 것이다")은 결코 작동하지 않습니다.

모바일 캡처: iOS Shortcuts, Working Copy, a-Shell

iOS에는 2026년 로컬 AI PKB로의 세 가지 실행 가능한 캡처 경로가 있습니다: Shortcuts → Obsidian, Shortcuts → Working Copy(Git), Shortcuts → a-Shell(스크립트 기반). 각각은 세 가지 참조 아키텍처 중 하나와 자연스럽게 결합됩니다. 전반적인 아키텍처의 동기화 모델과 일치하는 경로를 선택하십시오.

Shortcuts → Obsidian(Obsidian 중심): Obsidian "노트에 추가" Shortcut이 캡처된 콘텐츠를 vault에 직접 씁니다. Obsidian Sync(유료, 권장) 또는 iCloud Drive(무료, 조건부)를 통한 동기화. 노트 중심 워크플로우에 적합합니다.
Shortcuts → Working Copy(Git): 캡처된 콘텐츠가 iPhone의 Working Copy 저장소에 쓰여진 다음 자동으로 커밋되고 푸시됩니다. 데스크탑이 풀합니다. 무료, 견고, 모든 Markdown vault와 작동합니다. 참고: Working Copy는 유료입니다(일회성 결제 약 $20). Git 동기화 vault에 적합합니다.
Shortcuts → a-Shell: a-Shell은 스크립트를 실행하는 무료 iOS 터미널입니다. 캡처된 텍스트를 a-Shell 스크립트로 파이프하는 Shortcut을 구축하면 파일을 쓰고 git을 통해 커밋하거나, Tailscale을 통해 rsync로 동기화하거나, 커스텀 캡처 엔드포인트로 업로드합니다. 엔지니어가 구축한 커스텀 아키텍처에 적합합니다.
Android 동급: iOS의 Working Copy 경로와 동급인 Tasker + Termux + Git. 커스텀 엔드포인트 경로용 HTTP Shortcuts. Obsidian 경로용 Obsidian Mobile 공유 시트.
지연 시간 예산: 모바일 캡처는 단 대 단으로 5초 미만(공유 시트 → 파일 쓰기 / 커밋 / 업로드)에 완료되어야 합니다. 더 느리면 사용자가 앱을 한 번 열고 다시는 열지 않습니다.
오프라인 캡처: 세 가지 iOS 경로 모두 오프라인에서 대기열을 지원합니다(Shortcuts는 대기열, Working Copy는 커밋 대기열, a-Shell 스크립트는 로컬에 쓰고 나중에 동기화). 비행, 대중교통, 시골 지역에서의 캡처에 필수적입니다.

⚠️Warning: 데스크탑이 온라인 상태여야 하는 모바일 캡처 경로를 구축하지 마십시오(예: 노트북이 깨어 있을 때만 액세스 가능한 Tailscale로 보호된 엔드포인트로 POST). 업무 회의 중, 노트북이 절전 모드일 때, 밤에 캡처를 잃게 됩니다. 항상 켜져 있는 홈 서버 / NAS에서 캡처 엔드포인트를 실행하거나, 오프라인에서 버퍼링되는 eventually-consistent 스토어(Obsidian Sync, Git, iCloud)에 쓰십시오.

확장: 1K, 10K, 100K 항목

로컬 AI PKB 확장에는 세 가지 체제가 있습니다: 1,000개 항목 미만에서는 모든 현대 노트북에서 모든 것이 빠릅니다; 1,000~10,000개 항목 사이에서는 임베딩 인덱스가 관리해야 할 실제 아티팩트가 됩니다; 10,000개 항목을 초과하면 하드웨어가 병목이 되고 캡처 파이프라인 신뢰성이 결과를 지배합니다. 아래 실제 수치는 nomic-embed-text와 Llama 3.2 3B를 사용하는 Mac M3 Pro / RTX 4060 PC를 가정합니다.

항목 수	권장 아키텍처	초기 임베딩 시간	하드웨어	참고
1,000개 항목	세 가지 중 하나	약 2분	16 GB RAM 노트북	모든 것이 즉각적으로 느껴집니다. 아키텍처 선택은 순수하게 워크플로우 적합성 때문입니다.
10,000개 항목	Obsidian 또는 AnythingLLM	약 25분	16 GB RAM 노트북(32 GB 권장)	임베딩 인덱스 약 150-250 MB. 편집 시 재임베딩 시간 서브-초. 대부분의 지식 근로자에게 최적 지점.
50,000개 항목	AnythingLLM 또는 Python 커스텀	약 3시간	32 GB RAM 노트북 또는 홈 서버	초기 인덱스는 야간에 실행됩니다. 이 시점부터 서브-vault / workspace 계획. 임베딩 디스크 사용량 약 1.5-2 GB.
100,000개 항목	AnythingLLM(다중 workspace) 또는 Python 커스텀	6-8시간	최소 32 GB RAM; 홈 서버 선호	임베딩을 전용 홈 서버로 이동하십시오. 캡처 파이프라인 신뢰성이 이제 주요 실패 모드이며 검색이 아닙니다.
500,000개 항목 이상	Python + ChromaDB 커스텀	24시간 이상	64 GB RAM + 전용 GPU 홈 서버	샤딩, 중복 제거, 증분 재임베딩 파이프라인이 필요해집니다. 표준 도구는 더 이상 맞지 않습니다.

💡Tip: 초기 임베딩 비용은 일회성 청구입니다. 첫 번째 인덱스 이후 변경된 항목만 재임베딩됩니다 — 일반적으로 100K 항목에서도 저장 시 1초 미만. 처음의 느림은 실제이지만 반복적이지 않습니다. 충전된 머신에서 야간에 초기 인덱스를 실행하고 잊어버리십시오.

백업, 버전 관리, 다중 기기 동기화

로컬 AI PKB에는 세 가지 백업 레이어가 필요합니다: vault 스냅샷(Time Machine, Backblaze, restic), 일반 텍스트 콘텐츠의 Git 기록, 깔끔한 재구성을 위한 분기별 임베딩 및 메타데이터 내보내기. 임베딩은 기술적으로 재생성 가능하지만 100K+ 항목에서 재생성에는 몇 시간이 걸립니다 — 함께 백업하십시오.

vault 스냅샷(파일 시스템 레벨): Time Machine(macOS) 또는 restic(Linux) 매 24시간. 외부 저장을 위한 Backblaze 또는 rsync.net. 임베딩을 포함한 모든 것을 캡처합니다.
Git 기록(콘텐츠만): 일반 텍스트 Markdown 파일을 Git 저장소에 커밋(로컬 + 비공개 GitHub / Gitea). .smart-env/, vector_store/, 기타 바이너리 인덱스 폴더를 .gitignore에 추가하십시오. Git은 노트별 버전 기록을 제공하고; vault 스냅샷은 전체 시스템 롤백을 제공합니다.
임베딩 내보내기(분기별): 벡터 스토어를 이식 가능한 형식으로 내보내십시오(ChromaDB → parquet, Smart Connections → JSON dump, AnythingLLM → 내장 내보내기). 외부 저장소에 마지막 두 번의 내보내기를 저장하십시오. vault 스냅샷이 실패하거나 임베딩 인덱스가 손상된 경우 이것이 빠른 재구성 경로입니다.
다중 기기 동기화 — Obsidian 중심: Obsidian Sync는 일반 텍스트 + 바이너리 인덱스를 깔끔하게 처리합니다(종단 간 암호화). iCloud Drive는 일반 텍스트에서는 작동하지만 플랫폼 간 바이너리 인덱스를 손상시킵니다. Working Copy / Termux를 통한 Git은 일반 텍스트 전용으로 작동합니다 — 기기별 재인덱싱.
다중 기기 동기화 — AnythingLLM 중심: 홈 서버에서 Docker 컨테이너로 AnythingLLM을 실행하십시오. 모든 기기는 LAN 또는 Tailscale을 통해 동일한 인스턴스에 연결됩니다. 클라이언트 측 동기화가 필요 없습니다.
다중 기기 동기화 — Python 커스텀: 구축하는 아키텍처가 이것을 결정합니다. 대부분의 구축은 중앙 API 서비스(홈 서버의 FastAPI)를 사용하고 클라이언트는 캡처를 POST하고 쿼리를 GET합니다. Tailscale이 네트워크 레이어를 제공합니다.
새 컴퓨터로 마이그레이션: vault 스냅샷 복원 → Ollama 설치 및 동일한 모델 다운로드 → Obsidian / AnythingLLM / Python 커스텀 스택 설치 → 임베딩 인덱서 재시작. Obsidian Sync 또는 자체 호스팅 AnythingLLM을 사용하면 마이그레이션은 "클라이언트 설치 및 로그인"입니다 — 수동 복원이 필요 없습니다. 그것 없이는 10K 항목 vault에 약 30분, 50K에 약 2시간, 임베딩 내보내기 단계를 생략했다면 100K 이상에는 밤새 계산하십시오.
선택적 공유: vault의 일부를 공유하려면(예: 협력자와 연구 프로젝트), 서브-vault 또는 태그 기반 내보내기 스크립트를 사용하십시오. 전체 vault를 공유하지 마십시오 — 대부분의 로컬 AI PKB는 로컬 스택을 절대 떠나서는 안 되는 민감한 항목(의료, 금융, 개인)을 축적합니다.

💡Tip: 분기별로 복원을 테스트하십시오. "나는 백업이 있다"라는 대부분의 주장은 열망적입니다 — 테스트는 "2시간 미만에 새 노트북에서 vault를 복원할 수 있습니까?"입니다. 그 테스트를 실행하십시오. 처음 실행할 때 세 가지 레이어(스냅샷, Git, 임베딩 내보내기) 중 하나가 6개월 동안 잘못 구성되어 있었다는 것을 발견하게 됩니다.

일반적인 실수

캡처 레이어보다 검색 레이어를 먼저 설계합니다. 47개 항목의 vault에서 재순위를 사용한 커스텀 하이브리드 검색은 낭비입니다. 먼저 캡처를 구축하고, 순진한 상위-5 검색을 받아들이고, vault에 1,000개 이상의 항목이 있고 실제 쿼리에서 검색 품질을 측정할 수 있을 때만 검색을 최적화하십시오.
아키텍처 혼합. "노트용 Obsidian + PDF용 AnythingLLM + 이메일용 Python 커스텀"은 깔끔하게 들리지만 통합 비용이 지배합니다. 하나의 아키텍처를 선택하고, 제한 사항을 받아들이고, 절대적으로 필요한 경우에만 단일 커넥터를 추가하십시오(예: Obsidian vault 폴더를 읽기 전용 모드로 수집하는 AnythingLLM).
아카이브를 다시 임베딩하지 않고 임베딩 모델 변경. 동일한 스토어에서 nomic-embed-text의 768차원 벡터와 mxbai-embed-large의 1024차원 벡터를 혼합하면 검색이 자동으로 손상됩니다. 임베딩 모델 + 차원을 선택하고 고정하고, 아카이브 전체 재임베딩으로만 변경하십시오.
10,000개 항목 이상에서 임베딩 인덱스 백업 무시. "재생성할 수 있습니다"는 사실이지만 재생성에 몇 시간이 걸립니다. 10K 항목에서 임베딩 스토어를 백업 전략에 추가하십시오.
캡처의 80%가 모바일에서 발생하는데 데스크탑 전용으로 설계합니다. 모바일 캡처 경로가 없는 PKB는 먼지가 쌓입니다. 첫 날 모바일 캡처 흐름을 테스트하십시오 — 공유 시트에서 vault까지 5초 미만에 완료되어야 합니다.
바이너리 임베딩 인덱스에 iCloud Drive 신뢰. iCloud는 일반 텍스트를 잘 처리합니다; 바이너리 인덱스(Smart Connections .smart-env/, AnythingLLM 벡터 스토어)는 플랫폼 간에 손상됩니다. Obsidian Sync, 자체 호스팅 인스턴스를 사용하거나 기기별 재인덱싱을 받아들이십시오.
100K 항목에서 파티셔닝하지 않음. 100K 항목에서 단일 workspace / vault는 여러 초의 검색 지연 시간을 갖습니다. 주제(업무, 읽기, 프로젝트)별로 여러 workspace 또는 서브-vault로 파티셔닝하고; 각각을 별도로 또는 라우터를 통해 쿼리하십시오.

출처

Obsidian — obsidian.md 및 help.obsidian.md(vault 구조, 모바일 동기화 아키텍처, 플러그인 문서).
AnythingLLM — github.com/Mintplex-Labs/anything-llm(오픈 소스 자체 호스팅 RAG 애플리케이션).
Ollama — ollama.com 및 github.com/ollama/ollama(로컬 LLM 런타임; 채팅 + 임베딩 엔드포인트).
ChromaDB — trychroma.com 및 github.com/chroma-core/chroma(오픈 소스 로컬 벡터 데이터베이스).
Working Copy — workingcopy.app(모바일 캡처 파이프라인용 iOS Git 클라이언트).
a-Shell — holzschu.github.io/a-Shell_iOS/(스크립트 기반 모바일 캡처용 무료 iOS 터미널).

FAQ

지식 베이스에 웹 페이지를 어떻게 캡처합니까?

마찰 순서로 정렬된 세 가지 옵션이 있습니다. (1) 브라우저 확장으로서의 웹 클리퍼 — Obsidian Web Clipper 또는 AnythingLLM 확장이 현재 페이지를 vault / workspace에 직접 씁니다. (2) 모바일 공유 시트 — Safari / Chrome에서 공유 → Obsidian(Markdown 파일 쓰기) 또는 → Working Copy(Git에 커밋) 또는 → 커스텀 Shortcut(캡처 API로 POST). (3) 북마크릿 — 확장이 없는 브라우저용; 현재 URL + 선택 내용을 캡처 엔드포인트로 POST합니다. 모바일 공유 시트가 실제로 가장 많이 사용되는 경로입니다 — 먼저 설계하십시오.

시스템에 이메일을 전달할 수 있습니까?

예. 전용 주소(예: Fastmail / Migadu 별칭 kb@yourdomain.com)를 설정하고 홈 서버 또는 노트북에서 새 메일을 다운로드하고 vault에 이메일당 Markdown 파일을 쓰는 IMAP 폴러를 실행하십시오. 검색이 발신자별로 필터링할 수 있도록 파일 이름에 발신자 주소 접두사를 추가하십시오. AnythingLLM에는 자체 이메일 통합이 있습니다; Obsidian 사용자는 일반적으로 직접 IMAP 폴러를 구축하거나 n8n과 같은 IFTTT / Zapier 대안을 사용합니다.

데스크탑과 모바일 간에 어떻게 동기화합니까?

아키텍처에 따라 다릅니다. Obsidian 중심: Obsidian Sync(유료, 바이너리 인덱스를 깔끔하게 처리), iCloud Drive(무료, 일반 텍스트 전용 — 기기별 재인덱싱) 또는 Working Copy를 통한 Git(무료 + Working Copy 일회성 결제, 일반 텍스트 전용 — 기기별 재인덱싱). AnythingLLM 중심: 홈 서버의 Docker에서 AnythingLLM을 실행하고 모든 기기가 LAN 또는 Tailscale을 통해 연결됩니다 — 클라이언트 측 동기화가 필요 없습니다. Python 커스텀: 홈 서버의 중앙 API 서비스를 구축하고; 클라이언트는 캡처를 POST하고 쿼리를 GET합니다.

하나의 큰 vault를 사용해야 할까요, 아니면 주제별로 나눠야 할까요?

약 50,000개 항목까지는 하나의 vault를 사용하십시오. 50K 이상에서는 두 가지 이유로 주제(업무, 읽기, 프로젝트, 개인)별로 나누십시오: 검색 지연 시간이 약 1초 미만으로 유지되고, 규모에서 발생할 수 있는 의도치 않은 컨텍스트 누출(예: 업무 쿼리에서 개인 노트 나타남)이 가능해집니다. 50K 이전에 나누는 것은 너무 이릅니다 — PKB의 주요 가치인 우연한 교차 연결을 잃게 됩니다.

더 높은 정확도를 위해 얼마나 자주 재임베딩해야 합니까?

"정확도 드리프트"로 인해 재임베딩하지 마십시오 — 임베딩은 저하되지 않습니다. 임베딩 모델을 변경할 때만 재임베딩하십시오(예: 기술 콘텐츠에서 더 나은 검색을 위해 nomic-embed-text에서 mxbai-embed-large로 업그레이드). 세 가지 아키텍처는 모두 파일 변경 시 증분 재임베딩을 자동으로 처리합니다; 스케줄링할 필요가 없습니다. 예외는 인덱서를 제어하는 Python 커스텀 스택입니다 — 거기서는 저장 시 watchdog으로 제어되는 증분 재임베딩이 표준입니다.

지식 베이스에서 버전 관리를 사용할 수 있습니까?

일반 텍스트 콘텐츠에는 예(Markdown vault → Git 저장소, 로컬 + 비공개 GitHub / Gitea). 바이너리 인덱스 폴더(.smart-env/, vector_store/, ChromaDB 지속성 디렉토리)를 .gitignore에 추가하십시오 — 기록을 부풀리고 병합 충돌을 유발합니다. Git은 노트별 버전 기록을 제공하고; vault 스냅샷(Time Machine, restic)은 전체 시스템 롤백을 제공합니다. 하나가 아닌 두 레이어 모두.

이 시스템에서 PDF를 어떻게 처리합니까?

Obsidian 중심: Markdown 노트 옆에 PDF를 저장하십시오; Smart Connections는 PDF 콘텐츠를 직접 임베딩하지 않습니다 — 먼저 텍스트를 추출하십시오(예: PDF++ 플러그인 또는 각 PDF 옆에 Markdown 요약을 쓰는 전처리 스크립트를 통해). AnythingLLM 중심: PDF를 workspace에 직접 드래그하십시오; AnythingLLM이 PDF 파싱과 청킹을 자동으로 처리합니다. Python 커스텀: 수집 파이프라인에서 pypdf 또는 pdfplumber를 사용하여 텍스트를 추출하고, 추출된 텍스트를 임베딩하십시오. AnythingLLM은 PDF가 많은 아카이브에서 가장 마찰이 적은 옵션입니다.

KB의 일부를 선택적으로 공유할 수 있습니까?

예, 하지만 첫 날부터 설계하십시오. "공유 가능"하고 "비공개" 콘텐츠를 별도의 스토어에 유지하기 위해 서브-vault(Obsidian) 또는 workspace(AnythingLLM)를 사용하십시오. 일회성 공유의 경우 태그(예: #shareable)별로 항목을 추출하는 이식 가능한 Markdown 번들로 내보내는 태그 기반 내보내기 스크립트를 구축하십시오. 전체 vault를 공유하지 마십시오 — 대부분의 로컬 AI PKB는 로컬 스택을 절대 떠나서는 안 되는 민감한 항목(의료, 금융, 개인 서신)을 축적합니다.

최선의 백업 전략은 무엇입니까?

세 가지 레이어: (1) 24시간마다 파일 시스템 스냅샷(Time Machine / restic)과 외부 저장소 사본(Backblaze / rsync.net); (2) 노트별 버전 검색을 위한 일반 텍스트 콘텐츠의 Git 기록; (3) 빠른 재구성 경로로서의 분기별 임베딩 + 메타데이터 내보내기. 분기별로 복원을 테스트하십시오 — "2시간 미만에 새 노트북에서 vault를 재구성할 수 있습니까?" 첫 번째 복원 테스트는 일반적으로 세 가지 레이어 중 하나가 잘못 구성되어 있었다는 것을 드러냅니다.

새 컴퓨터로 어떻게 마이그레이션합니까?

vault 스냅샷 복원 → Ollama 설치 및 동일한 모델 다운로드 → Obsidian / AnythingLLM / Python 커스텀 스택 설치 → 임베딩 인덱서 재시작. Obsidian Sync 또는 자체 호스팅 AnythingLLM을 사용하면 마이그레이션은 "클라이언트 설치 및 로그인"입니다 — 수동 복원이 필요 없습니다. 그것 없이는 10K 항목 vault에 약 30분, 50K에 약 2시간, 임베딩 내보내기 단계를 생략했다면 100K 이상에는 밤새.

← 고급 로컬 LLM으로 돌아가기