LLM(대규모 언어 모델)과 Obsidian과 같은 로컬 지식 베이스(Vault)를 결합하여, AI 어시스턴트나 자율형 에이전트와 함께 자신의 지식을 키워나가는 스타일이 확산되고 있습니다.

그렇다면, 키워온 그 지식을 실제로 탐색하게 할 단계가 되면 무엇을 사용하고 있을까요? 오픈 소스 확장 기능이나 자체 제작 스크립트를 통해, RAG(Retrieval-Augmented Generation) 시스템이나 AI 코딩 툴(Claude Code, Gemini CLI 등)에 정보를 찾게 하는 ── 그러한 상황에서, 우리는 **「전문 검색(grep)」**을 다용하고 있지 않습니까?

"〇〇에 관한 기술을 찾아줘"라고 지시받은 AI는 디렉터리 내의 파일들을 하나하나 검색하며, 키워드가 일치하는 파일을 대량으로 읽어들입니다. 하지만 이러한 "무차별적인 탐색"은 편리한 한편, 때로는 우리의 컨텍스트를 소란스럽고 불확실하게 만드는 4가지 과제를 안고 있습니다.

추론 비용(API 토큰)의 팽창: 무관한 파일까지 컨텍스트에 흘려보내기 때문에, 컨텍스트 소비가 지수 함수적으로 증가한다. -
표기 불일치로 인한 누락: 유의어(Synonym)나 수학적인 추상 개념의 표현 차이를 포착하지 못해, 바로 옆에 있어야 할 사고에 도달하지 못한다. -
탐색 재현성의 흔들림: 같은 질문을 하더라도 그때그때 키워드가 걸리는 방식에 따라 LLM이 참조하는 컨텍스트가 달라져, 출력 품질이 안정되지 않는다. -
구조적 이해의 부재: AI가 "어떤 정보가 어떤 개념의 하위에 있는가"라는 지식의 계층을 이해하지 못하고, 산재한 점(단어)의 연결만으로 답변을 날조(Hallucination)하기 쉬워진다.

본고에서는 이러한 「grep 중심의 무질서한 탐색」에서 한 걸음 물러나, Obsidian에서의 **MOC(Map of Contents / 지식의 지도)**를 AI 탐색의 기점으로 삼는, 조금 더 정적이고 효율적인 지식 탐색의 방식을 제안해 보고자 합니다.

목표는 심플합니다. 필요할 때, 필요한 정보만을, 꺼낸다. 그것뿐입니다.

Obsidian에는 인간이 지적 정리를 수행하기 위한 관습으로서 **MOC(Map of Contents)**가 있습니다. 여기서의 제안은 간단합니다.

"AI에게 검색하게 하는" 것이 아니라, "인간이 이미 만들어 놓은 지식 지도를 AI가 따라가게 하는 것"

이미지 상으로는 다음과 같은 경로가 됩니다 (이후, Vault 루트의 MOC는 Top_MOC.md, 각 도메인의 MOC는 도메인명/MOC.md (예: AI/MOC.md)라는 명명 규칙으로 통일하여 표기합니다).

Question
↓
Top MOC
...

실제 폴더 계층으로 나타내면 다음과 같습니다.

Vault/
├─ Top_MOC.md (Vault의 루트 지도)
├─ AI/ (AI 에이전트 연구)
...

실제로 AI/MOC.md의 내용을 들여다보면 다음과 같은 모습이 됩니다.

# 🤖 AI 에이전트 연구 MOC
이 도메인에서는 로컬 LLM이나 멀티 에이전트 시스템에서의
「기억」과 「동일성」을 다룬다.
...

제목과 불렛 포인트, 그리고 WikiLinks로만 구성된 단순한 Markdown 파일입니다. 특별한 플러그인도 구문도 필요 없습니다. AI는 키워드 일치로 Vault 전체를 헤집는 것이 아니라, 먼저 Top_MOC.md를 읽고, 다음으로 지시와 관련된 도메인의 MOC.md로 링크를 따라가, 목적지인 Concept Note(나아가 Raw Note)에 핀포인트로 액세스합니다.

