BrainGrid 에이전트를 위해 Claude 웹 검색에서 Exa로 전환한 이유

지난주 우리는 AI 에이전트의 웹 검색에 대한 접근 방식 전체를 재고하게 만든 문제에 직면했습니다.

우리의 요구사항 기획 (requirements planning) 에이전트는 베스트 프랙티스 (best practices), 문서 (documentation) 등을 찾아보고 리서치를 수행할 수 있어야 했습니다. 아시다시피 OAuth 흐름을 올바르게 구현하는 방법, 최신 React 패턴, API 설계 가이드라인 같은 일반적인 작업들 말이죠. Claude의 내장 웹 검색은 완벽해 보였습니다. 우리는 모든 곳에서 Anthropic 모델을 사용하고 있으니, 그들의 검색 기능도 사용하는 게 당연해 보였습니다.

하지만 사용하지 말아야 할 아주 타당한 이유가 있다는 것이 밝혀졌습니다.

문제는 성능이나 비용이 아니었습니다. 우리가 전혀 예상하지 못했던 것이었습니다. 바로 암호화 (encryption)였습니다. Claude는 웹 콘텐츠를 암호화하는데, 이는 듣기에는 좋아 보이지만 에이전트가 실제로 무슨 일이 일어나고 있는지 이해할 수 없다는 것을 깨닫기 전까지는 그렇습니다. 우리는 개발자들이 더 나은 사양 (specs)을 작성할 수 있도록 돕는 요구사항 에이전트를 구축하는 과정에서 이 사실을 발견했습니다. 에이전트는 API 문서 (API docs)를 검색하여 정확히 필요한 것을 찾아냈지만, 그 다음에는... 아무것도 없었습니다. 구조화된 데이터 (structured data)가 있어야 할 자리에 그저 암호화된 덩어리 (encrypted blobs)만 있을 뿐이었습니다. 실제로 어떤 콘텐츠가 들어있는지 파악하기가 어려웠습니다. 한 가지 더 까다로운 점은, 우리 에이전트의 특정 작업에는 Google의 Gemini를 사용하는데, Gemini는 Claude의 암호화된 콘텐츠를 이해하지 못한다는 것이었습니다.

이것이 우리가 100줄 미만의 코드로 Exa를 도입하여 앞으로 나아간 방식입니다.

Claude의 암호화가 우리의 문서화 워크플로우를 망가뜨린 방식

상황을 설명해 보겠습니다. 당신의 에이전트가 "Stripe create payment intent API"를 검색합니다. Claude는 완벽한 페이지를 찾아냅니다. 하지만 돌아오는 결과는 다음과 같습니다:

