GEO 분석 도구에서 E-E-A-T를 재현 가능하게 점수화하는 방법

GEO(Generative Engine Optimization)는 ChatGPT, Gemini 같은 생성형 AI 환경에서 콘텐츠가 발견되고 답변의 근거로 활용될 가능성을 개선·분석하려는 실무 개념이다. 다만 생성형 AI 서비스가 출처를 선택하는 완전한 공식을 공개한 것은 아니며, GEO에 통용되는 단일 표준 점수도 없다.

Google의 E-E-A-T는 Experience, Expertise, Authoritativeness, Trustworthiness를 뜻하지만, Google이 웹페이지마다 공개하는 공식 수치가 아니다. 따라서 분석 도구가 표시하는 ‘E-E-A-T 78점’은 Google의 판정이 아니라 해당 도구가 정의한 관측 지표라는 사실을 명확히 밝혀야 한다.

LLM에 직접 점수를 맡기면 안 되는 이유

웹페이지 전체를 LLM에 넣고 경험·전문성·권위성·신뢰성을 각각 100점으로 평가하게 하면 빠르게 프로토타입을 만들 수 있다. 그러나 운영용 측정 시스템으로는 다음 문제가 생긴다.

• 같은 콘텐츠와 프롬프트에서도 실행할 때마다 점수가 달라질 수 있다.
• 모델 또는 제공 업체가 바뀌면 과거 점수와 비교하기 어렵다.
• 페이지에 없는 경력, 자격, 평판을 추론하는 환각이 발생할 수 있다.
• 점수에 영향을 준 문장과 규칙을 감사하기 어렵다.
• 외부 검증 없이 사이트의 자기소개를 사실로 받아들일 수 있다.
• 긴 문서가 잘리거나 추출 순서가 바뀌면 평가 결과도 변할 수 있다.

권장 구조는 다음과 같다.

웹사이트
  → 단일 시점 스냅샷 수집
  → 본문·메타데이터·엔티티·주장 추출
  → 외부 자료와 교차 검증
  → 버전이 고정된 규칙으로 점수 계산
  → 점수·근거·신뢰도 저장
  → LLM이 결과를 자연어로 설명

LLM을 전혀 사용하지 않아야 한다는 뜻은 아니다. 문장 분류, 주장 후보 추출, 이름 변형 탐색 등에 활용할 수 있지만, 결과를 원문 근거와 연결하고 캐시해야 한다. 최종 산술 계산과 상한·감점 규칙은 코드가 담당하는 편이 재현성과 감사 가능성을 높인다.

먼저 정의해야 할 평가 대상과 범위

점수 계산 전에 무엇을 평가하는지 고정해야 한다. 사이트 전체, 조직, 작성자, 개별 문서의 신호는 서로 대체할 수 없다.

주제도 함께 분류해야 한다. 의료·금융·법률처럼 잘못된 정보의 피해가 큰 분야와 개인 취미 후기는 요구되는 전문성 및 신뢰 증거가 다르다. 하나의 고정 가중치를 모든 분야에 적용하면 점수의 의미가 약해진다.

동일한 웹 스냅샷을 수집하는 방법

분석기는 한 번 저장한 스냅샷을 공유해야 한다. 본문은 오전 10시, JSON-LD는 10시 5분, 작성자 페이지는 10시 10분에 각각 다시 요청하면 변경된 상태가 섞일 수 있다.

스냅샷에는 가능하면 다음 항목을 저장한다.

• 최종 URL, 리디렉션 경로, HTTP 상태 코드 및 응답 헤더
• 원본 HTML과 필요한 경우 렌더링된 HTML
• 추출 본문, 제목, 설명, canonical 및 언어 정보
• 작성자, 발행일, 수정일, 발행 조직
• 내부·외부 링크와 앵커 텍스트
• JSON-LD, Microdata 등 구조화 데이터
• robots 지시, sitemap에서 확인한 관련 URL
• 수집 시각, 수집기 버전, 콘텐츠 해시

여러 페이지를 탐색할 때는 홈페이지에만 의존하지 않는다. sitemap.xml과 내부 링크를 이용해 About, Company, Team, Author, Profile, Editorial Policy, Contact, Privacy, Terms 같은 후보를 제한된 깊이에서 탐색한다. 개인정보나 이용 제한이 있는 페이지를 무리하게 수집해서는 안 되며 robots 정책, 서비스 약관, 적용 법률도 확인해야 한다.

