이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
LLM의 지식 cutoff를 보완하는 웹 검색에서는 검색 엔진보다 모델과 검색 예산의 조합이 품질·비용·속도를 크게 좌우한다. OpenRouter의 네 가지 벤치마크에서 1턴을 25턴으로 늘리면 BrowseComp 점수가 대략 두 배까지 오를 수 있지만 비용도 2.5~7배 증가하며, 쉬운 문제나 실패가 잦은 업무에서는 추가 검색이 비용만 키울 수 있다. 25턴 BrowseComp에서 엔진 변경에 따른 평균 점수 차이는 10점, frontier model과 비용 효율형 모델의 평균 격차는 15점이었다. 따라서 작업과 가까운 벤치마크에서 저렴한 상위 구성을 고른 뒤 자체 평가 세트로 재검증하는 방식이 적합하다.
섹션별 상세
웹 검색은 LLM의 지식 cutoff를 보완하는 기본 기능이지만, native search와 제3자 엔진 중 무엇을 쓸지, 몇 차례 검색을 허용할지, 검색 결과를 언제 모델에 전달할지를 함께 정해야 한다. OpenRouter는 모델, 엔진, 검색 방식, 검색 예산이라는 네 가지 요청 변수를 조합해 Exa·Parallel·Perplexity와 OpenAI·Anthropic·Google의 native engine을 비교한다. 검색 결과를 먼저 받아 문맥으로 넣는 방식과 모델이 필요할 때 도구를 호출하는 방식이 구분되며, 후자에서는 1·5·25턴 예산을 적용한다. BrowseComp, DeepSearchQA, WideSearch, HLE의 네 벤치마크가 품질·비용·속도별 live leaderboard를 구성하므로 특정 시점의 순위보다 작업에 맞는 조합을 찾는 기준으로 활용된다.
검색 예산을 1턴에서 25턴으로 늘리는 변화가 엔진을 바꾸거나 모델을 교체하는 것보다 품질을 크게 높이는 경우가 많다. Perplexity의 BrowseComp 초기 실행에서 Claude Opus 5는 35.8%에서 66.5%, 다시 89.0%로 올랐고 비용은 질문당 $0.14에서 $0.51, $0.99로 증가했다. GPT-5.6 Sol은 46.3%에서 65.2%, 82.4%로 변했고 GPT-5.6 Luna는 33.7%에서 57.0%, 74.0%로 변해 검색 깊이의 효과가 여러 모델에서 반복됐다. 1턴에서 25턴으로 늘리면 비용은 2.5~7배가량 증가하지만 점수는 대략 두 배가 될 수 있어, 단순히 엔진을 교체하기 전에 검색 라운드 상한을 조정하는 편이 효율적인 선택이 된다.
검색 깊이가 항상 응답 시간을 늘리거나 품질을 높이는 것은 아니다. GPT-5.6 Luna는 Perplexity에서 1턴일 때 질문당 140초, 25턴일 때 111초를 기록했고, 1턴과 5턴을 모두 실행한 35개 구성 중 3분의 1 이상은 오히려 적은 턴에서 더 느렸다. 반대로 HLE의 GPT-5.6 Sol과 Perplexity 조합은 1턴과 25턴의 점수가 비슷한데 비용만 세 배가 됐다. 따라서 쉬운 질문이 많은 업무에는 작은 예산이 적합하고, 여러 단계의 사실 확인이 필요한 업무에는 더 깊은 검색이 품질 개선으로 이어질 가능성이 크다.
모델이 정답을 찾지 못하는 경우에는 늘어난 검색 예산이 실패를 줄이지 못한 채 비용만 키울 수 있다. 25턴 설정에서 정답일 때와 오답일 때의 평균 검색 횟수는 BrowseComp 10.3회와 19.7회, DeepSearchQA 11.7회와 20.1회, HLE 5.2회와 7.5회, WideSearch 17.6회와 23.4회였다. WideSearch에서는 한 표를 완성하려고 81회 검색한 시도도 오답으로 판정됐다. 실패율이 높은 업무라면 모델이 답을 찾지 못할 때 검색을 계속하지 않도록 예산을 낮추는 것이 최악의 비용을 줄이는 방법이 된다.
검색 엔진의 차이보다 모델 선택의 영향이 더 크게 나타났다. BrowseComp 25턴 결과에서 Claude Opus 5는 Perplexity 89.0%($0.99), Exa 82.2%($1.29), Parallel 88.8%($2.42)를 기록했고, GPT-5.6 Luna는 각각 74.0%($0.10), 68.4%($0.14), 58.0%($0.11)를 기록했다. 같은 모델에서 엔진을 바꿀 때 점수 차이는 평균 10점이었지만, frontier model과 비용 효율형 모델 사이의 평균 격차는 15점이었다. 엔진 비용은 frontier model에서 가장 크게 벌어져 가장 비싼 선택지가 가장 싼 선택지보다 2.5배 비쌌고, 비용 효율형 모델에서는 그 차이가 1.5배였다.
벤치마크 순위는 실제 업무의 정답률과 비용을 대신하지 않으므로, 상위 구성을 후보군으로 좁힌 뒤 자체 질문 세트로 재검증해야 한다. 빠르고 저렴한 최신 사실 확인에는 모델 작성 전에 한 번 검색하는 Web plugin이 맞고, 여러 단계를 거쳐 답을 찾아야 하는 작업에는 모델이 후속 검색을 결정하는 Server tool이 맞다. OpenRouter에서는 engine을 exa, parallel, perplexity, native로 지정하거나 auto로 설정할 수 있으며, max_tool_calls가 검색 라운드 수를 제한하고 max_results가 회당 결과 수를 정한다. 작업과 가장 가까운 벤치마크에서 최고 점수보다 몇 점 낮더라도 가장 저렴한 구성을 먼저 고른 다음, 바로 위 두세 구성과 자체 평가 결과를 비교하는 절차가 권장된다.
용어 해설
- 검색 예산(Search Budget)
- — 모델이 웹 검색을 수행할 수 있는 최대 횟수다. 검색 도구를 호출할 때마다 한 턴으로 계산하며, 예산이 크면 결과가 부족할 때 질의를 바꾸거나 후속 검색을 수행할 여지가 커진다. 품질과 비용을 함께 결정하는 핵심 설정이다.
- BrowseComp
- — 실제 웹 탐색이 필요한 어려운 사실 확인 과제로 검색 성능을 측정하는 벤치마크다. 모델이 검색 결과를 바탕으로 정답을 찾아야 하며, 글에서는 여러 모델·검색 엔진·검색 예산 조합의 품질과 비용을 비교하는 기준으로 사용됐다.
- DeepSearchQA
- — 여러 단계의 검색과 추론이 필요한 연구형 질문으로 웹 검색 시스템을 평가하는 벤치마크다. 단일 검색 결과만으로 답하기 어려운 질문을 사용해 검색 깊이가 정답률과 비용에 미치는 영향을 측정한다.
- WideSearch
- — 넓은 범위의 정보를 수집해 표 전체를 채우는 유형의 검색 과제다. 많은 항목을 찾아야 하므로 검색 횟수가 크게 늘어날 수 있으며, 글에서는 정답 여부에 따른 평균 검색 횟수와 최대 81회 검색 사례가 제시됐다.
- Server tool
- — 모델이 필요할 때 웹 검색 도구를 직접 호출하도록 하는 OpenRouter 기능이다. 모델은 검색 결과를 읽고 질의를 수정하거나 후속 검색을 이어갈 수 있으며, max_tool_calls로 검색 라운드 상한을 정하고 max_results로 회당 결과 수를 조절한다.
기술
- OpenRouter API
- Exa
- Parallel
- Perplexity
- OpenAI native search
- Anthropic native search
- Google native search
- Web plugin
- Server tool
활용 사례
- 최신 사실 확인
- 다단계 연구 질문
- 대규모 표 정보 수집
- 전문가 시험형 질문 응답
- 웹 검색 기반 LLM 에이전트 구성
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 08. 15.수집 2026. 08. 15.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
