예측이 먼저, 데이터는 나중에: 50개 사이트를 스캔하기 전 AI 에이전트 준비성에 관한 7가지 파격적인 견해

로봇이 이것을 읽을 수 있을까요? 친구 대신 물어봅니다.

몇 달 전, 해커톤을 위해 AI 에이전트가 웹사이트를 읽을 수 있는지 확인하는 작은 도구를 만들었습니다. 하단에는 결정론적 체크(Deterministic checks)가 있고, 상단에는 AI 추론(AI reasoning) 레이어가 있는 구조였습니다. 잘 작동했습니다. 저는 이를 Hermes Clew라고 불렀습니다.

그냥 거기서 끝낼 수도 있었습니다. 해커톤은 끝났고 그것은 단지 개념 증명(Proof of concept)일 뿐이었으니까요. 하지만 아이디어는 떠나지 않았습니다. 사람들이 출시하는 제품에 에이전트가 더 많이 등장할수록, 이것은 향후 몇 년간의 핵심 질문처럼 보였습니다. "사람이 이것을 사용할 수 있는가"가 아니라, "에이전트가 사용할 수 있는가"의 문제입니다.

그래서 Hermes는 두 가지가 되었습니다. 엔진인 Perseus Clew와 제품인 Agentis Lux입니다. (라틴어로 대략 "에이전트의 빛"이라는 뜻입니다. 에이전트가 무엇을 보는지 보여줍니다.) 저는 지난 포스트에서 논지와 구축 과정을 설명했습니다. 이것이 제가 다시 돌아오겠다고 약속했던 부분입니다.

달 표면에 꽂아둔 깃발이라고 생각해주세요. 저는 에이전트가 핵심 질문이라고 생각합니다. 그리고 뒤에 숨을 데이터가 생기기 전에, 제가 무엇을 발견할 것으로 예상하는지 미리 적어두려 합니다.

여기에 내기가 있습니다.

저는 제 예측을 사전 등록합니다 (즉, 저 자신과 게임을 하는 것입니다!)

엔진이 단 하나의 사이트도 스캔하기 전에, 저는 엔진이 무엇을 발견할 것이라고 생각하는지를 적었습니다. 그런 다음 타임스탬프와 함께 이를 리포지토리(repo)에 커밋했습니다.

과학자들은 이를 사전 등록(pre-registration)이라고 부릅니다. 저는 이를 "취소 불가"라고 부릅니다.

이유는 간단합니다. 데이터가 들어오면, 숫자를 살펴보고 프로젝트를 돋보이게 하는 패턴을 찾아낸 뒤, 마치 처음부터 그것을 예상했던 것처럼 글을 쓰기가 쉽기 때문입니다. 예측을 먼저 적어두면 그것이 불가능해집니다. 제가 맞다면, 제가 예측한 것입니다. 제가 틀렸다면, 그 실수(miss)는 결과 옆에 페이지에 그대로 남게 됩니다. 어느 쪽이든 여러분은 제 작업 내용을 확인할 수 있습니다.

이 점은 여기서 평소보다 더 중요합니다. 왜냐하면 스코어링 도구(scoring tools)들은 스스로 채점한 숙제를 스스로 검토한다는 평판이 있기 때문입니다. 해결책은 제가 스스로를 속일 수도 있는 부분까지 포함하여 모든 것을 검사 가능(inspectable)하게 만드는 것입니다.

모든 논의의 근간이 되는 가설

웹은 인간을 위해, 인간에 의해 만들어졌습니다. 검색 크롤러(Search crawlers)와 스크린 리더(screen readers)는 나중에 부분적으로 수용되었습니다. 에이전트(Agents)들은 자신들을 위해 설계되지 않은 놀이터에 나타나고 있는 셈입니다.

따라서 저는 대부분의 사이트가 에이전트가 읽고 수행할 수 있는 영역에 격차(gaps)가 있을 것이라고 예상합니다. 그리고 저는 그 격차가 예측 가능한 지점에서 발생할 것이라고 예상합니다. 즉, 기계 가독성(machine readability)을 위해 인간의 인센티브가 지불되지 않은 곳이라면 어디든 그렇습니다. 사이트는 검색 순위(search ranking)나 접근성 법률(accessibility law)과 같은 다른 요소가 이미 깔끔한 구조를 강제한 곳에서는 우연히 에이전트가 읽을 수 있는 경향이 있습니다. 그 외의 나머지는 사각지대(blind spot)입니다.

