LLM의 API를 호출하여 앱을 하나쯤은 만들어 본 적은 있지만, Web 검색을 에이전트에 통합해 본 경험은 아직 없는 개발자를 상정하고 있습니다. 구체적으로는 다음과 같은 분들입니다.

• OSS 에이전트를 실행하려고 했더니 TAVILY_API_KEY를 요구받아 거기서 멈춰버린 분

• LangChain의 샘플 코드에 나오는 TavilySearch가 무엇을 하고 있는지 어렴풋이만 알고 있는 분

• Exa와 Tavily라는 이름은 본 적이 있지만, 두 제품이 같은 카테고리에 있는 상품인지 확신이 없는 분

• Exa와 Tavily를 포괄하는 상위 개념에는 입도(Granularity)가 다른 3가지 명칭이 존재한다는 것

• 에이전트와 Web 사이에 끼어 있는 계층이 6가지 유형으로 정리될 수 있다는 것

• 그 6가지 중 무엇을 선택해도 망가지지 않는 코드 작성법

• 각 서비스의 가격 비교 및 벤치마크 순위 소개

• 벡터 DB(Vector DB)를 사용한 사내 문서용 RAG 구축 절차

• 생성형 AI를 위한 콘텐츠 최적화, 이른바 GEO에 관한 이야기

이 섹션에서 알 수 있는 것: 질문에 대한 답변 그 자체입니다.

Exa와 Tavily를 통칭하여 무엇이라 부를 것인가. 조사해 보면 이것은 '답이 하나로 정해지지 않는' 유형의 질문이라는 것을 알 수 있습니다. 입도에 따라 업계에서 사용하는 명칭이 다르기 때문입니다.

가장 자주 사용되는 것은 첫 번째 줄입니다. 더 넓은 범주로서 단순히 'Web 검색 API'라고 부르기도 하지만, 그렇게 하면 후술할 SerpApi와 같은 스크레이퍼(Scraper)형까지 같은 주머니에 담겨 구분이 불가능해집니다.

흥미로운 점은 당사자인 두 회사가 스스로를 어떻게 정의하고 있는가입니다.

Tavily는 자사 블로그의 'Tavily 101'이라는 기사에서 스스로를 "the web access layer for AI agents"라고 정의하고 있습니다. 한국어로 번역하면 'AI 에이전트를 위한 Web 액세스 계층'입니다. 검색 엔진이 아니라 '계층(Layer)'이라고 자처하는 것이 포인트입니다.

Exa는 공식 문서의 서두에서 "a custom search engine built for AIs"라고 자처하고 있습니다. 한국어로 번역하면 'AI를 위해 만들어진 독자적인 검색 엔진'입니다. 이쪽은 '검색 엔진'이라고 자처하고 있습니다.

즉, 당사자들 사이에서도 자기 인식이 어긋나 있습니다. 그렇기 때문에 외부에서 하나의 이름으로 묶기가 어려운 것입니다. 이 기사에서는 그 '묶기 어려움'의 정체를 6가지 분류의 지도로 그려 나가겠습니다.

이 섹션에서 알 수 있는 것: 왜 검색 레이어(Search Layer)라는 개념이 필요하게 되었는가.

이 기사에서는 마지막까지 도서관 비유를 사용하여 이야기를 진행합니다.

LLM은 거대한 도서관에 갇힌 연구자와 같습니다. 장서는 방대하지만, 그 내용은 학습이 끝난 시점에 멈춰 있습니다. 어제 나온 논문도, 오늘 아침 업데이트된 API 레퍼런스도 서가에는 놓여 있지 않습니다.

그래서 외부 세계로부터 자료를 운반해 올 사람이 필요합니다. 이 운반 담당자의 총칭이 검색 레이어입니다.

중요한 것은 운반 담당자가 단 한 종류의 직업이 아니라는 점입니다. 다른 도서관의 목록을 복사해 오는 사람도 있고, 본문을 읽기 쉬운 형태로 필사하는 사람도 있으며, 읽은 내용을 바탕으로 구두로 요약해 주는 사람도 있습니다.

