GEO 분석 툴을 만들다: E-E-A-T 분석하는 법

언제부턴가 궁금한 게 생기면 검색창 대신 ChatGPT나 Perplexity 같은 AI부터 찾는게 일상이 됐습니다. 사용자의 검색 습관이 검색엔진에서 AI로 옮겨가면서, 기업의 시선도 자연스럽게 GEO(Generative Engine Optimization)로 이동하고 있습니다.

그런데 기업 담당자들과 이야기를 나눠보면 대부분 무엇부터 손대야 할지 잘 모르겠다고 합니다. 왜 이런 현상이 생기는지 이유는 명확합니다. 지금까지 어떤 빅테크 기업도 AI가 답변을 생성하는 방식이나, 인용 가중치 기준을 공개한 적이 없기 때문입니다. 완전한 블랙박스죠. 그러니 개선은 커녕 우리가 지금 어느 수준인지조차 알기 어려웠던 겁니다.

그래서 결국 GEO를 확인해 보기 위해 매일 아침 AI에 주요 질문을 하고, 답변 화면을 캡처해 보고서에 붙이는 일을 반복합니다. 어쩌다 우리 브랜드 링크가 한 번 인용되면 개선되고 있다고 보고하는데, 다음 날 같은 질문을 하면 또 답변에서 사라져 버립니다. 이렇게 우연히 인용된 스크린샷 한 장으로 성과를 주장하는 건 위험합니다.

“측정할 수 없으면 관리할 수 없고, 개선할 수도 없다.” — 피터 드러커(Peter Drucker)

결국 제대로 측정해 주는 도구를 찾지 못해서, 직접 만들어보기로 했습니다. 이번 글에서는 그 여정을 다뤄보겠습니다.

• GEO 분석 서비스

참고) Gemini API 키(BYOK)를 등록해 이용할 수 있습니다.
키 정보는 사용자 브라우저 로컬 스토리지에 저장됩니다.

미리 요점만 콕 집어보기

• GEO(Generative Engine Optimization) 대응의 출발점은 AI의 답변 스크린샷 수집이 아니라 재현 가능한 진단 체계를 만드는 것입니다.
• 경험(Experience)·전문성(Expertise)·권위성(Authoritativeness)·신뢰성(Trustworthiness)을 뜻하는 E-E-A-T는 추상적인 원칙처럼 보이지만 정규식과 계산 로직으로 나누어 진단할 수 있습니다.
• 커머스는 구매 후기와 실사용 경험(Experience)을, 미디어는 작성자의 전문성(Expertise)을 중심에 두는 것처럼 업종별로 평가 관점을 다각화해야 비로소 의미 있는 분석이 가능해집니다.

측정할 수 없어서 관리할 수 없었던 GEO의 시작

기존 검색엔진 최적화(SEO, Search Engine Optimization)에는 순위 추적 도구가 있었습니다. 그런데 GEO에는 그에 해당하는 게 없습니다. 순위가 중요한 게 아니라 생성된 답변 안에 인용되느냐가 핵심이기 때문입니다. 측정할 마땅한 툴이 없다 보니 측정 가능한 지표를 정의하고 기준점부터 세워야 했습니다.

첫 버전은 말 그대로 단순했습니다. 웹페이지를 긁어와 AI에 통째로 넘기고 “GEO 평가해줘”라고 시켰습니다. 결과는 그럴듯했습니다. 근거도 잘 대고, 개선 제안도 날카로웠습니다.

그런데 다음 날 같은 사이트를 다시 평가해 달라고 했더니 점수가 황당할 정도로 달라졌습니다. 사이트 소스는 한 줄도 바꾸지 않았는데 말이죠. 어느 날은 “저자 정보가 없어 전문성이 낮다”며 낮게 평가하더니, 다음 날은 똑같은 페이지를 보고 “회사 소개가 충실해 전문성이 높다”고 좋게 평가했습니다.

사실 구조적인 문제가 있었던 겁니다. AI 언어 모델은 본질적으로 확률에 따라 다음 토큰을 고릅니다. temperature를 0으로 낮춰도 평가처럼 긴 추론이 필요한 작업에서는 미세한 확률 차이가 최종 평가 점수와 의견을 크게 흔듭니다.

