이 내기는 명확하게 기술되어 있습니다. 내 AI 모델 디렉터리에 반복되는 251개의 보일러플레이트 (boilerplate) 행을 수정하는 것이, 50개의 고유 페이지를 추가로 게시하는 것보다 다음 AdSense 심사에 더 큰 긍정적 영향을 미칠 것이라는 점입니다. 타임라인은 2026년 7월 말까지입니다. 만약 다음 거절 사유로 모델 페이지의 저가치 콘텐츠 (low-value content)가 여전히 언급된다면, 이 내기는 가장 직접적인 방식으로 틀린 것이 됩니다.

이는 테스트 가능한 주장입니다. 프로그래매틱 (programmatic) AdSense 승인에 관한 대부분의 조언은 콘텐츠 추가 — E-E-A-T 페이지, 더 많은 고유 항목, 편집 레이어 (editorial overlays) — 에 집중합니다. 저는 그 모든 것을 해보았습니다. 4번의 거절과 몇 달간의 반복 작업 끝에, 저는 제가 간과했던 것을 발견했습니다. 그것은 개별적으로 생성된 콘텐츠라고 생각했던 것 내부의 문장 수준 반복 (sentence-level repetition)이었습니다.

생성된 콘텐츠에 어떻게 467개의 동일한 문장이 나타났는가

AI 도구 디렉터리는 3단계 콘텐츠 품질 사다리 (three-tier content quality ladder)를 사용합니다. HuggingFace의 모델 메타데이터 스키마 (model metadata schema)에는 라이선스 태그, 아키텍처 문자열, 파이프라인 태스크 (pipeline task) 필드가 포함되어 있으며, 각 항목은 Hub REST API를 통해 이를 노출합니다. 항목들은 처음에는 빈약한 폴백 스텁 (fallback stubs)으로 시작하여, scripts/polish.py를 통해 메타데이터가 풍부한 설명으로 업그레이드되고, 최종적으로 Claude Haiku를 통해 완전한 LLM 생성 산문 (prose)에 도달합니다. LLM 단계는 일일 실행당 100회의 업그레이드로 속도 제한 (rate-limited)이 걸려 있습니다.

이 속도 제한은 구조적인 문제를 야기합니다. 1,449개의 모델 항목이 한꺼번에 업그레이드된 것이 아니라, 수십 번의 일일 실행에 걸쳐 배치 (batch) 단위로 처리되었으며, 각 실행 시 Claude Haiku에게 장점, 단점, 요약 및 사용 사례를 생성하도록 요청했습니다. 프롬프트 (prompt)는 실행 전반에 걸쳐 일관되게 유지되었는데, 이는 일관성이 항목당 생성 비용을 줄여주기 때문입니다.

일관된 프롬프트 (prompt) + 유사한 입력 (input) = 유사한 출력 (output). pros (장점) 및 cons (단점) 필드에 대해 중복 제거 감사 (deduplication audit)를 실행했을 때, 결과는 예상보다 더 좋지 않았습니다:

• 서로 다른 모델 항목의 pros 필드에서 동일한 문장이 467회 발견됨
• cons 필드에서 다른 반복 문장이 378회 발견됨
• 최소 하나 이상의 필드에서 공유된 상용구 (boilerplate)가 포함된 행이 총 251개 존재

가장 심각한 두 가지 사례는 transformers 라이브러리를 사용하는 HuggingFace 모델이라면 — 즉, 대부분의 모델에 — 그럴듯하게 적용될 수 있는 문장들이었습니다. 생성 프롬프트 (generation prompt)는 다른 항목들에 대해 알지 못했기 때문에 이를 방지하지 못했습니다. 각 호출 (call)은 독립적이었기 때문입니다.

AdSense 검토자가 20개의 무작위 모델 페이지를 스캔하다가 15개 페이지에서 동일한 문장을 발견한다면, 이는 큐레이션된 디렉토리가 아니라 콘텐츠 공장 (content mill)으로 보일 것입니다. noindex gate를 통해 품질이 낮은 항목들이 Google 인덱스에 포함되는 것은 막았지만, 문장 반복 문제는 인덱싱된 계층 (indexed tier)에서도 존재했습니다.

해결책: API 없이 기존 메타데이터를 활용한 결정론적 순환 (deterministic rotation)

