레스토랑 메뉴 및 배달 가격 파싱: 가이드

```html

Yandex.Eda, Delivery Club, SberMarket 및 수십 개의 지역 배달 집계기는 마케팅 담당자, 분석가 및 레스토랑 사업자에게 데이터의 진정한 금광입니다. 가격과 메뉴 항목을 체계적으로 수집하기 시작하면 서비스가 요청을 차단하기 시작합니다. 이 기사에서는 메뉴 및 배달 가격 파싱을 올바르게 조직하는 방법, 사용할 도구 및 프록시가 차단을 피하는 데 어떻게 도움이 되는지에 대해 설명합니다.

레스토랑 메뉴 및 배달 가격을 파싱하는 이유

러시아의 음식 배달 시장은 전자 상거래에서 가장 역동적인 세그먼트 중 하나입니다. 요리의 가격, 메뉴 구성 및 배달 조건은 매일 바뀝니다. 수십 개의 경쟁자나 수백 개의 항목에 대해 이러한 변화를 수동으로 추적하는 것은 불가능합니다. 바로 여기서 자동 데이터 수집이 필요합니다.

다음은 메뉴 및 가격 파싱을 실제로 사용하는 사람들입니다:

레스토랑 및 카페 소유자 — 자신의 지역에서 경쟁업체의 가격을 추적하여 신속하게 가격 책정을 조정합니다.
레스토랑 체인 마케팅 담당자 — 경쟁업체가 프로모션 및 특별 제안을 통해 어떤 메뉴 항목을 홍보하는지 분석합니다.
HoReCa 시장 분석가 — 다양한 도시 및 지역의 요리 카테고리에 대한 평균 가격 보고서를 작성합니다.
스타트업 집계기 — 자신의 카탈로그를 위해 메뉴 및 가격이 포함된 레스토랑 데이터베이스를 수집합니다.
투자자 및 컨설턴트 — 새로운 시설이나 프랜차이즈를 열기 전에 경쟁 환경을 평가합니다.
애플리케이션 개발자 — 칼로리 계산 또는 식단 계획 애플리케이션을 위한 요리 데이터베이스를 형성합니다.

레스토랑 비즈니스에 종사하거나 분석을 하고 있다면, 경쟁업체의 가격을 정기적으로 모니터링하는 것은 사치가 아니라 필수입니다. 인기 있는 요리에서 30-50 루블의 차이는 주문 전환에 직접적인 영향을 미칠 수 있습니다. 자동화 없이는 이미 데이터 수집을 설정한 사람들보다 항상 한 발 뒤처지게 됩니다.

배달 집계기에서 수집하는 데이터

파서를 설정하기 전에 어떤 데이터가 필요한지 이해하는 것이 중요합니다. 배달 집계기에는 여러 계층의 정보가 포함되어 있으며, 각 계층은 다양한 작업에 유용합니다.

데이터 유형	포함된 내용	누구에게 유용한가
메뉴 및 항목	요리 이름, 설명, 구성, 중량, 칼로리	애플리케이션 개발자, 영양사
요리 가격	현재 가격, 할인 가격, 변경 이력	레스토랑 소유자, 마케팅 담당자
배달 조건	배달 비용, 최소 주문 금액, 배달 시간	분석가, 스타트업
프로모션 및 특별 제안	할인, 콤보, 프로모션 요리, 계절 제안	마케팅 담당자, 경쟁 정보
평가 및 리뷰	업소 평가, 리뷰 수, 품질 태그	투자자, 컨설턴트
지리 데이터	주소, 배달 지역, 존재 지역	시장 분석가, 프랜차이즈

가격 모니터링의 동적 변화는 특히 가치가 있습니다: 몇 개월 동안 하루에 한 번 데이터를 수집하면 경쟁업체의 가격 책정 패턴을 볼 수 있습니다 — 그들이 가격을 인상하는 시점, 프로모션을 시작하는 시점, 외부 이벤트(휴일, 스포츠 행사, 악천후)에 어떻게 반응하는지.

Yandex.Eda, Delivery Club 및 기타 집계기의 보호 기능

대규모 배달 집계기는 자동 데이터 수집으로부터 자신의 데이터를 적극적으로 보호합니다. 이는 이해할 수 있습니다: 그들의 레스토랑 데이터베이스와 현재 가격은 그들의 경쟁 우위입니다. 파서를 설정하기 전에 어떤 보호 기능에 직면할 것인지 이해해야 합니다.

Yandex.Eda

여러 보호 수준을 동시에 사용합니다. 첫째, 지리적 위치 기반 서비스가 적극적으로 사용됩니다: 메뉴 콘텐츠와 가격은 귀하의 IP 주소에 따라 표시됩니다 — 모스크바의 IP에서 접속하면 모스크바 레스토랑이 보입니다. 둘째, 사이트는 React로 구축된 SPA(Single Page Application)로 작동하므로 데이터는 HTML에 내장되지 않고 API 요청을 통해 로드됩니다. 셋째, 의심스러운 활동이 감지되면 Yandex SmartCaptcha가 활성화됩니다. 동일한 IP에서 자주 요청하면 사이트에 접근할 수 없게 됩니다.

Delivery Club (SberMarket)

유사한 아키텍처: 데이터는 정적 HTML이 아닌 내부 API를 통해 제공됩니다. 서비스는 행동 패턴을 분석합니다: 요청이 너무 빠르거나 간격 없이 진행되면 차단됩니다. 또한 User-Agent 및 요청 헤더 분석이 사용됩니다. 비표준 헤더는 즉시 의심을 불러일으킵니다.

지역 집계기

Chibbis, Goloso와 같은 서비스 및 지역의 로컬 집계기는 일반적으로 더 약한 보호를 가지고 있습니다. 그들 중 일부는 표준 도구로 파싱할 수 있는 간단한 HTML 페이지를 사용합니다. 그러나 여기서도 자주 요청할 경우 IP 차단은 일반적인 관행입니다.

배달 집계기에서 파서를 차단하는 주요 메커니즘:

요청 한도를 초과할 경우 IP 차단 (rate limiting)
지리적 차단 — 서로 다른 IP에 대해 서로 다른 콘텐츠 표시
User-Agent 및 HTTP 헤더 분석
의심스러운 활동 시 CAPTCHA
JavaScript 데이터 렌더링 (SPA 아키텍처)
행동 분석: 클릭 속도, 스크롤, 대기 시간

코드 없는 파싱 도구 및 코드가 있는 도구

좋은 소식은 레스토랑 메뉴를 파싱하는 데 프로그래밍 기술이 필요하지 않다는 것입니다. 대부분의 작업을 처리할 수 있는 준비된 no-code 솔루션이 있습니다. 그러나 Yandex.Eda와 같은 SPA 사이트에서 작업하려면 더 강력한 도구가 필요합니다.

코드 없는 도구 (프로그래밍 없음)

Octoparse — 가장 인기 있는 비주얼 파서 중 하나입니다. 페이지의 요소를 클릭하고 코드를 작성하지 않고 데이터 수집 시나리오를 구축할 수 있습니다. IP 회전이 포함된 클라우드 모드가 있습니다. 구조가 간단한 사이트에서 메뉴 수집에 적합합니다.

ParseHub — 비슷한 비주얼 인터페이스를 가진 도구입니다. JavaScript 페이지에서 작업할 수 있어 현대 집계기에 적용 가능합니다. 프록시 지원이 있습니다.

Apify — 인기 있는 사이트에 대한 준비된 "액터"(준비된 파서)가 있는 플랫폼입니다. 일부 배달 집계기에 대한 준비된 솔루션이 마켓플레이스에 이미 있습니다. 코드를 작성하지 않고 웹 인터페이스를 통해 실행할 수 있습니다.

코드가 있는 도구 (개발자를 위한)

Python + Requests + BeautifulSoup — 정적 페이지 파싱을 위한 고전적인 조합입니다. 빠르고 간단하지만 JavaScript 렌더링을 처리하지 못합니다.

Python + Selenium 또는 Playwright — 실제 브라우저(Chrome/Firefox)를 제어하므로 SPA 사이트, JavaScript 및 일부 CAPTCHA를 처리할 수 있습니다. Playwright는 더 현대적이고 빠른 솔루션으로 간주됩니다. 이 조합이 Yandex.Eda 및 Delivery Club에서 작동합니다.

Scrapy — 대규모 파싱을 위한 전문 Python 프레임워크입니다. 요청 큐, 프록시용 미들웨어, 다양한 형식으로의 내보내기를 지원합니다. 레스토랑 데이터 수집을 위한 대규모 프로젝트에 최적의 선택입니다.

도구	코드 필요?	JS 렌더링	프록시	적합한 용도
Octoparse	아니오	부분적	내장 회전	지역 집계기
ParseHub	아니오	예	외부 프록시	대부분의 집계기
Apify	아니오	예	내장 + 외부	Yandex.Eda, Delivery Club
Selenium/Playwright	예 (Python)	예	외부 프록시	모든 사이트
Scrapy	예 (Python)	플러그인을 통해	외부 프록시	대규모 데이터 수집

프록시 없이 파싱이 작동하지 않는 이유

이것은 핵심 질문입니다. 많은 초보 분석가들이 자신의 IP에서 직접 파서를 실행해 보려고 하지만 즉시 차단에 직면합니다. 이유는 간단합니다: 배달 집계기는 짧은 시간에 동일한 주소에서 수백 개의 요청을 감지하고 자동으로 차단합니다. 접근 복구는 몇 시간에서 며칠까지 걸릴 수 있습니다.

프록시는 요청을 여러 다른 IP 주소로 분산시켜 이 문제를 해결합니다. 서버 관점에서 요청은 서로 다른 장소의 다양한 사용자로부터 오는 일반 트래픽처럼 보입니다. 그러나 모든 프록시가 이 작업에 동일하게 효과적인 것은 아닙니다.

주거용 프록시

주거용 프록시는 실제 가정 사용자의 IP 주소를 사용합니다. Yandex.Eda 또는 Delivery Club 관점에서 이는 레스토랑 메뉴를 보러 온 일반 사용자입니다. 이러한 프록시는 올바르게 사용하면 거의 차단되지 않습니다. 강력한 보호가 있는 대규모 집계기에서 데이터를 수집하는 데 이상적인 선택입니다.

모바일 프록시

모바일 프록시는 이동통신 사업자의 IP 주소(MTS, Beeline, MegaFon 등)입니다. 이들의 특징은 하나의 모바일 IP가 수천 명의 실제 사용자에 의해 동시에 사용될 수 있다는 것입니다(NAT를 통해), 따라서 사이트는 모바일 주소를 차단하는 경우가 매우 드뭅니다. 이는 높은 빈도로 요청할 때 가장 신뢰할 수 있는 옵션 중 하나입니다.

데이터 센터 프록시

데이터 센터 프록시는 가장 빠르고 저렴하지만 그들의 IP는 "비인간적"으로 쉽게 식별됩니다. 지역 집계기에서 간단한 보호가 있는 경우에는 적합하지만 Yandex.Eda 및 Delivery Club에서는 비교적 빠르게 차단됩니다. 그럼에도 불구하고 데이터 센터 프록시는 사이트 구조를 탐색하고 파서를 실제로 실행하기 전에 테스트하는 데 잘 작동합니다.

메뉴 파싱을 위한 프록시 유형 선택:

Yandex.Eda, Delivery Club → 주거용 또는 모바일 프록시
지역 집계기 (Chibbis 등) → 데이터 센터 프록시 또는 주거용 프록시
전국 데이터 수집 (다양한 도시) → 도시별 지리 타겟팅이 가능한 주거용 프록시
고빈도 모니터링 (매시간) → 회전하는 모바일 프록시

프록시와 함께 파서 설정 단계별 가이드

실용적인 시나리오를 살펴보겠습니다: Yandex.Eda에서 귀하의 도시의 20개 경쟁업체의 피자 가격을 매일 수집하고 싶습니다. 다음은 단계별로 설정하는 방법입니다.

1단계. 집계기 API 구조 연구

브라우저에서 Yandex.Eda를 열고 F12(DevTools)를 누른 다음 네트워크 탭으로 이동하여 요청을 XHR/Fetch로 필터링합니다. 레스토랑 페이지를 찾아 메뉴 로드 시 어떤 API 요청이 전송되는지 확인합니다. 일반적으로 api/v1/menu?restaurantId=...와 같은 형식입니다. 이러한 요청의 헤더를 기록해 두십시오 — 나중에 모방하는 데 필요합니다.

2단계. 도구 선택

코드를 작성하지 않는 경우 — Apify 또는 ParseHub를 사용하십시오. Python으로 코드를 작성하는 경우 — JavaScript 사이트에서 작업하기 위해 Playwright가 최적의 선택이 될 것입니다. 필요한 도구를 설치하고 외부 프록시 연결을 지원하는지 확인하십시오.

3단계. 지리 타겟팅이 가능한 프록시 확보

이는 중요한 사항입니다. Yandex.Eda는 도시별로 다른 레스토랑을 표시합니다. 예카테린부르크의 레스토랑 메뉴를 파싱하는 경우 — 예카테린부르크의 IP를 가진 프록시가 필요합니다. 도시별 지리 타겟팅이 가능한 주거용 프록시는 지역 사용자가 보는 콘텐츠를 정확하게 수집할 수 있게 해줍니다. 프록시 설정 시 필요한 지역을 지정하십시오.

4단계. 프록시 회전 설정

모든 요청에 대해 하나의 프록시를 사용하지 마십시오. 회전을 설정하십시오: 5-10 요청마다 IP를 변경하십시오. Apify에서는 프록시 풀 설정을 통해 이루어집니다. Scrapy에서는 미들웨어를 통해, Playwright에서는 브라우저 컨텍스트를 생성할 때마다 새로운 프록시를 전달하여 이루어집니다. IP가 자주 변경될수록 차단 위험이 낮아집니다.

5단계. 요청 간 지연 설정

요청 간에 2초에서 8초 사이의 무작위 대기 시간을 추가하십시오. 이는 실제 사용자 행동을 모방합니다. 1초 미만의 간격으로 요청하지 마십시오 — 이는 차단의 확실한 경로입니다. Scrapy에서는 DOWNLOAD_DELAY 매개변수를 사용하고 AUTOTHROTTLE_ENABLED를 활성화하십시오.

6단계. 요청 헤더 설정

항상 현실적인 User-Agent(브라우저 문자열), Accept-Language 헤더(예: ru-RU,ru;q=0.9) 및 Referer를 전달하십시오. 이러한 헤더 없이 요청하면 봇처럼 보이며 가장 먼저 차단됩니다. Chrome 또는 Firefox의 최신 User-Agent 문자열을 사용하십시오.

7단계. 일정 및 데이터 저장 설정

파서를 야간(오후 2시에서 6시 사이)에 실행하십시오 — 집계기 서버에 대한 부하가 최소화되고 의심스러운 트래픽이 덜 눈에 띕니다. 데이터를 데이터베이스(PostgreSQL, MySQL) 또는 최소한 타임스탬프가 있는 CSV 파일에 저장하십시오. 이는 가격 변동 이력을 구축하는 데 도움이 됩니다.

# Playwright에서 프록시 설정 예제 (Python)
from playwright.sync_api import sync_playwright
import random
import time

proxies = [
    {"server": "http://proxy1.example.com:8080", "username": "user", "password": "pass"},
    {"server": "http://proxy2.example.com:8080", "username": "user", "password": "pass"},
    # ... 더 많은 프록시
]

def parse_restaurant_menu(url):
    proxy = random.choice(proxies)
    
    with sync_playwright() as p:
        browser = p.chromium.launch()
        context = browser.new_context(
            proxy=proxy,
            user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
        )
        page = context.new_page()
        
        # 무작위 지연 2-8초
        time.sleep(random.uniform(2, 8))
        
        page.goto(url)
        page.wait_for_selector('.menu-item')  # 메뉴 로드 대기
        
        # 요리 데이터 수집
        items = page.query_selector_all('.menu-item')
        menu_data = []
        for item in items:
            name = item.query_selector('.item-name').inner_text()
            price = item.query_selector('.item-price').inner_text()
            menu_data.append({'name': name, 'price': price})
        
        browser.close()
        return menu_data

일반적인 실수 및 피하는 방법

도구를 올바르게 설정하더라도 많은 사람들이 음식 배달 데이터 파싱 시 문제에 직면합니다. 다음은 가장 일반적인 실수와 이를 해결하는 방법입니다.

실수 1: 모든 요청에 대해 하나의 프록시 사용

가장 품질이 좋은 주거용 프록시라도 하루에 동일한 사이트에 수백 개의 요청이 들어오면 차단됩니다. 항상 최소 10-20개의 프록시 풀을 사용하고 회전을 설정하십시오. 파싱하는 레스토랑 수가 많을수록 더 많은 프록시가 필요합니다.

실수 2: 지리 타겟팅 무시

Yandex.Eda 및 Delivery Club은 사용자 도시별로 다른 콘텐츠를 표시합니다. 노보시비르스크의 레스토랑 데이터를 수집하려는 경우 모스크바 프록시를 사용하면 모스크바 데이터를 받게 됩니다. 항상 프록시가 필요한 지역과 일치하는지 확인하십시오.

실수 3: HTML 파싱 대신 API 사용

초보 파서들은 페이지의 HTML 코드에서 데이터를 수집하려고 합니다. 그러나 SPA 사이트(즉, Yandex.Eda)에서는 데이터가 HTML에 내장되어 있지 않고 API를 통해 로드됩니다. DevTools를 통해 필요한 API 엔드포인트를 찾아 직접 요청하는 것이 훨씬 효율적입니다. 이는 더 빠르고 안정적이며 리소스를 덜 소모합니다.

실수 4: 너무 높은 요청 빈도

데이터를 더 빨리 수집하려는 욕망은 이해할 수 있지만, 이는 즉각적인 차단으로 이어집니다. 50개 레스토랑의 가격을 매일 모니터링하려면 하루에 한 번 파서를 실행하고 요청 간에 3-5초의 대기 시간을 두는 것으로 충분합니다. 지연 시간을 줄여서 프로세스를 가속화하려고 하지 마십시오.

실수 5: 프록시 작동 여부 모니터링 부족

프록시는 "죽을" 수 있습니다 — 차단되거나 만료됩니다. 파서가 차단된 프록시로 계속 작동하면 빈 데이터나 오류가 발생하고 문제를 인식하지 못하게 됩니다. 각 실행 전에 프록시의 작동 여부를 확인하고 작동하지 않는 주소를 자동으로 교체하도록 설정하십시오.

실수 6: 사이트 구조 변경 무시

집계기는 정기적으로 사이트와 API를 업데이트합니다. 한 달 전에 작동했던 파서는 다음 업데이트 후 작동을 멈출 수 있습니다. 오류 알림을 설정하고 최소한 주 1회 파서의 작동 여부를 확인하십시오. 수집하는 데이터 구조에 대한 문서를 항상 준비해 두십시오.

레스토랑 메뉴 파서를 실행하기 전 체크리스트:

✅ 10개 이상의 프록시 풀 설정 및 회전
✅ 프록시가 필요한 도시/지역에 적합
✅ 요청 간 지연 3-8초 (무작위)
✅ 현실적인 User-Agent 설정
✅ Accept-Language 및 Referer 헤더 추가
✅ 타임스탬프가 있는 데이터 저장 설정
✅ 오류 모니터링 및 알림 활성화
✅ 야간 시간에 실행 계획

결론

레스토랑 메뉴 및 배달 가격 파싱은 레스토랑 비즈니스 및 HoReCa 시장 분석에서 경쟁 우위를 제공하는 실제 도구입니다. Yandex.Eda, Delivery Club 및 기타 집계기는 자신의 데이터를 적극적으로 보호하지만, 올바른 접근 방식 — 도구의 현명한 선택, 지연 설정 및 품질 높은 프록시 사용 — 을 통해 데이터 수집이 안정적으로 작동하고 차단 없이 진행될 수 있습니다.

이 기사의 주요 결론: JavaScript 렌더링을 지원하는 도구(Playwright, Apify)를 사용하고, 프록시 회전을 설정하며, 지리 타겟팅을 잊지 말고 요청 간에 무작위 지연을 항상 추가하십시오. 이는 안정적인 파싱의 세 가지 기둥입니다.

Yandex.Eda, Delivery Club 또는 지역 배달 집계기에서 데이터를 정기적으로 수집할 계획이라면 주거용 프록시에 주목하는 것이 좋습니다 — 이는 차단에 대한 최대 저항력을 제공하고 러시아 도시별 지리 타겟팅을 지원하여 특정 지역의 가격 데이터를 정확하게 수집하는 데 매우 중요합니다.