검색은 AI 에이전트가 사용할 수 있는 가장 중요한 외부 능력 중 하나가 되었습니다. 강력한 모델은 훌륭하게 추론할 수 있지만, 한 번도 검색되지 않은 사실을 복구할 수 없고, 증거 없이 최신 정보와 오래된 보도를 구분할 수 없으며, 누락된 회사 기록...

검색은 AI 에이전트가 사용할 수 있는 가장 중요한 외부 기능 중 하나가 되었습니다. 강력한 모델은 추론을 잘 수행할 수 있지만, 검색되지 않은 사실은 복구할 수 없고, 증거를 바탕으로 최신 정보와 오래된 정보를 구분할 수 없으며, 누락된 회사 기록을 신뢰성 있게 추론할 수 없습니다.
AnySearch는 이 문제를 사용자 대상 검색 페이지가 아닌 에이전트 대상 인프라로 간주합니다. 단순히 링크, 제목, 짧은 발췌문을 반환하는 대신, 쿼리를 관련 웹 또는 수직적 출처로 라우팅하고, 중복 및 저가치 콘텐츠를 제거하며, 유용한 정보를 추출하고, 모델의 추론 컨텍스트에 직접 입력할 수 있는 구조화된 응답을 제공합니다.
이 제품은 2026년 7월 6일 당일 및 당주 모두 Product Hunt 1위를 차지했습니다. 출시 소개에서는 API, MCP 서버 또는 설치 가능한 에이전트 스킬을 통해 실시간, 필터링, 중복 제거, 구조화된 정보를 제공한다고 강조합니다.

본 문서는 이러한 에이전트 중심 검색 워크플로우와 기존 검색 API의 차이점을 설명하고, 원본 보고서에 제시된 예시를 상세히 분석하며, 실용적인 설치 및 평가 가이드를 제공합니다.
벤치마크 참고사항: 아래의 정확도 및 지연 시간 데이터는 원본 기사에서 재현된 AnySearch 비교 결과를 기반으로 합니다. 본 버전에서 검토한 공개 자료에는 완전한 평가 코드, 원본 출력, 평가 프롬프트 또는 통계 분석이 포함되어 있지 않습니다. 이 데이터를 독립적으로 재현된 벤치마크가 아닌 공급업체 보고 결과로 간주하시기 바랍니다.
인간은 결과 페이지를 탐색하고, 광고를 무시하며, 중복 기사를 식별하고, 어떤 링크가 주목할 가치가 있는지 판단할 수 있습니다.
반면 에이전트는 각 결과를 입력으로 수신하는 경향이 있으며, 이는 여러 비용을 발생시킵니다:
문제는 검색 정확도뿐만 아니라 반환되는 정보의 형태와 밀도에 있습니다.
따라서 실용적인 에이전트 검색 시스템은 정보를 모델에 전달하기 전에 세 가지 질문에 답해야 합니다:
AnySearch는 이러한 단계를 중심으로 설계되었습니다.
AnySearch는 2026년 7월 6일 Product Hunt 당일 및 당주 1위를 차지했습니다. Product Hunt는 이를 다음과 같이 설명합니다:
에이전트와 개발자가 신뢰하는 실시간 구조화 검색으로, 병렬 검색 출처에서 필터링 및 중복 제거된 정보를 제공합니다.
해당 원본 기사는 세 가지 벤치마크 그룹으로 구성된 300문항 평가 체계도 소개했습니다:
기사에 따르면 AnySearch, Brave Search, Parallel은 모두 동일한 언어 모델을 사용했으므로, 검색 계층(모델 선택이 아닌)이 주요 변수입니다.
| 검색 시스템 | 전체 정확도 | FreshQA | WebWalkerQA |
|---|---|---|---|
| AnySearch | 76.4% | 80.0% | 65.2% |
| Brave Search | 64.0% | 74.0% | 46.8% |
| Parallel | 72.2% | 78.0% | 61.0% |

