지식 자동 발행 파이프라인

메모가 글이 되기까지 — Obsidian 인제스트부터 블로그 배포까지

들어가며

이 블로그의 글 대부분은 내가 직접 타이핑한 게 아니다. Obsidian 볼트의 raw/inbox/에 아무렇게나 던져둔 메모가, AI 에이전트(Claude Code)를 거쳐 정리된 위키 노트가 되고, 그중 완성도 높은 노트가 다시 이 블로그의 글로 변환·발행된다. 지금까지는 이 과정이 그냥 “알아서 되는 일”이었는데, 최근 재테크 메모 하나를 실제로 처리하면서 전체 흐름을 처음부터 끝까지 다시 정리해볼 기회가 생겼다. 이 글은 그 파이프라인 자체를 기록한 것이다 — 일종의 메타 포스트인 셈이다.

3단계 구조: Capture → Ingest/Compile → Publish

1단계. Capture (raw/inbox)

웹 아티클, 논문 스크랩, 개인 메모를 가공 없이 Obsidian의 raw/inbox/ 폴더에 마크다운으로 저장한다. 이 시점에서는 아무것도 정리하지 않는다. 그냥 원본을 던져두는 게 전부다.

2단계. Ingest & Compile (raw/inbox → wiki/)

“inbox에 있는 자료를 정리해줘”라고 요청하면 아래 순서로 처리된다.

  1. 원본 분석: 새 파일에서 핵심 개념·주장·키워드를 추출한다.
  2. 기존 지식 확인: 추출한 개념이 wiki/concepts/나 wiki/entities/에 이미 있으면 기존 문서를 훼손하지 않고 새 관점을 통합하고, 없으면 새 문서를 만든다. 여러 개념이 얽혀 있으면 wiki/synthesis/에 종합 노트도 따로 만든다.
  3. 양방향 링크: 새로 쓰거나 수정한 문서 안에서 관련 문서를 위키링크로 반드시 연결해 고립 문서가 생기지 않게 한다.
  4. 목차 갱신: 전체 위키의 목차(MOC) 역할을 하는 wiki/index.md에 새 문서를 등록한다.
  5. 아카이빙: 처리된 원본을 raw/inbox/에서 raw/archive/로 옮긴다. 이 이동 자체가 “처리 완료”를 뜻하는 상태값이라, 다음번 정리 요청 때 같은 파일이 다시 후보로 잡히지 않는다.

작성 표준도 정해져 있다. 모든 위키 문서는 type(concept/entity/synthesis), aliases, tags, created/updated, sources(원본 백링크) frontmatter를 갖추고, 본문은 개요 → 핵심 내용 → 연관 지식(Connections) 구조를 따른다. 원칙은 하나, 단순 요약 금지 — 새로 들어온 정보를 항상 기존 지식 그래프에 유기적으로 연결하는 것.

3단계. Publish (wiki/ → Astro 블로그)

여기부터는 별도의 발행 전용 작업(스킬)이 맡는다. 대상은 지금 보고 있는 이 Astro 블로그(Vercel 배포)다.

  1. 후보 스캔: wiki/concepts/, entities/, synthesis/를 훑어서 아직 blog_published: true 표시가 없는 노트만 후보로 삼는다. 종합 노트(synthesis)는 완성도가 높은 편이라 우선순위가 높다.
  2. 클러스터링 검토: 후보가 여러 개면 노트 1개를 글 1개로 기계적으로 뽑아내지 않는다. 같은 주제를 다루는 노트끼리는 “큰 그림 글”과 “딥다이브 글”처럼 앵글을 나눠 하나로 묶을 수 있는지 먼저 검토한다.
  3. 블로그 톤으로 재구성: 원문을 그대로 번역·축약하지 않는다. 위키의 그래프 컨텍스트가 없는 일반 독자가 바로 이해할 수 있도록 들어가며-본론-마치며 구조로 다시 쓴다. 위키링크는 평문이나 볼드체로 바꾸고, 원본의 트리형 다이어그램은 (이 템플릿엔 mermaid 렌더러가 없어서) 중첩 리스트나 화살표 텍스트로 변환한다.
  4. frontmatter 생성: 이 블로그의 콘텐츠 스키마에 맞춰 title/description/pubDate/category/tags/lang/draft를 채운다. category는 필수 필드라서, 미리 정의된 카테고리 슬러그 중 하나를 반드시 골라야 한다.
  5. 원본 노트에 발행 표시: 변환이 끝나면 원본 위키 노트에 blog_published, blog_slug, blog_published_at을 기록한다. 이게 두 번째 상태값 — 다음 발행 스캔에서 같은 노트가 중복 후보로 뜨지 않게 막아준다.
  6. 커밋까지만 자동, push는 승인 필수: 블로그 레포에 git commit까지는 자동으로 하지만, push는 절대 자동으로 하지 않는다. Vercel이 연결된 뒤로는 push가 곧 실배포라서, 반드시 사람의 확인을 받은 뒤에만 진행한다.