예를 들어, 다음과 같은 지시를 내렸다고 가정해 봅시다 (단순한 예시입니다).

"AI 실험 로그에 대해 이어서 진행하고 싶어. 준비해줘"

이때 AI 에이전트는 다음과 같은 경로를 따릅니다.

Top_MOC.md를 열어 Vault 전체의 제목 목록을 확인한다 - "AI"라는 키워드를 통해 AI/ 도메인을 선택한다 - AI/MOC.md를 열어 "실험 로그" 섹션에서 [[Experiment_N30통계실험]]을 찾는다 - Experiment_N30통계실험.md를 직접 읽으러 간다

grep 중심의 탐색이라면 실제로는 다음과 같은 결과가 됩니다.

$ grep -rl "実験\|AI\|ログ" Vault/
AI/Experiment_N30統計実験.md ← 정말로 원했던 파일
AI/20260702_Ablation_Study_Report.md ← 별개 테마(SCC/망각 기제)의 무관한 연구 로그
...

「실험」, 「AI」, 「로그」라는 단어가 같다는 이유만으로, 테마도 최신성도 제각각인 파일들이 한데 섞여서 걸려 나옵니다. AI는 이 중에서 원하는 것을 찾기 위해, 결국 모든 내용을 읽고 판단할 수밖에 없습니다.

반면 MOC 라우팅(Routing)에서는 다음과 같이 간단합니다.

Top_MOC.md → AI/MOC.md → Experiment_N30統計実験.md

3단계, 파일 1개. 노이즈를 읽을 필요도, 판단할 필요도 없습니다.

핵심은 GraphRAG처럼 그래프를 기계가 자동으로 생성하는 것이 아니라, 사용자가 이미 가지고 있는 MOC, 링크(Link), 백링크(Backlink) 구조를 그대로 활용한다는 점입니다.

여기서 당연히 의문이 생길 수 있습니다. "AI는 애초에 ls나 find, tree 명령어로 폴더 구조를 직접 읽을 수 있을 텐데. 그렇다면 굳이 MOC를 쓰지 않아도 폴더 이름을 따라가게 하면 똑같은 결과가 나오지 않을까?"

결론부터 말씀드리면, 이는 오해입니다. AI가 폴더 이름이나 디렉터리(Directory) 구조를 가져올 수 없다는 기술적 제약은 존재하지 않습니다. 그럼에도 MOC가 필요한 이유는 폴더 계층 그 자체가 가진 구조적인 한계에 있습니다.

1. 폴더 계층은 트리 구조(Tree Structure), MOC는 그래프 구조(Graph Structure)

파일은 물리적으로 단 하나의 폴더에만 둘 수 있습니다. 하지만 「AI × 철학」처럼 여러 도메인에 걸친 이야기는 폴더 계층만으로는 표현할 수 없습니다. 폴더를 넘나드는 관계성은 폴더 이름만으로는 절대로 드러나지 않습니다 (이 문제에 대한 구체적인 대처법은, 후술할 「개인 Vault에서의 최소 구현」에서 다루는 「교차 전용 MOC」입니다).

2. 폴더 이름은 「분류 라벨」이지 「관련성에 대한 설명」이 아니다

Articles/Resonance/와 같은 폴더 이름을 보더라도, AI는 그 안의 각 파일이 서로 어떻게 관련되어 있는지, 어떤 것이 현재 중요하고 어떤 것이 오래된 초안인지까지는 알 수 없습니다. MOC는 「이 노트와 저 노트는 연결되어 있다」라는 인간의 판단을 프라즈(Prose)와 위키링크(WikiLinks)로서 명시적으로 기록한 것입니다. 폴더 이름에는 그러한 정보가 담기지 않습니다.

3. 폴더 목록은 「거기에 있다」는 사실만 알려줄 뿐 「봐야 하는지」는 알려주지 않는다

실제로 필자의 Vault에서도 루트(Root) 직하단에 아직 어떤 MOC에도 링크되지 않은 가공되지 않은 메모들이 여러 개 존재합니다. ls로 루트를 보면, 이것들은 다른 중요한 파일들과 구분 없이 그저 나열되어 있습니다. 하지만 MOC는 의도적으로 이것들을 싣지 않습니다. 즉, 폴더·파일 목록은 「존재」를 보장할 뿐, 「의미적으로 따라가야 하는지」는 보장하지 않습니다. 그 선별 작업을 수행하는 것이 바로 MOC입니다.

