옵시디언 AI 자동화: raw 폴더에 던지면 분류·요약·백링크까지 붙는 개인 위키 파이프라인

읽은 아티클, GitHub에서 발견한 도구, AI와 나눈 대화에서 건진 인사이트. 이런 것들이 브라우저 탭과 클립보드에서 그대로 증발하는 게 늘 아까웠습니다. "나중에 정리해야지"는 한 번도 지켜진 적이 없습니다. 정리라는 행위 자체가 비용이라서요.

Obsidian을 쓰기 시작한 뒤에도 마찬가지였습니다. 볼트에 파일을 만들 수는 있는데, 태그를 달고 기존 노트와 연결하고 인덱스를 갱신하는 뒷정리가 밀리니까 결국 "잘 정돈된 폴더 하나, 방치된 폴더 아홉"이 됐습니다.

그래서 방향을 바꿨습니다. 정리를 내가 하지 않는 시스템을 만들기로요. 저는 자료를 한 폴더에 던져 넣기만 하고, 분류·요약·백링크 연결은 전부 AI가 합니다. Karpathy가 말한 "Obsidian은 IDE, LLM은 프로그래머, 위키는 코드베이스"라는 그림을 제 볼트에 그대로 구현한 셈입니다. 몇 달째 굴리면서 겪은 시행착오를 정리합니다.

원본은 로컬 마크다운에 둡니다#

처음엔 노션 같은 SaaS도 후보였습니다. 결론은 로컬 마크다운이었고, 이유는 단순합니다.

• AI가 파일을 직접 만질 수 있습니다. 마크다운은 ls, grep, 파일 읽기·쓰기만으로 파이프라인 전체가 돌아갑니다. API 토큰도, 블록 구조 파싱도 필요 없습니다.
• 자동화 인프라가 공짜입니다. macOS launchd로 야간 배치를 돌리고, lock 파일로 동시 실행을 막고, git으로 AI가 망친 문서를 되돌립니다. 전부 파일시스템이라서 가능한 일입니다.
• 소유권이 남습니다. 서비스가 죽어도, 요금제가 바뀌어도 텍스트 파일은 제 디스크에 그대로 있습니다.

특히 세 번째가 컸습니다. 지식 베이스는 10년을 보고 쌓는 자산인데, 그 수명을 남의 서비스에 걸고 싶지 않았습니다.

폴더 구조는 raw에 던지면 끝#

볼트의 위키 영역은 이렇게 생겼습니다.

wiki/
├── raw/            # 원본 소스 투입구. 절대 수정 안 함
│   └── done/       # 처리 완료된 소스가 이동
├── tool-eval/      # 도구 평가 리포트
│   ├── reports/
│   └── index.md
├── intel/          # 개념·패턴·뉴스 분석 문서
│   ├── reports/
│   └── index.md
├── field-notes/    # 작업 세션의 시행착오 기록 (블로그 원료)
├── index.md        # 전체 허브
├── log.md          # 시간순 작업 이력 (append-only)
└── schema.md       # 구조와 규칙의 단일 원천

제 일은 raw/에 파일을 떨어뜨리는 것까지입니다. 웹 클리핑이든, 대화 메모든, GitHub URL 하나 적힌 쪽지든 상관없습니다. 야간에 배치가 돌면서 raw/의 미처리 파일을 하나씩 집어 갑니다.

핵심 규칙 몇 개는 처음부터 schema.md에 못 박아 뒀습니다. raw는 불변입니다. AI는 읽기만 하고, 처리 후 done/으로 이동만 합니다. 원본이 오염되면 나중에 재처리할 방법이 없어서요. 그리고 처리가 완전히 끝난 뒤에만 이동합니다. 중간에 죽으면 다음 실행에서 자연스럽게 재시도되도록요.

던져진 자료는 두 갈래로 나뉜다#

AI가 raw 파일을 읽고 가장 먼저 하는 일은 타입 판별입니다.

• Type A (도구 평가): 본문에 GitHub 레포 URL이 있거나, 도구·라이브러리를 소개하는 내용이면 "이걸 도입할 만한가?"라는 질문으로 평가 리포트를 씁니다. tool-eval/reports/에 쌓입니다. URL이 명시돼 있지 않아도 도구 소개로 보이면 웹 검색으로 레포를 찾아 붙입니다.
• Type B (지식 정리): 평가할 도구가 없는 순수 개념·패턴·뉴스는 "여기서 뭘 배울 수 있나?"로 분석해 intel/reports/에 저장합니다.

애매하면 Type A로 기울입니다. 제가 raw에 넣는 자료 대부분이 "이 도구 써볼까?"라는 맥락이라, 기본값을 그쪽에 두는 게 오판이 적었습니다.

도구 평가 쪽은 인덱스에 점수와 도입 여부 컬럼을 둬서, 나중에 "실제로 워크플로우에 들어간 도구"만 모아 볼 수 있게 했습니다. 평가만 하고 잊는 게 아니라, 몇 달 뒤 "그때 그거 뭐였지?"를 인덱스 한 화면에서 복기하는 용도입니다. 분류가 끝나면 index.md 갱신, log.md에 이력 한 줄, 원본은 done/으로. 이 후처리를 빼먹으면 인덱스와 실제 문서가 어긋나기 시작해서 필수 단계로 묶어 뒀습니다.

고아 문서를 없애는 백링크 규칙#

