Gemini Parallel Web Search grounding 설계법: 엔터프라이즈 에이전트에 실시간 출처 붙이기

Google Cloud가 Gemini Enterprise Agent Platform에 Parallel Web Search를 grounding provider로 추가했다. 개발자는 Gemini API, Agent Studio, Google Cloud Marketplace를 통해 Parallel의 웹 검색 인프라를 에이전트 grounding 소스로 쓸 수 있다. Google은 KYC, 카탈로그 보강, 실시간 뉴스 분석, 기업 실사 같은 엔터프라이즈 워크플로우를 예시로 들었다.

이 글의 검색 키워드는 “Gemini Parallel Web Search grounding”이다. 목적은 뉴스 요약이 아니라 설계 가이드다. 실시간 웹 정보를 쓰는 에이전트를 만들 때 검색 결과를 어떻게 넣고, 출처를 어떻게 남기고, 캐시와 보안 경계를 어떻게 잡을지 정리한다.

출처: Google Developers Blog, Expanding Choice in Gemini Enterprise Agent Platform: Introducing Grounding with Parallel Web Search(2026-07-16).

왜 grounding이 다시 중요해졌나

초기 RAG는 내부 문서 검색이 중심이었다. 사내 정책, 매뉴얼, 계약서, FAQ를 벡터 DB에 넣고 모델이 답하게 했다. 하지만 기업용 에이전트가 실제 업무를 처리하려면 내부 문서만으로 부족하다.

예를 들어 공급사 리스크 점검은 최신 제재 목록, 뉴스, 기업 사이트, 공시 자료가 필요하다. KYC 자동화는 회사명, 주소, 대표자, 관련 사건을 외부 웹에서 확인해야 한다. 상품 카탈로그 보강은 제조사 사이트와 유통사 정보를 대조해야 한다.

이런 작업에서 모델이 “알고 있는 듯한 답”을 내면 위험하다. 필요한 건 답변보다 근거다. 어떤 출처에서 언제 가져왔고, 어떤 필드를 업데이트했는지 남겨야 한다.

Parallel Web Search 통합의 실무 의미

Google 설명에 따르면 Parallel Web Search는 Gemini 모델을 고품질 실시간 웹 결과에 연결하고, 원본 출처에 대한 citation을 제공한다. 또한 Agent Platform 안에서 호출 가능하고, Agent Studio에서 선택 가능하며, Marketplace 구독과 Google Cloud 청구로 묶인다.

개발자 관점에서 의미 있는 지점은 세 가지다.

첫째, grounding provider 선택지가 늘었다. 모든 팀이 같은 웹 검색 API를 쓰지 않아도 된다. 둘째, 결과를 다른 LLM이나 후처리 파이프라인에 넘길 수 있는 아키텍처 유연성이 있다. 셋째, 민감한 워크로드를 위한 zero data retention 옵션이 언급됐다.

즉, 단순 “검색 붙은 챗봇”보다 운영형 에이전트에 가깝다.

기본 아키텍처: 검색, 근거, 후처리를 분리하라

실시간 grounding 에이전트는 다음 단계를 분리하는 게 좋다.

1. Query planning: 사용자 요청을 검색 가능한 하위 질문으로 쪼갠다.
2. Web grounding: Parallel Web Search로 웹 결과와 citation을 가져온다.
3. Evidence filtering: 출처 신뢰도, 날짜, 중복, 도메인 정책을 검사한다.
4. Synthesis: Gemini가 근거 기반 답변을 만든다.
5. Action proposal: DB 업데이트, 리포트 생성, 티켓 생성 같은 후속 액션을 제안한다.
6. Audit logging: 사용한 query, 출처 URL, timestamp, 모델 응답을 저장한다.

여기서 검색 결과를 곧바로 최종 답변에 넣는 방식은 위험하다. 웹에는 오래된 문서, SEO 스팸, 복제 콘텐츠가 섞여 있다. 반드시 evidence filtering 레이어가 있어야 한다.

출처 품질을 점수화하는 간단한 방법

처음부터 복잡한 랭킹 모델을 만들 필요는 없다. 다음 기준으로 출처 점수를 계산해도 운영 품질이 올라간다.

에이전트는 최종 답변에 “확인됨”, “추정”, “출처 부족” 같은 신뢰 등급을 붙일 수 있다. 기업 실사나 리스크 분석에서는 이 구분이 답 자체보다 중요하다.

캐싱은 비용 절감이지만, 진실의 복사본이 될 수 있다

Google 글은 Parallel Web Search 결과를 추출하고 영구 캐시해 내부 데이터셋을 보강하는 사용 사례를 언급한다. 이건 카탈로그 보강에는 좋다. 예를 들어 제품 규격, 제조사 주소, 공급사 연락처를 자동 보완할 수 있다.

다만 캐시는 항상 만료 정책이 필요하다. 웹 데이터는 바뀐다. 특히 가격, 재고, 법적 상태, 제재 목록, 인사 정보는 오래된 캐시가 잘못된 의사결정을 만든다.

권장 TTL은 데이터 성격별로 나누자.

• 뉴스, 리스크 이벤트: 1~24시간.
• 가격, 재고, 채용 정보: 6~24시간.
• 회사 기본 정보: 7~30일.
• 기술 문서 버전 정보: 릴리스 감지 기반 갱신.
• 법규, 제재, 컴플라이언스: 짧은 TTL + 원본 재확인.

캐시에는 원문 URL, 수집 시각, 검색어, parser 버전, confidence score를 함께 저장해야 한다.

멀티 에이전트 오케스트레이션에서 쓰는 방법

Parallel Web Search의 장점 중 하나는 검색 결과를 다른 모델이나 서브 에이전트에 넘길 수 있다는 점이다. 이 구조는 멀티 에이전트 시스템에 잘 맞는다.

예를 들어 기업 실사 에이전트를 만든다면 이렇게 나눌 수 있다.

• 검색 에이전트: 회사명, 임원, 제품명, 리스크 키워드로 검색한다.
• 검증 에이전트: 출처 신뢰도와 날짜를 평가한다.
• 요약 에이전트: 확인된 사실만 보고서로 만든다.
• 정책 에이전트: 내부 기준에 따라 위험 등급을 매긴다.
• 액션 에이전트: 승인 후 CRM이나 티켓 시스템을 업데이트한다.

검색과 판단을 한 모델에 몰아넣으면 디버깅이 어렵다. 검색 결과가 나빴는지, 출처 필터가 약했는지, 모델 요약이 틀렸는지 분리해서 봐야 한다.

실행 체크리스트

• 사용자 요청을 바로 검색하지 말고 query planning 단계를 둔다.
• 모든 답변에 사용한 URL과 수집 시각을 저장한다.
• 공식 출처, 최근성, 중복 검증 기준으로 evidence score를 계산한다.
• 캐시 TTL을 데이터 유형별로 다르게 둔다.
• 민감 워크로드는 ZDR 옵션과 내부 로그 정책을 함께 검토한다.
• 검색 에이전트와 판단 에이전트를 분리해 장애 원인을 추적 가능하게 만든다.
• DB 자동 업데이트는 confidence threshold와 사람 승인 조건을 둔다.

Gemini Parallel Web Search grounding은 “검색 API 하나 추가”가 아니다. 실시간 웹을 쓰는 에이전트의 운영 기준을 정하는 기능이다. 출처, 캐시, 감사 로그를 같이 설계해야 프로토타입이 production agent가 된다.