에이전트 검색 도구 선택 방법: 탐색부터 검증된 답변까지

검색 에이전트는 관련 있어 보이는 링크를 10개 나열하고도 특정 파라미터가 현재 지원되는지에는 답하지 못할 수 있습니다. 링크가 오래된 버전을 가리키거나, 스니펫에서 제한 사항이 빠지거나, 여러 글이 같은 공지를 인용할 수 있기 때문입니다. 이럴 때 다음 단계는 검색 횟수를 늘리는 것보다 원본 페이지를 읽는 것인 경우가 많습니다.

도구를 선택할 때는 먼저 현재 단계의 결과물을 명확히 하십시오. 읽어야 할 출처인지, 특정 페이지의 콘텐츠인지, 구체적인 결론을 뒷받침하는 증거인지입니다. 이 글은 EveryInfra 검색 도구를 이 세 가지 결과물 기준으로 정리하고, 언제 검색을 멈추고 미확인 사항을 남기며 인용을 검증해야 하는지 설명합니다. 카탈로그와 타임스탬프가 있는 과거 호출 기록은 따로 문서화되어 있으며, 이 글은 모든 도구를 벤치마크하거나 종단 간 리서치 시스템을 제공한다고 주장하지 않습니다.

질문을 먼저 검증 가능한 명제로 바꾸기

"이 제품을 이해하기"는 리서치 방향으로는 괜찮지만 도구의 완료 조건으로는 쓸 수 없습니다. 이를 검증 가능한 질문으로 나누십시오. 어떤 엔드포인트가 이 파라미터를 받는지, 어떤 버전에 해당하는지, 추가 권한이 필요한지, 실패 시 재시도할 수 있는지입니다. 각 질문에는 기준 시점, 제품, 사용 맥락을 명시해야 합니다.

예를 들어 원격 서비스가 특정 클라이언트와 연동되는지 확인하는 편집자는 서비스가 지원하는 전송 방식, 클라이언트가 받는 인증 방식, 해당 클라이언트에서 호출이 실제로 성공했는지를 따로 확인해야 합니다. 앞의 두 가지는 문서에서 확인할 수 있지만, 세 번째는 실행 시점의 증거가 필요합니다. 두 문서가 각각 MCP 지원을 언급하더라도, 실행 증거 없이 이를 합쳐 연동이 검증되었다고 볼 수는 없습니다.

질문마다 기대하는 증거 유형을 기록해 두면 검색 범위가 계속 넓어지는 것을 막을 수 있습니다. 파라미터 정의는 해당 버전의 공식 레퍼런스 문서를 우선하고, 실제 장애 현상은 구체적인 입력, 오류, 환경이 필요하며, 고객 성과는 허가받고 추적 가능한 사례가 필요합니다. 해당하는 증거가 없으면 다른 자료로 대신하지 말고 결론의 범위를 좁히십시오.

이 파이프라인을 이해하려면 Lewis 등의 RAG 원 논문을 참고하십시오. 이 논문은 파라미터에 담긴 지식만을 유일한 근거로 삼지 않고 생성 모델과 검색 저장소를 결합합니다. 이 글에서 다루는 탐색, 읽기, 항목별 검증은 애플리케이션 계층의 설계이며, 논문의 실험 결과를 웹 에이전트의 정확도 보장으로 확대 해석하지 않습니다.

페이지 위치를 모를 때만 탐색부터 시작하기

질문은 있지만 URL이 없을 때는 web으로 관련 있을 만한 페이지를 찾는 것부터 시작하십시오. 2026년 9월 4일 기준 공개 카탈로그에는 q가 필수 파라미터로, 사이트, 지역, 기간, 페이지 번호 등이 선택 파라미터로 나열되어 있습니다. 자연어로 파라미터 이름을 추측하지 말고 호출 전에 항상 현재 카탈로그를 확인하십시오.

탐색 단계 도구는 입력과 기대 출력에 따라 선택할 수 있습니다:

• semantic은 자연어로 개념을 설명할 때 적합하고, suggest는 검색어 표현을 찾는 데 사용합니다. 연관어는 검색 단서일 뿐 결론이 아닙니다.
• similar는 기존 URL을 출발점으로 유사한 페이지를 찾고, deep은 더 깊은 검색 진입점을 제공합니다. 도구 이름에 "deep"이 들어 있다고 해서 해당 페이지가 현재 증거 요건을 충족한다는 뜻은 아닙니다.
• news, scholar, forum은 검색 범위를 뉴스, 학술 콘텐츠, 토론으로 옮깁니다. 바뀌는 것은 출처 범위이며, 사실 자동 검증의 기준은 바뀌지 않습니다.
• places, shopping, media, lens는 각각 장소, 상품, 미디어 키워드, 이미지 URL을 대상으로 합니다. 입력이 서로 다르므로 q만 받는 단일 함수로 묶을 수 없습니다.

