Gemini Parallel Web Search 적용법: 에이전트 답변에 출처와 캐시 정책 붙이기

요약: Gemini Enterprise Agent Platform에 Parallel Web Search grounding이 추가되면서, 에이전트가 실시간 웹 정보를 사용할 때 선택할 수 있는 구조가 넓어졌습니다. 실무에서는 “검색 붙였다”로 끝내면 안 됩니다. 출처, 캐시, 재사용, 비용, 데이터 보존 정책을 함께 설계해야 합니다. 핵심 키워드는 Gemini Parallel Web Search, 에이전트 grounding, 실시간 웹 검색, citation입니다.

독자의 문제: 에이전트는 자신 있게 틀린다

운영 중인 AI 에이전트에서 가장 위험한 답변은 모른다고 말하는 답변이 아닙니다. 오래된 정보로 그럴듯하게 답하는 답변입니다. 가격, 정책, 회사 정보, 법인 등기, 제품 카탈로그, 채용 공고, 경쟁사 업데이트처럼 시간이 중요한 정보는 모델 파라미터 안에만 의존하면 바로 낡습니다.

그래서 retrieval augmented generation, 즉 RAG를 붙입니다. 내부 문서에는 vector DB를 붙이고, 외부 최신 정보에는 웹 검색을 붙입니다. 문제는 웹 검색 결과를 LLM에게 던지는 것만으로 production-grade grounding이 되지 않는다는 점입니다. 출처가 부정확하거나, 결과를 캐시할 수 없거나, 검색 비용이 폭증하거나, 민감한 질의가 외부 provider로 나가면 운영 리스크가 커집니다.

Google과 Parallel Web Systems의 통합은 이 문제를 정면으로 다룹니다. Parallel Web Search는 agentic workload에 맞춘 검색 인프라를 제공하고, Gemini는 질의를 분해하고 결과를 종합해 citation annotation을 붙입니다.

원인: 검색은 기능이 아니라 데이터 파이프라인이다

많은 팀이 웹 검색을 tool calling 하나로 봅니다. 하지만 실제로는 데이터 파이프라인입니다. 사용자의 질문이 들어오고, 에이전트가 어떤 query를 만들지 정하고, 검색 provider가 결과를 반환하고, 모델이 요약하고, 출처를 붙이고, 일부 결과는 내부 DB에 저장되거나 후속 agent로 넘어갑니다.

이 흐름에서 결정해야 할 항목이 많습니다.

• 어떤 질의는 검색하고 어떤 질의는 검색하지 않을 것인가?
• 검색 결과 원문을 저장할 것인가, citation URL만 저장할 것인가?
• 같은 회사나 제품에 대한 결과를 얼마나 오래 캐시할 것인가?
• 사용자의 개인정보가 들어간 질의를 외부 검색으로 보낼 수 있는가?
• 최종 답변에서 출처 없는 문장을 허용할 것인가?
• 검색 결과를 다른 LLM이나 sub-agent에게 넘겨도 되는가?

Parallel 통합이 흥미로운 이유는 프로그램 호출, 검색 데이터 추출과 캐싱, 다른 LLM으로의 post-processing 같은 복잡한 아키텍처를 전제로 설명한다는 점입니다. 즉 “챗봇에 웹 검색 버튼 추가”가 아니라 “에이전트용 검색 계층”입니다.

해결 구조: grounding policy를 먼저 쓴다

도입 순서는 API 연결이 아니라 policy 작성부터입니다. 가장 먼저 에이전트가 검색을 써야 하는 상황과 쓰면 안 되는 상황을 문서화합니다.

예를 들어 기업 실사 에이전트라면 회사명, 대표자, 최근 뉴스, 제재 이력은 검색 대상입니다. 반대로 사용자가 입력한 주민등록번호, 계좌번호, 내부 계약서 원문은 외부 검색 질의에 포함되면 안 됩니다. 제품 카탈로그 enrichment 에이전트라면 공개 웹의 스펙 정보는 검색할 수 있지만, 내부 매입가나 계약 조건은 검색 context에 섞으면 안 됩니다.

다음으로 citation requirement를 정합니다. “최신 정보”를 주장하는 문장에는 원본 URL을 붙이고, citation이 없는 경우에는 불확실성을 드러내도록 합니다. 답변 품질 평가는 단순 정확도만 보지 말고 “주요 주장에 출처가 붙었는가”, “출처가 원문과 일치하는가”, “검색 결과와 모델 추론을 구분했는가”를 함께 봐야 합니다.

캐시 설계가 비용과 신뢰도를 결정한다

웹 grounding은 비용이 search call 수에 민감합니다. 모든 질문마다 실시간 검색을 하면 비용도 늘고 응답 시간도 늘어납니다. 반대로 과도하게 캐시하면 최신성이 떨어집니다.

실무에서는 데이터 유형별 TTL을 나눕니다.

• 주가, 뉴스, 장애 상태: 수분~수시간
• 채용 공고, 제품 가격, SaaS 약관: 하루~일주일
• 회사 기본 정보, 공개 주소, 창업자 프로필: 수주~수개월
• 법률·규제 해석: 원문은 캐시하되 최신 개정 여부를 재확인

또한 캐시에는 “검색 query”, “검색 시각”, “provider”, “원본 URL”, “요약문”, “사용된 답변 ID”를 함께 저장해야 합니다. 나중에 사용자가 이 답변이 왜 나왔는지 묻거나, 법무·보안 검토가 필요할 때 근거를 따라갈 수 있어야 합니다.

적용 예시: 카탈로그 enrichment 에이전트

전자상거래 팀이 내부 상품 DB에 빠진 속성을 채우는 에이전트를 만든다고 가정해봅시다. 사용자는 SKU 목록을 넣고, 에이전트는 제조사 공식 페이지와 유통사 페이지를 찾아 크기, 무게, 호환 모델, 출시일을 채웁니다.

이때 Parallel Web Search를 붙인 Gemini 에이전트는 단순 요약보다 검증 흐름이 중요합니다. 제조사 공식 페이지를 우선하고, 블로그나 포럼은 보조 근거로만 씁니다. 서로 다른 출처의 스펙이 충돌하면 자동 저장하지 않고 review queue로 보냅니다. 저장할 때는 값만 넣지 말고 근거 URL과 수집 시각을 같이 남깁니다.

이 구조를 만들면 LLM은 “텍스트를 잘 쓰는 모델”이 아니라 “출처 있는 데이터 보강 작업자”가 됩니다. 검색 grounding의 ROI는 여기서 나옵니다.

실행 체크리스트

• 검색을 허용할 use case와 금지할 use case를 policy로 분리합니다.
• 사용자 입력에서 개인정보·내부 비밀이 query로 나가지 않도록 redaction 단계를 둡니다.
• 주요 주장에는 citation을 요구하고, citation 없는 최신 정보 주장은 낮은 신뢰도로 표시합니다.
• 데이터 유형별 캐시 TTL을 정하고, 검색 시각과 provider를 저장합니다.
• 충돌하는 출처가 있을 때 자동 결론을 내리지 말고 review queue로 보냅니다.
• 검색 결과를 다른 LLM이나 sub-agent로 넘길 때 데이터 보존 정책을 다시 확인합니다.
• 비용 알림은 검색 call 수, 평균 결과 수, cache hit rate 기준으로 잡습니다.

출처: Google Developers Blog, “Introducing Grounding with Parallel Web Search”, 2026-07-16.