FreshQA는 현재 또는 변화하는 정보에 의존하는 질문을 평가합니다. WebWalkerQA는 여러 페이지에 걸쳐 웹사이트를 탐색하고 증거를 찾는 능력에 중점을 둡니다. 이 두 가지를 결합하면, 단순한 링크 목록 이상을 필요로 하는 에이전트에게 매우 적합합니다.
FRAMES는 원본 기사의 종합 평가에 포함되었지만, 기사에 표시된 벤치마크별 차트는 종합 점수 외에 FreshQA와 WebWalkerQA만 보여줍니다.
지연 시간 차트는 평균 비교와 WebWalkerQA 하위 집합 모두에서 AnySearch의 수치가 더 낮음을 보여줍니다.
| 검색 시스템 | 평균 지연 시간 값 | WebWalkerQA 지연 시간 값 |
|---|---|---|
| AnySearch | 48.0 | 76.5 |
| Brave Search | 68.9 | 133.0 |
| Parallel | 77.4 | 145.6 |

원본 이미지에는 단위가 명확하게 표시되지 않았으므로, 표는 의도적으로 보고된 값을 그대로 유지하였으며 초나 밀리초로 변환하지 않았습니다.
AnySearch는 현재 세 가지 주요 통합 방식을 지원합니다:
공식 GitHub 프로젝트는 Apache-2.0 라이선스의 스킬 및 MCP 서버를 제공합니다. 둘 다 일반 웹 검색, 수직적 검색, 병렬 배치 검색 및 전체 페이지 URL 추출을 지원합니다.

이 이미지는 문서에서 AnySearch를 소개하는 내용과 관련되어 있으며, AnySearch의 기능과 특징을 직관적으로 보여줍니다. 독자가 지원하는 검색 유형 등을 더 명확히 이해할 수 있도록 돕습니다.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/80912d0a-73aa-4f80-bbab-eb6f0779cd63-e96fb0d4-000e-4288-ae1b-bf3c078c578f.png)
공식 저장소에서는 메인 브랜치에서 미공개 변경 사항을 직접 가져오는 대신 고정 릴리스(pinned release)를 다운로드할 것을 권장합니다.
브랜치.
# 지정된 버전의 AnySearch Skill 릴리스를 다운로드합니다.
# 릴리스 페이지를 확인하고, 더 최신의 안정적인 버전이 있을 경우 v2.1.0을 대체하십시오.
curl -L -o anysearch-skill.zip \
https://github.com/anysearch-ai/anysearch-skill/archive/refs/tags/v2.1.0.zip
# 릴리스를 압축 해제합니다.
unzip anysearch-skill.zip
압축 해제된 디렉터리를 에이전트가 사용하는 적절한 위치로 이동합니다:
# Claude Code
mv anysearch-skill-2.1.0 ~/.claude/skills/anysearch
# OpenCode
mv anysearch-skill-2.1.0 ~/.config/opencode/skills/anysearch
# Cursor 또는 Windsurf 프로젝트
mv anysearch-skill-2.1.0 /.skills/anysearch
# 공유 에이전트 위치
mv anysearch-skill-2.1.0 ~/.agents/skills/anysearch
정확한 디렉터리는 에이전트 플랫폼과 현재 스킬 탐색 규칙에 따라 다릅니다.
공식 스킬 및 MCP 문서에 따르면 익명 액세스의 속도 제한은 낮습니다. API 키는 선택 사항이지만, 더 안정적이거나 높은 사용량을 위해 사용을 권장합니다.
API 키를 공개 저장소에 제출하지 마십시오. 환경 변수, 키 관리자 또는 무시되는 로컬 설정 파일에 저장하십시오.
원문의 첫 번째 테스트는 에이전트가 튜토리얼이 아닌 실제 프로덕션 환경용 Go API 속도 제한기 구현체를 찾도록 요구합니다.
프롬프트 내용:
Go로 API 속도 제한기를 구현하는 프로젝트를 진행 중입니다. 튜토리얼은 필요 없습니다. 실제 오픈소스 프로젝트에서 프로덕션 코드를 찾아주세요.
전용 검색 워크플로우 없이, 해당 에이전트는 일반적인 링크와 단편적인 코드 조각을 반환한 것으로 보고되었습니다. 이러한 결과는 개념을 설명할 수는 있지만, 개발자가 완전한 구현 컨텍스트를 필요로 할 때 도움이 제한적입니다.
AnySearch를 활용한 실행은 더 구조화된 코드 중심의 결과를 반환했으며, 더 명확한 호출 체인과 실제 코드베이스의 자료를 포함했습니다.
이 차이는 프로덕션 코드가 단순한 알고리즘 이상이기 때문에 매우 중요합니다. 유용한 검색 결과는 에이전트가 다음을 검토하는 데 도움을 주어야 합니다:
예쁜 함수만 추출하고 그 컨텍스트 가정을 무시하는 코드 검색은 구현 에이전트를 오도할 수 있습니다.
검색 제공업체와 관계없이, 더 명확한 쿼리는 결과를 개선할 수 있습니다:
유지 관리 중이며, 프로덕션 코드에서 API 속도 제한기를 구현한 오픈소스 Go 프로젝트를 찾습니다.
요구 사항:
- 저장소와 정확한 파일 경로를 반환합니다.
- 실제 서버나 게이트웨이에서 사용되는 코드를 우선시합니다.
- 초기화 및 요청 흐름 컨텍스트를 포함합니다.
- 알고리즘, 백엔드 저장소, 테스트 및 라이선스를 명시합니다.
- 튜토리얼 코드베이스와 복사된 코드 조각은 제외합니다.
- 최근 관련 커밋의 날짜를 명시합니다.
검색 시스템은 증거를 제공해야 합니다. 코딩 에이전트는 코드를 적용하기 전에 여전히 저장소, 라이선스, 테스트, 보안 가정 및 현재 유지 관리 상태를 확인해야 합니다.
두 번째 테스트
동일한 기업 조사 요구 사항에서 AnySearch와 Exa를 비교했습니다.
두 보고서 모두 기본적인 공개 기업 정보에서는 좋은 성과를 보였습니다. 차이는 주로 위험 부분에서 나타났습니다.
AnySearch가 Exa 보고서에는 누락된 현지 발행 규정 준수 기록과 플랫폼 공지를 찾은 것으로 보고되었습니다. 정보 출처는 이러한 차이를 언어 모델 자체보다는 중국 내 수직적 데이터 소스에 대한 접근성 차이로 돌렸습니다.


