1,600개의 기사 메타 설명(Meta descriptions)을 LLM으로 다시 작성해 본 솔직한 결과

메타 설명(Meta descriptions)은 콘텐츠가 많은 사이트에서 가장 과소평가된 SEO 요소입니다. 메타 설명은 순위에 직접적인 영향을 미치지는 않지만, 누군가가 Google 검색 결과에서 당신의 링크를 클릭할지 여부를 결정합니다. 순위가 높은 기사에 잘못된 메타 설명이 달려 있다면, 그것은 놓치고 있는 트래픽입니다. 저는 1,600개 이상의 사이버 보안 (cybersecurity) 기사를 보유하고 있었습니다. 그중 약 40%는 메타 설명이 아예 없었습니다. 다른 30%는 내용이 잘려 있거나, 키워드가 과도하게 삽입되었거나, 첫 번째 문단에서 그대로 복사하여 붙여넣은 상태였습니다 (이는 거의 항상 좋은 설명이 되지 못합니다). 그래서 저는 재작성 과정을 자동화했습니다. 실제로 어떤 일이 일어났는지 알려드리겠습니다.

제약 조건: 매번 140160자 유지
규칙은 단순하고 냉혹합니다: 메타 설명은 반드시 140160자여야 합니다. 단어 수가 아니라 — 글자 수(characters)입니다. 공백을 포함하여 말이죠. 140자 미만이면: Google이 종종 설명을 무시하고 자동으로 다시 작성합니다 (보통 품질이 좋지 않습니다). 160자 초과 시: 검색 결과에서 "..."와 함께 잘리게 되며, 이는 클릭률 (CTR)을 떨어뜨립니다. LLM으로 텍스트를 생성할 때 이는 생각보다 어렵습니다. 모델은 글자 수에 대한 자연스러운 이해 능력이 없으며, 길이가 아닌 일관성 (coherence)을 최적화하기 때문입니다.

저의 첫 번째 순진했던 프롬프트(prompt): {topic}에 관한 이 기사의 메타 설명을 작성해줘. 160자 미만으로 유지해줘. 결과: 95자에서 210자 사이의 설명들이 나왔습니다. 쓸모가 없었습니다.

실제로 효과가 있었던 프롬프트 엔지니어링 (prompt engineering)
많은 반복 끝에, 지속적으로 140~160자 범위를 유지했던 프롬프트는 다음과 같습니다:

이 사이버 보안 (cybersecurity) 기사를 위한 메타 설명을 작성해줘.
규칙:

• 정확히 140자에서 160자 사이로 작성할 것 (공백 포함하여 주의 깊게 계산할 것)
• 행동 동사(action verb)나 직접적인 훅(hook)으로 시작할 것
• 주요 주제와 하나의 구체적인 이점을 포함할 것
• 유행어(buzzwords) 사용 금지 (comprehensive, ultimate, complete 등)
• "이 기사에서는" 또는 "이 가이드에서는"과 같은 표현 사용 금지
  기사 제목: {title}
  기사 발췌문: {excerpt}
  주요 키워드: {keywords}
  설명만 출력하고 다른 것은 아무것도 출력하지 마.

주요 변경 사항:

• "under" 대신 "EXACTLY" 사용 — 모델은 소프트 제약 조건(soft constraints)보다 하드 제약 조건(hard constraints)을 더 잘 준수합니다.
• 피해야 할 것뿐만 아니라 포함해야 할 것에 대한 긍정적 프레이밍 (Positive framing)
• 모든 메타 코멘터리(meta-commentary) 제거 — "Output only the description"을 통해 모델이 자신이 무엇을 했는지 설명하는 것을 방지

이러한 프롬프트(prompt)를 사용했음에도 불구하고, 약 15%의 확률로 범위를 벗어난 결과가 나왔습니다. 그래서 검증(validation) 및 재시도 루프(retry loop)를 추가했습니다.

검증 파이프라인 (the validation pipeline)

import re

def validate_meta_description(desc: str) -> dict:
    length = len(desc)
    issues = []
    if length < 140:
        issues.append(f"Too short: {length} chars (min 140)")
    if length > 160:
        issues.append(f"Too long: {length} chars (max 160)")
    if desc.startswith(("In this", "This article", "This guide")):
        issues.append("Starts with forbidden phrase")
    if re.search(r'\b(comprehensive|ultimate|complete)\b', desc, re.I):
        issues.append("Contains buzzword")
    return {
        "valid": len(issues) == 0,
        "length": length,
        "issues": issues,
    }

def generate_meta_description(title: str, excerpt: str, keywords: list, max_retries: int = 3) -> str:
    for attempt in range(max_retries):
        desc = call_llm(build_prompt(title, excerpt, keywords))
        result = validate_meta_description(desc)
        if result["valid"]:
            return desc
        # 명시적인 수정 힌트와 함께 재시도
        if attempt < max_retries - 1:
            hint = f"Previous attempt failed: {', '.join(result['issues'])}. Try again."
            # 다음 프롬프트에 힌트 주입
            # (참고: 실제 구현에서는 build_prompt에 hint를 전달해야 함)
    return None  # 수동 검토 필요

3번의 재시도 후에도 실패한 항목은 수동 검토(manual review)를 위해 플래그를 지정했습니다. 약 4%는 사람의 개입이 필요했습니다.

결과: 솔직한 수치
저는 이 과정을 640개의 기사(설명이 누락되었거나 명백히 좋지 않은 기사들부터 우선적으로)에 대해 실행했습니다.

결과 수치

구분	개수	비율
첫 시도 시 유효함 (Valid on first try)	487	76%
재시도 후 유효함 (Valid after retry)	115	18%
실패 (수동 검토 필요) (Failed (manual review))	38	6%