포럼에 올라온 구체적인 오류 메시지는 문서에서 다루지 않는 환경 차이를 드러낼 수 있습니다. 그렇더라도 사람들의 논의가 버전이 일치하는 공식 정의보다 우선해서는 안 됩니다. 더 유용한 방법은 충돌을 그대로 보존하는 것입니다. 문서에는 지원한다고 되어 있지만 특정 환경에서는 실패가 보고된다는 사실을 기록하고, 두 결과가 왜 다른지 판단하려면 어떤 재현이 더 필요한지 구체적으로 적어 둡니다.

URL이 있다면 반복 검색 대신 읽기로 전환하기

지정한 페이지의 콘텐츠는 read가 처리합니다. 사이트 내 페이지 구조를 살펴볼 때는 map을 사용하고, 여러 페이지를 읽어야 한다면 crawl을 고려하십시오. harvest는 단일 페이지 읽기의 기본 진입점으로 쓰지 말고, 구조화된 사이트 작업에 맞는지 목표와 필드 요구 사항을 검토한 뒤 사용하십시오.

이 구분은 이후의 검증에 영향을 줍니다. map으로 URL 목록을 얻었더라도 발견한 페이지를 읽은 콘텐츠로 기록해서는 안 되며, 검색 스니펫에서 추출한 문장도 완전히 검증된 것으로 표시할 수 없습니다. 콘텐츠가 잘렸거나, 내비게이션만 있거나, 로그인 페이지가 반환되었다면 읽기 단계는 아직 완료되지 않은 것입니다.

도구를 바꿔 가며 접근 제한을 우회해서는 안 됩니다. 로그인 요청, 명시적인 접근 거부, 불분명한 권한 범위를 만나면 작업을 멈추고 먼저 승인된 경로를 확인하십시오. 일시적인 페이지 실패는 재시도 조건을 남겨 둘 수 있지만, 권한이 없는 대상이라면 도구를 바꿔 권한을 억지로 얻으려 하지 말고 범위 자체를 조정해야 합니다.

무료 명령 하나로 필수 파라미터 확인하기

아래 명령은 검색을 실행하거나 대상 콘텐츠를 다운로드하지 않으며, API 키 없이 공개 도구 카탈로그만 읽습니다. 터미널에 curl과 jq가 설치되어 있어야 합니다. pipefail을 켜 두면 요청 오류가 뒤이은 처리 과정에 가려지지 않습니다.

set -o pipefail
curl -fsS --max-time 20 \
  'https://api.everyinfra.com/api/v1/search/tools' \
  | jq -e '
      [.tools[] |
       select(.tool == "web" or .tool == "read" or .tool == "crosscheck") |
       {tool, required_params, optional_params}]
      | if length == 3 then . else error("selected tool missing") end'

이번 확인에서 web과 crosscheck는 q가, read는 url이 필수였습니다. crosscheck의 선택 파라미터로는 num, since, read_top, depth, mechanisms가 있으며, read에는 선택 파라미터가 없습니다. 모든 도구에 같은 시간·수량 필드를 무작정 전달하지 마십시오. 공개 검색 카탈로그

같은 카탈로그에는 도구 17개가 나열되어 있습니다. 이 숫자는 조회한 목록의 길이일 뿐이며, 17개 항목에 대한 비즈니스 검증도 아니고 글 제목에 걸 수 있는 장기적인 약속도 아닙니다. 카탈로그 선언은 요청 방법을 알려 주지만 전체 콘텐츠, 결과 수, 과금 상태를 보장하지는 않습니다.

crosscheck는 사실을 판정하지 않고 근거 간의 관계를 찾도록 돕습니다

답변이 문서, 코드, 외부 약속에 반영될 경우 crosscheck를 교차 검증의 진입점으로 사용할 수 있습니다. 이 도구의 목적은 편집자가 핵심 원문을 읽기 전에 서로 다른 검색 메커니즘이 어떻게 출처를 찾아내는지 관찰하게 하는 것입니다. 메커니즘별 적중 수를 보정되지 않은 확률 점수로 바꿔서는 안 됩니다.

같은 공지를 세 개의 검색 경로에서 찾았더라도 원본 근거는 여전히 하나뿐입니다. 여러 도메인이 같은 뉴스를 다시 게재했다고 해서 독립적인 관찰이 여러 건 생기지는 않습니다. 최종 URL, 원 게시자, 인용 관계, 버전, 타임스탬프를 평가해 각 출처가 독립적으로 뒷받침하는 근거인지, 같은 내용을 반복해 바꿔 쓴 것인지 판단해야 합니다.

