AI로 블로그를 1100편 넘게 자동 발행하고 알게 된 것 2026 — URL 742개 중 86개가 서로 잡아먹고 있었다

Posted on by

AI 에이전트로 블로그 발행을 자동화하면 병목이 글쓰기라고 생각하기 쉽습니다. 그래서 다들 모델을 키우고, 프롬프트를 다듬고, 리뷰 단계를 붙입니다. 저도 그렇게 했습니다.

그런데 오늘 색인 상태를 점검하다가 전혀 다른 결론에 도달했습니다. 자동 발행 파이프라인의 진짜 실패 모드는 글의 품질이 아니라 글의 중복입니다. 그리고 이건 편당 품질 검사로는 절대 안 잡힙니다.

시작은 평범한 색인 점검이었습니다

운영 중인 워드프레스 블로그의 성과검증 대기 건이 쌓여서, 색인 상태부터 확인하는 루틴을 돌렸습니다. Search Console URL Inspection API로 우선순위 4건을 검사했더니 이런 결과가 나왔습니다.

  • 색인됨: 1건
  • “Google에는 아직 알려지지 않은 URL입니다”: 3건

여기까지 보면 결론이 뻔합니다. sitemap이 안 걸렸거나, robots.txt가 막았거나, 발행 스크립트가 URL을 못 만든 겁니다. 자동화 파이프라인에서 흔한 사고죠.

그래서 sitemap을 직접 열어봤습니다. robots.txt는 정상이었고, wp-sitemap.xml도 살아 있었고, 문제의 3개 URL은 전부 sitemap에 정상 등재돼 있었습니다. 오늘 저녁에 발행한 글까지 들어가 있었습니다.

발견 실패가 아니었습니다. Google은 URL을 알 수 있는 상태였는데 크롤하지 않기로 한 겁니다. 이건 배관 문제가 아니라 판단 문제입니다.

742개 URL을 전부 클러스터링해봤습니다

왜 크롤 우선순위에서 밀렸는지 알고 싶어서, sitemap의 URL 742개를 전부 디코딩한 뒤 slug 앞쪽 2토큰 기준으로 묶어봤습니다. 코드는 20줄이 안 됩니다.

결과가 이랬습니다.

겹침 클러스터
13 건강보험-피부양자
11 종합소득세-신고
11 해외주식-양도소득세
10 퇴직-후
9 isa-만기
9 국민연금-받기
6 초보자를-위한
6 종합소득세-모두채움
6 종합소득세-환급계좌를
5 종합소득세-환급금이

5개 이상 겹치는 클러스터가 10개, 합쳐서 86개 URL입니다. 전체의 11.6%입니다. 종합소득세 계열만 따로 합치면 28개고요.

건강보험 피부양자 클러스터를 펼쳐보면 상황이 더 선명해집니다. 탈락 기준과 탈락 조건이 따로 있고, 탈락 뒤 이의신청이 받아들여지는 경우와 탈락 후 이의신청이 가능한 경우가 각각 별도 글로 존재합니다. 사람이 읽으면 같은 질문입니다.

그리고 사고 흔적을 하나 찾았습니다

같은 클러스터 안에서 이런 쌍을 발견했습니다.

isa-만기-자금-어디로-옮길까-2026-연금저축-irp-배치-체크리
isa-만기-자금-어디로-옮길까-2026-연금저축-irp-배치-체크리-2

워드프레스가 slug 충돌 시 자동으로 붙이는 -2 접미사입니다. 같은 글이 두 번 발행됐다는 뜻입니다. 파이프라인이 중복 발행 가드를 통과했다고 로그를 찍었는데도 이런 게 남아 있었습니다.

더 웃픈 건, 오늘 색인 점검 큐에 P1로 올라온 게 -2 쪽이었다는 점입니다. 원본과 사본이 서로 순위를 갉아먹고 있으니 노출 0이 나오는 게 당연했습니다. 여기에 색인 요청을 눌렀다면 중복 페이지 하나를 더 밀어 넣는 셈이었을 겁니다.

자동 발행이 만드는 실패 모드의 정체

이 구조가 왜 생기는지는 파이프라인을 뜯어보면 바로 보입니다.

제 발행 게이트는 편당 검사만 합니다. 본문 글자 수 2,800자 이상, 문단 14개 이상, 금지 헤더 없음, FAQ와 출처 섹션 존재. 이 검사들은 글 하나를 독립적으로 봅니다.

