Newscatcher CatchAll API: AI 에이전트를 위해 구축된 회수율 우선 웹 검색 테스트
Newscatcher CatchAll API에 한 가지 끈질긴 질문을 던졌다: 유럽에서 이번 분기에 일어난 모든 창고 화재를 찾아라. 상위 10개가 아니라 모든 것 말이다. 일반적인 검색 API는 순위가 매겨진 링크 페이지를 건네주고 긴 꼬리 결과는 조용히 버린다. 이건 "내 근처 최고의 피자 집" 같은 검색에는 괜찮지만, 전수 조사 작업에는 무용지물이다. Base 모드로 약 15분 후, CatchAll은 우리의 2026년 최고 AI 검색 API 테스트에서 순위 기반 API들이 절대 찾아내지 못한 지역 언론과 업계 출판물의 사건들을 돌려줬다. 각 결과는 링크가 아니라 하나의 구조화된 JSON 객체로 나타났다. 그 차이가 이 이야기의 전부다.
본격적으로 들어가기 전에 짧은 버전을 먼저 보자.
핵심 요점
- CatchAll은 회수율 우선 웹 검색 API다: 순위가 매겨진 검색 결과가 아니라 구조화된 이벤트 레코드를 반환한다.
- Newscatcher는 32개 쿼리 기준 79.8% 회수율과 F1 스코어 0.705를 보고한다. 홈페이지에서는 이를 86%로 반올림한다.
- 두 가지 모드: Lite(수초 단위, 약 100개 결과 한계)와 Base(비동기, 약 15분, 한계 없음).
- 열거 작업(컴플라이언스, 경쟁사 정보, 공급망 모니터링)에 최적화됨. SERP 순위 추적 도구가 아니다.
회수율 우선 검색은 모든 것을 찾는 데 최적화되고, 순위 우선 검색은 표면에 올라온 소수의 것들을 정렬하는 데 최적화된다. 이 한 문장을 기억하고 있으면 이 리뷰의 나머지가 다 이해된다.
CatchAll이란 무엇인가? (회수율 우선 웹 검색, 설명)
CatchAll은 Newscatcher의 회수율 우선 웹 검색 API다. 상위 약 10개 링크의 순위 목록 대신, 중복이 제거된 구조화된 이벤트 레코드 세트를 반환한다. 각 레코드는 인용문과 추출된 엔티티를 포함하는 단일 JSON 객체다. 회수율 우선이란 것은 목표가 완전성, 즉 관련된 모든 이벤트를 찾는 것이지, 짧은 목록을 관련성으로 순서 지우는 것이 아니라는 뜻이다.
Newscatcher는 직관적인 예시로 이를 설명한다: 유효한 이벤트가 200개 존재하는데 당신의 시스템이 5개만 찾아낸다면, 당신의 회수율은 2.5%다. "최고의 노트북이 뭘까?"라는 질문에는 괜찮다. 하지만 "올해 EU 핀테크 업체에 대한 모든 규제 조치"에는 2.5%의 답이 무용지물을 넘어 해로울 수도 있다. 왜냐하면 당신은 놓친 것이 무엇인지 볼 수 없기 때문이다.
이것이 CatchAll이 겨냥하는 카테고리 격차이며, 결코 가입하지 않더라도 이해할 가치가 있다. YC 런칭 피치는 이를 "회수율 우선 웹 검색 API"라고 부르며, Newscatcher의 CatchAll 웹 검색 API 제품 페이지에서 포지셔닝을 직접 읽을 수 있다. 솔직한 프레이밍이다: SERP API는 "내가 먼저 뭘 읽어야 할까?"에 답하고, CatchAll은 "완전한 목록이 뭘까?"에 답한다.
CatchAll 작동 방식: 검색 + 검증 파이프라인
CatchAll은 5단계 파이프라인을 실행한다: 쿼리 계획은 당신의 프롬프트를 여러 검색 각도로 재작성하고, 대규모 검색은 작업당 50,000개 이상의 페이지를 스캔하고, Leiden 알고리즘은 관련 페이지를 단일 이벤트로 클러스터링하고, LLM은 각 클러스터를 당신의 쿼리에 대해 검증하고, 살아남은 것들은 구조화된 JSON으로 돌아온다. 회수율은 스캔에서, 정밀도는 검증에서 나온다.
빠르게 분해해보자:
- 쿼리 계획. 하나의 쿼리가 여러 검색 프롬프트로 변환되어 다양한 표현과 이벤트 유형을 다룬다. 따라서 "창고 화재"는 "물류 센터의 화재"도 포착한다.
- 대규모 검색. Newscatcher는 단일 작업이 분당 약 10,000페이지로 50,000개 이상의 페이지를 풀어낼 때 결과 한계가 없다고 말한다. 지역 언론, 업계 간행물, 규제 서류에 도달한다. 이들은 주류 SERP가 맨 아래에 묻거나 건너뛴다.
- 클러스터링. Leiden 알고리즘은 밀도 있게 연결된 페이지를 커뮤니티로 그룹화한다. 평문으로는: 같은 로테르담 화재에 관한 30개 기사가 30개의 행이 아니라 1개의 이벤트로 축약된다.
- LLM 검증. 각 클러스터는 당신의 쿼리에 대해 채점되며, 관련 없는 것들은 버려진다. 이 단계는 실제 LLM 호출이 들어가므로, 프로덕션 에이전트 스택에서는 이들을 LLM 게이트웨이를 통해 라우팅해 비용을 제어하고 폴백을 확보하고 싶을 것이다.
- 구조화된 출력. 검증된 이벤트당 하나의 JSON 객체, 동적 스키마 포함.
Newscatcher는 매일 200만 개 이상의 실제 이벤트를 인덱싱하며, 새 이벤트는 수 시간 내에 도착한다고 보고한다. "완전성의 아키텍처"라는 기술 문서는 깊이 있는 내용을 원한다면 Leiden과 검증 내부를 다룬다.
여기가 내 창고-화재 테스트가 진행된 곳이다. Base 모드에서 열거 쿼리를 실행했고, 작업은 약 15분이 걸렸으며, 가치는 파이프라인이 약속하는 정확한 위치에 나타났다: 지역 및 업계 출처, 개별 이벤트로 클러스터링되어, 순위 기반 SERP가 맨 아래에 묻거나 완전히 건너뛸 이벤트들.
핵심 기능: 모니터(Monitor)와 감시 목록(Watchlist), 이벤트 추출
일회성 검색 외에도, CatchAll은 모니터와 감시 목록을 제공한다. 모니터는 정기적인 재실행(최소 1시간 간격)으로, 마지막 실행 이후 새롭고 중복 제거된 이벤트만 반환한다. 감시 목록은 엔티티로 필터링하며, 1-10의 관련성 점수와 언어 및 관할권 전체에서 동일 회사를 매칭하는 엔티티 해석을 제공한다.
모니터는 일회성 검색을 지속적인 감시로 바꾼다: 각 실행은 마지막 이후 새로운 이벤트만 반환한다. 이것이 "오늘 웹을 검색하라"와 "뭔가 바뀌는 순간 내게 말해줘" 사이의 차이다.
"실시간 이벤트 모니터링 API" 프레이밍에 대해 솔직한 주의 한 가지: 여기서 "실시간"이란 1시간 간격의 재실행을 의미하지, 밀리초 단위의 스트리밍이 아니다. 밀리초 단위의 푸시 알림이 필요하다면 이건 아니다. 하루에 두 번 체크하는 컴플라이언스 팀에는 시간 단위면 충분 이상이다. Company Watchlist는 경쟁 정보에서 눈에 띈다. "Acme GmbH," "Acme Inc," "Acme Holdings"를 세 개의 시끄러운 것이 아니라 하나의 추적된 엔티티로 해석하기 때문이다.
구조화된 JSON 출력 (실제 예시 포함)
모든 결과는 하나의 이벤트로 하나의 JSON 객체다: cluster_id, title, relevance score, entities 배열, source_citations 배열을 포함한다. HTML 스크래핑도 없고, 파싱할 링크 목록도 없다. 이것이 CatchAll을 SERP 래퍼가 아니라 진정한 구조화된 웹 검색 API로 만드는 이유다.
내 창고-화재 실행에서 온 축약된 이벤트 하나다. 약간 정리했지만 실제 구조다:
{
"cluster_id": "warehouse_fire_rotterdam_q2_2026",
"title": "Rotterdam logistics facility fire causes supply chain disruptions",
"relevance_score": 0.94,
"entities": [
{"type": "location", "value": "Rotterdam, Netherlands"},
{"type": "facility_type", "value": "warehouse"},
{"type": "date", "value": "2026-06-15"}
],
"source_citations": [
{
"title": "Major warehouse fire halts logistics in Rotterdam hub",
"url": "https://example-trade-pub.com/logistics/fire-rotterdam-2026",
"source": "Logistics Trade Weekly",
"published_date": "2026-06-15"
}
]
}
source_citations 배열이 지역 업계 출판물을 가리킨다. 정확히 순위 API가 낮은 우선순위를 매기는 종류의 출처다. 각 이벤트가 이미 구조화되어 있으므로, 검증된 레코드를 스크래핑이나 정리 단계 없이 직접 RAG 파이프라인에 떨어뜨리거나 벡터 데이터베이스에 저장해서 임베딩할 수 있다. 그 생략된 단계가 조용한 생산성 승리다.
Python에서 CatchAll을 어떻게 호출하나? (코드 빠른 시작)
API 키를 얻어서 x-api-token 헤더로 /v3/search에 POST를 하고 events 배열을 파싱한다. 이게 전부 루프다. 최소한의 Python 호출:
import requests
response = requests.post(
"https://api.newscatcher.com/v3/search",
headers={"x-api-token": "YOUR_API_KEY"},
json={
"q": "warehouse fire Europe",
"mode": "base", # or "lite"
}
)
events = response.json()["events"]
for event in events:
print(f"{event['title']} - {event['relevance_score']}")
한 가지 팁이자 함정: Lite 모드는 수초 만에 반환되지만 약 100개 결과 근처에서 한계를 맞고, Base 모드는 비동기이며 깊은 작업의 경우 약 15분이 걸린다. Base의 경우, 단일 호출을 대기하지 말고 제출하고 폴링한다. CatchAll을 에이전트에 연결할 때는 함수 호출을 통해 도구로 일반적으로 호출한다. 배포 전에 정확한 요청 매개변수와 Lite 대 Base 플래그를 CatchAll 문서에 대해 확인하자. 인증 헤더는 x-api-token이다.
CatchAll 비용은 얼마인가? 무료 티어가 있나?
가격은 사용량 기반이며 검증된 레코드당 약 $0.10이고, 결과가 없으면 비용이 없다. 가입 시 약 2,000 크레딧의 무료 티어와 한 달에 약 10회 검색이 있으며, 카드 없이 진행할 수 있다. 커밋하기 전에 실제 열거 테스트를 실행할 수 있다.
그 영 결과-영 요금 모델은 열거 작업에 중요하다: 정상적으로 매칭 이벤트가 없는 쿼리는 예산을 버리지 않는다. Google의 검색 API가 무료인가에 대한 흔한 질문에 대해, 기본 Google과 Bing 검색은 아니다. 이들은 순위 있는 링크를 반환하고 구조화된 검증 이벤트가 아니다. Bing의 검색 API는 폐지되고 있으며, 이것이 독립적 인덱스가 주목을 받는 이유의 일부다.
실제 사용 사례
...