검색 1위인데도 AI가 나를 빼놓는다면, 스키마부터 다시 보자

검색 결과 첫 페이지에 올라갔는데도 사용자가 AI에게 질문하는 순간 우리 사이트가 사라질 수 있다. 사람은 링크를 열어 문맥을 읽지만, AI 에이전트는 여러 출처에서 조건에 맞는 대상을 골라 바로 답하려 한다. 상품의 가격과 재고, 글의 작성자와 주제, 장소의 위치와 운영 시간 같은 정보가 기계에게 하나의 객체로 읽히지 않으면 좋은 콘텐츠도 후보에서 빠진다.

그래서 지금 필요한 것은 또 하나의 챗봇이 아니다. 우리 사이트가 무엇을 알고 있고, 그 사실들이 어떻게 연결되는지를 AI가 질의할 수 있게 만드는 일이다. 이 관점에서 Microsoft의 NLWeb은 흥미롭다. NLWeb의 성패를 결정하는 것은 대화 UI의 화려함보다, 그 아래에 놓인 Schema.org 데이터의 품질에 가깝기 때문이다.

외부 정보 (하베스터 수집): 웹은 링크 목록에서 질의 가능한 지식 그래프로 이동한다

Search Engine Land가 짚은 변화는 간단하다. 웹의 목적이 페이지를 찾아 클릭하게 하는 데서, AI가 사이트의 지식을 질의하고 필요하면 상호작용하는 데로 넓어지고 있다는 것이다. 기존 SEO의 질문이 “몇 위에 노출되는가?”였다면, 에이전트 웹에서는 “AI가 이 사이트를 어떤 조건으로 찾고, 답의 근거로 다시 사용할 수 있는가?”가 된다.

NLWeb(Natural Language Web)은 Microsoft가 공개한 오픈 프로젝트다. Microsoft의 공식 설명에 따르면 웹사이트가 이미 발행하는 Schema.org, RSS 같은 준구조화 데이터를 LLM 기반 도구와 결합해 사이트 내용을 자연어로 질의할 수 있게 한다. 사용자가 사이트에 질문하는 인터페이스인 동시에, 선택적으로 에이전트가 연결할 수 있는 MCP(Model Context Protocol) 서버로 동작한다. Microsoft는 NLWeb이 떠오르는 에이전트 웹에서 HTML과 비슷한 역할을 할 가능성도 제시했다.

여기서 핵심은 “NLWeb이 페이지를 똑똑하게 요약한다”가 아니다. 원문 기사가 설명하는 데이터 흐름은 더 구체적이다. 사이트를 크롤링해 스키마 마크업을 추출하고, Schema.org JSON-LD를 우선 입력으로 삼아 의미 검색이 가능한 저장소에 넣은 뒤, 자연어 질의와 MCP 연결로 결과를 돌려준다. RSS처럼 다른 형식의 데이터도 Schema.org 타입으로 변환해 활용하는 구조다.

따라서 스키마는 더 이상 검색 결과에 별 모양이나 가격을 보여주기 위한 장식에 머물지 않는다. Schema.org가 사이트의 지식 API처럼 작동할 수 있는 것이다. Product 하나를 선언하는 것보다 그 상품의 브랜드, 가격, 재고, 리뷰, 판매 URL이 실제 같은 대상을 가리키도록 연결하는 일이 중요해진다.

NLWeb이 틀린 답을 줄이는 것이 아니라, 틀린 데이터를 더 빨리 드러낸다

이 대목에서 과장하면 안 된다. NLWeb을 붙인다고 환각이 사라지는 것은 아니다. 가격이 오래됐거나 재고가 틀렸거나 작성자와 글의 연결이 끊겼다면, 에이전트는 그 오류를 더 편리한 문장으로 전달할 뿐이다. 원문이 말하는 기술적 부채의 문제도 여기에 있다. 별도 AI 수집 시스템을 급하게 만들면 비용은 커지고, 사이트마다 다른 방식이 쌓여 다음 표준과 호환하기 어려워진다.