여기에 환각(Hallucination)까지 더해지면, 아무것도 안 바꿨는데 점수만 혼자 좋아졌다 나빠졌다를 반복하는 웃긴 상황이 연출됩니다. 결국 AI의 그날 기분에 따라 달라지는 수치였던 셈입니다. 이런 건 지표가 될 수 없습니다.

그래서 원칙 하나를 세우고 다시 만들었습니다. 진단 및 수치 산출은 100% 코드가 로직 기반으로 수행한다. AI는 확정된 수집 데이터를 바탕으로 설명 서술만 맡는다.

이렇게 하면 동일한 입력에는 언제나 동일한 진단 결과가 나옵니다. 물론 “이 콘텐츠가 전문성이 있는가?” 같은 추상적 판단에는 여전히 AI를 씁니다. 다만 그 판단이 자의적으로 점수를 부여하도록 허용하지 않을 뿐입니다.

그리고 GEO 분석을 크게 두 가지 영역으로 나눴습니다. AI 봇이 사이트 정보를 손실 없이 읽고 활용할 수 있게 만드는 기술 인프라 영역, 그리고 브랜드 신뢰성과 메시지 구조를 다루는 콘텐츠 영역입니다.

전체 구조: 수집 → 병렬 분석 → 종합

먼저 전체 파이프라인의 구조입니다. 수집(Collection) → 병렬 분석(Analysis) → 종합(Synthesis)으로 이어지는 흐름으로 5개의 에이전트가 병렬로 동작합니다.

여기서는 파이프라인 단계 자체보다, 어떤 문제를 해결하려고 이렇게 만들었는지가 더 중요합니다.

1단계, 모든 분석은 같은 시점의 원본을 봐야 한다

진단에 필요한 입력 값은 단 2개입니다. 사이트 주소(URL)와 브랜드명이죠. 이 글에서 사이트는 그 주소 아래 딸린 페이지들을, 브랜드는 그 사이트가 내세우는 이름을 가리키는데, 회사명일 수도 서비스명일 수도 특정 제품명일 수도 있고 사람들이 검색창에 그 이름으로 찾는다면 무엇이든 브랜드가 될 수 있습니다. 표현상 브랜드로 통칭해서 부르도록 하겠습니다.

사이트 URL 기반으로 직접 크롤링해야 하고 브랜드는 검색을 통해 확인해야 합니다. 분석을 위해서 소스가 되는 데이터 수집 과정은 엄격한 통일성이 필요합니다. 만약 분석 모듈이 제각각 데이터를 수집하게 두면, 시차로 인해 모듈마다 서로 다른 버전의 HTML을 참조하게 되고, 결국 같은 사이트를 두고도 평가 근거가 달라지는 오류가 발생합니다.

즉, 진단의 일관성을 보장하기 위해서는 모든 분석 과정이 반드시 동일 시점의 동일한 소스를 바라봐야 합니다. 그래서 데이터 수집은 프로세스 맨 처음 수행해 단일 스냅샷을 생성해 두고, 모든 분석 에이전트가 이 스냅샷을 기반으로 평가를 진행하도록 설계했습니다. 구체적인 수집 범위는 다음과 같이 두 가지 항목으로 나뉩니다.

온사이트와 오프사이트를 굳이 나눠 수집하는 이유는 온사이트 내용은 브랜드 자신의 주장이고 오프사이트 기록은 그 주장에 대한 외부 검증이라 AI가 이 두 영역의 정보를 복합적으로 판단하기 때문입니다.

2단계, 영역별 분석하는 전문 에이전트를 구분한다

“GEO 분석 해주세요?”라고 단순하게 물으면 날카로운 분석 의견 대신 그럴듯하긴 한데 장황하고 막상 실무에 쓰려면 모호한 말들만 돌아옵니다. 개선할 대상이 특정되지 않기 때문이죠. 그래서 분석 영역을 나누고 특화된 각 에이전트들을 만들어 활용했습니다.

