Obsidian + Claude Code로 만든 블로그 글감 파이프라인
2026.04.23좋은 글감은 어디서 사라지는가
블로그 글감은 보통 작업하다가 떠오른다. "이거 정리하면 좋겠는데"라는 순간이 하루에도 몇 번씩 있다. 그런데 그날 저녁이면 절반은 잊어버린다. 그 다음 날이면 다 사라진다.
문제는 글감을 적는 데 마찰이 너무 컸다. 노션 열기, 메모 앱 열기, 폴더 찾기 — 그동안 다음 작업이 들어오면 글감은 휘발된다.
해결책은 마찰을 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단계 파이프라인이다.
- Stage 1: Blog Seeds 폴더 스캔, 글감 후보 제시
- Stage 2: 기존 글 분석, 스타일 가이드 추출
- Stage 3: 자료 조사 (WebSearch + 시드 보강)
- Stage 4: 팩트 체크
- 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 둘 다 클라이언트가 있다
정리
블로그 글감을 잃지 않으려면 마찰을 0에 가깝게 만들어야 한다. 사람이 결정해서 적는 게 아니라, 시스템이 알아서 적게 한다.
이 파이프라인의 핵심은 두 줄이다.
- CLAUDE.md에 "의미 있는 작업 후 시드를 저장하라"는 규칙
- 글을 쓸 때는
/blog-write obsidian한 줄
Obsidian 폴더가 글감의 저수지 역할을 하고, blog-write 스킬이 그 저수지에서 글을 길어 올린다. 사람은 결정하는 자리에만 들어가고, 나머지는 자동이다.
CLAUDE.md 안티패턴 글에서 다뤘듯, CLAUDE.md에 자주 변하는 정보는 안 들어간다. 하지만 이런 자동화 규칙은 한 번 정하면 거의 바뀌지 않으니 들어가기 좋다. 한 줄짜리 규칙이 글감을 평생 안 잃게 만든다.