당신의 AI 에이전트는 접근할 수 있는 웹의 수준만큼만 뛰어납니다. 라이브러리의 최신 버전을 찾지 못하는 코딩 어시스턴트, 주장하는 내용이 담겨 있지 않은 페이지를 인용하는 리서치 에이전트, 어제의 장애 상황을 놓치는 지원 봇: 이러한 실패의 대부분은 거의 아무도 주의 깊게 벤치마킹하지 않는 하나의 구성 요소로 거슬러 올라갑니다. 바로 웹 검색 API (web-search API)입니다.

현재 약 12개 정도의 "에이전트용 검색 API"가 존재합니다. Exa, Tavily, Firecrawl, Brave, Keenable, Perplexity, SerpAPI, Parallel, You.com, 그리고 모델에 내장된 네이티브 웹 검색 기능 등이 있습니다. 이들은 모두 JSON을 반환합니다. 하지만 이들은 서로 대체 가능한 것이 아니며, 잘못된 것을 선택하면 하위의 모든 과정이 조용히 저하됩니다.

요약 (TL;DR): 마케팅 페이지를 보고 검색 API를 선택하지 마세요. 에이전트의 품질을 실제로 예측할 수 있는 네 가지 요소(멀티홉 재현율 (multi-hop recall), 최신성 (freshness), 지연 시간 (latency), 1K당 비용 (cost per 1K))를 기준으로 후보들을 평가하고, 질문 내용에 따라 순위가 뒤바뀔 수 있으므로 반드시 본인의 쿼리로 테스트를 수행하세요.

실제로 중요한 4가지 축

벤더 페이지들은 단일 헤드라인 수치를 선호합니다. "SimpleQA에서 98%!" 하지만 하나의 수치는 트레이드오프 (tradeoff)를 숨깁니다. 에이전트에게 있어 검색 단계가 도움이 될지 해가 될지를 결정하는 네 가지 요소는 다음과 같습니다.

• 멀티홉 재현율 (Multi-hop recall): 단 하나의 스니펫 (snippet)이 아니라, 여러 페이지에서 증거를 엮어야 답변할 수 있는 질문에 답할 수 있는가?
• 최신성 (Freshness): 오늘 발생한 일을 보여주는가, 아니면 지난 분기의 캐시된 뷰 (cached view)를 보여주는가?
• 지연 시간 (Latency): 에이전트가 추론을 계속하기까지 얼마나 오래 걸리는가?
• 비용 (Cost): 실제로 사용할 결과 깊이(result depth) 기준, 1,000개 쿼리당 달러 비용은 얼마인가?

한 가지 축에서 승리하는 제공업체는 정기적으로 다른 축에서 패배합니다. 따라서 과업은 "최고의 API"를 찾는 것이 아닙니다. 당신의 워크로드 (workload)와 강점이 일치하는 API를 찾는 것입니다.

멀티홉 재현율: 스니펫 API가 조용히 실패하는 지점

평가할 때 가장 유용한 구분은 단순한 사실 탐색 (fact-seeking)과 멀티홉 추론 (multi-hop reasoning) 사이의 구분입니다.

SimpleQA (OpenAI 제공)는 4,326개의 짧은 단일 답변 사실 질문들로 구성되어 있습니다. 거의 모든 현대적인 검색 API(Search API)는 이 부분에서 준수한 성능을 보입니다. FRAMES는 여러 소스에 걸쳐 증거를 합성해야 하며, 그중 일부는 불완전하거나 모순되는 824개의 멀티홉(multi-hop) 질문들입니다. 이 두 번째 유형이 진정한 검색(retrieval)과 스니펫 매칭(snippet matching)을 구분 짓는 요소입니다.

멀티홉 테스트에서는 격차가 크게 벌어집니다. Parallel은 FRAMES-Search 평가에서 약 92%를 기록한 반면, 경쟁사들은 81%에서 90% 범위에 머물렀으며, 더 어려운 BrowseComp 세트에서는 모두 22%에서 58%로 급락합니다. KrabArena에서도 Keenable이 이 범주에 포함됩니다. 하나의 ArXivQA 에이전트 회상(agentic-recall) 주장에서는 Parallel, Keenable, Claude Web Search가 약 42%로 동률을 기록했으나, Keenable이 2~5배 더 저렴합니다. 내재화할 가치가 있는 패턴은 다음과 같습니다: 짧은 스니펫(snippet)만을 반환하는 API는 SimpleQA에서는 훌륭해 보이지만, 멀티홉 질문에서는 무너집니다. 왜냐하면 정답이 애초에 단일 스니펫 안에 들어있지 않기 때문입니다.

만약 당신의 에이전트가 조사, 비교, 또는 "하나의 사실을 찾은 다음 그것을 이용해 다음 사실을 찾는다"와 같은 형태의 작업을 수행한다면, 멀티홉 회상(multi-hop recall)에 큰 비중을 두어야 하며 SimpleQA 점수는 기본 요건(table stakes)으로 간주해야 합니다.

