AI 블로그 자동 포스팅, 어디까지 맡기나 · 56편의 중단 기준
자사 블로그 56편을 AI 파이프라인으로 자동 발행하다 네 개 브랜드를 멈췄다. 글이 나빠서가 아니라 설명이 문장 중간에서 잘리고 없는 기능을 파는 일이 조용히 반복됐기 때문이다. 어디서 깨졌고 무엇을 사람에게 되돌렸는지 실제 숫자로 적었다.
AI로 블로그를 자동 발행하면 글은 실제로 나온다. 문제는 그 다음이다.
우리는 자사 블로그를 AI 파이프라인으로 운영했다. 주제를 고르고, 초안을 쓰고, 설명을 붙이고, 발행까지 사람 손 없이 돌아갔다. 그렇게 쌓인 글이 56편이다. 그리고 2026년 9월, 네 개 브랜드의 자동 발행을 멈췄다.
멈춘 이유는 글이 못 써서가 아니다. 글은 읽을 만했다. 깨진 곳은 전부 본문 바깥이었다.
이 글은 그 세 지점을 실제 숫자와 함께 적는다. 자동화를 쓸지 말지 정하는 데 필요한 것은 "AI가 글을 잘 쓰나"가 아니라 "어디서 깨지고, 그 깨진 것을 누가 발견하나"이기 때문이다.
자동 발행이 깨지는 곳은 본문이 아니다
파이프라인은 보통 이렇게 생겼다. 키워드 선정 → 아웃라인 → 초안 → 메타데이터(제목·설명) → 발행. 사람들이 품질을 걱정하는 곳은 초안이다. 실제로 사고가 나는 곳은 그 앞뒤다.
| 단계 | 흔한 걱정 | 실제로 터진 것 |
|---|---|---|
| 키워드 선정 | AI가 엉뚱한 주제를 고른다 | 볼륨은 맞는데 검색 의도가 다르다 |
| 초안 | 글이 어색하다 | 읽을 만했다 |
| 메타데이터 | — | 설명이 문장 중간에서 잘려 나갔다 |
| 사실 검증 | — | 없는 기능을 팔았다 |
| 반복 실행 | — | 낡은 지식이 매주 재생산됐다 |
걱정하던 칸은 비어 있고, 걱정하지 않던 칸이 차 있다. 이게 자동화의 실제 위험 분포다. 눈에 띄는 실패는 사람이 금방 잡지만, 조용한 실패는 몇 달을 간다.
설명이 문장 중간에서 잘렸다 — 56편 중 23편
가장 먼저 발견한 것이다. 메타 설명을 훑다가, 56편 중 23편(41%)이 문장 한가운데서 끊기고 "…"로 끝나 있는 것을 봤다.
전부 같은 패턴이었다. 긴 설명을 쓴 다음 160자에서 기계적으로 자른 것이다. 자르는 코드는 정상 작동했다. 자를 위치를 고르지 않았을 뿐이다.
문제는 그 문자열이 어디로 가느냐다. 라이브에서 확인해 보니 잘린 문장이 description과 og:description 양쪽에 그대로 들어가 있었다. 검색 결과 스니펫과 카카오톡·슬랙 공유 카드가 동시에 걸린다. 사람이 그 글을 찾아보기도 전에 만나는 첫 문장이 미완성 문장이었다는 뜻이다.
41%가 이 상태로 몇 달을 있었는데 아무도 말하지 않았다. 당연하다. 자기 글의 메타 설명을 검색 결과에서 확인하는 사람은 거의 없다. 사이트에서는 멀쩡해 보인다.
왜 자동화가 이걸 못 잡나
길이 제한은 지켰기 때문이다. 게이트가 있었다면 "160자 이하"를 통과시켰을 것이다. 규칙은 만족했고 결과는 망가졌다.
자동화에서 검사할 것은 "몇 자인가"가 아니라 **"문장이 끝났는가"**다. 마침표나 종결어미로 끝나는지 보는 검사 한 줄이면 23편 전부 잡혔다.
이 검사는 도구가 없어도 할 수 있다. 글 목록을 뽑아 설명 필드의 마지막 글자만 모아서 보면 된다. 마침표가 아닌 것, 특히 …나 조사로 끝나는 것이 걸리는 대로 잘린 것이다. 우리는 이 한 번의 확인으로 23편을 찾았고, 그 뒤로는 발행 전 게이트에 넣어 다시 생기지 않게 했다.
같이 봐야 할 것이 두 가지 더 있다. 제목을 그대로 되풀이한 설명과 본문과 어투가 다른 설명이다. 전자는 검색 결과에서 같은 문장을 두 번 보여주는 셈이라 클릭할 이유를 주지 못하고, 후자는 사람이 쓴 글에 기계가 요약을 붙인 티가 난다. 우리가 23편을 다시 쓸 때 실제로 한 건이 이 어투 불일치로 걸렸다 — 본문은 "습니다"체인데 설명만 "한다"체였다.
없는 기능을 파는 글이 9편 있었다
설명을 고치다 본문에서 더 나쁜 것을 봤다. 전수 검색한 결과다.
| 문제 | 편수 | 본문에 쓰여 있던 것 |
|---|---|---|
| 다채널 동시 자동 발행 | 7 | "여러 채널에 동시 발행합니다", FAQ에 "네, 가능합니다" |
| 외부 블로그 연동 발행 | 1 | 위 7편 중 1편에 중복 |
| 폐기된 가격표 | 2 | 이미 없어진 요금제 이름과 금액 |
우리 제품은 그 시점에 다채널 동시 발행을 하지 않았다. 해당 기능은 그전에 제거됐고 자사 블로그 하나만 남아 있었다. 그런데 글은 계속 그 기능을 설명하고 있었다. 가장 심한 글은 H2 섹션 하나가 통째로 없는 기능의 작동 방식이었다. 표까지 그려져 있었다.
이건 오탈자가 아니다. 읽는 사람 입장에서는 허위 광고다. 그 글을 보고 문의한 사람에게 "그 기능은 없습니다"라고 말해야 한다.
원인은 초안 품질이 아니라 지식의 나이였다
AI는 주어진 브랜드 지식을 충실히 옮겼다. 그 지식이 낡았을 뿐이다. 제품에서 기능을 제거했을 때 코드와 가격표는 고쳤지만, 파이프라인이 참조하는 브랜드 설명은 그대로 남았다.
그래서 이 오류에는 자기 복제 성질이 있다. 사람이 쓰면 한 번 틀리고 끝이지만, 자동화는 같은 지식으로 다음 주에 또 쓴다. 우리는 9편을 손으로 고쳤는데, 고치는 동안에도 파이프라인은 같은 지식으로 새 글을 쓰고 있었다.
틀린 글을 고치는 것과 틀린 글이 생기는 것을 멈추는 것은 다른 일이다. 전자만 하면 영원히 따라잡지 못한다.
제품 주장만 뽑아서 보는 방법
전수 검색은 생각보다 간단하다. 글 전체를 읽을 필요가 없다. 제품을 주장하는 문장에는 공통된 단어가 들어간다. 기능 이름, 요금제 이름, 금액, 그리고 "가능합니다", "지원합니다", "자동으로" 같은 서술어다.
우리가 실제로 쓴 순서는 이렇다. 먼저 현재 제품에서 없어진 기능의 이름을 목록으로 적는다. 그 단어가 들어간 문장을 전부 뽑는다. 뽑힌 문장만 읽는다. 56편을 다 읽는 대신 수십 개 문장만 보면 된다.
FAQ 섹션은 따로 봐야 한다. 본문은 조심스럽게 쓰여 있어도 FAQ는 "네, 가능합니다" 한 줄로 단정하는 경우가 많다. 우리가 찾은 7편도 FAQ 쪽이 더 노골적이었다. 그리고 FAQ는 검색 결과에 구조화 데이터로 따로 노출될 수 있어서 틀렸을 때 더 멀리 간다.
일괄 수정이 멀쩡한 글을 망칠 뻔했다
고칠 때도 한 번 걸렸다. 폐기된 가격을 찾으려고 정규식으로 금액 패턴을 훑었더니 12건이 걸렸다. 그중 3건은 손대면 안 되는 것이었다.
- 경쟁사 비교 글에 적힌 제3자 업체의 공개 가격
- 도구 비교 글에 적힌 남의 제품 등급명
일괄 치환했으면 정상적인 비교 콘텐츠를 망가뜨렸을 것이다. 자동으로 만든 문제를 자동으로 고치려다 새 문제를 만드는 전형적인 자리다. 찾는 것은 기계가 하고, 고칠지 말지는 맥락을 보고 정해야 한다.
그래서 자동화를 버렸나 — 아니다
멈춘 것은 발행이다. 파이프라인 전체가 아니다.
| 계속 쓰는 것 | 사람에게 되돌린 것 |
|---|---|
| 키워드·주제 후보 발굴 | 무엇을 쓸지 최종 선택 |
| 검색 순위·노출 지표 수집 | 지표를 보고 무엇을 고칠지 판단 |
| 내부 링크 후보 제안 | 어느 문장에 링크를 넣을지 |
| 중복·잠식 검사 | 중복일 때 어느 쪽을 살릴지 |
| 초안 작성 | 사실 검증과 발행 |
경계가 어디에 그어졌는지 보면 규칙이 하나 보인다. 되돌릴 수 있는 일은 기계가 하고, 한 번 나가면 주워 담을 수 없는 일은 사람이 한다.
후보를 잘못 뽑으면 버리면 된다. 지표를 잘못 모으면 다시 모으면 된다. 그러나 발행은 다르다. 검색엔진이 읽어 가고, 공유 카드가 만들어지고, 누군가 그것을 보고 연락한다. 되돌리는 비용이 만드는 비용보다 훨씬 크다.
사람이 들어가야 하는 자리는 어디인가
우리 경험으로는 네 군데다.
제품 사실이 들어가는 문장. 기능·가격·범위를 말하는 모든 문장이다. 이것만 검증해도 위의 9편은 나가지 않았다. 글 전체를 읽을 필요도 없다. 제품을 주장하는 문장만 뽑아서 보면 된다.
검색 결과에 노출되는 문자열. 제목과 설명이다. 본문보다 짧은데 더 많이 읽힌다. 그리고 본문과 달리 잘못돼도 사이트에서는 안 보인다.
숫자와 출처. AI는 근거를 그럴듯하게 요약하지만 어디서 왔는지는 적지 않는다. 숫자가 들어간 문장은 출처를 확인하거나 빼야 한다. 표기 형식 자체가 헷갈린다면 인용 표기법 기준을 참고하면 된다.
발행 버튼. 위 세 가지를 통과했더라도 마지막 확인은 사람이 누른다. 우리가 이 경계를 실제로 어디에 그었는지는 자사 채널 콘텐츠 자동화 적용 기준에 적어 뒀다.
반대로 사람이 굳이 볼 필요가 없는 것도 분명하다. 문체 다듬기, 문단 순서, 소제목 표현 같은 것들이다. 여기에 시간을 쓰면 정작 위험한 네 군데를 볼 시간이 없어진다.
자동화를 붙이기 전에 만들어야 하는 것
도구를 고르는 것보다 먼저다. 순서를 바꾸면 위의 사고를 그대로 반복한다.
하나, 제품 사실의 단일 출처. 기능·가격·범위가 한 군데 적혀 있고, 바뀌면 거기만 고치면 되는 상태. 이게 없으면 파이프라인이 참조하는 지식은 반드시 낡는다. 우리가 겪은 9편이 정확히 이 문제였다.
둘, 나가는 것을 검사하는 게이트. 길이가 아니라 상태를 본다. 문장이 끝났는가, 제품 주장이 들어 있는가, 숫자에 출처가 있는가. 게이트는 통과/차단을 말할 뿐 고치지는 않는다.
셋, 되돌릴 방법. 발행 전 상태를 남겨야 한다. 우리는 글을 고칠 때마다 이전 상태를 파일로 남긴다. 되돌릴 수 있다는 것을 알면 고치는 결정이 빨라진다.
넷, 정기적인 전수 점검. 새 글만 보면 이미 나간 글의 문제는 영원히 안 보인다. 23편도 9편도 새 글을 검사해서 찾은 것이 아니라 전수로 훑다가 나왔다.
전수 점검은 자주 할 필요가 없다. 대신 제품이 바뀔 때마다 해야 한다. 기능을 없앴거나 가격을 바꿨다면 그날이 점검일이다. 바뀐 것의 이름으로 기존 글을 훑는 일은 십 분이면 끝나고, 안 하면 그 글들은 바뀌기 전 제품을 계속 설명한다.
우리 경우 이 네 가지 중 첫 번째가 없었던 것이 결정적이었다. 제품 사실이 코드·가격표·브랜드 설명 세 군데에 흩어져 있었고, 기능을 없앨 때 앞의 둘만 고쳤다. 나머지 한 곳을 파이프라인이 읽고 있었다. 어느 하나가 빠졌다기보다, 어디가 진짜인지 정해져 있지 않았던 것이다.
도구를 고르기 전에 물어야 할 것
도구 비교표보다 이 질문들이 먼저다. 어느 도구를 쓰든 답해야 하기 때문이다.
- 이 도구가 참조하는 제품 정보를 어디서 고치나? 고칠 데가 없으면 낡은 정보가 계속 재생산된다
- 발행 전에 멈출 수 있나? 승인 단계 없이 바로 나가는 구조라면 사고가 나간 뒤에 발견한다
- 이미 나간 글을 한꺼번에 검사할 수 있나? 새 글만 보는 도구는 쌓인 문제를 못 본다
- 되돌릴 수 있나? 발행 전 상태가 남는지, 한 번에 되돌릴 수 있는지
- 만든 글의 메타 설명을 실제 검색 결과 형태로 볼 수 있나? 사이트 화면에서는 안 보이는 곳이다
다섯 개 중 몇 개에 "아니오"가 나오는지가, 그 도구를 붙였을 때 사람이 얼마나 붙어 있어야 하는지를 말해 준다.
결국 무엇이 남았나
자동 발행을 멈추고 사람이 쓰기 시작한 뒤에도 파이프라인의 절반은 그대로 돌아간다. 없앤 것은 도구가 아니라 검증 없이 나가는 경로다.
그리고 그 판단은 "AI 글은 품질이 낮다"는 이유가 아니었다. 품질은 괜찮았다. 문제는 틀렸을 때 그것을 발견할 방법이 파이프라인 안에 없었다는 것이다. 41%의 잘린 설명도, 9편의 없는 기능도, 사람이 다른 일을 하다가 우연히 봤다.
자동화를 검토하고 있다면 물어야 할 것은 하나다. 이것이 틀렸을 때, 누가 언제 알아차리는가.
이 질문에 답이 없는 상태로 편수를 늘리면, 늘어나는 것은 콘텐츠가 아니라 아무도 읽지 않은 채 검색에 노출되는 문장의 수다. 우리는 그 수가 56편까지 간 뒤에야 확인했다. 더 일찍 봤어야 했다는 것이 이 글의 결론에 가깝다.
자주 묻는 질문
AI가 쓴 글은 검색에서 불이익을 받나요?
구글은 생성 방식이 아니라 유용성을 기준으로 삼는다고 밝히고 있다. 우리 경험으로도 순위 문제가 생긴 적은 없다. 문제가 된 것은 사실이 틀렸거나 메타데이터가 망가진 경우였고, 그건 사람이 썼어도 똑같이 문제가 된다.
초안까지만 AI에 맡기면 안전한가요?
훨씬 안전하다. 위에서 적은 세 가지 사고는 전부 발행까지 자동으로 이어졌기 때문에 생겼다. 초안 앞단인 브리프까지만 자동화하는 방식은 AI 콘텐츠 브리프 자동화 기준에서 다뤘다. 초안에서 멈추면 사람이 읽는 단계가 강제로 들어간다. 다만 초안만 쌓이고 아무도 검토하지 않으면 자동화의 이득도 같이 사라진다.
글이 몇 편부터 이런 문제가 생기나요?
편수보다 전수로 훑어본 적이 있는가가 기준이다. 우리는 56편에서 발견했지만, 20편이어도 아무도 메타 설명을 확인하지 않았다면 같은 비율로 깨져 있었을 것이다. 지금 몇 편이든 한 번은 전부 훑어볼 필요가 있다.
검토에 시간이 얼마나 드나요?
글 전체를 다시 읽으면 자동화의 의미가 없다. 우리는 제품을 주장하는 문장과 검색에 나가는 문자열만 본다. 한 편에 몇 분이면 된다. 어디를 볼지 정해 두는 것이 검토 시간을 줄이는 유일한 방법이다.
자동화하면 시간이 얼마나 줄어드나요?
줄어드는 것은 쓰는 시간이고, 늘어나는 것은 확인하는 시간이다. 우리 경우 초안 작성은 확실히 빨라졌지만, 위의 사고를 겪은 뒤로는 발행 전 확인 단계가 생겼다. 총량으로 보면 글 한 편당 시간은 크게 줄지 않았고, 대신 편수를 늘릴 수 있게 됐다. 한 편을 빨리 내는 것과 여러 편을 감당하는 것은 다른 이득이다. 기대를 전자에 걸면 실망한다.
이미 나간 글에 문제가 있으면 지워야 하나요?
지우는 것은 대개 최후의 선택이다. 우리는 9편 모두 고쳐서 살렸다. 사실이 틀린 문장을 고치고, 없는 기능을 설명한 섹션은 실제 동작으로 다시 썼다. 지우면 그 URL이 쌓아 둔 것까지 같이 사라진다.
참고 자료
- AI 생성 콘텐츠에 대한 구글 검색의 안내 — Google 검색 센터 — 생성 방식이 아니라 유용성을 기준으로 평가한다는 공식 입장.
- 유용하고 신뢰할 수 있는 콘텐츠 만들기 — Google 검색 센터 — 경험·전문성·권위·신뢰를 자가 점검하는 질문 목록.
- 제목 링크와 스니펫 관리하기 — Google 검색 센터 — 메타 설명이 검색 결과에 어떻게 쓰이는지에 대한 공식 문서.