그래서 “건강보험 피부양자 탈락 뒤 이의신청” 글은 통과합니다. 잘 쓴 글이거든요. 문제는 그 옆에 이미 열세 편이 있다는 사실을 게이트가 모른다는 점입니다. 편당 품질 검사는 정의상 이걸 볼 수 없습니다.

사람이 손으로 쓰던 시절에는 이 문제가 잘 안 생겼습니다. 비슷한 글을 열세 편 쓰려면 지겨워서 못 씁니다. 쓰다가 “이거 예전에 쓴 것 같은데” 하고 멈춥니다. 그 지겨움이 사실은 중복 방지 장치였던 겁니다.

에이전트는 안 지겨워합니다. 매일 새 글감을 받아서 매일 잘 씁니다. 그래서 1년쯤 돌리면 검색엔진 입장에서 구별이 안 되는 문서 뭉치가 만들어집니다. 속도가 올라간 만큼 자기잠식도 같이 빨라진 것이지, 새로운 병이 생긴 게 아닙니다.

그래서 파이프라인에 뭘 붙여야 하나

오늘 결론은 하나입니다. 편당 게이트만으로는 부족하고, 포트폴리오 게이트가 필요합니다.

제가 추가하려는 검사는 이겁니다.

신규 글 발행 전, 제목의 앞쪽 2토큰이 기존 발행 URL과 5개 이상 겹치면 new 발행을 막고 refresh 또는 hub_expand로 강제 전환한다.

구현 비용은 낮습니다. 이미 sitemap과 발행 원장이 있으니, 발행 직전 preflight에서 조회 한 번 더 하면 됩니다. 어려운 건 코드가 아니라 이 검사를 차단 조건으로 둘 것인가입니다.

경고로 두면 아무 의미가 없습니다. 자동화 파이프라인에서 경고는 로그에만 남고 아무도 안 읽습니다. 차단으로 걸어야 그 순간 사람이 “그럼 어느 글을 대표로 세울까”를 판단하게 됩니다.

자동화를 붙이기 전에 확인할 것들

같은 걸 하려는 분들이 미리 봤으면 하는 지점을 정리하면 이렇습니다.

발행량 목표를 KPI로 두지 마세요. “하루 3편”을 목표로 두면 파이프라인은 무조건 3편을 만듭니다. 만들 게 없으면 있는 주제를 미세하게 비틀어서 만듭니다. 그게 정확히 위 표를 만드는 방식입니다.

중복 검사는 제목이 아니라 검색 의도로 하세요. 제목 문자열 비교는 탈락 기준과 탈락 조건을 다른 글로 봅니다. 사람은 같은 질문으로 봅니다. slug 토큰 클러스터링이 완벽하진 않지만 문자열 비교보다는 훨씬 낫습니다.

발행 후 감사 루틴을 처음부터 넣으세요. 저는 1,100편을 발행하고 나서야 이걸 봤습니다. 100편쯤에서 돌렸으면 클러스터가 3~4개일 때 잡았을 겁니다. 지금은 86개 URL을 정리해야 하는 상황이고, 이건 301 리다이렉트와 canonical 지정이 필요한 수작업입니다.

중복 발행 가드 로그를 믿지 마세요. 제 파이프라인은 “중복 발행 가드 통과”를 매번 찍었는데도 -2 접미사 URL이 남았습니다. 가드는 발행 원장의 ID 기준으로 보는데, 실제 충돌은 워드프레스 slug 레벨에서 났습니다. 층이 다르면 못 잡습니다.

정리 비용은 발행 비용보다 훨씬 큽니다

이번에 가장 뼈아프게 느낀 부분입니다. 글 한 편을 자동으로 만드는 비용은 이제 거의 0에 수렴합니다. 리서치, 작성, 검증, 발행, 원장 기록까지 파이프라인이 몇 분 안에 끝냅니다.

그런데 잘못 만들어진 URL 하나를 정리하는 비용은 그대로입니다. 어느 글을 대표로 세울지 판단해야 하고, 나머지 글의 본문 링크를 옮겨야 하고, 301 리다이렉트를 걸어야 하고, 그게 반영되는지 확인해야 합니다. 이건 자동화가 잘 안 되는 영역입니다. 되돌리기 어려운 결정이 섞여 있어서 사람이 봐야 합니다.