이 평가 항목들은 일반적으로 GEO 분석 카테고리로 많이 알려진 요소들입니다. 이 컨셉을 가지고 어떻게 만들것인가는 구현의 영역입니다. 저는 각 영역은 서로의 결과를 참조하지 않고, 동시에 돌아가며 점수는 로직으로 계산합니다. 그리고 LLM은 이미 확정된 근거 목록을 받아, 사람이 이해할 수 있게 분석과 개선 가이드를 만듭니다. 그래서 LLM의 문장이 어제와 조금 달라져도 점수는 크게 달라지지 않기 때문에 일관된 평가 지표로 활용할 수 있습니다.

추가로, AI에 브랜드에 대한 연관 질문을 하고, 그 답변 중에 실제 브랜드에 대한 인용이 있는지도 실시간으로 같이 분석했습니다.

3단계, 점수 합산 다음에 나오는 우선순위

다섯 영역의 진단 결과를 합쳐 최종 GEO 점수(0~100점)를 만듭니다. 이때 영역마다 실제 AI 답변 인용에 미치는 영향력이 제각각이라, 합칠 때 반영 비율(가중치)을 따로 설정했습니다.

다만 실무에서 더 자주 쓰는 쪽은 총점이 아니라 영역 간 교차 분석에 대한 내용일 겁니다. 예를 들어 콘텐츠 수준이 아무리 좋아도 기술적 인프라 점수가 극단적으로 낮다면, 온사이트 영역을 고쳐봤자 AI 봇이 그 내용을 수집하지 못합니다. 이런 선후 관계를 따져, 어디부터 손대야 인용률이 가장 빨리 오르는가?의 개선 우선순위를 만들어 리포트에 제공합니다.

E-E-A-T 분석: 점수가 아닌 ‘관점과 시행착오’의 기록

다양한 분석 영역중에 저는 콘텐츠 분석 에이전트에 대해서 좀 더 설명을 할까 합니다. 콘텐트 영역 분석에 중요한 항목은 ‘E-E-A-T’입니다.

이 E-E-A-T는 구글 검색 품질 평가 가이드라인의 개념으로,

• 경험(Experience)
• 전문성(Expertise)
• 권위성(Authoritativeness)
• 신뢰성(Trustworthiness)을 뜻합니다.

AI 검색 엔진이 어떤 페이지를 답변 재료로 쓸지 판단할 때 참조하는 핵심 기준이기도 합니다.

문제는 이게 추상적인 개념이라는 점입니다. “전문성이 있다”는 명제를 코드는 직접 판정할 수 없습니다. 코드가 읽어낼 수 있는 건 저자 이름이 실명으로 표기돼 있다, JSON-LD에 Person 타입이 있다 같이 겉으로 드러난 정보들뿐입니다.

따라서 핵심은 어떤 관점으로 사이트를 바라보고, 어떤 요소를 통해 E-E-A-T를 입증할 것인가에 있습니다. 이 시스템을 구축하며 정의한 핵심 탐지 요소는 아래와 같습니다.

이 관점들을 실제 코드로 옮기는 과정에서 수많은 오탐과 시행착오를 만났습니다. 그중 대표적인 6가지 이야기를 소개합니다.

첫 번째 시행착오: Experience(경험)와 Expertise(전문성)는 다르다

처음 만든 버전은 Experience(경험)와 Expertise(전문성)를 따로 구분하지 않고, 여러 평가 요소들을 한데 뭉뚱그려 합치는 단순한 방식이었습니다. 예를 들어, 저자 표기가 있으면 점수 추가, 통계가 있으면 점수 추가하는 식이었죠.

이 구조가 무너진 건 커머스 사이트를 진단하면서입니다. 상품 상세 페이지에 구매 후기가 수백 개 쌓여 있고 실사용 사진도 붙어 있는 쇼핑몰이, 저자 프로필 표기가 없다는 이유로 부당하게 낮은 평가를 받았습니다. AI 입장에서 고객들의 구체적 후기 데이터는 훌륭한 인용 재료인데 말이죠.

