AI 에이전트가 읽는 홈페이지 — 구조화 데이터 실전 가이드

결론부터 말하면 이렇다. AI 에이전트가 내 홈페이지를 헷갈리지 않고 읽게 만들려면 사람이 보는 화면과는 별도로 기계가 읽는 정보 구조를 갖춰야 한다. 핵심은 두 가지다. 에이전트가 "무엇이 있는지" 알게 하는 구조화 데이터, 그리고 "무엇을 할 수 있는지" 헷갈리지 않게 하는 명확한 폼과 버튼 설계다.

마침 최근 이 흐름을 상징하는 소식도 나왔다. 오픈AI가 독립형 브라우저 챗GPT 아틀라스를 2026년 8월 9일 종료하고, 그 기능을 ChatGPT 앱의 브라우저 기반 에이전트 기능으로 흡수하기로 했다. 브라우저 하나가 사라진다고 해서 에이전트가 사이트를 대신 읽고 행동하는 흐름 자체가 끝나는 것은 아니다 — 오히려 형태를 바꿔 계속된다.

어제 올라간 짧은 글 챗GPT 아틀라스 같은 AI 브라우저, SEO에 어떤 영향을 줄까에서 에이전틱 브라우저라는 흐름 자체를 소개했다면, 이 글은 한 단계 더 들어간다. 실제로 어떤 스키마 코드를 넣어야 하는지, 폼은 어떻게 설계해야 하는지, 업종별로는 무엇부터 챙겨야 하는지를 구체적인 예시로 정리한다. 홈페이지·쇼핑몰·예약 페이지를 운영한다면 디자인 개편보다 먼저 봐야 할 내용이다.

지금까지 홈페이지 최적화는 대부분 "사람이 검색해서 클릭하게" 만드는 데 집중했다. 그런데 에이전트가 검색부터 클릭, 입력, 예약까지 대신 처리하는 비중이 늘면서 내 홈페이지의 실제 방문자가 사람이 아니라 소프트웨어일 가능성이 점점 커지고 있다. 이 소프트웨어가 페이지를 오해해서 잘못된 정보를 전달하거나, 아예 다음 단계로 넘어가지 못하고 멈춰 버리면 실제 고객을 놓치는 셈이 된다. 그래서 지금 이 구조를 갖춰 두는 일은 먼 미래를 위한 준비가 아니라, 이미 벌어지고 있는 상황에 대한 대응이다.

이 글의 핵심만 먼저 추리면 이렇다.

• 챗GPT 아틀라스는 2026년 8월 9일 종료되지만, 퍼플렉시티 코멧·크롬의 제미나이 오토브라우즈 등 에이전틱 브라우저 흐름 자체는 계속 확산 중이다.
• 에이전트는 구조화 데이터로 "무엇이 있는지" 발견하고, 명확한 폼과 버튼으로 "무엇을 할 수 있는지" 판단한다. 둘 중 하나만 있으면 절반짜리다.
• 상품·서비스 페이지에는 Product·Offer·AggregateRating·LocalBusiness 같은 스키마 타입을 정확한 값으로 채워야 에이전트가 오작동하지 않는다.
• llms.txt 같은 "AI 전용 파일"은 아직 구글 검색 순위에 직접 쓰이지 않는다고 확인됐다. 급하게 만들 필요는 없지만, 여유가 있다면 보험 삼아 준비해도 나쁘지 않다.
• 업종에 따라 우선순위가 다르다. 병원·미용실은 위치·예약 정보, 쇼핑몰은 가격·재고, 콘텐츠형 사이트는 작성일·저자 정보부터 챙기면 된다.

지금 에이전틱 브라우저 시장에서 무슨 일이 벌어지고 있나?

답부터 말하면, 대표 주자 하나가 사라지고 흐름은 다른 채널로 옮겨가는 중이다. 오픈AI는 2025년 10월 출시한 독립형 브라우저 챗GPT 아틀라스의 서비스를 2026년 8월 9일 종료한다고 밝혔다. 대신 그동안 아틀라스에서 쌓은 경험을 ChatGPT 앱 안의 브라우저 기반 에이전트 기능으로 옮겨, 다중 탭·다운로드·탐색 기능을 더 강화한 형태로 통합하겠다는 설명이다. 이용자는 8월 9일 전까지 북마크와 열린 탭, 쿠키·세션 정보를 내보내 다른 브라우저로 옮겨야 한다.