온사이트 증거와 오프사이트 증거 분리

온사이트 데이터는 해당 사이트가 직접 게시한 정보다. 작성자 소개, 제품 설명, 고객 사례, 편집 정책, 연락처, Person·Organization 구조화 데이터 등이 여기에 속한다.

오프사이트 데이터는 독립된 외부 출처가 작성자나 조직을 어떻게 확인하는지 보여준다. 정부·공공기관 자료, 학술기관, 전문 협회, 신뢰할 수 있는 언론, 업계 자료, 외부 프로필, 관련 백링크와 인용 등이 해당한다.

두 종류의 증거는 점수에서 구분해야 한다.

• ‘업계 최고’ 같은 자기 홍보 문구는 Authority의 독립 증거가 아니다.
• 외부 기사라도 보도자료를 그대로 전재한 자료는 독립성이 낮다.
• 서로 다른 URL에 같은 기사가 복제됐다면 출처 수를 중복 계산하지 않는다.
• 이름이 같은 다른 사람이나 조직의 실적을 연결하지 않도록 엔티티를 확인한다.
• sameAs 링크는 엔티티 후보를 연결하는 단서이지, 해당 경력의 진실을 자동 보증하지 않는다.

Experience: 직접 경험을 증거로 바꾸기

Experience는 작성자가 제품을 사용하거나 장소를 방문하고, 절차를 수행하거나 실험을 운영한 직접 경험을 평가한다. Expertise와 별개다. 노트북을 장기간 사용한 구매자는 실제 사용 경험이 풍부할 수 있지만 배터리 공학 전문가는 아닐 수 있다.

탐지할 신호

• 직접 사용·구매·방문·설치·운영·비교했다는 표현
• 사용 기간, 시험 횟수, 표본 수, 환경과 장비
• 수행 단계, 실패 과정, 제약 조건 및 예외
• 직접 촬영한 이미지, 로그, 원자료, 재현 절차
• 측정 전후 결과와 측정 방법

‘직접 써봤다’라는 한 문장만으로 높은 점수를 주면 조작이 쉽다. 구체적인 숫자도 그 자체로 사실을 증명하지 않는다. 측정 방법, 기간, 원자료, 문맥이 서로 일치할 때 더 강한 증거로 취급해야 한다.

경험 점수는 다음처럼 계층화할 수 있다.

Expertise: 확인 가능한 전문성 평가

Expertise는 해당 주제를 정확하게 다룰 지식과 역량이 있는지를 본다. 이름 옆에 ‘전문가’라고 표시한 것만으로 충분하지 않다.

분석 후보는 다음과 같다.

• 관련 직책, 소속, 업무 분야 및 경력 기간
• 학위, 공인 자격, 면허와 발급 기관
• 관련 연구, 논문, 저서, 강의, 프로젝트
• 주제와 연결되는 실제 근무 경력
• 전문적 설명의 정확성, 범위, 한계 및 출처
• 전문가 검토자와 검토 일자

작성자 값이 admin, administrator, 관리자, 운영자, 운영팀, editor와 같은 역할명이라면 실제 인물로 확정하지 않는다. Person 구조화 데이터가 있더라도 화면에 표시된 작성자 정보와 일치하는지 확인한다.

전문성은 주제 적합성을 반영해야 한다. 변호사 자격은 법률 콘텐츠에 강한 신호가 될 수 있지만 모든 의료·기술 주제의 전문성을 자동으로 증명하지는 않는다. 자격 검증이 필요한 분야에서는 발급 기관 또는 공식 조회 자료를 연결할 수 있을 때 검증 수준을 높인다.

Authoritativeness: 외부 인정과 엔티티 일치

Authoritativeness는 특정 주제에서 사람·조직·사이트가 외부로부터 어느 정도 인정받는지를 평가한다. 단순한 언급량보다 출처 품질, 주제 관련성, 독립성, 다양성이 중요하다.

권위성 분석기는 다음 절차를 따를 수 있다.

