TL;DR

• AI에게 노트를 계속 쓰게 하면, Vault는 '내용이 얕은 AI 생성 노트'로 가득 차게 되어 검색 노이즈가 된다. 이른바 **AI 슬러지 (AI Sludge)**다. - 하지만 나는 AI에게 노트를 쓰게 하는 것을 그만두지 않을 것이다. 일상의 수집·학습·발신을 반자동화하는 것은 앞으로도 계속할 것이다. 그만두는 것이 아니라, 쓰게 만든 것을 정리·감사하는 층을 한 단계 더 추가하는 것이다. 그 정리와 감사도 AI (Claude Code)에게 맡겼다. - 직접 만든 /vault-audit 스킬로 고립된 노트, 끊긴 링크, 태그 혼란을 기계적으로 탐지하고, MOC (Map of Content)로 재구조화했다. 결과적으로 고립된 노트는 445개 파일 중 143개 → 116개로 줄었으며, 끊긴 링크는 탐지율 22%에서 거의 0%가 되었다. - 다만 솔직히 말하자면, 이 시스템을 장기적으로 운용하며 검증하는 것은 이제부터이다. 본 기사는 '완성된 은탄환 (Silver Bullet)'이 아니라, 작동하는 구현과 설계 판단의 기록이다.

이 기사에서 다루는 것은 Obsidian Vault를 'AI가 읽고 쓰는 메모리 층'으로 운용하기 위한 frontmatter 규약, Dataview를 사용한 자기 감사형 MOC, Claude Code 스킬이라는 세 가지 구체적인 부품이다. 모두 복사해서 붙여넣을 수 있는 코드로 제시한다.

배경: 이 세컨드 브레인은 무엇이며, 왜 만들었는가

본론에 앞서, 감사의 대상이 된 Vault 자체의 성립 과정을 적어둔다. '왜 어지러워졌는가'는 '왜 감사가 필요해졌는가'와 동전의 양면이기 때문이다.

이 리포지토리 (Obsidian Vault + Git으로 운용 중인 개인의 디지털 가든)는 2026년 2월에 Notion에서 이주하며 시작했다. 동기는 두 가지였다. 하나는 Notion의 동작이 무거웠다는 점. 다른 하나는 AI가 뱉어내는 Markdown 파일을 그대로 둘 수 있는 장소가 필요했다는 점이다.

당초에는 전면 이주가 아니라 역할 분담으로 시작했다. "Obsidian = AI 생성물과 문서의 뷰어", "Notion = 태스크·프로젝트 관리"라는 병용 방식이다. Markdown은 플레인 텍스트(Plain Text)이므로 데이터 락인 (Data Lock-in)이 낮고, AI 도구와의 상성이 좋다. 이 판단은 지금도 옳았다고 생각한다.

그로부터 Claude Code의 스킬군을 통해 일상의 정보 수집·학습·발신·회고를 반자동화해 왔다. 트렌드 수집, URL 요약, 학습 노트, 사고 정리, 기사 집필, 주간 리뷰 ── 이것들이 각각 content/ 하위에 파일을 생성해 나간다. CLAUDE.md나 Hooks를 통해 Claude Code를 '심어두는' 하네스 엔지니어링 (Harness Engineering)적인 방식이다.

그리고 반년 후, Vault는 440개가 넘는 Markdown 파일로 성장해 있었다.

여기서 문제가 발생한다. 파일은 계속 늘어나는데, 그것들을 묶어주는 구조가 자라나지 않았다. 노트는 작성된 순간부터 고립되고, 다시는 참조되지 않는 것들이 쌓여간다. 축적량은 늘어나는데, 떠올릴 수 있는 지식은 늘어나지 않는다. 세컨드 브레인(Second Brain)으로서는 오히려 기능 부전이다.

왜 '쓰게 하는 것'에 '정리·감사하게 하는 것'을 더했는가

어지러워진 정체를 먼저 자신의 언어로 언어화했다. 그리고 조사해 나가는 과정에서, 이것이 나만의 문제가 아니라 2025~2026년에 PKM (Personal Knowledge Management) 업계에서 "AI 슬러지 (AI Sludge)"로 논의되고 있는 문제라는 것을 알게 되었다.

AI 슬러지란, AI가 생성한 '얕고 무난한' 노트가 지식 베이스를 메워버려 검색을 노이즈화하고 기억의 정착을 방해하는 현상을 가리킨다. 대책으로서 반복적으로 언급되는 정석은 세 가지가 있다.