이 예시는 기업 조사에서 흔한 한계를 강조합니다. 글로벌 웹 인덱스는 조직의 공식 웹사이트, 국제 뉴스 및 영어 데이터베이스를 잘 포괄할 수 있지만, 현지 규제, 법원, 민원 또는 플랫폼 기록은 놓칠 수 있습니다.
실사 에이전트는 여러 범주를 명시적으로 검색해야 합니다:
중요: 검색 지원 실사는 전문적인 법률, 재무 또는 규정 준수 검토를 대체할 수 없습니다. 기록이 불완전할 수 있고, 명칭이 혼동될 수 있으며, 자동 요약이 증거를 잘못 해석할 수도 있습니다.
세 번째 테스트는 AnySearch에 글로벌 에너지 시장 보고서 생성을 요청했으며, 다음 내용을 포함합니다:
정보 출처가 보여준 출력 결과에는 지역 재고 세부 정보, 유럽 전력 가격 비교 및 배출 데이터가 포함되었습니다. 해당 보고서는 7월 9일 미국 에너지 정보청(EIA) 데이터와 7월 12일 유럽 당일 전력 가격 등 최근 정보를 인용했습니다.


이 그림은 문서의 테스트 3 내용과 관련되어 있으며, 유럽 여러 국가의 당일 전력 가격 데이터를 보여줍니다. 이는 AnySearch가 생성한 글로벌 에너지 시장 보고서의 일부입니다.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/3f5432f8-0641-4e6e-b8aa-62b6a50e7d18-f18fcac7-52c7-4efa-a066-9c9722c9cea9.jpeg)
이는 다영역 조회의 대표적인 예시로, 시스템이 단일 일반 웹 검색이 아닌, 하나의 요청에 포함된 여러 독립적인 데이터 경로를 식별해야 함을 요구합니다.
신뢰할 수 있는 구현은 다음을 충족해야 합니다.
현재 데이터에는 항상 타임스탬프가 포함되어야 합니다. 보고서가 기초 측정의 발행 시간 및 적용 기간을 명시하지 않는다면, '최신'이라는 용어는 의미가 없습니다.
핵심 설계 주장은 AnySearch가 에이전트 행동을 중심으로 검색 파이프라인을 재구축한다는 것입니다.
소스 코드에 표시된 프로세스는 5단계로 구성됩니다.