1. 조직명, 작성자명, 도메인, 브랜드의 표준 엔티티를 만든다.
2. 이전 이름, 영문명, 약칭처럼 확인된 별칭을 연결한다.
3. 외부 문서에서 동일 엔티티인지 판별한다.
4. 출처의 독립성·품질·주제 관련성·최신성을 평가한다.
5. 보도자료 재배포와 동일 문서 복제를 묶는다.
6. 인용·언급이 긍정적 인정인지 단순 나열 또는 비판인지 구분한다.

한국어 웹을 분석하면서 Wikipedia, Wikidata, Reddit과 영어권 언론만 사용하면 국내 기관과 기업의 권위가 과소평가될 수 있다. 평가 시장에 따라 정부·공공기관, 공공데이터, 학술 데이터베이스, 전문 협회, 주요 언론 및 산업 전문 매체를 소스 레지스트리에 포함해야 한다. 반대로 특정 국가의 포털 노출만으로 세계적 권위를 단정해서도 안 된다.

소스 레지스트리에는 관할 지역, 발행 주체, 주제 범위, 독립성, 원출처 여부, 갱신 주기와 접근 조건을 기록하는 것이 좋다. 국가별 소스를 추가하더라도 점수 규칙과 선정 기준은 공개돼야 한다.

Trustworthiness: 가장 넓고 중요한 안전 축

Trustworthiness는 나머지 세 요소를 지탱한다. 직접 경험과 자격이 있더라도 허위 주장, 이해충돌 은폐, 출처 조작이 확인되면 전체 평가에 상한을 적용할 수 있다.

신뢰성 모듈에서 확인할 항목은 다음과 같다.

발행 주체와 책임성

• 운영 조직과 작성자가 명확히 표시되는가
• 연락 방법과 고객 지원 정보가 실제 페이지에 존재하는가
• 편집·검수·정정 정책을 확인할 수 있는가
• 광고, 협찬, 제휴, 이해충돌을 구분하는가

주장과 근거

• 핵심 사실에 원출처 또는 적절한 근거가 연결되는가
• 인용문과 통계가 원문 취지에 맞는가
• 발행일·수정일과 실제 콘텐츠 변경이 일치하는가
• 사실, 의견, 광고성 주장이 명확히 구분되는가
• 불확실성, 적용 범위, 예외와 한계를 밝히는가

거래와 안전

• 개인정보처리방침과 이용 조건이 서비스 성격에 맞게 제공되는가
• 결제·환불·배송 조건이 필요한 사이트에서 명확한가
• HTTPS, 악성 리디렉션, 깨진 인증서 같은 기술 위험이 없는가
• 건강·금융·법률 정보에서 위험한 단정이나 보장 표현을 사용하지 않는가

HTTPS나 개인정보처리방침이 있다는 사실만으로 콘텐츠가 정확해지는 것은 아니다. 이는 기본 안전 신호이며, 주장 수준의 신뢰성은 별도로 검증해야 한다.

구조화 데이터와 엔티티 검증

Person과 Organization 구조화 데이터는 이름, 소속, 직책, 공식 URL, 외부 프로필 관계를 기계가 이해하기 쉽게 제공한다. Article의 author, publisher, datePublished, dateModified도 문서의 출처 구조를 표현하는 데 유용하다.

그러나 Schema 마크업은 다음 원칙으로 평가해야 한다.

• 구조화 데이터가 화면에 보이는 콘텐츠와 일치하는지 확인한다.
• 존재한다는 이유만으로 자격·수상·평판을 사실로 확정하지 않는다.
• Person, Organization, Article 사이의 식별자와 관계가 일관적인지 본다.
• sameAs 대상이 실제 공식 프로필인지 확인한다.
• 문법 오류와 필수·권장 속성 누락을 분리한다.
• 과도하거나 관련 없는 Schema 유형 사용을 가점으로 보지 않는다.

구조화 데이터는 이해와 추출을 돕는 표현 계층이다. 높은 검색 순위나 생성형 AI 인용을 보장하지 않는다.

재현 가능한 점수 공식 설계

각 신호를 단순히 ‘있음·없음’으로만 처리하면 품질 차이를 놓친다. 다음과 같이 값을 분리하면 근거를 추적하기 쉽다.

