Obsidian × AI로 노트의 72.8%가 만들어진 채 방치되는 문제 — 자동화는 '소비 측면'에 집중하다
요약
Obsidian과 AI를 활용해 노트를 자동 생성하는 과정에서 '콘텐츠가 쌓이기만 하고 사용되지 않는' 문제를 발견했습니다. 이 글은 단순히 노트의 양적 증가에 집중하기보다, 실제 지식 관리 시스템(Vault)을 어떻게 구조화하고 맥락을 유지할지에 대한 해결책을 제시합니다.
핵심 포인트
- 노트 생성 자체는 쉬우나, 활용 및 연결이 핵심 과제입니다.
- 단순히 '수정되지 않은 노트 비율'에 집착하기보다 근본적인 시스템 개선이 필요합니다.
- 지식의 맥락 유지를 위해 '핫 캐시(hot cache)'와 같은 임시 메모리 구조를 도입해야 합니다.
- 노트 관리 시, 장기적 지식과 단기적 맥락을 분리하여 관리하는 것이 중요합니다.
Obsidian에 AI를 결합한 글은 많습니다. 저도 여러 번 시도했습니다. 클립을 자동으로 노트로 만들고, RSS 피드를 요약하여 저장하며, 회의록을 정리합니다. 콘텐츠 생성(Generation)은 이미 해결된 문제입니다.
그런데도 Vault가 좋아지고 있다는 실감이 나지 않았습니다. 노트는 확실히 늘어나고 있습니다. 늘어난 것이 무엇에 도움이 되는지 스스로 설명할 수 없었습니다.
설명할 수 없는 것은 셀 수밖에 없기에, Vault의 git 기록을 집계했습니다(2026-08-05 시점).
만들어진 후 한 번도 수정되지 않은 노트가 72.8%나 있었습니다.
이 글은 그 숫자를 어떻게 해석했고, 거기서부터 설정을 어떻게 재구성했는지에 대한 기록입니다.
📊 먼저 숫자 보기
Vault는 실제 노트 약 215개로 구성되어 있습니다. 내역은 다음과 같습니다.
| 폴더 | 본수 | 종류 |
|---|---|---|
Study/ | 63 | 학습 노트 |
Reference/ | 45 | 외부 지식(영구) |
daily/ | 36 | 일기・주간 기록 |
System/ | 32 | 자체 제작 시스템 매뉴얼 |
Memo/ | 13 | 개인 메모 |
Inbox/ | 7 | 미분류 |
| 기타 | 약 19 | Projects / MOC / Blog |
Vault는 git으로 관리하고 있으며, pre-commit hook이 frontmatter의 updated 필드를 자동으로 업데이트합니다. 즉, 노트를 수정하면 반드시 커밋에 기록됩니다. 그렇다면 '커밋에 한 번만 등장하는 노트' = 만들어진 후 한 번도 수정되지 않은 노트로 셀 수 있습니다.
git log --name-only --pretty=format: --diff-filter=AM -- '*.md' \
| grep -v '^$' | sort | uniq -c | sort -n \
| awk '$1==1{c++} END{print c}'
결과:
기록에 등장하는 .md: 254건(삭제 포함)
그 중 커밋이 1회만 있는 것: 185건 → 72.8%
🔍 기각한 가설들
숫자를 보고 변명거리를 찾기 전에, 먼저 스스로 깨뜨린 해석부터 적겠습니다. 여기를 건너뛰면 이 숫자는 단순한 자극에 불과합니다.
'수정되지 않았다 = 읽히지 않았다'는 아니다. 이것이 가장 큰 유보 사항입니다. git은 읽기를 기록하지 않습니다. 자주 참고하는 치트 시트처럼 완성도가 높아 수정할 필요가 없는 경우가 흔하게 있습니다.
애초에 수정할 수 없는 종류의 노트가 있다. daily/ 폴더의 36개는 일기이므로 나중에 수정하지 않습니다. Study/ 폴더의 63개도 시험이 끝나면 쓸모없어집니다. 이 99개를 제외하면 모수(母数)가 크게 줄어듭니다.
따라서 '72.8%가 사장되었다'고 읽는 것은 부정확합니다. 제가 실제로 어려움을 겪었던 것은 비율이 아니라 다음 세 가지였습니다.
Inbox가 영원히 비지 않는다— 클립은 쌓인다. 분류는 '나중에'.
링크가 걸리지 않는다— 신규 노트가 고립된 채로. 그래프가 별가루처럼 된다.
어제의 맥락이 사라진다— 세션을 열 때마다
이러한 500단어 이내의 '핫 캐시(hot cache)'를 단 하나만 가지고, 세션 시작 시에 자동으로 로드됩니다. AI에게 "기억해줘"라고 부탁할 필요가 없어집니다.
중요한 것은 저널(Journal)로 만들지 않는 것입니다. 계속 추가하다 보면 반드시 비대화되어, 맥락을 잡아먹는 장식품이 될 뿐입니다. /hot
명령어(Command)를 통해 매번 전체 내용을 덮어쓰고, "다음 세션에서 당장 필요할 것"만 적습니다. 영구적인 지식은 실제 노트에 두고, 여기서는 링크로 가리키는 역할만 하게 합니다.
2. PostToolUse 후크(Hook)로 편집 직후 lint 실행하기
파일을 수정한 직후에, 링크 끊김, frontmatter 누락, 폴더 규약 위반 등을 검사합니다.
/lint
이것을 명령어(Command)로 가지고 있을 때는 거의 치지 않았습니다. 지금은 편집할 때마다 자동으로 실행됩니다. 규약은 깨지는 순간 지적받지 못하면 지켜지지 않습니다.
3. 신규 노트 작성 시, 의미가 비슷한 기존 노트 제안하기
고립된 노트는 "나중에 링크를 걸자"라며 영원히 고립됩니다. 그래서 신규 노트를 저장하는 순간에, 임베디드 검색(embedded search)으로 의미가 비슷한 기존 노트를 보여줍니다.
키워드 일치가 아니라 임베딩(embedding)이라는 점이 핵심이라, 용어는 다르지만 같은 이야기를 하는 노트가 걸립니다. Zettelkasten에서 정말 필요한 건 바로 그런 경우입니다.
⚠️ 효과가 없었던 것들
솔직히 말씀드립니다.
알림을 늘리는 방향은 효과가 없었습니다. 시작 시 대시보드에는 미커밋(uncommitted) 개수, Inbox 잔여량, 고립 노트 수 등 나열할 만한 것이 얼마든지 있습니다. 하지만 많이 나열할수록 읽지 않게 됩니다. 지금은 하드코딩으로 최대 3줄로 제한하고, 초과분은 "기타 n개"로 접는 방식으로 처리했습니다. 상한선은 운영으로 지키는 것이 아니라, 구현(implementation)으로 지켜야 합니다.
RSS의 로컬 요약도, 효과를 본 것은 요약의 질이 아니라 본수의 상한선이었습니다. 현재는 피드당 최신 6개, 한 번에 처리하는 총 개수는 18개로 제한하고 있습니다.
MAX_PER_FEED = 6 # 1피드당 볼 최신 건수
MAX_TOTAL = 18 # 한 번에 다룰 총 건수의 상한선
상한선을 넘어서면, 읽어낼 수 없는 양이 Inbox에 쌓입니다. 그것은 "생성 과잉(over-generation)"을 다른 곳에서 재현하고 있을 뿐입니다.
즉, 자동화 기능을 추가하면 소비 부족(consumption deficit)이 악화되는 방향으로도 쉽게 무너질 수 있습니다. 무엇을 더하는 것이 생성 측면인지 소비 측면인지를 매번 확인하지 않으면, 같은 함정에 빠집니다.
📦 공개했습니다
이 설정 일체를 정제하여 공개합니다.
데모용으로 옮겨 적은 것이 아니라, 실제로 매일 작동하고 있는 설정입니다. 동기화 스크립트가 개인 경로의 대체 누락을 감지하면 비정상 종료되도록 했습니다.
- 슬래시 명령어 11개( /triage, /weekly-review, /save, /lint, /research 외) - 후크 9개(SessionStart / PostToolUse / Stop 계열)
- 스킬 8개, 서브 에이전트 5개
- macOS + Claude Code 전제, MIT 라이선스
🔄 2주 후에 다시 계산해 보니
지금까지의 시스템을 가동한 상태에서, 2주 후(2026-08-19)에 같은 명령어를 적용했습니다.
역사에 등장하는 .md: 354건
그중 1 커밋만 있는 것: 218건 → 61.6%
11포인트가 하락했습니다. 하지만 이 차이를 시스템의 효과라고 단정할 수는 없습니다. 같은 기간 동안 노트 자체가 215개에서 261개로 늘어났고, 분모와 분자 모두 움직였습니다. 시간이 지날수록 오래된 노트는 접촉 기회가 늘어난다는 당연한 효과도 섞여 있습니다.
말할 수 있는 것은 "비율이 하락했다"까지만입니다. 그래도, 같은 명령어로 추적할 수 있는 지표를 하나 가지고 있으면, 자동화를 추가한 후에 효과가 있었는지 나중에 검산할 수 있습니다. 이것이 지난 2주 동안 가장 유용했습니다. 숫자 자체보다, 숫자를 다시 가져올 수 있는 상태가 더 중요합니다.
✍️ 요약
- Obsidian × AI로 자동화할 때,
추가하려는 것이 생성 측면인지 소비 측면인지를 매번 확인해야 합니다. - 소비 측면의 시스템은
명령어로 만들지 않습니다. 치게 되지 않으므로, 후크에 가깝게 배치합니다. - 알림은 늘리면 읽지 않게 됩니다.
상한선을 먼저 정합니다. - 숫자는 한 번으로 끝내지 않고,
다시 가져올 수 있는 형태로 만듭니다. 효과가 있었는지 나중에 검산할 수 있습니다. - 그리고 자신의 Vault를 한번 세어보세요. 저는 72.8%였습니다.
명령어(command) 하나로 나옵니다. 저의 72.8%보다, 당신의 숫자가 더 유용합니다.
논의 (Discussion)

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기