시스템은 먼저 쿼리에 어떤 유형의 증거가 필요한지 식별합니다.
아이디어를 한 문장으로 입력하면 We0 AI가 쇼케이스 사이트, 페이지, CMS를 생성하고 출시 후 고객과 트래픽 확보를 돕습니다.
무료 등록을 위한 하나의 완전한 프로젝트 생성
하나의 완전한 생성 흐름을 시도하고 첫 번째 프로젝트 초안을 빠르게 보는 데 가장 적합합니다.
기업 배경 조회에는 등록 기록, 특허, 법률 데이터베이스 및 불만 플랫폼이 필요할 수 있습니다. 코드 관련 질문은 코드 저장소와 문서로 라우팅되어야 합니다. 에너지 시장 조회에는 공식 재고 및 전력 시장 데이터가 필요할 수 있습니다.
이는 모든 요청을 하나의 일반 색인으로 처리하는 방식과는 완전히 다릅니다.
AnySearch는 일반 검색 외에도 다음 분야를 포함한 20개 이상의 수직 카테고리를 지원한다고 밝힙니다.

공개 MCP 인터페이스에는 도메인 디렉터리 메서드가 포함되어 있습니다. 에이전트는 지원되지 않는 필터를 직접 생성하는 대신 유효한 도메인과 매개변수 스키마를 요청해야 합니다.
여러 도메인에 걸친 질문은 여러 개의 독립적인 검색을 시작할 수 있습니다. MCP 서버는 1~5개의 쿼리 객체를 일괄 실행할 수 있으며, 특정 분기의 실패가 다른 분기의 실행을 차단하지 않습니다.
병렬 검색은 총 대기 시간을 줄일 수 있지만, 집계 계층이 빠르게 나타난 저품질 결과가 느리지만 권위 있는 결과를 밀어내는 것을 방지할 수 있어야 합니다.
증거.
원문에서는 세 가지 정렬 방식을 제시합니다.
기대 목표는 콘텐츠가 언어 모델에 진입하기 전에 더 많은 필터링을 수행하는 것입니다.
이는 대량의 결과 세트를 반환하고 모델이 자체적으로 중복을 제거하도록 하는 파이프라인과 다릅니다. 사전 필터링은 토큰을 절약할 수 있지만, 또 다른 책임을 도입합니다. 정렬 시스템은 소수 출처나 중요한 모순 레코드를 조용히 제거해서는 안 됩니다.
정렬 후 AnySearch는 주요 콘텐츠를 추출하고 페이지 노이즈를 제거하며 결과를 Markdown 형식으로 변환합니다.
공식 MCP 서버는 URL 추출 작업도 제공하여 페이지 콘텐츠를 Markdown 형식으로 반환하며, 명확한 잘림 제한은 50,000자입니다.

