에이전트가 상속받은 웹 검색 기능으로는 충분하지 않습니다

외부 세계가 필요한 에이전트

한 소프트웨어 회사의 엔지니어가 회사의 시장 전망을 최신 상태로 유지하기 위한 에이전트를 구축하고 있습니다. 이 에이전트는 수십만 개의 잠재 고객 및 고객 계정을 모니터링하며 새로운 투자 유치, 경영진 교체, 제품 출시, 예산 확보를 나타내는 채용 급증 등 비즈니스 기회로 이어질 수 있는 신호를 감지합니다.

계정 기록은 이미 Databricks 내 Unity Catalog로 관리되는 Delta 테이블에 있으며, 회사의 자체 사용량 및 파이프라인 데이터와 결합되어 있습니다. 하지만 계정을 움직이는 신호는 회사 외부인 웹에 존재합니다. 에이전트의 역할은 이 두 가지를 지속적으로 결합하여 모든 계정에 대한 일관되고 최신 상태의 정보를 제공함으로써, 영업 담당자에게 이번 주에 연락해야 할 몇 개의 계정을 알려주는 것입니다.

버전 1.0: 작동은 하지만 엉망인 상태

첫 번째 버전은 단일 시스템이 아닙니다. 엔지니어가 선택한 각 도구에 맞춰 동일한 데이터 보강(enrichment) 로직을 처음부터 세 번이나 따로 구축한 결과물입니다. 첫 번째 버전은 Claude Code에서 실행되며, 에이전트 기능(새로운 검토가 필요한 계정 결정, 검색 체이닝, 요약 작성)이 작업의 대부분을 차지합니다. 동료가 Codex가 특정 종류의 배치 스크립팅을 더 빠르게 처리한다고 언급하자, 엔지니어는 이를 확인하기 위해 데이터 보강 루프를 이식합니다. 세 번째 복사본은 하네스(harness)를 완전히 건너뛰고 API를 통해 모델을 직접 호출하여, 도구 오케스트레이션 없이 단일 프롬프트와 응답만 필요한 가벼운 야간 작업을 수행합니다. 동일한 작업이지만 세 개의 빌드가 만들어졌고, 각각 그 순간에 가장 적합했던 도구에 맞춰 설계되었습니다.

각 하네스는 자체 도구와 웹 검색을 번들로 제공하고 고유한 방식으로 연결하므로, 엔지니어는 각 하네스의 구성(config) 형식에 맞춰 동일한 데이터 보강 로직을 세 번이나 구축해야 합니다. 여기에 하루를 다 허비하게 됩니다. 계정 보강 방식을 개선하는 대신, 엔지니어는 Claude Code가 도구 선언을 요구하는 방식, 동일한 MCP 서버가 Codex에서 다르게 연결되는 이유, 그리고 다른 두 도구에서 기본으로 제공하던 기능 중 원시 API 경로에서 누락된 것이 무엇인지 파악하는 데 시간을 쓰고 있습니다.

도구들이 동일하지 않기 때문에 결과도 일관되지 않습니다. 한 하네스에 번들로 제공되는 웹 검색은 다른 하네스와 다른 데이터를 반환합니다. 한 곳에서 접근 가능한 소스를 다른 곳에서는 놓치기도 합니다. LLM용 내장 웹 검색 도구는 투자 유치나 경영진 교체와 같은 상위 수준의 정보는 찾을 수 있지만, 기술 스택 변경과 같은 세부적인 정보는 놓칩니다. 온라인 정보에 대한 액세스는 이 에이전트가 존재하는 핵심 이유이지만, 이제 그 품질은 웹에서 주요 세부 정보를 안정적으로 찾아내지 못하는 웹 검색에 의존하게 되었습니다.

그리고 이 세 가지를 통합하여 관리하는 상위 레이어가 없습니다. 공유된 측정기(meter)가 없기 때문에 수십만 개의 계정에서 발생하는 주기별 비용을 확인하거나 제한할 수 없습니다. 공유된 규칙이 없으므로 에이전트가 읽을 수 있는 소스와 사람이 승인하는 시점이 세 가지 방식으로 제각각 설정되거나 아예 설정되지 않습니다. 공유된 기록이 없기 때문에 결과가 잘못되었을 때 에이전트가 무엇을 읽고, 비용을 얼마나 쓰고, 어떤 결정을 내렸는지 재구성할 수 있는 방법이 없습니다.

결과를 만들어낸다는 점에서 어느 정도 작동은 합니다. 그리고 바로 그 이유 때문에 이 문제는 결코 해결되지 않습니다. 계속 사용할 만큼은 작동하지만, 완전히 신뢰하기에는 부족합니다.