이것이 아래의 모든 예측을 뒷받침하는 엔진입니다.

예측

엔진이 가동되면 저는 50개의 사이트를 스캔할 것입니다. 이커머스(e-commerce), SaaS, 콘텐츠 및 미디어, 정부, 그리고 인디/빌더 프로젝트(indie/builder projects)에서 각각 10개씩 선정합니다. 규모, 플랫폼, 구축 유형을 아우르기 위해 최대 변이 표집(maximum-variation sampling) 방식으로 선정하며, 각 사이트별로 리포지토리(repo)에 기록할 것입니다. 무작위가 아니며, 제가 예상한 점수에 따른 선정도 아닙니다.

각 예측에는 신뢰도 태그와 무엇이 이 예측을 틀렸음을 증명할지에 대한 설명이 포함되어 있습니다. 왜냐하면 질 수 없는 예측은 예측이 아니기 때문입니다.

1. 렌더링 절벽(The rendering cliff)이 결정적인 경계선이다. (매우 확신함. 돈을 걸 수 있을 정도임.)
헤비 클라이언트 사이드 자바스크립트(client-side JavaScript) 앱으로 구축된 사이트들은 어떤 종류의 사이트이든 에이전트가 읽기 어려울 것입니다. 대부분의 AI 크롤러(AI crawlers)는 자바스크립트를 실행하지 않습니다. 수억 건의 크롤러 페치(fetch)에 걸친 Vercel의 네트워크 데이터에 따르면, 자바스크립트 실행이 전혀 발견되지 않았습니다. 만약 당신의 콘텐츠가 자바스크립트가 실행된 후에만 나타난다면, 에이전트는 빈 껍데기만 보게 됩니다.
틀린 경우: 클라이언트 중심 사이트가 콘텐츠가 HTML에 포함되어 있는지 여부에 대해 서버 렌더링(server-rendered) 사이트와 거의 동일한 점수를 받는 경우.

2. 정부가 스타트업을 이깁니다. (거의 확실함.)
미국 정부 사이트들은 소규모 인디 및 스타트업 사이트보다 에이전트(agent)가 읽기에 더 쉬울 것입니다. 정부의 누군가가 에이전트를 유치하려고 의도했기 때문이 아니라, 연방법(Section 508)이 깨끗하고 라벨이 지정된 시맨틱 마크업(semantic markup)을 강제하며, 에이전트가 파싱(parse)하는 구조가 바로 그 구조이기 때문입니다. 규제가 의도치 않게 그들을 에이전트 준비 상태(agent-ready)로 만든 것입니다. 저는 이번 테스트를 의도적으로 미국 한정으로 진행하고 있는데, 이는 다양한 국가의 규칙이 섞이지 않고 508 메커니즘 자체를 테스트하기 위함입니다.
틀린 경우: 미국 정부 사이트의 시맨틱 구조(semantic structure) 점수가 인디 사이트와 비슷하거나 그보다 낮게 나올 때.

3. 구조화된 데이터(Structured data)는 커머스 및 미디어의 영역입니다. (아마도, 거의 확실한 편.)
페이지가 무엇인지 에이전트에게 알려주는 기계 판독 가능 라벨(machine-readable labels)은 주로 쇼핑 및 뉴스 사이트에서 나타날 것이며, 정부 및 인디 사이트에서는 거의 나타나지 않을 것입니다. 검색 순위(Search ranking)가 이를 뒷받침하는 유일한 인센티브였습니다.
틀린 경우: 데이터가 고르게 분포되어 있거나, 검색 인센티브가 없는 곳에서 나타날 때.

4. 이커머스(E-commerce)의 편차가 가장 큽니다. (아마도.)
온라인 상점들은 어떤 그룹보다도 가장 큰 내부 범위를 가질 것입니다. 플랫폼 구성이 템플릿 기반 상점에서 완전히 커스텀된 자바스크립트(JavaScript) 프런트엔드 스토어에 이르기까지 다양하므로, 어떤 곳은 깔끔할 것이고 어떤 곳은 에이전트가 읽을 수 없을 것입니다.
틀린 경우: 상점 점수들이 촘촘하게 모여 있거나, 다른 그룹의 편차가 더 넓을 때.

