Obsidian LLM Wiki란? — AI 에이전트에게 장기기억을 주는 가장 현실적인 방법
AI 에이전트를 며칠만 써봐도 금방 부딪히는 문제가 있습니다.
모델은 똑똑합니다. 코드를 읽고, 문서를 요약하고, 서버 명령도 실행합니다. 그런데 이상하게도 지난주에 정한 운영 규칙, 이미 실패했던 방식, 우리 프로젝트만의 약속은 계속 다시 설명해야 합니다.
대화 기록을 길게 붙이면 잠깐은 해결되는 것처럼 보입니다. 하지만 세션이 길어질수록 컨텍스트는 무거워지고, 필요한 기억을 정확히 꺼내는 일도 어려워집니다.
에이전트마다 외부 장기기억 시스템이 필요한 이유입니다.
1. 핵심 요약 — 이 글에서 기억할 5가지
Obsidian LLM Wiki는 AI 에이전트가 매번 밑지 상태에서 시작하지 않도록, 프로젝트의 지식과 운영 규칙을 Markdown 위키로 쌓아두는 방식입니다.
이 방식은 사용자의 역할을 바꿉니다.
- 기존: 매번 같은 맥락을 다시 설명하는 사람
- 이후: 기억 구조를 설계하고, 잘못된 기억을 검증하는 운영자
이 글의 핵심은 다섯 가지입니다.
- AI 에이전트의 장기기억은 모델 내부가 아니라 외부 지식층으로 분리하는 편이 현실적입니다.
- Obsidian은 Markdown 파일과 링크 구조를 제공하므로 작은 LLM Wiki를 시작하기 좋습니다.
- 기본 구조는 Raw / Wiki / Schema 세 계층이면 충분합니다.
- 장기기억은 저장소가 아니라 Ingest / Query / Lint로 계속 관리하는 운영 루프입니다.
- RAG와 LLM Wiki는 경쟁 관계가 아니라, 서로 다른 문제를 맡는 보완재입니다.
Obsidian은 이 구조를 시작하기 좋은 도구입니다. 파일은 사람이 읽을 수 있고, Markdown은 여러 도구가 다룰 수 있으며, Git으로 변경 이력을 남기기도 쉽습니다. Obsidian 공식 도움말도 vault, note, link, plugin 중심의 지식관리 구조를 설명합니다. 참고: Obsidian Help.
2. 주요 용어 정리
- AI 에이전트(agent): 도구를 쓰고 판단하며 작업을 이어가는 AI. 단순 챗봇보다 “일꾼”에 가깝습니다.
- 장기기억(long-term memory): 세션이 끝나도 유지되어야 하는 프로젝트 지식, 운영 규칙, 결정 근거, 실패 기록입니다.
- Obsidian vault: Markdown 노트가 모여 있는 작업 공간입니다.
- LLM Wiki: LLM이 읽고 쓸 수 있도록 Markdown 페이지 단위로 정리한 지식 위키입니다.
- Raw Sources: 웹페이지, 회의록, 대화, 로그처럼 가공 전 원본 자료입니다.
- Schema: 무엇을 저장하고, 어떤 형식으로 쓰고, 언제 검증할지 정한 규칙입니다.
- RAG: 질문 시점에 관련 문서 조각을 검색해 LLM에게 넣는 방식입니다.
- Lint: 위키의 깨진 링크, 오래된 정보, 모순, 출처 없는 주장을 점검하는 작업입니다.
3. Obsidian LLM Wiki는 어떻게 구성되나요? — 3계층과 3루프
Obsidian LLM Wiki는 Raw / Wiki / Schema 세 계층과 Ingest / Query / Lint 세 루프로 구성됩니다.
크게 두 덩어리로 보면 쉽습니다.
먼저 3계층이 있습니다.
- Raw — 원본을 보존한다.
- Wiki — 반복 재사용할 지식으로 정리한다.
- Schema — 아무 정보나 저장하지 못하게 규칙을 둔다.
그리고 3루프가 있습니다.
- Ingest — 새 자료를 위키에 넣는다.
- Query — 필요한 기억을 찾아 답한다.
- Lint — 오래된 기억을 고친다.
즉, Obsidian LLM Wiki는 원본을 받고, 지식으로 정리하고, 다시 검증하는 작은 운영 시스템입니다.
4. Raw 계층은 왜 필요한가요? — 원본을 잃지 않는다
역할
Raw는 가공 전 원본을 보존하는 계층입니다.
웹페이지, 공식 문서, 회의록, 에러 로그, 대화 기록, 실행 결과처럼 나중에 다시 확인해야 할 수 있는 자료를 그대로 둡니다.
비유
Raw는 요리에서 “재료”에 가깝습니다.
요약본은 완성된 요리입니다. 맛있게 정리되어 있지만, 잘못 조리했는지 확인하려면 원재료가 필요합니다. AI가 요약을 잘못했을 때도 마찬가지입니다. 원본이 있어야 되돌아갈 수 있습니다.
핵심 포인트
- 원본과 요약을 섞지 않습니다.
- 출처 URL과 확인 날짜를 남깁니다.
- 중요한 실행 결과는 그대로 보존합니다.
- 비밀값은 Raw에도 넣지 않습니다.
실제 구현
예시는 다음과 같습니다.
LLM Wiki/
raw/
2026-06-24-obsidian-help.md
2026-06-24-ai-tool-docs.md
2026-06-24-server-error-log.md
원본을 보존하면, AI가 만든 위키 페이지가 틀렸을 때 “무엇을 보고 그렇게 썼는지” 추적할 수 있습니다.
5. Wiki 계층은 무엇을 하나요? — AI가 다시 읽을 지식으로 정리한다
역할
Wiki는 Raw를 그대로 복사하는 곳이 아닙니다.
반복해서 쓸 지식만 골라 사람이 읽을 수 있는 Markdown 페이지로 정리하는 계층입니다. 예를 들어 특정 프로젝트의 운영 규칙, 블로그 발행 절차, 서버 구성, 모델 선택 기준 같은 정보가 여기에 들어갑니다.
비유
Wiki는 인수인계 문서입니다.
새 사람이 올 때마다 말로 설명하지 않기 위해 문서를 씁니다. AI 에이전트도 마찬가지입니다. 세션이 바뀔 때마다 처음부터 설명하지 않으려면, 읽을 수 있는 인수인계 문서가 필요합니다.
핵심 포인트
- 반복 재사용될 정보만 넣습니다.
- 결정 이유와 책임자가 필요한 정보는 남깁니다.
- 실패한 방식도 남깁니다.
- 일회성 진행 상황은 넣지 않습니다.
실제 구현
예시는 다음과 같습니다.
LLM Wiki/
topics/
ai-agent-memory.md
project-knowledge.md
projects/
product-docs.md
runbooks/
publish-checklist.md
decisions/
tool-routing-policy.md
이렇게 하면 여러 AI 에이전트가 같은 문서를 읽고 이어서 작업할 수 있습니다.
6. Schema 계층은 왜 필요한가요? — 아무거나 기억하지 못하게 막는다
역할
Schema는 위키의 저장 규칙입니다.
무엇을 저장할지, 어떤 frontmatter를 쓸지, 어떤 링크 관계를 만들지, 언제 검증할지 정합니다. Schema가 없으면 장기기억은 금방 잡동사니 창고가 됩니다.
비유
Schema는 도서관의 분류 규칙입니다.
책을 아무 서가에나 꽂으면 처음에는 편해 보이지만, 나중에는 아무것도 찾을 수 없습니다. AI 장기기억도 같습니다. 저장 규칙이 없으면 기억이 많아질수록 성능이 좋아지는 것이 아니라, 오히려 헷갈리기 시작합니다.
저장 전 5필터
저장하기 전에 다음 질문을 통과한 것만 장기기억으로 승격하는 방식을 추천합니다.
- 반복 재사용될 정보인가?
- 다른 에이전트가 이어받기 위해 필요한가?
- 결정 이유나 책임자를 추적해야 하는가?
- 실패한 방식이라 다시 시도하면 안 되는가?
- 팀이나 에이전트 공통 규칙인가?
이 중 아무것도 해당하지 않으면 Wiki에 넣지 않는 편이 낫습니다.
실제 구현
LLM Wiki/
schema.md
_meta/
context-bootstrap.md
command-map.md
schema.md에는 frontmatter 규칙, 페이지 타입, 저장 기준, 검증 주기를 적습니다. context-bootstrap.md에는 에이전트가 처음 읽어야 할 진입점을 둡니다.
7. 왜 기억을 L1 / L2로 나누나요?
AI 에이전트는 항상 읽을 작은 기억과, 필요할 때 검색할 큰 기억을 분리해야 합니다.
역할
AI 에이전트는 매번 전체 Wiki를 읽으면 안 됩니다.
전체 기억을 한 번에 넣으면 컨텍스트가 무거워지고, 중요한 규칙이 오히려 묻힙니다. 그래서 항상 읽는 작은 기억과, 필요할 때 찾아 읽는 큰 기억을 나눕니다.
비유
L1은 책상 위 메모입니다.
항상 봐야 하는 규칙만 적어둡니다. L2는 책장입니다. 자세한 자료는 책장에 두고, 필요할 때 찾아옵니다.
핵심 포인트
| 구분 | 역할 | 예시 |
|---|---|---|
| L1 | 항상 읽는 핵심 기억 | 사용자 선호, 작업 시작점, 공통 규칙 |
| L2 | 필요할 때 찾는 상세 지식 | topic, project, runbook, decision |
실제 구현
L1에는 이런 파일이 어울립니다.
context-bootstrap.md
schema.md
index.md
최근 운영 규칙
핵심 프로젝트 지도
L2에는 이런 파일이 어울립니다.
topics/agent-memory-pattern.md
projects/service-runtime.md
runbooks/publish-checklist.md
decisions/model-routing-policy.md
이 구조를 쓰면 AI 에이전트는 매번 전체 기억을 다 읽지 않고, “어디를 봐야 하는지”만 먼저 알고 출발할 수 있습니다.
단, L1도 커지면 비용이 됩니다. bootstrap 기억은 수백 토큰에서 몇 천 토큰 이하로 작게 유지하는 편이 좋습니다. L1이 너무 커지면 토큰 비용이 늘고, 중요한 지시가 잡음에 묻히는 context dilution이 생깁니다.
8. Ingest 루프는 무엇을 하나요? — 새 자료를 기억으로 승격한다
역할
Ingest는 새 자료를 위키에 넣는 과정입니다.
단순 저장이 아닙니다. 원본을 보존하고, 관련된 기존 페이지를 찾고, 필요한 부분만 정리 지식으로 반영합니다.
비유
Ingest는 우편물을 정리하는 일과 비슷합니다.
우편함에 편지를 넣기만 하면 집이 어지러워집니다. 중요한 문서는 파일철에 넣고, 영수증은 따로 보관하고, 광고지는 버려야 합니다.
기본 흐름
새 소스 저장
→ 관련 topic/project/entity 탐색
→ 필요한 페이지에 추가 또는 수정
→ 관계 링크 추가
→ log 기록
핵심 포인트
- 원본은 Raw에 둡니다.
- 요약은 Wiki에 둡니다.
- 변경 사실은 log에 남깁니다.
- 출처 없는 주장은 만들지 않습니다.
9. Query 루프는 무엇을 하나요? — 필요한 기억을 찾아 답한다
역할
Query는 질문을 받았을 때 위키에서 필요한 기억을 찾아 답하는 과정입니다.
중요한 점은 “AI가 기억하고 있겠지”라고 기대하지 않는 것입니다. 먼저 index나 검색으로 관련 페이지를 찾고, 그 페이지를 읽은 뒤 답해야 합니다.
비유
Query는 사내 문서 검색입니다.
경험 많은 직원도 모든 문서를 외우지 않습니다. 대신 어디에 무엇이 있는지 알고, 필요할 때 찾아봅니다. AI도 그렇게 쓰는 편이 안전합니다.
기본 흐름
질문
→ index 또는 검색으로 후보 페이지 찾기
→ 관련 페이지 읽기
→ 근거 포함 답변
→ 새로 배운 내용이 있으면 저장 기준 검토
핵심 포인트
- 답변에는 근거 페이지를 같이 둡니다.
- 최신성이 중요한 정보는 원본을 다시 확인합니다.
- 새로 알게 된 정보도 저장 전 5필터를 통과해야 합니다.
10. Lint 루프는 왜 필요한가요? — 오래된 기억을 청소한다
역할
Lint는 위키가 오래되며 생기는 문제를 찾는 과정입니다.
장기기억은 방치하면 자산이 아니라 오류 저장소가 됩니다. 서버 IP가 바뀌었는데 옛 문서가 남아 있거나, 잘못된 링크가 늘어나거나, 출처 없는 주장이 반복되면 AI도 그 잘못된 기억을 따라갑니다.
비유
Lint는 창고 정리입니다.
물건을 넣기만 하고 버리지 않으면 창고는 점점 쓸모없어집니다. 기억도 같습니다. 넣는 것만큼 정리하는 것이 중요합니다.
점검 항목
- 모순되는 정보가 있는가?
- 위험도가 높은 운영 정보가 검증 주기를 넘겼는가?
- 고아 페이지가 생겼는가?
- 깨진 wikilink가 있는가?
- 출처 없는 주장이 늘어났는가?
실제 구현
처음에는 사람이 체크리스트로 점검해도 됩니다. 규모가 커지면 스크립트와 AI critic를 함께 쓰는 편이 좋습니다.
예를 들어 frontmatter 필수 필드 검증, 깨진 링크 탐지, 오래된 운영 문서 목록화는 결정론적 스크립트가 잘합니다. 반면 모순 탐지나 중복 개념 정리는 AI가 도와줄 수 있습니다.
11. RAG와 무엇이 다른가요?
역할 차이
RAG는 질문 시점에 관련 자료 조각을 찾아 LLM에게 넣는 방식입니다.
LLM Wiki는 반복해서 쓸 지식을 미리 사람이 읽을 수 있는 페이지로 통합해두는 방식입니다. 둘은 경쟁 관계라기보다 맡는 일이 다릅니다.
비교표
| 항목 | RAG | Obsidian LLM Wiki |
|---|---|---|
| 기본 단위 | chunk, 문서 조각, 검색 결과 | Markdown page |
| 강점 | 대용량·자주 바뀌는 자료 검색 | 안정적 지식 누적과 인수인계 |
| 약점 | 검색 품질과 chunk 설계에 의존 | 정기 정리와 lint 필요 |
| 투명성 | 구현에 따라 다름 | 사람이 직접 읽기 쉬움 |
결론
대용량 문서, 자주 바뀌는 자료, 웹 검색은 RAG가 유리합니다. 반복 재사용되는 운영 지식, 프로젝트 규칙, 실패 교훈은 LLM Wiki가 유리합니다.
실전에서는 둘을 함께 쓰는 하이브리드가 가장 안전합니다.
12. 실제 운영에서 조심할 점
LLM Wiki는 장기기억이지만, 잘못 운영하면 장기 오류 저장소가 됩니다.
1. AI가 만든 링크를 너무 믿지 말 것
LLM은 없는 페이지도 그럴듯하게 링크할 수 있습니다. 깨진 wikilink 탐지가 필요합니다.
2. 동시에 여러 에이전트가 같은 파일을 쓰게 하지 말 것
여러 writer가 같은 파일을 동시에 수정하면 덮어쓰기나 충돌이 생길 수 있습니다. 단일 writer 원칙, lock, merge 전략이 필요합니다.
원자적 rename은 임시 파일에 먼저 쓰고 같은 파일시스템 안에서 rename하는 방식입니다. 필요하면 fsync까지 고려해야 합니다. 이 방식은 부분 쓰기나 깨진 파일을 줄이는 장치이지, 여러 에이전트가 동시에 같은 문서를 고치는 논리적 충돌까지 해결하지는 못합니다.
3. 운영 정보와 리서치 정보를 구분할 것
서버 IP, 백업 경로, systemd 서비스명 같은 운영 정보는 틀리면 사고가 납니다. 반면 리서치 글은 “그 시점의 조사 결과”로 남겨도 됩니다.
4. 비밀값은 Wiki에 저장하지 말 것
Obsidian vault는 기본적으로 평문 파일입니다. API key, token, password, connection string은 Wiki에 넣으면 안 됩니다.
Wiki에는 “어떤 secret manager의 어떤 항목을 참조한다”는 절차만 남기고, 실제 값은 1Password나 환경변수, credential store에 둬야 합니다.
5. 규모가 커지면 검색 레이어가 필요하다
페이지가 늘어나면 index.md만 읽는 방식은 한계가 옵니다. 이때는 파일 검색, BM25, 임베딩 검색, MCP 검색 서버, RAG를 붙여야 합니다.
LLM Wiki는 검색을 없애는 구조가 아니라, 검색 결과를 사람이 검토 가능한 지식 페이지로 누적하는 구조에 가깝습니다.
13. 처음에는 어떤 구조로 시작하면 좋나요?
처음에는 복잡한 벡터DB 없이 폴더와 규칙부터 시작하는 것이 좋습니다.
LLM Wiki/
_meta/
context-bootstrap.md
command-map.md
topics/
agent-memory-pattern.md
projects/
decisions/
runbooks/
raw/
index.md
log.md
schema.md
최소 순서는 다음과 같습니다.
schema.md에 저장 규칙을 적습니다.context-bootstrap.md에 에이전트 시작점을 적습니다.raw/에는 원본 자료를 보존합니다.topics/에는 반복 재사용될 지식을 정리합니다.log.md에는 주요 변경만 남깁니다.- 주기적으로 lint해서 오래된 정보와 깨진 링크를 점검합니다.
Git을 붙이면 변경 이력과 rollback이 쉬워집니다. Git 공식 문서는 Pro Git 2판을 온라인으로 제공합니다. 참고: Pro Git Book.
14. 구조화 데이터와 발행 메타데이터
발행 메타데이터도 같이 준비하면 좋습니다. 이 글의 저자는 welltip, 발행일은 2026년 6월 24일, 주제 엔티티는 Obsidian, LLM Wiki, AI agent memory, RAG입니다. WordPress에서는 Rank Math 같은 SEO 플러그인과 충돌하지 않는 범위에서 TechArticle 또는 FAQPage schema를 붙일 수 있습니다.
15. 자주 묻는 질문
Obsidian LLM Wiki는 RAG를 대체하나요?
완전히 대체하지 않습니다. 반복 재사용되는 안정적 지식은 Obsidian LLM Wiki에 적합하고, 대용량·고빈도 변경 자료는 RAG나 웹검색이 더 적합합니다.
모든 대화 기록을 Obsidian에 저장해야 하나요?
모든 대화 기록을 저장하면 장기기억이 아니라 노이즈 저장소가 됩니다. 반복 재사용, 인수인계, 결정 근거, 실패 교훈, 공통 규칙에 해당하는 정보만 승격하는 편이 좋습니다.
AI 에이전트가 Wiki를 직접 수정해도 안전한가요?
조건부로 안전합니다. 원본 보존, Git 이력, 단일 writer 원칙, lint, 사람 검토가 있어야 합니다. 특히 운영 정보와 secret은 에이전트가 임의로 덮어쓰지 못하게 해야 합니다.
개인도 이런 구조가 필요한가요?
AI 에이전트를 단순 질의응답에만 쓴다면 필요 없습니다. 하지만 서버 운영, 블로그 발행, 코드 작업, 반복 리서치처럼 여러 세션에 걸친 작업을 맡긴다면 작은 LLM Wiki만으로도 재작업을 크게 줄일 수 있습니다.
16. 마무리
AI 에이전트의 장기기억은 모델 성능만으로 해결되는 문제가 아닙니다. 중요한 것은 기억을 어디에 두고, 누가 검증하고, 언제 고칠 것인지 정하는 운영 구조입니다.
Obsidian은 이 구조를 작게 시작하기 좋은 도구입니다. 원본은 Raw에 두고, 정리된 지식은 Wiki에 두고, 저장 규칙은 Schema에 둡니다. 작은 시작 기억은 L1에, 상세 지식은 L2에서 찾습니다. Ingest, Query, Lint 루프를 계속 돌려야 장기기억이 살아 있습니다.