요약하자면, 전체 검색(grep)과 디렉터리 목록(ls/tree)은 동일한 「무차별 대입(Brute-force)」 계통에 속하며, MOC와는 다른 축에 있습니다.

이 제안이 기존 방식들과 어떻게 다른지 정리해 두겠습니다. 현재 AI에게 Vault를 탐색하게 하는 대표적인 접근 방식은 다음 두 가지입니다.

Embedding RAG

질문 → 임베딩(Embedding) 검색 → 유사 チャンク(Chunk) → LLM

GraphRAG

질문 → 지식 그래프(Knowledge Graph) → 관련 노드(Node) → LLM

둘 다 「인간이 구조화해주지 않는다」라는 전제에 서 있습니다. 실제로 주요 Obsidian AI 플러그인(Smart Connections: 다운로드 수 78만 회 초과, Copilot, Local LLM Helper 등)은 모두 임베딩(Embedding) 단계에 머물러 있으며, MOC나 GraphRAG를 활용하지 못하고 있는 것이 실상입니다.

MOC를 AI의 라우터(Router)로 만든다는 발상 자체가 완전히 새로운 것은 아닙니다. 조사해 보니 비슷한 문제 의식을 가진 선행 사례를 몇 가지 찾을 수 있었습니다.

사례	내용
Chris Lettieri (Medium)	MOC 노트에서 링크 트리를 따라 이동하며, 해당 MOC에 특화된 RAG 범위를 구축한다는 실천 보고
Andrej Karpathy 「LLM Wiki」	임베딩(Embedding)·벡터 DB 없이, LLM이 자기 관리 인덱스(Self-managed index)를 따라 탐색하는 패턴. 약 40만 단어 규모에서 실용적이라고 보고됨
obsidian-wiki (Ar9av)	Karpathy 패턴을 구현한 프레임워크. 제거하면 그래프가 분단되는 「hub/bridge page」 분석 기능도 보유
PageIndex	이론적으로 가장 가까운 개념. 벡터 없이 LLM 추론으로 문서의 트리 구조(목차)를 내려가는 검색 방식. 단, 대상은 단일 문서
RAPTOR	계층 트리(Hierarchical tree)를 만들지만, 바텀업(Bottom-up) 방식이며 알고리즘에 의한 자동 클러스터링(Clustering). 인간이 의도한 개념 구조와 일치하지 않을 수 있음
GraphRAG (Microsoft)	엔티티(Entity) 추출 → Leiden 커뮤니티 탐지 → 요약 생성 → 검색,이라는 4단계 과정. 인덱스 구축 비용이 높음

즉, 「트리 구조·인덱스를 LLM 추론으로 내려간다」는 발상 자체에는 이미 여러 선행 연구와 구현이 존재합니다. 이 글의 주장은 「새로운 패러다임의 발명」이 아니라, 그 계보를 사용자가 이미 보유하고 있는 MOC 자산 위에서 어떻게 실천할 것인가에 대한 재해석 및 구현 가이드에 가깝습니다.

Embedding RAG, GraphRAG, MOC 라우팅(Routing) 세 가지를 나란히 놓고 정리하면, 각각의 장단점이 명확해집니다.

Embedding RAG	GraphRAG	MOC 라우팅
구조의 출처	구조 없음 (플랫한 벡터 공간)	LLM이 자동 생성
...	...	...

핵심적인 차이는 바로 이 지점입니다. GraphRAG와 MOC 라우팅은 목표(계층적·의미적 탐색)는 같지만, 구조를 얻는 방법이 정반대입니다.

• GraphRAG: 「구조가 없다」는 전제하에, 기계가 구조를 다시 만든다.
• MOC 라우팅: 「구조는 이미 있다」는 전제하에, 그것을 그대로 사용한다.

Embedding은 이 양자와는 별개의 축에 있으며, 애초에 구조라는 발상 자체를 가지고 있지 않습니다.

