AI 에이전트를 위해 Google 검색 결과를 JSON으로 가져오는 방법

당신은 AI 에이전트(AI agent)를 구축하고 있습니다.

처음에는 모든 것이 간단하게 느껴집니다. 사용자가 질문을 하면, 모델이 생각하고, 에이전트가 답변을 반환합니다.

그러다 명백한 문제에 직면하게 됩니다:

에이전트에게는 최신 정보가 필요합니다.

어쩌면 오늘자의 검색 결과가 필요할 수도 있습니다.

어쩌면 현재의 경쟁사 정보가 필요할 수도 있습니다.

어쩌면 최근의 제품 페이지가 필요할 수도 있습니다.

어쩌면 특정 도시의 지역 비즈니스 결과가 필요할 수도 있습니다.

어쩌면 연구 요약(research summary)을 작성하기 전에 출처가 필요할 수도 있습니다.

언어 모델(Language model)은 추론을 잘할 수 있지만, 지금 당장 무슨 일이 일어나고 있는지 항상 알고 있는 것은 아닙니다. 만약 작업이 현재의 검색 결과에 의존한다면, 검색 레이어(search layer)가 필요합니다.

많은 에이전트 워크플로우(agent workflows)에서, 그 검색 레이어는 JSON 형식의 Google 검색 결과로부터 시작됩니다.

이 포스트에서는 이를 생각하는 간단한 방법을 살펴보겠습니다:

사용자 작업(User task) → 검색 쿼리(search query) → SERP API → JSON 결과(JSON results) → AI 에이전트 응답(AI agent response)

우리가 만드는 것

기본적인 연구 에이전트(research agent)를 만든다고 가정해 봅시다.

사용자가 다음과 같이 질문합니다:

이메일 마케팅 소프트웨어의 주요 경쟁사를 찾고 Google에 나타나는 내용을 요약해줘.

에이전트는 다음을 수행해야 합니다:

검색 쿼리(search query) 생성
Google 검색 결과 가져오기
제목(titles), 링크(links), 스니펫(snippets), 순위(rankings) 파싱(Parse)
정제된 검색 컨텍스트(search context)를 LLM에 전달
유용한 요약 반환

중요한 부분은 우리가 가공되지 않은 HTML(raw HTML)을 원하지 않는다는 점입니다.

우리는 다음과 같은 구조화된 데이터(structured data)를 원합니다:

