검색 결과에 오르는 것만으로는 부족하다. 이제 AI가 당신의 사이트를 ‘답’으로 고를 수 있어야 한다

사람이 검색창에 질문하고 사이트를 클릭하던 시대에는 방문자를 설득할 페이지를 만들면 됐다. 하지만 사용자가 “30분 안에 만들 수 있는 고단백 채식 저녁 메뉴를 찾아줘”라고 AI 에이전트에게 부탁하는 순간, 게임의 규칙이 달라진다. 에이전트는 홈페이지를 천천히 읽지 않는다. 여러 사이트의 정보를 비교하고, 조건에 맞는 결과를 골라, 사용자의 다음 행동까지 이어간다. 당신의 사이트가 검색 결과에 보이는지는 출발점일 뿐이다. AI가 읽고, 이해하고, 선택할 수 있는 데이터인가가 더 직접적인 질문이 된다.

NLWeb(Natural Language Web)은 이 문제를 “사이트마다 별도의 AI 연동을 만들자”가 아니라 “웹사이트가 자연어로 질문받을 수 있는 공통 인터페이스를 열자”는 방향으로 푼다. 아직 승자가 정해진 완성형 웹 표준은 아니다. 그럼에도 지금 살펴볼 가치가 있는 이유는 분명하다. NLWeb은 새로운 콘텐츠를 억지로 생성하는 도구가 아니라, 이미 가진 구조화 데이터와 콘텐츠를 에이전트가 사용할 수 있는 경로로 바꾸는 오픈 프로젝트이기 때문이다.

이 글의 사실과 사례는 외부 정보(하베스터 수집)를 바탕으로 정리했다. 개인적인 도입 성과나 에이전트-드루 작업 경험을 사실처럼 섞지 않고, 외부 자료에서 확인되는 내용과 그에 대한 적용 제안을 분리한다.

웹페이지를 읽는 에이전트보다, 질문받는 웹사이트가 훨씬 효율적이다

Yoast가 설명하는 에이전틱 웹의 핵심 전환은 검색에서 위임으로(from searching to delegating)다. 지금까지 사용자는 상품을 찾고, 여러 페이지를 열고, 가격과 조건을 비교하고, 폼을 작성했다. 앞으로는 그 중 일부를 에이전트에게 맡길 수 있다. 사용자의 역할은 내비게이터에서 의사결정자로 이동한다.

이 변화는 “챗봇을 홈페이지에 붙이면 된다”는 뜻이 아니다. 챗봇은 보통 자기에게 주어진 문서나 검색 결과를 바탕으로 답한다. 반면 에이전틱 웹의 사이트는 스스로 쿼리되는 엔드포인트가 된다. 사이트가 무엇을 제공하는지, 어떤 조건으로 찾을 수 있는지, 결과를 어떤 형식으로 돌려줄 수 있는지를 기계가 예측할 수 있어야 한다.

여기서 가장 중요한 준비물은 화려한 대화 UI가 아니다. 상품은 상품답게, 레시피는 레시피답게, 이벤트는 이벤트답게 설명하는 구조다. Schema.org 같은 어휘와 RSS, JSON-LD 등 이미 웹에서 쓰이는 준구조화 포맷이 에이전트에게는 공통 언어 역할을 한다. 페이지가 사람에게 읽기 좋다는 사실과, 데이터가 기계가 처리하기 좋다는 사실은 겹치지만 동일하지 않다.

NLWeb이 웹사이트의 구조화 데이터와 자연어 질의를 연결하는 과정을 보여주는 다이어그램
NLWeb은 자연어 질의를 사이트의 구조화 데이터와 연결하는 대화 레이어를 지향한다. 이미지 출처: Yoast.

NLWeb은 정확히 무엇을 제공하나

Microsoft는 2025년 5월 NLWeb을 웹사이트에 자연어 인터페이스를 추가하기 쉽게 만드는 오픈 프로젝트로 소개했다. 사이트 운영자는 자기 데이터와 선택한 모델을 사용해 콘텐츠를 AI 앱처럼 질의할 수 있다. Microsoft의 공식 설명에서 특히 눈에 띄는 부분은 NLWeb 인스턴스가 MCP(Model Context Protocol) 서버로도 동작한다는 점이다. 즉, 같은 자연어 API를 사람용 인터페이스와 에이전트용 연결에 함께 활용하는 구상이다.

공식 NLWeb 저장소의 README는 이를 두 층으로 설명한다. 첫째는 사이트에 자연어로 질문하고 Schema.org 형식의 JSON 응답을 받는 프로토콜이다. 둘째는 제품·레시피·장소·리뷰처럼 구조화된 목록을 이미 가진 사이트에 대화형 인터페이스를 붙이는 참고 구현이다. 이 구분이 중요하다. NLWeb은 “LLM이 아무 페이지나 읽고 그럴듯한 답을 만들어내는 마법”이 아니라, 사이트가 제공하는 데이터의 형태를 에이전트가 안정적으로 소비하도록 돕는 인터페이스에 가깝다.