5. 일부 사이트는 실수로 문을 잠급니다. (동전 던지기 수준의 확률.)
상당수의 사이트가 robots.txt에서 에이전트를 차단하여, 에이전트가 페이지에 아예 도달하지 못할 것입니다. 저는 이것의 대부분이 의도치 않은 것, 즉 에이전트를 배제하려는 결정이 아니라 기본 설정이나 포괄적인 규칙 때문이라고 생각합니다.
틀린 경우: 거의 아무도 에이전트를 제한하지 않거나, 제한하는 이들이 명확하게 의도했을 때.

6. 점수가 매우 다양하게 나타날 것입니다. (거의 확실합니다.)
전반적으로 점수는 밀집되기보다는 넓게 퍼질 것입니다. 왜냐하면 에이전트 준비성 (agent readiness)에 대한 확립된 표준이 아직 없기 때문입니다. 규칙들이 만들어진 지 불과 몇 달밖에 되지 않았는데, 개발 도구 기업이 아닌 우리 중 얼마나 많은 이들이 그 규칙들을 채택했을까요? 규칙이 이렇게 새롭다면, 사이트들이 그 규칙들에 수렴했을 리 없습니다.
틀린 경우: 점수가 하나의 범위 내에 조밀하게 밀집되는 경우. 이는 사이트들이 의도하지 않았음에도 이미 수렴하고 있음을 의미합니다.

7. 좋은 명세(Spec), 잘못된 문 앞. (이미 목격한 현상이므로 막연한 추측이 아닙니다.)
다른 여섯 가지와 달리, 이것은 막연한 추측이 아닙니다. 사이트들을 선정하는 과정에서 이미 이를 확인했습니다. 제가 확인한 10개의 명세 (spec) 중 9개는 기업 자체 사이트가 아닌 GitHub 리포지토리 (repo)에 있었습니다. 단 하나만이 자체 도메인에서 제공하고 있었습니다. 따라서 저는 이것을 무언가를 보기 전에 건 도박이 아니라, 이미 근거를 가지고 가진 기대치로 기록합니다. 패턴은 이렇습니다: API를 출시하는 기업들은 명세를 게시하는 경향이 있지만, 에이전트가 그것을 찾을 만한 곳에 게시하지는 않습니다. 에이전트가 실제로 확인해야 할 정문(front door)에 도착하면 아무것도 찾지 못합니다. 명세는 존재하지만, 에이전트가 결코 찾아볼 생각을 하지 못할 어딘가에 있을 뿐입니다. 훌륭한 명세지만, 잘못된 문 앞입니다.
틀린 경우: 10개 중 한두 개 이상이 결국 자체 도메인의 발견 가능한 경로에서 명세를 노출하는 것으로 밝혀지는 경우.

이것이 흥미로운지 어떻게 알 수 있을까

저는 나중에 스스로에게 이야기를 만들어내지 않도록, 어떤 수치를 보기 전부터 의도적으로 이 결정을 내렸습니다. 두 가지 결과 모두 발견 (finding)입니다. 단지 그 울림의 크기가 다를 뿐입니다.

Loud (큰 울림): 점수가 넓게 퍼지고, 그룹들이 서로 명확하게 다르게 보이며, 적어도 하나의 결과가 저를 놀라게 하는 경우 (정부 기관이 스타트업을 이기는 것 등이 해당됩니다). 확산과 놀라움이 결합되면 그 자체로 포스트를 이끌어갈 이야기가 됩니다.

Quiet (작은 울림): 모든 것이 하나의 범위에 밀집되고 어떤 그룹도 도드라지지 않는 경우. 이것은 실패가 아닙니다. 하나의 발견입니다. 즉, 사이트들이 아직 에이전트 준비성 (agent-readiness)에 수렴하지 않았으며, 이를 입증하는 기준점 (baseline)을 찾았다는 것입니다. 더 조용한 포스트가 되겠지만, 실제 결과이며, 다음 스캔에서 비교할 측정 대상이 생기는 것입니다.

