10월 2일에 Cloudflare가 Web Search API를 오픈베타로 열었습니다. Ceramic.ai·Exa·Linkup 세 검색 provider를 같은 API 모양으로 쓰고, 요청은 AI Gateway 안에서 logging·analytics·billing·access control로 관리됩니다.

짧은 뉴스 같지만 의미는 큽니다. 웹 검색이 에이전트 도구 하나가 아니라 모델 inference처럼 관측하고 교체하고 비용을 관리해야 하는 infrastructure layer가 되고 있습니다.

뭐가 나왔나: 3 provider, 3 경로

항목 내용
Provider Ceramic.ai, Exa, Linkup (3종 중 선택)
호출 경로 AI Gateway 직접 / REST 엔드포인트 / Workers 바인딩(한 줄 호출)
관측 모델 추론 호출과 같은 Gateway 로그·분석에 표시
과금 기존 AI Gateway 크레딧에서 차감
데이터 3사 모두 Cloudflare 경유 요청에 Zero Data Retention 지원, BYOK 가능 
// Workers 바인딩 예시 (공식 문서 형태)
const response = await websearch({
  gatewayId: "default",
  query: "What are some fun things to do in Salt Lake City as fall approaches?",
  provider: "exa",
  limit: 5,
});
const results = await response.json();

에이전트 입장에서 반가운 문장이 changelog에 있습니다. "URL을 추측하거나 모델의 학습 컷오프에 의존하는 대신" 실시간 정보에 답을 grounding한다는 것입니다. 환각으로 URL을 지어내는 실패를 검색 계층에서 막는 구조입니다.

왜 인프라인가: RAG의 검색 단계가 밖으로 나왔다

RAG 구조를 떠올려보세요. 파싱·청킹·검색·재순위·생성 중 검색은 내 문서용이었습니다. 이제 웹 검색도 같은 대우를 받습니다.

예전: 검색 = 에이전트가 부르는 함수 1개 (로그도 과금도 따로)
지금: 검색 = Gateway 안의 일원 (로그·분석·과금·접근통제 일괄)
→ provider를 코드 수정 없이 교체 가능
→ 품질·지연·비용을 추론과 같은 표에서 비교

RAG 실패 분석에서 "검색이 1등 범인일 때만 임베딩을 만져라"고 했는데, 웹 검색도 똑같습니다. provider별 품질·지연·비용을 재고 나서 바꾸는 순서입니다.

고르는 5지표: 같이 기록하세요

provider 비교표 (매주 1회 갱신):
[ ] quality: 내 질문 20개에서 근거 적중률
[ ] latency: p50·p95 응답 시간
[ ] cost: 1천 회당 비용 (Gateway 크레딧 기준)
[ ] citation quality: 제목·URL·스니펫이 답에 바로 인용되는가
[ ] data retention: ZDR 지원 여부 + BYOK 가능 여부

특히 마지막 2개가 2026년식입니다. 인용 품질은 금융 글에서 말한 "출처가 답의 일부"와 연결되고, ZDR·BYOK는 보안 글의 데이터 통제와 연결됩니다. 검색 선택이 보안 선택이 되는 시대입니다.

CodeBridge Mini Lab: 3사 20문항 비교

① 내 질문 20개를 뽑는다 (업무 질문 + 최신 정보 질문 반반)
② 3 provider에 같은 20개를 돌린다 (limit·옵션 고정)
③ 5지표를 기록한다 (위 표)
④ 판정:
   - 적중률 동점이면 지연·비용으로 선택
   - 최신 정보 질문에서만 차이 나면 용도 분리 (기본 1개 + 최신용 1개)
   - Gateway 로그로 주 1회 드리프트 확인 (어느 날 갑자기 나빠지는지)

프롬프트 캐싱처럼 반복 질문은 캐시와 함께 보면 더 정확합니다. 자주 묻는 것은 검색 전에 캐시 적중부터 확인하는 순서입니다.

결론: 검색도 슬롯이다

게이티드 모델 글에서 모델을 슬롯으로 두라고 했습니다. 검색도 같습니다.

특정 provider에 의존하지 말고, Gateway 뒤의 교체 가능한 슬롯으로 두라.

오늘 할 일은 하나입니다. 우리 에이전트의 검색 호출이 어디에 로그되고 얼마가 드는지 확인하는 것. 그 숫자가 보이면 검색은 도구에서 인프라가 됩니다. 인프라는 관리할 수 있습니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

검색·파싱·인용까지 실무 RAG를 설계해보고 싶다면, Classic RAG에서 GraphRAG·Agentic RAG로 확장하는 과정이 이 글의 provider 비교와 바로 이어집니다.