Omnigent: 단 하나의 정의로 모든 하네스 지원

Omnigent는 이러한 무분별한 확장을 억제하는 레이어입니다. 개별 하네스의 상위에 위치하므로 엔지니어는 에이전트, 실행할 모델, 액세스할 수 있는 도구, 작동 범위 내의 정책 및 제한 사항을 단 한 번만 정의하면 됩니다. 세 번의 재구축 작업이 하나의 정의로 통합되며, 엔지니어는 다시 계정 보강 작업에 집중할 수 있습니다. 도구는 더 이상 각 하네스에 번들로 제공되는 것에 국한되지 않고 에이전트의 선언이 되어, 한 번 설정하면 자유롭게 교체할 수 있습니다. Databricks 호스팅 모델에서 실행되는 모델 호출은 Foundation Model APIs를 통해 라우팅되며, 여기서 모든 호출은 세 개의 런타임에 분산되는 대신 한 곳에서 비용, 감사 및 거버넌스를 위해 캡처됩니다. 또한 모델이나 비용 구조가 변경되면 엔지니어는 중단 없이 한 줄만 수정하여 새 모델을 선택하거나 더 저렴한 모델로 전환할 수 있습니다.

이를 통해 대부분의 무분별한 확장은 해결되지만, 설계가 아닌 기본 설정에 의해 결정되는 한 가지 중요한 문제가 남습니다. 웹 검색은 모든 하네스가 번들로 제공하는 핵심 기능 중 하나이지만, 동일한 검색 기능을 제공하는 하네스는 없습니다. 동일한 쿼리가 Claude Code를 통해서는 하나의 결과를, Codex를 통해서는 다른 결과를 제공합니다. Omnigent는 각 작업에 대해 일관된 선택을 정의할 수 있는 기능을 제공하지만, 결정을 대신 내려주지는 않습니다. 파트너 검색 기능을 할당해야 합니다. Nimble과 같은 파트너를 사용하면 슬롯에 작업에 맞게 조정되는 기능을 배치하고, 하위의 모든 하네스에 동일한 전문적인 분석 결과를 제공할 수 있습니다.

Nimble: 검색 슬롯 채우기

Nimble의 Search API는 실시간 검색을 통해 최신의 실시간 웹 데이터를 기반으로 답변을 제공할 수 있습니다. 심층적인 리서치 작업의 경우, Nimble의 Web Search Agents는 웹 검색 및 추출 오케스트레이션을 자동화하여 작업을 수행합니다. 여러 소스를 탐색하고 교차 검증한 후 각 주장을 뒷받침하는 인용구와 함께 답변을 반환하며, 이는 일반적인 방식으로는 결코 생성할 수 없는 감사 추적(audit trail)을 제공합니다.

일반적인 웹 검색 도구는 모든 사용 사례를 동일하게 처리하는 반면, Nimble은 에이전트의 특정 사용 사례에 특화되어 최상의 검색 방법을 스스로 학습하고, 웹 검색 및 크롤링을 도메인 깊숙이 적용하여 일반 검색 도구가 놓치는 데이터를 캡처합니다. 일반적인 크롤러가 포기하는 JavaScript, 필터, 페이지네이션(pagination) 뒤에 숨겨진 데이터까지 찾아냅니다. 또한 관련 데이터를 검색하는 최상의 방법을 기억하므로, 토큰 비용을 줄이기 위해 모든 것을 처음부터 다시 찾는 대신 데이터 검색 경로를 재사용합니다. 구성(config)에서 제공업체로 지정하면, 이는 에이전트에게 더 완전한 웹 컨텍스트를 제공하는 빠른 경로가 됩니다.

Nimble의 테스트에 따르면, Nimble의 웹 검색을 추가했을 때 LLM 벤치마크 정확도가 46%에서 71%로 향상되는 동시에 웹 검색 비용은 절반으로 줄어들었습니다(Claude 대 Nimble 웹 검색 비용 비교). Web Search Agents를 특정 도메인에 지정해 두면, 어떤 소스와 검색 경로가 올바른 데이터를 생성했는지 기억하고 다음 번에 이를 재사용합니다. 도메인에서 오래 작동할수록 더 정교해지며, 가장 자주 실행되는 계정에서 신호가 있는 위치를 다시 찾는 비용이 감소합니다.

버전 2.0: Databricks와 Nimble에서 단 한 번만 구축