이 소식만 보면 "에이전틱 브라우저는 실패한 실험이었나" 싶을 수 있다. 하지만 다른 지표를 보면 얘기가 다르다. 퍼플렉시티 코멧은 2025년 7월 출시 이후 무료 제공을 유지하며 꾸준히 이용자를 늘리고 있고, 어제 짧은 글에서 소개한 조사에서도 브라우저형 AI 에이전트 트래픽의 절반 가까이를 차지할 만큼 이미 자리를 잡았다. 여기에 더해 구글은 크롬의 제미나이 오토브라우즈 기능을 2026년 1월부터 전체 사용자에게 순차 배포했고, 연말까지 픽셀 10·갤럭시 S26 같은 안드로이드 기기 약 2억 대까지 확대할 계획도 밝혔다.

정리하면 이렇다. 오픈AI 입장에서 아틀라스를 종료하는 이유는 "에이전틱 브라우징이 안 통해서"가 아니라, 별도 앱을 따로 설치·관리하게 하는 것보다 이미 수억 명이 쓰는 ChatGPT 앱 안에 브라우저 기능을 넣는 편이 효율적이라는 판단에 가깝다. 즉 독립형 AI 브라우저라는 형태 하나는 정리되지만, "AI가 사람 대신 웹사이트를 읽고 행동한다"는 큰 흐름은 오히려 더 넓은 채널(주요 브라우저 자체 기능, 모바일 OS 단)로 번지고 있다.

그래서 홈페이지 운영자 입장에서 준비할 방향은 바뀌지 않는다. 특정 브라우저 하나를 겨냥해 대응할 게 아니라, 어떤 이름의 에이전트가 찾아와도 헷갈리지 않는 구조를 갖추는 것이 목표다. 아틀라스를 쓰던 사용자도 결국 ChatGPT 앱의 브라우저 기능으로 옮겨 갈 뿐, 그 에이전트가 내 홈페이지를 읽는 방식 자체는 크게 달라지지 않는다.

브라우저 이름표가 바뀌었다고 대응 전략을 다시 짤 필요는 없다. "에이전트가 읽기 쉬운 구조"라는 목표 자체는 그대로다.

국내 사정도 크게 다르지 않다. 네이버 역시 검색 결과 안에 AI 브리핑·AI탭을 확대하며 답변형 검색 비중을 늘리고 있고, 구글 크롬을 쓰는 국내 이용자도 제미나이 오토브라우즈의 영향권 안에 들어와 있다. 특정 회사의 브라우저 하나만 신경 쓰기보다, 어떤 플랫폼의 에이전트가 오더라도 페이지 구조 자체가 명확한지를 기준으로 삼는 편이 훨씬 안정적이다.

이런 맥락에서 구조화 데이터·폼 설계는 SEO(검색엔진최적화)·AEO(답변엔진최적화)·GEO(생성엔진최적화)라는 세 갈래를 한 번에 만족시키는 몇 안 되는 작업이기도 하다. 검색엔진에는 순위 판단의 근거를 주고, 답변형 AI에는 인용할 정확한 사실을 주고, 에이전트에는 실행할 행동을 준다. 세 목적이 갈라지지 않고 같은 코드 한 벌에서 출발한다는 점이, 이 작업을 우선순위 앞쪽에 둘 만한 이유이기도 하다.

AI 에이전트는 사람과 무엇이 다르게 홈페이지를 읽나?

사람은 화면 디자인, 색감, 배치를 눈으로 보고 판단한다. 반면 AI 에이전트는 화면을 보지 않고 HTML 코드와 텍스트, 속성값을 그대로 읽는다. 예쁘게 디자인됐어도 코드상으로 "이게 상품명인지, 가격인지, 그냥 장식 문구인지" 구분이 안 되면 에이전트는 잘못 읽거나 아예 건너뛴다. 이미지 안에 텍스트로 새겨 넣은 가격표가 대표적인 예다. 사람 눈에는 잘 보이지만, 에이전트에게는 그냥 그림 파일일 뿐이다.

