Obsidian + Claude Code로 만든 블로그 글감 파이프라인

좋은 글감은 어디서 사라지는가

블로그 글감은 보통 작업하다가 떠오른다. "이거 정리하면 좋겠는데"라는 순간이 하루에도 몇 번씩 있다. 그런데 그날 저녁이면 절반은 잊어버린다. 그 다음 날이면 다 사라진다.

문제는 글감을 적는 데 마찰이 너무 컸다. 노션 열기, 메모 앱 열기, 폴더 찾기 — 그동안 다음 작업이 들어오면 글감은 휘발된다.

해결책은 마찰을 0에 가깝게 만드는 거였다. 작업하다가 끝나는 시점에 자동으로 글감이 적혀 있어야 한다. 사람이 결정해서 적는 게 아니라, 시스템이 알아서 적게 한다.

이 글은 Obsidian + Claude Code로 만든 그 파이프라인이다.

전체 흐름

1. Claude Code 세션에서 작업한다
   ↓
2. CLAUDE.md 규칙에 따라 세션 끝에 요약을 Obsidian에 저장
   ↓
3. Obsidian의 Blog Seeds 폴더에 .md 파일이 쌓인다
   ↓
4. 글을 쓰고 싶은 날 /blog-write obsidian
   ↓
5. blog-write 스킬이 시드를 읽고 풀 파이프라인으로 글 작성

5단계인데, 1~3은 자동, 4~5는 한 번의 명령. 사용자 마찰이 거의 없다.

단계 1~3: 시드 자동 저장

핵심은 CLAUDE.md에 세션 요약 자동 저장 규칙을 박는 것이다.

## Obsidian Blog Seeds
 
세션에서 블로그 글감이 될 만한 작업을 했을 때, 요약을 아래 경로에 저장:
`/Users/me/Library/Mobile Documents/iCloud~md~obsidian/Documents/Joowon/Blog Seeds/`
- 파일명: `YYYY-MM-DD-주제.md`
- 내용: 작업 요약, 핵심 포인트, 블로그 키워드

CLAUDE.md는 모든 세션에 자동 주입된다. 이 규칙이 있으면 Claude가 작업이 끝날 즈음 알아서 시드 파일을 만든다.

내가 직접 "Obsidian에 정리해줘"를 안 해도, 의미 있는 작업을 마치면 Claude가 "이번 작업 시드를 저장하시겠습니까?"라고 묻거나 자동 저장한다. 이게 자동화의 핵심이다.

저장된 시드 파일 예시:

# 2026-04-23 Cloudflare 빌드 캐시 디버깅
 
## 작업 요약
Cloudflare Pages 빌드가 8분으로 늘어난 문제 해결. NODE_VERSION 환경 변수 누락이 원인.
 
## 핵심 포인트
- package-lock.json이 git에 있어야 캐시 적용
- _headers 파일로 정적 자산 영구 캐싱
- pnpm으로 갈아타면 추가 단축
 
## 블로그 키워드
cloudflare-pages, build-cache, nextjs, ci-cd

이 시드가 그대로 미래 글의 출발점이 된다.

Obsidian 폴더 구조

내 Obsidian 볼트 구조.

Joowon/
├── Blog Seeds/              # 작업 시드 (자동 저장)
│   ├── 2026-04-12-plan-mode.md
│   ├── 2026-04-13-hooks.md
│   └── drafts/              # blog-write 중간 산출물
│       └── plan-mode/
│           ├── keyword-brief.md
│           ├── style-guide.md
│           └── research-notes.md
├── Projects/
│   ├── joowonkoh-dev/       # 이 블로그 프로젝트 노트
│   ├── JIGUMIA/             # 다른 프로젝트
│   └── Joshua Web/
└── Personal/                # 개인 메모

Blog Seeds/는 글감만, drafts/는 글 쓰는 도중의 중간 산출물(키워드 브리프, 스타일 가이드, 리서치 노트)이 들어간다.

단계 4~5: blog-write 스킬

글을 쓸 때는 한 줄.

> /blog-write obsidian

이 스킬은 5단계 파이프라인이다.

1. Stage 1: Blog Seeds 폴더 스캔, 글감 후보 제시
2. Stage 2: 기존 글 분석, 스타일 가이드 추출
3. Stage 3: 자료 조사 (WebSearch + 시드 보강)
4. Stage 4: 팩트 체크
5. Stage 5: 글 작성 (스타일 가이드 따름) + 이미지 요청서

각 단계의 산출물이 drafts/<slug>/ 아래에 저장된다. 글 한 편이 완성될 때까지 모든 결정이 추적된다.

자세한 정의는 ~/.claude/skills/blog-write/SKILL.md에 있다. 스킬은 description으로 호출되니, MDX 글 작성 작업이 들어오면 자동으로 매칭되기도 한다.

시드의 품질이 곧 글의 품질

이 파이프라인의 효과는 시드 품질에 달려 있다. 시드가 부실하면 글도 부실하다.

내가 시드를 잘 만들기 위해 CLAUDE.md에 추가한 규칙들:

시드 작성 시 포함할 것:
- 작업 중 부딪힌 구체적인 함정 (일반론 X)
- 직접 측정한 수치, 시간, 결과
- 시도했다가 실패한 접근법
- 1인칭 경험담의 핵심 한 문단