이 과정에 검증되지 않은 고정 임계값을 적용하지 마십시오. 예를 들어 어떤 숫자가 세 도메인에 나타나면 AI 인용 가중치가 두 배가 된다고 가정해서는 안 됩니다. AI Overviews 및 AI 모드에 관한 Google 공식 문서를 보면, 공개된 권장 사항은 기본적인 SEO, 발견 가능한 내부 링크, 유용한 콘텐츠에 초점을 맞출 뿐 여러 도메인에 따른 배수 규칙을 규정하지 않습니다. 또한 이 문서가 모든 RAG 시스템을 대표하지도 않습니다. 같은 팀이 회사 사이트, LinkedIn, Medium에 게시한 숫자는 독자가 원 출처를 찾는 데 도움이 되지만, 근거 카드에서는 별개의 표 세 개로 세지 말고 하나의 원본 관찰로 거슬러 올라가야 합니다.

출처가 서로 충돌하면 충돌의 종류를 나눠 살펴보십시오. 이전 문서와 새 문서가 다르면 버전 변경을 먼저 확인합니다. 공식 설명과 런타임 실패가 다르면 시나리오와 재현의 빈틈을 그대로 남겨 둡니다. 2차 사이트와 1차 출처가 다르면 원 출처의 해당 단락으로 돌아갑니다. 다수결로 답을 하나로 정하거나, 도구가 생성한 요약을 유일한 근거로 삼아서는 안 됩니다.

모든 결론마다 근거 카드 남기기

비즈니스 시스템에서는 다음 필드를 관리할 것을 권장합니다. 이는 기록 방식에 대한 제안이며, API 응답 구조를 설명하는 것은 아닙니다:

• claim: 필요한 최소한의 주장과 적용되는 제품, 버전, 지역.
• source_url 및 final_url: 리디렉션이나 중복 출처를 식별하기 위한 원래 진입점과 최종 도착 페이지.
• observed_at: 읽은 시각. 페이지에 표시된 published_at, updated_at과 구분해 보관합니다.
• evidence_locator: 홈페이지만이 아니라 특정 섹션, 단락, 샘플을 가리키는 위치 정보.
• support_status: 뒷받침, 상충, 무관, 읽기 불가, 검증 대기를 구분하는 권장 분류.
• limits: 원문에 나온 적용 범위 제한, 예외, 근거 공백, 재평가 조건.

근거 카드의 목적은 서류 작업을 늘리는 것이 아니라, 다른 검토자가 같은 링크로 같은 사안을 판단할 수 있게 하는 데 있습니다. "A 웹사이트에서 그렇다고 함"만 저장하면 재검증할 수 없고, 출처의 조건을 빠뜨리면 링크를 더 추가해도 결론을 바로잡을 수 없습니다.

가격, 버전, 기능 목록처럼 자주 바뀌는 정보는 재평가 일정을 정하고, 게시 전에 실제 인용을 다시 확인하십시오. 페이지가 살아 있다고 해서 내용이 그대로라는 보장은 없고, 링크가 작동한다고 해서 원래 주장이 여전히 유효하다는 보장도 없습니다. 결론을 수정할 때는 이전 관찰 날짜를 오늘로 바꾸지 말고 원래 근거를 보존하십시오.

여러 단계에 걸친 추적이 필요하다면 엔터티, 활동, 파생 관계에 관한 W3C PROV 권고안을 참고해 출처 버전, 읽기 로그, 답변을 연결하십시오. 이렇게 하면 결론이 어디에서 왔는지 설명하기 쉬워지지만, 출처의 독립성이나 내용의 정확성이 자동으로 판정되지는 않습니다.

성공, 빈 결과, 읽기 불가 상태 구분하기

2026년 9월 2일의 비식별 처리된 비즈니스 샘플에서 web은 결과 3건을 반환했고, crosscheck의 한 사례는 메커니즘 4개에 대한 레코드를 반환했습니다. 같은 회차에는 read가 지정 문서를 읽지 못한 샘플, HTTP 503이 발생한 샘플, scholar 요청은 성공했지만 결과가 비어 있던 샘플도 있었습니다. 이는 특정 과거 입력에 대한 결과이며, 모든 호출의 동작을 보장하지 않습니다.