이 과정은 크게 두 단계로 나뉜다. 첫째는 발견 단계다. 에이전트가 "이 페이지에 무엇이 있는지" 파악하는 과정으로, 구조화 데이터가 이 역할을 한다. 둘째는 행동 단계다. "이 페이지에서 무엇을 할 수 있는지" 판단하는 과정으로, 명확한 폼·버튼 설계와 최근 등장한 WebMCP 같은 실행 표준이 이 역할을 맡는다.

예를 들어보자. 어떤 사람이 에이전트에게 "27센티 발에 맞는, 10만 원대 재고 있는 러닝화 찾아서 장바구니에 담아줘"라고 요청했다고 하자. 에이전트는 먼저 구조화 데이터로 사이즈·가격·재고 여부가 표시된 상품을 찾아낸다(발견). 그다음 "장바구니 담기" 버튼이 정확히 무엇을 하는 버튼인지 코드로 확인한 뒤 클릭한다(행동). 결제까지 이어진다면 별도의 거래 표준이 관여하지만, 국내 대부분의 홈페이지·쇼핑몰에서는 앞의 두 단계만 제대로 갖춰도 충분하다.

병원이나 미용실 같은 예약형 업종도 원리는 같다. "이번 주 토요일 오후에 예약 가능한 미용실 찾아줘"라는 요청을 받은 에이전트는 영업시간·휴무일 정보(구조화 데이터)로 후보를 추린 다음, 예약 폼의 날짜·시간 선택 항목(행동)을 찾아 채운다. 영업시간이 이미지로만 안내돼 있거나, 예약 버튼이 자바스크립트 팝업으로만 동작해 코드상 의미가 드러나지 않으면 이 과정에서 에이전트가 멈춰 버린다.

구조화 데이터만 있고 폼·버튼이 불분명하면, 에이전트는 "이게 내가 찾던 상품(혹은 업체)"이라는 것까지는 알아도 정작 장바구니에 담거나 예약을 완료하지는 못한다. 발견과 행동은 세트로 챙겨야 한다.

구조화 데이터부터 제대로 넣으려면 어떻게 해야 할까?

답은 명확하다. schema.org 어휘를 JSON-LD 형식으로 작성해 페이지에 넣는 것이다. JSON-LD가 정확히 무엇인지는 이미 다룬 적이 있으니, 여기서는 에이전트가 실제로 참조하는 값 위주로 짚는다.

"우리 홈페이지는 이미 상품 설명을 자세히 써 놓았는데 굳이 필요할까"라고 생각할 수 있다. 하지만 사람이 읽는 문장과 기계가 참조하는 값은 다르다. "가격은 상담 후 결정됩니다"라는 문장은 사람에게는 자연스러워도, 에이전트에게는 숫자 필드가 비어 있는 것과 다르지 않다. 정확한 값을 정해진 자리에 넣어 줘야 에이전트가 다른 페이지의 값과 비교하거나 조건에 맞는지 판단할 수 있다.

상품·서비스를 판매하는 페이지라면 최소한 이름·가격·통화·재고 여부·평점이 정확한 값으로 채워져 있어야 한다. 나쁜 예는 이렇다.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "러닝화"
}

이름만 있고 가격·재고·통화 정보가 없다. 에이전트 입장에서는 "구매 가능한 상품인지, 얼마인지" 전혀 알 수 없어 아예 후보에서 제외해 버릴 수 있다. 좋은 예는 다음처럼 필요한 값을 빠짐없이 채운 형태다.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "경량 러닝화 270",
  "offers": {
    "@type": "Offer",
    "price": "129000",
    "priceCurrency": "KRW",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "212"
  }
}

가격·통화·재고 상태(availability)를 표준 값으로 정확히 채우는 것이 핵심이다. "품절"이라는 한글 텍스트만 있고 availability 값이 InStock으로 잘못 남아 있으면, 에이전트가 실제로는 살 수 없는 상품을 장바구니에 담으려다 오류를 겪을 수 있다. 재고나 가격이 자주 바뀌는 업종이라면, 관리자 화면에서 상품 정보를 수정할 때 이 값도 함께 갱신되는지 반드시 확인해야 한다.

업종별로 우선 챙길 스키마 타입도 다르다. 정리하면 다음과 같다.

