나만의 RAG 시스템: Obsidian 노트를 AI의 참고서로 만드는 법

RAG를 처음 들으면 대개 벡터 DB부터 떠올린다.
임베딩을 만들고, 청크를 나누고, 검색기를 붙이고, 모델에게 관련 문서를 넣어주는 구조를 생각한다.

하지만 개인 지식 관리에서 RAG를 그렇게 시작하면 자주 실패한다.

이유는 단순하다.
검색기가 나쁜 것이 아니라, 검색할 지식이 아직 정리되어 있지 않기 때문이다.

나에게 더 현실적인 출발점은 Obsidian이다. 내가 이미 읽고, 밑줄 긋고, 연결하고, 다시 쓴 노트를 AI가 참고하게 만드는 것. RAG는 거대한 인프라 이전에 내 노트를 AI의 참고서로 만드는 일이다.

RAG는 오픈북 시험이다

RAG는 Retrieval-Augmented Generation의 약자다.
쉽게 말하면 AI가 답하기 전에 책을 펼쳐보게 하는 방식이다.

닫힌 시험에서는 모델이 자기 기억만으로 답한다.
오픈북 시험에서는 내가 제공한 문서, 노트, 매뉴얼, 코드, 정책을 찾아보고 답한다.

개인 지식 관리로 옮기면 질문은 이렇게 바뀐다.

AI가 내 생각을 모른다면,
내가 어떤 참고서를 만들어줘야 하는가?

여기서 핵심은 “AI가 똑똑한가”가 아니다.
AI가 다시 읽을 수 있는 형태로 내가 지식을 남겼는가다.

1단계: Inbox를 RAG에 넣지 않는다

가장 흔한 실수는 볼트 전체를 그대로 검색 대상으로 만드는 것이다.

Inbox에는 임시 메모, 덜 검토한 아이디어, 웹에서 긁어온 조각, 중복된 문장, 아직 내 생각이 아닌 자료가 섞여 있다. 이것을 그대로 RAG에 넣으면 AI는 내 지식과 잡음을 구분하지 못한다.

RAG에 먼저 넣어야 할 것은 20_Permanent 같은 검토된 노트다.

좋은 RAG 후보 노트는 이런 조건을 가진다.

• 제목만 봐도 범위가 분명하다.
• 출처와 내 생각이 구분되어 있다.
• 하나의 노트가 하나의 핵심 질문을 다룬다.
• frontmatter에 도메인, 상태, 공개 가능 여부가 있다.
• 다른 노트와 링크되어 있다.

즉 RAG는 검색 기술 이전에 노트 위생의 문제다.

2단계: frontmatter를 AI의 사용 규칙으로 만든다

사람은 문맥을 보고 대충 판단할 수 있다.
하지만 에이전트에게는 명시적 표식이 필요하다.

---
domain: "blog-ops"
status: "reviewed"
agent_usable: true
publishable: true
trust: "medium"
source_type: "personal-note"
updated: 2026-06-24
---

이 몇 줄은 작지만 중요하다.

agent_usable은 에이전트가 답변에 참고해도 되는지 알려준다.
publishable은 공개 글로 전환 가능한지 알려준다.
trust는 신뢰 수준을 알려준다.
source_type은 원문인지, 내 생각인지, 요약인지 구분하게 한다.

RAG 시스템이 커질수록 이 메타데이터는 검색 정확도만큼 중요해진다.

3단계: 먼저 긴 컨텍스트로 실험한다

처음부터 벡터 DB를 붙일 필요는 없다.
작은 개인 프로젝트라면 핵심 노트를 하나의 Markdown 또는 PDF로 묶고, 긴 컨텍스트 모델에 넣어 실험할 수 있다.

질문은 구체적이어야 한다.

이 문서 묶음을 바탕으로,
내가 반복해서 말하는 교육 철학 5가지를 뽑고,
각각을 블로그 카테고리와 연결해줘.

이 단계의 목표는 시스템 구축이 아니라 내 노트가 AI에게 읽힐 수 있는지 확인하는 것이다. 답변이 흐릿하다면 검색기가 부족한 것이 아니라 노트 구조가 흐릿한 것이다.

4단계: Obsidian 내부 검색과 플러그인을 활용한다

Obsidian 안에서도 RAG에 가까운 경험을 만들 수 있다. Smart Connections 같은 플러그인은 노트를 인덱싱하고, 질문과 관련된 노트를 찾아준다.

다만 여기서도 기준은 같다.

플러그인이 내 지식 구조를 대신 만들어주지는 않는다.
찾아줄 수는 있지만, 무엇이 중요한지 판단해주지는 않는다.

그래서 먼저 해야 할 일은 플러그인 설치가 아니라 노트 정리다.

TABLE file.mtime as "수정일", length(file.content) as "길이", status as "상태"
FROM "20_Permanent"
WHERE length(file.content) > 300
SORT file.mtime DESC
LIMIT 20

이런 목록을 보고 RAG 후보 노트를 점검한다. 길이가 충분하고, 최근 수정되었고, 상태가 검토됨이라면 좋은 후보가 된다.

5단계: 답변이 아니라 출처 연결을 검증한다

RAG의 품질은 답변 문장이 그럴듯한지로만 판단하면 안 된다.
정말 중요한 것은 어떤 노트를 근거로 답했는가다.

검증 질문은 이렇게 바꿔야 한다.

• 답변이 참조한 노트가 실제로 존재하는가?
• 핵심 문장이 원노트의 의미를 왜곡하지 않았는가?
• 서로 충돌하는 노트를 함께 보여주는가?
• 오래된 노트를 최신 노트처럼 말하지 않는가?
• 공개하면 안 되는 private note를 사용하지 않았는가?

이 기준이 없으면 RAG는 환각을 줄이는 도구가 아니라, 환각에 출처 모양을 붙이는 도구가 된다.

LLM Wiki와 RAG는 적이 아니다

나는 RAG를 버리자는 쪽이 아니다.
다만 순서가 중요하다고 본다.

먼저 LLM Wiki가 필요하다.
지식의 이름, 범위, 관계, 상태, 출처, 공개 가능성을 정리해야 한다.

그다음 RAG가 필요하다.
정리된 지식을 필요한 순간에 찾아오게 해야 한다.

LLM Wiki는 도서관의 분류 체계다.
RAG는 그 도서관에서 책을 찾아오는 사서다.

분류 체계가 없으면 사서는 열심히 뛰어다니지만 좋은 책을 찾기 어렵다.

결론: AI에게 가르치지 말고 참조하게 하라

개인 지식 관리에서 가장 큰 전환은 이것이다.

AI에게 매번 처음부터 설명하지 않는다.
내가 이미 쓴 노트를 참조하게 한다.

그러려면 노트는 사람이 읽기 좋은 글이면서, 에이전트가 다룰 수 있는 구조여야 한다. 제목, frontmatter, 링크, 출처, 상태, 공개 가능 여부가 함께 있어야 한다.

RAG의 시작은 벡터 DB가 아니다.
내 지식이 다시 읽힐 수 있도록 정리하는 일이다.