제가 하지 않을 단 한 가지는 존재하지 않는 변동성 (variance)을 만들어내는 것입니다. 데이터가 평탄하게 나온다면, 저는 평탄하다고 보고할 것입니다. 이것은 6주 전의 상태에 대한 첫 번째 측정입니다. 기준점 (baseline)은 결과가 평탄하게 나왔다고 해서 실패하는 것이 아닙니다. 오직 그 형태에 대해 거짓을 말할 때만 실패하는 것입니다.

이것이 아닌 것

그룹당 10개씩 총 50개의 사이트를 선정하는 것은 예시를 위한 것입니다. 이는 웹 전체를 대표하는 표본이 아니며, 보고서에도 그렇게 명시할 것입니다. 이는 패턴과 사례를 보여주는 것이지, 통계적 증명이 아닙니다.

저는 공개된 표면 (public surface)만을 스캔합니다. SaaS 제품의 경우, 이는 로그인 뒤에 있는 앱이 아니라 마케팅 사이트, 문서 (docs), 그리고 API 명세 (API spec)를 의미합니다. 에이전트 (Agents)는 로그인하기 훨씬 전, 제품의 공개된 문에서 여러분의 제품을 만납니다. 저는 그 문들을 스캔하고 있는 것입니다.

그리고 저는 존재하는 것에 대해 점수를 매깁니다. 양식 (forms)이 없는 사이트는 양식 항목 때문에 감점을 받지 않습니다. 따라서 저는 하나의 결합된 수치가 아니라, 한 번에 하나의 카테고리씩 동일한 조건끼리 그룹 대 그룹으로 비교할 것입니다.

저의 앞문도 스캔하고 있습니다

50개 중 2개는 Dev.to와 Devpost입니다. 여러분이 이 글을 읽고 있는 곳이자, 제가 이 글을 제출하는 곳입니다. 이들은 콘텐츠 그룹에 속하며, 다른 모든 곳과 마찬가지로 스캔됩니다. 제가 좋아하는 플랫폼들이 에이전트에게 어떻게 읽히는지 확인하고 싶으며, 이는 다른 모든 플랫폼과 함께 보고서에 포함될 것입니다.

또한 도구는 자체 스캔을 통과해야 합니다. AgentisLux는 제가 다른 모든 대상에게 적용하려는 것과 동일한 체크 항목으로 자신의 사이트를 대상으로 지정됩니다. 저는 이를 두 번 실행합니다. 한 번은 지금 벤치마크 (benchmark) 전이고, 다시 한 번은 그 이후에 실행하여 여러분이 저의 앞문이 어떻게 변하는지 지켜볼 수 있게 할 것입니다. 자신의 집이라고 해서 검사를 면제해주지 않습니다.

다음 단계

엔진은 구축, 테스트 및 병합되었습니다: 6개의 프론트엔드 체크(frontend checks), 6개의 API 체크(API checks), 스캔 핸들러(scan handler), 에이전트 시뮬레이션 레이어(agent-simulation layer), 그리고 50개 사이트 전체를 실행하는 배치 엔진(batch engine)이 포함됩니다. 공개 스캔은 프론트엔드를 읽습니다. API 체크는 벤치마크(benchmark) 내부에서 실행됩니다. 이러한 분리는 핵심이며, 이는 아키텍처(architecture) 상의 '문(doors)' 아이디어입니다. 스캔이 실행되기 전 마지막 단계는 프로덕션(production)에 배포하는 것입니다. 진행 과정을 지켜보고 싶다면 빌드 과정을 따라가셔도 좋습니다. 스캔이 완료되면, 적중한 것과 빗나간 것 모두를 포함한 결과를 이 예측값 바로 옆에 게시하겠습니다.

그때까지 베팅은 기록된 상태로 남습니다. 저는 몇 달 전에 이 아이디어의 첫 번째 버전을 구축했으며, 수없이 틀리기도 했습니다. 이 기록들은 리포지토리(repo)에 타임스탬프와 함께 저장되어 있으며, 데이터가 도착하면 맞든 틀리든 제가 남겨둔 바로 그 자리에 놓여 있을 것입니다. 어떤 것이 가장 먼저 깨질 것 같은 직감이 있으신가요? 자, 베팅할 준비가 되셨나요?

AI 지원. 인간 승인 (모든 베팅은 본인의 책임입니다). NLP 기반.

_ Devpost H0 Hackathon을 위해 제작되었습니다. #H0Hackathon_