AI가 쓴 "뻔한 글", 이 블로그는 실제로 어떻게 막는가 — 프롬프트 설계와 품질 게이트의 역할 분리

AI가 쓴 글이 온 인터넷을 뒤덮고 있습니다. 마우스 클릭 몇 번으로 2,000자짜리 글이 뚝딱 완성되는 시대입니다. 하지만 역설적이게도 독자들은 그 어느 때보다 빠르게 피로감을 느끼고 있습니다. 구글 역시 2024년 3월 코어 업데이트를 통해 ’대량 생성된 저품질 콘텐츠(Scaled Content Abuse)’를 검색 결과에서 대대적으로 퇴출하기 시작했습니다.

이 블로그 역시 생성형 AI로 초안을 만듭니다. 다만 흔히 오해하는 것과 달리, 이 블로그에는 “AI 특유의 뻔한 글투”를 사후에 자동으로 걸러내는 별도의 필터가 있는 것이 아닙니다. 실제로는 글을 쓰게 하는 프롬프트 자체를 설계 단계에서 다듬는 것과, 발행 직전 기계적으로 확인하는 것이 서로 다른 역할을 맡고 있습니다. 이 둘을 헷갈리기 쉬워서, 오늘은 정확히 무엇이 어디서 처리되는지 코드로 공개합니다.

AI 특유의 ’뻔함’을 만드는 4가지 패턴

LLM(대형 언어 모델)이 작성한 글에는 특유의 ‘사투리’ 혹은 ‘지문’ 같은 흔적이 남습니다. 기계적으로 정보를 취합하다 보니 발생하는 한계입니다. 흔히 관찰되는 패턴은 다음 4가지입니다.

1. 상투적이고 도식적인 서론과 결론

AI는 글의 시작과 끝을 맺을 때 놀라울 정도로 정형화된 틀을 사용합니다.

2. 구체성이 결여된 ’수식어 남발’과 ‘추상적 서술’

AI는 구체적인 데이터나 실증적 사례를 제시하기 어려울 때 수식어를 남발하는 경향이 있습니다. ‘매우 혁신적인’, ‘획기적인 지평을 넓힌’, ‘다양한 관점에서 조망하는’ 등 화려하지만 알맹이 없는 형용사구는 글의 신뢰도를 떨어뜨립니다.

3. 기계적인 병렬 구조 (첫째, 둘째, 셋째의 늪)

어떤 주제를 던져주든 “첫째, 둘째, 셋째, 마지막으로”의 구조로 항목을 나열하는 방식입니다. 정보의 경중(Priority) 없이 단순히 개념을 평면적으로 나열하기 때문에 독자가 끝까지 읽을 동력을 상실하게 만듭니다.

4. 지나치게 완곡하고 방어적인 어조

“~하는 것은 매우 중요하다고 볼 수 있습니다”, “~에 도움을 줄 수 있습니다”처럼 단정을 피하고 에두르는 표현이 반복되는 어조입니다. 영어 데이터를 기반으로 학습한 뒤 한국어로 번역/생성하는 과정에서 흔히 나타나며, 지나치게 격식을 차린 번역투 문장과 함께 독자에게 신뢰감을 주지 못합니다.

중요한 것은, 이 4가지는 발행 이후 어떤 자동화 스크립트가 “탈락”이라고 판정해서 걸러내는 항목이 아니라는 점입니다. 아래에서 보듯, 이 문제는 애초에 AI가 이런 식으로 쓰지 않도록 글을 생성하는 프롬프트 단계에서 다룹니다.

[비교] AI 날것의 초안 vs 다듬은 문장

’마케팅 자동화의 필요성’이라는 동일한 주제를 다루었을 때의 차이를 예시로 들어보겠습니다.

