E-E-A-T 점검 도구를 코딩 없이 만들었다 — AI 에이전트로 사이트 감사하기

E-E-A-T 점검이 자동화되지 않았던 이유는 단순하다. 페이지 속도나 코어 웹 바이털과 달리, 구글의 E-E-A-T 가이드는 API 엔드포인트로 노출되지 않는다. 구글이 제공하는 것은 프레임워크와 방법론뿐이고, 그걸 적용하는 것은 사람의 판단이었다.

서치 엔진 랜드에 실린 제임스 앨런(James Allen)의 실험은 그 판단 작업을 AI 코딩 에이전트에 넘겼다. 비정형 정보를 대량으로 읽고 프레임워크를 적용하는 일이야말로 AI가 잘하는 영역이라는 판단에서다.

두 가지 경로 중 하나

AI 코딩 도구로 마케팅 도구를 만드는 방법은 크게 둘로 갈린다.

첫째, AI 플랫폼 안에서 도구를 만들어 여러 세션에 걸쳐 계속 쓰는 방식. 둘째, 그 기술로 독립 애플리케이션을 만들어 별도 호스팅에 배포하는 방식.

앨런이 택한 건 첫 번째다. 배포와 인프라 지식이 필요 없어 마케터가 접근하기 쉽기 때문이다.

구축 과정

준비물

• 클로드 코드를 쓸 수 있는 요금제(프로·맥스·팀·엔터프라이즈) 또는 별도 API 크레딧
• 프로젝트 백업용 깃허브 계정
• 워드 문서 생성을 위한 오피스(대안으로 HTML 앱이나 리브레오피스도 가능)

다른 AI IDE나 데스크톱 에이전트를 써도 흐름은 거의 같다.

크롤링은 내장 페치 대신 헤드리스 브라우저로

URL 목록을 주면 AI는 보통 내장 웹 페치를 쓴다. 문제는 이 방식이 상당수 사이트에서 차단된다는 점이다. 그래서 앨런은 파이썬 헤드리스 브라우저를 띄우도록 지시했고, 에이전트는 크로미엄 엔진을 선택했다.

이 선택에는 부수 효과가 하나 더 있다. 헤드리스 브라우저는 코드를 실행하고 렌더링한 뒤 분석하므로, 원본 HTML과 렌더링된 결과를 모두 확보할 수 있다. 자바스크립트로 생성되는 저자 정보나 신뢰 요소가 있는 사이트에서는 이 차이가 결정적이다. 자바스크립트 링크는 AI 검색에 보이지 않는다와 같은 문제의식이다.

지식 베이스와 채점 기준

에이전트는 구글 품질 문서를 읽어 자체 데이터 구조로 정리하고, E-E-A-T 지식 베이스와 채점 루브릭을 만들었다. 저작권 있는 원문이 깃허브 저장소에 그대로 올라가지 않도록 분리하는 처리도 함께 했다.

여기서 실무적으로 중요한 선택지가 하나 있다. 웹에서 자료를 긁어 오는 대신, 직접 정리한 자사 기준과 참고 자료를 넣어도 된다. 오히려 브랜드마다 다른 신뢰 기준을 반영하려면 이쪽이 낫다.

전체 크롤이 아니라 대표 페이지 표본

한 페이지만 물려서는 사이트 전체의 E-E-A-T를 평가할 수 없다. 그렇다고 전체 크롤도 대개 불필요하다. 앨런은 15개 안팎의 대표 페이지 유형을 골랐다. 홈, 팀 소개, 저자 페이지, 회사 소개, 최신 글 목록, 개별 기사, 가이드, 이벤트, 문의, 개인정보처리방침, 이용약관 등이다.

표본 설계가 이 도구의 품질을 사실상 결정한다. 저자와 회사 신뢰 신호가 어디에 있는지를 아는 사람이 골라야 한다.

두 번의 패스

첫 실행에서 이미 쓸 만한 감사 보고서가 나왔고, 두 번째 패스에서 서식과 가독성을 다듬었다. 완성된 프로젝트는 깃허브에 백업했다. 메모리 파일, 프롬프트, 스크립트가 저장소에 올라가면 도구의 지식 베이스 전체가 보존되고, 기기가 망가져도 클론 한 번으로 복구된다.

이 접근이 통하는 조건

앨런이 E-E-A-T를 고른 것은 우연이 아니다. API가 아니라 비정형 가이드를 평가하는 영역이었기 때문이다. 같은 접근은 브랜드 가이드라인 준수, 편집 기준 점검, 접근성 리뷰처럼 "문서로 된 기준을 사람이 읽고 판단하던" 모든 작업에 그대로 옮겨 간다. 사내에 기준 문서는 있는데 점검이 매번 수작업인 영역을 찾으면 된다.

한계는 분명히 해 둘 것

E-E-A-T는 직접적인 순위 요소가 아니고, 어떤 점검 도구도 순위 상승을 보장하지 못한다. 이 도구가 측정하는 것은 구글이 콘텐츠 품질을 평가할 때 쓰는 가이드에 사이트가 얼마나 부합하는가다. 그것만으로도 벤치마크로서는 충분하지만, 성과 지표와 혼동하면 안 된다.

첫 결과물은 완성본이 아니라 좋은 초안으로 다뤄야 한다. 검토하고 수정한 내용을 프로젝트에 다시 넣으면 다음 감사부터 반영된다. 도구가 지식을 로컬 메모리에 저장하는 구조이기 때문이다. AI 산출물을 계속 손보게 되는 이유를 다룬 AI가 쓴 글을 계속 고치게 되는 이유와 같은 맥락이다.

실제로 무엇이 잡혔나

앨런이 서치 엔진 랜드 자체를 감사했을 때 전반적인 결과는 좋았지만, 방치된 법무 페이지와 표기되지 않은 리드젠 허브가 지적됐다. 둘 다 사람이 사이트를 훑을 때 가장 잘 놓치는 유형이다. 오래돼서 아무도 열지 않는 페이지, 그리고 목적이 명시되지 않은 페이지.

에이전트에 감사를 맡기는 실익이 여기에 있다. 새로운 인사이트가 아니라, 아무도 다시 보지 않는 페이지를 매번 빠짐없이 다시 보는 일이다.