E-E-A-T 원문을 다시 읽고 나서야 알았습니다. Experience(경험)와 Expertise(전문성)는 결이 전혀 다른 평가 기준입니다. Experience(경험)는 자격을 요구하지 않습니다. 직접 해봤다는 증거, 원본 데이터, 구체적 사용 사례면 충분합니다. 반면 Expertise(전문성)는 자격과 이력을 봅니다. 이 둘을 한 덩어리로 뭉개면, 경험은 넘치지만 자격은 없는 사용자 제작 콘텐츠(UGC)나 커머스 상세 페이지가 구조적으로 부당한 저점을 받게 됩니다.

그래서 자격 키워드를 찾는 로직은 Expertise(전문성) 항목으로 제한하고, Experience(경험) 항목은 완전히 다른 패턴으로 데이터를 체크하도록 했습니다. 예를 들어, 아래 같은 형태로 말이죠.

// Experience(경험) — 자격을 확인하지 않는다. 원본 데이터·1인칭 서술·구체적 사례로 판단.
const CASE_STUDY_PATTERN = /\d+%|\d+개월\s*만에|\d+주\s*만에|\d+배\s*(증가|향상|성장|절감)/
const EXPERIENCE_NARRATIVE_PATTERN =
  /직접\s*(경험|사용|체험)|저희가\s*실제로|다녀와서|사용해\s*보니|실제로\s*써\s*본|다녀온\s*후기|we\s+tested|in\s+our\s*experience|hands-on/i

// Expertise(전문성) — 자격과 이력은 여기서만 본다.
const CREDENTIAL_KEYWORD_PATTERN = /대표\s|박사|자격증|경력\s*\d+\s*년|CEO|founder|certified|Ph\.?D|공인/i

이 코드는 ‘경험’과 ‘전문성’을 판단하는 기준을 분리하여, 경험 기반 콘텐츠가 전문성 부족으로 부당하게 감점되는 문제를 해결합니다.

“3개월 만에 40% 절감” 같은 표현은 자격 증명 없이도 경험을 증명합니다. “사용해 보니”, “다녀온 후기” 같은 1인칭 서술도 마찬가지입니다. 반대로 “박사”, “경력 10년”은 경험이 아니라 자격의 증거입니다. 이 구분을 코드로 명확히 구분 할 수 있어야, 평가에서도 적절하게 활용할 수 있었습니다.

또한, 외부 신뢰도를 증명하는 권위 도메인(Authoritative Domains)을 판정할 때도 한국어 콘텐츠만의 고유한 맥락을 반영해야 했습니다.

글로벌 기준의 GEO 도구들은 주로 위키백과(wikipedia.org), 네이처(nature.com), 뉴욕타임스(nytimes.com) 같은 영미권 매체나 국제기구 사이트 위주로 권위성을 체크합니다. 그러다 보니 국가통계포털(kosis.kr)이나 정부 부처 공공기관 보고서, 국내 주요 언론사를 인용한 양질의 한국어 콘텐츠가 ‘권위 있는 출처 인용 없음’으로 무참히 필터링되는 문제가 있었습니다.

이를 해결하기 위해 진단 대상이 한국 브랜드이거나 한국어 기반의 사이트일 경우에는, 국내 공공 데이터 포털, 국가 통계 사이트, 국내 주요 언론사 등 한국 환경에 최적화된 로컬 권위 매체 목록을 추가로 병합하여 교차 검증하는 동적 판단 로직을 적용했습니다. 글로벌 통용 기준만 고집하지 않고 타깃 시장의 맥락에 맞게 검증 대상을 확장한 것입니다.

두 번째 시행착오: “작성자: 관리자”라는 오탐

저자 식별 로직을 처음엔 HTML에 author, byline, 작성자, 필자 같은 문자열이 포함되어 있으면 저자가 명시된 것으로 간주했습니다.

그랬더니 국내 사이트 상당수가 이 항목에서 무더기로 통과했습니다. 워드프레스(WordPress)나 국내 콘텐츠 관리 시스템(CMS)으로 만든 블로그들이 기본값으로 ‘작성자: 관리자’를 출력하고 있었기 때문입니다. ‘작성자: 운영팀’, ‘작성자: admin’도 흔했습니다.

