블로그 자동화, 부수입용과
사업용은 설계가 반대입니다
많이 올리는 자동화와
빠짐없이 올리는 자동화는 다릅니다
요즘 AI 코딩 도구로 블로그 자동 발행 프로그램을 만드는 글이 많이 돕니다. 대부분 개인 부수입, 그러니까 광고 수익형 블로그가 기준입니다. 좋은 자료들이고, 저희도 참고했습니다.
그런데 사업체 블로그는 목적이 다릅니다. 조회수와 광고 수익이 아니라 신뢰와 문의가 목적입니다. 목적이 다르면 같은 도구로도 설계가 반대로 갑니다. 저희가 7월 29일부터 자사 칼럼을 자동 발행하며 3주 동안 확인한 것을 정리합니다. 잘 된 것과 안 된 것을 같이 씁니다.
목적이 다르면 설계가 반대로 갑니다
먼저 두 자동화가 어디서 갈라지는지부터 보겠습니다.
| 항목 | 부수입용(광고 수익) | 사업용(문의·신뢰) |
|---|---|---|
| 목적 함수 | 노출·조회·광고 클릭 | 문의·상담 전환 |
| 원본이 있는 곳 | 포털 블로그(부계정 권장) | 자사 도메인, 포털은 배포처 |
| 발행량 | 계정이 버티는 한 최대 | 하루 1편 상한, 대신 매일 |
| 소재 | 검색량 있는 키워드·이슈 | 고객이 실제로 물어본 것 |
| 검수 | 비공개 발행 후 확인 | 사람이 승인해야 나감 |
| 실패의 정의 | 계정 제재·저품질 | 틀린 말이 회사 이름으로 나가는 것 |
표의 오른쪽 열이 이 글의 전부입니다. 아래는 그 여섯 칸을 실제로 어떻게 정했고, 정한 대로 됐는지입니다.
결정 1 — 원본은 내 도메인에, 포털은 배포처로
사업체 블로그의 글은 자산입니다. 포털 계정에 원본을 두면 계정 정책이 바뀌는 순간 자산이 흔들립니다. 그래서 원본은 자사 홈페이지에 먼저 올리고, 네이버·링크드인·스레드에는 채널에 맞게 다시 쓴 판을 시간차로 배포합니다.
순서에도 이유가 있습니다. 검색엔진이 자사 사이트를 원문 출처로 먼저 색인해야 이후 채널에 올라간 글이 복제본이 아니라 배포본으로 취급됩니다. 이 배포 구조 자체는 이전 글에 정리했으니 여기서는 넘어갑니다.
결정 2 — 하루 1편 상한, 그리고 사람 승인 게이트
자동화를 붙이면 하루 열 편도 물리적으로는 됩니다. 저희는 코드에 하루 1편 상한을 두고, 그 1편도 사람이 리뷰 페이지에서 승인한 글만 나가게 했습니다. 승인이 없으면 시스템은 그날 아무것도 하지 않습니다.
이 설계의 결과를 숨기지 않고 쓰겠습니다. 8월 13일 이후 닷새 동안 승인을 안 했더니, 대기 글이 42편이나 쌓여 있는데도 닷새 내내 발행이 0이었습니다. 병목이 기계에서 사람으로 옮겨간 겁니다.
그래도 이 설계를 유지하는 이유 — 사업체 블로그에서 최악은 "안 올라간 날"이 아니라 "틀린 말이 회사 이름으로 나간 날"입니다. 닷새 공백은 승인 루틴을 아침 체크리스트에 넣어 고칠 수 있지만, 검수 없이 나간 글은 회수가 안 됩니다. 대신 승인 자체는 10분 안팎으로 끝나게 리뷰 페이지를 만들었습니다. 전문 펼쳐 읽기 → 승인 → 끝.
결정 3 — 소재는 뉴스가 아니라 상담에서
부수입용 자동화는 소재가 비면 그날 이슈에서 채워오게 만듭니다. 사업체 블로그에서 이렇게 하면 AI가 아는 일반론이 회사 이름으로 쌓입니다. "상황에 따라 다릅니다", "전문가와 상의하세요" 같은 문장들이요. 읽는 사람이 제일 빨리 알아채는 종류의 글입니다.
저희 소재 큐는 이번 주 상담에서 고객이 실제로 물어본 것, 구축하면서 실제로 막힌 것, 실제로 나온 숫자에서만 나옵니다. 그래서 대기 42편의 제목이 전부 "치과 리콜 자동화", "숏폼 한 편 제작비", "구축 비용과 기간"처럼 질문 모양입니다. 소재가 비면 채우지 않고 비워둡니다. 비는 날이 있어도, 지어낸 글이 있는 것보다 낫습니다.
결정 4 — 발행 전날 밤, 단톡방에 예고문 한 장
검색 유입은 쌓이는 데 몇 달 걸립니다. 그 사이 글을 읽는 사람이 0이면 발행 리듬은 의지만으로 유지되지 않습니다. 그래서 대기 글마다 단톡방용 예고문을 같이 만들어 두고, 전날 밤 방에 올립니다. 왜 이 글을 쓰는지 서너 문장, 그리고 "내일 아침 전문 올라갑니다" 한 줄.
이건 트래픽 장치가 아니라 관계 장치입니다. 검색으로 오는 낯선 사람이 아니라, 이미 저희를 아는 사람이 먼저 읽습니다. 사업체 블로그의 첫 독자는 원래 그쪽입니다.
결정 5 — 조용히 멈추는 자동화를 잡는 점검 항목
이 글을 준비하며 발견한 겁니다. 채널 배포를 맡은 워커가 옛 폴더의 발행 기록을 보고 있었습니다. 폴더를 옮긴 뒤로 워커는 매일 제 시각에 돌아서 "오늘 발행 글 없음 — 스킵"이라는 로그만 남기고 조용히 끝났습니다. 열흘이 넘도록요. 홈페이지 발행은 정상이었으니 아무도 몰랐습니다.
자동화는 안 도는 것보다 도는 척하는 게 무섭습니다. 에러가 나면 알람이라도 울리는데, "할 일 없음"으로 끝나는 건 성공처럼 보입니다. 이번에 두 가지를 바꿨습니다.
| 바꾼 것 | 왜 |
|---|---|
| 발행 기록 참조 경로를 한 곳으로 | 같은 사실(오늘 발행된 글)을 두 파일이 들고 있으면 언젠가 반드시 갈라집니다 |
| 주간 점검에 "스킵 로그 며칠 연속인가" 추가 | 발행은 있는데 배포 스킵이 이어지면 에러가 아니라도 고장입니다 |
사업체 자동화에서 특히 중요한 이유 — 개인 블로그는 며칠 비어도 본인 손해로 끝납니다. 사업체는 "매일 올린다"고 말해 놓고 열흘 비면 말과 실제가 어긋난 채로 노출됩니다. 조용한 고장이 신뢰 문제로 이어지는 구간입니다.
결정 6 — 측정은 방문자가 아니라 문의로
부수입용은 방문자와 광고 클릭이 곧 성과입니다. 사업체는 문의·상담 신청이 성과이고, 방문자는 중간 지표입니다. 그래서 성과 칸에는 방문자 수 대신 문의 건수를 적고, 방문자 그래프는 참고만 합니다.
다만 정직하게 쓰면, 3주는 이 지표를 말하기에 짧습니다. 이 기간 들어온 문의가 있지만 블로그 때문이라고 단정할 근거는 아직 없습니다. 분기 단위로 다시 정리해서 올리겠습니다. 잘되면 잘된 대로, 아니면 아닌 대로.
숫자로 보면 이렇습니다
| 항목 | 수치 (7/29 ~ 8/18) | 판정 |
|---|---|---|
| 자동 발행 | 16일간 15편 (하루 상한 1편, 일부 날 2편은 수동 즉시 발행) | 설계대로 |
| 대기 큐 | 42편 (전부 상담·구축에서 나온 소재) | 설계대로 |
| 승인 공백 | 5일 (8/14 ~ 8/18) → 그 기간 발행 0 | 설계가 만든 공백 |
| 채널 배포 워커 | 열흘 넘게 조용히 스킵 → 이 글 준비 중 발견·수정 | 설계에 없던 고장 |
| 하루 사람 몫 | 승인 10분 안팎 + 전날 밤 예고문 붙여넣기 | 설계대로 |
설계대로 된 것, 설계가 만든 공백, 설계에 없던 고장을 한 표에 그대로 적었습니다.
정리 — 도구는 같고, 상한과 게이트가 다릅니다
부수입용 자동화의 질문은 "얼마나 많이 올릴 수 있나"이고, 사업용 자동화의 질문은 "어떻게 하면 하루도 빠짐없이, 한 편도 틀리지 않게 나가나"입니다. 그래서 사업용은 상한을 낮게 박고, 사람 승인을 남기고, 소재를 상담에서 가져오고, 배포가 조용히 멈추는지를 봅니다.
이 뼈대는 콘텐츠 회사 전용이 아닙니다. 병원의 칼럼, 전문직 사무소의 인사이트, 쇼핑몰의 상품 소식처럼 회사 이름으로 정기적으로 나가는 글이 있는 곳이면 그대로 들어갑니다. 지금 그 발행을 손으로, 그것도 바쁘면 건너뛰며 하고 있다면 — 자동화 1순위는 발행량이 아니라 빠짐없음입니다.
우리 회사 콘텐츠 발행,
어디까지 자동화할까요?
매일 손으로 옮기는 그 발행, 시스템으로 바꿔드립니다
30분 무료 진단으로 지금 손으로 하는 반복 업무를 목록화하고, 자동화 가능 범위와 절감 시간을 추정해 드립니다.
무료 업무 진단 신청하기 →