다시 엔지니어의 이야기로 돌아가면, 이제 에이전트는 일관되고 관리 가능하며 신뢰할 수 있는 완전한 시스템으로 나아가고 있습니다. 에이전트는 Databricks 호스팅 모델을 기반으로 Omnigent에서 단 한 번 정의되며, 도구, 정책 및 제한 사항이 단일 사양(spec)에 포함됩니다. 세 번의 재구축 작업은 사라졌습니다. 불필요한 연결 작업(plumbing tax)도 사라졌습니다. 엔지니어는 각 하네스가 도구 선언을 요구하는 방식이 아니라, 다시 데이터 보강 작업에 집중하고 있습니다.

이제 웹 검색은 세 번이 아닌 단 한 번의 결정으로 끝납니다. web_search 빌트인에 Nimble을 지정하면 하위의 모든 하네스가 동일한 Nimble Search API를 가리켜 빠르고 효율적인 웹 검색을 수행할 수 있습니다:

원시 웹 데이터 대신 신뢰할 수 있는 답변이 필요한 계정의 경우, Omnigent는 리서치, 데이터 보강 또는 데이터 세트 구축을 위해 웹 검색 및 추출을 자동화하는 Nimble의 Web Search Agents를 활용할 수 있습니다.

키는 Nimble 계정에서 제공되며, 무료로 시작할 수 있습니다.

이제 제어 기능이 한곳으로 통합되었습니다. 모델 호출은 거버넌스 하에 Foundation Model APIs를 통해 라우팅되고, 비용은 한곳에서 시각화 및 제한되며, 에이전트가 읽고 소비하고 결정하는 모든 내용이 단일 거버넌스 표면에서 일관되게 캡처됩니다.

마침내 두 개의 조각이 하나로 합쳐졌습니다. Databricks의 내부 기록과 Nimble의 외부 신호가 한곳에 모여 단일 에이전트에 의해 관리되고 읽힙니다. 버전 1.0은 세 개의 하네스만 존재하고 통합된 관점이 없었습니다. 이제는 회사가 알고 있는 정보와 웹이 알려주는 정보를 기반으로, 데이터가 이미 존재하는 곳에서 실행되는 단 하나의 에이전트가 존재합니다. 이전에는 일관성이 없던 부분이 일관되게 유지되고, 얕았던 분석이 깊어졌으며, 외부 웹 컨텍스트 검색에 대한 완전한 거버넌스가 확보되었습니다.

지금 바로 사용해 보세요

이를 설정하는 데는 두 단계가 필요합니다.

Omnigent를 Databricks에 연결합니다. Databricks가 사용자를 대신해 Omnigent 서버를 실행합니다. 로컬 머신에서 Databricks 통합 기능이 포함된 CLI를 설치하고 해당 머신을 호스트로 등록합니다:

그런 다음 작업 공간(workspace) ID로 로그인하고 Databricks 호스팅 모델에서 첫 번째 에이전트를 실행합니다. Databricks 기반 Omnigent에서 시작할 수 있으며, 여기서는 관리형 설정의 처음부터 끝까지를 다루고 CLI 단계를 링크로 제공합니다. 먼저 확인해야 할 두 가지 필수 조건이 있습니다. 작업 공간에 Omnigent Beta가 활성화되어 있어야 하며, 작업 공간이 Unity AI Gateway를 지원하는 리전에 있어야 합니다. 다른 설치 방법 및 요구 사항은 전체 설치 참조 문서에서 확인할 수 있습니다.

에이전트가 관리형 서버에서 실행되므로 모든 환경에서 동일한 세션이 유지됩니다:

• 설치를 진행한 터미널
• 사용자의 응답을 기다리는 에이전트를 위한 알림 및 독(dock) 배지가 제공되는 네이티브 창인 데스크톱 앱
• 워크스페이스 URL을 입력하여 접속할 수 있는 네이티브 iOS 및 Android 앱 또는 모든 모바일 브라우저의 웹 UI인 모바일

검색 대상을 Nimble로 지정하세요. 앞서 설명한 한 줄의 코드 변경인 web_search 빌트인에 Nimble을 지정하면, Databricks에서 호스팅되는 모든 에이전트가 이를 기반으로 답변을 생성합니다. 신뢰할 수 있고 감사 가능한 작업을 원하신다면 리서치 패스(research pass)를 활용해 보세요. Nimble 커넥터 문서에서 두 가지 모두를 다룹니다. Nimble 키가 필요하며, 무료 체험을 시작하여 키를 발급받을 수 있습니다.

내부 데이터는 이미 확보되어 있습니다. 이제 동일한 플랫폼에서 두 영역을 모두 관리하며 에이전트가 웹의 나머지 영역에 대해 추론하도록 설정하는 일만 남았습니다.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)