AI Sparkup

복잡한 AI 세상을 읽는 힘 ⚡

Google AI Mode가 웹을 읽는 두 가지 방법: browsing vs content_fetcher

﹒

﹒

3 minutes

Google AI Mode가 당신의 웹사이트를 방문할 때, 어떤 방식으로 콘텐츠를 가져갈까요? 사람처럼 한 페이지씩 읽을까요, 아니면 검색 결과를 한꺼번에 긁어갈까요? 이 차이를 이해하면 AI 검색 최적화 전략이 달라집니다.

사진 출처: DEJAN

SEO 전문가 Dejan이 Google AI Mode의 시스템 프롬프트를 추출해 내부 작동 방식을 분석한 글을 공개했습니다. 핵심은 Google의 Gemini 기반 AI가 웹 콘텐츠를 가져오는 두 가지 서로 다른 API—browsing과 content_fetcher—를 사용한다는 점입니다.

출처: Browsing vs Content Fetcher – DEJAN

사람처럼 읽는 browsing

browsing은 사용자가 웹 브라우저 주소창에 URL을 직접 입력하는 것과 비슷합니다. 특정 페이지 하나를 지정해서 그 내용을 통째로 가져오죠.

def browse(
    query: str,
    url: str,
) -> str:
    ...

입력값은 단순합니다. query(무엇을 찾는지)와 url(어디서 찾는지) 두 가지만 있으면 됩니다. 예를 들어 “현재 주식 가격을 확인하고 싶어”라는 질문에 특정 금융 뉴스 사이트 URL을 제공하면, AI가 그 페이지를 직접 방문해서 정보를 읽어옵니다.

이 방식은 단일 페이지에서 심층 정보를 추출할 때 효과적입니다. 사용자가 명시적으로 URL을 제공하거나, AI가 특정 페이지의 상세 내용이 필요하다고 판단할 때 사용됩니다.

배치로 처리하는 content_fetcher

반면 content_fetcher는 여러 소스를 한꺼번에 처리하도록 설계됐습니다. 검색 결과를 받아 그중 유용한 페이지들을 동시에 가져오는 방식이죠.

@dataclasses.dataclass
class SourceReference:
    id: str
    type: str | None = None

def fetch(
    query: str,
    source_references: list[SourceReference],
) -> str:
    ...

입력값으로 SourceReference 객체의 리스트를 받습니다. 각 객체에는 소스의 id(대부분 URL)와 type이 포함됩니다. 구조화된 데이터를 받는다는 점에서 시스템 중심적이고 효율적입니다.

실제 작동 예시를 보면 명확합니다. 사용자가 “커스텀 러닝복을 디자인하고 주문할 수 있는 곳”을 검색하면, AI는 먼저 Google Search로 관련 사이트들을 찾습니다. 그 결과로 customink.com, tdsportswear.com, gobik.com 등 여러 URL이 나오죠. 이때 content_fetcher가 이 URL들을 한꺼번에 가져와 비교 분석하고 종합된 답변을 만들어냅니다.

검색부터 답변까지의 흐름

실제 Google AI Mode는 이 두 도구를 상황에 맞게 조합합니다. 일반적인 흐름은 이렇습니다:

  1. 사용자 질문 분석
  2. Google Search로 관련 페이지 탐색 (검색 결과에 URL 리스트 포함)
  3. content_fetcher로 여러 소스의 콘텐츠를 배치 수집
  4. 필요시 browsing으로 특정 페이지 상세 분석
  5. 수집한 정보를 종합해 답변 생성

Dejan의 추가 연구에 따르면, Google AI Mode는 내부적으로 다음과 같은 검색 결과 구조를 사용합니다:

{
  "index": "1.2.2",
  "snippet": "페이지 스니펫 텍스트...",
  "source_title": "출처 제목",
  "url": "https://example.com",
  "publication_time": "March 13 2025"
}

이 구조화된 데이터가 바로 content_fetcher가 처리하는 SourceReference 리스트의 원천입니다. 검색 도구가 먼저 이런 메타데이터를 수집하고, content_fetcher가 실제 콘텐츠를 가져오는 분업 구조죠.

실무자들이 알아야 할 것

SEO/콘텐츠 제작자 관점:

  • AI가 당신의 페이지를 읽는 방식은 두 가지입니다. 검색 결과에 먼저 노출돼야 content_fetcher로 수집될 기회를 얻고, 상세 분석이 필요한 콘텐츠라면 browsing으로 심층 방문을 받습니다.
  • 스니펫 최적화가 중요합니다. content_fetcher는 검색 결과의 짧은 스니펫을 먼저 보고 전체 페이지를 가져올지 결정하기 때문입니다.
  • 구조화된 데이터와 명확한 헤딩이 더 중요해졌습니다. AI가 여러 페이지를 동시에 비교하므로 정보를 빠르게 파악할 수 있는 구조가 유리합니다.

개발자 관점:

  • LLM 애플리케이션을 만들 때 단일 소스 분석과 다중 소스 비교를 구분해서 설계해야 합니다.
  • Google의 접근처럼 검색과 콘텐츠 수집을 분리하면 효율성과 확장성이 높아집니다.
  • API 설계 시 단일 URL 처리와 배치 처리를 별도 엔드포인트로 제공하는 것을 고려할 수 있습니다.

Google의 공식 Gemini API 문서를 보면, 이와 유사한 개념으로 url_context 도구가 있습니다. 이 도구는 최대 20개의 URL을 한 번에 처리할 수 있으며, 내부 캐시와 실시간 페칭을 조합한 2단계 검색 방식을 사용합니다. 먼저 인덱스 캐시에서 콘텐츠를 찾고, 없으면 실시간으로 페이지를 가져오는 방식이죠. 이는 속도, 비용, 최신성 사이의 균형을 맞추려는 설계입니다.

한계와 미래

현재 시스템에도 한계는 있습니다. Dejan의 다른 연구에 따르면 AI Mode는 완전한 실시간 웹 접근이 아니라 Google의 기존 인덱스나 캐시 버전에 의존하는 경우가 많습니다. 아주 새로운 콘텐츠나 인덱스되지 않은 페이지는 제대로 읽지 못할 수 있죠.

또한 페이월 뒤의 콘텐츠, YouTube 동영상(별도 처리 필요), Google Workspace 파일 등은 지원하지 않습니다. 이런 제약은 시간이 지나면서 개선될 가능성이 높습니다.

하지만 분명한 것은 AI 검색이 전통적인 크롤러와는 근본적으로 다른 방식으로 웹을 소비한다는 점입니다. 검색 결과를 구조화된 데이터로 수집하고, 여러 소스를 동시에 비교하며, 필요시 심층 분석을 수행하는 이 패턴은 앞으로 더 정교해질 것입니다.

참고자료:

AI Sparkup 구독하기

최신 게시물 요약과 더 심층적인 정보를 이메일로 받아 보세요! (무료)

Comments

Comments

Join the conversation on Bluesky

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

More posts