Gemini Enterprise Parallel Web Search: 실시간 그라운딩이 엔터프라이즈 에이전트 설계를 바꾸는 이유

요약: Google Cloud가 Gemini Enterprise Agent Platform에 Parallel Web Search를 그라운딩 공급자로 통합했다. 핵심은 “검색 결과를 붙인 챗봇”이 아니라, 엔터프라이즈 에이전트가 실시간 웹 데이터를 인용·저장·후처리할 수 있는 운영 선택지가 늘었다는 점이다.

2026년 7월 16일 Google Developers Blog는 Parallel Web Systems가 Gemini Enterprise Agent Platform의 네이티브 웹 그라운딩 제공자로 들어왔다고 발표했다. Parallel Web Search는 Gemini 모델 응답을 실시간 공개 웹 데이터에 연결하고, 원본 출처에 대한 citation annotation을 제공하는 방식이다. Google 설명에 따르면 이 기능은 Gemini API에서 호출할 수 있고, Agent Studio에서 선택할 수 있으며, Google Cloud Marketplace 구독과 기존 Google Cloud 청구서 기반 과금도 지원한다.

실무 개발자 입장에서 이 소식이 중요한 이유는 단순하다. 프로덕션 에이전트의 가장 큰 장애물은 모델 성능보다 “답변 근거를 운영자가 신뢰할 수 있느냐”다. 내부 문서만 보는 RAG는 최신 시장 정보, 외부 회사 정보, 규제 공지, 제품 가격, 공개 레퍼런스 변화에 약하다. 반대로 무제한 웹 검색을 붙이면 출처 품질, 비용, 캐싱 정책, 개인정보, 감사 로그 문제가 생긴다. 이번 통합은 이 중간 지점, 즉 기업 환경에서 통제 가능한 라이브 웹 그라운딩 레이어를 제공한다.

무엇이 바뀌었나

이번 변화의 핵심은 Gemini Enterprise Agent Platform에서 Parallel Web Search를 네이티브 옵션으로 선택할 수 있다는 점이다. Google은 이 기능을 “Grounding with Parallel Web Search”라고 설명한다. 모델이 복잡한 사용자 프롬프트를 이해하고 분해한 뒤, Parallel의 웹 인덱스에서 관련 결과를 가져오고, 그 결과를 기반으로 답변과 정확한 인용을 만든다는 구조다.

여기서 중요한 표현은 “native integration”이다. 개발자가 별도 검색 API를 붙이고, 결과 스키마를 맞추고, citation 포맷을 직접 만들고, 결제·권한·로그를 따로 관리하는 방식과 다르다. Agent Platform 안에서 구독, 선택, 호출, 과금이 이어진다. 특히 Google Cloud Marketplace를 통한 구독과 기존 청구서 통합은 엔터프라이즈 구매·보안 심사에서 체감 차이가 크다.

또 하나 눈에 띄는 부분은 zero data retention 옵션이다. 민감한 워크로드에서 웹 그라운딩을 쓰려면 검색 질보다 데이터 보존 정책이 먼저 걸린다. 고객사 이름, 조사 대상, 내부 의사결정 맥락이 외부 서비스에 오래 남으면 보안 검토에서 막힌다. ZDR 옵션은 이런 조직에서 PoC를 실제 배포로 옮길 때 필요한 조건에 가깝다.

왜 기존 RAG만으로는 부족한가

많은 팀이 “우리는 사내 문서 RAG가 있으니 웹 검색은 필요 없다”고 생각한다. 그러나 에이전트가 맡는 업무가 KYC, 공급사 검증, 뉴스 모니터링, 카탈로그 보강, 경쟁사 조사처럼 바뀌면 내부 문서만으로는 빈칸이 생긴다. 내부 지식은 정확하지만 느리고, 외부 웹은 빠르지만 노이즈가 많다. 프로덕션 에이전트는 둘을 분리해서 다뤄야 한다.

