원문 한 편이 네 채널로
다채널 자동 발행 만드는 법
옮겨 붙이는 일을 사람이 안 하는 법
콘텐츠가 없어서가
아니었습니다
만들긴 만듭니다. 그런데 매주 링크드인에 붙이고, 네이버에 옮기고, 스레드용으로 줄여 쓰다 지칩니다. 그러다 한 주 건너뛰고, 두 주 건너뛰고, 어느새 채널 하나만 남습니다.
제작이 아니라 운영이 문제였습니다. 글을 쓰는 데 두 시간, 그걸 네 군데에 맞춰 옮기는 데 한 시간. 그 한 시간이 매주 돌아옵니다.
지금 저희 회사는 그 한 시간을 안 씁니다. 아래는 오늘 아침에도 그대로 돌아간 시간표입니다.
| 시각 | 무슨 일이 | 사람이 하는 일 |
|---|---|---|
| 08:00 | 채널별 팩 자동 생성 | 없음 |
| 09:30 | 블로그 원문 1편 발행 | 없음 (승인은 전날) |
| 11:00 | 링크드인 | 없음 |
| 12:00 | 네이버 블로그 | 없음 |
| 13:00 | 페이스북 | 없음 |
| 19:00 | 스레드 | 없음 |
구조는 세 덩어리입니다. 원문을 한 곳에서만 쓰고, 채널 버전을 자동으로 뽑고, 시간을 정해두고 잊는 것. 하나씩 보겠습니다.
01. 원문은 한 곳에서만 쓴다
가장 흔한 실수는 채널마다 글을 새로 쓰는 것입니다. 그러면 채널 수만큼 일이 늘고, 나중에 어느 게 최신인지도 모르게 됩니다.
원본은 하나여야 합니다. 저희는 블로그 글이 원본입니다. 블로그에 안 쓰면 아무 데도 안 올라갑니다. 반대로 블로그에 쌓아두면 그게 곧 다음 달 발행분이 됩니다.
원문은 큐에 쌓입니다. 오늘 기준 대기 51편, 발행 완료 22편입니다. 매일 아침 큐에서 승인된 것 중 가장 앞의 한 편이 나갑니다.
큐를 쌓는 게 이 구조의 연료입니다.
자동화를 붙여도 큐가 비면 아무 일도 안 일어납니다. 발행이 자동이 되는 순간 병목은 "올리는 일"에서 "쓰는 일"로 옮겨갑니다. 그게 정상이고, 그때부터 글 쓰는 데만 집중하면 됩니다.
02. 채널 버전은 자동으로 뽑는다
같은 글이라도 채널마다 읽히는 방식이 다릅니다. 그래서 원문을 그대로 복사해 붙이면 어디서도 안 읽힙니다.
저희는 아침 8시에 원문 하나에서 채널별 파일을 각각 뽑습니다. 같은 글의 첫 문단이 실제로 이렇게 갈립니다.
linkedin.txt · 길게, 존댓말
대행사 제안서는 결과물을 보고 사는 게 아니라, 약속을 보고 사는 거래입니다.
콘텐츠 제작은 결과물이 나오기까지 최소 한 달이 걸리는데, 계약은 그 전에 이뤄집니다.
threads.txt · 짧게, 끊어서
대행사 제안서는 다 그럴듯합니다.
당연합니다. 콘텐츠는 결과물이 나오기까지 최소 한 달이 걸리는데, 계약은 그 전에 이뤄지니까요.
같은 주장인데 링크드인은 결론부터 단정하고, 스레드는 공감부터 열고 들어갑니다. 이 차이를 매번 손으로 만들면 그게 아까 말한 한 시간입니다.
한 슬러그 폴더에 이렇게 남습니다.
linkedin.txt 링크드인용 — 길게, 존댓말, 문단 나눔
threads.txt 스레드용 — 짧게, 끊어서
naver.html 네이버용 — HTML (본문 서식 유지)
kakao.txt 단톡방 공유용 — 3줄 요약
posted.json 어디에 올렸는지 기록 (중복 발행 방지)
posted.json 이 빠지면 언젠가 같은 글이 두 번 올라갑니다. 어느 채널에 언제 올렸는지를 파일로 남겨두고, 발행 전에 그걸 먼저 확인하게 만들어야 합니다.03. 시간을 정해두고 잊는다
여기서 대부분 "예약 발행 도구"를 찾습니다. 그런데 채널마다 도구가 다르고, 도구가 늘수록 관리할 게 늘어납니다.
저희는 운영체제의 작업 스케줄러를 씁니다. 시각마다 스크립트를 하나씩 부르는 게 전부입니다. 별도 서비스도, 구독료도 없습니다.
schtasks /create /tn "채널_링크드인" ^
/tr "pythonw C:\경로\channel_publish.py linkedin" ^
/sc daily /st 11:00
schtasks /query /tn "채널_링크드인" 등록 확인
schtasks /run /tn "채널_링크드인" 지금 한 번 돌려보기
crontab -e 에 0 11 * * * python3 /경로/channel_publish.py linkedin 한 줄. 등록한 뒤 /run 으로 한 번 돌려보세요. 시간이 될 때까지 기다렸다가 실패를 발견하면 하루를 버립니다.시간은 어떻게 정하나
정답은 없지만 기준은 있습니다.
| 원칙 | 이유 |
|---|---|
| 원문 발행이 가장 먼저 | 다른 채널 글이 원문을 링크합니다. 원문이 없으면 링크가 깨집니다 |
| 채널끼리 최소 1시간 간격 | 같은 시각에 몰면 실패했을 때 무엇이 실패했는지 구분이 안 됩니다 |
| 사람이 깨어 있는 시간에 | 새벽 3시에 실패하면 그날 하루가 통째로 날아갑니다 |
| 채널 성격에 맞춰 | 링크드인·네이버는 업무 시간, 스레드는 퇴근 후가 반응이 낫습니다 |
저희가 11 · 12 · 13 · 19시로 잡은 이유가 이 네 줄입니다. 그대로 쓰셔도 되고, 본인 독자가 있는 시간으로 옮기셔도 됩니다.
여기서부터가 진짜 문제입니다
구조는 위 셋이 전부입니다. 그런데 실제로 굴려보면 무너지는 곳은 구조가 아니라 디테일입니다. 채널 팩을 어떤 규칙으로 뽑을지, 실패했을 때 어떻게 알아챌지.
채널별 포맷 규칙
같은 원문에서 뽑되 채널마다 다른 규칙을 겁니다. 링크드인은 첫 문장이 결론이어야 하고, 스레드는 한 덩어리가 세 줄을 넘으면 안 됩니다. 네이버는 검색으로 들어오는 사람 기준이라 도입부를 다르게 씁니다.
아래 원문에서 채널별 버전을 만들어줘.
[링크드인]
- 첫 문장이 결론. 질문으로 열지 마
- 문단마다 빈 줄. 한 문단 3줄 이내
그리고 실패했을 때 어떻게 알아채는지가 남습니다. 자동 발행의 진짜 위험은 실패가 아니라 조용한 실패입니다.
여기부터는 콘텐츠 살롱 멤버에게 열립니다
채널별 포맷 규칙 전문, 저희가 쓰는 팩 생성 지시문 그대로, 조용한 실패를 잡는 법, 그리고 채널을 하나 더 붙일 때의 순서가 이어집니다.
콘텐츠 살롱 멤버에게는 전체 공개됩니다.
이미 등록하셨다면 등록한 이메일로 확인해주세요
오늘 시작한다면
| 할 것 | 걸리는 시간 | |
|---|---|---|
| 1 | 원본을 어디에 둘지 정한다 (블로그, 노션, 문서 어디든 한 곳) | 5분 |
| 2 | 글 세 편을 먼저 쌓는다. 자동화는 그다음 | — |
| 3 | 채널 하나만 골라 팩 생성 + 발행을 붙인다 | 1시간 |
| 4 | 일주일 돌려보고 멀쩡하면 두 번째 채널 | — |
네 채널을 한 번에 붙이지 마세요. 어디서 깨졌는지 알 수 없게 됩니다. 하나가 일주일을 버티면 그때 다음 것을 붙이면 됩니다. 저희도 그렇게 넷이 됐습니다.
첫 주에는 오히려 느립니다. 붙이는 시간이 드니까요. 차이는 넷째 주에 납니다. 매주 한 시간씩 옮겨 붙이던 사람과, 그 한 시간을 글 쓰는 데 쓴 사람의 결과물 개수가 그때 갈립니다.
우리 채널에 맞는
발행 규칙이 궁금하다면
채널별 규칙과 지시문이 필요하시다면
위 구조는 그대로 가져가시면 됩니다. 채널별 포맷 규칙 전문과 저희가 쓰는 팩 생성 지시문은 콘텐츠 살롱 멤버십에 있습니다.
콘텐츠 살롱 멤버 되기 →직접 하실 시간이 없거나, 더 깊이 배우고 싶으시다면.