프로토콜의 핵심 개념은 자연어 질의를 받는 ask다. 개념적으로는 다음과 같은 요청이다.

POST /ask
{
  "query": {
    "text": "30분 안에 만들 수 있는 고단백 채식 레시피를 찾아줘"
  },
  "prefer": {
    "mode": "list, summarize"
  }
}

응답은 단순한 자유 형식 문장만이 아니라, 결과의 타입과 속성을 포함하는 JSON으로 설계된다. 레시피라면 이름, 조리 시간, 재료 같은 필드가 Recipe라는 의미와 함께 돌아올 수 있다. 질문이 모호하면 추가 정보를 요청하는 응답을 보낼 수도 있고, 오래 걸리는 작업이라면 나중에 확인할 수 있는 비동기 결과를 반환할 수도 있다. 에이전트 입장에서는 사이트마다 버튼 위치를 새로 학습하는 대신, 질문하고 예측 가능한 결과를 받는 흐름을 사용할 수 있다.

다만 NLWeb을 MCP와 혼동하면 안 된다. MCP는 에이전트가 외부 도구와 데이터에 연결되는 방식을 다루고, NLWeb은 웹사이트가 자연어로 콘텐츠와 기능을 노출하는 데 초점을 둔다. NLWeb이 MCP 서버로 동작할 수 있다는 것은 이 둘을 연결하는 선택지가 생긴다는 뜻이지, 모든 웹사이트가 자동으로 에이전트의 거래 대상이 된다는 뜻은 아니다.

이 도구를 도입할 때 얻는 이득은 ‘AI 기능 추가’보다 구체적이다

NLWeb 도입을 “우리도 AI 검색을 넣었다고 말할 수 있다”는 홍보 프로젝트로 시작하면 금방 막힌다. 실제 이득은 다음 세 가지 운영 문제를 줄이는 데 있다.

  • 연동 비용을 줄인다. 사이트마다 특정 에이전트용 플러그인을 따로 만드는 대신, 자연어 질의와 구조화된 응답이라는 공통 접점을 준비할 수 있다. 생태계가 커질수록 한 번 만든 인터페이스의 재사용 가치가 커진다.
  • 답변의 근거를 사이트 데이터에 묶는다. LLM에게 페이지를 통째로 요약시키는 방식보다, 사이트가 관리하는 객체와 속성을 직접 반환하는 편이 “무엇을 근거로 골랐는가”를 확인하기 쉽다. 물론 이것이 환각과 오류를 자동으로 제거한다는 뜻은 아니다. 원천 데이터가 오래됐거나 잘못됐으면 에이전트도 틀린다.
  • 콘텐츠를 여러 접점에서 재사용한다. 같은 상품·레시피·이벤트 데이터가 사람이 보는 페이지, 사이트 내부 검색, 자연어 UI, 외부 에이전트 연결에 함께 쓰일 수 있다. 새 채널이 생길 때마다 콘텐츠를 다시 작성하는 대신 데이터 레이어를 개선하게 된다.

결국 NLWeb은 콘텐츠 팀과 개발 팀 사이의 우선순위도 바꾼다. “페이지를 더 많이 만들자”에서 “핵심 객체를 더 명확하게 정의하자”로 이동한다. 사용자가 어떤 질문을 하든 답을 길게 쓰는 것이 목표가 아니다. 에이전트가 한 개의 결과 객체를 꺼내도 이름, 조건, 가격, 시간, 출처가 충분히 이해되도록 만드는 것이 목표다.

지금 당장 NLWeb을 설치하기보다, 세 단계로 도입 가능성을 검증하라

이 절은 외부 자료에서 확인한 NLWeb의 작동 전제를 실제 운영 워크플로에 옮기기 위한 필자의 적용 제안이다. 아래 순서는 특정 서비스의 공식 도입 절차가 아니라, 작은 범위에서 비용과 효과를 확인하기 위한 검증 순서다.

1. 가장 자주 묻는 객체 하나를 고른다

처음부터 전체 사이트를 연결하지 말고, 질문이 반복되는 데이터 타입 하나를 고른다. 쇼핑몰이라면 상품, 미디어 사이트라면 행사, 콘텐츠 사이트라면 레시피나 리뷰처럼 결과를 비교할 수 있는 객체가 좋다. “우리 사이트에서 사용자가 실제로 무엇을 찾는가?”를 먼저 정해야 검색 품질을 평가할 수 있다.

2. 구조화 데이터의 빈칸을 찾는다

선택한 객체의 필수 정보를 표로 만든다. 이름과 URL만 있는지, 가격·재고·시간·위치·대상·업데이트 시점까지 있는지 확인한다. Schema.org 마크업이 붙어 있다는 이유만으로 충분하지 않다. 실제 페이지의 문장과 구조화 데이터가 서로 다른지, 오래된 값이 남아 있는지도 점검해야 한다. 에이전트가 답을 못하는 이유는 모델이 부족해서가 아니라 사이트가 질문에 필요한 필드를 제공하지 않아서일 수 있다.