다시 말해, MOC는 「인간이 가장 높은 해상도와 문맥적 편향(Contextual bias)을 가지고 구축한, 커뮤니티 요약」에 가까운 성질을 가집니다. 다만 주의해야 할 점은, 이것이 보장하는 것은 링크 구조 그 자체가 AI의 날조가 아니라는 점이지, AI가 링크된 노트의 내용을 올바르게 해석·요약할 수 있다는 것까지 보장하지는 않는다는 것입니다. 관계성의 출처가 신뢰할 수 있다는 것과, AI의 독해가 항상 정확하다는 것은 별개의 문제입니다.

또 하나, 사소하지만 중요한 차이가 있습니다. 바로 **가시성(Visibility)**입니다. GraphRAG의 지식 그래프(Knowledge Graph)나 Embedding의 벡터 공간은 인간이 직접 열어서 「이것이 옳은가」를 눈으로 확인할 수 있는 형태가 아닙니다 (DB 내부의 표현이나 수치의 나열을 보고 검증하는 것은 현실적이지 않습니다). 반면 MOC는 단순한 Markdown 파일과 위키링크(WikiLinks)입니다. 처음에 그것을 작성한 것이 인간이든, AI가 초안을 작성한 것이든 관계없이, 인간이 그 자리에서 바로 열어 읽고, 틀렸다면 그 자리에서 바로 고칠 수 있다는 성질은 변하지 않습니다. 중요한 것은 「누가 처음 썼는가」가 아니라, 「항상 인간이 검증하고 수정할 수 있는 형태인가」입니다.

실무적으로는 이 세 가지를 역할 분담시키는 하이브리드 방식이 현실적이라고 생각합니다.

MOC 라우팅 (Coarse) → Embedding (Fine, 리프 노드 내부) → GraphRAG (다단계 관계 추론이 필요할 때만 부분적으로 이용)

여기까지 읽으면 「그렇다면 왜 아무도 하지 않는가」라는 의문이 들 것입니다. 솔직하게 말씀드리겠습니다.