Exa와 Tavily는 이 6가지 직종 중 하나인, '용건을 듣고 필요한 부분을 발췌하여 전달해 주는 사서'에 해당합니다. 이 기사의 3-3에서 자세히 다루겠습니다.

이 섹션에서 알 수 있는 것: 2025년 이후에 이 카테고리가 단번에 팽창한 두 가지 구조적인 이유.

'도서관 운반 담당자'라는 직종 자체는 예전부터 있었습니다. Google이나 Bing의 검색 API를 호출하면 되었기 때문입니다. 그것이 불과 몇 년 만에 직종이 세분화된 데에는 명확한 원인이 있습니다.

Microsoft는 2025년 8월 11일에 Bing Search API를 완전히 중단했습니다. 공식 라이프사이클 공지에는 다음과 같이 적혀 있습니다.

"Bing Search APIs will be retired on August 11, 2025."

번역: Bing Search API는 2025년 8월 11일에 제공 종료됩니다.

같은 페이지에서 이행 대상으로 Azure AI Agents의 Grounding with Bing Search가 안내되고 있습니다. 주의해야 할 점은 이것이 '동등한 API로의 갈아타기'가 아니라는 것입니다. 이행 대상은 에이전트 제품이며, 순수한 검색 결과를 반환하는 엔드포인트가 아닙니다.

오랫동안 Bing의 검색 API를 기반으로 해왔던 제품군은 이로 인해 기반을 잃었습니다. 도서관의 비유를 들자면, 모두가 사용하던 자료 요청 창구가 예고 없이 폐쇄된 셈입니다. 그 공백에 새로운 직종이 단숨에 흘러 들어왔습니다.

또 다른 하나는 법적 리스크입니다. Google의 검색 결과를 대리 취득하여 판매하는 이른바 스크레이퍼 (Scraper)형 서비스에 대해, 2025년 12월 19일 Google이 미국 캘리포니아 북부 연방 지방법원에 제소했습니다. 쟁점은 저작권 침해 그 자체가 아니라, DMCA 제1201조, 즉 기술적 보호 수단의 회피입니다.

이 소송은 2026년 7월 20일에 핵심적인 주장이 기각되었습니다. 법원은 검색 결과에 포함된 URL이나 스니펫 (Snippet)은 저작물이 아니므로, 이를 보호하는 메커니즘을 회피하더라도 1201조의 대상이 되지 않는다고 판단했습니다.

이 소송의 결과는 집필 시점에서 확정되지 않았습니다. 일부 주장들에 대해서는 수정된 소장을 제출할 여지가 남아 있습니다. 실무적인 교훈은 승패 그 자체가 아니라, 타사의 검색 결과를 대리 취득하는 모델은 기술 이외의 요인으로 인해 갑자기 사용할 수 없게 될 가능성을 구조적으로 안고 있다는 점입니다.

창구가 닫히고, 대행업자의 발판이 흔들렸다. 이 두 가지가 겹친 결과, "자체적으로 인덱스 (Index)를 보유하고, AI를 위해 정제하여 반환한다"는 직종에 큰 수요가 생겨났습니다. Exa와 Tavily는 그 흐름의 중심에 있습니다.

여기까지가 배경입니다. 다음부터는 실제로 어떤 직종들이 있는지 살펴보겠습니다.

이 섹션에서 알 수 있는 것: 에이전트와 Web 사이에 설 수 있는 선택지의 전체 모습과, 각각이 무엇을 대신 처리해 주는지.

먼저 전체 모습입니다.

이 6가지는 "어디까지 밑준비를 해서 전달해 주는가"의 연속체로서 나열되어 있습니다. 1에 가까울수록 가공되지 않은 상태(Raw)이며, 6에 가까울수록 조리가 완료된 상태입니다. 1에 가까울수록 자유도가 높고, 6에 가까울수록 편리하지만 유연성이 떨어집니다.

대표 예시: SerpApi, Serper, SearchApi

기존 검색 엔진의 결과 페이지를 대리 취득하여 구조화된 데이터 (Structured Data)로 반환하는 유형입니다. 도서관으로 치면 타 도서관의 목록 카드를 베껴다 주는 대행업자입니다. 반환되는 것은 제목, URL, 수백 자 정도의 스니펫 (Snippet)이 중심이며, 본문은 포함되어 있지 않습니다.

