Write-Once 퍼블리싱 파이프라인 구축
Source: Dev.to
문제
콘텐츠를 작성하는 것은 쉬운 부분입니다.
메타데이터, 이미지, 태그, 정규 URL, 업데이트 등을 포함해 여러 플랫폼에 일관되게 퍼블리시하는 부분에서 문제가 발생합니다.
대부분의 워크플로우는 아직도 다음과 같습니다:
- 하나의 도구에서 콘텐츠 작성
- WordPress에 복사·붙여넣기
- 다른 플랫폼용으로 다시 포맷팅
- 어디에 무엇을 퍼블리시했는지 잊어버림
- 업데이트와 수정 사항을 추적하지 못함
저는 다른 방식을 원했습니다:
한 번 작성 → 여러 곳에 퍼블리시 → 안전하게 업데이트 → 모든 것을 자동화
이 목표가 Git 기반 자동 퍼블리싱 파이프라인을 만들게 했습니다.
핵심 아이디어
이 시스템의 핵심 원칙은 간단합니다:
Markdown을 Git에 보관하는 것이 유일한 진실 원천이다.
그 외의 모든 것—퍼블리싱, 업데이트, 추적, 미디어 처리—은 여기서 파생됩니다.
파이프라인은 다음과 같이 설계되었습니다:
- 멱등성 보장 (반복 실행해도 안전)
- CI 레벨에서 무상태(stateless)
- 데이터베이스를 통한 상태 인식
- 새로운 플랫폼에 대한 확장성
- 컨테이너화 및 Kubernetes 적용 준비
현재 기능 세트
콘텐츠 및 메타데이터
- YAML 프론트매터가 포함된 Markdown
- 제목, 슬러그, 태그, 대표 이미지
- 플랫폼별 퍼블리시 스위치
- 선택적
force_update플래그
퍼블리싱
- WordPress REST API를 통한 퍼블리싱 (자동 포스트 생성 및 업데이트)
- 초안 또는 공개 상태 지정
- 자동 정규 URL 생성
대표 이미지
- WordPress REST API를 이용한 미디어 업로드
- 기존 미디어 재사용 (멱등성)
- Markdown에 직접 이미지 선언
상태 추적
- PostgreSQL 기반 상태 추적:
- 어느 플랫폼에 포스트가 퍼블리시 되었는지
- 플랫폼별 포스트 ID
- 콘텐츠 해시
- 퍼블리시 타임스탬프
- 콘텐츠 변경 자동 감지
안전한 업데이트
- 콘텐츠 해시 비교
- Markdown이 변경될 때 자동 포스트 업데이트
- 중복 퍼블리시 방지
- 수동 DB 편집 불필요
워크플로우
퍼블리싱 흐름은 다음과 같습니다:
- Markdown 파일을 작성하거나 수정
- Git에 커밋하고 푸시
- Jenkins 파이프라인 실행
퍼블리셔는:
- 프론트매터 파싱
- 콘텐츠 해시 계산
- PostgreSQL에서 플랫폼 상태 확인
- 필요 시 대표 이미지 업로드
- WordPress 포스트 생성 또는 업데이트
- 데이터베이스에 상태 업데이트
파이프라인은 안전하고 반복 가능하게 종료됩니다.
흐름도
이 아키텍처가 효과적인 이유
Git이 진실
모든 콘텐츠와 의도는 Git에 존재합니다. 숨겨진 상태나 UI 전용 변경이 없습니다.
데이터베이스가 상태
데이터베이스는 무엇이 일어났는지를 기록합니다. 이는 업데이트와 수정이 안전하게 이루어지게 합니다.
CI는 무상태
Jenkins는 실행 간에 아무것도 저장하지 않으므로 시스템을 포터블하고 컨테이너 친화적으로 만듭니다.
플랫폼 추상화
WordPress는 단지 하나의 퍼블리셔일 뿐입니다. Dev.to, Substack, Patreon 등 다른 대상 추가 시 핵심 모델을 변경할 필요가 없습니다.
향후 방향
파이프라인은 이미 백엔드 서비스처럼 동작하고 있습니다. 자연스러운 다음 단계는 다음과 같습니다:
- 더 많은 퍼블리싱 대상 추가 (Dev.to, Substack 등)
- 분석 및 참여 추적 도입
- 퍼블리셔를 컨테이너로 패키징
- Kubernetes 내부에서 실행
- 간단한 UI 추가
Publishing as a Service 로 제공: 하나의 레포, 하나의 워크플로, 하나의 진실 원천 — 수년간의 콘텐츠를 위해.
마무리 생각
“좀 더 쉽게 퍼블리시하고 싶다”는 생각에서 시작해 완전 자동화된 퍼블리싱 플랫폼으로 발전했습니다:
- Git 기반 콘텐츠 관리
- CI 구동 실행
- 데이터베이스 기반 상태 관리
- 멱등적이며 업데이트에 안전한 퍼블리싱
그리고 가장 좋은 점? 이제 콘텐츠 작성을 제외하고는 모든 단계가 자동화되었습니다.