• presence: 신호 존재 여부 또는 충족 정도
• verification: 독립적으로 검증된 정도
• relevance: 평가 주제와의 관련성
• source_quality: 근거 출처의 품질과 독립성
• freshness: 최신성이 필요한 신호의 유효성
• weight: 버전으로 관리하는 신호 중요도

예시 공식은 다음과 같다.

신호 기여도 = weight × presence × verification × relevance × source_quality × freshness
차원 점수 = 100 × 기여도 합계 ÷ 적용 가능한 weight 합계

이 공식은 설계 예시이지 공식 E-E-A-T 산식이 아니다. 각 계수는 0에서 1 사이로 정규화할 수 있다. 논리적으로 적용되지 않는 항목만 N/A로 제외하고, 필요한 증거를 찾지 못한 상태는 0점과 구분해 missing으로 저장한다.

점수와 별도로 신뢰도 표시

78점이라는 결과도 필수 페이지 절반을 수집하지 못했다면 믿기 어렵다. 따라서 평가 신뢰도 또는 증거 커버리지를 별도로 계산해야 한다.

평가 신뢰도 = 수집 커버리지 × 엔티티 일치도 × 검증 가능한 증거 비율

결과 화면에는 최소한 다음을 함께 표시한다.

• 차원별 점수와 종합점수
• 평가 신뢰도
• 확인됨·미확인·불일치·적용 제외 상태
• 근거 URL과 원문 일부
• 수집 시각과 스냅샷 해시
• 규칙·가중치·소스 레지스트리 버전

GEO 종합점수와 E-E-A-T를 분리하기

E-E-A-T가 높다고 반드시 AI 답변에 인용되는 것은 아니다. 답변 시스템은 질문 적합성, 정보의 추출 용이성, 최신성, 크롤링 가능성, 문서 형식 등도 고려할 수 있으며 구체적인 선택 방식은 서비스마다 다르다.

GEO 도구는 다음 모듈을 분리하는 편이 낫다.

예를 들어 AI 인용 준비도 30%, 브랜드 권위 20%, 콘텐츠 E-E-A-T 20%, 기술 접근성 20%, Schema 10%처럼 구성할 수 있다. 이 비율은 어디까지나 제품 정책의 예시다. 실제 가중치는 주제별 검증 데이터로 보정하고 버전을 표시해야 한다.

AI 인용 준비도에서는 짧은 문장만 무조건 선호해서는 안 된다. 핵심 주장이 독립적으로 이해되고, 근거와 조건이 가까이 있으며, 표·목록·제목 구조가 의미를 보존하는지를 평가한다. 검색엔진이나 AI를 속이기 위한 숨김 텍스트, 반복 문구, 근거 없는 대량 페이지는 감점 또는 위험 신호로 처리한다.

모듈 간 오류 전파를 막는 구조

각 분석기가 다른 분석기의 결론을 그대로 입력받으면 초기 오류가 확대될 수 있다. 공유해야 할 것은 결론보다 원본 스냅샷과 정규화된 증거다.

Snapshot Store
 ├─ Content / Claim Analyzer
 ├─ Author / Expertise Analyzer
 ├─ Entity / Authority Analyzer
 ├─ Trust Analyzer
 ├─ Technical Analyzer
 └─ Schema Analyzer
          ↓
 Evidence Store → Deterministic Scorer → Explanation LLM

모든 판정 레코드는 claim_id, evidence_id, 원문 위치, 판정 규칙, 모듈 버전을 포함하는 것이 좋다. LLM에는 계산된 JSON과 허용된 근거 문장만 전달하고, 새로운 자격이나 외부 평판을 보충해서 쓰지 말라는 제약을 둔다.

흔히 놓치는 문제: 불확실성과 적대적 조작

많은 GEO 분석은 신호를 찾는 데 집중하지만, 사이트가 분석기를 속이려는 상황은 충분히 다루지 않는다. 이 문제는 별도의 품질·보안 계층으로 운영해야 한다.

• 보이지 않는 영역에 경력과 키워드를 반복 삽입할 수 있다.
• 가짜 작성자와 Person 구조화 데이터를 생성할 수 있다.
• 동일 보도자료를 여러 도메인에 배포해 외부 언급량을 부풀릴 수 있다.
• 존재하지 않는 연구, 자격, 수치를 인용할 수 있다.
• 수정일만 갱신해 오래된 글을 최신 콘텐츠처럼 표시할 수 있다.
• 동명이인이나 유사 브랜드의 권위를 잘못 연결하도록 유도할 수 있다.