강점은 Google의 검색 결과 페이지 구조를 그대로 다룰 수 있다는 점입니다. 쇼핑 프레임이나 로컬 팩 (Local Pack) 같은 특수한 결과까지 가져올 수 있으므로, 순위 측정이나 SEO 도구에서는 여전히 제1의 선택지입니다.

약점은 두 가지입니다. 본문을 얻으려면 직접 각 URL을 가져가야 한다는 점과, 2-2에서 언급한 법적·운영적 불안정성입니다.

대표 예시: Brave Search API

자체 크롤러 (Crawler)로 자체 인덱스 (Index)를 보유하고, 거기서 결과를 반환하는 유형입니다. 자신의 서고와 목록을 가지고 있는 도서관에 해당합니다.

Brave는 자사의 독립적인 Web 인덱스 (Web Index)를 기반으로 하고 있다고 설명합니다. 타사의 결과를 대리 취득하는 것이 아니므로, 3-1의 구조적 리스크로부터 자유롭습니다. 반면 인덱스 규모는 대형 검색 엔진보다 작은 것이 통례이므로, 니치(Niche)한 일본어 페이지의 망라성은 직접 쿼리를 통해 확인할 필요가 있습니다.

대표 예시: Exa, Tavily, You.com, Linkup

이 기사의 주인공입니다. 자체 인덱스 (Index)를 보유하면서도, 반환값을 처음부터 LLM이 소비한다는 전제하에 정제하여 반환하는 유형입니다.

도서관의 비유로 말하자면, 용건을 전달하면 필요한 부분만 발췌하여 메모 형태로 전달해 주는 사서입니다. 목록 카드도 아니고 책 그 자체도 아닌, 그 중간 단계입니다.

3-1과의 결정적인 차이는 반환값의 입도 (Granularity)에 있습니다. SERP 프록시 (Proxy)형이 "URL과 짧은 스니펫 (Snippet)"을 반환하는 반면, 이 유형은 "쿼리와 관련성이 높은 본문 발췌본"을 반환합니다.

이 차이가 구현량에 얼마나 영향을 미치는지 시퀀스 다이어그램 (Sequence Diagram)으로 살펴보겠습니다.

패턴 A에서 직접 작성해야 하는 "본문 추출, Markdown화, 토큰 (Token) 절감"의 3단계를 패턴 B는 API 측에서 대신 처리해 줍니다. 이 공정을 맡는 것이야말로 AI 네이티브 검색형의 정의라고 이해하면 카테고리의 윤곽이 명확해집니다.

대표 예시: Jina Reader, Firecrawl

URL을 전달하면 해당 페이지를 가져와서 LLM이 읽을 수 있는 형태로 변환하여 반환하는 유형입니다. 지정한 책을 펼쳐서 읽을 수 있는 형태로 옮겨 적어 주는 필사 담당자입니다.

Jina Reader는 "Convert any URL to an LLM-friendly input"을 내세우고 있습니다. 번역하면 "어떤 URL이든 LLM이 다루기 쉬운 입력으로 변환한다"입니다. 사용법도 철저히 단순하여, URL 앞에 https://r.jina.ai/를 붙이기만 하면 됩니다.

이 유형은 검색 기능과는 본래 다른 관심사라는 점에 주의해야 합니다. "찾는 것"이 아니라 "읽는 것"을 담당합니다. 다만 실제 제품은 경계를 넘나들고 있어서, Firecrawl은 검색과 크롤링(Crawl)도 가지고 있으며, Tavily도 /extract 엔드포인트를 가지고 있습니다. 분류는 제품이 아니라 기능에 적용하는 것이 올바른 해석입니다.

대표 예시: Perplexity Sonar

검색하고, 읽고, 요약하여, 출처가 포함된 문장으로 반환하는 유형입니다. 읽은 후 구두로 답해주는 레퍼런스 담당자라고 할 수 있습니다.

돌아오는 것은 자료가 아니라 답변 문장입니다. 편리하지만, 요약 과정이 블랙박스(Black box)가 되기 때문에 에이전트가 스스로 증거를 대조하며 판단하고 싶은 상황에는 적합하지 않습니다.