구조화된 출력은 다음 내용이 포함될 경우 모델에 필요한 작업량을 줄일 수 있습니다.
에이전트가 동일한 이벤트에 대한 10개의 결과를 수신한다고 가정해 보겠습니다. 그중 7개가 동일한 원본 보고서를 재가공한 것이라면, 컨텍스트는 7개의 독립적인 확인 정보가 아닌 반복된 주장으로 채워집니다.
이는 세 가지 문제를 야기합니다.
소스 기반 중복 제거는 단순히 순위가 가장 높은 페이지를 유지하는 것이 아니라 고유한 증거를 보존하는 것을 목표로 합니다.
실용적인 에이전트 검색 응답은 출처 정보를 확인 가능하게 만들어야 합니다. 개발자는 5개의 결과가 5개의 원본 소스, 동일한 소스의 5개 연합 게시물, 또는 주요 및 보조 증거의 혼합을 나타내는지 알 필요가 있습니다.
원문에서는 낮은 토큰 소모를 AnySearch의 장점으로 설명하지만, 보편적인 토큰 감소 비율은 공개되지 않았습니다.
절감량은 다음에 따라 달라지기 때문에 이는 합리적입니다.
공정한 평가는 첫 번째 검색 응답뿐만 아니라 전체 태스크를 측정해야 합니다.
유용한 지표는 다음과 같습니다.
| 지표 | 측정 내용 |
|---|---|
| 검색 입력 토큰 | 검색 자료가 소모한 컨텍스트 |
| 에이전트 총 토큰 | 검색, 추론, 후속 작업, 최종 생성 |
| 검색 라운드 당 호출 횟수 | 약한 검색이 반복 검색을 유발하는지 여부 |
| 고유 출처 수 | 중복 제거 후 증거 다양성 |
| 인용 정확도 | 인용된 출처가 관련 주장을 뒷받침하는지 여부 |
| 답변 완전성 | 응답이 필요한 모든 차원을 포괄하는지 여부 |
| 종단 간 지연 시간 | 태스크 완료에 필요한 시간 |
| 태스크 성공률 | 에이전트가 의도된 목표를 달성하는지 여부 |
핵심 증거를 생략한 짧은 응답은 최적화 전략이 아닙니다. 토큰 수 감소는 응답 품질과 추적 가능성이 유지될 때만 가치가 있습니다.
실제 프로덕션 환경에서 사용되는 검색 컴포넌트는 제품 데모에서는 거의 발생하지 않는 장애 문제를 처리해야 합니다.
리소스 출처는 다음과 같은 특성을 강조합니다.
공개 MCP 문서는 또한 다음 기능을 지원합니다.

