DEV Community

Seonho Kim
Seonho Kim

Posted on • Originally published at comfunny.com

한 번 쓰고 여러 곳에 — 직접 만든 콘텐츠 배포 파이프라인(POSSE)

블로그를 운영하다 보면 늘 같은 고민에 부딪힌다. "내 사이트에 쓸까, 아니면 사람이 많은 플랫폼에 쓸까?"

  • 내 사이트에 쓰면 자산은 쌓이지만 초기 트래픽이 없다.
  • 외부 플랫폼(Dev.to, Velog)에 쓰면 도달은 좋지만 내 것이 아니다.

둘 다 갖고 싶었다. 그래서 POSSE 패턴으로 파이프라인을 직접 만들었다.

POSSE — Publish on Own Site, Syndicate Elsewhere

원칙은 단순하다.

원본(canonical)은 내 사이트에. 외부에는 복제하되 원문 링크를 박는다.

핵심은 rel="canonical"이다. 복제본이 원문을 가리키면 검색엔진은 중복으로 처벌하지 않고
원본에 점수를 몰아준다. 즉 내 사이트는 자산으로 쌓이고, 외부는 유입을 끌어온다.

파이프라인 구조

전체 흐름은 4단계다.

  • 수집: Hacker News·RSS에서 IT/AI 주제를 모은다 (키 불필요)
  • 선별: 키워드·인기도로 점수화해 상위 주제를 고른다
  • 작성: 대본/본문을 생성한다
  • 배포: 내 블로그(원본) → Dev.to(API 자동) → Velog(붙여넣기 초안)

복제 단계는 이렇게 생겼다.

// 내 블로그가 원본임을 명시하며 Dev.to에 복제
await fetch("https://dev.to/api/articles", {
  method: "POST",
  headers: { "api-key": KEY, "content-type": "application/json" },
  body: JSON.stringify({
    article: {
      title,
      body_markdown: body,
      published: true,
      canonical_url: "https://comfunny.com/blog/" + slug, // ← 핵심
    },
  }),
});
Enter fullscreen mode Exit fullscreen mode

설계에서 가장 중요했던 결정

"AI가 없어도 동작해야 한다."

생성 단계는 AI가 있으면 AI가, 없으면 템플릿이나 사람이 채운다. 어느 쪽이든
파이프라인의 나머지(수집·배포·상태기록)는 똑같이 굴러간다. 도구가 빠져도
시스템이 멈추지 않게 만드는 것 — 이게 자동화를 오래 끌고 가는 비결이라고 믿는다.

또 하나, 영상 채널은 솔직하게 분리했다. 텍스트 대본만으로 유튜브·릴스를
올릴 수는 없다(영상 파일이 필요하다). 그래서 블로그는 완전 자동, 영상은
별도 렌더 큐로 위임했다. 할 수 없는 걸 할 수 있는 척하지 않는 게 설계의 정직함이다.

결과

이제 글 하나를 쓰면:

  • 내 블로그에 원본이 남고(자산)
  • Dev.to에 자동 복제되어 글로벌 개발자에게 닿고(도달)
  • Velog용 초안까지 손에 들어온다

그리고 각 글이 어느 채널에 나갔는지는 관리자 대시보드에서 한눈에 본다.

마치며

"많이 쓰는 것"보다 "한 번 잘 써서 여러 곳에 닿게 하는 것"이 오래 간다.
도구는 거들 뿐, 자산은 내 도메인에 쌓인다.

이 글은 그 파이프라인이 직접 배포했습니다.

Top comments (0)