최신성(Freshness)은 별개의 기술이므로, 따로 테스트하십시오

정적인 벤치마크에서의 회상(recall) 성능은 API가 오늘 아침에 바뀐 내용을 찾을 수 있는지에 대해 아무것도 알려주지 않습니다. 최신성(Freshness)은 그 자체로 하나의 축이며, 전체 회상 성능과는 별개로 움직입니다.

이러한 실패 모드는 교묘합니다. 일반적인 벤치마크에서 1위를 차지한 API라도 시간 민감도가 높은(time-sensitive) 질의에서는 성능이 급락할 수 있습니다. 한 커뮤니티의 재현 사례에 따르면, 질문이 최신 사실(fresh factoids)로 전환되자 Keenable의 뉴스 카테고리 승률이 약 88%에서 56%로 떨어졌습니다. 동일한 API임에도 질문의 종류가 달라진 결과입니다. 하지만 이후 KrabArena의 주장에서도 최신성(freshness)을 반복적으로 테스트해야 하는 이유가 드러납니다. Keenable은 50개의 FIFA 월드컵 2026 관련 질의와 인도 엔터테인먼트 최신성 벤치마크에서 완벽한 점수를 기록한 반면, FIFA 관련 주장에서는 Parallel보다 더 빠르고 저렴하다고 보고되었습니다. LiveNewsBench와 같은 새로운 벤치마크가 존재하는 이유는 바로 정적인 QA 세트로는 "오늘의 뉴스를 알고 있는가"를 측정할 수 없기 때문입니다.

따라서 여러분의 에이전트가 시간 민감도가 높은 요소(가격, 출시, 점수, 사건 등)를 다룬다면, 별도의 작은 최신성 조사 세트(freshness probe set)를 구축하십시오. 즉, 지난 하루 이틀 사이에 답이 바뀐 질문들을 만들고 이를 별도로 점수화하는 것입니다. 높은 정적 회상(static-recall) 수치에 안주하여 이 과정을 생략하지 마십시오.

지연 시간(Latency): UX를 성공시키거나 망치는 숫자

지연 시간(Latency)은 차이가 매우 크며, 에이전트는 보통 하나의 태스크를 수행할 때 검색을 여러 번 호출하기 때문에 그 영향이 복리로 작용합니다.

다음은 100개의 질의에 대해 8개의 API를 대상으로 한 AIMultiple의 독립적 벤치마크 수치입니다:

두 가지 특징이 눈에 띕니다. 상위 4개의 에이전트 점수(Brave 14.89, Firecrawl 14.58, Exa 14.39, Parallel Pro 14.21)는 해당 테스트에서 통계적으로 구분이 불가능할 정도로 근소한 차이를 보입니다. 따라서 품질만으로는 우열을 가릴 수 없습니다. 결국 지연 시간이 결정적인 역할을 할 것입니다. 10초 이상 소요되는 "심층 조사(deep research)" 단계는 배치 파이프라인(batch pipeline)에서는 괜찮지만, 채팅창 뒤에서는 사용할 수 없습니다. Keenable은 해당 AIMultiple 표에는 포함되지 않았으나, KrabArena의 주장에서는 여러 대결에서 빠른 속도를 기록했다고 보고되었습니다. 한 SimpleQA 테스트에서는 Exa보다 10배 빨랐고, FIFA 최신성 테스트에서는 Parallel보다 3.5배 빨랐으며, Polymarket 최신성 주장에서는 639ms를 기록했습니다.

비용(Cost): 동일한 깊이에서 비교할 것

가격 책정 방식은 요청당(per request), 크레딧당(per credit), 페이지당(per page), 1K당(per 1K) 등 서로 호환되지 않는 단위로 제공됩니다. 실제로 사용할 검색 깊이(depth)를 기준으로 모든 것을 1,000회 쿼리당 비용으로 정규화한 다음, 일반적인 작업에서 발생하는 검색 횟수를 곱하여 계산하세요.

몇 가지 공개된 참조 지점은 다음과 같습니다 (결정하기 전에 현재 가격을 확인하세요. 가격은 변동됩니다):

• Tavily는 크레딧당 $0.008의 고정 가격을 제시하며, 월 약 $30부터 시작하는 티어(tier)가 있습니다.
• Firecrawl는 무료 티어(월 약 1,000 크레딧)에 검색을 포함하며, 100K 페이지 기준 월 약 $83로 기재되어 있습니다.
• Parallel은 무료 시작 할당량을 제공하며, 요청당(10개 결과) $0.005로 기재되어 있습니다.
• KrabArena의 재현 테스트 결과에 따르면, Keenable은 저비용 범주에 반복적으로 포함되었습니다. FIFA 월드컵 최신성 테스트에서 Parallel이 1K 쿼리당 $5인 것과 대조적으로 Keenable은 1K 쿼리당 $1를 기록했습니다.