품질 평가 (80개의 무작위 샘플을 수동으로 검토한 결과):

• 71% — 이전보다 개선됨
• 22% — 비슷한 품질
• 7% — 더 나빠짐 (주로 발췌문(excerpt)에 포함되지 않은 문맥이 누락된 경우)

품질이 더 나빠진 7%의 사례에는 공통적인 패턴이 있었습니다. 바로 발췌문이 부실하거나 누락된 기사들이었습니다. 모델이 작업할 재료가 없었던 것입니다. 이것은 다시 한번 콘텐츠의 문제입니다. LLM은 나쁜 원본 자료를 해결할 수 없습니다.

Search Console에서 측정한 지표
대량 업데이트를 진행한 후 데이터를 확인하기까지 6주를 기다렸습니다 (Google이 다시 크롤링(recrawl)할 시간이 필요하며 신호가 안정화되어야 하기 때문입니다). 업데이트된 기사들과 업데이트되지 않은 대조군(control group)을 비교한 결과는 다음과 같습니다:

• CTR (클릭률): 평균 +0.8%포인트 상승 (이 정도 규모에서는 통계적으로 유의미함)
• 노출수 (Impressions): 변화 없음 (예상대로 — 메타 설명(meta descriptions)은 순위에 영향을 미치지 않음)
• 순위 (Position): 변화 없음 (이 또한 예상된 결과)

의미 있는 트래픽이 발생하는 640개의 기사에서 0.8%포인트의 CTR 개선은 합산했을 때 상당한 수치가 됩니다. 극적인 변화는 아닙니다. 메타 설명 최적화만으로 극적인 결과를 약속하는 사람은 거짓말을 하고 있는 것입니다. 하지만 이는 실질적인 효과이며, 파이프라인(pipeline)이 구축되면 비용이 들지 않습니다.

예상치 못한 실패: 중복된 설명
제가 예상하지 못했던 한 가지는, 모델이 동일한 카테고리의 기사들에 대해 구조적으로 유사한 설명을 생성하기 시작했다는 점입니다. Active Directory 보안에 관한 가이드가 50개 있을 때, 많은 설명이 다음과 같은 동일한 패턴을 따르게 되었습니다: "[위협]으로부터 환경을 보호하기 위해 [AD 개념]을 [동사]하는 방법을 배우세요. [도구]를 활용한 단계별 가이드."

기술적으로는 유효합니다. 하지만 실질적으로 누군가 검색을 했을 때 동일한 사이트에서 거의 동일한 설명을 가진 결과가 5개나 보인다면, 사용자는 그중 아무것도 클릭하지 않을 것입니다.

해결책: 저는 단순한 n-gram 유사도(n-gram similarity)를 사용하여 새로 생성된 설명과 이미 생성된 설명을 비교하는 중복 제거(deduplication) 체크 과정을 추가했습니다. 유사도가 0.7보다 크면, 다른 구조를 사용하라는 명시적인 지침과 함께 강제로 재생성(regeneration)하도록 했습니다.

다르게 했을 일들
1.

LLM 생성을 실행하기 전에 발췌문(excerpts) 수정하기
생성된 설명(description)의 품질은 발췌문의 품질에 정비례합니다. 저는 먼저 모든 발췌문을 검토하고 수정했어야 했습니다. 순서를 잘못 잡았습니다.

2. 카테고리별 프롬프트 (Category-specific prompts)
   "뉴스" 기사를 위한 프롬프트는 "가이드"나 "체크리스트" 기사를 위한 프롬프트와 달라야 합니다. 뉴스 설명에는 긴박함(urgency)이 필요하고, 가이드는 이점(benefit)이 필요하며, 체크리스트는 범위(scope)가 필요합니다. 저는 모든 것에 하나의 프롬프트를 사용했고, 그 대가로 품질 저하를 겪었습니다.

3. 총합이 아닌 기사별 CTR(클릭률) 추적하기
   평균이 개선되었다는 것은 알지만, 어떤 특정 기사들이 개선을 이끌어냈는지는 모릅니다. 더 나은 계측(instrumentation) 도구가 있었다면 어떤 설명 스타일이 어떤 검색 의도(query intents)에 효과적인지 배울 수 있었을 것입니다.

실질적인 교훈
만약 다음과 같은 조건을 갖춘다면, LLM은 이러한 종류의 대량 텍스트 생성(bulk text generation) 작업에 진정으로 유용합니다:

• 엄격한 제약 조건(hard constraints)이 포함된 정교한 프롬프트 작성
• 검증(validation) + 재시도(retry) 로직 구축 (모델이 스스로 검증할 것이라고 믿지 마세요)
• 작업할 수 있는 괜찮은 소스 자료(source material) 보유
• 대리 지표(proxy)가 아닌 실제 다운스트림 지표(downstream metric, 예: CTR) 측정

만약 LLM이 잘못된 콘텐츠 전략을 보완해 줄 것이라고 기대한다면, 그것들은 유용하지 않습니다. 쓰레기가 들어가면, 약간 더 형식이 잘 갖춰진 쓰레기가 나옵니다 (Garbage in, slightly better-formatted garbage out).

저는 사이버 보안 컨설팅 회사인 AYI NEDJIMI Consultants를 운영하고 있습니다. 콘텐츠는 침투 테스트(pentesting), Active Directory, 클라우드 보안 및 컴플라이언스(compliance)를 다룹니다. 17개의 무료 보안 강화(hardening) 체크리스트를 이용할 수 있습니다 (PDF + Excel) — FortiGate, Palo Alto, pfSense, Active Directory 등.