마크다운 한 번으로 네 곳에 발행하기: dev.to, Medium, AWS Builder Center, LinkedIn

AI 요약

마크다운 원고 하나를 여러 플랫폼에 올리려면 표, 코드 블록, 표지 이미지가 플랫폼마다 다르게 보이는 문제부터 해결해야 합니다. 이 글은 Claude Code, Codex, Antigravity에서 쓰는 에이전트 스킬 publishing-kit으로 dev.to, Medium, AWS Builder Center, LinkedIn용 게시물을 만드는 절차를 설명합니다. 글쓴이는 도구를 사용해 본문을 네 곳에 준비하고, 발행 전에 검증하는 과정도 함께 공개합니다.

플랫폼마다 다른 게시 경로

dev.to는 생성·수정·목록 조회·조직 라우팅을 지원하는 REST API를 제공합니다. 다만 마크다운 줄바꿈을 그대로 문단에 반영하고, 표지 이미지를 2.381:1 비율로 잘라 표시합니다. API로 기존 게시물을 수정할 때 front matter의 published: false가 함께 전달되면 공개 글이 초안으로 되돌아갈 수 있습니다.

Medium은 2023년부터 API를 지원하지 않습니다. URL 가져오기는 문단과 제목, 링크, 이미지를 가져오지만 표를 버리고 여러 줄 코드 블록을 한 줄로 합칩니다. 제목 크기도 두 종류만 표시하며 이미지 설명에 링크가 있으면 이미지가 사라질 수 있습니다. URL을 기준으로 가져온 결과를 캐시하고 쿼리 문자열은 무시하므로, 수정한 페이지를 다시 가져와도 이전 내용이 나올 수 있습니다. 편집기에 붙여넣으면 여러 줄 코드는 유지되지만 data: URI 이미지가 제거됩니다. 따라서 도구는 표를 PNG 이미지로 바꾸고, 코드 블록은 HTML로 준비한 뒤 브라우저 편집기에 붙여넣습니다. Medium 편집기는 붙여넣은 본문에서 제목을 채우지 않으므로 제목 필드도 따로 입력해야 합니다.

AWS Builder Center에는 게시 API가 없습니다. 브라우저 편집기에 본문을 붙여넣으며, 게시 과정에서 일반 텍스트로 적은 URL까지 검사합니다. 링크 검사가 실패해도 어떤 링크가 문제인지 알려주지 않는다는 점을 글에서 짚습니다. LinkedIn에는 Posts API가 있지만 생성 상태로 PUBLISHED만 받아들이므로 API로 올리면 바로 피드에 게시됩니다. 게시물 본문도 마크다운을 렌더링하지 않습니다. 도구는 별도의 텍스트 파일을 만들고, 모든 링크가 확정된 뒤 편집기에 붙여넣도록 합니다.

원본은 dev.to 마크다운, 나머지는 변환 결과

원본 파일은 dev.to 마크다운과 front matter로 작성합니다. 표와 코드, 이모지를 원본에서 표현하고, 플랫폼별 변환 스크립트가 각 형식에 맞는 결과물을 생성합니다. make-medium.py는 표를 이미지로 만들고 Medium용 HTML을 씁니다. make-builder.py는 Builder Center용 본문을 만들며, make-linkedin.py는 LinkedIn 게시물 텍스트를 생성합니다. make-cover.py는 플랫폼별 크기의 표지를 만들고 파일 내용의 해시를 파일명에 넣습니다. 예시에서는 dev.to 표지를 1376×578, Builder Center 표지를 1200×675로 생성했습니다. 표지와 Medium 이미지가 공개 URL로 제공되도록 먼저 GitHub에 푸시해야 합니다.