이건 저자가 누구인지 밝힌 것이 아니라, 사실상 저자를 밝히지 않은 것과 마찬가지입니다. 실제 값 자체가 없으면 감점 요소로 판단하면 되지만 값이 있는 경우엔 그 값이 의미 있는 정보인지 파악해야 합니다. 아래 예시 한 줄짜리 로직으로 부정확한 정보를 필터링할 수 있었습니다.

const GENERIC_AUTHOR_PATTERN = /^(관리자|운영자|운영팀|admin|administrator|staff|marketing\s*team)$/i
function hasNamedAuthorSignal(rawHtml, searchText) {
  const labelMatch = searchText.match(/(작성자|필자|저자|byline)\s*[:：]?\s*([^\n,·|]{1,20})/i)
  if (!labelMatch) return /author|byline|written by|작성자|필자|기자|저자/i.test(rawHtml)
  return !GENERIC_AUTHOR_PATTERN.test(labelMatch[2].trim())
}

이 코드는 CMS 기본값인 ‘관리자’ 등의 무의미한 저자 표기를 걸러내어, 실제 저자 정보가 없는 페이지를 정확히 식별하기 위한 로직입니다.

세 번째 시행착오: 메인 페이지만 봐서는 Expertise(전문성)를 찾을 수 없다

Expertise(전문성) 항목의 자격 키워드를 메인 페이지(홈페이지) 본문에서만 찾으려 하니 놓치는 경우가 많았습니다. 기업 대표 이력, 팀 구성원 소개, 관련 자격증은 대부분 메인 페이지가 아니라 ‘회사 소개(About)’나 ‘팀 소개’ 페이지에 위치합니다. 메인 페이지에는 브랜드 슬로건과 주요 서비스 안내 버튼만 있는 경우가 태반이기 때문입니다.

그래서 파이프라인 앞단에서 사이트맵(sitemap)을 파싱하여 정보 가치가 높은 서브 페이지를 추가로 추출한 뒤, Expertise(전문성) 진단에 한해 메인 페이지와 서브 페이지 텍스트를 합쳐서 검증하도록 개선했습니다.

다만 이 방식을 모든 진단 항목에 남발해서는 안 됩니다. 단 하나의 페이지에만 정보가 있어도 다른 저자가 작성한 정보도 모두 병합되어 오탐이 발생할 수 있습니다.

따라서 작성자의 Expertise(전문성)를 명확히 인지하게 하려면 콘텐츠 내에 다음과 같은 구체적인 정보를 구조화하여 노출해야 합니다.

• 명확한 저자 프로필: 콘텐츠 상단이나 하단에 작성자 이름과 사진 표시
• 객관적 자격 명시: 저자의 관련 전공, 보유 자격증, 해당 분야 실무 연차 표기
• 증빙 링크 연결: LinkedIn 프로필, 공식 인증 페이지, 학위/자격 검증 링크 연결

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@name": "홍길동",
  "@jobTitle": "소프트웨어 엔지니어",
  "@sameAs": [
    "https://www.linkedin.com/in/your-profile",
    "https://github.com/your-id"
  ]
}

위 예시처럼, sameAs 속성에 공식 SNS나 외부 프로필 링크를 연결하면, 구글 지식 그래프(Knowledge Graph)가 이 글의 저자와 외부의 실제 인물을 동일인으로 인지하는 데 도움을 줍니다.

네 번째 시행착오: 푸터를 지워놓고 푸터를 찾았다

이것은 순전히 개발 파이프라인 처리 순서에서 발생했던 제 버그였습니다.

HTML 파서는 본문 텍스트를 정제할 때 헤더(header), 푸터(footer), 내비게이션(navigation) 영역을 먼저 제거합니다. 본문 분량이나 단락 길이를 계산할 때 상하단 공통 메뉴 텍스트가 섞이면 데이터가 오염되기 때문에 지극히 당연한 정제 과정입니다.