예를 들어 공급사 리스크 점검 에이전트를 만든다고 하자. 내부 DB에는 계약서, 거래 이력, 담당자 메모가 있다. 하지만 최근 제재 뉴스, 법원 공시, 보안 사고, 가격 정책 변경은 내부 DB에 바로 들어오지 않는다. 이때 에이전트가 최신 웹 데이터를 확인하고, 원본 URL을 citation으로 남기고, 필요한 속성만 구조화해 내부 시스템에 저장할 수 있으면 업무 가치가 달라진다.

반대로 웹 데이터를 무작정 매번 검색하면 비용과 지연 시간이 늘어난다. 그래서 Google 발표에서 “extract and cache web data”, “post-process search results using other LLMs” 같은 표현이 중요하다. 한 번 찾은 공개 데이터를 프로그램적으로 추출해 내부 데이터셋에 보강하고, 필요하면 다른 LLM으로 후처리하는 아키텍처를 허용한다는 뜻이다.

적용하기 좋은 업무와 피해야 할 업무

Parallel Web Search 기반 Gemini 그라운딩은 “최신성 + 출처 검증 + 반복 조회”가 필요한 업무에 맞다. 제품 카탈로그 속성 보강, 벤더 연락처 업데이트, 글로벌 규제 체크, 기업 실사, 뉴스 기반 투자 리서치, 경쟁사 기능 모니터링이 대표적이다. 이런 업무는 사람이 매번 검색해도 결국 표 형태로 정리하고, 출처를 붙이고, 내부 시스템에 옮긴다. 에이전트가 이 흐름을 맡기 좋다.

반면 검색 결과가 조금만 틀려도 즉시 법적 책임이 생기는 최종 판단 업무에는 바로 붙이면 안 된다. 신용 승인, 의료 조언, 법률 결론, 제재 대상 확정 같은 영역은 웹 그라운딩을 “판단 엔진”이 아니라 “증거 수집 보조”로 둬야 한다. 최종 결정은 규칙 엔진, 사람 승인, 감사 가능한 내부 기준을 통과해야 한다.

운영 기준은 이렇게 잡는 편이 안전하다. 에이전트가 웹에서 가져온 내용은 항상 출처, 수집 시각, 검색 쿼리, 요약자 모델, 저장 여부를 함께 남긴다. 사람이 승인하기 전에는 내부 마스터 데이터에 덮어쓰지 않는다. 인용 URL이 없거나 출처가 약하면 “확정 정보”가 아니라 “검토 필요” 상태로 분류한다.

구현 전 확인해야 할 아키텍처 질문

첫째, 웹 그라운딩 결과를 영구 저장할 것인지 결정해야 한다. Google 발표는 Parallel Web Search 결과를 추출·캐시해 내부 데이터셋을 보강하는 유연성을 언급한다. 하지만 저장은 개인정보, 저작권, 라이선스, 보존 기간 정책과 연결된다. 개발자가 먼저 정해야 할 것은 “원문 저장”, “요약 저장”, “속성값만 저장”, “URL과 해시만 저장” 중 어느 수준인지다.

둘째, 검색 공급자를 하나로 고정할지 추상화할지 정해야 한다. 오늘은 Parallel이 적합해도 내일은 Google native grounding, 내부 검색, Bing, Perplexity API를 섞고 싶을 수 있다. 코드에서는 groundingProvider 인터페이스를 두고, 결과 스키마를 title, url, snippet, fetchedAt, confidence, licenseHint 정도로 표준화하는 게 좋다.

셋째, 모델 답변과 검색 증거를 분리 저장해야 한다. 운영 중 장애가 나면 “검색 결과가 틀렸는지”, “모델 요약이 틀렸는지”, “후처리 규칙이 틀렸는지”를 나눠 봐야 한다. 단일 텍스트 답변만 저장하면 재현이 어렵다. 프로덕션 로그에는 원본 검색 결과, 선택된 citation, 모델 입력, 모델 출력, 사람이 수정한 최종값을 분리해야 한다.

