화면만 지운 텍스트 웹사이트가 인공지능 에이전트를 망가뜨리는 이유

마크다운 텍스트만 떠먹여 주는 웹사이트가 인공지능 시대를 헛짚은 이유

많은 기업이 인공지능 검색 엔진이나 자율형 에이전트의 눈에 띄기 위해 웹사이트를 순수 텍스트 형태인 마크다운(Markdown) 파일로 변환해 제공하는 방식을 앞다투어 도입하고 있다. 생성형 검색 최적화(GEO) 열풍을 타고 페이지의 디자인과 화려한 자바스크립트를 모두 걷어낸 뒤, 알맹이 글자만 건네면 인공지능이 우리 웹사이트를 더 잘 인용해 줄 것이라는 기대 때문이다.

하지만 이 접근법에는 결정적인 구멍이 있다. 마크다운으로 찍어낸 복제본은 인공지능의 ‘읽기’ 문제는 해결해 줄지언정 ‘행동’ 문제는 완전히 지워버린다. 사람이 웹 브라우저에서 버튼을 누르고, 장바구니에 상품을 담고, 구독을 취소하는 모든 인터랙션 요소는 마크다운으로 깎아내는 순간 평범한 줄글로 변해 사라진다. 기계가 읽을 수 있는 문장만 남기고, 기계가 실행할 수 있는 손잡이를 통째로 뜯어낸 셈이다.

사람이 전혀 들어오지 않고 오직 인공지능 비서만 방문하는 웹사이트를 상상해 보면 답은 명확해진다. 레이아웃, 여백, 브랜드 디자인 시스템, 눈길을 사로잡는 이미지 배치는 기계에게 아무런 의미가 없다. 화면을 보지 않는 기계에게 중요한 것은 두 가지뿐이다. 구조가 명확하게 잡힌 HTML(의미론적 웹 규격)이든가, 아니면 기계가 호출할 수 있는 도구 목록(Tool Surface)이다. 그러나 현재 유행하는 텍스트 변환 기술은 인공지능이 무언가를 직접 결제하거나 처리하러 들어왔을 때 누를 버튼조차 찾지 못하게 만드는 심각한 구조적 후퇴를 낳고 있다.

95.9%의 웹 접근성 붕괴와 28.3%로 주저앉은 에이전트 성공률의 민낯

인공지능 에이전트가 웹사이트에서 작업을 완수하지 못하는 가장 근본적인 이유는 기계의 지능 부족이 아니다. 웹사이트 자체의 기초 바닥이 심각하게 깨져 있기 때문이다. 사람이 마우스로 화면의 파란색 네모를 누르는 행동은 눈으로 보기에 직관적이지만, 화면을 시각적으로 보지 않고 코드 구조(접근성 트리)로 파악하는 에이전트에게 이름 없는 버튼은 보이지 않는 벽과 같다.

웹 접근성 평가 기관인 WebAIM이 공개한 2026년 백만 개 대표 웹사이트 전수 조사 결과는 충격적이다. 최상위 100만 개 홈페이지만 추려 검사했음에도 국제 웹 접근성 표준(WCAG 2)을 통과하지 못한 사이트가 무려 95.9%에 달했다. 2025년의 94.8%보다 오히려 악화하며 지난 6년간 이어지던 개선 흐름이 완전히 뒤집혔다. 페이지당 감지된 오류는 평균 56.1개로 1년 만에 10.1% 늘어났다.

가장 흔한 실패 원인 세 가지가 바로 에이전트의 ‘행동’을 마비시키는 요소들이다. 입력창에 라벨(Label)이 없는 페이지가 절반(51.0%)을 넘었고, 목적지가 비어 있는 링크가 46.3%, 이름 없는 버튼이 30.6%였다. 버튼에 ‘구매하기’나 ‘확인’이라는 텍스트 라벨이 명시되지 않고 단순 아이콘 그래픽만 들어가 있다면, 화면을 텍스트 구조로 번역해 받아들이는 에이전트는 두 버튼 중 무엇을 눌러야 할지 구분할 수 없다.

실제 연구 결과에서도 이 취약점은 여실히 드러난다. 컴퓨터를 직접 조작하는 에이전트인 엔스로픽의 ‘클로드 소네트 4.5’를 대상으로 60가지 일상 웹 업무를 수행하게 한 CHI 2026 학술 연구에 따르면, 정상적인 기본 시각 환경에서 78.3%에 달했던 작업 성공률은 키보드로만 조작해야 하는 환경에서 41.7%로 급락했다. 화면을 150% 확대한 상태에서는 성공률이 28.3%까지 곤두박질쳤다. 보조 기술에 의존하는 시각 장애인이 겪는 웹의 결함이 인공지능 에이전트에게도 고스란히 치명타로 작용한 것이다.