정리만 하고 끝나면 폴더에 파일이 쌓일 뿐, 위키가 아닙니다. 새 문서가 기존 문서와 [[wikilink]]로 이어져야 그래프가 됩니다. 그래서 문서 생성 직후 링크 주입 단계가 무조건 따라붙습니다.

여기서 가장 크게 데인 게 할루시네이션 링크입니다. AI에게 "관련 문서를 링크해"라고만 하면 그럴듯한 문서명을 지어내서 [[존재하지 않는 문서]]를 만들어 버립니다. Obsidian 그래프에 빨간 깨진 링크가 늘어나는 걸 보고 규칙을 뒤집었습니다. 링크 후보는 실제 존재하는 리포트 파일명 목록에서만 고르게 하고, 주입 후에 매칭 검증을 한 번 더 돌립니다. 목록에 없는 이름은 아무리 그럴듯해도 링크하지 않습니다.

링크는 세 방식으로 들어갑니다. 본문에서 첫 등장하는 참조를 인라인 wikilink로 바꾸고, 문서 끝에 같은 카테고리 문서 몇 개를 "관련" 섹션으로 붙이고, 프론트매터에 원본 소스 역참조를 남깁니다.

## 관련
- [[browser-use]] — AI 에이전트 브라우저 자동화
- [[lightpanda-browser]] — 경량 브라우저 자동화

과유불급도 규칙입니다. 문서당 링크 상한을 정해 두지 않으면 모든 단어가 파랗게 물들고, 그건 링크가 없는 것과 같습니다. 참조가 여러 번 나와도 첫 등장만 링크합니다.

또 하나, wikilink를 태그로 대체하지 않습니다. 처음엔 "태그가 있는데 링크까지 필요한가" 싶었는데, 둘은 역할이 다릅니다. 태그는 검색과 필터링용이고, wikilink는 그래프용입니다. 그래프 뷰에서 문서들이 어떻게 뭉치고 어디가 비어 있는지 보이는 건 링크가 있을 때뿐입니다.

매일 전체를 다시 돌리지 않으려면#

볼트는 계속 자랍니다. 새 문서가 들어오면 기존 문서에도 새 백링크 후보가 생기니, 옛 문서도 주기적으로 재처리해야 합니다. 그런데 매일 밤 전체 문서에 LLM을 돌리면 토큰이 낭비됩니다. 그래서 처리 이력을 각 문서의 프론트매터에 박아 두고, 재처리 여부를 LLM 없이 셸 스크립트만으로 거릅니다.

---
title: some-tool
linker_processed: 2026-04-18
linker_links_count: 7
linker_candidate_pool: 89
---

메타가 아예 없는 신규 문서, 처리한 지 오래된 문서, 처리 시점보다 링크 후보 풀이 크게 자란 문서만 LLM 재처리로 넘어갑니다. 나머지는 토큰 소모 없이 스킵. 이 필터 하나로 야간 배치 비용이 문서 수와 무관하게 일정 수준에 묶였습니다.

여기서도 함정이 하나 있었습니다. 프론트매터가 없는 옛 문서에 AI가 메타데이터를 마크다운 표 안에 끼워 넣은 겁니다. 셸 필터는 YAML 블록만 파싱하니 이 값을 못 읽고, 문서는 매일 밤 "신규"로 분류돼 무한 재처리 루프에 빠졌습니다. 자동화 파이프라인에서는 데이터가 어디에 적히는지까지 형식으로 강제해야 한다는 걸 배웠습니다.

AI가 망친 건 AI가 고친다#

배치 처리는 비용 때문에 싸고 빠른 모델을 씁니다. 링크 매칭 같은 단순 작업엔 그걸로 충분한데, 대량으로 돌리다 보면 일정 비율로 사고가 납니다. 링크만 넣으라고 했는데 본문을 날려 먹는 파괴적 편집, 자기 자신을 링크하는 문서, 위에서 말한 깨진 링크 같은 것들요. 그래서 배치 끝에 실패가 감지되면 더 강한 모델이 헬스 체크를 돕니다. 로그를 읽고 명확한 패턴만 자동 수선합니다. 없는 링크 제거, 잘못 들어간 메타 이관, 반복 실패한 파일은 강한 모델로 재시도. 문서 크기가 원본 대비 크게 줄어든 파괴적 편집은 자동으로 손대지 않고 사람 확인으로 넘깁니다. 모호한 판단까지 자동 수리에 맡기면 수리가 새 사고를 만듭니다. 안전이 속도보다 우선이라는 선을 여기서 지킵니다.

운영 디테일도 전부 파일시스템 수준에서 해결했습니다. 배치가 겹쳐 돌지 않게 lock 파일을 확인하고, 처리 이력은 append-only 로그에 남기고, 뭔가 이상하면 로그부터 봅니다. 데이터베이스도 대시보드도 없지만, 이 정도 규모의 개인 시스템엔 그게 오히려 디버깅하기 쉬웠습니다.

이 시스템에서 제가 하는 일은 이제 두 가지뿐입니다. 자료를 raw에 던지는 것, 그리고 가끔 Obsidian 그래프 뷰를 열어 섬처럼 떠 있는 문서가 없는지 훑는 것. 정리의 비용을 0으로 만들었더니 수집량 자체가 늘었습니다. "정리해야 하는데"라는 부채감이 사라진 게 이 파이프라인의 가장 큰 수익이라고 생각합니다.