게시 전 검사 스크립트 preflight.py는 표지, front matter, 본문, 링크와 글에 적힌 수치를 확인합니다. --live 옵션은 공개 URL의 응답과 로컬 파일의 바이트가 일치하는지 확인하고, 링크도 실제 게시 과정처럼 가져와 검사합니다. 검사 결과 LinkedIn 게시물은 Medium과 Builder Center 링크가 아직 PENDING이라 실패했지만, dev.to 초안에 필요한 검사는 통과했습니다. 링크가 정해지지 않은 상태에서 LinkedIn 게시물이 나가지 않도록 막는 방식입니다.

초안부터 게시까지

dev.to는 publish-devto.py --create로 초안을 만들고 조직에 연결합니다. 글에서는 같은 파일을 두 조직에 각각 초안으로 등록했으며, 본문은 바이트 단위로 같고 조직만 다르다고 설명합니다. 공개는 --publish <id>를 실행하는 별도 단계입니다. Medium과 Builder Center는 브라우저 편집기에 붙여넣은 뒤 게시 버튼을 누릅니다. LinkedIn은 모든 링크를 확정한 뒤 생성 파일을 게시물 작성창에 붙여넣고 표지를 첨부합니다.

브라우저 자동화에는 편집기가 비어 있는지, 탭이 입력을 받을 수 있는 상태인지 확인하는 헬퍼를 사용합니다. Builder Center에서는 로컬 서버로 본문을 전달하고, 양쪽에서 체크섬을 비교한 뒤 한 번만 붙여넣습니다. 글은 Medium과 Builder Center의 편집기가 백그라운드 탭 입력을 거부하거나 업로드 버튼을 숨길 수 있고, 편집기가 비어 있지 않으면 붙여넣기가 중복될 수 있다고 설명합니다. 전체 구성에는 Python 3, Pillow, Medium 결과물 생성을 위한 pandoc, dev.to API 키와 각 서비스의 로그인 세션이 필요합니다.

글에서 확인한 결과

작성자는 publishing-kit 0.30.0을 사용해 dev.to 조직 두 곳, Medium, AWS Builder Center, LinkedIn에 글을 준비했습니다. dev.to 초안은 API로 등록했고, Medium에서는 표와 코드 표현을 처리해 편집기에 붙여넣었습니다. Builder Center 본문은 체크섬을 확인한 뒤 붙여넣었으며, LinkedIn 게시물은 링크가 해결된 다음 게시하도록 생성했습니다. Medium과 Builder Center는 브라우저 작업이 필요하고, LinkedIn은 API로 초안을 만들 수 없어 게시 전 파일 상태로 대기해야 합니다. 글의 범위는 2026년 10월 2일 Linux의 Claude Code에서 실행한 단일 글 사례입니다.

dev.to 반응

• @dannwaneri — 저도 방금 Substack 계정을 만들었습니다. 비교표에 넣을 만합니다. Substack에도 공개 게시 API가 없고 Medium과 마찬가지로 읽기 전용 RSS 피드만 제공합니다. 다섯 번째 대상으로 추가하려면 Medium, Builder Center와 같은 브라우저 붙여넣기 방식이 필요하겠네요.
• @anubhabdaserrr — 정말 좋네요. 조만간 한번 써보겠습니다!
• @mrsaynothing — 저희는 매주 이 파이프라인을 직접 실행합니다. 원본 글 하나를 dev.to에 교차 게시하고, 일요일마다 Hashnode와 Medium에 복사합니다. 표에 적힌 내용이 저희가 겪은 문제와 일치합니다. Medium API가 닫히면서 자동 미러링이 모두 망가졌고, LinkedIn만은 예외라서 저희는 복사하지 않고 다시 씁니다. 아무도 미리 경고하지 않는 함정은 canonical URL이 달라지는 문제입니다. 검색엔진 최적화 점수가 여러 사이트로 나뉘지 않으려면 canonical_url을 원본 URL 그대로 유지해야 합니다. publishing-kit은 플랫폼별 canonical URL을 고정하나요, 아니면 front matter에 적힌 값을 그대로 믿나요?

원문: dev.to / 번역·요약: Trawling