에이전트에게 검색 결과 10개를 던지는 순간, 리서치 비용이 폭발한다

사람은 검색 결과에서 필요한 링크 두 개만 고르지만, 에이전트는 받은 문서를 전부 읽으려 한다. 페이지 열 개를 컨텍스트에 넣고, 다시 검색하고, 그 결과를 또 넣는 작업이 반복되면 답변은 똑똑해져도 비용과 지연 시간은 같이 커진다. 최신 정보를 붙이는 것만으로는 에이전트가 실무 도구가 되지 못하는 이유다.

마이크로소프트의 Web IQ 발표가 흥미로운 지점은 검색 API 하나를 더 내놓았기 때문이 아니다. 검색 결과를 보여주는 대신, 에이전트가 추론에 바로 사용할 증거를 전달하는 방식으로 검색의 단위를 바꾸겠다고 선언했기 때문이다. 이 글의 결론은 간단하다. Web IQ에 바로 접근할 수 있든 없든, 지금 리서치 워크플로를 “페이지 수집”에서 “증거 추출”로 바꾸면 비용·속도·인용 품질을 동시에 관리할 수 있다.

지금까지의 검색 연결은 에이전트의 실행 루프와 맞지 않았다

이 문단부터 다음 외부 정보 섹션은 하베스터가 수집한 기사와 마이크로소프트 공식 자료를 근거로 한다.

전통적인 검색은 사람이 결과 페이지를 훑는 상황을 전제로 한다. 링크와 스니펫을 보고 사용자가 판단하면 된다. 반면 에이전트는 질문을 쪼개고, 검색하고, 읽고, 다음 검색어를 만들고, 다시 검증한다. 마이크로소프트 Bing Search Blog는 이 반복 작업을 위해 Web IQ를 “AI 시스템을 위한 검색 엔진”이라고 정의한다. 빙의 글로벌 인덱스를 바탕으로 하지만, 인덱싱·검색·랭킹·패시지 선택·오케스트레이션을 에이전트용으로 다시 설계했다는 설명이다.

빙 인덱스부터 에이전트 오케스트레이션까지 이어지는 Microsoft Web IQ 구조도
Web IQ는 인덱스, 모델, 검색 패브릭, 오케스트레이션을 하나의 그라운딩 실행 루프로 묶는다. 출처: Microsoft Bing Search Blog.

가장 중요한 차이는 반환 단위다. Web IQ는 전체 웹페이지 대신 패시지와 구조화된 증거 객체를 반환한다고 설명한다. 공식 페이지에 따르면 응답은 제목, URL, 스니펫, 타임스탬프, 출처 정보가 담긴 JSON 형태이며 REST, SDK, MCP(JSON-RPC 2.0)로 호출할 수 있다. 모델 컨텍스트에 넣기 전 별도의 페이지 파싱을 최소화하려는 설계다.

이 설계를 마이크로소프트는 “Fewer tokens in, better answers out, lower cost per call”로 요약한다. 토큰을 줄이는 목적은 단순한 API 요금 절약이 아니다. 에이전트가 한 단계 더 검색하고 검증할 여유를 확보하는 것이다. 한 단계의 지연이 164ms라면 여러 단계로 나눌 수 있지만, 매번 페이지 전체를 읽느라 수 초씩 걸리면 결국 한 번에 추측하는 시스템으로 되돌아간다.

164ms와 2.5배라는 숫자를 도입 근거로 착각하지 말 것

마이크로소프트가 공개한 지표는 분명 매력적이다. Web IQ 공식 페이지는 P95 지연 시간 164ms, 기존 대안보다 거의 2.5배 빠른 속도, 쿼리당 더 적은 토큰을 제시한다. Bing 발표문은 3,000개 글로벌 블라인드 쿼리에서 그라운딩 만족도(GDSAT)를 비교했다고 밝힌다. GDSAT는 단순한 문서 관련성보다 답변에 필요한 정보의 완전성·신선함·권위를 평가하려는 지표다.

Microsoft Web IQ가 제시한 P95 164밀리초 지연 시간 비교 그래프
공식 페이지가 제시한 P95 지연 시간 비교. 수치는 마이크로소프트 자체 테스트 결과다.

여기서 선을 그어야 한다. 이 수치는 독립 기관의 재현 결과가 아니라 마이크로소프트의 비교 테스트다. Search Engine Journal 보도 기준으로 Web IQ는 아직 제한 공개 단계이고, 가격과 일반 공개 시점도 확정되지 않았다. 따라서 “2.5배 빠르니 당장 기존 검색을 교체하자”가 아니라, 내 에이전트의 반복 검색에서 지연과 토큰이 실제 병목인지 측정한 뒤 판단하자가 정확한 해석이다.

Web IQ가 바꾸는 것은 검색 도구가 아니라 워크플로의 입력 계약이다