• Human-in-the-Loop: AI 출력은 일단 Inbox / Draft에 머물게 하고, 인간이 자신의 언어로 다시 쓴 것(Rewrite)만 영구 노트로 승격시킨다.
• AI의 역할을 '생성'에서 '정리·연결'로 한정한다: AI에게 문장을 쓰게 하는 것이 아니라, 링크 제안·의미 검색·메타데이터 정리에 사용한다.
• 그라운딩 (Grounding)의 제한: 외부 지식이 아니라 자신의 노트만을 참조원으로 삼는다.

여기서 나의 입장을 분명히 해두겠다. 두 번째 방식처럼 'AI에게 쓰게 하는 것을 그만둘' 생각은 없다. 일상의 트렌드 수집도 학습 노트도 기사 초안도, 앞으로도 계속 Claude Code의 스킬에 쓰게 할 것이다. 생성의 반자동화는 이 세컨드 브레인의 가치 그 자체이기 때문이다.

그 대신에 택한 것은 「쓰게 하는 것」에 「정리·감사하게 하는 것」을 덧붙이는 접근 방식이다. 생성을 제한하는 것이 아니라, 생성물이 쌓이는 하류 단계에 감사층(audit layer)을 한 겹 끼워 넣는 것이다. AI가 뱉어낸 노트를 다른 AI(동일한 Claude Code이지만 「감사역」으로서 행동하게 함)가 순회하며 구조화하고 탐지한다. 생성을 멈추지 않으면서 슬러지화(sludge)를 방지하겠다는 도박이다.

로컬 임베딩(local embedding)으로 노트 간의 관련성을 추천하는 Smart Connections나, 로컬 퍼스트(local-first) 세컨드 브레인인 Khoj 등 기존 도구들은 모두 「AI에게 검색·연결을 돕게 하는」 방향으로 나아가고 있다. 내가 해야 할 일은 Claude Code를 이 「감사역」으로 심어두는 것이었다.

전체 아키텍처

만든 메커니즘은 3개 층으로 구성되어 있다.

• frontmatter 규약── 각 노트에 기계 판독 가능한 메타데이터(area, tags, AI 생성물을 추적하는 origin/human_review)를 갖게 하는 토대
• MOC (Map of Content)── 토픽별 허브 노트. 인간의 목차와 AI의 탐색 기점을 겸함
• Claude Code 스킬 /vault-audit── Vault를 순회하며 고립된 노트, 링크 끊김, 태그 위반을 기계적으로 탐지

이후, 이 3개 층 중 흥미로운 부분을 구현 내용과 함께 설명한다.

① frontmatter에 "For AI Agents" 블록을 심기

MOC는 「토픽의 지도」다. 예를 들어 「AI 에이전트」에 관한 노트를 하나의 허브 노트로 집약하고, 거기서 각 노트로 찾아갈 수 있게 한다. Obsidian 커뮤니티에서는 Nick Milo의 LYT/MOC로 알려진 수법이다.

여기서 한 가지 기교를 부렸다. MOC의 서두에 인간을 위한 본문과는 별개로, AI 에이전트를 위한 네비게이션 블록을 기계 판독 가능한 형태로 배치했다.

> [!NOTE] For AI Agents
> - purpose: AI 에이전트 관련 노트·기사·사고 정리의 허브
> - key_notes: ../notes/tech/2026-04-14_openclaw-vs-hermes.md, ../articles/published/2026-02-05_multi-agent-building-guide.md
...

purpose (이 MOC가 묶는 범위), key_notes (최우선 노트로의 경로), active_context (현재 진행 중인 문맥), last_curated (최종 정리일)를 하나의 블록으로 모아두었다.

목표는 이렇다. Claude Code가 Vault를 읽을 때, 갑자기 440개 이상의 파일을 grep 하는 것이 아니라, 먼저 HOME MOC → 토픽 MOC의 For AI Agents 블록 순으로 내려오면 「지금 읽어야 할 노트」에 최단 거리로 도달할 수 있다. 인간이 사용하는 목차를 그대로 AI의 탐색 인덱스로 이중 활용하는 것이다.

② MOC를 자기 감사형으로 만들기 (Dataview outlinks 제외 쿼리)

이 부분이 개인적으로 가장 마음에 드는 부분이다.

MOC는 수동으로 큐레이션한다. 하지만 「이 토픽의 노트를 전부 올렸는가?」를 인간이 계속 파악하기는 어렵다. 누락되는 경우가 반드시 발생한다.

그래서 Dataview 플러그인을 사용하여, 「이 토픽의 태그가 붙어 있음에도 불구하고, 아직 이 MOC에서 링크하지 않은 노트만」 자동으로 표시하는 쿼리를 각 MOC의 끝에 심어두었다.