추상적인 요약("Cloudflare Pages를 사용했다")보다 구체적인 사실("8분 → 1분 30초로 단축, 원인은 NODE_VERSION 환경 변수")이 좋은 시드다. 좋은 시드는 그대로 본문 인트로가 된다.

시드 → 글 비율

매일 작업한다고 매일 시드가 쌓이는 건 아니다. 내 경험상 비율은 이렇다.

• 작업 세션 30회
• 시드 생성 10회 (의미 있는 작업의 1/3 정도)
• 글로 발전 5~7편 (시드의 절반쯤)

시드가 있다고 다 글이 되는 건 아니다. 일부는 너무 좁거나, 다른 시드와 합쳐야 하거나, 시간이 지나면서 의미가 흐려진다. 그래도 "글감이 사라지는" 문제는 거의 사라졌다.

함정과 트러블슈팅

함정 1: iCloud 동기화 지연

Obsidian을 iCloud Drive에 두면 다른 기기와 동기화된다. 다만 iCloud 동기화가 가끔 늦다. 시드를 만든 직후 다른 기기에서 보려고 하면 안 보일 수 있다. 분 단위 차이라 작업 흐름에 큰 영향은 없다.

함정 2: 파일명 충돌

같은 날 같은 주제로 시드를 두 번 만들면 파일명이 겹친다. CLAUDE.md 규칙에 "파일명 충돌 시 -2, -3 suffix 추가"를 박아둔다.

함정 3: 시드가 너무 길어진다

시드가 본문보다 더 길어지면 본말 전도다. 시드는 5분 안에 읽고 이해할 수 있는 길이가 적당하다. 200~500자 정도. 그 이상은 이미 글에 가깝다.

함정 4: 시드를 안 본다

시드만 쌓이고 글로 안 발전하면 의미가 없다. 매주 한 번 /blog-write obsidian으로 시드 목록을 한 번씩 본다. 시간이 지나도 가치 있는 시드만 남고 나머지는 archive로 보낸다.

다른 도구와의 통합

Obsidian이 아니어도 비슷한 셋업은 가능하다.

• Notion 데이터베이스: API로 시드 자동 추가 가능. 다만 Claude Code에서 파일 시스템 접근만큼 매끄럽지 않다.
• 로컬 마크다운 폴더: 가장 단순. iCloud나 Dropbox로 동기화.
• Bear, Drafts: macOS 친화적 노트 앱. 다만 Claude Code와의 통합이 어렵다.

내가 Obsidian을 고른 이유:

• 평범한 마크다운 파일이라 Claude Code가 직접 읽고 쓸 수 있다
• 폴더 구조와 태그를 자유롭게 짤 수 있다
• 동기화는 iCloud로 무료
• macOS, iOS 둘 다 클라이언트가 있다

직접 겪은 일: 시드 아홉 개 중 글이 된 건 몇 개인가

지금 Blog Seeds 폴더에 노트가 아홉 개 쌓여 있다. 2026-04-02-블로그-리디자인-및-인프라, 2026-07-29-코인푸셔-추첨기-공정성, 2026-08-03-어드민-대시보드-4겹-방어 같은 것들이다.

이 중 하나가 글이 된 경로를 따라가 보면 이렇다. 2026-04-07-터미널-생산성-도구-리서치.md가 먼저 쌓였고, 그 다음 날 터미널 도구 세팅 글이 올라갔다. 하루 차이다. 글을 쓰려고 조사한 게 아니라 이미 쌓여 있던 걸 꺼낸 것이다.

솔직히 말하면 아홉 개 중 여덟 개는 아직 글이 아니다. 파이프라인이 글을 써주지는 않는다. 다만 글감이 사라지지는 않는다 — 그게 이 구조가 하는 일의 전부이고, 그거면 충분하다. 7월 29일에 코인푸셔 공정성을 따져본 기억은 지금 내 머리에 남아 있지 않지만 폴더에는 남아 있다.

붙여 둔 MCP 서버가 지금 하나뿐인데 그게 Obsidian인 것도 같은 이유다. 도구를 늘리는 것보다 글감이 새지 않게 막는 쪽이 먼저였다.

정리

블로그 글감을 잃지 않으려면 마찰을 0에 가깝게 만들어야 한다. 사람이 결정해서 적는 게 아니라, 시스템이 알아서 적게 한다.

이 파이프라인의 핵심은 두 줄이다.

1. CLAUDE.md에 "의미 있는 작업 후 시드를 저장하라"는 규칙
2. 글을 쓸 때는 /blog-write obsidian 한 줄

Obsidian 폴더가 글감의 저수지 역할을 하고, blog-write 스킬이 그 저수지에서 글을 길어 올린다. 사람은 결정하는 자리에만 들어가고, 나머지는 자동이다.

CLAUDE.md 안티패턴 글에서 다뤘듯, CLAUDE.md에 자주 변하는 정보는 안 들어간다. 하지만 이런 자동화 규칙은 한 번 정하면 거의 바뀌지 않으니 들어가기 좋다. 한 줄짜리 규칙이 글감을 평생 안 잃게 만든다.