그런데 확인해야 하는 Trustworthiness(신뢰성) 핵심 단서들인 개인정보처리방침, 이용약관, 연락처, 고객센터 등의 정보가 거의 푸터 영역에 몰려 있습니다. 이미 푸터가 제거된 본문 텍스트에서 약관을 찾으니 아무것도 검출되지 않았고, 멀쩡히 약관을 갖춘 사이트들이 신뢰성 항목에서 누락되었습니다.

해결책은 파이프라인의 입력을 바르게 교정하는 것이었습니다. Trustworthiness(신뢰성) 검증 로직은 정제된 본문이 아니라, 정제 전 원본 HTML(rawHtml)을 직접 참조하도록 해서 분석에 필요한 소스 정보를 놓치지 않도록 했습니다.

이 버그가 준 교훈은 명확합니다. 자동화 진단 로직에서 발생하는 수많은 오류는 판정 규칙 자체가 틀려서라기보다, 분석의 소스 데이터가 언제 어떻게 가공되었는지를 놓칠 때 발생한다는 점입니다. LLM에 평가를 몽땅 맡겼다면 이 파이프라인의 오류는 발견조차 되지 못했을 겁니다.

다섯 번째 시행착오: 에이전트 간 분석 결과를 참조하지 않는다

초기에는 시스템 효율을 높이고자 했습니다. 구조화 데이터를 분석하는 에이전트가 이미 JSON-LD를 파싱하고 있었으므로, E-E-A-T 분석 에이전트에서는 그 파싱 결과값을 가져다 써도 되겠다고 판단했습니다.

하지만 이 의존성이 엉뚱한 연쇄 오류를 낳았습니다. 구조화 데이터 에이전트는 스키마 표준 규격에 맞게 엄격한 문법 검증(Validation)을 수행하고 온전한 객체만 결과물로 넘겨줍니다. 그런데 어떤 사이트의 JSON-LD에 사소한 쉼표 누락 같은 문법 오류가 발생하자, 구조화 데이터 에이전트는 이를 유효하지 않음으로 규정하고 빈 데이터(null)를 반환해 버렸습니다.

이 때문에 E-E-A-T 에이전트는 본문에 엄연히 저자(Person) 정보가 기재되어 있었음에도 불구하고, 앞선 에이전트가 넘겨준 null 값만 보고 저자 정보가 없다며 E-E-A-T 점수를 깎아버렸습니다. 구조화 데이터의 문법 규격 오류가 아무 상관 없는 콘텐츠의 저자 신뢰성 평가 실패로 꼬여서 번진 것입니다.

이처럼 개별 에이전트가 다른 에이전트의 처리 결과물에 의존하면, 한 곳의 사소한 에러나 로직 수정이 도미노처럼 다른 에이전트의 분석 결과를 오염시키게 됩니다.

이를 해결하기 위해 E-E-A-T 에이전트가 다른 에이전트의 가공된 결과물 대신, 원본 소스 데이터로부터 직접 스키마 텍스트를 추출해 독립적으로 정보를 분석하도록 구조를 개선했습니다.

비록 파싱 연산이 중복되어 자원은 조금 더 들더라도, 개별 에이전트의 로직 수정이나 특정 페이지의 오류가 시스템 전체로 전파되는 것을 완벽히 방지하여 독립성을 유지할 수 있게 되었습니다.

여섯 번째 시행착오: 업종의 맥락을 생략하면 분석에 왜곡이 발생한다

E-E-A-T를 분석할 때는 업종의 특성을 좀 더 고려해야 했습니다.

예를 들어 전문 기술 블로그나 미디어는 고객 실사용 후기나 1인칭 체험담(Experience)이 거의 없습니다. 이 매체들이 AI 검색 답변으로 인용되는 핵심 가치는 필자의 깊은 전문성(Expertise)과 외부 언론의 권위(Authoritativeness)입니다. 반대로 전자상거래 쇼핑몰은 저자의 학위나 자격증(Expertise)보다는 실제 구매자의 사용 경험 데이터(Experience)가 훨씬 중요한 신뢰 기준입니다.

