에이전트에 대한 웹 호환성은 추가 기능에서 기본 요구 사항으로 이동됩니다.

정상적인 콘텐츠가 브라우저에 표시되지만 에이전트 프로그램에 전달되면 완전히 읽을 수 없는 경우가 많습니다. 페이지가 열릴 수 있다고 해서 페이지가 실제로 소비될 수 있다는 의미는 아닙니다. 사람이 볼 수 있다고 해서 기계가 안정적으로 읽고 검증하고 추적할 수 있는 것은 아닙니다.

이 문제는 “사이트맵 채우기” 또는 "기사 페이지에 일부 구조화된 데이터 추가"와 같은 부차적인 문제로 간주되었습니다. 더 이상 코너가 아닙니다. 공용 사이트가 AI 크롤러, 자동화된 검색 및 에이전트 기반 워크플로에 직면하면 호환되는 개체는 더 이상 브라우저와 검색 엔진뿐만 아니라 의미론에 따라 페이지를 분할하고, 링크에 따라 점프하고, 상태에 따라 실행을 계속할 수 있는 클라이언트 유형이기도 합니다. 페이지가 인간 독자에게만 친화적이지만 그러한 클라이언트에 대한 함정으로 가득 차 있다면 호환성이 불완전한 웹사이트처럼 보이기 시작할 것입니다.

페이지를 열 수 있다고 해서 페이지를 읽을 수 있는 것은 아닙니다.

첫 번째 문제는 대개 콘텐츠의 품질이 아니라 콘텐츠가 출력되는 방식입니다.

페이지가 클라이언트 측 렌더링에 본문 텍스트를 포함하고, 아코디언 패널에서 주요 필드를 숨기고, 명시적인 URL 없이 스크롤 흐름으로 페이지 매김을 만들고, 테이블을 이미지로 렌더링하는 경우 에이전트 프로그램은 추측에만 의존할 수 있습니다. 인간의 경우 잘못된 추측은 단락이 누락되었음을 의미할 수 있습니다. 기계의 경우 잘못된 추측으로 인해 후속 작업이 잘못된 방향으로 갈 수 있으며 앞으로 몇 단계를 더 거치면 잘못된 이해가 계속될 것입니다.

이러한 유형의 문제는 문서 사이트와 콘텐츠 사이트에서 특히 두드러집니다. 인간 독자는 시각적 계층을 따르고 컨텍스트 자체를 완성합니다. 대리인은 그렇지 않습니다. 에이전트가 보는 것은 DOM, 헤더 계층 구조, 링크 관계, 양식 제어, 상태 코드 및 크롤링 가능한 텍스트입니다. 본문이 이러한 기본 신호와 단절되면 페이지는 어색한 상태로 나타날 것입니다. 현대적으로 보이지만 실제로는 불안정합니다.

과거에 단일 페이지 애플리케이션을 마이그레이션할 때 이 레이어가 가장 먼저 노출되는 경우가 많았습니다. 첫 번째 화면이 나타나고 인터랙션이 가능하지만, 머신이 셸을 캡처하고 스크립트가 끝날 때까지 실제 텍스트가 나타나지 않습니다. 지연 로딩, 무한 스크롤, 다양한 “확장 및 보기” 디자인과 결합하여 콘텐츠 페이지는 일련의 우연한 이벤트가 됩니다. 브라우저 사용자에게는 약간의 속도 저하일 뿐입니다. 상담원에게 이는 신뢰할 수 없는 항목의 체인입니다.

기계가 원하는 것은 시각적 콘텐츠가 아닌 안정적인 진입이다.

사이트를 "에이전트 지원"으로 만드는 것은 본질적으로 새로운 트릭을 추가하는 것이 아니라 호환성 계층을 추가하는 것입니다.

이 호환성 계층의 가장 가치 있는 측면은 페이지를 “컴퓨터에 있는 것처럼 보이도록” 만드는 것이 아니라 가장 기본적인 사실, 즉 이 페이지가 어떤 페이지인지, 텍스트가 어디에 있는지, 현재 상태가 무엇인지, 계속 이동할 수 있는지 여부, 실패 시 무엇을 반환해야 하는지를 명확하게 설명하는 것입니다. 이러한 사실이 불안정한 한 에이전트는 경계를 반복적으로 테스트합니다.

콘텐츠 사이트에서 가장 먼저 처리해야 할 가장 가치 있는 사항은 일반적으로 다음과 같습니다.

• 텍스트는 추측하기 위해 스크립트에 의존하지 않고 HTML에서 직접 액세스할 수 있어야 합니다.
• 제목 계층 구조는 안정적이어야 하며 시각적 스타일이 의미 구조를 대체하지 않아야 합니다.
• 페이지 매김, 필터링, 검색 결과에는 프런트엔드 상태에만 존재하는 것이 아닌 공유 가능한 URL이 있어야 합니다.
• 그림, 표, 코드 블록에는 읽을 수 있는 대체 텍스트 또는 원본 텍스트가 있어야 합니다.
• 표준, 사이트맵, 피드의 기본 내보내기는 깨끗해야 하며 여러 임시 매개변수와 혼합되어서는 안 됩니다.

