에이전트에게 검색 결과 10개를 던지면, 에이전트는 그 10개를 전부 읽는다. 사람이야 “이 두 개만 보면 되겠다”고 3초 안에 판단하지만, 에이전트는 다르다. 거의 전부를 컨텍스트 윈도우에 넣고, 그건 곧 돈이고 지연이다.

지난 6월 마이크로소프트가 Build 2026에서 발표한 Web IQ는 이 어긋남을 정확히 겨냥한다. “검색은 페이지를 주지만, 에이전트는 증거가 필요하다.” 이 글에서는 Web IQ가 무엇인지, 왜 이 발표가 에이전트 워크플로와 콘텐츠 전략 양쪽에 신호인지, 그리고 API를 쓰기 전에 지금 워크플로에 옮길 수 있는 원칙을 정리한다.

에이전트는 검색 결과를 “탐색”하지 않고 “소비”한다

이 섹션은 하베스터로 수집한 외부 정보(Search Engine Journal 보도, Bing Search Blog 공식 발표, Microsoft Command Line 기술 블로그)를 기준으로 작성했다.

마이크로소프트는 Web IQ를 한 문장으로 정의한다. “A search engine for AI systems.” 빙이 사람의 웹페이지 탐색을 돕는 곳이라면, Web IQ는 AI 에이전트가 추론 과정에서 필요한 정보를 찾아 증거로 바꿔 쓰도록 설계된 검색 시스템이다.

핵심 차이는 반환 단위다. Web IQ는 웹페이지 전체가 아니라 “패시지(passage)”와 “구조화된 증거 객체(structured evidence objects)”를 돌려준다. 발표문(6월 2일, Bing Search Blog)은 이렇게 쓴다. “모델은 문서가 필요하지 않다. 문서는 종종 그 정보의 좋지 않은 대용물이다.”

이 설계 원칙은 세 단어로 압축된다.

“Fewer tokens in, better answers out, lower cost per call.” 적은 토큰을 넣고, 더 나은 답을 받고, 호출당 비용을 줄인다. 발표문이 강조하는 건 토큰 절감 자체가 아니라, “제약된 컨텍스트에서 추론의 정밀도를 유지하는 것”이 더 깊은 가치라는 점이다.

.Command Line 블로그의 기술 심층 분석(Lisa Brown Jaloza)은 이것을 더 구체화한다. Web IQ의 증거 객체는 “패시지 단위의 단서와 출처·구조적 메타데이터를 포함한 유닛”으로, 원본 페이지에서 분리되더라도 해석 가능한 충분한 로컬 컨텍스트를 담고 있다. 최적화 목표가 “문서 관련성”에서 “토큰당 정보 밀도(information density per token)”로 바뀌는 셈이다.

Web IQ의 증거 객체 설계 — 패시지 단위로 콘텐츠를 추출해 토큰 효율과 정보 밀도를 높이는 구조
Web IQ의 증거 객체 설계. 원문 페이지 대신 패시지 단위로 추출해 토큰당 정보 밀도를 높인다 (출처: Microsoft Command Line Blog, 2026-06-02)

수치로 보는 주장 — 단, 전부 마이크로소프트 자체 테스트다

이 섹션도 외부 정보 기준이다. 아래 수치는 전부 마이크로소프트 자체 테스트 기반이며, 독립 검증 전 단계라는 점을 먼저 밝혀둔다.

Microsoft Web IQ 공식 페이지(microsoft.com/en-us/webiq)와 발표문에서 제시한 세 가지 수치:

  • GDSAT(grounding satisfaction) — 전통적인 관련성 점수가 “문서가 쿼리에 얼마나 관련 있는가”를 보는 반면, 그라운딩이 사용자 의도를 완전성·신선함·권위 측면에서 실제로 충족하는지를 측정하는 지표. 3,000개 글로벌 블라인드 쿼리 기준 79.05점으로, 경쟁 대안보다 높은 점수를 기록했다고 보고했다.
  • 지연 시간 — P95 기준 164ms. 미국 3곳, 북유럽, 한국 등 5개 DC에서 캐시 히트를 피하는 유니크 쿼리로 측정됐으며, “이전 코호트의 차선 경쟁 대안”보다 약 2.5배 빠르다고 보고했다.
  • 토큰 효율 — 결과 수(10·15·20개)와 결과당 문자 수(3K·5K·10K·20K)를 늘려가며, 같은 품질을 더 적은 토큰으로 달성했다고 보고했다. “주어진 품질에 필요한 컨텍스트의 양” 자체를 줄인다는 게 핵심이다.