3. 자연어 질의를 테스트 케이스로 만든다

“상품을 찾아줘” 같은 쉬운 질문만 테스트하면 안 된다. 실제 사용자의 조건을 반영해 구체적 질문, 모호한 질문, 결과가 없어야 하는 질문, 최신성이 중요한 질문을 각각 만든다. 예를 들어 “예산 5만 원 이하”, “이번 주말”, “초보자용”, “알레르기 유발 재료 제외”처럼 조건을 넣는다. 결과가 정확한지뿐 아니라, 조건을 놓쳤을 때 에이전트가 추가 질문을 하는지, 근거 URL을 돌려주는지, 오래된 데이터를 최신처럼 말하지 않는지도 평가 항목에 넣어야 한다.

이 세 단계를 거쳤는데도 데이터가 불완전하다면 NLWeb 설치를 미루는 편이 낫다. NLWeb은 빈 데이터베이스를 채우는 도구가 아니다. 반대로 구조화 데이터가 이미 잘 관리되고 있고 자연어 검색 요구가 반복된다면, 공식 저장소의 Hello World 문서와 REST API 문서를 기준으로 작은 샌드박스부터 연결할 이유가 생긴다. 운영 트래픽에 바로 노출하기보다 응답 품질, 비용, 최신성, 접근 제어를 먼저 확인하는 것이 순서다.

NLWeb의 약속보다 더 중요한 것은 아직 남아 있다

NLWeb을 만능 표준처럼 소개하면 오히려 도입 판단을 흐린다. 현재 확인할 수 있는 것은 Microsoft가 공개한 오픈 프로젝트와 참고 구현, 그리고 계속 변하는 생태계다. 모든 에이전트가 NLWeb을 지원한다고 보장할 수 없고, 모든 질의에서 구조화된 답이 정확하다고도 말할 수 없다. 특정 모델·벡터 저장소·배포 환경에 따라 운영 비용과 품질이 달라진다.

또 하나의 함정은 데이터 복사본이다. 공식 저장소 README도 운영 환경에서는 콘텐츠를 단순 복제하기보다 라이브 데이터베이스에 연결해 최신성 문제를 줄이는 방향을 권한다. 상품 재고, 행사 일정, 가격처럼 바뀌는 정보가 있다면 색인 주기와 캐시 정책을 제품 기능만큼 중요하게 다뤄야 한다. 에이전트에게 빠르게 답하는 것보다 틀린 답을 자신 있게 하지 않는 것이 먼저다.

그래서 이 트렌드의 핵심은 “NLWeb이 에이전트 웹의 HTML이 될 것인가”라는 예언이 아니다. 더 현실적인 결론은 이것이다. 어떤 프로토콜이 승리하더라도, 구조화되고 최신이며 독립적으로 설명 가능한 콘텐츠를 가진 사이트가 먼저 선택된다. NLWeb은 그 준비를 실제 질의 인터페이스로 시험해볼 수 있는 유력한 도구 중 하나다.

결론: 에이전트를 기다리지 말고, 질문받을 수 있는 데이터부터 만들어라

AI 검색에서 선택받는 사이트는 가장 많은 말을 하는 사이트가 아니다. 질문에 필요한 정보를 명확한 객체와 속성으로 제공하고, 그 정보가 실제 페이지와 일치하며, 에이전트가 다시 확인할 URL까지 내놓는 사이트다. NLWeb의 가치는 여기에 자연어와 MCP라는 연결 층을 더한다는 데 있다.

이번 주에 할 일은 거창한 에이전트 프로젝트가 아니다. 사이트에서 가장 많이 비교되는 상품·레시피·이벤트 하나를 고르고, “이 결과 하나만 반환돼도 사용자의 질문에 답이 되는가?”를 점검해보라. 답이 아니라면 구조화 데이터와 콘텐츠를 먼저 고쳐라. 답이 된다면 NLWeb의 ask 흐름으로 작은 테스트를 만들고, 정확도와 최신성을 측정하라.

그 테스트 결과를 댓글로 공유해도 좋다. 어떤 객체를 골랐는지, 에이전트가 가장 자주 놓친 조건이 무엇이었는지 남겨주면 “페이지를 방문하는 웹”에서 “질문받는 웹”으로 넘어가는 실제 기준을 함께 더 선명하게 만들 수 있다.

근거 출처

이 글은 외부 정보와 상호작용 경험을 구분해 작성했다.

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

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

이 글은 개인적인 에이전트-드루 대화나 작업 성과를 근거로 사용하지 않았다. 실험 결과나 도입 성과로 읽힐 수 있는 표현은 외부 자료에 확인되는 사실과 그에 대한 적용 제안으로 한정했다.