2026년 9월 4일의 재확인은 도구 카탈로그만 대상으로 했으며 인증 워크플로는 다시 실행하지 않았습니다. 따라서 이 글은 "read가 현재 실패한다"고도, "read가 복구되었다"고도 주장하지 않습니다. 연동 검수에서는 전체 콘텐츠 조회, 실패 상태 보존, 인용 뒷받침을 각각 독립적으로 확인해야 하며, 오래된 샘플이 현재 결과를 대신할 수 없습니다.

에이전트는 결과가 비었을 때 쿼리 조건과 기간을 보존하고, "사실이 존재하지 않음"이 아니라 "이번 회차에는 결과 없음"으로 출력해야 합니다. 읽을 수 없을 때는 찾은 URL과 실패 상태를 보존하고, 스니펫을 전체 콘텐츠처럼 꾸며서는 안 됩니다. 타임아웃으로 요청 결과를 알 수 없을 때는 작업이 실행되지 않았다거나 계정에 변화가 없다고 섣불리 결론 내리지 마십시오.

재시도에는 횟수와 트리거 조건에 대한 제한이 필요합니다. 권한 실패는 권한 문제를 해결하고, 파라미터 오류는 입력을 수정하며, 일시적이고 재시도 가능한 실패는 인터페이스 규약에 따라 처리하십시오. 그래도 근거를 얻을 수 없다면 에이전트를 무한 루프에 가두거나 읽지 않은 내용을 지어내지 말고, 공백을 남긴 채 해당 항목을 마무리하십시오.

인용 검증과 보안 검사는 하나의 전달 과정에서 함께 이루어집니다

검색 콘텐츠는 검증할 데이터이지 새로운 작업 지시가 아닙니다. 웹 페이지가 로컬 파일 업로드, API 키 붙여넣기, 보안 검사 비활성화, 낯선 주소로의 전송을 요구하더라도 검색 결과에서 나온 텍스트라는 이유만으로 실행해서는 안 됩니다. 페이지 콘텐츠를 시스템 지시, 자격 증명, 사용자 승인과 분리하고, 도구는 현재 문제에 필요한 데이터만 가져와야 합니다.

답변을 완성한 뒤에는 인용을 한 줄씩 검증하십시오. 링크가 인접한 주장을 뒷받침하는지, 제한 조건이 보존되었는지, 날짜가 관찰 시점과 일치하는지, 1차 출처가 중복으로 계산되지 않았는지 확인해야 합니다. 참고 목록이 비어 있지 않다는 것만으로는 충분하지 않습니다. 특히 "연결 가능"을 "완전히 구현됨"으로, "필드 지원"을 "모든 필드 반환"으로 바꿔 쓸 때, 원래 의미가 넓어졌다는 사실을 인용이 알려 주는 경우는 거의 없습니다.

워크플로는 직접 준비한 테스트 자료로 점검할 수 있습니다. 1차 출처 하나와 재게재본 두 개, 같은 페이지의 이전 버전과 새 버전, 제목만 담긴 읽기 결과, 콘텐츠에 삽입된 악의적인 작업 지시가 그 예입니다. 각각의 기대 동작은 중복 근거 제거, 버전 표기, 읽기를 미완료로 유지, 페이지 지시 거부입니다. 이는 권장하는 검수 세트이며, 이번 주기에 실제로 실행한 제품 테스트는 아닙니다.

웹 페이지 텍스트에 담긴 악의적인 지시는 OWASP가 설명하는 간접 프롬프트 인젝션 위험에 해당합니다. 최소 권한과 도구 호출 검증 원칙에 따라, 읽기 도구가 페이지 텍스트 때문에 파일 업로드나 계정 수정 기능을 얻어서는 안 되며, 위험도가 높은 액션은 별도의 승인 단계로 통제해야 합니다.

검증 가능한 질문 하나로 연동 시작하기

첫 회차에는 공개되어 있고 위험이 낮으며 승인 범위가 명확한 질문 하나를 고르고, 기대하는 1차 출처를 미리 정해 두십시오. 탐색 결과, 콘텐츠, 결론, 인용을 단계별로 기록하고, 빠진 논리가 없는지 사람이 확인하게 하십시오. 이 근거 체인 하나를 검증한 뒤에 질문 유형과 도구 범위를 넓히십시오.

EveryInfra의 공개 카탈로그로 도구와 입력을 먼저 확인할 수 있지만, 실제 비즈니스 호출, 실패 처리, 결과물 품질은 직접 승인받은 샘플로 검증해야 합니다. 이 글의 완료 기준은 "모든 도구를 호출했다"가 아닙니다. 어떤 진술에 1차 근거가 있고, 어떤 진술이 아직 불확실하며, 다음에 어떤 근거가 필요한지 독자가 짚어 낼 수 있는지가 기준입니다. API 문서 보기