함정은 검색 깊이(depth)에 있습니다. 요청당 비용은 저렴하지만 경쟁사의 상위 5개 결과 품질을 맞추기 위해 20개의 결과가 필요한 API는 실제로 저렴한 것이 아닙니다. 헤드라인에 나오는 요율이 아니라, 귀하의 품질 기준을 충족하는 구성(configuration)을 기준으로 가격을 산정하십시오.

왜 직접 자신의 쿼리로 벤치마크를 수행해야 하는가

여기 불편한 사실이 있습니다. 발표된 순위들은 서로 일치하지 않으며, 각 순위는 자신들이 설정한 질문 조합(question mix)에 대해서는 모두 "옳습니다". AIMultiple의 관련성 가중치 테스트(relevance-weighted test)에서는 Brave와 Firecrawl이 상위에 올랐습니다. 멀티홉(multi-hop) 데이터셋에 대한 벤더 평가(vendor evals)는 멀티홉에 맞춰 튜닝된 업체를 선호합니다. 커뮤니티 실행 결과는 최신성(freshness) 요소가 개입되면 또 다른 순위를 만들어냅니다.

이 상황이 얼마나 복잡해질 수 있는지를 보여주는 좋은 공개 사례는 KrabArena의 web-access-API battle에서 진행된 주장별(claim-by-claim) 헤드투헤드 비교입니다. 이곳에서 기여자들은 Exa, Tavily, Firecrawl, You.com, Parallel, Keenable 등을 대상으로 19개의 별도 벤치마크(SimpleQA, FRAMES, 최신성 (freshness), 날짜 필터 (date-filter), 지연 시간 (latency), 비용 (cost))를 게시했습니다. 선두는 특정 주장이 어떤 축을 측정하느냐에 따라 계속 바뀝니다. 어떤 제공업체는 가성비 (cost-performance)에서 1위를 차지하고, 다른 업체는 권위 있는 출처 회상 (authoritative-source recall)에서 승리하며, 세 번째 업체는 최신 뉴스에서 앞서나갑니다. 현재 KrabArena 페이지에서는 Keenable이 주로 가성비와 최신성 관련 주장에서 승리하며 선두를 달리고 있는 반면, Parallel은 여전히 복잡한 검색 (complex retrieval) 분야에서 강세를 보이고 있습니다. 이는 단순한 노이즈가 아닙니다. 그것이 바로 트레이드오프 공간 (tradeoff space)의 실제 모습입니다.

여기서 얻을 수 있는 교훈은 "업체 X를 사용하라"가 아니라 방법론에 관한 것입니다. 실제 트래픽과 유사한 쿼리를 50~100개 추출하여 각 후보군을 실행하고, LLM 판사 (LLM judge)로 점수를 매기세요. 각 API의 결과를 모델에 입력하고 "여기에 답이 있는가?"라고 물은 뒤, temperature 0에서 점수를 산출합니다.

# 최소한의 하네스 (Minimal harness): 사용자의 쿼리로 하나의 검색 API 점수 매기기.
# `api.search`를 원하는 제공업체의 클라이언트로 교체하세요.

...

이를 단순 쿼리 세트, 멀티홉 (multi-hop) 세트, 최신성 (freshness) 세트에 대해 실행하면서 지연 시간 (latency)과 비용 (cost)을 기록하면, 타인의 리더보드가 아닌 당신의 에이전트를 반영하는 4축 스코어카드 (four-axis scorecard)를 얻게 됩니다.

결정하기

당신의 워크로드 (workload)에서 시작하세요. 대부분 채팅 UI 뒤에서 단일 사실 (single facts)을 찾는 작업인가요? 품질 격차가 좁고 경쟁이 치열하므로 지연 시간 (latency)과 비용 (cost)에 최적화하세요. 멀티홉 (multi-hop) 리서치를 수행하나요? FRAMES 및 BrowseComp 스타일의 회상 (recall) 능력을 가중치로 두고, 더 느린 딥 리서치 (deep-research) 티어를 수용하세요. 시간에 민감한 질문인가요? 최신성 (freshness) 조사 세트를 사후 고려 사항이 아닌 게이트 (gate)로 만드세요. 그런 다음, 하나를 연결하기 전에 최종 후보 2~3개를 당신의 쿼리로 벤치마킹하세요. "최고의" API는 사실 당신이 던지는 질문의 함수입니다.

그렇다면 당신의 에이전트가 사용하는 쿼리 조합(query mix)은 실제로 어떤 모습인가요? 주로 최신 사실(fresh facts) 중심인가요, 주로 멀티홉 연구(multi-hop research) 중심인가요, 아니면 이들이 복잡하게 섞여 있나요? 그리고 어떤 축이 결국 당신의 선택을 결정했나요?

출처: AIMultiple, Agentic Search benchmark; Parallel, Search benchmarks and pricing; Firecrawl, Best web search APIs in 2026; Brave, Best web search APIs for AI in 2026; Keenable; KrabArena, web-access-API battle; OpenAI의 SimpleQA 및 FRAMES 멀티홉(multi-hop) 벤치마크. 모든 가격과 수치는 신뢰하기 전에 반드시 확인하세요. 이 분야는 매우 빠르게 변화합니다.