프로덕션 팀은 여전히 자체 통제 조치를 추가해야 합니다.
검색 출력은 신뢰할 수 없는 외부 입력입니다. 비록 정리된 Markdown 텍스트라도 악의적인 명령, 허위 진술 또는 손상된 콘텐츠를 포함할 수 있습니다.
전통적인 검색은 사용자가 페이지를 찾도록 돕습니다. 에이전트 검색은 목표가 다릅니다: 추론과 실행을 위해 기계가 사용할 수 있는 증거를 제공하는 것입니다.
이는 설계 우선순위를 변경합니다.
| 인간 중심 검색 | 에이전트 중심 검색 |
|---|---|
| 빠른 브라우징에 최적화 | 기계 처리에 최적화 |
| 링크 및 요약 | 구조화된 증거 |
| 사용자가 직접 중복 제거 | 시스템이 중복을 줄여야 함 |
| 사용자가 만료일 확인 | 날짜가 명시적으로 표시되어야 함 |
| 사용자가 신뢰도 결정 | 출처 및 품질 신호 필요 |
| 브라우징은 탐색적일 수 있음 | 반복 검색은 시간과 토큰 소모 |
| 시각적 레이아웃 중요 | 안정적인 구조와 Markdown 중요 |
모델은 에이전트가 증거를 사용하여 추론하는 능력을 결정합니다. 검색 레이어는 처음에 어떤 증거를 사용할 수 있는지 결정합니다.
모델 성능이 향상됨에 따라 검색 품질의 중요성은 더욱 커집니다. 강력한 모델은 빈약한 컨텍스트를 기반으로도 매우 설득력 있는 답변을 생성할 수 있습니다. 이는 출처 선택, 시의성, 추적 가능성을 에이전트 안전성 및 신뢰성 시스템의 일부로 만듭니다.
개발자는 단일 공개 벤치마크나 인상적인 안전 데모 하나만 보고 검색 제공자를 선택해서는 안 됩니다.
대신 실제 시나리오를 기반으로 평가 세트를 구축해야 합니다.
귀하의 에이전트가 수행하는 바로 그 태스크를 기반으로요.
간단한 경우와 어려운 경우를 모두 포함합니다.
각 제공자에 대해 동일한 모델, 프롬프트, 도구 전략, 출력 형식을 사용합니다.
모델이 요약하기 전에 반환된 출처를 저장합니다. 그렇지 않으면 오류가 검색 과정에서 발생했는지 추론 과정에서 발생했는지 판단할 수 없습니다.
지연 시간, 총 토큰 수, 중복 검색 호출 횟수, 적용 범위, 인용 지원, 시의성, 실패율을 측정합니다.
금융, 법률, 보안, 의료 및 규정 준수 작업은 전문가의 검토가 필요합니다. 검색 API는 증거 수집을 개선할 수 있지만, 전문적 책임을 대신할 수는 없습니다.
특정 소스를 비활성화하고, 특정 경로를 느리게 하며, 잘못된 형식의 콘텐츠를 반환하고, 중복 결과를 주입합니다. 프로덕션 환경의 신뢰성은 검색이 완벽하지 않을 때 시스템이 어떻게 작동하는지에 따라 달라집니다.
AnySearch는 AI 에이전트와 개발자를 위해 설계된 실시간 검색 인프라 서비스입니다. 웹 검색, 수직 분야 검색, 일괄 검색 및 구조화된 출력을 포함한 전체 텍스트 추출 기능을 제공합니다.
사용자가 검색을 시도할 수 있는 웹사이트가 있지만, 주요 포지셔닝은 에이전트 인프라입니다. 핵심 통합 방식은 API, MCP 및 설치 가능한 Skill입니다.
공식 Skill 및 MCP 문서에 따르면 익명 액세스는 속도 제한과 할당량이 낮습니다. API 키는 선택 사항이지만, 더 정기적인 사용을 위해 권장됩니다.
공개 문서에는 금융, 학술 연구, 보안, 법률 정보, 코드 및 기타 카테고리가 언급되어 있습니다. 에이전트는 특정 도메인 매개변수를 사용하기 전에 지원되는 도메인 디렉토리를 조회해야 합니다.
검색 전에 쿼리를 라우팅하고, 중복 소스를 줄이며, 정보 밀도가 높은 결과를 우선 처리하고, 페이지 노이즈를 제거하며, 구조화된 Markdown 형식을 반환합니다. 실제 토큰 절감 효과는 쿼리 내용과 광범위한 에이전트 워크플로우에 따라 달라집니다.
해당 점수는 AnySearch에서 보고되었으며 원본 기사에서 재현되었습니다. 검증 과정에서 완전한 공개 평가 패키지는 발견되지 않았으므로, 이 결과는 공급업체가 보고한 비교 데이터로 간주되어야 합니다.
아니요. 회사, 법률, 재무 및 공공 위험 정보를 수집하는 데 도움을 줄 수 있지만, 전문가가 신원, 출처의 권위, 완전성, 관할권 및 해석을 반드시 확인해야 합니다.
AnySearch Skill 및 MCP 서버의 코드베이스는 Apache-2.0 라이선스로 공개되어 있습니다. 호스팅된 API 백엔드는 별도의 서비스이며, 해당 코드베이스의 라이선스 범위에 포함되지 않습니다.
AnySearch는 검색을 사용자가 탐색하는 페이지 목록이 아닌 에이전트의 입력 계층으로 간주합니다. 일반 및 수직 소스를 넘나들며 쿼리를 라우팅하고, 여러 경로를 검색하며, 증거를 정렬 및 중복 제거하고, 페이지 노이즈를 제거한 후 API, MCP 또는 Skill 통합을 통해 구조화된 콘텐츠를 반환합니다.
소스의 예시는 이러한 설계가 프로덕션 코드 발견, 현지 회사 실사 및 현재의 다중 시장 데이터에 왜 중요한지 보여줍니다. 각 경우에서 에이전트는 단순한 관련 링크가 아니라 완전하고 시의적절하며 추적 가능한 증거가 필요합니다.
Product Hunt 순위와 공급업체가 보고한 벤치마크 결과는 AnySearch를 테스트해볼 가치가 있게 만들지만, 팀은 프로덕션 검색 스택을 교체하기 전에 자체 쿼리, 모델, 토큰 계산 및 품질 기준을 사용하여 비교 결과를 재현해야 합니다.
에이전트 워크플로우에서 모델은 증거를 처리하는 방법을 결정하고, 검색 계층은 올바른 증거가 모델에 도달할 수 있는지 여부를 결정합니다.