블로그 콘텐츠를 Dev.to에 자동 배포하기

블로그에 글을 올릴 때마다 손으로 Dev.to에도 동일한 내용을 복붙해서 올리던 반복 작업을 없애기로 했다. bot/generate.py에 Dev.to 신디케이션 로직을 추가해서 블로그 배포와 함께 자동으로 Dev.to에 콘텐츠가 올라가도록 정리했다.

왜 신디케이션이 필요했나

기술 블로그를 운영하면서 맞닥뜨리는 흔한 딜레마가 있다. 원본 블로그에만 글을 올리면 도달 범위가 제한되고, 그렇다고 여러 플랫폼에 동일하게 올리려면 수작업이 너무 많다는 것. Dev.to나 Medium 같은 플랫폼은 독립적인 생태계를 갖고 있고, 여기서 발견되는 독자들도 상당하니까 무시할 수 없는데, 매번 글을 복사-붙여넣기 하는 건 지속 가능하지 않다.

신디케이션이라는 접근은 이 둘을 모두 챙기려는 실용적인 선택이었다. 원본 블로그는 소유권을 유지하고, 다른 플랫폼에는 그걸 파생 콘텐츠로 배포하되, 트래픽과 권위는 원본으로 돌려주는 구조. 자동화까지 더하면 운영 부담도 큰 폭으로 줄일 수 있다.

Canonical backlink의 중요성

여러 곳에서 동일한 콘텐츠가 노출될 때 가장 먼저 신경 써야 할 게 canonical 태그다. 검색 엔진 입장에서는 같은 콘텐츠가 여러 URL에서 떠도는 것처럼 보일 수 있고, 이게 중복 콘텐츠로 판단되면 어느 버전을 진짜로 볼 것인지 헷갈린다. Canonical backlink를 원본 블로그로 명확히 설정하면 "이 콘텐츠의 원본은 저기고, 나는 배포본입니다"라는 신호를 주는 거다.

개발자 관점에서는 이게 SEO 기술 같지만, 실제로는 더 기본적인 원칙이다. 저작권 표시, 출처 명시, 트래픽 공정한 배분. Dev.to 자체도 canonical을 지원하기 때문에, 우리가 이를 제대로 활용하면:

• 원본 블로그의 검색 랭킹을 지킬 수 있다
• Dev.to의 독자도 원본으로 유입될 길을 만든다
• 나중에 콘텐츠 마이그레이션이나 집계할 때도 명확하다

구현 관점에서의 선택

bot/generate.py를 건드린 이유는 이미 블로그 글 생성 로직이 여기 집중되어 있었기 때문이다. 한 번의 실행으로 "글 생성 → 메타데이터 정리 → 플랫폼별 배포"까지 파이프라인을 만들면, 개발자가 신경 써야 할 진입점이 하나다.

이게 팀 관점에서는 작은 것처럼 보이지만 꽤 중요한 의사결정이었다. 나중에 Medium 같은 다른 플랫폼도 추가해야 한다면? 그때 또 다른 스크립트를 따로 만들 수도 있지만, 이미 bot/generate.py에 Dev.to 신디케이션이 있다면 패턴만 따라가면 된다. 중복 코드도 줄어들고, 누군가 새로 온 팀원도 자동화 로직의 위치를 직관적으로 찾을 수 있다.

끝내며

이런 작은 자동화들이 쌓이면 팀의 운영 마찰이 확 줄어든다. 글쓰기에만 집중할 수 있고, 배포와 도달 범위 최적화는 배경에서 조용히 돌아간다. 그리고 canonical backlink처럼 기술적 정확성도 사람의 실수 여지 없이 지킬 수 있다. 다음에 비슷한 반복 작업을 마주치면, "이것도 자동화할 수 있지 않을까"라고 먼저 생각하는 습관이 생겼다.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.