LIST
FROM #ai/agent or #hermes-agent or #openclaw
WHERE !contains(this.file.outlinks, file.link) AND area != "moc" AND file.path != this.file.path
SORT file.mtime DESC

핵심은 WHERE !contains(this.file.outlinks, file.link) 부분이다. this.file.outlinks는 「이 MOC가 걸어둔 링크」의 목록을 가리킨다. 거기에 후보 노트가 포함되어 있지 않은 것만 표시한다.

결과적으로 이 목록에 나타나는 것은 「태그상으로는 동료이지만, 아직 MOC에 수록되지 않은 노트」 즉, 수록 후보뿐이게 된다. 수동으로 링크를 한 줄 추가하면, 해당 노트는 다음 재렌더링 시 자동으로 이 목록에서 사라진다. 리스트가 비게 되면 「이 태그의 노트는 모두 수록 완료됨」이라는 상태를 한눈에 파악할 수 있다.

MOC가 자신의 누락을 항상 지적해 주는, 자기 감사형 (Self-auditing) 허브 노트가 된 셈이다. 태그의 표기 불일치(후술)에 대비하여, 관련 태그를 or로 여러 개 나열해 두는 것이 작은 요령이다.

③ /vault-audit로 고립 노트 · 링크 끊김 · 태그 위반을 기계적으로 탐지

Dataview는 「Obsidian을 열고 있을 때」의 상시 모니터링이다. 다른 한편으로는 「Claude Code 측에서 일괄적으로 건강 검진을 수행하는」 수단도 필요했다. 그래서 /vault-audit라는 읽기 전용 스킬을 만들었다.

Claude Code의 스킬은 SKILL.md (지시서)와 scripts/ (실행 코드)로 구성된다. /vault-audit의 검사 항목은 4가지다.

• links: 상대 Markdown 링크의 실재 여부 검증. Vault 외부(~/.claude/ 등)로의 참조는 별도 분류 -
• orphans: 어디에서도 링크되지 않은 완전 고립 노트와, MOC에서 추적할 수 없는 노트의 탐지 -
• tags: 정규 태그 사전과의 대조 (표기 불일치 탐지) -
• frontmatter: 필수 필드 누락 체크

스크립트의 핵심은 모든 Markdown을 스캔하여 역링크 맵 (Inbound link map)을 만들고, 고립된 노트를 찾아내는 부분이다.

def build_inbound_map(files: list[Path]) -> dict[Path, set[str]]:
    """각 노트가 「어떤 파일로부터 링크되고 있는지」를 집계한다."""
    inbound: dict[Path, set[str]] = {}
    ...

역링크 수가 0이면 완전 고립, 역링크는 있지만 MOC로부터의 링크가 하나도 없다면 「MOC 미수록」으로 분류한다. 출력은 JSON 형식이며, Claude 측이 이를 읽어 일본어 리포트로 정형화하고, 나아가 「이 고립 노트를 이 MOC에 넣는 건 어떨까?」라는 수록 제안까지 내놓도록 설계했다.

포인트는 이 스킬은 파일을 일절 수정하지 않는다는 점이다. 탐지와 제안에 집중하고, 수정은 인간의 판단에 맡긴다. 「AI에게 정리시킨다」고는 하지만, 파괴적인 변경을 자율적으로 실행하는 것은 두렵다. 읽기 전용이라는 제약을 구현 레벨에서 지킴으로써, 안심하고 몇 번이고 돌릴 수 있다.

참고로, frontmatter 체크는 기존의 수정 스킬(/vault-migrate) 코드를 재사용하고 있다. 탐지 역할(vault-audit)과 수정 역할(vault-migrate)을 별개의 스킬로 나누고, 탐지 역할이 수정 역할을 가리키도록 역할 분담을 했다.

실측 결과: 고립 노트 143 → 116

시스템을 대략적으로 구축하고, 첫 번째 /vault-audit를 돌린 결과가 다음과 같다.

Before (MOC 도입 전)

• 스캔 대상: 445 파일
• 완전 고립 노트: 143건
• MOC 미수록: 20건
• 링크 끊김: 수정 전 초기 감사에서 125건 중 28건 (약 22%)
• 태그 위반 (표기 불일치): 79건

「그래프 뷰가 어지럽다」는 느낌의 정체가 고립 노트 143건이라는 숫자로 명확히 보였다.

여기서부터 감사가 탐지한 고립 노트를 수록 원천으로 삼아, MOC 4개(AI 에이전트 / Claude Code / 개발 환경 / YouTube 운영)를 만들었다. 탐지 결과 그 자체를 사용하여 MOC를 채워 넣는 순환 구조다.

After (MOC 4개 수록 후)

