GEO 진단, 스크린샷 대신 측정 가능한 체계가 필요한 이유

한줄 요약

GEO는 우연한 인용 캡처가 아니라, 재현 가능한 측정 구조로 관리해야 한다.

AI 검색 최적화(GEO, Generative Engine Optimization)란 ChatGPT·Gemini 같은 생성형 AI가 답변을 구성할 때 특정 브랜드나 콘텐츠를 인용하도록 유도하는 전략이다. 사용자의 정보 탐색 경로가 검색엔진에서 AI로 빠르게 이동하면서, 클라이언트들이 "우리 브랜드가 AI 답변에 나오게 하려면 어떻게 해야 하냐"고 묻는 빈도가 눈에 띄게 늘었다. 문제는 대부분의 시도가 측정 체계 없이 진행된다는 점이다.

AI 답변 캡처가 지표가 될 수 없는 이유

많은 팀이 GEO 대응을 시작할 때 가장 먼저 하는 일이 있다. 매일 AI에 특정 질문을 던지고, 브랜드가 언급되면 화면을 캡처해 보고서에 첨부하는 것이다. 한 번 인용됐다가 다음 날 사라지는 일이 반복되는데도 이 방식을 유지한다.

이게 지표로 기능하지 못하는 이유는 구조적이다. 생성형 AI는 동일한 질문에도 매번 다른 확률 경로로 답변을 생성한다. 어제의 인용은 오늘의 인용을 보장하지 않는다. 재현 불가능한 결과를 성과로 제시하면, 그 다음 개선 방향도 근거 없는 추정에 의존하게 된다.

개발 관점에서 이 문제는 더 명확하게 보인다. 동일한 입력에 동일한 출력이 나오지 않는 시스템은 테스트할 수 없고, 테스트할 수 없는 시스템은 개선할 수 없다. GEO도 같은 원칙이 적용된다.

측정 체계를 설계할 때 먼저 정해야 할 것

GEO 진단 도구를 직접 구축하거나 외주 개발로 의뢰할 때, 설계 전에 반드시 결정해야 할 원칙이 하나 있다. 수치 계산은 코드 로직이 담당하고, AI는 그 결과를 사람이 읽을 수 있는 언어로 변환하는 역할만 맡긴다는 것이다.

AI에게 "이 사이트의 GEO 점수를 평가해줘"라고 던지면 그럴듯한 분석이 나온다. 그런데 같은 사이트를 다음 날 다시 넣으면 점수가 달라진다. 콘텐츠는 그대로인데 평가만 바뀌는 상황이다. 이건 평가가 아니라 AI의 즉흥적 해석이다.

올바른 구조는 다음과 같다.

• 수집: URL 기반 크롤링과 브랜드명 기반 외부 데이터 수집을 동시에 수행하고, 모든 분석 모듈이 동일한 시점의 스냅샷을 참조한다.
• 분석: 정규식·파싱 로직·규칙 기반 코드가 수치를 확정한다. AI는 확정된 수치에 대한 설명문만 생성한다.
• 종합: 영역별 점수에 가중치를 적용해 최종 지표를 만들고, 개선 우선순위를 도출한다.

이 구조를 지키면 동일한 페이지에는 항상 동일한 진단 결과가 나온다. 개선 전후 비교가 가능해지고, 비로소 관리할 수 있는 지표가 생긴다.

E-E-A-T를 코드로 옮길 때 반복되는 실수

GEO 진단에서 콘텐츠 품질을 평가하는 핵심 기준은 E-E-A-T다. 경험(Experience), 전문성(Expertise), 권위성(Authoritativeness), 신뢰성(Trustworthiness)의 약자로, AI가 어떤 페이지를 답변 재료로 쓸지 판단하는 데 실질적으로 영향을 미치는 요소다.

이걸 코드로 구현하는 과정에서 빠지기 쉬운 함정이 몇 가지 있다.

첫째, 경험과 전문성을 같은 로직으로 처리하는 실수다. 경험은 직접 해봤다는 증거, 즉 구체적 수치, 1인칭 서술, 실사용 사례로 판단한다. 전문성은 자격과 이력으로 판단한다. 이 둘을 같은 기준으로 뭉개면, 사용자 후기가 수백 개 쌓인 커머스 페이지가 저자 프로필이 없다는 이유만으로 낮은 점수를 받는 오탐이 발생한다.

둘째, 저자 표기 로직에서 CMS 기본값을 걸러내지 않는 실수다. 워드프레스 기반 사이트 상당수가 "작성자: 관리자" 또는 "author: admin"을 자동으로 출력한다. 저자 표기가 있다는 사실만 체크하면 이런 사이트가 전부 통과된다. 실제로 의미 있는 저자 정보가 있는지를 판별하는 필터가 별도로 필요하다.

셋째, 신뢰성 관련 정보를 정제된 본문 텍스트에서 찾으려는 실수다. 개인정보처리방침, 이용약관, 연락처 같은 신뢰성 신호는 대부분 푸터 영역에 위치한다. HTML 파서가 푸터를 먼저 제거한 뒤 본문을 분석하면, 이 정보들이 통째로 누락된다. 신뢰성 항목은 정제 전 원본 HTML을 직접 참조하도록 파이프라인을 분리해야 한다.

---

이런 시행착오들은 결국 하나의 교훈으로 수렴한다. 진단 오류는 판정 규칙이 틀려서 생기는 경우보다, 어떤 데이터를 언제 어떻게 가공해서 분석 모듈에 넘기는지를 놓쳤을 때 더 자주 발생한다.

외주 개발로 GEO 진단 시스템을 만들 때 체크해야 할 것

GEO 진단 도구를 외부 개발사에 의뢰할 때 스펙으로 챙겨야 할 요소는 다음과 같다.

수집 일관성 보장 여부. 모든 분석 모듈이 동일 시점의 단일 데이터 스냅샷을 참조하는지 확인한다. 모듈마다 개별 크롤링을 허용하면 시차로 인한 데이터 불일치가 발생한다.

에이전트 간 의존성 설계. 특정 분석 모듈이 다른 모듈의 처리 결과를 참조하는 구조는 위험하다. 한 모듈에서 오류가 발생하면 연쇄적으로 다른 모듈의 결과까지 오염된다. 각 에이전트는 원본 데이터를 독립적으로 참조하도록 설계해야 한다.

로컬라이제이션 적용 여부. 글로벌 기준의 권위 도메인 목록만 참조하면 국내 공공기관, 정부 통계, 국내 주요 언론사를 인용한 콘텐츠가 '권위 없음'으로 판정된다. 한국어 기반 사이트를 진단할 때는 국내 기준이 반영된 판단 로직이 병행돼야 한다.

점수 산출의 투명성. 최종 점수가 어떤 항목에서 어떤 근거로 계산됐는지 역추적 가능해야 한다. 블랙박스 점수는 개선 방향을 도출할 수 없다.