2.5억 달러 Exa, 에이전트 검색 병목의 가격표

AI 요약

• 무슨 일: Exa가 2.5억 달러 Series C를 발표하며 AI용 검색 엔진 확장을 전면에 세웠습니다.
  • 공식 발표 기준 가치는 22억 달러이며, a16z가 라운드를 주도했습니다.
• 핵심 숫자: Exa는 40만 명 이상 개발자, 5천 개 이상 회사, 5천억 URL 추적을 주장합니다.
• 의미: 에이전트 품질은 모델만이 아니라 검색 품질, 지연시간, 토큰 절감, 출처 검증에 묶입니다.
  • 특히 코딩·리서치 에이전트는 웹 검색을 한 번이 아니라 반복적인 검증 루프로 사용합니다.
• 주의점: Exa의 벤치마크와 시장 규모 주장은 자체 발표가 중심이라 독립 검증을 함께 봐야 합니다.

Exa가 2026년 5월 20일 2억 5천만 달러 Series C를 발표했습니다. 회사가 밝힌 사후 가치는 22억 달러이고, 라운드는 a16z가 주도했습니다. 숫자만 보면 또 하나의 AI 인프라 투자 뉴스처럼 보입니다. 하지만 이번 발표에서 더 흥미로운 대목은 Exa가 자신을 "AI를 위한 검색 엔진"으로 다시 못 박았다는 점입니다. 모델이 더 똑똑해질수록 검색은 덜 중요해지는 것이 아니라, 오히려 에이전트가 외부 세계를 확인하는 핵심 경로가 되고 있습니다.

사람의 검색과 에이전트의 검색은 다릅니다. 사람은 검색어를 넣고 결과 몇 개를 열어본 뒤 결정을 내립니다. 에이전트는 목표를 하위 질문으로 쪼개고, 후보를 모으고, 최신성을 확인하고, 서로 다른 출처를 대조하고, 도구를 실행하기 전에 다시 한 번 검증합니다. 코딩 에이전트라면 오류 메시지, 라이브러리 문서, GitHub 이슈, 릴리스 노트, 예제 코드를 여러 차례 왕복합니다. 리서치 에이전트라면 같은 주제를 관점별로 다시 검색하고, 모순되는 문장을 걸러야 합니다. 이 반복 루프가 커질수록 검색 API는 부가 기능이 아니라 런타임 비용과 품질을 결정하는 인프라가 됩니다.

Exa의 발표문은 이 전환을 매우 공격적으로 표현합니다. 회사는 AI 에이전트가 올해 사람보다 더 많이 웹을 검색할 것이라고 주장하고, 앞으로 몇 년 안에 LLM이 만드는 검색량이 오늘날 Google 검색량보다 1000배 많아질 수 있다고 말합니다. 이 숫자는 예측이므로 그대로 받아들이기보다 시장을 어떻게 보고 있는지 보여주는 문장으로 읽는 편이 맞습니다. 핵심은 검색량의 절대치보다 검색의 성격입니다. 검색이 "사용자가 보는 결과 페이지"에서 "에이전트가 작업 중 호출하는 기계용 인프라"로 이동하고 있습니다.

Exa가 밝힌 숫자들

공식 발표에서 Exa는 이미 Cursor, Cognition, HubSpot, OpenRouter, Monday.com 등에 검색을 제공한다고 밝혔습니다. 개발자 수는 40만 명 이상, 사용하는 회사는 5천 개 이상이라고 설명합니다. 또 자체 크롤러가 5천억 개 이상의 URL을 추적하고, 연구팀이 특수 임베딩 모델을 학습하며, 에이전트의 높은 QPS를 감당하기 위한 벡터 데이터베이스를 직접 만들었다고 말합니다.

이 문장들이 중요한 이유는 Exa가 자신을 "검색 결과를 포장하는 API"가 아니라 "검색 엔진을 직접 만드는 인프라 회사"로 포지셔닝하기 때문입니다. 많은 검색 API는 기존 검색 엔진 결과를 받아 정리하거나, 크롤링과 추출을 조합해 개발자에게 제공합니다. Exa의 주장은 그보다 아래층을 갖고 있다는 것입니다. 자체 크롤러, 자체 인덱스, 자체 임베딩, 자체 추출 모델을 묶어 에이전트용 검색 품질과 지연시간을 함께 통제한다는 방향입니다.