• MOC는 공식 사양이 아니라 단순한 관습입니다. 운영 품질이 사용자에게 달려 있어 범용 플러그인으로 만들기 어렵습니다.
• 다단계 LLM 추론(MOC를 한 단계씩 내려가는 과정)은 Embedding의 단일 벡터 계산보다 느리고 비용도 높습니다. 게다가 이 비용은 검색할 때마다 매번 발생합니다. GraphRAG의 비용이 주로 사전 인덱스 구축 시(단 한 번) 발생하는 것과는 대조적입니다. 또한 발상 자체가 아직 새롭습니다 (Karpathy Wiki, obsidian-wiki...

、PageIndex(최근 구현 사례들 모두)를 포함하여, 이를 제품화할 주체가 아직 적습니다. '사용자의 구조를 신뢰한다'는 설계는 불특정 다수에게 배포하는 범용 도구에게는 리스크가 높기 때문입니다(폴더가 곧 개념이라는 전제가 무너진 사용자도 많습니다).

지금까지의 비용만 보면 Embedding(임베딩) 방식이 더 합리적으로 보일지도 모릅니다. 하지만 Embedding이 저비용인 것은 '개념 구조 그 자체를 유지할 수 없다'는 약점과 맞바꾼 결과입니다(앞서 제시한 비교표와 같이). Embedding이 포착할 수 있는 것은 어디까지나 텍스트 자체의 의미적 유사성입니다. '어휘는 다르지만 인간이 이 두 가지는 관련이 있다고 판단했다'는, 텍스트 외부에 존재하는 분류 의도까지는 반영되지 않습니다. MOC가 지불하는 매번의 추론 비용은, '인간이 이미 검증한, 조작 없는 구조를 그대로 사용할 수 있다'는, Embedding에는 없는 보증에 대한 대가라고 이해해 주세요.

즉, 이것은 기술적인 장벽이라기보다, Vault(볼트)를 깔끔하게 정리해 둔 사람이 애초에 소수이며, 또한 범용 도구로 만들기에는 운영 품질에 대한 의존도가 너무 높다는 것이 실태에 가깝다고 생각합니다. 반대로 말하면, 평소에 MOC를 정성스럽게 유지하고 있는 개인의 Vault라면 지금 바로 실천할 수 있는 이야기이기도 합니다.

이론 무장은 필요 없으며, 구현 자체는 매우 심플합니다.

Vault/
├ AI/
│ ├ MOC.md
...

• 각 디렉토리에 MOC.md를 두고, Root MOC에서 찾아 들어갈 수 있도록 한다. - AGENTS.md(또는 CLAUDE.md 등)에 「MOC → MOC → grep」 순서로 탐색하라는 지시를 몇 줄 적는 것만으로 작동한다.

• 디렉토리를 가로지르는 관계(즉, 나무 구조가 아닌 그래프의 문제)는, 교차 전용 MOC를 만들어 Root나 도메인 MOC에서 상호 링크를 걸어두면 해결된다. - 이것은 obsidian-wiki가 기계적으로 검출하려고 하는 'bridge page'를, 인간이 처음부터 명시적으로 준비해 두는 것과 동일한 효과를 가지는 더 확실한 방법이다.

• 핵심은 Root MOC가 '이 쿼리는 교차 MOC를 봐야 하는가'를 판단할 수 있도록, Root(또는 도메인 MOC)에 교차 MOC로의 링크와 간단한 요약을 적어두는 것입니다.

• 모든 루트를 MOC에 살며시 연결해 두기: 고립된 노트(Orphan note)를 줄이고, MOC나 상위 개념 노트로부터의 WikiLinks를 의식적으로 붙인다. 위의 교차 전용 MOC도 이 일환이다.

• 전체 검색(grep)은 '최후의 수단'으로 위치시키기: AI에게 「먼저 MOC를 따라가 보고 목적의 정보를 찾지 못할 경우에만, 보조 수단으로서 grep을 사용한다」는 우선순위를 의식시킨다.

• MOC 단계에서 개념을 완만하게 일반화해 두기: 멀티 에이전트나 AI가 대외용 아웃풋(집필 등)을 수행할 경우, MOC 단계에서 개념이 적절히 일반화되어 있다면 AI는 불필요한 문맥 번역을 거치지 않고 의도에 부합하는 문서를 만들어낼 수 있다.

• MOC 자체의 초안은 AI에게 맡겨도 좋다: 처음부터 전부 손으로 쓸 필요는 없다. 출력 형식까지 지정한 상태에서 초안을 작성하게 하고, 내용을 인간이 확인 및 수정하여 확정하면 충분하다. MOC가 보증하는 것은 「항상 인간이 검증 및 수정할 수 있는 형태가 되어 있다」는 점이지, 「첫 초안을 누가 썼는가」가 아니다.

「AI/ 폴더의 내용을 모두 읽고, AI/MOC.md를 만들어줘. 헤더는 ## 개념 노트, ## 실험 로그, ## 관련 도메인과 같이 분류하고, 각 항목은 [[노트명]] — 한 줄 요약 형식으로 리스트를 만들어줘. 내용을 파악하기 어려운 파일이 있다면 억지로 분류하지 말고 그대로 보고해줘」

전체 검색(grep)은 편리하지만, AI에게는 「그저 사막을 불도저로 뒤엎는 듯한 작업」입니다.

인간이 Vault라는 정원에 MOC라는 이름의 오솔길을 닦는다. AI는 그 오솔길을 따라가며, 인간이 의도한 문맥과 스토리에 따라 필요한 열매(지식)를 정확하게 따낸다.

다만, 이것이 만능 처방전은 아닙니다. 위에서 보았듯이, 이 방법이 기능하는 것은 Vault의 구조 자체가 이미 신뢰할 수 있는 형태로 유지되고 있는 경우에 한합니다. MOC가 낡았거나 고립된 노트투성이라면, AI는 잘못된 오솔길을 걷게 될 뿐입니다.

그럼에도 불구하고, 평소에 Vault를 정성스럽게 가꾸어 온 사람에게는 오늘부터 바로 실천할 수 있는 이야기입니다. 당신의 Vault도 AI를 위한 지식의 지도로, 살며시 조율해 보지 않겠습니까?