업종	우선 스키마 타입	꼭 채울 값
병원·미용실·식당 등 동네 상권	LocalBusiness	주소, 전화번호, 영업시간, 휴무일
온라인 쇼핑몰	Product, Offer, AggregateRating	가격, 통화, 재고 상태, 평점
컨설팅·에이전시형 서비스	Service	제공 범위, 대상 지역, 문의 방법
블로그·콘텐츠 사이트	Article(BlogPosting)	작성일, 수정일, 저자
자주 묻는 질문이 있는 페이지	FAQPage	질문과 답변 텍스트

LocalBusiness를 쓴다면 주소·전화번호·영업시간을 텍스트로 명확히 밝혀야 한다. 매장 사진 안에 영업시간을 손글씨처럼 새겨 넣기만 하고 코드에는 값이 없다면, 에이전트는 "이 업체가 지금 문을 열었는지"조차 판단하지 못한다. FAQ 스키마 활용법은 AI가 인용하는 스키마 마크업 가이드에서 타입별로 더 자세히 다뤘다.

업종을 막론하고 홈페이지 전체에 걸쳐 챙길 스키마도 하나 있다. 사이트 최상위 정보를 밝히는 Organization이다.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "이루웹",
  "url": "https://iruweb.com",
  "logo": "https://iruweb.com/logo.png",
  "sameAs": ["https://www.instagram.com/iruweb"]
}

회사명·공식 URL·로고, 그리고 실제 운영 중인 SNS 계정 정도만 정확히 채워도 에이전트가 "이 사이트가 어떤 주체가 운영하는지"를 헷갈리지 않는다. 여기에 페이지 이동 경로를 알려 주는 BreadcrumbList까지 더하면, 에이전트가 지금 보고 있는 페이지가 전체 사이트에서 어디에 위치하는지도 함께 파악할 수 있다.

이 작업은 워드프레스나 아임웹·카페24 같은 빌더를 쓰고 있어도 대부분 플러그인이나 앱으로 처리할 수 있다. 다만 값을 실제 상품·서비스 정보와 정확히 일치시키는 확인 작업만큼은 사람이 직접 해야 한다. 자동 생성 플러그인이 기본값을 그대로 남겨 두는 경우가 의외로 많다.

어떤 플랫폼으로 홈페이지를 운영하는지에 따라 접근 순서가 조금씩 달라진다. 카페24·아임웹·식스샵처럼 국내 쇼핑몰 빌더는 상품 등록 화면 안에 스키마 자동 생성 기능을 기본 내장한 경우가 많아, 값을 정확히 입력하는 것만으로도 상당 부분이 자동으로 채워진다. 워드프레스는 관련 플러그인을 설치해야 하는 대신 원하는 스키마 타입을 세밀하게 조정하기 쉽다. 직접 제작한 자체 개발 홈페이지라면 개발자가 페이지 템플릿 안에 JSON-LD를 직접 심어야 해서 손이 더 가지만, 한 번 심어 두면 콘텐츠가 늘어나도 자동으로 값이 채워지도록 설계할 수 있다는 장점이 있다. 어떤 방식이든 목표는 같다. 관리자 화면에서 값을 한 번 입력하면, 사람이 보는 화면과 기계가 읽는 코드에 동시에 반영되는 구조를 만드는 것이다.

업종별로는 실제로 무엇부터 손대야 할까?

앞의 원칙을 업종별로 구체화하면 다음과 같다.

병원·미용실 같은 예약 기반 업체라면 가장 먼저 LocalBusiness 스키마의 영업시간·휴무일·전화번호를 실제 운영 상황과 일치시키는 것부터 시작한다. 명절·임시 휴진처럼 자주 바뀌는 정보는 관리자가 수정할 때마다 코드값도 함께 바뀌는지 확인해야 한다. 예약 폼은 날짜·시간·인원처럼 값이 정해진 항목일수록 <select>나 <input type="date"> 같은 표준 요소로 만들어 두는 편이 에이전트에게도, 사람에게도 오작동이 적다.

온라인 쇼핑몰은 상품 수가 많을수록 자동화가 중요하다. 상품 등록 화면에서 가격·재고·옵션을 입력하면 Product·Offer 스키마 값도 함께 갱신되도록 쇼핑몰 솔루션의 설정을 확인해야 한다. 품절 처리를 늦게 반영하면, 에이전트가 이미 팔린 상품을 장바구니에 담으려다 실패하는 경험을 이용자에게 그대로 넘겨주게 된다.