251개 행 전체를 다시 생성하기 위해 Claude Haiku를 호출하는 것은 약 3달러의 API 비용이 발생하며, 동일한 구조적 위험을 다시 초래합니다. 즉, 유사한 입력에 대해 동일한 프롬프트를 실행하면 다시 유사한 출력을 얻게 되는 것입니다. 초기 폴백 (fallback) 업그레이드에 사용했던 결정론적 해시 풀 접근 방식 (deterministic hash pool approach)이 더 나은 방향을 제시해 주었습니다.

새로운 scripts/humanize-aiappdex.mjs 스크립트는 각 모델의 HuggingFace 레코드에 이미 존재하는 메타데이터 — 라이선스 유형 (license type), 파라미터 수 (parameter count), 양자화 형식 (quantization formats), 지원 언어 (supported languages), 아키텍처 제품군 (architecture family), 파이프라인 작업 (pipeline task), 다운로드 순위 (download rank) — 를 사용하여 영향을 받은 행들을 재구축합니다. 네트워크 요청도 없고, API 호출도 없습니다. 유일한 입력은 기존의 apps/ai-tools/src/data/models.json 파일뿐입니다.

고유성 메커니즘은 모델 ID의 FNV-1a 해시(hash)에서 파생된 슬러그(slug)별 시드(seed)입니다. 스크립트가 동등한 표현들 — 예를 들어 "14개 언어를 지원합니다"와 "14개 언어 쌍을 아우르는 다국어 지원" 사이에서 선택할 때 — (hash(slug) + facet_salt) % variants.length를 사용합니다. 메타데이터가 동일한 두 모델이라도 슬러그의 해시값이 다르기 때문에 서로 다른 표현을 얻게 됩니다.