구분 AI 기본 출력 초안 다듬은 문장
도입부 (Hook) 현대 비즈니스 환경에서 마케팅 자동화는 기업의 성장을 위해 필수적인 요소로 자리 잡고 있습니다. 본 글에서는 마케팅 자동화가 왜 중요한지 그 이유와 효과를 살펴보겠습니다. “이메일 발송에만 매주 6시간을 쓰고 계신가요?” 마케팅 자동화는 단순히 ’편리한 도구’가 아니라, 기획에 써야 할 시간을 확보해 주는 생존 전략입니다.
정보 전달 방식 첫째, 시간 절약: 반복적인 업무를 자동화하여 시간을 아낄 수 있습니다.
둘째, 효율성 증대: 타겟 고객에게 맞춤형 메시지를 보낼 수 있어 효율적입니다.		 고객 가입 후 웰컴 메일 발송, 리드 점수화(Scoring) 등 손이 많이 가지만 규칙적인 업무를 백그라운드로 전환합니다. 담당자는 그만큼 확보된 시간을 캠페인 기획처럼 자동화가 대신할 수 없는 일에 쓸 수 있습니다.
문체 및 톤앤매너 귀사의 비즈니스에 자동화를 도입한다면 큰 시너지 효과를 창출할 수 있을 것으로 기대됩니다. 지금 당장 마케팅 자동화 툴을 결제하기 전에, 우리 팀의 ’수동 워크플로우’가 먼저 문서화되어 있는지부터 점검하십시오. 프로세스가 엉망이면 자동화 역시 엉망이 됩니다.

실제 파이프라인: 프롬프트 설계 → Fact-check → Quality Gate

이 블로그가 실제로 돌리고 있는 발행 파이프라인은 다음 순서로 동작합니다.

[1단계: 프롬프트로 구조·깊이를 지시해 초안 생성] ➔ [2단계: Fact-check (Gemini + 구글 검색 그라운딩)] ➔ [3단계: Quality Gate (기계적 4항목 최종 점검)] ➔ [필요시 사람이 직접 재작성 후 재발행] ➔ [최종 발행]

여기서 흔히 오해하는 지점이 있습니다. “뻔한 글투를 걸러내는 금지어 필터”가 별도 단계로 존재하는 것이 아니라는 점입니다. 실제로 발행 직전 quality-gate.mjs가 기계적으로 확인하는 항목은 정확히 4가지뿐입니다.

검사 항목 기준
팩트체크 완료 여부 draft: false인데 factChecked가 true가 아니면 반려
미확정 데이터 마커 잔존 본문에 미기입 데이터를 표시하는 운영자 확인 마커가 남아 있으면 반려
본문 최소 분량 400자 미만이면 반려
슬러그 중복 같은 파일명(슬러그)이 이미 존재하면 반려

상투적 표현이나 수식어 남발, 번역투 어조처럼 이 글 앞부분에서 다룬 4가지 패턴은 이 표에 없습니다. 이 문제는 애초에 생성 프롬프트 단계에서 미리 방지하도록 설계되어 있고, 그 결과물이 실제로 자연스러운지는 최종적으로 사람이 읽고 판단합니다. 이 블로그 소개 페이지에는 이런 문장이 있습니다.

“사실관계가 의심되는 내용은 사람이 직접 확인하고 수정한 뒤에만 발행합니다 — 실제로 지금까지 발행된 글 중 20% 정도에서 이 과정을 통해 실질적인 오류를 수정했습니다.”

이것이 이 블로그가 공개적으로 밝히고 있는 유일한 실측 수치입니다. “반려율 몇 %, 평균 수정 시간 몇 분” 같은 세부 통계는 별도로 집계하고 있지 않으며, 근거 없이 숫자를 지어내지 않는 것이 이 블로그의 원칙이기도 합니다.

뻔한 글을 예방하는 실제 프롬프트 설계 (3가지)

“좋은 글로 다듬어줘”라는 막연한 지시로는 LLM의 고질적인 습관을 고칠 수 없습니다. 실제로 초안을 생성하는 generate-post.mjs의 프롬프트에 담긴 지시는 다음 3가지로 요약됩니다.

- 소제목(##)을 포함한 구조화된 글이되, 매번 같은 뼈대("1. 2. 3." 번호 소제목 + 마지막
  "결론: 핵심 요약" 불릿)를 반복하지 말 것. 주제 성격에 맞게 비교표, 단계별 체크리스트,
  Q&A, 케이스 스터디 등 글마다 다른 구조를 선택한다.