개발팀용 설계 예시

가장 현실적인 1차 구조는 4단계다. 1단계에서 사용자의 조사 요청을 intent로 분류한다. 2단계에서 내부 DB를 먼저 조회한다. 3단계에서 최신성이 필요한 필드만 Parallel Web Search로 보강한다. 4단계에서 Gemini가 내부 데이터와 웹 citation을 함께 사용해 요약을 만들고, 사람이 승인하면 구조화 필드를 저장한다.

예를 들어 “A사 신규 벤더 등록 가능 여부를 검토해줘”라는 요청이 들어오면 에이전트는 먼저 내부 거래 이력과 기존 벤더 상태를 확인한다. 이후 웹 그라운딩으로 회사 공식 사이트, 최근 뉴스, 제재·소송 관련 공개 자료를 조회한다. 답변에는 “확인된 사실”, “출처가 약한 주장”, “추가 확인 필요”를 분리한다. 승인 UI에는 각 항목 옆에 citation URL과 수집 시각을 붙인다.

이 구조의 장점은 실패 범위가 작다는 점이다. 웹 검색이 실패해도 내부 정보 기반 검토는 계속된다. citation 품질이 낮으면 해당 항목만 보류할 수 있다. 사람이 수정한 값은 다음 실행의 평가 데이터가 된다. 이렇게 만들어야 웹 그라운딩이 데모 기능에서 운영 기능으로 넘어간다.

비용과 지연 시간을 통제하는 방법

웹 그라운딩은 공짜가 아니다. 모델 호출 비용뿐 아니라 검색 호출, 후처리, 저장, 재시도 비용이 붙는다. 따라서 모든 요청에 웹 검색을 붙이면 안 된다. 요청을 세 단계로 나누는 게 좋다. 캐시로 충분한 요청, 내부 데이터만 필요한 요청, 실시간 웹 확인이 필요한 요청이다.

캐시 정책은 업무별로 다르게 둔다. 제품 가격은 하루 단위 캐시가 가능할 수 있지만, 규제 공지나 뉴스 리스크는 몇 시간 단위가 필요할 수 있다. 회사 기본 정보처럼 변동이 적은 데이터는 30일 이상 캐시해도 된다. 캐시 키에는 검색 쿼리만 넣지 말고 대상 엔티티 ID, 언어, 국가, 필드명을 포함해야 같은 회사의 다른 질문이 섞이지 않는다.

지연 시간은 병렬 처리와 중간 결과 UI로 줄인다. 내부 DB 조회, 웹 검색, 문서 검색을 동시에 시작하고, 먼저 끝난 결과를 부분 표시한다. 단, 최종 답변은 citation 검증이 끝난 뒤에만 확정한다. 사용자는 2초 안에 “조사 중인 출처 목록”을 보고, 10~20초 뒤에 구조화된 결과를 받는 경험이 훨씬 낫다.

실행 체크리스트

• Gemini Enterprise Agent Platform에서 Parallel Web Search 사용 가능 여부와 Marketplace 구독 조건을 확인한다.
• 웹 그라운딩을 붙일 업무를 “최신성 필요”, “출처 검증 필요”, “반복 조회” 기준으로 고른다.
• 원문, 요약, 속성값, URL 중 무엇을 저장할지 데이터 보존 정책을 먼저 정한다.
• 검색 결과와 모델 답변을 같은 필드에 섞지 말고 별도 로그로 남긴다.
• citation 없는 답변은 운영 UI에서 확정값으로 표시하지 않는다.
• 캐시 TTL을 업무별로 다르게 둔다. 모든 검색을 실시간으로 돌리지 않는다.
• 사람 승인 전에는 내부 마스터 데이터를 자동 덮어쓰기하지 않는다.
• PoC 성과는 “정답률” 하나로 보지 말고 출처 품질, 재현성, 비용, 평균 지연 시간까지 같이 측정한다.