학원·컨설팅처럼 상담·문의가 핵심인 서비스형 업체는 Service 스키마로 제공 범위와 대상 지역을 명확히 밝히고, 문의 폼의 각 입력창에 "이름", "연락처", "상담 희망 분야"처럼 실제 목적이 드러나는 레이블을 붙이는 것이 우선이다. 여러 지점을 운영한다면 지점마다 별도 페이지와 스키마를 두는 편이 에이전트가 "어느 지점 이야기인지" 헷갈리지 않는다.

블로그·콘텐츠 중심 사이트는 Article(BlogPosting) 스키마에 작성일·수정일·저자를 정확히 넣는 것만으로도 상당 부분 준비가 끝난다. 정보가 오래돼도 수정일을 갱신하지 않고 방치하면, 에이전트가 최신 정보인지 판단하기 어려워진다는 점도 함께 기억해 두면 좋다.

폼과 버튼은 에이전트가 실수 없이 채우게 설계했나?

이 질문에 대한 답은 하나다. 버튼과 입력창의 이름표(레이블)가 실제 기능을 그대로 드러내야 한다. 사람은 디자인과 배치, 아이콘만 보고도 "이건 검색창이구나" 짐작하지만, 에이전트는 <label>이나 name, aria-label 같은 속성값을 읽고 판단한다.

나쁜 예는 이런 식이다.

<input type="text" placeholder="입력">
<button>버튼1</button>

무엇을 입력하라는 건지, 버튼을 누르면 무슨 일이 일어나는지 코드만 봐서는 전혀 알 수 없다. placeholder는 입력 중 사라지는 안내 문구일 뿐, 레이블 역할을 제대로 대신하지 못한다는 점도 놓치기 쉬운 부분이다. 좋은 예는 다음과 같다.

<label for="phone">연락처</label>
<input id="phone" name="tel" type="tel" autocomplete="tel" required>
<button type="submit">상담 신청하기</button>

레이블(label)과 입력 항목이 for·id로 연결되고, name·autocomplete 속성이 실제 의미(전화번호)와 일치하며, 버튼 문구가 "제출"이 아니라 "상담 신청하기"처럼 행동을 그대로 드러낸다. 이렇게 만들어 두면 사람에게는 자동완성 편의가 생기고, 에이전트에게는 오작동 없이 정확히 채울 수 있는 근거가 생긴다.

예약 페이지의 날짜·시간 선택도 마찬가지다. 달력을 이미지로 그려 넣고 자바스크립트로만 클릭을 처리하면, 에이전트는 어떤 날짜가 선택 가능한지 구분하기 어렵다. 반대로 <select>나 표준 <input type="date"> 요소로 만들어 두면, 선택 가능한 값과 비활성 값이 코드에 그대로 드러나 에이전트도 사람과 똑같이 정확히 고를 수 있다.

한 걸음 더 나아간 표준도 등장했다. WebMCP(Web Model Context Protocol)는 웹사이트가 navigator.modelContext라는 브라우저 API를 통해 자기 기능을 "호출 가능한 도구"로 직접 노출하는 방식이다. 크롬 146 버전(2026년 2월)부터 공개 오리진 트라이얼로 실험 중이며, 화면을 캡처해서 분석하는 기존 방식보다 훨씬 적은 정보량으로도 에이전트가 정확히 동작할 수 있다는 점이 특징으로 꼽힌다.

개념적으로는 버튼 하나에 "이름"과 "설명"을 함께 등록해 두는 방식에 가깝다. 예를 들어 예약 확정 버튼이라면 "이 도구는 선택된 날짜·시간으로 예약을 확정한다"는 설명을 코드 차원에서 미리 선언해 두는 식이다. 지금의 label·name 속성을 정교하게 다듬는 작업의 연장선으로 이해하면 크게 어렵지 않다.

다만 WebMCP는 아직 크롬 한 브라우저의 실험 단계다. 지금 당장 전면 도입할 기술이라기보다, HTML 표준 폼과 레이블부터 정확히 갖춘 다음 지켜볼 대상에 가깝다.

llms.txt 같은 "AI 전용 파일"도 꼭 만들어야 할까?