- 사실에 기반한 정확한 내용만 작성 (확실하지 않은 수치/사실은 넣지 말 것)
- 이 블로그 운영자의 1인칭 경험이나 내부 실측 데이터가 필요한 대목에서는 절대 그럴듯한 값을
  지어내지 말고, 해당 위치에 운영자 확인이 필요하다는 마커를 그대로 남길 것.

원칙 1: 가장 흔한 뼈대(번호 소제목 + 결론 불릿)를 프롬프트에서 명시적으로 금지

막연히 “다양하게 써 달라”고 하는 대신, AI가 가장 자주 빠지는 정확한 패턴(“1. 2. 3.” 번호 소제목과 기계적인 요약 불릿으로 끝맺는 구조)을 콕 집어 금지하고, 대신 비교표·체크리스트·Q&A·케이스 스터디 중 주제에 맞는 구조를 고르도록 지시합니다.

원칙 2: 없는 데이터는 지어내지 않고, 자리만 남긴다

운영자의 실측 데이터나 1인칭 경험이 필요한 자리에서 AI가 그럴듯한 숫자를 지어내는 것이 가장 위험한 실패 패턴입니다. 그래서 이런 자리에는 운영자 확인이 필요하다는 마커를 그대로 남기도록 강제하고, 이 마커가 남은 채로는 quality-gate.mjs가 발행 자체를 막습니다. 사람이 실제 데이터를 채우거나, 없는 데이터라면 그 주장 자체를 들어내야만 발행됩니다.

원칙 3: 충분한 분량과 자연스러운 마무리를 명시적으로 요구

2,500~3,500자 분량을 요구해 표면적인 개요 나열에 그치지 않도록 하고, “글을 요약 불릿으로 기계적으로 마무리하지 말고 자연스러운 마무리 문단으로 끝낼 것”을 별도로 지시합니다. 이 두 가지가 앞서 본 “상투적 결론”과 “허술한 분량” 문제를 프롬프트 단계에서 줄이는 역할을 합니다.

여기까지가 프롬프트 설계로 예방하는 부분이고, 그럼에도 남은 문제(사실관계 오류, 남은 마커, 분량 미달, 슬러그 중복)는 앞서 설명한 Fact-check와 Quality Gate가 기계적으로 잡아냅니다.

Q&A: AI 콘텐츠 품질 관리에 관한 흔한 오해들

Q. AI가 쓴 글이라는 것을 구글(Google)이 정말 알아채고 불이익을 주나요? 구글의 공식 입장은 “AI로 작성했든 사람이 작성했든 상관없이, 사용자에게 유용하고 독창적인 콘텐츠(Helpful Content)라면 노출해 준다”입니다. 문제는 AI가 쓴 글 자체를 잡아낸다기보다는, AI가 쓴 글의 상당수가 ’기존 웹상의 정보를 짜깁기한 유용하지 않은 글’이기 때문에 시스템적으로 필터링된다는 점입니다. 즉, AI 작성 여부 자체가 죄가 아니라, ’깊이 없음’이 문제입니다.

Q. AI 탐지기(AI Detector) 툴을 신뢰할 수 있나요? 시중에 나와 있는 여러 AI 탐지 도구들은 오판율(False Positive)이 매우 높습니다. 특히 전문적인 한국어 텍스트에 대해서는 완성도 높은 탐지가 거의 불가능합니다. 기술적 도구에 의존하기보다, 본문에서 언급한 ‘상투적 표현 분석’, ‘문장 구조의 다양성’ 같은 기준을 사람이 직접 검수하는 것이 훨씬 정확합니다.

마치며: 프롬프트와 게이트는 서로 다른 일을 한다

’뻔한 글투’를 막는 것은 프롬프트 설계의 몫이고, ’사실관계 오류’와 ’발행 사고’를 막는 것은 Fact-check와 Quality Gate의 몫입니다. 이 둘을 하나의 “품질 게이트”로 뭉뚱그리면 실제로 무엇이 어떤 문제를 잡아내는지 놓치기 쉽습니다. 이 블로그는 이 두 역할을 분리해서 유지하고 있고, 그 경계 자체를 이번 글에서 공개했습니다.

연관 글