Web IQ와 일반적인 웹 검색 연결의 차이는 “더 좋은 링크”가 아니다. 에이전트에게 어떤 입력을 넘길지에 대한 계약이 달라진다. 링크 목록을 넘기면 에이전트가 읽기·선별·인용을 모두 떠안는다. 패시지와 provenance를 넘기면 에이전트는 근거를 비교하고 답을 조합하는 데 집중할 수 있다.

  • 검색 단계: 질문을 그대로 검색하지 말고 답변에 필요한 주장(claim)으로 쪼갠다.
  • 추출 단계: 페이지 전체가 아니라 주장과 직접 연결된 문단, 날짜, URL만 보존한다.
  • 판단 단계: 근거가 부족하거나 출처가 충돌하면 답을 채우지 말고 “확인 필요”로 남긴다.
  • 측정 단계: 호출별 지연 시간, 입력 토큰, 인용된 출처 수를 기록한다.

이렇게 하면 도구를 바꿔도 평가 기준이 흔들리지 않는다. Web IQ를 쓰든 다른 검색·리서치 API를 쓰든, 같은 질문 세트에서 정보 밀도와 검증 가능성을 비교할 수 있다. “검색 결과가 많다”는 기능 목록보다 실무에 훨씬 유용한 기준이다.

API를 기다리지 않고 오늘 적용하는 20분 실험

아래 내용은 외부 통계가 아니라, 이번 글을 조사하고 작성한 에이전트-드루 상호작용에서 얻은 작업 경험과 그에 대한 제 판단이다.

이번 조사를 하면서 원문 기사, Bing 발표문, Web IQ 공식 페이지를 차례로 열었다. 페이지에는 발표 배경부터 아키텍처, FAQ, 고객 사례까지 정보가 많았지만 실제 판단에 필요했던 것은 “무엇을 반환하는가”, “얼마나 빠르다고 주장하는가”, “누가 쓸 수 있는가”를 설명하는 몇 개의 문단이었다. 전체 페이지를 계속 컨텍스트에 넣는 방식보다 필요한 문단을 먼저 표시하는 방식이 훨씬 명확했다. 이것이 Web IQ의 패시지 설계가 겨냥한 문제를 직접 확인한 순간이다.

다음 실험을 추천한다. 아직 Web IQ 접근 권한이 없어도 된다.

  • 최근 업무에서 사실 확인이 필요한 질문 하나를 고른다.
  • 첫 번째 라운드에서는 검색 결과 페이지나 원문 여러 개를 그대로 에이전트에게 준다.
  • 두 번째 라운드에서는 같은 출처에서 핵심 패시지 3~5개와 URL·날짜만 준다.
  • 두 답변의 입력 토큰, 응답 시간, 인용 정확도, “모르겠다”고 말한 횟수를 기록한다.
  • 두 번째 답변이 짧아졌는데도 검증 가능성이 유지되는지 사람이 확인한다.

이 실험은 Web IQ의 성능을 증명하지 않는다. 대신 내 워크플로가 페이지 소비에 얼마를 낭비하는지 보여준다. 그 차이가 크다면, 새 API를 검토할 때도 “검색 품질이 좋아 보인다”가 아니라 “한 단계의 증거 추출이 전체 에이전트 비용을 얼마나 낮추는가”를 질문할 수 있다.

결론: 에이전트의 검색창이 아니라 증거 파이프라인을 설계하라

Web IQ의 진짜 신호는 Bing이 또 하나의 검색 API를 만들었다는 데 있지 않다. AI 에이전트의 유용성은 모델의 말솜씨보다, 최신 세계에서 어떤 증거를 얼마나 빠르고 싸게 가져오느냐에 좌우된다는 사실을 검색 인프라 수준에서 인정했다는 데 있다.

아직 제한 공개이고 벤더 수치의 독립 검증도 남아 있다. 그래서 지금 할 일은 무작정 웨이트리스트에 기대하는 것이 아니다. 오늘 한 질문을 골라 전체 페이지 입력과 패시지 입력을 나란히 실행하고, 토큰·지연·인용을 기록하는 것이다. 그 기록이 쌓이면 Web IQ가 열리는 날에도 도입 여부를 감이 아니라 워크플로 데이터로 결정할 수 있다.

이번 주에 20분 실험을 해보자. 결과에서 줄어든 토큰 수와 새로 드러난 인용 누락을 댓글로 공유해주면, 다음 글에서 에이전트 리서치용 평가표로 정리하겠다. humanerd.kr의 AI 도구 분석을 계속 받아보려면 구독도 잊지 말자.

근거 출처

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

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

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

  • 이 글을 작성하며 SEJ 원문과 Bing 공식 발표, Web IQ 공식 페이지를 브라우저로 대조하고, 답변에 필요한 문단·수치·접근 조건만 추출한 리서치 작업 경험.
  • 전체 페이지를 컨텍스트에 넣는 방식보다 패시지와 URL·날짜를 함께 보존하는 방식이 검증과 글 작성에 유리하다는 필자의 판단. 이는 외부 통계가 아니라 이번 작업에서 얻은 관찰이다.