클라우드플레어가 AI 에이전트와 애플리케이션이 실시간으로 웹을 검색할 수 있게 해주는 Web Search API를 베타로 내놓았다. 이 기능은 클라우드플레어의 AI Gateway를 통해 제공되며, 모델이 URL을 추측하거나 학습 시점(training cutoff) 이후의 정보를 알지 못하는 한계를 벗어나 답변을 최신 정보에 근거하도록 하는 것을 목표로 한다. 출시 시점 기준으로 Ceramic.ai, Exa, Linkup 세 곳의 검색 제공업체 중 하나를 선택해 사용할 수 있다.
왜 '검색'이 에이전트의 숙제가 되었나
거대 언어 모델은 특정 시점까지의 데이터로 학습되기 때문에, 그 이후에 벌어진 사건이나 최신 문서를 알지 못한다. 실무에서 이 한계는 두 가지 문제로 나타난다. 하나는 모델이 모르는 것을 모른다고 말하는 대신 그럴듯하게 지어내는 환각(hallucination)이고, 다른 하나는 존재하지 않는 URL이나 오래된 정보를 근거로 제시하는 경우다. 이를 보완하려면 외부 검색 결과를 가져와 모델의 답변에 '근거를 대는(grounding)' 과정이 필요한데, 지금까지는 개발자가 직접 검색 제공업체와 계약하고 API를 붙여야 했다.
Web Search API는 바로 이 연결 작업을 클라우드플레어의 게이트웨이 계층으로 흡수한 형태다. 에이전트가 사용자 질문에 답하기 전에 웹을 조회하고, 그 결과를 응답의 근거로 삼는 이른바 RAG(검색 증강 생성) 패턴을 별도 인프라 없이 구성할 수 있게 된다. 여러 검색 사업자를 하나의 인터페이스 뒤에 두었다는 점에서, 모델뿐 아니라 검색 소스까지 선택지로 추상화하려는 시도로 읽힌다.
세 개의 제공업체, 그리고 데이터 처리 기준
이번 베타에서 선택 가능한 제공업체는 Ceramic.ai, Exa, Linkup 세 곳이다. 클라우드플레어는 이 세 곳 모두 자사를 경유하는 요청에 대해 Zero Data Retention(무보존)을 지원한다고 밝혔다. 즉 클라우드플레어를 통해 들어온 검색 요청의 데이터가 제공업체 측에 남지 않는다는 의미로, 민감한 질의를 다루는 사내 도구나 규제 산업 애플리케이션에서 특히 중요하게 볼 대목이다.
또한 세 업체 모두 클라우드플레어가 정의한 '검증된 봇 크롤링(verified bot crawling)' 표준을 준수하기로 약속했다고 한다. 이는 검색 과정에서 이뤄지는 웹 크롤링이 클라우드플레어가 식별 가능한 정상 봇의 규칙을 따른다는 뜻으로, 콘텐츠 원 사이트 입장에서 출처가 불분명한 자동 수집 트래픽에 대한 우려를 일부 낮추는 장치로 볼 수 있다.
과금과 로그는 AI Gateway로 일원화
운영 측면에서 눈에 띄는 설계는 모든 요청이 AI Gateway를 거친다는 점이다. 이에 따라 검색 요청이 게이트웨이 로그에 그대로 기록되어, 에이전트가 언제 무엇을 검색했는지 추적하고 관찰(observability)하기가 쉬워진다. 요청 비용은 AI Gateway 크레딧에서 차감되며, 각 제공업체의 공식 API 정가가 그대로 적용되고 별도의 추가 마진은 붙지 않는다고 클라우드플레어는 설명했다. 모델 호출과 검색 호출의 비용을 한곳에서 관리할 수 있다는 점은 다수의 외부 서비스를 조합해 에이전트를 운영하는 팀에 실질적인 편의가 된다.
여기에 더해, 자신이 이미 보유한 제공업체 API 키를 가져와(bring your own key) 사용할 수도 있다. 이미 Exa나 Linkup 등과 직접 계약을 맺고 있는 조직이라면 기존 요금 체계를 유지하면서 게이트웨이의 로깅과 라우팅만 활용하는 구성이 가능하다는 의미다.
실무자가 짚어둘 지점과 한계
정리하면 Web Search API는 '검색 소스 선택, 데이터 비보존, 과금·로그 일원화'를 묶어 에이전트의 웹 접근을 표준화하려는 제품이다. 여러 제공업체를 코드 수정 없이 바꿔 끼울 수 있다면, 특정 검색 사업자에 대한 종속을 줄이면서 품질과 비용을 비교·전환하는 운영이 수월해진다. 반면 현 시점에서 공개된 정보는 제한적이라는 점도 분명히 해둘 필요가 있다. 세 제공업체의 검색 품질 차이, 지원 언어와 한국어 검색 성능, 지역별 결과의 신뢰도, 응답 지연과 처리량 같은 지표는 발표 내용만으로는 판단할 수 없다.
무엇보다 이 기능은 아직 베타 단계다. API 명세나 가격, 제공업체 구성이 정식 출시 과정에서 달라질 여지가 있으므로, 당장 프로덕션에 올리기보다는 내부 프로토타입에서 검색 근거의 정확도와 비용 추이를 직접 측정해 보는 접근이 현실적이다. 도입을 검토하는 팀이라면 무보존 정책의 실제 적용 범위와 로그에 남는 데이터의 민감도를 함께 확인한 뒤, 자사 데이터 거버넌스 기준에 맞는지를 먼저 따져보는 것이 순서다.