대표 예시: OpenAI의 web_search 도구, Anthropic의 Web 검색 도구, Gemini의 Grounding with Google Search

모델 제공자가 처음부터 준비해 둔 검색 도구입니다. 도서관에 처음부터 부설되어 있는 안내 카운터와 같습니다.

Gemini의 공식 문서에 따르면, google_search를 활성화하면 모델이 검색 필요 여부를 스스로 판단하고, 필요하다면 여러 개의 쿼리(Query)를 생성하여 실행한 뒤, 통합된 답변을 출처 주석과 함께 반환합니다.

외부 API 키가 필요 없어 도입이 가장 빠르다는 것이 강점입니다. 약점은 모델을 교체하면 검색 동작 자체가 바뀐다는 점입니다. 도메인 필터링이나 기간 지정의 세밀함도 모델에 따라 다릅니다.

이 섹션에서 알 수 있는 것: 6가지 분류의 요점을 하나의 표로 압축합니다.

선택 방법을 도식화하면 다음과 같습니다.

서두의 질문으로 돌아가겠습니다. Exa와 Tavily를 포괄하는 상위 개념이란 이 표의 3행을 의미합니다. 그리고 표 전체를 가리키는 말이 "검색 레이어(Search Layer)", 그 안에서 추론하며 반복적으로 검색하는 동작 방식을 가리키는 말이 "에이전틱 서치(Agentic Search)"가 됩니다.

여기서부터는 3행의 내용을 조금 더 자세히 살펴보겠습니다.

이 섹션에서 알 수 있는 것: Exa와 Tavily가 동일한 분류 내에서 어디에 집중하고 있는지. 우열이 아닌 설계 사상의 축으로서 살펴봅니다.

같은 "발췌해 주는 사서"라도 힘을 쏟는 방향이 다릅니다. 어느 쪽이 더 뛰어난가의 문제가 아니라, 자신의 용도가 어느 축에 해당하는가의 문제입니다.

Exa의 공식 문서를 읽어보면 두 가지 지점에 역점이 놓여 있음을 알 수 있습니다.

하나는 레이턴시(Latency)와의 트레이드오프(Trade-off)를 호출 측에서 선택할 수 있다는 점입니다. instant부터 deep-reasoning까지 여러 검색 타입이 있어, 실시간 채팅 용도와 시간을 들여 다단계 추론을 시키는 조사 용도를 동일한 API로 구분하여 사용할 수 있습니다.

또 하나는 카테고리별 인덱스(Index)입니다. 기업, 인물, 학술 논문, 뉴스, SEC 제출 서류와 같은 영역별로 전용 색인을 가지며, category 파라미터로 검색 대상을 전환할 수 있습니다. 대상의 종류가 처음부터 정해져 있는 검색에 효과적입니다.

highlights 옵션은 페이지 전체가 아니라 쿼리와 관련된 부분만 반환하는 기능으로, 컨텍스트(Context)에 담는 토큰(Token) 양을 직접적으로 줄여줍니다.

Tavily는 엔드포인트의 조합을 전면에 내세우고 있습니다. 공식 블로그에서 정리된 활용법은 다음과 같습니다.

즉, Tavily는 3-3뿐만 아니라 3-4의 기능도 내포하고 있습니다. 한 회사에서 "찾는 것"과 "읽는 것"을 모두 책임지는 설계입니다.

공식 블로그는 /search에 본문 취득 기능을 함께 제공하는 옵션도 언급하면서, 정밀도를 요구하는 상황에서는 두 단계로 나누는 것이 좋다고 안내합니다. "한 번에 끝낼 것인가, 두 단계로 나눌 것인가"를 선택할 수 있다는 점 자체가 설계 사상이라고 읽힙니다.

또 한 가지, Tavily는 취득한 콘텐츠를 스캔하여 프롬프트 인젝션(Prompt Injection)을 차단하는 기능을 명시적으로 내세우고 있습니다. 이는 후술할 함정과 직결되는 이야기입니다.