회사 발표에 따르면 Exa는 GTM 에이전트에는 사람과 회사에 대한 포괄적인 검색이 필요하고, 코딩 에이전트에는 공개 코드와 기술 문서에 대한 복잡한 검색이 필요하며, 채팅 에이전트에는 빠르고 싼 검색과 텍스트 추출이 필요하다고 봅니다. 그래서 코드 검색용 특수 임베딩 모델을 학습했고, sub-200ms 검색 API와 LLM 토큰 수를 20배 이상 줄이는 텍스트 추출 모델을 만들었다고 설명합니다. 여기서 보이는 방향은 명확합니다. 모든 에이전트에 같은 웹 검색을 붙이는 것이 아니라, 작업 유형별 검색 요구를 별도 제품처럼 다루겠다는 것입니다.

위 이미지는 Exa 공식 발표에 포함된 검색 품질 벤치마크입니다. FRAMES, Tip-of-Tongue, Seal0 같은 평가에서 Exa가 Perplexity와 Brave보다 높은 정확도를 보인다고 주장합니다. 다만 이 차트는 Exa 자체 발표의 일부입니다. 평가 데이터셋, 쿼리 구성, 제품 버전, 호출 설정에 따라 결과가 달라질 수 있으므로, 투자 뉴스의 핵심 근거로 쓰기보다는 Exa가 어떤 경쟁 축을 강조하는지 보여주는 자료로 보는 것이 좋습니다.

검색은 왜 모델 밖 병목인가

LLM 제품을 만들 때 검색은 종종 "컨텍스트를 붙이는 기능"으로 취급됩니다. 질문을 받으면 관련 문서를 찾고, 그 문서를 모델에 넣고, 답변을 생성합니다. 초기 RAG 시스템에서는 이 정도 설명이 꽤 잘 맞았습니다. 그러나 에이전트에서는 검색이 훨씬 더 복잡한 역할을 맡습니다.

첫째, 검색은 최신성의 통로입니다. 모델은 학습 시점 이후의 정보를 알 수 없고, 긴 컨텍스트를 넣더라도 최신 웹 상태를 자동으로 보장하지 않습니다. 에이전트가 오늘의 API 변경, 방금 닫힌 GitHub 이슈, 새 가격표, 보안 공지, 회사 인수 발표를 다뤄야 한다면 검색이 필요합니다.

둘째, 검색은 검증의 통로입니다. 에이전트가 한 번 찾은 문장을 바로 믿으면 위험합니다. 서로 다른 출처를 대조하고, 공식 문서와 보조 보도를 구분하고, 오래된 블로그 글과 최신 릴리스 노트를 분리해야 합니다. 이 과정은 모델 추론만으로 끝나지 않습니다. 어떤 URL을 고르고, 어떤 본문을 추출하고, 어떤 문장을 근거로 남기는지가 품질을 좌우합니다.

셋째, 검색은 비용의 통로입니다. 검색 결과를 많이 가져오면 모델 입력 토큰이 늘어납니다. 결과를 너무 적게 가져오면 답변이 빈약하거나 틀립니다. 페이지 전체를 긁으면 느리고 비싸며, 스니펫만 쓰면 중요한 맥락을 놓칠 수 있습니다. Exa가 텍스트 추출로 토큰 수를 20배 이상 줄인다고 강조하는 이유도 여기에 있습니다. 검색 품질은 정확도 문제이면서 동시에 토큰 비용 문제입니다.

넷째, 검색은 권한과 책임의 통로입니다. 에이전트가 웹을 검색해 결정을 내릴 때는 어떤 출처를 신뢰했는지, 언제 접근했는지, 사용자가 어떤 권한을 줬는지 남겨야 합니다. 특히 금융, 의료, 법률, 채용, 보안처럼 결정 비용이 큰 영역에서는 검색 결과가 단순 참고 자료가 아닙니다. 에이전트 행동의 근거가 됩니다.

Exa와 Parallel이 보여주는 새 시장

Exa만 이 방향을 보고 있는 것은 아닙니다. Parallel Web Systems는 2026년 4월 1억 달러 Series B를 발표하며 20억 달러 가치에 도달했다고 밝혔습니다. Parallel도 자신을 AI 에이전트가 오픈 웹에 접근하고 사용하는 방식을 위한 인프라로 설명합니다. TechCrunch는 Exa와 Parallel, Tavily, TinyFish 같은 회사들을 Google과 OpenAI가 밀고 있는 AI 검색 전환과 함께 묶었습니다.

이 경쟁은 검색창 UI 경쟁과 조금 다릅니다. Google Search와 Perplexity, ChatGPT Search는 사용자가 직접 보는 답변 인터페이스를 장악하려 합니다. Exa와 Parallel은 그 아래층에서 에이전트와 앱이 호출하는 검색 API, 추출, 인덱스, 연구 도구를 팔려고 합니다. 한쪽은 사용자의 기본 진입점이 되고 싶어 하고, 다른 한쪽은 모든 에이전트의 기본 검색 계층이 되고 싶어 합니다.