대응 방법으로는 화면 표시 내용과 마크업 비교, 원출처 군집화, 자격 발급처 검증, 콘텐츠 해시 기반 변경 감지, 엔티티 속성 교차 확인, 비정상 링크 패턴 탐지가 있다. 심각한 불일치가 발견되면 단순 감점보다 전체 점수 상한이나 수동 검토 상태를 적용하는 편이 안전하다.

평가 모델을 검증하는 방법

점수 공식이 결정론적이어도 평가 타당성이 자동으로 생기지는 않는다. 다음 시험이 필요하다.

1. 반복성 시험: 같은 스냅샷과 버전에서 비트 단위로 같은 결과가 나오는지 확인한다.
2. 전문가 기준 세트: 분야 전문가가 독립적으로 표시한 증거와 시스템 결과를 비교한다.
3. 평가자 일치도: 사람 평가자 사이에서도 합의가 어려운 항목을 찾아 규칙을 수정한다.
4. 교란 시험: 작성자 이름, 날짜, Schema 또는 근거 링크를 제거했을 때 예상 방향으로 변하는지 본다.
5. 조작 내성 시험: 숨김 문구, 가짜 프로필, 중복 보도자료가 점수를 과도하게 높이지 않는지 확인한다.
6. 지역 편향 시험: 언어·국가별로 동등한 품질의 엔티티가 체계적으로 불리하지 않은지 측정한다.
7. 결과 보정: 실제 인용 관찰 데이터를 사용할 경우 질문, 시점, 모델, 위치를 함께 기록한다.

생성형 AI의 인용 결과는 질문 표현과 서비스 업데이트에 따라 달라질 수 있다. 따라서 실제 인용률을 절대적 정답으로 사용하기보다 시점이 명시된 외부 검증 지표로 다루는 것이 적절하다.

운영 결과에 포함할 데이터 명세

사람과 다른 시스템이 결과를 재검증할 수 있도록 다음 구조를 제공할 수 있다.

{
  "snapshot_id": "sha256:...",
  "collected_at": "ISO-8601 timestamp",
  "scoring_version": "eeat-1.3.0",
  "scope": "document",
  "topic_class": "software-review",
  "scores": {
    "experience": 72,
    "expertise": 61,
    "authoritativeness": 54,
    "trustworthiness": 80
  },
  "confidence": 0.74,
  "evidence": [
    {
      "dimension": "experience",
      "status": "verified",
      "source_url": "https://example.invalid/page",
      "rule_id": "EXP-METHOD-02"
    }
  ],
  "missing": ["independent_author_profile"]
}

위 URL은 데이터 구조를 보여주기 위한 유효하지 않은 예시 문자열이다. 실제 결과에서는 수집한 근거 URL과 원문 위치를 넣어야 한다. 원문 전체를 재배포할 권리가 없다면 필요한 범위의 짧은 증거와 해시, 위치 정보만 저장한다.

구현 체크리스트

• 평가 단위를 문서·작성자·조직·도메인으로 구분한다.
• 같은 시점의 스냅샷을 모든 분석기에 제공한다.
• 자기 주장과 독립적인 외부 검증을 분리한다.
• 경험과 전문성을 별도 차원으로 계산한다.
• 국가·언어별 Authority 소스 레지스트리를 관리한다.
• 구조화 데이터와 화면 표시 내용의 일치를 검사한다.
• 결측, 불일치, 적용 제외를 서로 다른 상태로 저장한다.
• 점수와 평가 신뢰도를 함께 공개한다.
• 가중치와 규칙 변경 시 버전을 올린다.
• LLM 설명에 근거 밖의 사실을 추가하지 못하도록 제한한다.
• 조작 탐지와 수동 검토 경로를 마련한다.
• 실제 AI 인용 결과를 관찰할 때 모델·질문·시점을 기록한다.

핵심은 E-E-A-T를 하나의 모호한 인상 점수로 압축하지 않는 것이다. 검증 가능한 증거, 적용한 규칙, 불확실성, 출처 계보를 함께 제공해야 GEO 분석 결과가 운영 의사결정과 장기 비교에 쓸 수 있는 데이터가 된다.