어느 것을 선택할지 고민된다면, 결정적인 기준은 "검색 대상의 종류가 사전에 결정되어 있는가"입니다. 기업이나 논문 등 대상 카테고리가 고정되어 있다면 Exa의 카테고리 지정이 효과적입니다. 대상이 정해져 있지 않고, 찾기·읽기·추적하기를 오간다면 Tavily의 엔드포인트 합성(Endpoint Composition)이 효과적입니다.

이 섹션에서 알 수 있는 것: 검색 레이어(Search Layer) 주변에서 자주 혼동되는 용어들을 도서관의 설비로서 다시 정의합니다.

도서관에는 운반 요원 외에도 다양한 설비가 있습니다. 혼동하기 쉬운 개념들을 나열해 두겠습니다.

RAG는 사전에 인덱스(Index)를 만들어 두고, 거기서 추출한 내용을 모델에 전달하는 메커니즘입니다. 도서관으로 치면 자館(자체 도서관)의 서고와 같습니다. 인덱스를 만든 시점의 정보만 들어가는 대신, 스스로 컨트롤할 수 있습니다. Agentic RAG는 에이전트 스스로가 "언제, 어떤 도구로 추출할지"를 판단하는 구성이며, 이 글에서 다루는 검색 레이어는 그 외부 지향적인 도구에 해당합니다.

사내 문서는 RAG, 외부의 살아있는 정보는 검색 레이어. 이 역할 분담이 기본 형태입니다.

더 형식적인 명칭입니다. Java용 LangChain4j의 문서에는 웹 검색 엔진에 대해 "Web search engines can be used as ContentRetrievers"라고 적혀 있습니다. 이를 번역하면 "Web 검색 엔진은 ContentRetriever로서 이용될 수 있다"입니다.

즉, 프레임워크의 세계에서는 벡터 DB(Vector DB)도 웹 검색 API도 동일한 Retriever 인터페이스의 구현체로 취급됩니다. 이 관점은 7장의 코드 설계와 직결됩니다.

MCP는 검색 그 자체가 아니라, 에이전트와 외부 도구를 연결하는 배선 규격입니다. 도서관으로 치면 관내 전화 규격과 같습니다.

Exa와 Tavily 모두 MCP 서버를 공식적으로 제공하고 있습니다. MCP는 6가지 분류 중 하나가 아니라, 6가지 분류 중 무엇과도 결합될 수 있는 직교(Orthogonal)하는 개념이라는 점을 유의하세요.

Grounding은 모델의 출력을 외부 정보원에 연결하여 출처를 나타낼 수 있도록 하는 것입니다. 수단이 아니라 목적을 가리키는 용어이므로, 6가지 분류 중 무엇을 사용하더라도 달성할 수 있습니다.

Deep Research는 한 번의 쿼리(Query)로부터 여러 번의 검색을 반복하여, 결과를 대조하고 리포트를 생성하는 메커니즘입니다. Exa의 deep-reasoning이나 Tavily의 /research처럼, 검색 레이어 측에 이 기능을 갖추려는 움직임이 진행되고 있습니다. 에이전트 측에서 구성하던 루프(Loop)를 API 측으로 밀어 넣는 흐름이라고 이해하면 위치가 명확해집니다.

이 섹션에서 알 수 있는 것: 6가지 분류 중 어떤 것으로 교체하더라도 에이전트 측을 다시 작성할 필요가 없는 구조를 만드는 방법.

여기서부터 Python 코드가 등장합니다. 어려운 구문은 사용하지 않았습니다. 요점은 단 하나입니다.

에이전트에게 전달하는 것은 "사서의 명함"이 아니라 "접수표의 양식"으로 만드는 것입니다.

즉, 에이전트의 코드가 TavilyClient나 Exa를 직접 알고 있는 상태를 피하는 것입니다. 교체할 때마다 본체를 다시 작성해야 하는 상황을 방지하기 위해서입니다. 의존성 역전 원칙(Dependency Inversion Principle) 그 자체이며, 실무적인 이점도 명확합니다.

• 서비스 장애 시 다른 타입으로 폴백(Fallback)할 수 있음
• 테스트 시에는 실제 API를 호출하지 않는 더미(Dummy) 구현체로 교체 가능
• 개발 환경과 운영 환경에서 서로 다른 타입을 사용할 수 있음