개발자 입장에서 이 구분은 실용적입니다. ChatGPT나 Gemini 안에서 검색을 쓰는 것과, 자체 에이전트에 Exa나 Tavily 같은 검색 API를 붙이는 것은 다른 선택입니다. 전자는 모델과 검색이 결합된 제품 경험을 얻습니다. 후자는 검색 호출을 직접 설계하고, 결과를 캐시하고, 출처를 저장하고, 여러 모델에 같은 검색 계층을 붙일 수 있습니다. 어느 쪽이 낫다는 문제가 아닙니다. 에이전트가 제품의 핵심 기능이 되는 순간 검색 계층을 누가 통제할지 결정해야 한다는 뜻입니다.

코딩 에이전트가 검색 회사를 키우는 이유

Exa가 발표문에서 직접 언급한 고객 중 Cursor와 Cognition은 상징적입니다. 코딩 에이전트는 검색의 좋은 테스트베드입니다. 코드는 최신 문서와 버전 차이에 민감합니다. 사용자가 쓰는 프레임워크, 패키지, 런타임, 클라우드 API가 모두 빠르게 변합니다. 모델이 오래된 문법을 제안하면 빌드가 깨지고, 보안 옵션을 놓치면 실제 리스크가 됩니다.

또 코딩 에이전트는 검색 결과를 사람이 읽는 문서보다 더 엄격하게 사용합니다. 예를 들어 Next.js의 특정 버전에서 캐시 API가 어떻게 바뀌었는지 알아야 한다면, 에이전트는 공식 문서, 릴리스 노트, GitHub 이슈, 예제 코드, 마이그레이션 가이드를 함께 봐야 합니다. 일반 검색 결과 첫 페이지에 있는 오래된 튜토리얼이 오히려 위험할 수 있습니다. 이때 필요한 것은 인기 있는 페이지가 아니라 최신성과 버전 맥락이 맞는 근거입니다.

코딩 에이전트의 검색은 비용도 빠르게 커집니다. 사용자가 "이 테스트 실패를 고쳐줘"라고 말하면 에이전트는 로컬 파일을 읽고, 오류 메시지를 해석하고, 의존성 문서를 찾고, 비슷한 이슈를 검색하고, 패치를 만들고, 다시 테스트합니다. 이 과정에서 웹 검색은 한 번만 일어나지 않습니다. 검색 호출, 페이지 추출, 모델 입력 토큰, 재시도 비용이 모두 쌓입니다. 그래서 검색 API의 지연시간과 텍스트 추출 품질은 사용자 경험의 일부가 됩니다.

x402와 에이전트 결제까지 이어지는 검색

흥미로운 연결점은 Coinbase가 2026년 4월 Exa 검색을 x402로 에이전트가 결제 가능한 서비스로 소개했다는 점입니다. x402는 HTTP 402 Payment Required를 활용해 에이전트가 어떤 API를 호출하다가 결제가 필요하다는 응답을 받고, 가격을 확인하고, 결제 후 계속 진행하는 흐름을 목표로 합니다. Coinbase의 Exa 소개는 검색이 사람의 사전 가입과 API 키 발급을 넘어, 에이전트가 작업 중 필요할 때 구매하는 자원으로 바뀔 수 있음을 보여줍니다.

아직 이런 흐름이 널리 쓰인다고 말하기는 이릅니다. 하지만 방향은 중요합니다. 에이전트가 자율적으로 외부 도구를 선택한다면 검색, 크롤링, 데이터베이스 조회, 인증, 결제는 모두 하나의 실행 경로 안에 들어옵니다. 검색 API가 "개발자가 월별로 사서 앱에 붙이는 도구"에서 "에이전트가 순간적으로 호출하고 비용을 지불하는 서비스"로 이동하면, 가격 단위와 사용량 관리도 달라집니다.

이는 보안과 거버넌스 문제도 함께 부릅니다. 어떤 에이전트가 어떤 검색을 얼마까지 살 수 있는지, 민감한 쿼리를 외부 검색 API에 보내도 되는지, 검색 결과가 비즈니스 의사결정에 쓰일 때 감사 로그는 어디에 남는지 결정해야 합니다. 검색 인프라 경쟁은 단순히 더 정확한 결과를 주는 회사를 고르는 일이 아니라, 에이전트가 외부 세계와 거래하는 경계를 설계하는 문제로 커질 수 있습니다.

벤치마크를 읽는 방법

Exa는 발표에서 품질과 지연시간 벤치마크를 강조했습니다. FRAMES와 Tip-of-Tongue, Seal0에서 Exa가 높은 정확도를 보인다는 차트와, HLE-Search에서 품질 대비 지연시간이 좋다는 비교를 제시했습니다. 이런 자료는 투자 발표에서 중요한 신호지만, 동시에 조심해서 읽어야 합니다.

