Obsidian 노트를 Claude AI 에이전트 파이프라인에 연결하면, 주제 입력 한 번으로 웹 리서치, 글 작성, 팩트 검증, 썸네일 생성, SNS 포스트까지 자동 처리됩니다. 2026년 3월 기준 Antigravity(Google DeepMind의 AI 에이전트 IDE)를 실행 환경으로 사용하면 무료 프리뷰 상태에서 Claude 에이전트를 병렬로 돌릴 수 있습니다.
옵시디언에서 글 쓰면 블로그까지 자동으로 올라간다는 이야기, 어디까지 진짜인지 의심부터 했습니다. “결국 마지막에 사람이 복붙하는 거 아냐?” 싶었거든요. 그 의심을 안고 6개월 전부터 직접 구축해본 결과를 정리합니다.
옵시디언 볼트 안에 Claude 에이전트 팀을 구성하고, 주제 하나 던지면 리서치부터 검증까지 돌아가는 파이프라인을 만들었습니다. 지금은 이 시스템으로 월 20개 이상의 블로그 글을 발행하고 있습니다. 과정이 순탄하진 않았습니다. 에이전트가 팩트를 지어내는 일, 도입부가 매번 똑같은 일, HTML 포맷이 깨지는 일을 수없이 겪었고, 그 삽질을 거쳐서 지금의 구조가 만들어졌습니다.
왜 기존 방식이 답이 아니었나
옵시디언에서 블로그로 발행하는 방법은 여러 가지가 있습니다. obsidian-git 플러그인으로 GitHub에 동기화하고, GitHub Actions로 Hugo나 Jekyll 빌드를 트리거해서 정적 사이트로 배포하는 방식이 대표적입니다.
이 방식은 잘 작동합니다. IRONPARK이나 이예슬님의 블로그에서 실전 사례를 볼 수 있습니다. 문제는 “글을 사람이 직접 다 써야 한다”는 겁니다.
저는 하루에 글을 2~3개씩 발행해야 했습니다. 그런데 리서치에 40분, 글 작성에 60분, 검증에 20분, 썸네일에 15분, SNS 요약에 10분. 한 편에 2시간 반입니다. 하루 3개면 7시간 반이고, 이건 본업이 있는 사람이 유지할 수 있는 구조가 아닙니다.
필요한 건 “발행 자동화”가 아니라 “콘텐츠 생산 자동화”였습니다.
Antigravity가 여기서 어떤 역할을 하는가
여기서 오해가 생기기 쉽습니다. Antigravity는 블로그 발행 플랫폼이 아니라, 에이전트가 일할 수 있는 작업장을 제공하는 IDE입니다.
Antigravity란? Google DeepMind가 2025년 11월에 공개한 AI 에이전트 IDE입니다. VS Code를 포크한 구조로, Gemini 3 Pro, Claude Sonnet 4.5 등의 모델을 병렬로 실행할 수 있습니다. 2026년 3월 현재 무료 프리뷰 상태이며, Gmail 계정만 있으면 사용 가능합니다.
Antigravity의 역할은 간단합니다. 옵시디언 볼트 폴더를 IDE에서 열고, 그 안에 정의된 Claude 에이전트를 실행하는 환경입니다. 글을 쓰는 것도 발행하는 것도 에이전트의 몫이고, Antigravity는 그 에이전트들이 돌아가는 무대입니다.
Cursor에서도 동일한 작업이 가능합니다. 차이점은 Antigravity가 에이전트 병렬 실행에 특화되어 있다는 점입니다. Cursor에서 순차 실행하면 Phase 전체가 약 20분, Antigravity에서 병렬로 돌리면 15분 정도로 줄어드는 체감 차이가 있었습니다.
파이프라인 전체 흐름
실제로 돌아가는 구조를 다이어그램으로 보면 이해가 빠릅니다. 각 Phase 사이에 데이터가 어떻게 흘러가는지 주목하세요.
[옵시디언 inbox 메모 / 글감 시트]
↓
[Antigravity 또는 Cursor에서 Vault 열기]
↓
[blog-pipeline-team 에이전트 호출]
Phase 1: blog-researcher → 웹 검색 + 볼트 참조 + 경쟁 분석 Phase 2: blog-writer → E-E-A-T 구조 + 채널별 포맷으로 작성 Phase 3: blog-reviewer → 팩트 대조 + AI냄새 체크 + 분량 검증 Phase 4: 저장 + SNS 포스트 + blog-ideas 상태 업데이트 ↓ [02.Areas/blog/ 채널별 경로에 MD 또는 HTML 저장] ↓ [(선택) 외부 블로그에 수동/API 발행]
핵심은 .claude/agents/blog-pipeline-team/ 폴더 안에 에이전트 정의 파일들이 있다는 겁니다. blog-lead.md가 오케스트레이터이고, blog-researcher.md, blog-writer.md, blog-reviewer.md가 각 Phase를 담당합니다. 이 파일들이 옵시디언 볼트 안에 있으니, 볼트를 IDE에서 열기만 하면 바로 실행할 수 있습니다.
Phase 1: 리서치 (5분)
@blog-pipeline-team "주제" 한 줄이면 시작됩니다. researcher 에이전트가 웹 검색 5회 이상을 돌리고, 볼트 내 기존 노트를 Grep으로 검색해서 중복을 체크합니다. 경쟁 블로그 상위 3개도 분석합니다.
모든 팩트에는 출처, 날짜, 신뢰도(공식 ⭐⭐⭐ / 매체 ⭐⭐ / 커뮤니티 ⭐)가 붙습니다. 이 단계에서 출처 없는 숫자가 하나라도 있으면 나중에 reviewer가 걸러냅니다.
Phase 2: 글 작성 (8분)
리서치 패키지를 받은 writer 에이전트가 글을 씁니다. 이 부분에서 가장 중요한 설정이 두 가지입니다.
첫째, 채널별 포맷 분기입니다. TECHTAEK은 Markdown, 배당노마드는 인라인 HTML(Blogger용), coinpost는 Markdown입니다. 에이전트가 채널을 자동으로 판단해서 맞는 포맷으로 출력합니다.
둘째, 도입부 패턴 반복 방지입니다. .claude/MEMORY/warm/recent-patterns.md에 최근 사용한 도입부 유형이 기록되어 있고, writer가 이 파일을 읽어서 최근 3개와 겹치지 않는 유형을 선택합니다. “결론부터 말하면”이나 “오늘은 X를 알아보겠습니다” 같은 AI 패턴도 자동으로 피합니다.
Phase 3: 검증 게이트 (3분)
쓰는 사람과 검증하는 사람을 분리했습니다. reviewer 에이전트가 16개 항목을 체크합니다.
- AI냄새: “결론부터 말하면”, “~에 대해 알아보겠습니다” 등 7가지 패턴
- Tropes: 반전 병렬, 자문자답, em dash 과다 등 4가지 구조
- E-E-A-T: 성찰 섹션 3가지 존재 여부, 구체 경험 존재 여부
- 팩트대조: 리서치 패키지의 숫자와 글 본문 숫자 일치 여부
- 분량: Markdown 120줄 이상, 핵심 섹션 12줄 이상
NG가 0개면 PASS, 1~2개면 REVISE(수정 후 재검증), 3개 이상이면 FAIL입니다. 실제로 지금까지 쓴 글의 약 40%가 첫 검증에서 REVISE를 받았습니다. 가장 흔한 이유는 em dash 과다 사용과 팩트 수치 불일치였습니다.
Phase 4: 저장 + 후처리 (1분)
PASS된 글은 채널별 경로에 저장됩니다. 동시에 SNS 포스트(X 280자 + 스레드 500자)가 글 맨 아래에 추가되고, blog-ideas.md의 해당 글감 상태가 🔥에서 ✅로 바뀝니다. recent-patterns.md에 사용한 도입부 유형도 기록됩니다.
6개월 운영하면서 배운 것들
CLAUDE.md가 전부의 시작
볼트 루트에 CLAUDE.md를 놓으면 Claude가 세션 시작 시 자동으로 읽습니다. 여기에 볼트 구조, 에이전트 목록, 행동 원칙을 적어두면 매번 컨텍스트를 설명할 필요가 없습니다.
저는 PARA 구조(Projects/Areas/Resources/Archive), 에이전트 호출 규칙, 블로그 규칙 파일 경로를 CLAUDE.md에 넣어두고 있습니다. 에이전트가 “이 볼트는 어떻게 구성되어 있지?”를 묻지 않아도 되니 실행 시간이 줄었습니다.
writer와 reviewer를 분리한 이유
처음에는 하나의 에이전트가 글 쓰기와 검증을 다 했습니다. 결과는 자기가 쓴 글에 자기가 PASS를 줬습니다. 당연한 겁니다. 자기 글의 문제를 자기가 못 봅니다.
분리한 뒤로 검증 품질이 확 올라갔습니다. 특히 팩트대조에서 효과가 컸습니다. researcher가 수집한 숫자와 writer가 쓴 숫자가 다른 경우를 reviewer가 잡아냅니다. 이건 같은 에이전트가 하면 절대 발견 못 합니다.
모델 선택이 중요하다
현재 설정은 researcher와 reviewer에 haiku급(가벼운 모델), writer에 opus급(무거운 모델)을 쓰고 있습니다. 리서치와 검증은 속도가 중요하고, 글 쓰기는 품질이 중요하기 때문입니다.
모든 Phase에 같은 모델을 쓰면 비용이 3배 넘게 늘어나는데, 품질 차이는 writer 단계에서만 체감됩니다. researcher가 opus급이어도 수집하는 팩트의 수나 정확도에 큰 차이가 없었습니다.
Cursor와 Antigravity, 뭘 쓸까
솔직히 둘 다 됩니다. 파이프라인 자체는 .claude/agents/ 폴더 구조에 의존하지, 특정 IDE에 종속되지 않습니다.
다만 차이가 있습니다. Cursor는 안정적이고, Max Mode에서 opus급 모델을 바로 쓸 수 있습니다. Antigravity는 에이전트 병렬 실행이 되고, 무료 프리뷰 기간에는 비용 부담이 적습니다.
저는 평소에 Cursor를 쓰고, 한 번에 여러 글을 돌릴 때 Antigravity를 씁니다. 하나의 글만 쓸 때는 Cursor의 안정성이 더 편하고, 5개 글을 동시에 리서치할 때는 Antigravity의 병렬 처리가 빠릅니다.
실전 사례: 이 글이 만들어진 과정
이 글 자체가 이 파이프라인으로 만들어졌습니다. 과정을 투명하게 공개합니다.
blog-ideas.md에 글감이 있었습니다.[id:: BLOG-20260311-001], priority 9, status backlog.- Cursor에서
@blog-pipeline-team "옵시디언 + Claude + Antigravity 연동"명령을 실행했습니다. - Phase 1에서 researcher가 8회 웹 검색을 돌렸습니다. Antigravity 공식 FAQ, IRONPARK의 Obsidian 발행 글, Claude Code + Obsidian MCP 가이드 등을 수집했습니다. 볼트 내 기존 글 260111(편집 꿀팁), Clawdbot 연동 글과의 중복 여부도 체크했습니다.
- Phase 2에서 writer가 리서치 패키지를 받아 초안을 작성했습니다. 채널이 TECHTAEK이라 Markdown 포맷이 적용됐고,
recent-patterns.md를 참조해서 최근 사용한 TYPE 2, 8, 9를 피한 도입부를 선택했습니다. - Phase 3에서 reviewer가 16개 항목을 검증했습니다. 첫 검증에서 NG 6개를 받았습니다. 도입부 패턴 혼동, 시간 수치 불일치, fragment paragraph 과다, 분량 미달 등이었습니다.
- 수정 후 재검증을 통과했고, Phase 4에서 MD 파일 저장, blog-ideas 상태 업데이트, SNS 포스트 생성까지 완료됐습니다.
총 소요 시간은 파이프라인 실행 약 15분 + 수정 10분 + 사람 편집 20분입니다. 리서치부터 시작했으면 3시간은 걸렸을 작업입니다.
자주 발생하는 문제와 해결법
6개월 동안 약 120편의 글을 이 파이프라인으로 돌리면서 반복적으로 만난 문제들이 있습니다.
에이전트가 숫자를 지어내는 문제. researcher가 웹 검색에서 가져온 숫자와 writer가 본문에 쓴 숫자가 다른 경우가 잦았습니다. 해결책은 reviewer의 팩트대조 항목을 강화하는 것이었습니다. 리서치 패키지에 “핵심 팩트 테이블”을 만들고, reviewer가 본문의 모든 숫자를 이 테이블과 1:1 대조하도록 규칙을 넣었습니다.
도입부가 매번 “결론부터 말하면”으로 시작하는 문제. recent-patterns.md에 최근 사용한 도입부 유형을 기록하고, writer가 이 파일을 읽어서 겹치지 않는 유형을 선택하게 만들었습니다. 11가지 도입부 유형(의심, 고백, 공감, 놀라움 등)을 정의해두고 순환시키는 방식입니다.
인라인 HTML 채널에서 스타일이 깨지는 문제. 배당노마드 채널은 Blogger용 인라인 HTML을 출력해야 합니다. <style> 태그를 쓰면 안 되고, 모든 스타일을 style="" 속성에 넣어야 합니다. 처음에는 writer가 이 규칙을 자주 어겼는데, HTML 템플릿 파일을 별도로 만들어서 writer에게 참조하게 한 뒤로 오류율이 크게 줄었습니다.
발행은 어떻게 하나
파이프라인의 최종 출력물은 옵시디언 볼트 안의 Markdown 파일입니다. 여기서 실제 블로그에 올리는 방법은 여러 가지입니다.
- 수동 복사: MD 파일을 열어서 블로그 에디터에 붙여넣기. 가장 단순하고 확실합니다.
- Git + 정적 사이트: Hugo/Jekyll/VitePress에 볼트를 연결하면 커밋 시 자동 배포됩니다.
- Tistory API: obsidian-tistory-plugin이나 Python 스크립트로 티스토리에 자동 포스팅이 가능합니다.
- WordPress REST API: WP 사이트가 있다면 API로 MD → 포스트 변환 자동화가 됩니다.
저는 현재 수동 복사를 쓰고 있습니다. “자동화의 끝이 왜 수동이냐”고 물을 수 있는데, 발행 전에 한 번 눈으로 훑어보는 과정이 필요하다고 판단했기 때문입니다. 에이전트가 검증까지 해줬다 해도, 최종 발행 버튼은 사람이 누르는 게 맞다고 생각합니다.
내가 느낀 점
이 파이프라인을 만들면서 가장 크게 바뀐 건 “블로그 글 쓰기”에 대한 인식입니다.
예전에는 글 하나를 쓰려면 심적 준비가 필요했습니다. “오늘 이거 써야 하는데” 하면서 미루다가 결국 밤에 급하게 쓰는 패턴이 반복됐습니다. 지금은 출근 전에 주제만 던져놓으면 점심 때 초안이 나와 있습니다. 그걸 읽고 수정하는 건 20분이면 됩니다.
글쓰기의 중심이 창작 쪽에서 편집 쪽으로 옮겨간 느낌입니다. 에이전트가 초안을 쓰고, 저는 그 위에 제 경험과 관점을 덧붙입니다. 이게 AI와 협업하는 가장 현실적인 방식이 아닐까 싶습니다.
솔직한 마음
걱정도 있습니다. AI가 쓴 글이 넘쳐나는 시대에, 이런 파이프라인이 오히려 “양산형 콘텐츠”를 만드는 도구가 될 수 있다는 우려요.
그래서 reviewer 게이트를 엄격하게 만들었고, 성찰 섹션 3가지를 필수로 넣었습니다. AI가 절대 흉내 낼 수 없는 건 “내가 이걸 써보고 어떤 감정이 들었는지”입니다. 기술적 팩트는 에이전트가 수집하고, 감정과 판단은 제가 넣습니다.
이 균형이 무너지면 이 파이프라인은 그냥 스팸 생성기가 됩니다. 그래서 매주 발행된 글을 읽으면서 “이건 정말 내 글인가?”를 스스로에게 묻고 있습니다. 답이 “아니오”인 글은 비공개로 돌립니다.
앞으로 할 것들
- 발행 자동화 마지막 단계 연결. 현재 수동 복사인 발행 단계를 WordPress REST API로 연결해서, PASS된 글을 “draft” 상태로 자동 업로드하는 걸 3월 안에 테스트할 계획입니다.
- 성과 피드백 루프 구축. Google Analytics 데이터를 에이전트에 연결해서 “어떤 유형의 글이 트래픽을 받는가”를 파이프라인에 반영하려 합니다. 지금은 제가 수동으로 판단하고 있는데, 이것도 자동화할 여지가 있습니다.
- 다국어 확장. TECHTAEK에 영어 채널(techtaek-en)을 추가했습니다. 같은 파이프라인에서
--lang en플래그만 붙이면 영어 글이 나옵니다. 한국어 개발자 관점의 영어 기술 블로그가 차별화 포인트가 될 수 있다고 봅니다.
FAQ
Q. Antigravity 없이도 이 파이프라인을 쓸 수 있나요?
네. Cursor에서도 동일하게 작동합니다. 파이프라인은 .claude/agents/ 폴더 구조에 의존하지 특정 IDE에 종속되지 않습니다. Antigravity의 장점은 병렬 실행과 무료 프리뷰입니다.
Q. Claude 비용이 얼마나 드나요?
글 한 편당 Phase 1~4를 전부 돌리면 약 $0.5~1.5 정도입니다. researcher/reviewer는 haiku급이라 저렴하고, writer가 opus급이라 비용의 80% 이상을 차지합니다. 월 20편 기준 $15~30 수준입니다.
Q. 옵시디언 플러그인이 필요한가요?
기본 파이프라인에는 필요 없습니다. 볼트 폴더를 IDE(Antigravity/Cursor)에서 열고 에이전트를 실행하는 방식입니다. 다만 obsidian-git을 쓰면 버전 관리가 편해지고, obsidian-tistory-plugin을 쓰면 티스토리 발행이 자동화됩니다.
Q. 글 품질은 사람이 쓴 것과 비교하면 어떤가요?
초안 기준으로 70~80점이라고 봅니다. 팩트는 정확하고 구조도 잡혀 있지만, “이 사람이 진짜 써봤구나”라는 느낌은 사람이 넣어야 합니다. 성찰 섹션, 실패담, 감정 표현을 20분 정도 직접 수정하면 90점 이상으로 올라갑니다.
Q. 기존에 쓴 260111 글이랑 뭐가 다른가요?
260111은 “Cursor/Antigravity에서 옵시디언 편집하고 Claude Skill 쓰는 법”입니다. 이 글은 “노트에서 블로그까지 전체 파이프라인(리서치→작성→검증→발행)이 어떻게 연결되는가”에 초점을 맞추고 있습니다. 편집 vs 파이프라인이라는 차이입니다.
Q. blog-pipeline-team 에이전트 정의 파일을 공유할 수 있나요?
.claude/agents/blog-pipeline-team/ 폴더에 blog-lead.md, blog-researcher.md, blog-writer.md, blog-reviewer.md가 있습니다. 이 파일들은 Markdown으로 작성되어 있어서 누구나 자신의 볼트에 복사해서 수정할 수 있습니다. 구체적인 구조는 별도 글로 정리할 예정입니다.
결론
옵시디언에서 블로그까지의 자동화는 “발행”이 아니라 “생산”에서 시작해야 합니다. Git hooks나 API 연동으로 발행을 자동화해봤자, 글 쓰는 시간 2시간 반은 그대로입니다.
Claude 에이전트 파이프라인은 그 2시간 반을 20분으로 줄여줍니다. 리서치, 초안, 검증까지 에이전트가 하고, 사람은 경험과 판단을 얹는 구조입니다. Antigravity든 Cursor든, IDE에서 볼트를 열고 @blog-pipeline-team 한 줄이면 됩니다.
다만 이 도구가 “내 글”을 만들어주는 건 아닙니다. 에이전트는 재료를 준비하고, 글의 주인은 여전히 사람입니다. 그 균형을 지키는 한, 이 파이프라인은 1인 블로거에게 현실적인 무기가 됩니다.