Microsoft Web IQ의 P95 지연 시간 경쟁 비교 — 164.4ms로 경쟁 대비 약 2.5배 빠르다
Web IQ의 P95 지연 시간: 164ms. 경쟁 대비 약 2.5배 빠르다 (출처: microsoft.com/en-us/webiq)

기술 층에서도 주목할 지점이 있다. Web IQ는 4월 오픈소스로 공개된 Harrier 임베딩 모델을 검색의 중심으로 쓴다. Command Line 블로그는 이를 “decoder-only 아키텍처에 last-token pooling과 normalization을 적용한 멀티텍스트 임베딩 모델”로 설명하며, “인코더 중심의 기존 패턴과 달리 LLM 스택과의 결합이 더 단단하다”고 밝힌다. 콘텐츠 이해와 랭킹을 담당하는 모델들은 “스탠드얼론 벤치마크 점수가 아니라 LLM 추론 안에서 출력이 실제로 쓰이는 방식”에 맞춰 학습됐다고 한다.

대규모 벡터 검색을 디스크 상에서 처리하는 DiskANN3는, 분산 파티션 전역에서 라우팅되는 “리트리벌 패브릭”으로 확장된다. Command Line 블로그는 DiskANN3의 업데이트 로직을 특히 강조한다. “근접 그래프는 국소 연결이 깨지기 쉬워 단순 삭제/삽입이 검색 품질을 떨어뜨리거나 전체 재구축을 강제한다”는 문제를 해결해, “새 콘텐츠를 검색 가능한 상태로 만드는 데 수 밀리초만 걸리는 진짜 스트리밍 시맨틱 인덱스”에 도달했다고 설명한다.

오케스트레이션 레이어에 대한 정의가 이번 발표의 철학을 가장 잘 드러낸다. 이 레이어는 “외부 API 레이어가 아니라 에이전트 실행 루프의 일부”다. 지연은 단순한 체감 문제가 아니라, “에이전트가 여러 번의 추론 단계를 가질 수 있는지, 아니면 한 번에 압축해야 하는지”를 결정하는 구조적 제약이 된다.

측정 도구와 공급 채널이 한 몸이 됐다

이 섹션은 외부 정보 기준이다.

Web IQ는 단독 발표가 아니다. 마이크로소프트가 올해 내내 쌓아온 흐름의 마지막 조각이다. 시간순으로 나열하면 그림이 선명해진다.

  • 2월 — Bing Webmaster Tools에 AI 인용 데이터 추가. “AI 시스템이 내 콘텐츠를 얼마나 인용하는가”를 웹마스터가 볼 수 있게 됐다.
  • 3월 — 그라운딩 쿼리를 인용된 페이지에 매핑. 어떤 질문이 내 페이지로 이어졌는지 추적 가능해졌다.
  • SEO Week — Citation Share 미리보기. AI 인용에서 내 사이트가 차지하는 비중을 보여주는 지표다.
  • 5월 — Bing 팀이 “그라운딩은 왜 기존 인덱싱과 다른가”를 다루는 설계 프레임워크를 발표. 페이지 랭킹 기준과 패시지 유틸리티 기준이 겹치지 않는다는 점을 공식화했다.
  • 6월 (Build 2026) — Web IQ. 반대편, 즉 AI 시스템이 콘텐츠를 실제로 끌어가는 검색 레이어가 등장했다.

“AI가 내 콘텐츠를 어떻게 쓰는지 보여주는 측정 도구”와 “AI가 콘텐츠를 끌어가는 검색 엔진”이 한 몸이 된 것이다. 측정과 공급의 양쪽을 모두 가진 플레이어는 이 시점에서 마이크로소프트가 유일하다.

5월 프레임워크에서 가장 중요한 시사점이 하나 더 있다. 마이크로소프트는 이 문서에서 전통 검색과 그라운딩이 다섯 가지 측정 영역에서 어긋난다고 밝힌다. 사실 정확도, 출처 인용 품질, 신선함, 고가치 사실 커버리지, 모순 처리. 특히 모순 처리에서, “검색은 상위 결과를 보여주고 사용자가 판단하지만, 그라운딩 시스템은 그렇게 할 수 없다. AI 시스템이 모순된 소스를 조용히 중재하면 잘못된 것을 자신 있게 단언할 수 있다”고 설명한다. 이건 SEO 관점에서 심각한 경고다. 지금까지의 SEO 노력이 그대로 AI 인용으로 이어지지 않을 가능성이 크다.

