babipanote·
#buildlog#obsidian#dataview#seo#claude-mcp#개인지식관리

Obsidian으로 블로그 SEO 관제 시스템 만든 과정

15개 글 기획·추적을 위해 Obsidian + Dataview + Claude MCP로 SEO 관제 시스템을 만든 과정. Notion 대신 Obsidian을 선택한 이유와 과설계의 함정까지 솔직하게 기록했다.

읽는 시간 5

"블로그 15개 글을 어떻게 관리하지?"

Sprint 계획이 15개 글이다. 이걸 "뭐 쓸까 → 키워드 뭐지 → 발행했나 → 성과 어때" 흐름으로 추적하려면 시스템이 필요했다. Notion? 느리다. 스프레드시트? 확장성 없다. Obsidian으로 SEO 관제 시스템을 만들었다.

왜 Notion이 아니라 Obsidian인가

기준NotionObsidian
속도2초 로딩즉시
오프라인⚠️
Git 버전 관리
Claude MCP 연동⚠️ 제한적✅ 완벽
마크다운 호환변환 필요네이티브
비용$10/월 (팀)무료

결정적 이유는 Claude MCP. Obsidian vault에 Claude를 연결하면 "Pipeline 카드 상태 바꿔줘"가 된다. Notion MCP도 있지만 응답이 느리고 DB 구조 제약이 있다.

폴더 구조 전부 공개

02. Blog SEO/
├── 00. 프로젝트 개요.md
├── 01. Workflow Guide.md
├── 02. AIGrit 글쓰기 지침서.md
├── 03. babipanote 글쓰기 지침서.md
├── 04. 네이버 에디션 운영 가이드.md
├── 05. SEO 도구 현황.md
├── 06. Dashboard.md              ← Dataview 자동 집계
├── 07. Sprint 실행 계획.md
├── 08. Workflow 다이어그램.md
├── 09. 실전 워크플로우 매뉴얼.md
├── 09a. 구현 체크리스트.md
├── 09b. 수동 세팅 체크리스트.md
├── 10. Pipeline/
│   ├── AIGrit/               ← 글별 SEO 카드
│   ├── babipanote/           ← 빌더 저널 카드
│   └── Naver/                ← 네이버 에디션 카드
├── 11. Keyword DB/
├── 12. Topic Cluster/
└── 99. Templates/

핵심 통찰: 문서 13개는 "한 번 쓰고 참조하는 문서". 매일 만지는 건 10. Pipeline/ 카드와 06. Dashboard뿐이다.

Dataview 쿼리 5개 레시피

Obsidian Dataview 대시보드

Dashboard.md 실제 화면 — 글 현황이 자동 집계된다

1. 상태별 글 수

TABLE status, length(rows) FROM "10. Pipeline" GROUP BY status

2. 발행 완료 글 (최신순)

TABLE publish_date, monthly_views FROM "10. Pipeline" WHERE status = "published" SORT publish_date DESC

3. 클러스터 건강도

TABLE length(rows), Pillar 수, Cluster 수 FROM "10. Pipeline" GROUP BY topic_cluster

4. 네이버 에디션 후보

TABLE naver_edition_angle FROM "10. Pipeline" WHERE naver_edition_candidate = true

5. 내부 링크 네트워크

TABLE length(internal_links_used) FROM "10. Pipeline" WHERE status = "published"

Claude.ai와 연동 (MCP)

가장 강력한 부분. Claude.ai에서 Obsidian MCP가 연결되면:

  • "Dashboard 보여줘" → Dataview 결과 확인
  • "Pipeline 카드 15개 일괄 생성해줘" → 실제 파일 생성
  • "상태를 published로 바꿔줘" → frontmatter 직접 수정
  • "다음 글 주제 추천해줘" → 기존 카드 분석 후 제안

실제로 Sprint 1주차 회고에서 언급한 "Obsidian SEO 관제 시스템이 과했을 수도"의 주인공이 바로 이 시스템이다. 만드는 재미는 있었지만 글 0개 시점의 투자 타이밍이 아쉽다.

배운 것 — 과설계 vs 적정 설계

과설계의 함정: 글 0개인 시점에 SEO 시스템 만드는 데 반나절을 썼다. 재미있었지만, 그 시간에 글 1개를 더 쓸 수 있었다.

적정 설계 기준:

  • 글 5개까지: Pipeline 카드 + Dashboard만
  • 글 10개부터: Topic Cluster + 내부 링크 전략
  • 글 20개부터: 성과 기반 최적화

지금 다시 시작한다면 Pipeline 카드 템플릿 1개 + 간단한 Dataview 쿼리 2개로 시작했을 것이다. 이 교훈은 Flutter 앱 3개 만든 과정에서도 똑같이 배웠었다 — "시스템 먼저 쌓으려 하지 말고 결과물 먼저 쌓자". 두 번째로 같은 실수를 했다는 게 재미있다.

다음 단계

  • 글 20개 쌓인 후 성과 데이터(GSC 노출·클릭) 수동 입력 루틴 추가
  • 월간 리포트 자동화 (Dataview → 마크다운 export)
  • AI 주제 추천 프롬프트 템플릿화 (Craft 원자료 노트로 분리)

"시스템 만들기"가 재미있어서 "글 쓰기"를 대체하면 안 된다. 이번엔 배웠다. 세 번째는 하지 않겠다.