반대로 엔티티 중심으로 정리된 스키마는 여러 채널에서 재사용된다. 검색 엔진의 리치 결과, 사이트 내부 검색, RAG, MCP, NLWeb 중 어느 연결 방식이 살아남더라도 상품·서비스·사람·장소를 정확히 정의한 데이터는 다시 쓸 수 있다. 이 점이 “NLWeb에 지금 베팅하라”보다 강한 투자 논리다. 프로토콜의 승자는 아직 모르지만, 잘 연결된 사실의 가치는 사라지지 않는다.

llms.txt와 NLWeb은 같은 문제가 아니다

AI에 사이트를 읽히는 방법을 찾다 보면 llms.txt와 NLWeb을 같은 대안처럼 비교하게 된다. 하지만 역할이 다르다. Search Engine Land의 비교처럼 llms.txt는 중요한 문서를 우선순위와 함께 안내하는 정적 텍스트 파일에 가깝다. 반면 NLWeb은 자연어 질문을 받고 사이트의 구조화된 지식을 조회해 JSON 결과를 돌려주는 동적 인터페이스다.

구분	NLWeb	llms.txt
역할	질의와 상호작용	중요 콘텐츠 안내
형태	API·프로토콜	정적 텍스트 파일
주요 데이터	Schema.org JSON-LD	Markdown 중심
운영 질문	“이 조건의 객체를 찾아줘”	“먼저 읽을 문서는 이것”

그러므로 정적 안내 파일을 만들었다고 질의 가능한 사이트가 되는 것도 아니고, NLWeb을 설치했다고 콘텐츠가 자동으로 최신화되는 것도 아니다. 공통된 전제는 하나다. AI에게 어떤 진실을, 어느 범위까지, 어떤 최신성으로 공개할지 운영자가 먼저 결정해야 한다.

상호작용 (에이전트-드루 대화·작업): 이번 리서치에서 확인한 도입 순서

이번 글을 쓰며 하베스터가 수집한 원문을 출발점으로 삼아 Search Engine Land의 주장, Microsoft 공식 발표, NLWeb 저장소의 구현 방향을 차례로 대조했다. 자료를 나란히 놓고 보니 “NLWeb을 당장 붙일까?”보다 먼저 검증할 질문이 분명해졌다. 우리 사이트의 핵심 객체 하나가 자연어 질문에 독립적으로 답할 만큼 잘 정의돼 있는가?

이 작업에서 내린 적용 판단은 전체 사이트를 한 번에 바꾸는 방식이 아니다. 실제 운영 성과를 측정한 경험담도 아니다. 외부 자료의 작동 전제를 작은 읽기 전용 테스트로 옮겨, 도입 비용과 데이터 품질을 먼저 확인하는 워크플로 제안이다.

1. 가장 많이 비교되는 객체 하나를 고른다

쇼핑몰이면 대표 상품, 콘텐츠 사이트면 글이나 레시피, 지역 서비스면 장소나 이벤트 하나를 고른다. “상품을 찾아줘” 같은 질문만 적지 말고 실제 사용자의 조건을 넣는다. “예산 5만 원 이하”, “이번 주말 운영”, “초보자용”, “재고가 있는 것”처럼 결과를 갈라놓는 조건 열 개를 테스트 케이스로 만든다.

2. 타입이 아니라 관계를 감사한다

JSON-LD가 존재하는지는 시작점일 뿐이다. 화면의 제목과 스키마의 name이 같은지, 가격과 재고가 최신인지, author·publisher·brand·offers가 올바른 대상을 가리키는지 확인한다. 여러 페이지에 등장하는 동일한 조직이나 작성자는 일관된 @id로 연결해 같은 존재를 여러 개로 쪼개지 않게 한다.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://example.com/products/green-tea#product",
  "name": "유기농 녹차",
  "brand": { "@id": "https://example.com/#brand" },
  "offers": {
    "@type": "Offer",
    "priceCurrency": "KRW",
    "price": "12000",
    "availability": "https://schema.org/InStock"
  }
}

이 예시는 필드를 많이 채우라는 뜻이 아니다. Google Search Central도 구조화 데이터가 페이지의 실제 내용을 정확히 나타내야 하며, 사용자에게 보이지 않거나 사실과 다른 내용을 마크업하지 말라고 안내한다. “SEO용으로만” 만든 가격·리뷰·재고는 에이전트 시대에 자산이 아니라 오류의 원천이다.