모든 사이트를 동일한 기준으로 바라보면, 쇼핑몰은 전문성 부족으로, 기술 블로그는 경험 부족으로 억울한 감점을 받게 됩니다. 그래서 사이트의 업종 맥락을 정규식 매칭을 통해 먼저 분류하고, 업종별로 4가지 관점의 가중치를 다르게 할당하도록 개선했습니다.

쇼핑몰과 지역 서비스는 경험(Experience 35%)에 무게를 두고, 미디어/출판은 전문성(Expertise 30%)에 더 가중치를 주는 식입니다.

또한 이 업종 분류 과정에서도 성급한 확정을 피하는 안전장치를 두었습니다. 자사 브랜드 몰을 직접 운영하는 SaaS 기업처럼 두 가지 성격이 비등하게 섞여 있는 경우, 단어 몇 개 차이로 업종이 강제 정의되면 진단 프레임 전체가 요동치기 때문입니다. 분류가 애매할 때는 섣부르게 억지로 분류하지 않고, 균등 가중치를 적용합니다.  

그래서 LLM은 무엇을 하나

여기까지 설명하면 “그렇다면 LLM은 아무 역할도 하지 않는가?”라는 의문이 들 수 있습니다. 당연히 LLM의 역할은 매우 명확하고 강력합니다.

코드로 구성된 로직 엔진이 E-E-A-T 검증 결과와 수집된 정황 근거, 본문 샘플을 깔끔한 데이터 객체로 정리하여 넘겨주면, LLM은 이를 바탕으로 사람이 읽고 즉시 실행할 수 있는 분석 리포트를 작성합니다.

진단 점수는 로직이 계산한 값 그대로 고정되며, LLM 응답값에서 숫자를 역파싱하지 않습니다. 프롬프트 문구로 “점수를 바꾸지 말라”고 부탁하는 것이 아니라, 코드 구조상으로 LLM이 수치 데이터에 접근해 임의적 해석을 할 수 없도록 물리적 격리를 구현한 것입니다.

대신 LLM은 서술 영역에서 압도적인 능력을 발휘합니다. 어떤 부분을 어떻게 고쳐야 하는지 실제 교체 가능한 예시를 작성해 주고, 개발 지식이 없는 마케팅/콘텐츠 담당자도 바로 복사해 적용할 수 있는 직관적인 가이드를 제공합니다.

마치며

GEO(Generative Engine Optimization)는 키워드를 반복 배치하던 기존 SEO의 단순 연장선이 아닙니다. AI 검색 엔진은 단순 키워드 매칭을 넘어서, 파싱 가능한 형태로 정돈된 데이터 인프라와 콘텐츠의 실질적 신뢰도를 판단합니다.

진단 도구를 뜯어고치며 얻은 6가지 핵심 레슨을 요약하면 다음과 같습니다.

AI 빅테크 기업들이 정확한 인용 가중치 공식을 완전히 공개하지 않는 한, 우리가 만든 모든 진단 프레임워크는 현실에 대한 정교한 추정일 뿐입니다.

하지만 그 추정을 AI의 환각에 맡기지 않고 명확한 코드로 구현해 두면, 어디가 틀렸고 어떤 예외 상황에서 오탐이 발생하는지 추적하여 계속해서 로직을 진화시킬 수 있습니다. AI가 그날그날 다르게 뱉어내는 수치로는 엔지니어가 개선할 요소를 파악하기 어렵습니다.

내일 아침 경영진이나 팀원이 “우리 서비스가 AI 검색에 왜 인용되지 않는가”를 물어온다면, AI에 검색어를 입력하고, 화면을 캡처하는 일을 멈추시길 바랍니다. 대신 우리 서비스의 데이터가 AI에 손실 없이 전달되고 있는지, E-E-A-T를 입증할 단서들이 올바른 관점으로 정돈되어 있는지 진단 체계부터 세워보시길 권합니다. 관점이 명확해지는 순간, GEO 대응은 막연한 추측이 아니라 ‘다음 스프린트에 어떤 기술적/콘텐츠적 결함을 고칠 것인가’라는 구체적인 실행 계획으로 바뀔 것입니다.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.