AI 에이전트의 404 오류와 지식 단절 문제를 겨냥한 검색 API 공개
클라우드플레어(Cloudflare)가 연례 행사인 '생일 주간(Birthday Week) 2026' 기간 중 AI 게이트웨이(AI Gateway)를 통해 이용할 수 있는 웹 검색 API(Web Search API)를 오픈 베타 형태로 공개했습니다. 이번 발표는 Michelle Chen, Sam Else, Gabriel Massadas 등 클라우드플레어 담당 팀의 주도로 이뤄졌으며, 거대언어모델(LLM)과 자율 에이전트가 최신 웹 정보를 조회할 때 겪던 구조적 비효율을 해소하는 데 초점을 맞추었습니다.
기존 AI 에이전트는 실시간 웹 페이지 조회가 필요할 때 주소를 임의로 추측한 뒤 curl 형태의 도구 호출을 실행하는 경우가 많았습니다. 이 과정에서 존재하지 않는 주소로 인한 404 Not Found 오류가 빈번히 발생했습니다. 또한 모델은 학습 시점의 지식 마감(Cutoff date) 이후에 일어난 최신 사건, 변경된 기술 문서, 실시간 뉴스 등에 접근하기 어려웠습니다. 클라우드플레어는 이러한 한계를 극복하기 위해 검증된 검색 제공자를 연결하는 통합 검색 계층을 마련했다고 설명했습니다.
Ceramic.ai·Exa·Linkup과의 제휴 및 크롤링 윤리 표준 설정
웹 검색 API의 검색 엔진 생태계 구축을 위해 클라우드플레어는 Ceramic.ai, Exa, Linkup 등 3개 전문 검색 업체와 초기 파트너십을 체결했습니다. 이 중 Ceramic.ai는 기본 제공자(Default provider)로 지정되었으며, 400억 개 이상의 독립 웹 페이지 색인을 바탕으로 페이지당 최대 8,000자의 설명 스니펫을 전달해 저지연·저비용 에이전트 작업에 맞췄습니다. Exa는 정교한 구조화 검색과 하이라이트 기능을 지원하며, Linkup은 빠른 응답을 위한 고속 모드(Fast mode) 등을 제공합니다.
클라우드플레어는 이번 연동에 엄격한 웹 크롤링 및 데이터 윤리 기준을 도입했다고 밝혔습니다. 모든 검색 파트너는 클라우드플레어 개발자 문서에 명시된 '인증된 봇(Verified Bots)' 규격을 의무적으로 준수해야 합니다. 이에 따라 각 파트너 크롤러는 robots.txt 정책을 준수하고 크롤러 식별자를 명확히 공개해야 하며, 반환되는 검색 결과에는 인용 출처 URL이 반드시 포함되어야 합니다. 또한 3개 파트너사 모두 클라우드플레어를 경유하는 요청에 대해 사용자 데이터를 보관하지 않는 '데이터 무보관(Zero Data Retention, ZDR)' 정책을 적용했습니다.
단일 제어 평면 기반의 REST API·Workers 연동 및 요금 체계
새로운 웹 검색 API는 클라우드플레어 AI 게이트웨이의 제어 평면(Control Plane)에 흡수되어 관측성(Observability), 보안, 통합 결제를 공유합니다. 개발자는 클라우드플레어 표준 REST 엔드포인트에 계정 토큰과 원하는 공급자명을 전달해 외부 백엔드나 모바일 애플리케이션에서 직접 호출할 수 있으며, 클라우드플레어 워커스(Workers) 환경에서는 'env.AI.websearch()' 형태의 단일 바인딩 코드로 검색 기능을 애플리케이션에 결합할 수 있습니다. AI 플레이그라운드(AI Playground) 콘솔을 통한 사전 테스트도 지원됩니다.
비용 측면에서 클라우드플레어는 검색 API 호출에 별도의 추가 마크업(Markup)을 붙이지 않는다고 발표했습니다. 이용자는 AI 게이트웨이 크레딧에서 파트너사의 공식 정가(List API pricing)대로 통합 차감되는 방식을 선택하거나, 기존 파트너사 계정의 API 키를 직접 연동하는 BYOK(Bring-Your-Own-Key) 방식을 선택해 기존 기업 계약 조건을 그대로 유지할 수 있습니다.
인프라 제어 관점의 효용과 실무 아키텍처 개선 효과
엔지니어링 실무 관점에서 이번 출시의 가장 큰 장점은 개별 모델 공급자나 서드파티 툴킷에 분산되어 있던 RAG(검색 증강 생성) 전처리 파이프라인을 엣지 인프라 레벨로 일원화했다는 점입니다. 지금까지 AI 에이전트를 구축할 때 개발팀은 별도의 웹 스크래퍼를 호스팅하거나 타사 검색 API별로 서로 다른 SDK, 인증 방식, 에러 핸들링 코드를 작성해야 했습니다. AI 게이트웨이를 단일 창구로 삼으면 호출 성공률 모니터링, 토큰 사용량 추적, 접근 제어를 중앙에서 일괄 관리할 수 있습니다.
또한 클라우드플레어가 인증된 봇 표준을 검색 파트너에 강제한 점은 콘텐츠 원작자와 플랫폼 간의 긴장을 완화하려는 실용적 접근으로 평가됩니다. 단순 무단 스크래핑을 통한 환각 방지가 아니라, 원본 출처 링크를 명시하도록 강제함으로써 생성 결과물의 근거(Grounding) 검증이 투명해집니다. 이는 기업 내부에서 AI 답변의 법적·윤리적 신뢰성을 확보해야 하는 감사 조직 입장에서도 긍정적인 평가 요소입니다.
브라우저 자동화의 부재와 로깅 설정 시 검토해야 할 제약 사항
다만 실무 적용을 검토하는 팀은 이 서비스가 제공하는 기술적 경계를 정확히 구분해야 합니다. 웹 검색 API는 주어진 질의어에 맞춰 구조화된 텍스트 스니펫과 링크를 반환하는 '정보 검색(IR)' API일 뿐, 헤드리스 브라우저를 띄워 자바스크립트를 렌더링하거나 로그인 세션을 처리하고 버튼을 클릭하는 '브라우저 자동화(Browser Automation)' 도구가 아닙니다. 따라서 복잡한 동적 웹 애플리케이션과의 심층 상호작용이 필요한 태스크라면 별도의 브라우저 렌더링 계층을 병행 설계해야 합니다.
보안 및 데이터 거버넌스 측면에서도 유의할 점이 있습니다. 파트너사 수준에서는 데이터를 저장하지 않는 'ZDR'이 보장되지만, 개발사가 클라우드플레어 AI 게이트웨이 자체의 관측성 로그 기능을 활성화해 둔 경우 사용자의 검색 질의어와 응답 페이로드가 기업 계정 내부 로그에 그대로 남을 수 있습니다. 민감 정보를 다루는 환경이라면 게이트웨이 차원의 페이로드 로깅 정책을 사전에 검토해야 합니다. 아울러 별도 코드 작성 없이 게이트웨이가 툴 호출을 대행해 주는 '네이티브 서버 툴(Server Tools)' 기능은 아직 개발 중이므로, 현재 베타 단계에서는 클라이언트나 워커스 코드 단에서 도구 오케스트레이션 로직을 직접 구현해야 한다는 점을 고려해야 합니다.
출처
Cloudflare Blog의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
Introducing Web Search API via AI Gateway (새 창)