{
  "query": "best email marketing software",
  "organic_results": [
...

이것은 에이전트가 전체 검색 결과 페이지를 사용하는 것보다 훨씬 사용하기 쉽습니다.

왜 Google을 직접 스크래핑(scrape)하지 않나요?

Google을 직접 스크래핑할 수도 있습니다.

작은 실험용이라면 작동할 수도 있습니다. 요청을 보내고, HTML을 파싱하고, 링크를 추출한 뒤 다음 단계로 넘어가면 됩니다.

하지만 프로덕션(production) 환경은 다릅니다.

검색 페이지는 변경됩니다. 레이아웃은 쿼리(query)에 따라 달라집니다. 일부 결과에는 광고(ads), 로컬 팩(local packs), 이미지(images), 비디오(videos), 쇼핑 블록(shopping blocks), 관련 질문(People Also Ask), 또는 뉴스 결과(news results)가 포함됩니다. 결과 또한 국가, 언어, 기기 및 위치에 따라 달라집니다.

그리고 운영상의 문제(operational problems)가 있습니다:

차단된 요청 (blocked requests)
CAPTCHA
일관되지 않은 HTML (inconsistent HTML)
프록시 유지 관리 (proxy maintenance)
파서 업데이트 (parser updates)
재시도 로직 (retry logic)
위치 불일치 (location mismatch)
깨진 셀렉터 (broken selectors)

만약 당신의 목표가 AI 에이전트 (AI agent)를 구축하는 것이라면, 검색 스크레이퍼 (search scraper)를 유지 관리하는 것은 대개 핵심 제품이 아닙니다.

에이전트에게는 신뢰할 수 있는 검색 컨텍스트 (search context)가 필요합니다. 에이전트는 그것을 수집하기 위해 얼마나 많은 작업이 들어갔는지에는 관심이 없습니다.

그것이 바로 SERP API가 종종 더 적합한 선택인 이유입니다.

SERP API가 하는 일

SERP API는 검색 엔진 결과 (search engine results)를 수집하여 보통 JSON과 같은 구조화된 형식 (structured format)으로 반환합니다.

에이전트에게 가공되지 않은 HTML (raw HTML)을 처리하도록 요청하는 대신, 다음과 같이 깔끔한 필드 (fields)를 제공합니다:

결과 위치 (result position)
제목 (title)
링크 (link)
스니펫 (snippet)
도메인 (domain)
결과 유형 (result type)
위치 (location)
검색 엔진 (search engine)
관련 결과 또는 SERP 기능 (related results or SERP features)

워크플로우 (workflow)가 훨씬 단순해집니다:

검색 쿼리 (Search query) → SERP API 요청 (SERP API request) → JSON 응답 (JSON response) → 에이전트 컨텍스트 (agent context)

SerpApi, SearchAPI, Bright Data 또는 Talordata와 같은 제공업체를 통해 이 워크플로우를 테스트할 수 있습니다. 실제 사용 사례에서는 응답의 품질이 제공업체 자체보다 더 중요합니다.

이 예제에서는 일반적인 SERP API 요청 구조를 사용하겠습니다. 엔드포인트 (endpoint)와 파라미터 (parameter) 이름을 사용 중인 제공업체에 맞게 교체하세요.

기본적인 Python 예제

먼저, requests를 설치하세요:

pip install requests

그 다음 작은 스크립트를 작성합니다:

import os
import requests

...

이 스크립트는 세 가지 작업을 수행합니다:

SERP API에 검색 쿼리를 전송합니다.
구조화된 JSON을 돌려받습니다.
상위 유기적 결과 (organic results)를 출력합니다.

실제 에이전트 워크플로우에서는 아마 결과를 출력하지는 않을 것입니다. 대신 모델을 위한 컨텍스트 (context)로 변환할 것입니다.

SERP 결과를 에이전트 컨텍스트로 변환하기

LLM (Large Language Model)은 API 응답 전체를 필요로 하지 않습니다.

유용한 부분들에 대한 깔끔한 요약이 필요할 뿐입니다.

다음은 간단한 헬퍼 함수 (helper function)입니다:

def build_search_context(serp_data, max_results=5):
    results = serp_data.get("organic_results", [])[:max_results]

...

이제 다음과 같이 사용할 수 있습니다:

serp_data = search_google("best email marketing software")
search_context = build_search_context(serp_data)

...

예시 출력:

Position: 1
Title: Best Email Marketing Software Tools
URL: https://example.com
...

이것이 에이전트 (agent)가 사용할 수 있는 종류의 컨텍스트 (context)입니다.

에이전트 프롬프트에 검색 컨텍스트 추가하기

구조화된 검색 컨텍스트 (search context)를 확보했다면, 이를 LLM 프롬프트 (prompt)에 전달할 수 있습니다.

예시:

def build_agent_prompt(user_task, search_context):
    return f"""
You are a research assistant.
...
"""

사용법:

user_task = "Find the top competitors for email marketing software and summarize what appears in Google."

serp_data = search_google("best email marketing software")
...

이 시점에서 프롬프트는 원하는 LLM으로 전송될 수 있습니다.

중요한 점은 에이전트가 더 이상 정적인 지식 (static knowledge)만으로 답변하지 않는다는 것입니다. 에이전트는 최신의 검색 컨텍스트 (search context)를 갖게 됩니다.

간단한 에이전트 흐름 (agent flow)

다음은 전체적인 단순화된 흐름입니다:

def run_search_agent(user_task):
    # 실제 에이전트에서는 이 쿼리 (query)가 LLM에 의해 생성될 수 있습니다.
    query = "best email marketing software"
...

이것은 아직 완전한 프로덕션 수준의 에이전트 (production agent)는 아닙니다.

하지만 핵심적인 검색 레이어 (search layer)를 제공합니다:

작업 (task) → 쿼리 (query) → SERP JSON → 정제된 컨텍스트 (clean context) → LLM 프롬프트 (prompt)

여기에서 다음과 같은 기능들을 추가하여 개선할 수 있습니다:

쿼리 생성 (query generation)
다중 검색 (multiple searches)
소스 필터링 (source filtering)
도메인 추출 (domain extraction)
위치 타겟팅 (location targeting)
결과 캐싱 (result caching)
순위 비교 (ranking comparison)
인용 (citations)
재시도 로직 (retry logic)
예약된 모니터링 (scheduled monitoring)

AI 에이전트에게 위치는 중요합니다

흔히 하는 실수 중 하나는 Google 검색 결과가 어디서나 동일할 것이라고 가정하는 것입니다.

결과는 그렇지 않습니다.

다음과 같은 쿼리 (query)는:

best CRM software

국가, 언어 또는 기기에 따라 다른 결과를 생성할 수 있습니다.

다음과 같은 로컬 쿼리 (local query)는:

coffee shop near me

도시나 동네에 따라 완전히 달라질 수 있습니다.

만약 당신의 AI 에이전트가 로컬 SEO (local SEO), 시장 조사 (market research), 경쟁사 추적 (competitor tracking), 여행 조사 (travel research), 또는 이커머스 분석 (e-commerce analysis)을 수행하고 있다면, 위치 타겟팅 (location targeting)은 매우 중요합니다.

이는 귀하의 SERP API가 다음과 같은 파라미터 (parameters)를 지원해야 함을 의미합니다:

국가 (country)
도시 (city)
언어 (language)
기기 (device)
검색 엔진 (search engine)
출력 형식 (output format)

이러한 기능이 없다면, 귀하의 에이전트 (agent)는 잘못된 시장의 결과를 요약할 수 있습니다.

SERP API를 선택하기 전에 확인해야 할 사항

제공업체를 선택하기 전에, 실제 에이전트 작업으로 테스트해 보십시오.

단 하나의 데모 쿼리 (demo query)만 실행하지 마십시오.

귀하의 에이전트가 실제로 실행할 검색을 시도해 보십시오. 응답 (response)에 귀하의 워크플로 (workflow)가 필요로 하는 필드 (fields)가 포함되어 있는지 확인하십시오.

몇 가지 실질적인 질문들입니다:

깔끔한 JSON을 반환하는가?
필요한 경우 HTML도 제공하는가?
위치 기반 결과 (location-based results)를 지원하는가?
유기적 검색 결과 (organic results), 광고 (ads), 지도 (maps), 쇼핑 (shopping), 뉴스 (news) 또는 기타 SERP 블록 (SERP blocks)을 포함하는가?
필드 (fields)가 자동화에 충분할 만큼 안정적인가?
실패한 요청 (failed requests)에 대해서도 비용이 청구되는가?
데이터를 LLM (Large Language Model)에 전달하기 전에 얼마나 많은 정제 (cleanup) 작업이 필요한가?

이 지점이 마케팅 페이지보다 테스트가 더 중요한 부분입니다.

예를 들어, SerpApi, SearchAPI, Bright Data, Talordata 또는 기타 SERP API 제공업체를 비교하고 있다면, 각 업체에 동일한 실제 쿼리를 보내고 응답 구조 (response structure)를 비교해 보십시오.

최고의 API는 대개 추가적인 작업 없이 에이전트에게 사용 가능한 컨텍스트 (context)를 제공하는 API입니다.

실제 프로젝트에서의 적용

이 패턴은 많은 AI 에이전트 유스케이스 (use cases)에 적용됩니다:

리서치 에이전트 (research agents)
SEO 코파일럿 (SEO copilots)
경쟁사 모니터링 도구 (competitor monitoring tools)
시장 조사 어시스턴트 (market research assistants)
이커머스 인텔리전스 도구 (e-commerce intelligence tools)
로컬 검색 분석 (local search analysis)
자동 보고서 생성 (automated report generation)
검색 기반 RAG 워크플로 (search-driven RAG workflows)

에이전트는 인간처럼 "웹을 브라우징"할 필요가 없습니다.

에이전트에게는 추론 (reason)할 수 있는 구조로 된 신뢰할 수 있는 검색 데이터가 필요합니다.

그것이 AI 에이전트를 위한 SERP API의 진정한 가치입니다.

마치며

Google 검색 결과를 JSON으로 가져오는 것은 단순히 스크래핑 (scraping)의 문제가 아닙니다.

AI 에이전트에게 이것은 컨텍스트 (context)의 문제입니다.

모델은 신선하고 관련성이 있으며 구조화된 검색 데이터를 필요로 합니다. 가공되지 않은 HTML은 지저분합니다. 정적인 모델 지식 (static model knowledge)은 구식일 수 있습니다. 수동 검색은 확장성 (scale)이 없습니다.

SERP API (Search Engine Results Page API)는 에이전트에게 더 깔끔한 검색 레이어 (search layer)를 제공합니다.

쿼리를 전송하면 구조화된 결과 (structured results)를 받고, 유용한 필드 (fields)를 추출하여 이를 컨텍스트 (context)로서 모델에 전달합니다.

이러한 워크플로 (workflow)를 테스트하고 있다면, Talordata는 비교해 볼 만한 선택지 중 하나입니다. Talordata는 구조화된 SERP 데이터, JSON / HTML 응답 형식 (response formats), 지리적 타겟팅 결과 (geo-targeted results)를 지원하며, AI 에이전트, SEO 모니터링, 경쟁사 추적 (competitor tracking), 시장 조사 (market research)를 위한 검색 워크플로를 지원합니다.

또한 Talordata는 **가입 후 1,000회의 무료 API 요청**을 제공하므로, 특정 제공업체를 확정하기 전에 실제 에이전트 쿼리로 응답 형식을 테스트하기에 충분합니다.