결론부터 말하면 급하게 만들 필요는 없다. llms.txt는 사이트 개요와 핵심 페이지를 마크다운으로 정리해 /llms.txt 경로에 올려 두는 파일인데, 2026년 기준 실제 채택률은 전체 사이트의 10퍼센트 안팎에 머물러 있고, 구글은 llms.txt가 현재 검색 결과에 직접 쓰이지 않는다고 공식적으로 밝힌 바 있다.

그렇다고 아예 무의미한 것은 아니다. 사이트 개요·서비스·블로그 목록을 정리해 두는 작업 자체는 30분 안팎이면 끝나는 가벼운 작업이라, 여유가 있다면 "혹시 몰라 준비해 두는" 보험 정도로 생각하면 된다. 순위나 노출을 위한 필수 조치로 오해해 우선순위를 높게 잡을 필요는 없다는 뜻이다.

전자상거래 플랫폼을 직접 운영한다면 .well-known/mcp.json도 참고할 만하다. 에이전트가 사이트의 기능 목록을 한눈에 파악하도록 돕는 일종의 "에이전트용 사이트맵" 개념으로, 일부 대형 쇼핑 플랫폼이 실제로 적용을 시작한 단계다. 마이크로소프트가 선보인 NLWeb처럼, 이미 갖춰 둔 schema.org 구조화 데이터를 그대로 질문-답변 기능의 기반으로 재활용하는 방식도 나오고 있다. 이 대목에서도 결국 출발점은 같다. 구조화 데이터를 정확히 갖춰 두면, 이후 어떤 새 표준이 등장해도 다시 활용할 수 있는 자산이 된다.

다만 이 역시 표준화가 진행 중이라, 국내 중소형 홈페이지라면 지금 단계에서는 구조화 데이터와 폼 정비를 먼저 마치는 편이 투자 대비 효과가 크다. 새 표준이 나올 때마다 전부 따라가려 하기보다, 기본기가 튼튼하면 대부분 자연스럽게 대응된다는 뜻이다.

지금 당장 할 일과 나중으로 미뤄도 되는 일은 어떻게 나누나?

우선순위를 세 단계로 나누면 헷갈리지 않는다.

지금 당장(1단계): 핵심 페이지의 schema.org 마크업 점검, 폼·버튼 레이블 정비, robots.txt에서 AI 크롤러를 실수로 차단하지 않았는지 확인한다. 대부분 홈페이지가 이미 갖춰야 하는 기본 SEO와 겹치는 항목이라, 별도 예산 없이도 시작할 수 있다. 구체적으로는 아래 항목부터 순서대로 확인하면 된다.

• 홈·상품(서비스)·문의 페이지에 알맞은 schema.org 타입이 들어가 있는가.
• 가격·재고·영업시간처럼 자주 바뀌는 값이 실제 상황과 일치하는가.
• 모든 입력창에 label이 연결돼 있고, placeholder에만 의존하고 있지 않은가.
• 버튼 문구가 "제출"·"확인" 대신 실제 행동("상담 신청하기", "장바구니 담기")을 드러내는가.
• 핵심 정보(가격표·영업시간·연락처)가 이미지에만 텍스트로 박혀 있지 않은가.
• robots.txt가 GPTBot·PerplexityBot 같은 AI 크롤러를 실수로 막고 있지 않은가.

이 여섯 가지는 대부분 하루 이틀, 페이지 수가 많아도 한두 주 안에 마칠 수 있는 점검이다. 외부 도구나 별도 예산 없이 관리자 화면과 코드만 살펴봐도 상당 부분 해결된다.

여유 있을 때(2단계): llms.txt 작성, 전자상거래라면 .well-known/mcp.json 검토, FAQ 페이지에 FAQPage 스키마 보강 같은 작업이다. 이 단계는 1단계처럼 시급하지는 않지만, 콘텐츠나 상품 수가 많은 사이트일수록 투자 대비 효과가 조금씩 커지는 영역이다.

지켜보며 대응(3단계): WebMCP 같은 실행 표준, 여러 에이전트가 서로 통신하는 프로토콜은 아직 브라우저 한두 곳의 실험 단계다. 표준이 자리 잡는 흐름을 지켜보다가, 우리 업종에서 실제 사례가 쌓이면 그때 검토해도 늦지 않다. 지금 미리 적용해 두더라도 표준 자체가 바뀌면 다시 손봐야 할 가능성이 크므로, 서두른다고 유리할 것이 없는 영역이기도 하다.