진부하게 들릴 수도 있지만 이제 그 의미가 바뀌었습니다. 과거에는 검색 엔진과 접근성을 위해 추가되었습니다. 이제는 에이전트가 수동 프롬프트 없이 안정적으로 콘텐츠를 찾고, 페이지 간의 관계를 결정하고, 다음 단계를 진행할 수 있도록 이러한 기능이 추가되었습니다. 그들은 모두 같은 점을 지적합니다. 페이지는 일회성 시각적 결과가 아니라 다른 클라이언트의 명확한 입력으로 처리되어야 합니다.

이것이 바로 "AI 버튼 추가"가 실제로 도움이 되지 않는 이유입니다. 버튼 자체가 페이지를 더 많이 사용하게 만들지는 않습니다. 기껏해야 작업을 새 항목으로 래핑하는 것뿐입니다. 맨 아래 레이어가 이해를 유지하기 위해 여전히 시각적 레이아웃과 임시 상태에 의존하는 경우 에이전트 프로그램은 새로 고침, 점프, 롤백 및 권한 변경 시 여전히 제어력을 잃게 됩니다.

상호작용은 프롬프트에서 멈추는 것이 아니라 작업을 완료해야 합니다.

페이지가 콘텐츠 표시만을 위한 것이라면 호환성 문제는 비교적 쉽게 처리할 수 있습니다. 상호 작용 및 운영 수준에 관해서는 문제가 더욱 어려워집니다.

에이전트에게 실제로 필요한 것은 "거의 충분"이 아니라 명확한 작업 경계입니다. 제출, 확인, 취소, 다운로드, 구독, 점프 및 내보내기 등의 작업에는 명확한 전제 조건, 실패 반환 및 추적 가능한 결과가 있어야 합니다. 작업이 여러 팝업, 프롬프트 및 2차 확인과 혼합되는 한, 기계는 계속해서 같은 위치에 멈춰 있을 것입니다.

여기서 공개 사이트와 내부 시스템의 차이가 커지기 시작합니다. 공용 사이트는 소비 가능성에 직면하고 내부 시스템은 권한 및 위험 제어에 직면합니다. 전자는 정보 구조와 동작 의미를 안정화하는 데 더 적합하므로 외부 클라이언트가 우회를 피할 수 있습니다. 후자는 특히 자금, 게시, 삭제 및 권한 변경이 관련된 경우 "에이전트와 호환"되기 위해 경계를 완화해서는 안 됩니다. 보수적이어야 할 곳에서는 여전히 보수적이어야 합니다.

따라서 이것은 모든 웹페이지를 기계 인터페이스로 변환하는 것이 아닙니다. A more realistic approach is to turn the pages that are originally intended for external consumption into stable, verifiable, and replayable entrances. 기사 페이지, 문서 페이지, 기술 자료, 도움말 센터, 공개 API 및 공개 검색 결과가 가장 먼저 영향을 받고 가장 먼저 혜택을 볼 수 있습니다.

이 수준의 호환성에는 명확한 경계가 있습니다.

상담사 지원은 모든 경우에 적용되는 일률적인 목표가 아닙니다.

완전한 인트라넷의 백엔드, 강력한 권한 제어 기능을 갖춘 비즈니스 시스템, 짧은 수명 주기 활동 페이지 및 공개 소비를 위한 콘텐츠 스테이션은 동일한 수준에 있지 않습니다. 전자는 제어에 더 중점을 두는 반면, 후자는 가독성, 색인화 가능성 및 추적성에 더 중점을 둡니다. 이러한 두 가지 유형의 시스템을 “기계를 사용 가능하게 만드는” 동일한 표준 세트로 강제하는 것은 결국 관리 비용만 증가시킬 뿐입니다.

하지만 공개된 사이트에서는 계속해서 아무 것도 변하지 않은 척 하기는 어렵습니다. AI 크롤러는 점점 더 페이지를 직접 읽을 것이며 에이전트 워크플로는 구조화된 콘텐츠와 안정적인 작업에 점점 더 의존하게 될 것입니다. 사이트가 여전히 "사람들이 보기에 충분하다"는 생각을 고수한다면 조만간 콘텐츠 배포, 검색, 보관 및 자동화된 통합에 균열이 생길 것입니다.

따라서 이번 변경은 호환성 업그레이드에 가깝습니다. 과거에는 프런트엔드가 다양한 브라우저, 다양한 화면, 다양한 네트워크를 고려해야 했습니다. 이제는 스스로 페이지를 분할하고, 스스로 링크를 따라가고, 스스로 상태를 확인할 수 있는 클라이언트 유형도 고려해야 합니다. 이러한 호환성 계층이 추가되면 사이트는 실제로 새로운 기본 요구 사항을 충족할 수 있습니다. 즉, 볼 수 있을 뿐만 아니라 안정적으로 소비되어야 합니다.