화면만 예쁜 껍데기 사이트가 초래하는 주문 먹통과 비용 누수

기계가 읽을 수 있는 뼈대를 갖추지 않은 채 시각적 화면에만 매달리는 사이트는 에이전트 도입 과정에서 기업의 일상 운영을 심각하게 뒤흔든다. 눈으로 보는 사람에게는 아무 문제가 없더라도, 에이전트가 접속하는 순간 백엔드 시스템에는 예기치 못한 비용과 장애가 연쇄적으로 발생한다.

중복 결제와 티켓 폭증으로 터져나가는 고객 응대 비용

에이전트가 웹 폼을 제출할 때 가장 흔히 터지는 사고는 바로 ‘작업 성공에 대한 명확한 기계적 피드백’의 부재다. 사람이 폼을 제출하면 화면에 잠깐 뜨는 ‘접수되었습니다’라는 팝업이나 초록색 안내 문구를 보고 작업을 멈춘다. 하지만 이 메시지가 화면에 픽셀로만 그려지고 기계가 읽을 수 있는 상태 코드나 데이터로 반환되지 않으면, 에이전트는 제출이 완료되었는지 알 방법이 없다.

그 결과 에이전트는 성공 신호를 확인하지 못해 주문이나 신청을 반복해서 시도한다. 실제로 현장 테스트에서 동일한 주문서가 서너 번씩 연속 접수되거나, 똑같은 고객 지원 문의가 수십 건씩 중복 등록되는 현상이 발생했다. 이는 인공지능의 오작동이 아니라 결과 피드백을 기계 친화적으로 돌려주지 않은 웹사이트의 구조적 결함이다. 이를 처리하기 위한 취소 환불 처리, 중복 데이터 정제 비용은 고스란히 기업의 몫으로 남는다.

버튼을 못 찾는 에이전트의 반복 호출과 서버 응답 지연

버튼이나 입력창에 올바른 이름표가 없으면 에이전트는 원하는 요소를 찾기 위해 페이지 전체를 훑고 또 훑는다. 한 번의 요청으로 끝날 작업이 대여섯 번의 추가 페이지 분석 요청으로 이어지며 서버 자원을 불필요하게 갉아먹는다.

이 과정에서 에이전트 모델을 호출하는 데 들어가는 토큰 비용이 천정부지로 치솟는다. 단순히 폼 하나를 작성하는 작업에 수만 토큰이 소모되고, 사이트 서버에는 수 초 단위로 반복적인 탐색 트래픽이 몰려 일반 고객의 페이지 로딩 속도까지 지연시키는 병목을 유발한다.

기계 친화적 안내 신호 누락이 초래하는 거래 단절 리스크

텍스트만 달랑 복사해 놓은 마크다운 미러링 사이트는 다음 행동 경로를 완전히 차단한다. 상품 설명은 잔뜩 적혀 있지만 ‘어디로 결제 요청을 보내야 하는지’, ‘옵션 변경은 어떤 규격으로 요청해야 하는지’ 안내하는 인터페이스가 전무하기 때문이다.

결국 사용자가 인공지능 비서에게 “A 쇼핑몰에서 저 영양제 장바구니에 넣고 결제해 줘”라고 지시해도, 에이전트는 결제 단계로 진입하지 못한 채 “해당 사이트는 구매 기능을 지원하지 않습니다”라는 오류를 뱉어내게 된다. 눈앞에 찾아온 구매 전환 기회를 웹사이트 스스로 차단하는 셈이다.

쇼피파이의 WebMCP 승부수: 화면 대신 도구 목록을 건네는 법

이러한 한계를 뚫기 위해 전자상거래 플랫폼 쇼피파이(Shopify)는 2026년 8월, 독자적인 템플릿 언어(Liquid)로 구축된 모든 스토어에 웹 모델 컨텍스트 프로토콜(WebMCP) 도구를 기본 활성화하는 파격적인 조치를 단행했다. 상인이 코드를 한 줄도 수정하거나 별도의 플러그인을 설치할 필요 없이, 플랫폼 전체에 기계 전용 도구 인터페이스를 한 번에 배포한 것이다.

쇼피파이가 연동한 도구는 네 가지다. 상품 카탈로그 검색, 장바구니 담기, 결제 진행, 그리고 매장 정책 조회다. 쇼피파이는 자체 CDN을 통해 모든 매장에 동일한 어댑터 스크립트를 주입했다. 이 스크립트는 인공지능 에이전트가 접속했을 때 화면을 복잡하게 해석하려 애쓰는 대신, 기계가 즉시 호출할 수 있는 도구 목록을 건넨다.