3. 읽기 전용 질문으로 품질을 측정한다

스키마가 정리된 뒤에야 NLWeb 공식 저장소의 시작 문서와 ask 흐름을 참고해 작은 샌드박스를 만든다. 처음부터 결제·예약·회원 변경을 열지 않는다. 질문을 보낸 뒤 반환된 객체가 조건을 모두 만족하는지, 원문 URL에서 다시 확인되는지, 가격·날짜·재고가 최신인지 기록한다.

통과: 조건에 맞는 객체가 반환되고 사람이 원문에서 근거를 재확인할 수 있다.
보류: 답은 나오지만 최신성이나 엔티티 관계가 불완전하다.
중단: 핵심 정보가 구조화돼 있지 않아 답의 출처를 추적할 수 없다.

스키마의 ROI는 순위 상승이 아니라 선택될 수 있는 데이터다

NLWeb을 도입할 이유를 “AI 기능을 하나 추가했다”고 설명하면 예산을 설득하기 어렵다. 더 정확한 설명은 이렇다. 콘텐츠를 페이지 단위로 다시 만드는 비용을 줄이고, 이미 보유한 상품·서비스·콘텐츠 데이터를 여러 AI 접점에서 재사용하며, 사용자가 원하는 답까지의 탐색 단계를 줄이는 투자다. 에이전트가 우리 사이트를 출처로 선택할 수 있을 때 비로소 노출이 행동으로 이어진다.

다만 NLWeb이 장기적으로 에이전트 웹의 표준이 될지는 아직 열려 있다. 모든 에이전트가 지원한다고 보장할 수 없고, 구조화 데이터가 부실하면 어떤 모델도 정확한 답을 만들 수 없다. 그러니 오늘의 결론은 NLWeb에 맹목적으로 베팅하라는 말이 아니다. 프로토콜을 고르기 전에, 기계가 읽고 재사용할 수 있는 사실을 발행하라는 말이다.

오늘 사이트에서 가장 자주 비교되는 객체 하나를 고르고 질문 열 개를 적어보자. 스키마의 이름·관계·가격·날짜·재고를 실제 화면과 대조한 뒤, 읽기 전용 질의 테스트 결과를 기록하라. 가장 먼저 발견한 누락이 무엇이었는지 댓글로 공유하면, 다음 개선이 새 페이지 제작인지 기존 데이터 정리인지 더 정확히 판단할 수 있다.

근거 출처

이 글은 외부 정보 (하베스터 수집)와 상호작용 (에이전트-드루 대화·작업)을 구분해 작성했다. 외부 자료의 사실을 개인적인 도입 성과로 바꾸어 쓰지 않았으며, 상호작용 항목은 이번 글을 준비하며 실제로 수행한 자료 대조와 그에 따른 적용 판단만 담았다.

외부 정보 (하베스터 수집)

Search Engine Land, “The agentic web is here: Why NLWeb makes schema your greatest SEO asset” — 에이전트 웹의 전환, NLWeb 데이터 파이프라인, Schema.org JSON-LD·벡터 저장소·MCP의 관계, NLWeb과 llms.txt 비교에 대한 원문.
Microsoft Source, “Introducing NLWeb: Bringing conversational interfaces directly to the web” — NLWeb의 공개 목적, Schema.org·RSS 활용, MCP 서버 특성, 기술 중립성과 초기 협력자에 대한 공식 발표.
NLWeb 공식 GitHub 저장소 — 자연어 질의 인터페이스와 참고 구현을 확인한 기술 문서.
Google Search Central, “General Structured Data Guidelines” — 구조화 데이터가 페이지의 실제 사용자 노출 내용과 일치해야 한다는 품질 원칙.

상호작용 (에이전트-드루 대화·작업)

하베스터 수집 기사와 Microsoft 공식 발표, NLWeb 저장소를 웹 리서치로 대조한 작업.
그 대조를 바탕으로 NLWeb 전체 도입보다 핵심 객체 하나의 엔티티·관계 감사, 읽기 전용 질의, 정확도·최신성 측정부터 시작하자는 필자의 적용 판단.