발행되는 글을 분류하는 카테고리 체계

파이프라인을 여러 번 돌리다 보니 이 블로그에 서로 다른 도메인의 글이 섞이기 시작했다. 그래서 포스트 유형을 나누는 카테고리 체계를 별도로 만들었다.

  • 카테고리 slug·라벨·아이콘·설명을 한 파일에서 관리하는 단일 소스가 있고, 현재 5종(AI 에이전트 자동화, 알고리즘 트레이딩, Physical AI & 자율주행, 지식 자동 발행 파이프라인, 재테크 & 자산관리)이 정의돼 있다.
  • 콘텐츠 스키마의 category 필드가 이 목록을 그대로 참조하는 필수값이라, 새 글은 카테고리 지정을 빠뜨릴 수 없다.
  • 포스트 카드와 상세 페이지에는 클릭 가능한 카테고리 뱃지가 붙고, 카테고리별 글 목록 페이지도 별도로 생성된다.

실행 사례: 재테크 메모 하나가 글이 되기까지

이 파이프라인이 실제로 어떻게 돌아가는지, 최근 처리한 사례로 보여주는 게 가장 빠를 것 같다.

raw/inbox/에 있던 “5대 금융계좌 비교” 메모 하나를 정리 요청했더니:

  1. 연금저축·IRP·ISA·일반계좌·CMA 각각이 개별 개념 노트로, 연령대별 활용 전략이 별도의 종합 노트로 컴파일됐다 — 총 6개 노트. 전부 서로 링크되고 위키 목차에도 반영됐다. 원본 메모는 아카이브로 이동.
  2. 종합 노트가 “20대엔 ISA, 40대엔 연금저축 — 나이 들수록 계좌를 갈아타야 하는 이유”라는 블로그 글로 재구성돼 발행됐다.
  3. 이때 이 블로그에 처음으로 재테크 도메인 글이 들어오면서, 포스트 유형을 구분할 필요가 생겼고 — 그 결과가 바로 위에서 설명한 카테고리 체계다.

메모 하나가 위키 노드 6개를 낳고, 그중 하나가 블로그 글이 되고, 그 과정에서 블로그 자체의 구조(카테고리)까지 하나 더 생겨난 셈이다.

마치며

정리하면 이 파이프라인의 핵심은 두 가지다. 사람이 개입하는 지점을 발행 후보 선택과 배포 승인, 딱 두 곳으로 줄인 것, 그리고 아카이빙과 발행 플래그라는 두 개의 상태값으로 중복 처리를 막은 것. 메모를 정리하고, 글을 쓰고, 배포하는 과정 각각은 원래 다 귀찮은 일들인데, 이 세 가지가 하나의 흐름으로 이어지니 “일단 메모만 잘 던져두면 된다”는 게 실제로 가능해졌다. 지금 이 글도 그렇게 만들어졌다.

이 글은 개인 위키에 정리해둔 지식 자동 발행 파이프라인 노트를 블로그용으로 재구성한 것입니다.

댓글