도구의 작동 방식은 철저히 기계 호출 규격을 따른다. 에이전트가 상품 검색 도구를 호출하면 규격화된 상품 목록과 가격 데이터가 반환되며, 결과 메시지 안에는 “다음 작업으로 장바구니 도구를 호출하라”는 구체적인 다음 행동 지침이 포함된다. 결제 도구를 호출하면 브라우저를 최종 결제 화면으로 이동시킨 뒤 기계에게 “추가 내비게이션을 멈추고 결과를 대기하라”는 안내를 전달한다.

이 방식의 핵심적인 이점은 사람이 이용하는 카탈로그와 기계가 호출하는 데이터가 단일 원천(Single Source of Truth)에서 나온다는 점이다. 사람이 보는 재고와 기계가 조회하는 재고가 어긋날 위험이 없고, 상인에게 추가 인프라 유지 비용도 발생하지 않는다. 비록 초기 배포 당시 결제 경로에서 일부 내부 오류가 관측되는 등 과도기적 불안정성이 남아 있었지만, 화면을 텍스트로 뭉개버리는 대신 ‘기계가 쓸 수 있는 손잡이’를 제공했다는 점에서 향후 커머스 웹 아키텍처가 나아갈 방향을 명확히 제시했다.

도입 적합 대상 vs 보류 대상 판정

인공지능 에이전트의 방문을 대비하는 기술 전략은 유행하는 마크다운 파일 추가가 아니라, 사이트의 기본 뼈대를 수리하고 명확한 기계 인터페이스를 열어주는 데서 시작해야 한다. 기업의 비즈니스 형태와 기술 성숙도에 따라 지금 취해야 할 행동은 완전히 갈린다.

지금 즉시 의미론적 뼈대와 도구 인터페이스를 갖춰야 할 기업

• 자사몰 중심의 거래형 전자상거래 기업: 예약, 결제, 장바구니 등 사용자의 명확한 행동이 매출로 직결되는 사이트는 지금 당장 WebMCP 도입을 검토하거나 폼 전송 규격을 표준화해야 한다. 에이전트가 대리 결제를 시도할 때 막힘없이 완수할 수 있는 인터페이스가 미래 커머스의 핵심 진입 장벽이 된다.
• 고객 지원 및 셀프서비스 포털 비중이 높은 기업: 주소 변경, 구독 해지, 티켓 접수처럼 정형화된 업무를 처리하는 페이지라면 텍스트 안내보다 명확한 상태 피드백을 주는 웹 표준 양식을 구축해야 한다. 이를 통해 에이전트의 반복 호출로 인한 시스템 과부하를 사전에 차단할 수 있다.
• 복잡한 SaaS 및 웹 기반 업무 도구 제공사: 화면의 화려한 그래픽 뒤에 숨겨진 입력창과 버튼마다 표준 ARIA 이름과 고유 식별값을 부여해야 한다. 스크린리더를 지원하는 표준 접근성 구조를 복원하는 것만으로도 컴퓨터 조작형 에이전트의 작업 성공률을 2배 이상 끌어올릴 수 있다.

마크다운 미러링 유행을 멈추고 기본 웹 규격부터 고쳐야 할 기업

• 기본 HTML 검증 오류가 수십 개씩 방치된 웹사이트: 기초적인 닫는 태그 누락, 중복 ID, 이름 없는 버튼이 방치된 상태에서 마크다운 복제본을 추가하는 일은 깨진 독에 물을 붓는 격이다. 복제본을 만들기 전에 기존 운영 페이지의 표준 웹 규격 준수율부터 손보는 것이 훨씬 급선무다.
• 단순 브랜드 홍보 및 브로슈어형 정적 사이트: 사용자가 누를 버튼이 없고 단순히 글과 정보만 읽는 사이트라면 굳이 복잡한 도구 인터페이스를 구축할 필요가 없다. 이 경우에는 검색 엔진이 이미 잘 긁어가고 있는 JSON-LD 형태의 구조화된 데이터(Schema.org)만 충실히 채워 넣는 것으로 충분하다.
• 사내 전담 개발 인력이 없는 중소 규모 사이트: 자체적인 기계 호출 규격을 설계할 여력이 없다면, 쇼피파이나 주요 CMS 플랫폼이 코어 차원에서 정식 표준을 일괄 배포할 때까지 관망하는 것이 현명하다. 검증되지 않은 외부 변환 스크립트를 얹는 것은 보안 구멍과 데이터 불일치만 초래한다.