생성 비용은 0으로 떨어졌는데 정리 비용은 그대로라는 건, 시간이 갈수록 정리가 밀린다는 뜻입니다. 그래서 자동 발행 시스템을 만들 때는 생성 속도만 설계하면 안 되고, 정리 속도가 생성 속도를 따라갈 수 있는 구조인지를 같이 봐야 합니다. 제 경우엔 안 따라갔고, 그 격차가 86개 URL로 쌓였습니다.

게이트를 어디에 두느냐가 결과를 바꿉니다

같은 검사라도 파이프라인의 어느 단계에 두느냐에 따라 효과가 완전히 다릅니다.

글감 수집 단계에 두면 후보가 아예 안 만들어집니다. 가장 싸고 깔끔하지만, 이 단계에서는 아직 최종 제목이 안 정해져서 정확도가 떨어집니다. 발행 직전에 두면 정확하지만, 이미 글을 다 쓴 뒤라 버리는 비용이 큽니다.

제 결론은 두 군데 다 두는 겁니다. 글감 단계에서는 경고로 띄워서 “이 주제는 이미 9개 있다”를 보여주고, 발행 직전에는 차단으로 걸어서 실제로 못 나가게 합니다. 앞쪽은 후보를 줄이고, 뒤쪽은 사고를 막는 역할입니다.

이 글에서 확인 안 된 것

정직하게 남길 부분이 있습니다. 이 분석은 URL 구조만 본 결과입니다. 각 글의 실제 노출과 클릭 데이터를 붙인 게 아닙니다.

그래서 “86개 URL이 서로 잡아먹고 있다”는 건 구조적 위험 진단이지, 각 글이 실제로 얼마를 잃고 있는지를 계산한 게 아닙니다. 클러스터별 대표 글을 확정하려면 GA4와 Search Console 성과 데이터를 붙여야 합니다. 그건 다음 작업입니다.

또 하나, 이건 워드프레스 사이트 한 곳 기준입니다. 같은 파이프라인으로 운영하는 다른 블로그는 플랫폼이 달라서 sitemap 구조부터 다릅니다. 아직 안 봤습니다.

FAQ

Q1. AI로 글을 많이 쓰면 무조건 자기잠식이 생기나요? 많이 쓰는 것 자체가 문제는 아닙니다. 문제는 편당 품질 검사만 있고 포트폴리오 검사가 없을 때입니다. 같은 검색 의도의 글이 쌓이는 걸 아무도 안 보면, 속도가 빠를수록 빨리 쌓입니다.

Q2. 몇 편부터 이 검사를 붙여야 하나요? 100편 근처가 좋다고 봅니다. 그쯤이면 클러스터가 눈에 보이기 시작하고, 아직 정리 비용이 작습니다. 1,000편을 넘기면 정리가 수작업 프로젝트가 됩니다.

Q3. slug 2토큰 클러스터링이 정확한가요? 완벽하지 않습니다. 제목 앞부분이 다르면 같은 주제여도 안 묶입니다. 다만 구현이 20줄이고 즉시 돌릴 수 있다는 장점이 큽니다. 정밀하게 하려면 임베딩 기반 유사도를 쓰는 게 맞지만, 우선 이걸로 상위 클러스터를 잡고 시작해도 충분합니다.

Q4. 중복이 발견되면 글을 지워야 하나요? 삭제보다 통합이 먼저입니다. 대표 글 하나를 canonical로 세우고, 나머지는 대표 글로 내부링크를 몰아주거나 301 리다이렉트를 겁니다. 삭제는 되돌리기 어렵고, 이미 붙어 있던 외부 링크까지 날립니다.

Q5. Search Console에서 색인 요청을 누르면 해결되나요? 중복 상태에서 요청하면 중복 페이지 하나를 더 밀어 넣는 셈입니다. 순서는 중복 정리 → 대표 글 지정 → 색인 요청입니다. 반대로 하면 크롤 예산만 씁니다.

Q6. 발행 게이트를 차단으로 걸면 파이프라인이 자주 멈추지 않나요? 멈추는 게 목적입니다. 멈춘 자리에서 사람이 new를 refresh로 바꾸면 그 글은 신규 URL을 만들지 않고 기존 글을 강화합니다. 파이프라인 처리량은 줄지만 URL 증가 속도가 같이 줄어드는 게 의도한 결과입니다.

참고 자료

※ 본문의 URL 개수, 클러스터 분포, 색인 검사 결과는 2026년 8월 8일 직접 운영 중인 사이트에서 수집한 값입니다. 사이트마다 결과는 다릅니다.

관련 글