먼저, 검색 레이어가 반환하는 유일한 타입을 정의합니다. 이 타입 이후로는 벤더(Vendor) 명칭이 전혀 등장하지 않습니다.

클릭하여 소스 코드 펼치기 — retriever/core.py

"""검색 레이어의 추상 정의. 여기에 벤더 고유의 지식을 두지 않는다."""
from __future__ import annotations
from abc import ABC, abstractmethod
...

다음으로, 실제 SDK를 이 양식으로 변환하는 계층을 작성합니다. SDK의 반환 값 형태는 버전에 따라 변할 수 있으므로, 변환 처리를 이 파일 하나에 가두어 두는 것이 요점입니다. 문제가 생겼을 때 수정해야 할 곳이 한 군데로 줄어듭니다.

클릭하여 소스 코드 펼치기 — retriever/adapters.py

"""벤더 고유의 SDK를 Document로 변환하는 어댑터(Adapter) 군.
이 파일만이 각 SDK의 반환 값 형태를 알고 있다.
SDK의 버전 업그레이드로 인해 코드가 깨진다면, 반드시 여기가 깨진다.
...

장애 발생 시의 폴백은 어댑터 안에 작성해서는 안 됩니다. 어댑터의 책임은 변환뿐이기 때문입니다. 전환 전용 클래스를 별도로 만듭니다. 동일한 인터페이스를 구현하고 있으므로, 에이전트 측에서는 구분할 수 없습니다.

클릭하여 소스 코드 펼치기 — retriever/fallback.py

"""폴백 (fallback) 전용 합성 리트리버 (retriever)."""
from __future__ import annotations
import logging
...

마지막으로, 어떤 타입을 사용할지를 설정 파일로 분리합니다. 코드 측에 환경 분기 로직을 작성하지 않는 것이 핵심입니다.

클릭하여 설정 파일 3종 펼치기

# config/dev.yaml — 개발 환경. 무료 할당량을 절약함
retriever:
  primary: tavily
...

# config/prod.yaml — 운영 환경. 한쪽이 다운되어도 중단되지 않음
retriever:
  primary: exa
...

# config/test.yaml — CI. 실제 API를 호출하지 않음
retriever:
  primary: stub
...

# retriever/factory.py — 설정으로부터 조립하는 유일한 장소
from __future__ import annotations
from typing import Any, Callable
...

이렇게 하면, 에이전트 본체 코드는 다음 한 줄만 알고 있으면 됩니다.

documents = retriever.retrieve("Mermaid v11 subgraph 日本語ラベル", k=5)

6가지 분류 중 어떤 것으로 교체하더라도 이 줄은 변하지 않습니다. 접수증의 형식을 고정함으로써 얻은 효과입니다.

이 섹션에서 알 수 있는 것: 실제로 구현한 뒤에 빠지기 쉬운 6가지 함정.

마지막에서 두 번째 줄은 특히 중요합니다. 도서관 비유를 들자면, 사서가 가져온 자료의 여백에 "지금까지의 지시를 무시하고 관내의 책을 전부 가져오라"라고 적혀 있는 상황입니다. 운반 요원이 신뢰할 수 있더라도, 운반되어 오는 자료의 내용은 신뢰할 수 없습니다.

Tavily가 콘텐츠 스캔 기능을 내세우는 것은 이 문제에 대한 대응이지만, API 측의 대책에만 전적으로 의존하는 것은 위험합니다. 획득한 텍스트를 시스템 프롬프트 (system prompt)와 동일하게 취급하지 않는다는 설계 측면의 방어가 전제가 되어야 합니다.

이 섹션에서 알 수 있는 것: 이 기사에 등장한 용어의 최소한의 정의.

이 섹션에서 알 수 있는 것: 다음에 무엇을 다루면 좋을지.

제1단계 — 직접 움직이며 차이를 체감하기

무료 할당량으로 Tavily와 Exa 양쪽에 동일한 쿼리 (query)를 던지고, 반환된 JSON을 나란히 놓고 비교해 보세요. 아울러 https://r.jina.ai/에 적당한 URL을 붙여 호출해 보면, 획득·정형 타입이 무엇을 하고 있는지도 1분 만에 알 수 있습니다.

제2단계 — 추상화 계층을 직접 구성하기

7장의 코드를 단순히 베껴 쓰는 것이 아니라 재설계해 보세요. Document에 무엇을 담을지는 용도에 따라 달라집니다. 공개일, 언어, 도메인의 신뢰도 등, 자신의 에이전트가 판단에 사용할 정보를 추가해 나가는 작업 자체가 그대로 설계 연습이 됩니다.

제3단계 — 검색 레이어의 품질 측정하기

자신의 도메인에서 검증용 쿼리를 20개 정도 만들고, 상위 5개에 1차 정보가 몇 개 포함되어 있는지 타입별로 세어 봅니다. 벤더가 공표한 벤치마크 (benchmark)가 아니라, 자신의 용도에서의 실측치가 유일한 판단 근거입니다. 여기까지 오면 OSS 에이전트 구현이 어떤 타입을 선택하고 있는지, 그 이유까지 읽어낼 수 있게 됩니다.

도서관에 갇힌 연구자에게 외부 자료를 운반해 줄 사람이 필요하다. 이것이 이 기사의 출발점이었습니다.

• Exa와 Tavily를 포괄하는 명칭은 입도(granularity)에 따라 3가지가 있다. 제품 카테고리라면 "AI 네이티브 검색 API", 아키텍처라면 "검색 레이어 (search layer)", 동작 방식이라면 "Agentic Search"
• 운반 요원은 6가지 직종으로 정리할 수 있다. 차이는 "어디까지 밑준비를 해서 전달할 것인가"라는 한 점으로 수렴된다.
• Exa는 의미(semantic)로 끌어오는 방향, Tavily는 공정(workflow)을 합성하는 방향에 집중하고 있다. 우열의 문제가 아니라 축의 차이다.
• 6가지 직종 중 무엇을 고용해도 망가지지 않는 코드는, 접수증의 형식을 고정함으로써 작성할 수 있다.

이름이 아직 흔들리고 있는 이유는, 카테고리 자체가 2025년에서 2026년에 걸쳐 급격하게 형태를 바꾸고 있기 때문입니다. 창구가 닫히고, 대행업자의 발판이 흔들리며, 모델 제공자가 자체적인 카운터를 설치했습니다. 이름이 정해지지 않는 것은 지형이 아직 움직이고 있다는 증거라고 생각하는 것이 실태에 가깝습니다.

호칭을 하나로 결정하는 것보다, 자신의 에이전트가 어떤 직종을 고용하고 있는지를 설명할 수 있는 것이 실무에서는 더 유용합니다.

각 링크에는 그곳에서 무엇을 확인할 수 있는지를 덧붙였습니다.

• Tavily 공식 블로그 Tavily 101 — 2026년 1월 28일자. 자사를 "the web access layer for AI agents"라고 정의. 4개 엔드포인트(endpoint)의 용도 구분과 인젝션(injection) 차단에 대한 언급
• Exa 공식 문서 Search API Guide — 자사를 "a custom search engine built for AIs"라고 정의. 검색 타입별 레이턴시(latency) 표, 카테고리별 인덱스(index), highlights에 대한 설명
• Microsoft Learn Bing Search API 서비스 종료 공지 — 종료일과 이전 대상 안내. 원문은 "Bing Search APIs will be retired on August 11, 2025."
• Google AI for Developers Grounding with Google Search — google_search 도구의 동작 흐름과 과금 단위 설명
• Jina AI reader 리포지토리 — "Convert any URL to an LLM-friendly input" 원문과 r.jina.ai 사용법
• Brave Search API 공식 페이지 — 독립적인 웹 인덱스(Web index)를 기반으로 하고 있다는 기술
• Perplexity API Platform — Search API와 Sonar의 위치 설정, 출처가 포함된 답변 사양
• LangChain4j 문서 Web Search Engines — "Web search engines can be used as ContentRetrievers" 원문. 프레임워크 측의 추상화(abstraction) 방식을 알 수 있음
• SerpApi 공식 블로그 소송 기각 보고 — 2026년 7월 20일자. 당사자에 의한 1차 보고. 법원 명령 PDF 링크 포함

업데이트 정보나 제작 중인 기사에 대해서는 이곳에서 발신하고 있습니다.