제한 공개, 그리고 아직 안 풀린 질문들

이 섹션은 외부 정보 기준이다.

Web IQ는 현재 제한 공개(limited access) 단계다. aka.ms/WebIQ에서 관심 의향(expression of interest)을 받고 있지만, 가격·일반 공개(GA) 시기·API 문서가 아직 불명확하다. Microsoft Web IQ 공식 페이지는 “2.5배 속도”를 내세우며 웨이트리스트를 운영 중이고, 네이스닥(Nasdaq Boardvantage®)이 이미 “외부 정보를 안전하게, 데이터 격리 하에서 빛의 속도로 쿼리”하고 있다는 고객 사례를 공개했다.

Command Line 블로그는 Web IQ를 “MCP-native, model-agnostic platform”으로 설명한다. 즉, 기존 Copilot·ChatGPT 그라운딩이 이미 이 인프라를 쓰고 있을 가능성이 높지만, 공식 확인은 아직 없다. “Web IQ가 이미 Copilot과 ChatGPT 웹 응답의 그라운딩에 쓰이고 있다”는 후속 보도가 있었으나, 자사 주장이며 독립 검증 전 단계다.

API가 없어도 지금 따라 할 수 있는 네 가지

이 섹션은 이 글을 쓰는 과정에서 실제로 수행한 리서치·원본 수집·검증 워크플로(에이전트-드루 상호작용)에서 얻은 경험을 바탕으로 한다. Web IQ의 제공 현황 자체는 외부 정보다.

솔직히 고백하면, 이 글을 쓰는 동안에도 나는 같은 패턴을 반복했다. 원본 기사를 수집하고, 발표 원문과 후속 보도를 직접 확인하기 위해 페이지를 통째로 불러왔다. 막상 답에 쓰인 건 결국 문단 몇 개뿐이었다. Web IQ는 그 비효율을 API로 자동화하겠다는 선언이지만, 그 설계 철학은 API가 없어도 지금 내가 수동으로라도 따라 할 수 있는 원칙으로 읽힌다.

Command Line 블로그가 말하는 “토큰당 정보 밀도” 최적화를 실무로 옮기면 다음과 같다:

  • “증거 우선” 추출 레이어를 먼저 끼워보기 — 검색 결과를 컨텍스트에 통째로 넣기 전에, 요약·추출 레이어를 한 번 끼워서 답에 쓰일 조각만 남긴다. 이번 작업에서도 페이지 전체 대신 “이 문단만”으로 요약해 넣었을 때 토큰이 어떻게 줄어드는지 체감할 수 있었다. Web IQ가 API로 자동화하는 일을 수동으로 먼저 해보면, 그 이득이 손에 잡힌다.
  • 호출당 토큰을 측정하는 습관 — 에이전트 검색은 반복 호출이 기본이다. “한 번 검색 = 평균 N 토큰”이라는 기준을 세워두면, 새 검색 도구를 평가할 때 공정한 비교선이 생긴다. Web IQ의 “fewer tokens in”이 실재인지 검증할 기준도 바로 그것이다.
  • 패시지 단위로 콘텐츠를 다시 보기 — 페이지가 아니라 “이 문단이 단독으로 읽혔을 때 답이 되는가”를 기준으로 콘텐츠를 점검한다. 어떤 쿼리가 내 페이지로 이어졌는지는 Bing Webmaster Tools의 AI 인용 데이터와 그라운딩 쿼리 매핑으로 이미 확인할 수 있다.
  • 웨이트리스트는 미리 신청해두기 — Web IQ는 아직 제한 공개 단계라 바로 쓸 수 없다. “나중에 보자”보다는 aka.ms/WebIQ에 관심 의향을 남겨두고, 열리면 패시지 단위 응답을 직접 측정해보는 쪽이 이득이다.

마무리 — 발표를 기다리는 대신 원칙을 먼저 가져가라

