Design Google Search AI Overviews, 검색 결과를 요약하는 문제가 아니라 출처와 함께 생성 답변을 제공하는 서비스

검색 결과 몇 개를 LLM에 넣으면 답변은 만들 수 있습니다. 하지만 실제 검색 제품에서는 검색 확장, 문서 선택, publisher 제어, 답변 생성, 출처 연결, 재검증을 서로 다른 처리 경로로 설계해야 합니다.

Introduction & Requirements

이 글에서 등장하는 Search Orchestrator, Source Snapshot Service, Citation Mapper, Answer Snapshot Store 같은 컴포넌트는 공개 문서에서 확인된 Google 내부 서비스 이름이 아닙니다. 공개된 제품 동작과 Search Central 정책을 바탕으로, 면접 상황에서 대규모 생성형 검색 시스템을 어떻게 설계할 수 있는지 설명하기 위해 정의한 컴포넌트입니다.

Google은 AI Overviews가 검색 결과에서 AI가 생성한 정보 요약과 더 깊게 탐색할 수 있는 링크를 제공한다고 설명합니다. 또한 Google Search Central은 AI Overviews와 AI Mode가 관련 웹 링크를 보여주며, 여러 하위 주제와 데이터 소스에 걸쳐 관련 검색을 동시에 수행하는 query fan-out을 사용할 수 있다고 설명합니다.

여기서 query fan-out이라는 용어를 먼저 풀어보겠습니다.

사용자가 다음과 같이 검색했다고 가정하겠습니다.

전기차를 처음 사는데 겨울 주행거리와 충전비를 고려하면 어떤 차가 좋은가?

이 질문을 검색 한 번으로만 처리하지 않고 내부적으로 다음과 같은 관련 검색으로 확장할 수 있습니다.

전기차 겨울 주행거리 감소율
전기차 모델별 실제 겨울 주행거리
지역별 급속 충전 비용
가정용 충전 비용
전기차 배터리 열관리
초보 운전자 전기차 비교

하나의 사용자 질문에서 여러 관련 검색을 만드는 방식을 query fan-out이라고 부릅니다.

이 구조가 들어가면 일반적인 검색 결과 조회보다 처리량이 빠르게 증가할 수 있습니다. 사용자 요청은 한 건이지만 내부에서는 여러 검색 요청, 문서 후보, 중복 URL, source policy 확인, ranking, context 구성 작업이 생기게 됩니다.

처음 이 문제를 보면 이렇게 설계할 수 있습니다.

“검색 결과 상위 몇 개를 가져오고, 본문 일부를 LLM에 넣어서 답변을 만들면 되지 않을까요?”

작은 테스트 환경에서는 이 방식으로 결과를 만들 수 있습니다. 검색 결과 URL 몇 개를 가져오고, 텍스트를 추출한 뒤, 모델에 전달하면 요약 답변이 나옵니다.

하지만 실제 검색 환경에서는 질문 하나가 여러 하위 주제로 확장될 수 있습니다. 각 하위 검색에서는 서로 다른 문서 후보가 나오고, 같은 URL이 반복될 수 있으며, 페이지마다 최신성도 다르게 됩니다. 일부 페이지에는 snippet 사용 제한이 있을 수 있고, 일부 문서는 검색 결과에 표시될 수 있는 조건을 충족하지 않을 수 있습니다.

Google Search Central은 AI 기능의 supporting link로 표시되려면 페이지가 Google Search에 색인되어 있고 snippet 표시 자격을 가져야 한다고 설명합니다. 또한 nosnippet, data-nosnippet, max-snippet 같은 제어가 Search의 AI 기능에서 콘텐츠 사용 범위에 영향을 줄 수 있다고 설명합니다.

그래서 이 글에서는 검색 결과 URL을 바로 LLM에 넣지 않습니다.

검색 후보를 수집한 뒤 다음 조건을 확인하게 됩니다.