첫째, 검색 벤치마크는 쿼리와 평가 방식에 민감합니다. 검색 시스템은 범용 질문, 코드 질문, 사람·회사 검색, 학술 검색, 쇼핑 검색, 뉴스 검색에서 서로 다른 강점을 보입니다. 한 데이터셋에서 우수하다고 해서 모든 에이전트 워크로드에서 우수하다고 볼 수 없습니다.

둘째, 검색 API의 실제 품질은 후처리와 함께 결정됩니다. 결과 URL의 순위, 본문 추출, 중복 제거, 신뢰도 필터링, 캐시 정책, 최신성 처리, 모델에 넣을 요약 방식이 모두 영향을 줍니다. 검색 결과 자체보다 "에이전트가 쓸 수 있는 형태로 얼마나 잘 가공되는가"가 중요할 때도 많습니다.

셋째, 가격은 단순 호출당 과금으로 끝나지 않습니다. 검색 호출이 빠르더라도 가져온 본문이 길면 LLM 토큰 비용이 늘어납니다. 반대로 추출이 너무 과감하면 근거가 사라집니다. Exa가 텍스트 추출 모델과 토큰 절감을 함께 강조하는 이유는 검색 시장의 비용 계산이 검색 API 가격표 밖으로 이어지기 때문입니다.

개발팀이 지금 물어야 할 질문

이번 뉴스를 "Exa를 써야 하는가"로만 읽으면 좁습니다. 더 유용한 질문은 "우리 에이전트의 검색 계층을 어떻게 설계할 것인가"입니다. 내부 문서 검색만 하는 에이전트라면 사내 인덱스와 권한 필터가 더 중요할 수 있습니다. 공개 웹 최신성이 중요한 리서치 에이전트라면 Exa, Tavily, Brave, SerpAPI, Firecrawl, 자체 크롤러를 조합해야 할 수 있습니다. 코딩 에이전트라면 공식 문서와 코드 검색의 품질, 버전 신선도, GitHub 이슈 추적이 더 중요합니다.

실무적으로는 몇 가지 기준을 먼저 잡는 것이 좋습니다. 검색 결과를 그대로 모델에 넣을지, 중간 요약을 만들지, 원문 URL과 접근 시각을 저장할지, 캐시를 얼마 동안 유지할지, 실패 시 다른 공급자로 fallback할지, 민감한 쿼리를 외부로 보내도 되는지 정해야 합니다. 검색 API를 교체 가능한 어댑터로 둘지, 특정 공급자의 랭킹과 추출 형식에 깊게 의존할지도 결정해야 합니다.

특히 에이전트 제품을 운영하는 팀이라면 검색 로그를 관측 데이터로 다뤄야 합니다. 어떤 쿼리를 보냈고, 어떤 URL이 선택됐고, 어떤 본문이 모델에 들어갔고, 어떤 결정을 만들었는지 추적할 수 있어야 합니다. 검색은 더 이상 보이지 않는 helper 함수가 아닙니다. 잘못된 검색 결과는 잘못된 답변, 잘못된 코드 패치, 잘못된 비즈니스 판단으로 이어질 수 있습니다.

결론: 모델 경쟁의 다음 비용표

Exa의 2억 5천만 달러 라운드는 검색 회사의 성장 뉴스이면서, 모델 경쟁의 다음 비용표를 보여주는 사건입니다. 에이전트가 많아질수록 모델 호출만 늘어나는 것이 아닙니다. 검색 호출, 문서 추출, 출처 검증, 캐시, 인덱스, 벡터 데이터베이스, 결제, 감사 로그까지 함께 늘어납니다. 그중 검색은 에이전트가 외부 세계를 만나는 첫 번째 계층입니다.

Google과 OpenAI는 검색을 모델과 사용자 인터페이스 안으로 끌어들이고 있습니다. Exa와 Parallel은 그 아래에서 모든 에이전트가 쓸 수 있는 검색 인프라를 만들겠다고 말합니다. 어느 쪽이 더 오래가는 구조가 될지는 아직 정해지지 않았습니다. 다만 한 가지는 분명합니다. AI 제품팀이 검색을 "나중에 붙일 기능"으로 취급하기 어려워졌습니다.

앞으로 좋은 에이전트는 좋은 모델만으로 만들어지지 않습니다. 무엇을 검색할지, 어떤 출처를 믿을지, 얼마나 빠르게 가져올지, 얼마나 적은 토큰으로 근거를 남길지, 실패했을 때 어떻게 재시도할지까지 포함해야 합니다. Exa가 받은 2억 5천만 달러는 그 질문에 붙은 시장 가격입니다. 에이전트 시대의 병목은 모델 밖에도 있고, 검색은 그 병목 중 가장 먼저 돈이 몰리는 층이 되고 있습니다.