Web IQ가 165ms 미만 지연과 토큰 효율을 독립적으로 증명할지는 아직 모른다. 다만 이 발표가 확정한 방향은 하나다. AI 에이전트는 “링크 목록”이 아니라 “증거”를 원하며, 검색은 그에 맞게 다시 설계될 것이다. 그리고 그 전환에서 승자의 조건은 워크플로 운영자든 콘텐츠 제작자든 동일하다. 페이지 단위가 아니라 패시지 단위에서 경쟁하는 법을 배우는 것.

그 방향을 지금 당장 워크플로에 옮기는 데 API가 필요하지 않다. 이번 주에 리서치 에이전트 하나를 골라 (1) 검색 결과를 통째로 넣었을 때의 토큰 수와 (2) 증거 조각만 추려 넣었을 때의 토큰 수를 비교해보라. 그 차이가 곧 Web IQ가 자동화하려는 가치다. 웹사이트를 운영한다면 Bing Webmaster Tools의 AI 인용 데이터부터 확인해보라. 측정이 시작돼야 최적화도 시작된다.

직접 비교해본 토큰 수나, 패시지 단위 그라운딩을 측정해본 결과가 어땠는지 댓글로 알려달라. “페이지를 읽는 에이전트”에서 “증거를 쓰는 에이전트”로 옮겨가는 과정을, 함께 검증해보고 싶다.

근거 출처

이 글의 근거는 두 범주로 나뉜다.

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

  • Search Engine Journal — “Microsoft Web IQ Gives AI Agents Bing Grounding APIs” (Matt G. Southern, 2026-06-02). “A search engine for AI systems” 정의, 패시지·구조화된 증거 객체 반환, “fewer tokens in, better answers out, lower cost per call” 원칙, GDSAT(3,000 쿼리), P95 165ms 미만·경쟁 대비 약 2.5배(5개 DC), 토큰 효율, robots 배제 규칙·IETF 표준 논의, 오픈소스 임베딩 모델·DiskANN, 2월 AI 인용 데이터·3월 그라운딩 쿼리 매핑·SEO Week Citation Share의 흐름, 관심 의향 접수 중·GA/가격/API 문서 미정.
  • Bing Search Blog — “Announcing Microsoft Web IQ” (Knut Risvik, 2026-06-02). Web IQ 아키텍처(빙 글로벌 인덱스 → 소수의 세계 최고 수준 모델 → DiskANN 기반 리트리벌 패브릭 → 에이전트 실행 루프의 일부인 오케스트레이션), “모델은 문서가 아니라 정보가 필요하다”, GDSAT 정의(완전성·신선함·권위), 5개 DC P95 165ms 미만, 발행자 통제와 IETF 참여.
  • Microsoft Web IQ 공식 페이지 — microsoft.com/en-us/webiq. GDSAT 79.05점, P95 164ms, “2.5배 속도”, “Fewest tokens per query”, 네이스닥 고객 사례.
  • Search Engine Journal — “Bing Reveals What Grounding Means For AI Search Visibility” (Matt G. Southern, 2026-06-09). Bing 그라운딩 프레임워크: 전통 검색과 그라운딩의 다섯 가지 측정 영역 차이(사실 정확도, 출처 인용 품질, 신선함, 고가치 사실 커버리지, 모순 처리), 중립 추상(abstention), 반복 리트리벌(iterative retrieval).
  • Microsoft Command Line Blog — “Grounding at scale: Engineering the retrieval system for the agentic web” (Lisa Brown Jaloza, 2026-06-02). Web IQ 기술 심층 분석: Harrier 임베딩 모델(decoder-only, last-token pooling), DiskANN3(스트리밍 시맨틱 인덱스, 수 밀리초 업데이트), 증거 객체(패시지 단위, 토큰당 정보 밀도 최적화), 오케스트레이션(에이전트 실행 루프의 일부), 시맨틱 퍼스트 리트리벌 시스템 설계 원칙, MCP-native·model-agnostic.

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

  • 이 글을 쓰는 과정에서 수행한 리서치·원본 수집·검증 워크플로 경험 — 하베스터가 수집한 기사 원본(SEJ)을 바탕으로 발표 원문(Bing Search Blog), 공식 페이지(microsoft.com/en-us/webiq), 기술 심층 분석(Command Line Blog), 그라운딩 프레임워크(SEJ 후속 보도)를 직접 확인하는 과정에서, 웹 검색 기반 에이전트 작업이 페이지 전체 소비로 인한 토큰·지연 낭비를 반복한다는 관찰과, “증거 우선” 추출 레이어·호출당 토큰 측정의 실용성에 대한 필자 판단.