콘텐츠 자동화 저장소를 이용한 다중 채널 블로그 발행 자동화

요약: 저는 콘텐츠 자동화 파이프라인을 수정하여 단일 CI 단계에서 Medium, Substack, Bluesky에 일일 게시물을 생성하고 포맷팅하며 푸시하도록 만들었습니다. 이 변경 사항은 몇 개의 Markdown, JSON 및 메타데이터 파일에 존재하며, 각 플랫폼의 페이로드를 유효하게 유지하면서 수동 복사-붙여넣기 오류를 제거합니다.

문제점

매일 아침 저는 백로그에 세 가지 작업 티켓을 가지고 있었습니다:

1. 오늘 기사를 Medium에 발행하기 (영어 및 스페인어).

2. Bluesky에 간결한 업데이트 게시물 올리기 (영어 및 스페인어).

수동 워크플로우는 다음과 같았습니다:

$ cat content/2026/10/05/content-automation/medium_en.md
# … (복사-붙여넣기) …

저는 계속해서 각 파일을 열고, 프론트매터를 조정하고, 줄 바꿈을 수정한 다음, 각 플랫폼의 UI를 통해 수동으로 업로드했습니다. 가장 큰 문제는 Bluesky의 페이로드 불일치였습니다. JSON 스키마는 type 필드(progress/avance)와 300자로 제한된 text 필드를 예상했는데, 생성된 JSON에서 오타가 하나만 있어도 API가 다음과 같은 메시지로 요청을 거부했습니다:

Error: payload validation failed – field "text" exceeds max length

이 오류는 제가 이미 Medium 초안 준비에 약 30분을 소비한 후에야 나타났기 때문에, 저는 변경 사항을 되돌리고 모든 것을 다시 편집해야 했습니다. 저는 다음 기능을 수행하는 결정론적이고 반복 가능한 프로세스가 필요했습니다:

• 동일한 소스 Markdown을 한 번 가져오기.

• 커밋하기 전에 각 페이로드를 검증하기.

• 하드코딩된 경로(Hard‑coded paths): 날짜가 바뀔 때마다 수동 업데이트가 필요했습니다.

• 스키마 유효성 검사 부재(No schema validation): Bluesky JSON을 가공 없이 전송했기 때문에 길이 오류가 계속 발생했습니다.

• CI 통합 부재(No CI integration): 스크립트를 로컬에서 실행해야 했고, 이는 '빌드 공개(build in public)' 자동화 목표를 무산시켰습니다.

실패는 누락된 쉼표로 인해 깨진 JSON 페이로드와 다운스트림 작업이 의존하는 불일치한 metadata.json 플래그(medium_generated: false)로 나타났습니다.

구현(The Implementation)

1. 리포지토리 레이아웃 (Repository Layout)

content/
└─ 2026/
   └─ 10/
...

모든 파일은 이제 단일 Node.js 스크립트(scripts/generate-content.js)에 의해 자동으로 생성됩니다. 이 스크립트는 템플릿(templates/post.hbs)을 읽고 해당 날짜의 데이터(날짜, 제목, 태그)를 주입합니다. 그런 다음 플랫폼별 파일을 작성하고 metadata.json을 업데이트합니다.

2. 핵심 생성기 (Core Generator) (scripts/generate-content.js)

// scripts/generate-content.js
const fs = require('fs');
const path = require('path');
...

주요 사항(Key points)

• Handlebars 템플릿: 산문(prose)을 DRY하게 유지합니다. 언어별로 다른 문자열만 다릅니다.
• writeIfChanged: 불필요한 Git diff를 방지하여 CI 캐시가 정상적으로 작동하도록 합니다.
• Bluesky 페이로드: API 호출 전에 스키마 준수를 보장하기 위해 하드 제한(slice(0, 300))을 사용하여 구축됩니다.

3. CI 통합 (CI Integration)

새로운 GitHub Actions 워크플로우(.github/workflows/content.yml)는 일정(cron: '0 6 * * *')과 main 브랜치에 푸시가 발생할 때마다 실행됩니다:

name: Content Automation

on:
...

이 워크플로우는 생성된 파일을 **자동 커밋(auto‑commits)**하며, 이는 diff에서 볼 수 있는 정확히 세 가지 커밋입니다:

• chore(content): auto-generate 2026-10-07<br>
• chore(bluesky): posts 2026-10-07<br>
• chore(devto): article 2026-10-07<br>

생성 후 metadata.json 플래그가 이제 true로 설정된 것을 주목하세요:

-

내 [Build in Public](https://dev.to/zaerohell) 시리즈의 일부 — 멕시코 플라야 델 카르멘에서 SaaS 프로젝트를 구축하는 실제 과정을 공유합니다.

Repo: `zaerohell/content-automation` · 2026-10-07

#playadev #buildinpublic