• 완전 고립 노트: 116건 (27건이 MOC를 통해 연결됨)
• MOC 미수록: 15건
• 링크 끊김: 수정을 통해 남은 1건 (이마저도 표기 예시라 실질적 해가 없음) = 거의 0

단 한 번의 작업으로 고립이 32건 줄었다. 아직 116건이 남아있지만, 이는 「다음에 만들어야 할 MOC의 토픽」이 숫자로 보인다는 뜻이기도 하다. 태그 집계를 보니 툴 선정 · 구독 관리 계열의 노트가 뭉텅이로 고립되어 있었다 ── 이것이 다음 MOC 후보다. 감사가 다음 수까지 가리켜 주는 것이다.

시행착오 · 주의사항

솔직하게, 잘 되지 않았던 점과 주의사항을 적어둔다.

태그의 표기 불일치가 상상 이상으로 많았다

감사(Audit)해 보니, 482종류의 태그 중 302종류가 단 한 번만 사용된 일회성 태그였다. ai / AI / ai-agent / ai/agent와 같이 동의어 태그가 분열된 경우도 많았다. Dataview 쿼리에서 태그를 or로 여러 개 나열해야 했던 이유가 바로 이것이다. 정규 태그 사전을 만들어 신규 부여분부터 통일하는 방침을 세웠으나, 기존 302종류에 대한 소급 수정은 비용 대비 효율이 맞지 않아 포기했다.

프라이빗한 지식 베이스를 AI에게 읽히는 것에 대한 주의사항

세컨드 브레인(Second Brain)에는 개인적인 사고나 판단의 기록이 들어간다. 그것을 AI 에이전트(AI Agent)에게 읽히는 이상, 어떤 파일을 참조 범위에 포함할지는 의식적으로 설계해야 한다. 나는 Vault 외부(~/.claude/의 메모리 파일)로의 직접 링크를 감사 시 'Vault 외부 참조'로 계속 가시화하는 방식을 택했다.

그리고 최대의 한계: 장기 운용 검증은 이제부터

지금까지 써 내려온 메커니즘은 사실 단 하루 만에 구축한 것이다. MOC(Map of Content)가 정말로 일상적인 검색과 회상을 편하게 해주는지, /vault-audit를 주 단위로 돌리는 운용이 지속될 수 있을지 ── 그 효과 검증은 아직 시작되지 않았다. 본 기사를 "이것으로 해결했다"라는 성공담으로 읽지 말아 주길 바란다. 어디까지나 "이렇게 설계하여 초기 구축까지 작동했다"라는 기록이다.

요약: 해외 방법론들 사이에서의 위치

세컨드 브레인 구축 방법론에는 확립된 계보가 있다.

• PARA (Tiago Forte): Projects / Areas / Resources / Archives의 4가지 분류. 실행 가능성에 따라 배치한다.
• LYT / MOC (Nick Milo): 폴더에 의존하지 않고, MOC(허브 노트)와 양방향 링크(Bidirectional Link)로 동적으로 연결한다.
• Zettelkasten (Niklas Luhmann): 1노트 1아이디어의 원자성(Atomicity)과 링크를 통한 네트워크.
• Johnny.Decimal (Johnny Noble): 10개 영역 × 10개 카테고리의 엄격한 번호 그리드.

이번에 수행한 작업은 이 중에서 LYT/MOC를 토대로 삼으면서, 그 큐레이션(Curation)과 감사를 AI 에이전트에게 대신 맡긴 것이라고 할 수 있다. MOC 방법론 자체는 새롭지 않다. 새로운 것은 "MOC 수록 누락"이나 "고립된 노트"라는 MOC 운용의 약점을 AI의 기계적 탐지로 메운다는 조합이다.

조사한 바로는, AI를 이용한 Vault 감사(고립된 노트 탐지·링크 제안)는 "개념 선행"으로 논의되는 경우가 많고, 실제로 작동하는 스크립트와 운용 플로우(Workflow)까지 구현된 사례는 아직 적다. Smart Connections와 같은 "유사 노트 추천"의 한 단계 앞에는, "자율 에이전트가 Vault를 순회하며 구조를 정돈해 나가는 관리인"이라는 역할이 있다. 그 구체적인 구현 사례를 하나 더할 수 있었다면, 이 글을 쓴 의미가 있다.

AI에게 쓰게 하는 것을 그만두지는 않을 것이다. 계속 쓰게 하되, 어질러진 뇌 속을 정리해 줄 파트너를 한 명 더 준비했다 ── 그것이 이번에 한 일이다. 여기까지가 구축의 기록이다. 실제로 운용해 보니 어땠는지는 다음에 다시 쓰겠다.

Discussion