Cloudflare, AI Gateway를 통해 Web Search API 도입… 검색을 인프라로 전환
Cloudflare가 세 개의 검색 공급자를 지원하는 AI Gateway 기반 Web Search API를 도입하며, 실시간 웹 검색을 모델 추론과 동일한 제어 평면으로 가져오고 있다. 베타 버전은 하나의 인터페이스를 통해 Ceramic.ai, Exa, Linkup을 지원한다. 개발자는 백엔드, Cloudflare Worker 또는 에이전트 워크플로에서 이를 호출할 수 있다.
중요한 변화는 또 하나의 웹 검색 엔드포인트가 생겼다는 데 있지 않다. Cloudflare는 검색을 모델 라우팅, 로그, 보안 제어, 자격 증명, 사용량 관리와 나란히 배치하고 있다. 이러한 위치 설정은 검색을 고립된 통합 작업에서 관리형 AI 인프라로 바꾼다.
이 움직임은 또한 뚜렷한 경쟁 구도를 만든다. 개발자는 모델 플랫폼에 내장된 검색 도구를 사용하거나, 전문 검색 기업에 직접 연결하거나, 독립적인 게이트웨이 뒤에 검색 기능을 둘 수 있다. Cloudflare는 특히 하나의 애플리케이션이 여러 모델과 검색 공급자를 사용할 때 팀들이 세 번째 선택지를 원할 것이라고 보고 있다.
AI Gateway를 통한 Web Search API 도입이 제어 지점을 바꾼다
Cloudflare는 이제 검색 기능을 특정 언어 모델에 묶지 않고, 세 개의 독립 검색 서비스로 향하는 하나의 관리형 경로를 개발자에게 제공한다.
회사는 2026년 10월 2일 베타 버전을 발표했다. 출시 발표에 따르면 요청은 Ceramic.ai, Exa 또는 Linkup을 사용할 수 있다. 애플리케이션이 공급자를 지정하지 않으면 Ceramic.ai가 기본값이 된다.
모든 응답은 각 결과의 제목, URL, 설명을 포함하는 공통 구조를 따른다. 메타데이터에는 쿼리, 요청 식별자, 지연 시간 정보도 포함될 수 있다. 공급자별 차이가 애플리케이션 코드로 새어 들어가는 경우가 많기 때문에 이러한 일관성은 중요하다.
개발자는 표준 REST 엔드포인트를 통해 서비스에 접근할 수 있다. Cloudflare Workers 사용자는 대신 AI 바인딩을 통해 env.AI.websearch()를 호출할 수 있다. 두 방식 모두 기존 AI Gateway를 통해 요청을 전송한다.
REST 경로는 쿼리, 공급자 이름, 결과 제한 수, 게이트웨이 설정을 받는다. Workers 바인딩은 JavaScript 또는 TypeScript를 통해 동등한 제어 기능을 제공한다. Cloudflare의 구현 가이드에 따르면 쿼리는 최대 1,024자를 포함할 수 있으며, 한 요청은 최대 10개의 결과를 반환한다.
이 제한은 제품의 설계 목적을 보여준다. 이는 일반적인 검색 결과 페이지를 대체하는 서비스가 아니라 모델 호출을 위한 컨텍스트 검색 계층이다. 애플리케이션은 집중된 출처 집합을 수집하고 관련 스니펫을 모델의 작업 컨텍스트에 넣는다.
서비스는 두 가지 자격 증명 경로를 지원한다. 팀은 AI Gateway 크레딧을 사용하거나, 공급자 키를 저장한 뒤 bring-your-own-key 별칭을 통해 선택할 수 있다. Cloudflare는 애플리케이션이 매 검색 요청마다 자격 증명을 전송하도록 요구하는 대신 게이트웨이 내부에서 해당 자격 증명을 가져온다.
이 아키텍처는 팀에 인증을 위한 공통 경계를 제공한다. 또한 애플리케이션, 배포 시스템, 개발자 머신 전반에 분산되는 외부 자격 증명의 수를 줄인다. 손상된 애플리케이션 토큰은 여전히 위험을 초래하지만, 자격 증명 확산은 더 쉽게 통제할 수 있게 된다.
Cloudflare는 웹 검색 요청이 일반 AI Gateway 관측성 로그에 표시된다고 말한다. 팀은 별도의 모니터링 스택을 운영하는 대신 모델 트래픽과 함께 요청 활동을 검토할 수 있다. 액세스 정책은 특정 검색 공급자에 접근할 수 있는 애플리케이션도 결정할 수 있다.
이 통합은 이 글의 핵심 긴장을 만든다. 직접 검색 API는 중간 계층이 더 적은 반면, 게이트웨이는 더 큰 운영 통제력을 제공한다. Cloudflare는 제어 계층이 추가하는 복잡성보다 더 많은 복잡성을 줄인다는 점을 입증해야 한다.
검색은 AI Gateway 스택의 일부가 되고 있다
Cloudflare가 실시간 검색을 이를 소비하는 모델에서 분리하면서, 경쟁 압력은 모델 플랫폼과 전문 검색 공급자에 가해지고 있다.
많은 모델이 이미 네이티브 웹 검색을 제공한다. Cloudflare의 기존 게이트웨이 문서는 OpenAI, Anthropic, xAI, Alibaba의 지원 검색 도구를 나열한다. 이러한 도구는 각 공급자 인터페이스와 모델 기능에 계속 연결된 상태다.
팀이 하나의 모델 계열을 선택할 경우 네이티브 검색은 편리할 수 있다. 모델이 검색 시점을 결정하고, 공급자가 근거를 형식화하며, 같은 서비스가 답변을 생성한다. 단순한 어시스턴트에서는 이 경로가 오케스트레이션 작업을 최소화할 수 있다.
그러나 애플리케이션이 모델을 바꾸면 편의성이 떨어진다. 도구 스키마, 지원 모델, 인용 형식, 지역별 가용성, 보존 조건은 서로 다를 수 있다. 모든 경로가 같은 기본 검색 작업을 수행하더라도 팀은 공급자별로 별도 구현이 필요할 수 있다.
Cloudflare Web Search API는 이 경계를 바꾼다. 검색은 공통 응답 형식을 갖춘 애플리케이션 제어 단계가 된다. 검색된 자료는 Workers AI를 통해 제공되는 모델, AI Gateway를 통해 라우팅되는 모델 또는 다른 추론 서비스에 공급될 수 있다.
이 분리는 하나의 답변을 생성하기 전에 여러 검색을 수행하는 에이전트에게 중요하다. 조사 에이전트는 폭넓은 쿼리로 시작해 기업이나 문서를 식별한 뒤 더 좁은 후속 검색을 실행할 수 있다. 이러한 호출은 최종 모델 요청보다 많아질 수 있으므로 예측 가능한 로깅과 권한 관리가 필요하다.
게이트웨이 접근 방식은 명시적인 공급자 선택도 지원한다. 개발자는 한 워크로드를 Ceramic.ai로, 다른 워크로드를 Exa 또는 Linkup으로 라우팅할 수 있다. 선택한 공급자가 바뀌더라도 애플리케이션은 전체 통합 방식을 바꿀 필요가 없다.
Cloudflare는 각 공급자가 서로 다른 검색 프로필을 제공한다고 설명한다. 공급자 문서에 따르면 Ceramic.ai는 400억 개 이상의 페이지를 포함하는 독립 인덱스를 운영한다. 이는 에이전트에 상당한 컨텍스트를 제공할 수 있는 긴 설명을 반환한다.
Exa는 키워드 방식과 임베딩 기반 검색을 결합한다. 이는 단순히 일치하는 용어에만 의존하지 않고 의미론적 표현을 비교하는 방식이다. Cloudflare는 검색된 페이지에서 쿼리와 관련된 하이라이트를 반환하도록 이를 구성한다. 이 형식은 간결한 근거가 필요한 프롬프트에 적합하다.
Linkup은 종합된 답변을 생성하지 않고 빠른 검색 모드를 통해 출처가 명시된 스니펫을 반환한다. 이는 검색과 추론을 분리한다. 애플리케이션은 어떤 모델이 결과를 분석할지, 인용을 어떻게 표시할지를 결정할 수 있다.
이러한 차이는 Cloudflare가 여러 공급자를 지원할 이유를 제공한다. 검색 품질은 단일 차원의 문제가 아니다. 최신성, 인덱스 범위, 의미적 관련성, 지연 시간, 스니펫 길이, 출처 선택은 작업에 따라 각각 더 중요할 수 있다.
같은 다양성은 제품을 복잡하게 만들기도 한다. 정규화된 응답이 공급자들을 동등하게 만들지는 않는다. 개발자는 각 서비스가 자신의 도메인에 맞는 근거를 검색하는지 측정하는 평가가 여전히 필요하다.
따라서 Cloudflare는 검색 기업에 두 방향의 압력을 가한다. 확립된 개발자 플랫폼을 통해 유통을 제공하는 동시에, 공통 인터페이스 뒤에서 이들을 교체 가능한 선택지로 제시한다. 이는 고객 관계의 일부를 게이트웨이 쪽으로 이동시킬 수 있다.
모델 공급자는 다른 과제에 직면한다. 통합 검색 도구는 검색과 생성을 함께 최적화할 수 있다. Cloudflare의 접근 방식은 많은 팀이 긴밀히 결합된 경험보다 이식성, 독립적인 공급자 선택, 중앙집중식 정책을 더 중시할 것이라는 주장이다.
Vercel도 유사한 전략을 추진하고 있다. Vercel의 AI Gateway는 최근 도구 호출을 지원하는 여러 모델에서 작동하는 search and fetch 도구를 추가했다. 이러한 출시 시점의 근접성은 게이트웨이가 모델 라우팅을 넘어 완전한 에이전트 도구 계층으로 확장되고 있음을 시사한다.
이것은 누가 먼저 모델을 검색에 연결했는지에 관한 경쟁이 아니다. 어느 플랫폼이 그 연결을 관리하는지를 둘러싼 경쟁이다. 승자는 자격 증명, 로그, 라우팅 결정, 보존 설정, 개발자의 통합 표면을 통제하게 된다.
메커니즘은 단순하지만 아키텍처 변화는 더 크다
Cloudflare는 애플리케이션이 모델 호출 전, 도중 또는 사이에 호출할 수 있는 재사용 가능한 검색 프리미티브로 검색을 전환한다.
기본 워크플로는 사용자 질문으로 시작한다. 애플리케이션은 그 질문 또는 파생된 쿼리를 Web Search API에 전송한다. 구조화된 결과를 받고, 선택한 설명을 모델 프롬프트에 넣는다.
에이전트도 서비스 호출 시점을 결정할 수 있다. 개발자는 모델에 설명되는 호출 가능한 작업인 web_search 함수 도구를 정의한다. 모델이 해당 도구를 요청하면 애플리케이션 코드가 검색을 실행하고 결과를 반환한다.
그다음 모델은 원래 질문과 검색된 근거를 포함하는 두 번째 추론 호출을 받는다. 이 패턴은 모델이 작업을 수행하면서 외부 정보를 수집하기 때문에 흔히 도구 증강 생성이라고 불린다. 이는 모델 파라미터에 저장된 지식에만 의존하는 방식과 다르다.
Cloudflare는 네이티브 서버 도구가 나중에 제공될 예정이라고 말한다. 이러한 도구는 더 많은 오케스트레이션을 AI Gateway 자체로 옮길 수 있다. 현재로서는 개발자가 도구 호출을 받고, 검색을 실행하고, 결과를 모델에 반환하는 루프를 구현해야 한다.
이 구분은 중요하다. 현재 베타는 검색 서비스와 공통 게이트웨이 제어 기능을 제공한다. 쿼리를 결정하고, 근거를 필터링하며, 상충하는 출처를 해결하고, 인용된 답변을 작성하는 완전 관리형 조사 에이전트는 아직 제공하지 않는다.
독립형 설계에도 유용한 장점이 있다. 팀은 결과가 모델에 도달하기 전에 원시 결과를 검토할 수 있다. 차단된 도메인을 제외하고, 승인된 출처를 요구하며, 중복 페이지를 제거하거나, 내부 신뢰 정책을 충족하는 문서로 검색을 제한할 수 있다.
지원 어시스턴트가 실용적인 예를 제공한다. 고객이 최근 변경된 API에 관해 질문하면, 에이전트는 오래된 학습 스냅샷을 바탕으로 답하는 대신 최신 문서를 검색할 수 있다. 애플리케이션은 검토를 위해 검색된 URL을 보존할 수 있다.
소프트웨어 에이전트도 오류를 해결할 때 같은 패턴을 사용할 수 있다. 새 릴리스 노트, 변경된 구성 옵션 또는 현재 호환성 경고를 검색할 수 있다. 검색 결과는 근거가 되고, 모델은 그 근거를 해석할 책임을 계속 진다.
조사 및 모니터링 제품은 여러 개의 집중된 쿼리를 실행할 수 있다. 한 요청은 공식 발표를 찾고, 다른 요청은 문서를 찾으며, 세 번째 요청은 독립 보도를 확인할 수 있다. 좋은 워크플로는 첫 번째 결과를 그대로 받아들이는 대신 이러한 출처를 비교한다.
지식 근로자는 비공개 자료 안에서 관련된 문제에 직면한다. 시스템은 외부 동향을 메모, 문서, 이미 확립된 조직적 맥락과 결합해야 한다. 이 과정은 사용자가 이미 신뢰하는 정보와 연결된 뒤에야 새로운 근거가 유용해지는 knowledge blending과 닮아 있다.
게이트웨이는 이런 워크플로에 포함된 검색 호출을 기록할 수 있다. 답변이 실패했을 때 운영자에게 더 명확한 기록을 제공한다. 쿼리가 부실했는지, 공급자가 페이지를 놓쳤는지, 스니펫에 맥락이 부족했는지, 모델이 좋은 근거를 잘못 해석했는지를 확인할 수 있다.
이 분리는 더 나은 평가를 지원한다. 검색 품질과 답변 품질을 독립적으로 측정할 수 있다. 이러한 분리가 없으면 저품질 응답만으로 검색과 생성 중 어느 쪽이 문제를 일으켰는지 알기 어렵다.
또한 단계적 폴백도 지원한다. 애플리케이션은 한 제공업체에 질의한 뒤 결과 수를 확인하고, 커버리지가 부족할 경우 다른 제공업체로 재시도할 수 있다. Cloudflare는 베타가 이러한 품질 판단을 자동으로 수행한다고 주장하지 않았으므로, 개발자가 직접 이를 구축하고 테스트해야 한다.
캐싱도 마찬가지다. 일부 시사성 질문은 빠르게 오래된 정보가 되지만, 안정적인 문서 관련 질의는 결과를 재사용할 수 있다. 책임 있는 애플리케이션에는 만료, 소스 업데이트, 반복 요청에 대한 정책이 필요하다.
Cloudflare의 기존 gateway search support는 이미 여러 모델 제공업체의 네이티브 도구를 프록시한다. 새로운 API는 이와 다른 경로를 추가한다. 즉, 해당 네이티브 도구와 독립적인 제공업체 불문 검색 호출이다.
이는 이제 팀이 더 넓은 Cloudflare 플랫폼 안에서 두 가지 검색 패턴을 사용할 수 있음을 뜻한다. 모델 제공업체의 네이티브 도구 동작을 유지하거나, 새로운 독립형 API를 사용할 수 있다. 올바른 선택은 이식성, 제어 수준, 그리고 팀이 직접 관리하려는 오케스트레이션의 범위에 달려 있다.
이 메커니즘은 소박한 API 추가처럼 보인다. 하지만 아키텍처 관점에서는 검색에 추론, 스토리지, 큐 및 기타 조합 가능한 서비스와 동일한 지위를 부여한다. 에이전트는 최신 웹 정보를 특정 모델에 묶인 특수 기능이 아니라 인프라로 취급할 수 있다.
AI Gateway Web Search가 옵저버빌리티의 중요성을 높인다
중앙화된 로그는 팀이 생성된 주장과 이를 뒷받침한 정확한 검색 단계를 연결할 수 있을 때 가장 큰 가치를 발휘한다.
Cloudflare는 AI Gateway를 모델 애플리케이션의 컨트롤 플레인으로 제시한다. 이미 요청 가시성, 보안 제어, 사용량 관리 기능을 제공한다. 검색 기능이 추가되면서, 그 옵저버빌리티는 답변의 최신성을 좌우하는 경우가 많은 단계까지 확장된다.
모델은 신중하게 추론하더라도 증거가 불완전하면 잘못된 응답을 생성할 수 있다. 검색은 오래된 페이지, 복제된 기사, 또는 적절한 어휘를 사용하지만 다른 주제를 다루는 결과를 반환할 수 있다. 운영자는 이러한 실패를 구별하기 전에 먼저 이를 확인할 수 있어야 한다.
요청 식별자와 지연 시간 메타데이터는 출발점을 제공한다. 이를 통해 느리거나 실패한 검색을 특정 에이전트 실행과 연관 지을 수 있다. 로그는 애플리케이션이 불필요한 질의를 발행하는지, 또는 같은 페이지를 반복적으로 가져오는지도 보여줄 수 있다.
하지만 검색 트래픽을 기록하면 그 자체로 거버넌스 문제가 발생한다. 사용자 질의에는 기밀 계획, 고객 이름, 보안 사고, 의료 관련 우려 또는 내부 프로젝트 세부 정보가 드러날 수 있다. 따라서 중앙화된 게이트웨이는 접근 경계와 보존 정책을 명확히 해야 한다.
Cloudflare는 이 서비스를 통해 라우팅되는 요청에 대해 세 출시 파트너 모두 Zero Data Retention을 지원한다고 밝혔다. Zero Data Retention은 적용되는 계약 조건에 따라 제공업체가 처리 후 요청 데이터를 보관하지 않는다는 뜻이다. 이는 전체 애플리케이션 전반의 모든 개인정보 보호 문제에 자동으로 답을 주지는 않는다.
개발자는 질의에 어떤 정보가 들어갈지를 여전히 통제한다. Cloudflare는 여전히 게이트웨이와 그 로그를 운영한다. 최종 모델 제공업체는 애플리케이션이 전송하는 검색 컨텍스트를 받는다. 각 단계에는 의도적인 데이터 정책이 필요하다.
BYOK(Bring-your-own-key) 지원 역시 신중한 구성이 필요하다. Cloudflare 문서에 따르면 명시적 별칭을 지정한 경우 해당 키를 사용할 수 없으면 요청이 실패한다. 명시적 별칭이 없으면 게이트웨이는 구성된 기본 키 또는 사용 가능한 게이트웨이 크레딧을 사용할 수 있다.
이 동작은 편의성을 제공하지만, 팀은 폴백이 허용 가능한지 결정해야 한다. 규제 대상 워크로드에는 특정 제공업체 계약이 필요할 수 있다. 기술적 결과가 유효하더라도, 다른 상업적 경로로 조용히 전환하는 방식은 내부 통제와 충돌할 수 있다.
옵저버빌리티는 과도한 민감 데이터 저장 없이도 평가에 필요한 충분한 세부 정보를 보존해야 한다. 횟수와 지연 시간만으로는 관련성 실패를 설명할 수 없다. 전체 질의와 결과 스니펫은 더 큰 진단 가치를 제공하지만 노출도 역시 높인다.
올바른 균형은 애플리케이션마다 다르다. 공개 뉴스 어시스턴트는 내부 법률 조사 시스템보다 더 많은 검색 세부 정보를 기록할 수 있다. Cloudflare의 장점은 관리자가 이러한 차이를 이해하기 쉬운 정책으로 표현할 수 있는지에 달려 있다.
운영 제어에는 남용 방지도 포함된다. 도구 루프에 빠진 에이전트는 반복 검색을 대량으로 발행할 수 있다. 검색은 에이전트 활동의 상당한 비중을 차지할 수 있으므로, 속도 제한, 요청 예산, 애플리케이션별 권한이 중요하다.
중앙화된 로그는 이러한 동작을 식별하는 데 도움이 된다. 하지만 그 자체로 이를 막지는 못한다. 팀은 에이전트 프레임워크 내에 최대 도구 호출 횟수, 타임아웃, 도메인 정책, 명확한 중단 조건을 여전히 마련해야 한다.
보안에도 같은 원칙이 적용된다. 검색 결과에는 신뢰할 수 없는 텍스트가 포함되며, 웹페이지에는 에이전트를 조작하려는 지시가 들어갈 수 있다. 프롬프트 인젝션은 외부 콘텐츠가 애플리케이션의 의도된 규칙을 무시하도록 시도할 때 발생한다.
정규화된 검색 응답이 악성 콘텐츠를 무력화하지는 않는다. 모델은 여전히 적대적 스니펫을 지시로 해석할 수 있다. 개발자는 검색된 자료를 증거로 표시하고, 검색 이후 가능한 작업을 제한하며, 도구가 활성화된 컨텍스트에 비밀 정보를 넣지 않아야 한다.
새 API는 이러한 관행을 중앙화하기 쉽게 만들지만, 이를 대체할 수는 없다. Cloudflare는 더 나은 제어 지점을 판매하고 있다. 그 지점 뒤에서 작동하는 에이전트의 행동에 대한 책임은 고객에게 남는다.
크롤러 규칙은 유용한 약속이자 어려운 시험을 만든다
Cloudflare는 이번 출시를 책임 있는 크롤링과 연결하고 있지만, 규정 준수가 완전하고 정확하며 대표성 있는 검색 결과를 보장하지는 않는다.
회사는 참여 제공업체에 크롤러 식별, robots.txt 준수, 검색된 콘텐츠 링크 포함을 요구한다. 또한 제공업체의 크롤러는 검증된 봇에 대한 Cloudflare의 요구사항을 충족해야 한다고 밝혔다.
검증된 봇은 Cloudflare가 신원을 확인한 자동화 서비스다. 검증은 사이트 운영자가 크롤러 허용 또는 차단 여부를 결정할 때 더 명확한 신호를 제공한다. 검색 회사를 대표한다고 주장하는 식별되지 않은 트래픽과 비교해 모호성을 줄인다.
Cloudflare는 이를 AI 검색 서비스와 퍼블리셔 간의 더 공정한 관계를 위한 표준으로 제시한다. 이 정책은 제작자에게 누가 자신의 페이지에 접근하는지에 대한 더 많은 가시성을 제공한다. 소스 링크는 사용자도 기반 자료를 검토할 수 있게 한다.
이러한 약속은 이번 출시를 불투명한 스크래핑과 구분 짓는다. 퍼블리셔들이 AI 시스템이 웹 콘텐츠를 획득하고, 요약하고, 상업화하는 방식을 점점 더 문제 삼고 있기 때문에 특히 중요하다. 검색 제공업체에는 접근이 필요하지만, 사이트 소유자는 강제 가능한 통제를 원한다.
그 대가는 존중하는 크롤링이 커버리지를 줄일 수 있다는 점이다. 일부 사이트는 자동화된 접근을 차단하거나 특정 봇을 제한하며, 자료를 인증 뒤에 둔다. 검색 결과는 제공업체가 색인화했고 계속 사용할 수 있도록 허용된 페이지에만 반영될 수 있다.
따라서 세 제공업체는 웹에 대해 서로 다른 관점을 반환할 수 있다. 이들은 별도의 색인, 순위 시스템, 갱신 일정, 스니펫 생성 프로세스를 운영한다. 공통 API 스키마는 이러한 구현 세부 사항을 숨기지만 그 효과까지 없애지는 않는다.
소스 귀속은 또 다른 과제를 제시한다. URL을 반환하는 것은 필요하지만, 생성된 답변이 해당 페이지를 정확히 반영한다는 증거는 아니다. 애플리케이션은 각 주장과 이를 뒷받침하는 결과 간의 연결을 보존해야 한다.
최종 모델은 어떤 소스도 명시적으로 뒷받침하지 않는 진술로 여러 스니펫을 결합할 수 있다. 또한 게시 날짜를 간과하거나 업데이트된 문서를 이전 버전과 혼동할 수도 있다. 인용의 존재를 인용의 정확성과 혼동해서는 안 된다.
검색 순위는 추가적인 불확실성을 더한다. 고도로 최적화된 페이지가 1차 출처보다 높은 순위에 오를 수 있다. 원본 보도보다 신디케이트된 복제본이 더 눈에 띄게 나타날 수 있다. 검색된 설명은 전체 페이지에서 분명해지는 단서를 생략할 수 있다.
Cloudflare의 현재 API는 전체 페이지 검증이 아니라 검색 결과를 반환한다. 높은 신뢰도가 필요한 애플리케이션은 중요한 페이지를 가져와 내용을 검토하고, 날짜를 비교하며, 1차 문서를 우선해야 한다. 한 번의 검색 호출은 발견이지 증명이 아니다.
지연 시간도 품질 판단에 영향을 줄 수 있다. 에이전트는 종종 응답 시간 예산에 직면하므로, 개발자는 빠른 제공업체를 선택하거나 처음으로 그럴듯해 보이는 결과에서 멈출 수 있다. 이러한 최적화는 여러 소스를 통해 민감한 주장을 검증해야 하는 필요성과 충돌할 수 있다.
여기서 베타 상태가 중요하다. Cloudflare는 인터페이스와 제공업체 특성을 문서화했지만, 비교 관련성에 관한 공개 증거는 여전히 제한적이다. 개발자는 제공업체 설명을 독립적으로 검증된 성능 순위가 아니라 설계 지침으로 다뤄야 한다.
모든 애플리케이션에 적용되는 보편적 벤치마크도 없다. 소프트웨어 문서에서 좋은 성과를 내는 제공업체가 지역 뉴스, 과학 문헌 또는 잘 알려지지 않은 기업 공시에서는 어려움을 겪을 수 있다. 팀은 자신의 예상 질의에서 추출한 테스트 세트가 필요하다.
유용한 평가는 올바른 페이지가 나타나는지, 얼마나 높은 순위에 오르는지, 얼마나 최신인지, 스니펫이 핵심 맥락을 유지하는지를 기록해야 한다. 또한 적대적 페이지, 모호한 이름, 답변이 변하는 질의도 테스트해야 한다.
정확한 상업 조건이 다르더라도 비용은 이 평가에 포함되어야 한다. 에이전트 워크플로는 하나의 사용자 질문을 여러 번의 검색과 모델 호출로 늘릴 수 있다. 팀은 개별 요청을 비교하기보다 전체 작업 비용을 측정해야 한다.
Cloudflare의 무마진 포지셔닝은 한 가지 우려를 줄이지만, 가치를 결정하지는 않는다. 더 비싼 검색 경로도 추가 호출을 피하거나 답변 정확도를 높인다면 가치가 있을 수 있다. 반대로 저렴한 경로는 부실한 결과가 재시도를 유발할 때 비용이 커질 수 있다.
크롤러 표준은 여전히 발표의 의미 있는 부분이다. Cloudflare는 사이트와 자동화된 클라이언트 사이의 위치를 활용해 참여 요건을 설정하고 있다. 시험대는 이 규칙이 개발자가 알아차리지 못하는 사각지대를 만들지 않으면서 책임 있는 검색을 만들어내는지 여부다.
베타 출시 이후 개발자가 주시해야 할 점
다음 단계는 Cloudflare Web Search API가 지속 가능한 게이트웨이 기본 요소가 될지, 아니면 파트너 엔드포인트를 감싼 편리한 래퍼로 남을지를 보여줄 것이다.
첫 번째 신호는 네이티브 서버 도구의 도입이다. Cloudflare는 웹 검색이 AI Gateway 컨트롤 플레인에 직접 통합되는 최초의 도구 중 하나가 될 것이라고 밝혔다. 이 출시가 이루어지면 개발자가 현재 유지하는 오케스트레이션 코드를 줄일 수 있다.
유용한 서버 도구 구현은 함수 호출을 숨기는 것 이상을 해야 한다. 개발자는 도구 권한, 최대 사용 횟수, 재시도, 타임아웃, 결과 출처, 제공업체 선택을 어떻게 처리하는지 살펴봐야 한다. 이러한 제어 기능은 팀이 이를 프로덕션 에이전트에서 안전하게 사용할 수 있는지를 결정한다.
서버 도구가 모델 전반에서 공통 동작을 유지한다면 Cloudflare의 게이트웨이 논지는 더 강해진다. 플랫폼은 모델 접근과 검색 오케스트레이션을 모두 담당하게 된다. 각 모델에 여전히 상당한 맞춤형 처리가 필요하다면, 이점은 청구와 옵저버빌리티로 좁아진다.
두 번째 신호는 측정 가능한 제공업체 이식성이다. Cloudflare의 공통 응답 형식은 API 수준에서 전환을 단순하게 보이게 한다. 실제 이식성에는 비교 가능한 결과 품질, 예측 가능한 오류 처리, 프로덕션 부하에서의 안정적인 동작이 필요하다.
팀은 동일한 질의 세트를 Ceramic.ai, Exa, Linkup을 통해 실행해야 한다. 소스 커버리지, 최신성, 순위, 지연 시간, 스니펫 유용성을 비교해야 한다. 또한 모호하거나 적대적인 질문에서 결과가 어떻게 달라지는지도 검토해야 한다.
개발자가 이를 의도적으로 선택할 수 있을 때에만 제공업체별 강점이 가치가 있다. 대부분의 애플리케이션이 평가 없이 기본값에 머문다면 마켓플레이스 요소의 의미는 줄어든다. 팀이 워크로드별로 라우팅한다면 Cloudflare는 방어 가능한 조정 역할을 확보한다.
세 번째 신호는 경쟁사의 대응이다. Vercel은 이미 게이트웨이 수준의 검색 도구를 제공하고 있으며, 모델 기업들은 네이티브 브라우징 기능을 계속 개선하고 있다. 다른 클라우드 플랫폼 역시 자체 제어 영역 안에서 검색, 모델, 에이전트 런타임을 결합할 수 있다.
이들 경쟁사가 더 많은 독립 검색 제공업체, 강화된 평가 도구 또는 통합 인용 형식을 추가하는지 지켜볼 필요가 있다. 이러한 대응은 제공업체 중립적 검색이 표준 게이트웨이 기능으로 자리 잡을지, 아니면 일시적인 차별화 요소에 그칠지를 보여줄 것이다.
개발자는 봇 정책과 퍼블리셔 제어 방식의 변화도 주시해야 한다. 검색 품질은 유용한 소스에 지속적으로 접근할 수 있는지에 달려 있다. 크롤링 가능한 콘텐츠와 제한된 콘텐츠 간 격차가 커지면, 각 크롤러가 명시된 규칙을 따르더라도 모든 제공업체에 영향을 미칠 것이다.
초기 시험에서는 답변이 자주 바뀌고 식별 가능한 1차 출처가 있는 작업을 선택하라. 릴리스 노트, 서비스 상태, 제품 문서, 공개 공시는 광범위한 의견 질문보다 더 명확한 평가 기준을 제공한다.
검색을 사용자 대면 에이전트에 통합하기 전에 작은 벤치마크를 만들어야 한다. 예상 출처, 허용 가능한 게시 날짜, 그리고 올바른 답변에 반드시 포함되어야 할 사실을 기록하라. 이후 검색과 생성을 각각 분리해 테스트한다.
가능하다면 애플리케이션 인터페이스에 출처 URL을 보존하라. 특히 답변이 중요한 결정에 영향을 줄 때 사용자는 근거를 검토할 수 있어야 한다. 인용은 응답 전체를 장식하는 요소가 아니라 특정 주장을 뒷받침해야 한다.
각 작업에 검색 예산을 설정하라. 반복 쿼리를 제한하고, 순환적인 도구 호출을 중단하며, 에이전트가 외부 작업을 수행하기 전에는 추가 확인을 요구해야 한다. 검색은 모델에 새로운 정보를 제공하지만, 그 정보에 권한을 부여하지는 않는다.
Introducing Web Search API via AI Gateway 출시는 궁극적으로 개발자에게 검색이 어디에 속하는지 다시 생각해 보라고 요구한다. 검색은 모델의 기능인가, 공급업체와의 직접적인 관계인가, 아니면 애플리케이션 플랫폼이 제어하는 공유 서비스인가?
Cloudflare는 공유 서비스 모델에 대해 설득력 있는 근거를 제시했다. 베타 버전은 세 제공업체, 하나의 인터페이스, 게이트웨이 로그, 자격 증명 관리, 명시적인 크롤러 표준을 결합한다. 그 가치는 신뢰성, 검색 품질, 그리고 약속된 서버 도구 계층에 달려 있다.
이미 AI Gateway 또는 Workers를 사용하는 팀이라면, 다음 실질적 단계는 실제 쿼리를 대상으로 한 통제된 평가다. 세 제공업체를 비교하고, 모든 출처를 검토하며, 완전한 작업 결과를 측정하라. 독립적인 검색 계층이 에이전트를 개선할 것인가, 아니면 또 하나의 게이트웨이 경계가 제거하는 일보다 더 많은 일을 만들어낼 것인가?