이렇게 단계를 나눠 보면, 사실 1단계만 제대로 해도 대부분의 실질적 효과는 이미 얻는다는 것을 알 수 있다. 2·3단계는 여력이 생겼을 때, 혹은 업종 특성상 필요성이 뚜렷할 때 순서대로 접근하면 된다.

에이전트가 실제로 우리 사이트를 방문하는지는 어떻게 확인하나?

가장 간단한 방법은 서버 접속 기록(로그)에서 사용자 에이전트(User-Agent) 값을 확인하는 것이다. 사람이 쓰는 일반 브라우저와 달리, AI 에이전트나 크롤러는 자신을 밝히는 고유한 이름을 요청 헤더에 남긴다. GPTBot, PerplexityBot, ClaudeBot처럼 이름 자체에 서비스가 드러나는 경우가 많아, 호스팅사의 접속 로그나 애널리틱스 도구에서 해당 문자열을 검색해 보면 방문 여부를 대략 확인할 수 있다.

방문 기록이 전혀 잡히지 않는다면 두 가지를 의심해 봐야 한다. 하나는 robots.txt에서 해당 크롤러를 차단해 둔 경우고, 다른 하나는 아직 그 에이전트 서비스 자체의 이용자가 우리 업종·지역에서 활발하지 않은 경우다. 반대로 방문 기록은 있는데 실제 문의나 예약으로 이어지지 않는다면, 이 글에서 다룬 구조화 데이터나 폼 설계에서 에이전트가 막히고 있을 가능성을 점검해 볼 신호로 삼을 수 있다. 로그 확인은 어디까지나 첫 단계이고, 노출·인용 현황을 본격적으로 추적하는 전용 도구와 지표는 별도로 다룰 만큼 폭이 넓은 주제이므로 이 글에서는 시작점만 짚어 둔다.

보안·법적 이슈도 함께 알아둬야 할까?

에이전틱 브라우저는 아직 초기 기술이라, 관련 보안·법적 이슈도 함께 다뤄지고 있다는 점은 참고해 둘 만하다. 새 기술이 빠르게 퍼질 때 흔히 겪는 성장통에 가깝지만, 결제나 개인정보처럼 민감한 영역을 다룬다면 사업자 입장에서도 알아 둬야 한다.

2026년 3월 보안업체 제니티랩스(Zenity Labs)가 에이전틱 브라우저의 취약점을 공개했고, 같은 해 7월 워싱턴대학교 연구에서는 일부 브라우저가 동일출처정책(같은 출처의 데이터만 접근하도록 막는 웹 보안 원칙)을 우회할 수 있다는 사실이 확인됐다.

법적 분쟁도 진행 중이다. 아마존과 퍼플렉시티 간 소송에서 2026년 3월 10일 법원이 코멧의 아마존 계정 접근을 제한하는 가처분명령을 내렸고, 항소심에서도 이 결정이 유지됐다. 이후 6월 11일 제9순회항소법원에서 구두 변론이 진행됐다.

이런 소식을 접하고 지레 겁먹을 필요는 없다. 표준과 판례가 아직 자리를 잡아가는 과정일 뿐, 구조화 데이터를 정비하고 폼을 명확히 만드는 기본 작업의 가치가 줄어드는 것은 아니다. 다만 결제·계정 접근처럼 민감한 기능을 에이전트에게 통째로 맡기는 자동화는, 표준이 좀 더 자리 잡을 때까지 신중하게 접근하는 편이 안전하다. 예를 들어 결제 완료 전 사람의 최종 확인을 한 단계 거치게 만드는 정도의 안전장치는 지금도 충분히 적용할 수 있다.

새로운 기술을 막연히 경계할 필요도, 무조건 서둘러 도입할 필요도 없다. 표준이 자리 잡는 속도에 맞춰 단계적으로 따라가는 것으로 충분하다.

이런 보안·법적 이슈는 대부분 "에이전트에게 결제나 계정 접근 권한을 얼마나 넘길 것인가"라는 지점에서 발생한다. 반대로 이 글에서 다룬 구조화 데이터·폼 명확화 작업은 정보를 정확히 드러내는 것이 목적이라 위험 요소가 거의 없다. 두 영역을 분리해서 생각하면, 어디까지는 지금 바로 해도 되고 어디부터는 신중해야 하는지 판단이 한결 쉬워진다.

