Google은 대량의 AI 콘텐츠를 게시하는 웹사이트 트래픽 중 최대 80%를 삭제했습니다. 이는 '규모가 큰 콘텐츠 남용(scaled content abuse)' 때문입니다.

하지만 저희는 여전히 아티클 제작을 자동화하고 싶었습니다. 따라서 문제는 '어떻게 빨리 생산할까'가 아니라, **'어떻게 기계가 쓰레기 같은 내용을 게시하는 것을 막을까'**였습니다.

이것이 저희가 채택한 아키텍처이며, 정말 중요한 코드 부분입니다.

파이프라인 (Le pipeline)

각 단계는 자체적인 컨텍스트를 가진 전문 Claude Code 에이전트에 의해 관리되는 6단계로 구성됩니다:

1. Chasseur      → 키워드 마이닝(실제 질문, 낮은 경쟁률) 수행
2. Cartographe   → Google의 1페이지를 읽고 다뤄진 질문 추출
3. Rédacteur     → 버전 관리된 보이스 가이드에 따라 작성
...

4단계가 정말 중요한 유일한 단계입니다. 이것이 없으면, 저희는 단순히 검색 엔진에서 색인(désindexer)되는 콘텐츠 공장만 갖게 됩니다.

코드화된 안전장치 (Le garde-fou, en code)

흔한 실수는 LLM에게 '이 아티클이 좋은가?'라고 묻는 것입니다. 자신의 결과물을 판단하는 모델은 순응적일 수밖에 없습니다.

그래서 저희는 결정론적인 스크립트를 도입했습니다. AI도 의견도 없이, 측정 가능한 기준들만 사용합니다:

const R = {
  minWords: 700,                    // 미달 시 = 콘텐츠가 빈약함
  introMin: 250, introMax: 1400,    // '답변 우선(answer-first)' 영역
...

그리고 스크립트를 코드 1로 종료시키는 검증들:

// frontmatter 전체 필수 항목
for (const k of R.required)
  if (!meta[k]) err(`frontmatter: "${k}" 누락`);
...

게시 스크립트는 이 코드를 가장 먼저 호출합니다:

set -e
node check.mjs      # ⛔ 종료 코드 1 발생 → 여기서 모든 것이 중단됨
node build.mjs
...

set -e + 종료 코드 1 = 아티클이 기준을 통과하지 못하면 게시가 구조적으로 불가능합니다. '한번 지켜보자' 같은 여지는 없습니다.

안전장치가 첫 번째 테스트에서 잡아낸 것

저희가 공들여 작성한 처음 세 개의 아티클에서도:

• 너무 긴 메타 설명 (meta descriptions trop longues) (180~214자). Google이 잘라냈을 것입니다. 눈에는 보이지 않지만, 스크립트에게는 명확했습니다.
• URL 아키텍처 변경 후 **깨진 내부 링크(lien interne cassé)**가 있었습니다.

밤 11시에 다시 읽어보는 사람이라면 아무도 발견하지 못했을 내용들입니다.

마주친 함정들

LLM이 자신의 작업물을 잘못 판단합니다. 그래서 결정론적 스크립트(script déterministe)가 필요했습니다. AI가 글을 쓰고, 코드가 측정하는 방식입니다.

시간대(fuseau horaire) 문제. new Date('2026-07-17T00:00:00Z').toLocaleDateString('fr-FR')는 7월 16일을 표시했습니다. 반드시 timeZone: 'UTC'를 강제해야 합니다. 그렇지 않으면 모든 게시 날짜가 하루씩 밀립니다.

빌드 잔여물(résidu de build). 배포 디렉터리 안에 잊힌 폴더 하나 때문에 웹사이트 전체가 잘못된 위치에 올라갔습니다. 그 이후로 빌드 스크립트만이 이 폴더에 글을 쓰도록 했고, 전송할 때마다 내용을 확인합니다.

규칙 조정(calibrage des règles). 첫 번째 버전은 직접적인 답변을 확인하기 위해 '첫 문단'만을 측정했습니다. 짧은 단락 스타일의 경우, 이는 지속적으로 경보를 울리게 했습니다. 이제는 첫 ## 이전의 전체 블록을 측정합니다.

제가 얻은 교훈

AI에게 글을 쓰게 하는 부분이 어려웠던 것이 아닙니다. 그것은 사소해졌습니다.

어려운 부분은 평범함을 게시하는 것을 불가능하게 만드는 것입니다. 수치화된 기준점, 종료 코드(code de sortie), 그리고 결코 이를 우회하지 않겠다는 규율입니다.

또 다른 점은 다음과 같습니다. 트래픽 볼륨이 메인 도메인으로 가지는 않습니다. 일주일에 3~4개의 아티클 정도가 적당하며, 30개가 아닙니다. 볼륨은 권위가 높은 플랫폼(high autorité) — 예를 들어 이곳과 같은 곳 — 에 분산됩니다. 우리가 가진 것은 자동화하고, 빌려 쓰는 것은 수작업으로 관리합니다.

저희는 개발 스튜디오입니다. 맞춤형 애플리케이션을 구축하고, 그렇게 하면서 배운 것을 문서화합니다. 전체 아키텍처에 관심이 있다면 저희 블로그에서 자세한 내용을 확인하실 수 있습니다.