{
  "content": {
    "encrypted": "2f3a9b8c4d5e6f7a8b9c0d1e2f3a4b5c...",
...

저 암호화된 필드(encrypted field) 말인가요? 그 안에 모든 유용한 정보가 들어있습니다. 요청 파라미터 (request parameters), 응답 스키마 (response schema), 코드 예제 (code examples) 등 에이전트가 적절한 요구사항을 작성하는 데 필요한 모든 것이 말이죠. 하지만 그것은 잠겨 있습니다.

우리는 우회 방법을 시도했습니다. 인용 (citations)을 사용하여 콘텐츠를 재구성할 수 있을까요? 아니요. 인용은 아주 작은 조각 (snippets)만을 제공할 뿐, 전체 API 스키마 (API schema)를 제공하지는 않습니다. 여러 번의 검색을 체이닝 (chaining)할 수 있을까요? 그것은 그저 더 많은 암호화된 덩어리들만 가져다줄 뿐이었습니다.

우리는 다양한 접근 방식을 시도하며 수 시간을 보냈습니다. 인용문 (citations)을 더 영리하게 파싱(parse)하거나, 더 작은 청크 (chunks)를 검색하거나, 서로 다른 쿼리 패턴 (query patterns)을 사용하는 등의 시도를 했습니다. 하지만 아무것도 작동하지 않았습니다. 암호화는 콘텐츠를 보호하기 위해 설계된 목적 그대로 작동하고 있었습니다. 단지 우리의 사용 사례 (use case)에는 맞지 않았을 뿐입니다.

Exa의 등장: AI 애플리케이션을 위해 구축된 검색 엔진

그때 우리는 Exa를 발견했습니다. Exa는 스스로를 "AI를 위해 구축된 검색 (search built for AIs)"이라고 홍보하며, 솔직히 말해서 그것은 정확히 그 자체입니다.

다음은 Exa를 사용한 동일한 Stripe API 검색 결과입니다:

{
  "url": "https://stripe.com/docs/api/payment_intents/create",
  "title": "Create a PaymentIntent | Stripe API Reference",
...

차이점이 보이시나요? 실제 콘텐츠입니다. 파싱 가능하고 (parseable), 구조화되어 있으며 (structured), 즉시 유용하게 사용할 수 있는 콘텐츠입니다.

하지만 Exa는 단순히 암호화되지 않은 Claude 검색이 아닙니다. 구조 자체가 다릅니다. 신경망 검색 (neural search)은 전통적인 검색 방식이 이해하지 못하는 방식으로 기술적인 쿼리 (technical queries)를 이해합니다. "React Server Components 데이터 페칭 패턴 (data fetching patterns)"을 요청하면, 단순히 해당 단어들이 포함된 페이지를 찾는 것이 아니라 문서 내의 정확한 섹션을 찾아냅니다.

가장 좋은 점은 무엇일까요? 우리의 Vercel AI SDK 설정에 바로 연결되었다는 점입니다. 우리는 이미 AI SDK v5를 사용하고 있었습니다 (우리의 마이그레이션 모험 이후). Exa는 이를 일급 시민 (first-class) 수준으로 지원합니다. 전체 통합 시간은 단 한 번의 오후였습니다.

구현: 두 가지 도구를 통한 웹 검색 및 웹 페이지 읽기

여기서부터 흥미로워집니다. 우리는 단순히 Claude의 검색을 교체한 것이 아니라, 더 나은 무언가를 만들었습니다.

아래 코드는 초기 구현을 보여줍니다. 다음을 처리하는 완전히 새로운 도구입니다:

• 웹 검색 (Searching the web)
• 검색 결과를 사용하여 가장 관련성 높은 콘텐츠 가져오기

// 관련 문서 및 베스트 프랙티스 (best practices)를 찾기 위한 웹 검색
const webSearchTool = tool({
  description: 'Search the web for relevant information',
...

하지만 검색만으로는 충분하지 않았습니다. 만약 사용자가 에이전트에게 웹 페이지를 컨텍스트 (Context)로 첨부하기를 원한다면 어떻게 될까요? 다행히도, 사용자가 제공한 URL을 통해 에이전트가 웹 페이지를 읽을 수 있도록 매우 간단한 도구 (Tool)를 추가할 수 있습니다.

// 에이전트가 완전한 컨텍스트 (Context)가 필요할 때 전체 웹 페이지를 읽음
const readWebPageTool = tool({
  description: 'Read a web page and return the content',
...

에이전트에게 관련 콘텐츠를 찾기 위해 웹을 서핑하는 능력을 부여하는 것은 매우 강력하지만, 사용자에게 API 문서나 베스트 프랙티스 (Best practices) 가이드와 같이 관련 정보를 검색할 위치를 에이전트에게 직접 알려줄 수 있게 하는 것은 훨씬 더 강력합니다. 그리고 이 모든 과정이 암호화나 파싱 (Parsing)의 번거로움 없이 이루어집니다. 요구사항 작성 (Requirement writing)에 즉시 사용할 수 있는 깨끗하고 평이한 문서 형태 그대로 제공됩니다.

또한 우리는 최신 콘텐츠 검색을 강제하는 Exa의 livecrawl 기능을 발견했습니다. 이는 빈번하게 변경되는 API 문서에 있어 매우 중요합니다. 이제 6개월 전의 캐시된 (Cached) 응답을 받을 일이 없습니다.

결과: 더 빠르고, 깔끔하며, 더 신뢰할 수 있는 요구사항 생성

경험이 스스로 증명하듯, 우리의 에이전트는 이제 더 나은 연구를 수행하고 더 나은 요구사항을 작성할 수 있습니다. 에이전트는 다양한 측면을 탐색하기 위해 분기 검색 (Branched searching)을 수행할 수 있으며, 더 깊이 파고들 필요가 있다면 readWebPage 도구를 사용하여 완전한 컨텍스트 (Context)를 가져올 수 있습니다.

BrainGrid 에이전트는 결과를 파싱 (Parse)하여, 현재 요구사항 문서가 이미 어떤 베스트 프랙티스 (Best practices)를 구현하고 있는지, 그리고 무엇이 누락되었는지 파악하는 것과 같이 실행 가능한 응답을 제공합니다.

또한 읽은 모든 내용을 그대로 받아들이지 않고, 당신이 작업 중인 요구사항에 대해 가장 영향력 있는 베스트 프랙티스 (Best practices)를 추천합니다.

하지만 진짜 승리는 무엇일까요? 우리의 요구사항(Requirements)이 더 좋아졌다는 점입니다. 훨씬 더 좋아졌습니다.

이러한 수준의 상세함은 개발자들이 명확히 하기 위한 질문을 던지는 데 쓰는 시간을 줄이고, 구축하는 데 더 많은 시간을 쓸 수 있음을 의미합니다. 요구사항은 첫날부터 실행 가능(Actionable)합니다.

예상치 못한 이점 중 하나는 에이전트가 자신의 출처를 공개한다는 것입니다. 에이전트가 특정 접근 방식을 추천할 때, 어떤 검색 결과(Search results)를 얻었는지, 어떤 페이지를 읽었는지 정확히 확인할 수 있습니다. 개발자는 추론 과정을 검증하거나, 새로운 것을 배우거나, 필요에 따라 더 깊이 파고들 수 있습니다.

더 큰 그림 (The bigger picture)

이 모든 경험은 우리에게 중요한 교훈을 주었습니다. 개발자를 위한 AI 도구를 만들 때는 데이터 접근(Data access)의 품질이 모델 선택만큼이나 중요하다는 것입니다.

Claude의 웹 검색(Web search)은 오직 Claude 모델만을 사용하는 일반적인 쿼리(Queries)에는 매우 훌륭하게 작동합니다. 하지만 동일한 컨텍스트(Context) 내에서 서로 다른 작업에 대해 다양한 모델을 활용하는 더 정교한 에이전트(Agents)를 구축할 때는, 컨텍스트에 들어가는 내용에 대해 완전한 제어권(Full control)이 필요합니다.

만약 암호화된 콘텐츠(Encrypted content) 문제로 비슷한 벽에 부딪히고 있다면, Exa를 살펴보세요. 특히 이미 Vercel AI SDK를 사용 중이라면 마이그레이션(Migration)은 간단합니다. 우리의 전체 전환 작업은 두 개의 PR(Pull Requests)에 걸쳐 100줄 미만의 코드로 완료되었습니다.

AI 개발 도구를 구축하고 계신가요? 함께 이야기해 봅시다. 우리는 BrainGrid에서 매일 이러한 문제들을 해결하며, 어지러운 아이디어들을 AI 준비가 된 요구사항(AI-ready requirements)으로 바꾸고 있습니다. 직접 체험해 보고 제대로 조사된 AI 준비가 된 요구사항이 어떤 모습인지 확인해 보세요.

원문은 BrainGrid 블로그에 게시되었습니다.