자주 묻는 질문

에이전틱 브라우저 대응을 꼭 지금 서둘러야 하나요?

전면 개편을 서두를 필요는 없다. 구조화 데이터를 정확히 채우고 폼·버튼 레이블을 명확히 하는 작업은 원래 좋은 SEO의 기본기와 겹치는 부분이 많아, 지금 시작해도 낭비가 아니다.

챗GPT 아틀라스가 없어지면 그동안 준비한 게 헛수고 아닌가요?

아니다. 브라우저 하나의 형태만 바뀔 뿐, 구조화 데이터와 명확한 폼이라는 준비는 퍼플렉시티 코멧이든 크롬의 제미나이 오토브라우즈든 어떤 에이전트가 와도 그대로 유효하다.

워드프레스나 아임웹 같은 빌더에서도 구조화 데이터를 넣을 수 있나요?

대부분 가능하다. 플러그인이나 앱으로 기본 스키마를 자동 생성해 주는 경우가 많지만, 가격·재고 같은 실제 값이 정확히 반영되고 있는지는 별도로 확인해야 한다.

WebMCP는 지금 바로 도입해야 하는 기술인가요?

아직은 아니다. 크롬 한 브라우저에서 오리진 트라이얼로 실험 중인 단계이므로, 지금은 표준 HTML 폼과 레이블부터 정확히 갖추고 지켜봐도 충분하다.

우리 업종은 쇼핑몰도, 예약도 아닌 소개형 홈페이지인데도 대응이 필요한가요?

필요하다. 회사 소개, 서비스 설명, 오시는 길, 문의 폼처럼 정보 전달형 페이지도 에이전트가 "어떤 회사인지, 어떻게 연락할 수 있는지"를 정확히 읽어야 하기 때문이다. Organization이나 LocalBusiness 스키마와 명확한 문의 폼만 갖춰도 충분한 경우가 많다.

구조화 데이터를 넣으면 순위가 바로 오르나요?

구조화 데이터 자체가 순위를 직접 끌어올리는 요소는 아니다. 다만 검색엔진과 AI 에이전트 모두가 페이지 내용을 정확히 이해하도록 돕는 기초 작업이라, 콘텐츠 품질·사용자 경험 같은 다른 요소와 함께 갖춰야 장기적으로 효과가 쌓인다. 단기간에 순위를 올려 주는 마법 같은 장치로 오해하지 않는 편이 좋다.

이미 SEO 최적화를 해 뒀다면 추가로 뭘 더 해야 하나요?

일반적인 SEO(제목·설명 태그, 내부 링크, 콘텐츠 품질)를 이미 잘 갖췄다면 절반은 끝난 셈이다. 여기에 이 글에서 다룬 schema.org 값의 정확도와 폼·버튼 레이블의 명확성만 추가로 점검하면 된다. 완전히 새로운 작업이라기보다, 기존 SEO 체크리스트에 "기계가 읽고 행동하기에도 충분한가"라는 항목을 하나 더 얹는다고 생각하면 된다.

이 작업을 직접 하기 어렵다면 어떻게 시작해야 하나요?

개발 지식이 없어도 우선순위 1단계 정도는 관리자 화면에서 값을 정확히 채우는 수준으로 시작할 수 있다. 다만 스키마 코드를 직접 심거나 폼 구조를 손봐야 하는 부분은 개발자나 전문 업체의 손을 거치는 편이 안전하다. 잘못 작성된 스키마는 없느니만 못한 경우도 있어서, 값을 채운 뒤에는 반드시 실제로 페이지에 정확히 반영됐는지 확인하는 절차가 필요하다.

에이전틱 브라우저는 이제 막 자리를 잡아가는 흐름이라, 앞으로도 세부 대응법은 계속 바뀔 가능성이 큽니다. 우리 홈페이지가 사람에게도, AI 에이전트에게도 정확히 읽히고 있는지 점검이 필요하시다면 이루웹의 홈페이지 제작 상담에서 구조화 데이터부터 폼 설계까지 함께 살펴봐 드리겠습니다. 이루웹의 다른 서비스도 확인해 보시고, 궁금한 점이 있으시면 언제든 문의 주시면 성실히 답해 드리겠습니다.