"gemini web scraping"으로 검색해 나오는 튜토리얼은 대부분 독자가 한 사람이라고 가정해요. 가상 환경은 이미 깔려 있고, Pydantic 스키마도 익숙하며, 비동기 라이브러리 취향까지 확고한 Python 개발자죠. 그런 분이라면 바로 코드로 넘어가시면 돼요. 그런데 영업, 마케팅, 이커머스 운영을 하면서 markdownify 같은 걸 따로 공부할 여유 없이 여러 웹페이지에서 구조화된 데이터만 뽑고 싶은 분도 많아요. 이 글은 그런 분들까지 염두에 두고 썼어요.
Gemini는 Google의 멀티모달 AI 제품군이에요. 요즘은 웹 데이터 추출 엔진으로도 빠르게 자리 잡고 있죠. 2025 Stack Overflow Developer Survey를 보면 개발자의 84%가 AI 도구를 쓰거나 쓸 계획이라고 답했어요. LLM 기반 스크래핑이 그 흐름의 큰 축이에요. 다만 "URL 하나에서 멋지게 도는 데모"와, 페이지네이션·하위 페이지·봇 차단·지저분한 HTML까지 대규모로 감당하는 실제 파이프라인은 차이가 커요. 이 가이드는 Python 방식과 노코드 방식을 둘 다 다뤄요. 실제 토큰 계산으로 모델 고르는 법도 짚고, 다른 글이 잘 건너뛰는 멀티페이지 스크래핑까지 챙겨요. Gemini 스크래핑이 어디서 무너지는지도 솔직하게 말씀드릴게요. 끝까지 읽으면 어떤 방식이 본인 업무에 맞는지, 개발자든 아니든 흔히 빠지는 함정을 어떻게 피하는지 감이 잡힐 거예요.
Gemini 웹 스크래핑이란?
Gemini 웹 스크래핑은 웹페이지 내용을 — HTML이든 Markdown이든, 스크린샷까지 — Google의 Gemini AI에 넣고, 페이지를 해석해 구조화된 데이터로 돌려받는 방식이에요. CSS 선택자도, XPath도 필요 없어요. 사이트 레이아웃이 조금만 바뀌어도 깨지는 불안정한 규칙도 안 써요.
핵심 흐름은 이래요.
- 페이지 가져오기 (
requests, 헤드리스 브라우저, 또는 Chrome 확장 프로그램 사용) - 내용 정리 및 변환 (보통 HTML → Markdown으로 바꿔 토큰 비용 절감)
- 원하는 필드를 설명한 스키마와 함께 Gemini로 전송
- 구조화된 JSON 수신 — 스프레드시트, CRM, 데이터베이스에 바로 활용 가능
전통적인 BeautifulSoup나 Selenium 방식과 비교해 보면 차이가 분명해요. 그쪽은 div.product-title > span.price 같은 선택자를 하드코딩하고, 사이트가 다음 주에 리디자인 안 하길 빌어야 하죠. Gemini는 사람이 페이지 읽듯 콘텐츠를 이해해요. 문맥을 파악하고, 레이아웃 변화에 적응하며, 커스텀 규칙 없이도 복잡한 포맷을 처리해요.
하나 더 짚을 게 있어요. Gemini는 태생이 멀티모달이에요. 텍스트, 이미지, 영상, 오디오, PDF, 코드까지 한 번에 받아요. 그래서 HTML 대신 스크린샷을 보내는 식의, 다른 LLM으로는 따라하기 힘든 방법도 가능해요. 이건 뒤에서 다시 볼게요.
Gemini 웹 스크래핑이 비즈니스 팀에 중요한 이유
마케팅 매니저나 이커머스 애널리스트가 왜 LLM과 웹 스크래핑을 챙겨야 하냐고 묻는다면, 답은 간단해요. 시간을 엄청 아껴 주고, 웹사이트가 업데이트될 때마다 깨지지 않거든요.
웹 스크래핑 소프트웨어 시장은 2025년 약 10억 달러에서 2030년 20억 달러 이상으로 커질 전망이에요. 그중 AI 기반 추출이 가장 빠르게 성장하는 분야고요. 단순한 과장이 아니라, 데이터 수집 방식 자체가 바뀌고 있다는 신호예요.
Gemini 스크래핑은 일상적인 업무에서 이렇게 쓰여요.
| 활용 사례 | 추출 대상 | 주요 수혜자 |
|---|---|---|
| 리드 생성 | 디렉터리, LinkedIn(공개 정보), 회사 웹사이트의 연락처 정보 | 영업, BDR |
| 경쟁사 가격 모니터링 | 제품 가격, 재고 상태, 프로모션 | 이커머스, 가격 전략팀 |
| 상품 카탈로그 추출 | 상품명, 사양, 이미지, 리뷰 | 머천다이징, 마켓플레이스 운영 |
| 부동산 매물 수집 | 매물 정보, 가격, 중개인 정보 | 중개인, 투자자 |
| 콘텐츠 수집 | 뉴스, 블로그 글, 소셜 미디어 언급 | 마케팅, PR |
| 채용 시장 조사 | 직무명, 연봉, 지역 | HR, 채용 |
실질적인 이점은 두 가지예요. 첫째, 파싱 스크립트를 쓰고 테스트하고 디버깅하는 과정을 건너뛸 수 있어요. 모델이 매번 페이지를 새로 읽으니까요. 둘째, 사이트가 <div> 위치를 바꿀 때마다 개발자를 다시 부를 필요가 없어요. Gemini 무료 티어 덕에 소규모 작업은 거의 공짜로 실험해 볼 수 있어요. Flash-Lite는 하루 약 1,000회, Pro는 하루 약 100회 요청이 되고, 신용카드도 안 받아요.
어떤 Gemini 모델을 선택해야 할까? (Flash Lite vs. Flash vs. Pro)
스크래핑에서 모든 Gemini 모델이 똑같은 성능을 내진 않아요. 잘못 고르면 돈만 날리거나, 엉망인 데이터를 받게 돼요. 그래서 대부분의 튜토리얼이 빼먹는 실전 비교를 준비했어요.
현재 Gemini 2.5 모델 3종은 모두 1,048,576 토큰 컨텍스트 윈도우를 공유하고 멀티모달을 지원해요. 차이는 비용, 속도, 복잡한 추출을 견디는 힘이에요.
| 모델 | 입력 비용(100만 토큰당) | 출력 비용(100만 토큰당) | 적합한 용도 | 복잡한 스키마 정확도 | 속도 |
|---|---|---|---|---|---|
| Gemini 2.5 Flash Lite | 약 $0.025 | 약 $0.10 | 단순한 평면 데이터, 대량 처리 | ⚠️ 중첩/선택 필드에 약함 | 가장 빠름 |
| Gemini 2.5 Flash | 약 $0.075 | 약 $0.625 | 대부분의 스크래핑 작업 | ✅ 구조화 추출에 적합 | 빠름 |
| Gemini 2.5 Pro | 약 $0.3125 | 약 $2.50 | 복잡한 중첩 스키마, 예외 케이스 | ✅ 최고 수준의 정확도 | 가장 느림 |
(가격은 Gemini Developer API 기준이에요. Batch API는 이 요금의 50%예요.)
Gemini 2.5 Flash Lite: 빠르고 저렴하지만 누락을 조심하세요
Flash Lite는 예산이 빠듯할 때 좋은 선택이에요. 상품명, 가격, 단일 레벨 목록처럼 단순하고 평평한 데이터를 대량으로 돌릴 때 잘 맞아요. 다만 선택 필드, 타임스탬프, 중첩 데이터에서 사고를 친 사례가 기록으로 남아 있어요. Google 포럼의 한 개발자는 필수가 아닌 선택 필드가 끼면 Flash Lite가 "완전히 이상해진다"고 했어요. 토큰 한도에 닿을 때까지 같은 텍스트를 반복 출력한다는 거죠. 스키마가 2단계 이상 중첩되거나, 일부 페이지엔 없을 수도 있는 필드가 있다면, Flash Lite는 토큰도 인내심도 다 갉아먹을 수 있어요.
Gemini 2.5 Flash: 대부분의 스크래핑 작업에 균형이 가장 좋아요
실전 스크래핑이라면 저는 거의 항상 Flash부터 잡아요. 구조화 추출을 잘하고, 페이지네이션 로직도 무난하게 다뤄요. 입력 비용이 Flash Lite보다 3배쯤 비싸지만, 정확도 향상이 그 값을 충분히 해요. GPQA 수준 추론 벤치마크에서도 Flash는 Pro와 몇 점 차이밖에 안 나요. 스크래핑에 필요한 추론, 정규화, 평탄화를 잘 해낸다는 뜻이에요.
Gemini 2.5 Pro: 복잡한 데이터에는 최고 정확도
Pro는 정밀 도구예요. 다층 중첩 스키마를 뽑을 때, 또는 허위 필드가 절대 용납 안 되는 경우(법률, 금융, 의료 데이터)에 쓰세요. 입력 비용이 Flash Lite의 약 12배라, 가격보다 정확도가 훨씬 중요한 작업에만 쓰는 게 좋아요.
실제 비용 예시: 상품 페이지 10,000개
HTML을 Markdown으로 전처리한다고 칠게요. 사실 그래야 맞고요. 자세한 건 아래에서 더 다루지만, 보통 상품 페이지는 원시 HTML 기준 약 20,000 토큰인데 Markdown으로 바꾸면 약 4,000 토큰으로 줄어요. 출력 JSON은 페이지당 약 500 토큰 정도예요.
| 모델 | 입력 비용(4,000만 토큰) | 출력 비용(500만 토큰) | 10,000페이지 총비용 |
|---|---|---|---|
| Flash Lite | $1.00 | $0.50 | 약 $1.50 |
| Flash | $3.00 | $3.13 | 약 $6.13 |
| Pro | $12.50 | $12.50 | 약 $25.00 |
Markdown 전처리 없이 원시 HTML을 그대로 넣으면(입력이 약 2억 토큰 수준), 이 비용이 4~5배까지 뛰어요. 전처리는 파이프라인에서 효과가 가장 큰 최적화예요.
코드 vs. 노코드: Gemini 웹 스크래핑의 두 가지 경로
여기서 길이 갈려요. 커스텀 파이프라인을 짜는 개발자라면 Python + Gemini API가 제어권을 가장 많이 줘요. 반대로 터미널은 안 건드리고 지금 당장 데이터가 필요한 비즈니스 사용자라면 노코드 AI 스크래퍼가 훨씬 빨라요.
| 기준 | Gemini API (Python) | Thunderbit (노코드) |
|---|---|---|
| 설정 시간 | 15~30분(환경, 키, 라이브러리) | 1분 미만(Chrome 확장 설치) |
| 코딩 필요 여부 | 예(Python, Pydantic) | 없음 |
| 페이지네이션 처리 | 수동 스크립팅 | 내장 지원(클릭 또는 무한 스크롤) |
| 하위 페이지 보강 | 사이트별 커스텀 코드 필요 | 1클릭 "하위 페이지 스크래핑" |
| 토큰 비용 관리 | 수동(HTML 정리, 모델 선택) | AI 엔진이 자동 처리 |
| 내보내기 옵션 | 스크립트를 통한 JSON/CSV | Excel, Google Sheets, Airtable, Notion |
| 적합한 사용자 | 커스텀 파이프라인을 만드는 개발자 | 지금 당장 데이터가 필요한 비개발자 |
Thunderbit은 Thunderbit에서 만든 노코드 옵션이에요. 내부적으로 Gemini, ChatGPT, Claude 등을 활용하는 AI로 필드를 추천하고, 두 번 클릭으로 스크래핑하고, 원하는 도구로 바로 내보내는 Chrome 확장 프로그램이죠. 아래에서 두 경로를 모두 살펴볼게요.
스프레드시트 위주로 일하는 분이라면 Quadratic도 알아둘 만해요. 시트 안에서 Gemini 기반 웹 스크래핑을 돌리는 AI 스프레드시트예요. 다만 이미 아는 웹페이지에서 출발하는 워크플로(상품 목록, 디렉터리, 리드 DB 등)라면 Thunderbit가 사고 방식과 더 잘 맞아요.
단계별: Python으로 Gemini 웹 스크래핑하기
이 섹션은 개발자용이에요. 노코드 경로를 원하면 다음 섹션으로 넘어가세요.
시작 전 준비:
- 난이도: 중급(Python 이해 필요)
- 소요 시간: 첫 스크래핑 약 20~30분
- 필요한 것: Python 3.10+, Google AI Studio 계정(무료), 대상 URL
1단계: Python 환경과 Gemini API 키 설정
프로젝트 폴더와 가상 환경을 만들고 필요한 라이브러리를 설치해요.
mkdir gemini-scraper && cd gemini-scraper
python -m venv venv && source venv/bin/activate
pip install -U google-genai requests beautifulsoup4 markdownify pydantic
중요: 2026년 현재 올바른 SDK는 google-genai 하나뿐이에요. 예전 google-generativeai 패키지는 2025-11-30에 종료됐고 지금은 deprecated 상태예요. 튜토리얼에서 import google.generativeai as genai가 보이면, 그 코드는 이미 낡은 거예요.
이어서 Google AI Studio에서 API 키를 발급받아요. "Get API Key"를 누르고 새 키를 만든 뒤 환경 변수로 저장하세요.
export GEMINI_API_KEY="your-key-here"
이걸로 의존성이 깔리고 API 키까지 준비된 Python 환경이 완성돼요.
2단계: 대상 페이지의 HTML 가져오기
requests로 페이지를 가져와요. 예시로 상품 페이지를 스크래핑해 볼게요.
import requests
url = "https://example.com/product/widget-pro"
response = requests.get(url, headers={"User-Agent": "Mozilla/5.0"}, timeout=30)
html = response.text
사이트가 JavaScript 렌더링이 강하거나 봇 차단이 빡세면 requests.get()이 빈 껍데기만 주거나 403을 던질 수 있어요. 이런 경우 해결법은 뒤의 한계 섹션에서 다룰게요. 다만 많은 공개 사이트에선 이 방법으로 잘 돼요.
3단계: HTML을 정리하고 Markdown으로 변환하기
대부분 튜토리얼이 말만 하고 숫자는 안 내놓는 단계예요. 보통 상품 페이지의 원시 HTML은 약 20,000 토큰 수준이에요. BeautifulSoup로 군더더기를 걷어내고 Markdown으로 바꾸면 대략 765~4,000 토큰까지 줄어, 5~10배 절감이 가능해요. 비용도 줄고, 환각 가능성도 낮아져요.
from bs4 import BeautifulSoup
from markdownify import markdownify
soup = BeautifulSoup(html, "html.parser")
main = soup.select_one("main") or soup # 콘텐츠 영역만 가져오기
markdown_content = markdownify(str(main))
select_one("main")은 헤더, 푸터, 내비게이션, 스크립트 같은 잡음을 걷어내요. 토큰을 낭비하고 모델을 헷갈리게 하는 것들이죠. 사이트에 <main> 태그가 없으면 .product-detail, #content처럼 실제 데이터가 든 래퍼를 찾아보세요.
이 단계가 끝나면 페이지 핵심만 담긴 깔끔한 Markdown 문자열이 남아요.
4단계: 데이터 스키마를 정의하고 Gemini로 전송하기
Pydantic으로 받아올 데이터를 정의해요. google-genai SDK는 response_schema에 Pydantic BaseModel을 그대로 받아요.
from google import genai
from google.genai import types
from pydantic import BaseModel
class Product(BaseModel):
name: str
price: str
sku: str | None = None
description: str
sizes: list[str] = []
colors: list[str] = []
client = genai.Client() # 환경 변수 GEMINI_API_KEY를 읽음
response = client.models.generate_content(
model="gemini-2.5-flash",
contents=f"이 페이지에서 상품 세부 정보를 추출해 주세요:\n\n{markdown_content}",
config=types.GenerateContentConfig(
response_mime_type="application/json",
response_schema=Product,
),
)
product = response.parsed
print(product)
기록으로 남은 버그 목록에서 나온 주의점이 몇 가지 있어요.
- Gemini에 보낼 스키마에선
Field(default=...)를 쓰지 마세요 — API가ValueError를 던져요. 대신sku: str | None = None처럼 타입 수준에서 처리하세요. - 중첩은 얕게 유지하세요(최대 3단계). 깊게 중첩하면 Flash와 Flash Lite에서 재귀 출력이나 안 닫힌 괄호가 나올 수 있어요.
- Flash Lite를 쓸 땐 필드를 필수로 지정하고, 생략 대신 빈 문자열 같은 센티널 값을 쓰는 게 나아요. Flash Lite는 선택 필드 처리에 신뢰성이 떨어져요.
이걸로 페이지에서 구조화된 데이터를 담은 Product 객체를 얻을 수 있어요.
5단계: 추출한 데이터 내보내기 및 저장하기
결과를 JSON이나 CSV로 저장해요.
import json
with open("products.json", "w") as f:
json.dump(product.model_dump(), f, indent=2)
Google Sheets로 넘기려면 gspread 라이브러리를 쓰면 돼요. 데이터베이스라면 원하는 ORM에 맞춰 직렬화하면 되고요. Gemini의 구조화 출력은 대부분 후속 도구에 바로 넣을 만큼 깔끔해요.
단계별: 코드 없이 Gemini 웹 스크래핑하기 (Thunderbit 사용)
이 경로는 비즈니스 사용자, 또는 일회성 스크래핑 스크립트를 짜기 싫은 개발자를 위한 거예요.
시작 전 준비:
- 난이도: 초급
- 소요 시간: 첫 스크래핑 약 5분
- 필요한 것: Chrome 브라우저, Thunderbit 확장 프로그램 (무료 티어 가능)
1단계: Thunderbit Chrome 확장 프로그램 설치
Chrome Web Store로 가서 "Add to Chrome"을 누르세요. 이메일로 가입하면 끝이에요. 전체 과정이 1분도 안 걸려요. 위의 Python 설정과 비교하면 훨씬 간단하죠.
2단계: 대상 페이지를 열고 "AI Suggest Fields" 클릭
스크래핑할 웹사이트로 가세요. 상품 목록, 부동산 디렉터리, 리드 DB 등 뭐든 좋아요. 브라우저 툴바에서 Thunderbit 아이콘을 누른 뒤 **"AI Suggest Fields"**를 클릭하세요.
Thunderbit의 AI가 페이지를 읽고 "Product Name", "Price", "Rating", "Image URL" 같은 열 이름과 데이터 유형을 자동으로 추천해요. 열 이름을 고치거나, 안 쓰는 필드를 빼거나, 각 열에 맞춤 AI 프롬프트를 더할 수도 있어요(예: "High/Medium/Low로 분류", "영어로 번역").
스크래핑을 시작하기 전에 설정한 열이 표 미리보기로 먼저 보여요.
3단계: "Scrape" 클릭 후 결과 확인
한 번만 클릭하면 돼요. Thunderbit가 페이지네이션을 알아서 처리하고 — 클릭 방식의 "Next" 버튼도, 무한 스크롤도 — 데이터를 구조화된 표로 뽑아요. 다음 중 하나를 고르면 돼요.
- Cloud Scraping: 더 빠르고 최대 50페이지를 동시에 처리해요. 공개 사이트에 적합해요.
- Browser Scraping: 로그인된 브라우저 탭에서 돌아가요. 인증이 필요한 사이트(CRM, 접근 제한 디렉터리, 내부 도구)에 쓰세요.
결과는 확장 프로그램 사이드바의 표에 바로 떠요. 내보내기 전에 눈에 띄는 오류가 있는지 확인하세요.
4단계: Excel, Google Sheets, Airtable 또는 Notion으로 내보내기
내보내기 버튼을 누르고 원하는 형식을 고르세요. Thunderbit는 Excel, Google Sheets, Airtable, Notion으로 무료 내보내기를 지원해요. 추가 결제도 없고요. 이미지 필드는 Notion과 Airtable의 이미지 라이브러리에 바로 올라가요. 상품 사진이나 프로필 사진을 스크래핑할 때 특히 편해요.
JSON 파싱도, 스크립트도 필요 없어요. 데이터를 바로 쓰면 돼요.
Gemini로 멀티페이지 및 하위 페이지 스크래핑하기
대부분 튜토리얼은 조용히 URL 하나에서 끝나요. 실제 스크래핑 업무는 그렇지 않죠.
페이지네이션과 상세 하위 페이지가 있는 상품 페이지 500개를 긁는 건 그 자체로 하나의 일이에요. 단일 URL 데모와 실제 업무 사이의 간극은 정말 커요.
Gemini API로 페이지네이션 처리하기(코드 방식)
페이지 번호가 붙는 URL 패턴이 가장 흔해요. 결과가 빌 때까지 페이지를 반복하면 돼요.
import time
all_products = []
for page in range(1, 101): # 최대 100페이지
url = f"https://example.com/products?page={page}"
md = fetch_clean(url) # 앞에서 만든 HTML→Markdown 함수
response = client.models.generate_content(
model="gemini-2.5-flash-lite", # 목록 페이지는 저렴한 모델 사용
contents=f"상품명과 URL을 추출해 주세요:\n\n{md}",
config=types.GenerateContentConfig(
response_mime_type="application/json",
response_schema=list[ListingItem],
),
)
items = response.parsed
if not items:
break
all_products.extend(items)
time.sleep(4) # 무료 티어 한도 준수
커서 기반이나 무한 스크롤 사이트라면, 프런트엔드가 호출하는 XHR 엔드포인트를 브라우저 Network 탭에서 찾아 직접 반복 호출하세요. 페이지를 다시 렌더링하는 것보다 훨씬 싸고, LLM 정리가 필요한 필드만 Gemini에 통과시키면 돼요.
여기선 토큰 비용을 꼭 신경 쓰세요. 페이지가 늘수록 요금도 같이 불어나요. 단순 목록 페이지는 Flash Lite로, 상세 추출이 필요할 때만 Flash로 올리세요.
더 풍부한 데이터를 위한 하위 페이지 스크래핑(코드 방식)
클래식한 2단계 패턴이에요. 1단계에서 목록 페이지의 URL을 모으고, 2단계에서 각 상세 페이지로 들어가 정보를 더 뽑아요.
# 1단계: 저렴한 Flash Lite로 URL 수집
class Listing(BaseModel):
product_urls: list[str]
listing = client.models.generate_content(
model="gemini-2.5-flash-lite",
contents=f"상품 URL을 추출해 주세요:\n{listing_md}",
config=types.GenerateContentConfig(
response_mime_type="application/json",
response_schema=Listing,
),
).parsed
# 2단계: Flash로 상세 정보 추출
class ProductDetail(BaseModel):
name: str
price: str
specs: dict[str, str]
reviews: list[str]
for url in listing.product_urls:
md = fetch_clean(url)
detail = client.models.generate_content(
model="gemini-2.5-flash",
contents=f"상품 상세 정보를 추출해 주세요:\n{md}",
config=types.GenerateContentConfig(
response_mime_type="application/json",
response_schema=ProductDetail,
),
).parsed
# detail 저장...
time.sleep(0.5)
방식 자체는 돌아가요. 다만 붙여야 할 장치가 많아요. URL 중복 제거, 오류 처리, 속도 제한 관리, 재시도 로직, 스키마를 고쳐도 다시 안 가져오게 원본 HTML 캐싱까지요. 50페이지쯤은 감당돼요. 그런데 5,000페이지가 되면 사실상 인프라를 만드는 셈이에요.
노코드 대안: Thunderbit의 내장 페이지네이션 및 하위 페이지 스크래핑
Thunderbit는 클릭 방식과 무한 스크롤 페이지네이션을 자동으로 처리해요. 반복문을 직접 짤 필요가 없죠. 하위 페이지 보강은 "Scrape Subpages" 기능으로 목록에 연결된 각 상세 페이지를 방문해 원본 표에 더 깊은 필드를 채워요. 스크립트 한 줄보다 버튼 한 번이 더 간단해요.
Cloud Scraping 모드는 최대 50페이지를 동시에 처리해서, 상품 카탈로그나 부동산 디렉터리를 대규모로 긁을 때 차이가 커요. Python 루프와 재시도 로직을 직접 관리하고 싶지 않은 분에겐 가장 실용적인 선택이에요. (웹사이트 데이터를 Excel로 스크래핑하는 방법도 별도 가이드로 정리해 뒀어요.)
스크린샷 스크래핑: Gemini의 멀티모달 지름길
대부분 튜토리얼이 통째로 건너뛰는 방식이 하나 있어요. 웹페이지의 스크린샷을 Gemini 비전 API에 보내는 거예요. 원시 HTML 대신 이미지 한 장만 보내는 셈이죠. 한 개발자는 스크린샷 1장이 약 258 토큰밖에 안 든다고 했는데, 이건 정리된 Markdown보다도 쌀 수 있어요. 단순 추출에선 비용 차이가 꽤 나요.
Gemini 비전 API로 웹 스크래핑하는 방법
Playwright로 스크린샷을 찍고, 인코딩한 뒤 Gemini로 보내요.
from playwright.sync_api import sync_playwright
from google import genai
from google.genai import types
from pydantic import BaseModel
class Product(BaseModel):
title: str
price: str
with sync_playwright() as p:
page = p.chromium.launch().new_page()
page.goto("https://example.com/product/widget-pro")
page.wait_for_load_state("networkidle")
png_bytes = page.screenshot(full_page=False) # 화면 상단 영역만
client = genai.Client()
resp = client.models.generate_content(
model="gemini-2.5-flash",
contents=[
{"inline_data": {"mime_type": "image/png", "data": png_bytes}},
"상품 제목과 가격을 JSON으로 추출해 주세요.",
],
config=types.GenerateContentConfig(
response_mime_type="application/json",
response_schema=Product,
),
)
print(resp.parsed)
Google의 이미지 토큰 문서에 따르면, 가로세로 모두 384px 이하인 이미지는 258 토큰이에요. 더 큰 이미지는 768×768 타일로 쪼개지고, 타일 하나당 258 토큰이 들어요. 짧은 상단 화면 스크린샷(258~1,600 토큰)은 원시 HTML보다 훨씬 유리해요. 다만 아주 긴 전체 페이지 스크린샷(~5,000 토큰)은 정리된 Markdown(7651,200 토큰)보다 오히려 비쌀 수 있어요.
스크린샷 스크래핑의 한계
- 밀도 높은 표엔 정밀도가 떨어져요: 여러 열이 겹치거나 글자가 작거나 요소가 포개진 레이아웃은 일부를 놓칠 수 있어요. 환각이라기보다 레이블 누락이나 헤더 정렬 오류에 가까워요.
- 링크를 따라갈 수 없어요: 비전 모델은 클릭 가능한 앵커가 아니라 텍스트를 돌려줘요. 페이지네이션도, 하위 페이지 보강도 안 돼요.
- 해상도 한계: 약 10px보다 작은 텍스트는 자주 잘못 읽혀요. Google은 긴 변을 약 1,568px 정도로 다운샘플링해요.
- 캡처 오버헤드: Playwright 실행 + networkidle 대기만 해도 페이지당 2~5초가 걸려 대규모 작업에선 누적돼요.
스크린샷 스크래핑은 JavaScript가 많은 페이지, 봇 차단 사이트(requests.get()은 403인데 브라우저에선 멀쩡한 경우), 차트나 이미지 안에 데이터가 든 페이지에서 특히 강해요. 반대로 텍스트가 많은 긴 페이지라면 여전히 Markdown이 나아요.
Thunderbit의 이미지 및 PDF 스크래핑도 비슷한 AI 비전 접근을 써요. 이미지를 넣으면 구조화된 표로 바꿔 주고, 스크린샷 스크립트나 base64 작업도 필요 없어요. (이미지를 Excel로 변환하는 방법도 참고해 보세요.)
Gemini 웹 스크래핑이 실패하는 경우와 대안
Gemini는 추출 엔진이지, 가져오기 엔진이 아니에요. 페이지 내용을 Gemini까지 못 가져오면 아무 소용이 없어요. 그게 끝이에요.
이 접근이 통째로 무너지는 대표 상황이 몇 가지 있어요. 대부분 튜토리얼은 이걸 뒷부분에 슬쩍 끼워 넣어요. 저는 더 솔직하게 말씀드릴게요.
| 한계 | 무슨 일이 벌어지는가 | 대응 방법 |
|---|---|---|
| 안티봇 / Cloudflare | API 요청이 차단되고 requests.get()은 403 또는 챌린지 페이지를 반환 | TLS 지문 회전 프록시를 사용하거나 브라우저 기반 도구 사용(Thunderbit의 브라우저 스크래핑은 로그인 세션 활용) |
| 토큰 윈도우 한계 | 큰 페이지가 사용 가능한 컨텍스트를 초과함(기술적으로는 100만 토큰이지만, 안정적인 추출은 약 20만~30만 토큰이 현실적) | HTML→Markdown 정리, 페이지 분할, 또는 스크린샷 사용 |
| 시각 콘텐츠 환각 | Gemini가 실제 이미지 내용 대신 alt 텍스트나 캡션을 추측 | 출력 검증, 이미지 데이터는 비전 API 명시 사용, grounding validator 추가 |
| API 속도 제한 | 대량 처리 시 제한 발생 — 무료 티어는 Pro 약 100 RPD, Flash Lite 약 1,000 RPD | 큐 관리, 배치 처리(50% 할인), 또는 사전 구축 도구 사용 |
| 추출 일관성 부족(Lite 모델) | 선택 필드, 타임스탬프, 중첩 데이터 누락 또는 조작 | Flash/Pro로 업그레이드하거나 명시적 스키마 제약 추가 |
| 보호된 사이트(LinkedIn 등) | 오류 또는 빈 데이터 반환 | 활성 세션을 사용하는 브라우저 기반 스크래핑(Thunderbit 지원), 이용약관 준수 |
이 중 몇 개는 부연이 필요해요.
안티봇은 이제 LLM도 의식해요. Cloudflare는 2025년 7월부터 AI 크롤러를 기본 차단하고 있어요. 첫 5개월 동안 4160억 건의 AI 봇 요청을 막았죠. Datadome도 2025년에 LLM 전용 탐지를 더했고, LLM 봇 트래픽이 4배 늘었다고 밝혔어요. 단순한 requests.get() + Gemini 조합은 Datadome 보호 사이트 앞에선 사실상 끝난 거예요. 문제는 IP가 아니라 지문이에요. TLS 지문이 "Python requests"라고 말하는데 IP만 바꿔 봐야 의미가 없어요.
환각은 미묘해요. 유용하라고 학습된 LLM은 선택 필드를 null로 두기보다 그럴듯한 내용을 지어내는 경향이 있어요. 모델이 URL 슬러그에서 상품 브랜드를 추측하거나, TLD에서 통화를 유추하거나, 스켈레톤 로더를 보고 그럴듯하지만 가짜인 리뷰 수를 써 넣는 경우를 봤어요. 대응 스택은 이래요. 엄격한 Pydantic 스키마, 검증 피드백을 넣은 재시도 루프, 추출값이 실제 원본 HTML에 있는지 확인하는 grounding validator, 그리고 2단계 추출(Flash가 추출하고 Pro가 샘플 검증)이에요.
100만 토큰 컨텍스트 윈도우를 100만 토큰까지 실제로 다 쓸 수 있는 건 아니에요. Chroma의 연구를 비롯한 여러 연구를 보면, 추론 품질은 토큰 한도 한참 전부터 떨어져요. 구조화 추출에선 약 20만~30만 토큰을 실질 상한으로 보는 게 좋아요.
의사결정 트리: 어떤 도구를 써야 할까?
- 작은 규모 + 단순 페이지 + 개발자 → Gemini API 무료 티어 + Python
- 중간 규모 + 복잡한 스키마 + 개발자 → Gemini 2.5 Flash 유료 + Python + 구조화 출력 + 전처리
- 어떤 규모든 + 비개발자 + 로그인 벽/페이지네이션 많음 → Thunderbit
- 매우 큰 규모 + 강한 봇 차단 + 미션 크리티컬 → 관리형 스크래핑 인프라(프록시 서비스) + 추출 계층으로 Gemini
Gemini 웹 스크래핑: 시간과 비용을 아끼는 팁
Python으로 짜든 버튼을 누르든, 아래 팁들은 분명 도움이 돼요.
- Gemini에 보내기 전에 항상 HTML을 Markdown으로 전처리하세요. 보통 5~10배 토큰 절감이 되고, BeautifulSoup로 미리 잘라내면 95% 절감도 가능해요.
google-genai만 쓰세요. deprecated 된google-generativeai패키지는 쓰지 마세요.- Flash Lite는 평면 스키마에서만 시작하세요. 중첩이나 선택 필드가 보이면 곧장 Flash로 올리세요.
- Gemini에 넘기는 Pydantic 스키마에선
Field(default=...)를 피하세요. 대신sku: str | None = None처럼 타입 수준에서 처리하세요. - Pydantic +
response_schema는 핵심 방어선이에요. 계약이자 환각 방지 장치죠. - 1,000페이지가 넘는 작업엔 Batch API를 쓰세요. 50% 할인되고 실시간 RPM에도 영향을 덜 줘요.
- 새 추출기를 대규모로 돌리기 전에 10~50개 행을 직접 샘플링해 검증하세요. 정확도 저하는 직접 보기 전엔 잘 안 보여요.
- 원본 HTML은 디스크에 캐시하세요. 스키마를 조금 고쳤다고 다시 가져올 필요는 없어요.
- 모든 행에 원본 URL을 기록하세요. 전체 작업을 다시 돌리지 않고도 개별 페이지를 재크롤링할 수 있어요.
- 노코드 사용자라면 Thunderbit의 열별 AI 프롬프트를 활용해 프롬프트 엔지니어링을 스프레드시트 레이어로 옮기세요. 번역, 분류, 요약을 열 단위로 처리할 수 있어요.
하나 더 덧붙일게요. 무료 티어를 프로덕션에 그대로 올리면 안 돼요. 2025년 12월에 제한이 50~80% 줄었고, 예고 없이 또 줄 수 있어요.
마무리
단일 URL Gemini 데모와 실제 운영 파이프라인 사이의 거리는 대부분 튜토리얼이 보여주는 것보다 훨씬 멀어요.
Python + Gemini API 경로는 개발자에게 모델 선택, 전처리, 페이지네이션, 스키마 설계를 전부 통제할 권한을 줘요. 반면 Thunderbit 같은 노코드 도구는 비즈니스 사용자가 터미널 안 건드리고도 같은 수준의 구조화 데이터 추출을 할 수 있게 해 줘요.
제가 꼭 전하고 싶은 핵심은 이래요.
- 모델 선택이 중요해요. 대량 처리엔 Flash Lite, 균형은 Flash, 복잡성은 Pro예요. 가장 싼 옵션을 기본값으로 두고 왜 데이터가 틀렸는지 의아해하지 마세요.
- 멀티페이지와 하위 페이지 스크래핑이야말로 튜토리얼이 가장 자주 놓치는 부분이에요. 실제 업무가 벌어지는 지점이죠. 이 글의 두 경로가 그 공백을 메워요.
- 한계를 솔직히 알면 시간을 아껴요. 사이트가 API 요청을 막으면 프롬프트를 아무리 잘 써도 소용없어요. 가장 화려한 도구가 아니라, 작업에 맞는 도구를 고르세요.
- HTML을 Markdown으로 전처리하는 게 효과가 가장 큰 최적화예요. 비용을 75% 이상 줄이고 환각도 낮춰요.
노코드 경로를 시험해 보고 싶다면 Thunderbit 무료 티어로 몇 페이지를 직접 긁어 결과를 확인해 보세요. 코딩이 편하면 Gemini 무료 API 티어만으로도 오후 한나절이면 파이프라인 프로토타입을 만들 수 있어요. 어느 쪽이든 복붙보다 훨씬 빠르게 구조화된 데이터를 얻을 수 있어요. 웹사이트 데이터를 Excel로 추출하는 방법이나 최고의 AI 웹 스크래퍼도 블로그에서 자세히 다뤘어요.
AI 웹 스크래핑용 Thunderbit 사용해 보기 Get Started Free
FAQ
Gemini로 웹 스크래핑하는 데 비용은 얼마나 드나요?
Gemini API는 무료 티어가 있어요. 2026년 초 기준으로 Pro는 하루 약 100회, Flash는 500회, Flash Lite는 1,000회 정도 요청할 수 있어요(이 제한은 2025년 12월에 줄었어요). 유료 티어에선 HTML을 먼저 Markdown으로 전처리한다고 가정할 때, 상품 페이지 10,000개 스크래핑 비용이 Flash Lite 약 $1.50, Flash 약 $6, Pro 약 $25 정도예요. 전처리를 안 하면 비용이 4~5배로 뛰어요. Batch API는 실시간이 아닌 작업에 50% 할인을 줘요.
Gemini로 로그인 필요한 웹사이트도 스크래핑할 수 있나요?
Gemini API 자체는 웹사이트에 로그인하지 못해요. 사용자가 보내는 콘텐츠만 처리할 뿐이죠. 그래서 본인이 인증된 세션으로 HTML을 직접 가져와야 해요(예: 헤드리스 브라우저와 저장된 쿠키 사용). Thunderbit의 Browser Scraping 모드는 이 과정을 기본으로 처리해요. 로그인된 Chrome 탭 안에서 돌아가니까, 브라우저에서 볼 수 있는 사이트라면 Thunderbit가 스크래핑할 수 있어요.
Gemini 웹 스크래핑은 합법인가요?
합법성은 웹사이트 이용약관, 데이터 유형, 관할 지역에 따라 달라요. 미국에선 hiQ v. LinkedIn과 Meta v. Bright Data 이후, 로그인 없이 공개 접근 가능한 데이터를 긁는 건 대체로 허용되는 것으로 봐요. 다만 모든 사례는 사실관계에 따라 달라져요. 로그인 뒤에 있는 데이터를 긁으면 법적 위험이 더 커요. EU 거주자의 개인정보는 공개 사이트인지와 무관하게 개인정보보호법(GDPR) 적용 대상이에요. 항상 robots.txt와 이용약관을 지키고, 법적 근거 없이 개인정보를 스크래핑하지 마세요.
Gemini로 JavaScript가 많은 동적 사이트도 스크래핑할 수 있나요?
가능해요. 다만 먼저 JavaScript를 렌더링해야 해요. 헤드리스 브라우저(Playwright, Puppeteer)를 쓰거나 사이트 API 엔드포인트를 직접 가로채면 돼요. 렌더링된 HTML을 얻고 나면 평소처럼 정리해 Gemini로 보내면 되고요. 또는 Gemini 비전 API로 스크린샷 스크래핑을 쓰면 JS 렌더링을 통째로 건너뛸 수 있어요. 브라우저에 보이는 내용이면 Gemini도 볼 수 있어요. Thunderbit는 Cloud와 Browser 스크래핑 모드 모두에서 JS 렌더링 페이지를 자동 처리해요.
Gemini로 스크래핑하는 것과 Thunderbit 같은 전용 스크래핑 도구를 쓰는 것의 차이는 무엇인가요?
Gemini는 추출 엔진이에요. 콘텐츠를 해석해 구조화된 데이터를 돌려주죠. 웹사이트를 방문하거나, 페이지네이션을 처리하거나, 인증을 관리하거나, 스프레드시트로 내보내는 일을 직접 하진 않아요. 그래서 페이지 내용을 Gemini로 가져오는 도구와, 결과를 활용하는 도구가 따로 필요해요. Thunderbit 같은 전용 도구는 가져오기, 렌더링, AI 추출, 페이지네이션, 하위 페이지 보강, 내보내기를 하나로 묶어 줘요. 별도 연결 작업이 필요 없죠.
더 알아보기