function hash(str) {
  let h = 2166136261;
  for (let i = 0; i < str.length; i++) {
...

스크립트는 알려진 공통 상용구(boilerplate)를 포함하는 행(row)만 수정합니다. 기존 산문(prose)이 직접 작성되었거나, 패턴이 일치하지 않을 정도로 충분히 구체적으로 생성되어 진정으로 고유했던 행들은 변경되지 않고 그대로 유지됩니다.

lint:humanization --strict를 실행한 결과, 경고(warning)가 11개에서 0개로 줄었습니다. 251개의 행에는 이제 metadata-derived 태그가 붙어 있으며, 이는 LLM 재생성 대기열에서 해당 행들을 제외하므로, 향후 Haiku 실행 시 수정 사항이 덮어씌워지는 것을 방지합니다.

세 가지 접근 방식 비교

트레이드오프(tradeoff)는 산문의 품질입니다. "Apache 2.0 라이선스 하에 배포되어 제한 없이 상업적 배포가 가능합니다"와 같은 메타데이터 기반 문장은 편집된 글이 아니라 데이터베이스 주석처럼 읽힙니다. 반면, 프롬프트(prompt)가 충분히 구체적일 때 LLM이 생성한 산문은 더 자연스럽게 들립니다. 쌍별 모델 비교 페이지에서 LLM 산문을 사용하는 이유는, 비교 프레임워크(framing)에 메타데이터가 제공할 수 없는 추론(reasoning)이 필요하기 때문입니다.

하지만 모델 목록 페이지의 장단점에 대해서는, 고유성 제약(uniqueness constraint)이 산문 품질 제약(prose-quality constraint)보다 더 중요합니다. 사실적으로 정확하고, 디렉토리 내 다른 어디에서도 반복되지 않으며, 실제 메타데이터에 기반한 문장이 다른 466개 페이지와 공유되는 더 예쁜 문장보다 더 가치 있습니다.

내가 진지하게 받아들이는 반론

가장 강력한 반론은 이렇습니다. AdSense 검토자들은 251개의 모델 페이지를 일일이 읽으며 문장을 비교하지 않습니다. 그들은 몇 개의 페이지를 샘플링하여 해당 페이지가 검색 쿼리에 답을 하는지 확인하고, 광고 배치, 내비게이션, 콘텐츠 대 템플릿 비율과 같은 구조적 신호(structural signals)를 살펴봅니다. 본문 텍스트의 문장 수준 반복은 그들이 검토하는 임계값(threshold) 미만입니다.

만약 이것이 맞다면, 해결책은 도움이 되지 않을 것입니다. 세 번째와 네 번째 거절을 유발했던 우발적인 저가치 신호(accidental low-value signals)는 5초 동안 훑어보는 사람도 알아챌 수 있는 것들이었습니다. 방법론 페이지에서 AI 요약을 신뢰해서는 안 된다고 말하는 것, llms.txt가 사이트를 "실험(experiment)"으로 프레이밍(framing)하는 것, 일반적인 저자 표기 등이 그러합니다. 이것들은 한눈에 보입니다. 페이지 본문 두 단락 지점에 있는 동일한 문장은 그렇지 않습니다.

또한 커버리지(coverage) 측면의 논거도 있습니다. 나의 E-E-A-T 투명성 페이지(E-E-A-T transparency pages)는 마지막 거절 전에 이미 마련되어 있었지만, 거절을 막지는 못했습니다. 내가 직접 작성한 린트 체크(lint check)를 통과하는 인프라를 추가한다고 해서 AdSense 검토자들이 그것을 동일한 비중으로 다룰 것이라는 의미는 아닙니다.

나는 이 반론을 무시할 수 없습니다. 그것이 정확히 맞을 수도 있습니다. 문장 반복은 인간 검토자에게는 완전히 보이지 않을 수 있으며, Google의 자동화된 품질 신호와는 무관할 수도 있습니다. 솔직한 프레이밍(framing)을 하자면, 이 개입은 내가 측정한 대상을 목표로 하는 것이지, 이전 거절의 인과 요인이었다고 검증할 수 있는 대상을 목표로 하는 것이 아닙니다.

그럼에도 이것이 올바른 조치라고 생각하는 이유

AdSense 베팅이 맞는지 여부와 상관없는 두 가지 이유가 있습니다.

첫째, 콘텐츠 품질 게이트 (content quality gate)는 Dev.to에 게시되기 전에 문서 수준의 품질을 강제합니다. 이 로직을 디렉토리 엔트리(directory entry) 콘텐츠로 확장하는 것은 단순히 희망 사항이 아니라 일관된 논리입니다. 만약 제가 12개의 반복되는 문장이 포함된 600단어짜리 기사를 게시하지 않을 것이라면, 251개의 모델 페이지가 동일한 산문을 공유하는 것도 용납해서는 안 됩니다.

둘째, 메타데이터에서 추출된 텍스트는 그것이 대체하는 LLM(대규모 언어 모델) 생성 상용구(boilerplate)보다 사실 관계 측면에서 우수합니다. "HuggingFace의 transformers 파이프라인을 통해 로드되며 표준 추론 API를 지원합니다"라는 문장은 467개의 서로 다른 모델에 대해 반복되었던 장점이었습니다. 이는 모든 모델에 대해 기술적으로는 사실이었습니다. 하지만 모델 간의 차이를 구별하는 데 있어서는 완전히 무용지물이었습니다. 이를 해당 모델의 특정 라이선스, 아키텍처 및 언어 지원을 참조하는 문장으로 교체하는 것은, AdSense가 어떻게 생각하든 사용자에게 실행 가능한 정보를 제공합니다.

AI 디렉토리 vs Google AI 개요(AI Overviews) 베팅은 구조적 포지셔닝에 관한 것이었습니다. 즉, 큐레이션된 디렉토리가 AI가 생성한 요약이 제공할 수 없는 무언가를 제공할 수 있는가에 대한 문제였습니다. 이번 베팅도 동일한 구조를 가집니다. 만약 "이 페이지가 존재할 가치가 있는가?"라는 질문에 대한 답이 "예, 이 특정 모델에 대해 독특한 내용을 말해주기 때문입니다"라면, 문장 수준의 고유성은 단순히 AdSense에 관한 문제가 아닙니다. 그것은 디렉토리가 어쨌든 충족해야 할 편집 표준입니다.

내 생각을 바꿀 수 있는 것

세 가지 신호가 나타난다면 이 베팅이 틀렸음을 알게 될 것입니다.

동일한 문구로 인한 또 다른 거절. 만약 인간화 (humanization) 과정을 거친 후에도 다음 AdSense 검토에서 여전히 "가치 낮은 콘텐츠 (low-value content)" 또는 "콘텐츠 부족 (insufficient content)"을 이유로 인용하고, 특히 모델 페이지에서 거절이 발생한다면, 문장 고유성 (sentence uniqueness)이 변수가 아니었다는 뜻입니다. 다음 수정 사항을 안다고 가정하기 전에, 검토자가 실제로 무엇을 샘플링했는지 조사해야 할 것입니다.

차이가 없는 참여도 (Engagement) 데이터. 인간화 작업은 251개 페이지의 콘텐츠를 변경합니다. 만약 변경되지 않은 1,198개 페이지와 비교했을 때, 해당 페이지들의 페이지 체류 시간 (time-on-page)과 스크롤 깊이 (scroll depth)가 평이하다면, 메타데이터에서 파생된 텍스트 역시 사용자에게 가치를 제공하지 못하고 있다는 의미입니다. 그것이 해결책을 뒤집지는 않겠지만 — 페이지마다 다른 표현을 사용하는 것이 동일한 표현을 사용하는 것보다 여전히 낫지만 — 산문 품질 (prose quality)의 트레이드오프 (tradeoff)가 실제적이고 유의미하다는 것을 알려줄 것입니다.

린트 (Lint): 엄격한 인간화가 새로운 패턴을 발견함. 중복 제거 (deduplication) 감사 결과 467번과 378번이 가장 심각한 위반 항목으로 나타났습니다. 만약 500행 임계값 (threshold)에서 실시한 후속 감사에서, 이미 고유하다고 생각했던 항목들 내에서 다른 문장이 200번 반복되는 것을 발견한다면, 이는 감사 방식이 문제를 예방하는 것이 아니라 문제를 뒤쫓고 있다는 것을 의미합니다. 이에 대한 해결책은 구조적인 것, 즉 생성 프롬프트 (generation prompts)가 작동하는 방식을 바꾸는 것이지, 또 다른 중복 제거 과정을 거치는 것이 아닙니다.

30일 체크포인트

저는 2026년 7월 중순까지 AI 도구 디렉토리를 AdSense에 재제출할 것입니다. 그 결과는 이 베팅을 뒷받침하거나 반박할 것입니다. 저는 실수로 인한 가치 낮은 신호에 관한 포스트를 작성했던 것과 동일한 방식으로 후속 글을 작성할 것입니다. 즉, 거절이 발생한다면 그 구체적인 문구, 그로부터 추론한 내용, 그리고 다음에 무엇을 했는지를 다룰 것입니다.

만약 인간화 수정 후 첫 번째 재제출에서 통과된다면, 저는 인과관계 (causation)를 주장할 수 없습니다. 지난 몇 주 동안 사이트에 다른 변경 사항들이 있었기 때문입니다. 저는 오직 그 순서만을 보고할 수 있습니다. 그것이 이런 종류의 베팅에 대한 정직한 버전입니다. 결과는 측정할 수 있지만, 원인은 항상 측정할 수 있는 것이 아닙니다.

FAQ

메타데이터 로테이션 대신 Claude Haiku를 사용하여 인간화된 콘텐츠를 작성하지 않는 이유는 무엇인가요?

두 가지 이유가 있습니다. 결정론적 (Deterministic) 접근 방식은 동일한 입력에 대해 매번 동일한 출력을 생성합니다. 이는 CI 재실행 시 콘텐츠가 변경되지 않음을 의미하며, lint:humanization --strict 체크가 안정적으로 유지됨을 뜻합니다. 반면 확률론적 (Stochastic) LLM 출력은 실행할 때마다 동일한 린트 (lint) 체크를 서로 다르게 통과합니다. 두 번째 이유는 비용 예측 가능성입니다. Claude Haiku의 입출력 요율로 251개 행을 처리하는 것은 몇 달러 수준이지만, 만약 감사 (audit) 과정에서 계속해서 새로운 패턴이 발견되어 재실행이 필요해진다면 그 비용은 누적됩니다. API 비용이 전혀 들지 않는 방식은 토큰 예산에 대한 걱정 없이 모든 CI 환경에서 실행될 수 있습니다.

"lint:humanization --strict"는 정확히 무엇을 체크하나요?

이 명령은 models.json의 모든 항목에 걸쳐 summary, pros, cons, use_cases와 같은 모든 텍스트 필드를 스캔하며, 5개 이상의 행에서 동일하게 나타나는 모든 문자열을 찾아 표시합니다. --strict 플래그는 그 임계값을 3개로 강화합니다. 수정 전 발생했던 11개의 경고는 임계값을 초과하여 반복된 11개의 서로 다른 문장에 해당했으며, 수정을 통해 11개 모두 제거되었습니다.

풍부한 HuggingFace 태그가 없는 모델에도 메타데이터 기반 텍스트가 효과가 있을까요?