웹 스크레이핑 작업의 상당 부분은 실제로 스크레이퍼 코드를 작성하기 전에 이루어집니다. 데이터가 어디에 존재하는지, 사이트가 이를 어떻게 노출하는지, 그리고 불필요한 작업을 수행하지 않으면서 필요한 모든 것을 반환할 요청이 무엇인지를 이해해야 하기 때문입니다.
여기서 Zyte MCP가 저에게 가장 유용했습니다. 이 도구는 AI 에이전트에게 Zyte의 도구를 통해 웹사이트에 접근할 수 있게 해주므로, 제가 사이트를 조사하도록 요청하고 효율적으로 스크레이핑하는 방법을 결정하는 데 도움을 받을 수 있습니다. 보통 제 시작점은 간단합니다. “저는 이 사이트에서 이 데이터를 원해요. 가장 좋은 방법은 무엇인가요?”
이를 제대로 답변하려면 에이전트는 실제 웹사이트를 검사해야 하며, 차단되거나, 도전 페이지(challenge page)를 보거나, JavaScript로 로드된 콘텐츠에 도달할 수 없는 경우, 사이트에 대한 그림 자체가 처음부터 불완전합니다. Zyte MCP는 Zyte의 페칭(fetching), 브라우저 렌더링(browser rendering), 그리고 추출(extraction) 도구를 제공하여, 기본적인 HTTP 요청만으로는 충분하지 않은 사이트에서도 페이지를 검색하고 그 뒤에 있는 데이터를 살펴볼 수 있게 합니다. 이후 대화는 실질적인 단계로 진행됩니다. 에이전트는 무엇이 있는지 검토하고, 접근 방식을 시도하며, 제가 작업할 수 있는 증거를 가져옵니다.
제가 먼저 확립하고 싶은 것은 데이터가 어디에서 와야 하는지입니다. 렌더링된 제품 페이지는 당연한 장소이지만, 동일한 정보는 HTML에 있거나 사이트가 사용하는 API에서 올 수도 있습니다. 사이트맵(sitemap)은 제품 URL을 발견하는 간단한 방법을 제공할 수 있으며, 카테고리 페이지는 제가 실제로 원하는 카탈로그 부분으로 크롤링 범위를 좁힐 수 있게 해줍니다. 이러한 선택들은 구현 방식과 실행 비용 모두에 영향을 미칩니다. 왜냐하면 필요한 것을 더 간단한 요청이 반환한다면 모든 페이지를 렌더링하는 것은 낭비이고, 단지 한 가지 카테고리만 원할 때 전체 사이트를 크롤링하는 것도 마찬가지이기 때문입니다. 저는 에이전트를 사용하여 구축하기 전에 이러한 옵션들을 탐색하며, 또한 Zyte API가 해당 도메인을 지원하는지 여부와 그곳에서 HTTP 요청 및 브라우저 요청 비용이 얼마인지 미리 확인할 수 있습니다. 따라서 이 두 가지 사이의 차이는 제가 각 옵션을 비교할 수 있는 기준점이 됩니다.
Three routes leading to the same product card: a rendered page, plain HTML and an API.
하지만 효율성은 데이터 요구 사항과 비교하여 측정되어야 합니다. 왜냐하면 비용 효율적인 요청(cheaper request)이라도 작업에 필요한 정보를 반환해야만 유용하기 때문입니다. 이것이 제가 조사 과정의 일부로 샘플 기록(sample records)과 비교 분석을 요청하는 이유입니다. 만약 에이전트(agent)가 유망한 API를 찾으면, 그 응답이 페이지와 어떻게 비교되는지 알고 싶습니다. 필수 필드를 모두 포함하고 있는지, 일부 세부 정보는 다른 요청에서 오는지, 그리고 해당 경로를 선택할 경우 데이터셋에 공백(gap)이 생기지는 않을지 확인해야 합니다.
첨부 비디오는 이것이 왜 중요한지 보여줍니다. 한 사이트에서 API가 제품 정보에 대한 유용한 경로를 제공하지만, 이를 렌더링된 페이지와 비교해보니 UPC, 무게(weights), 치수(dimensions)를 포함한 누락된 필드가 발견되었습니다. 이러한 발견은 크롤(crawl)의 요구 사항을 변경시킵니다. 비교 과정이 없다면, 제가 필요로 하는 정보를 제외하면서도 기록을 성공적으로 수집하는 스크레이퍼를 만들기 쉬울 것입니다.
Two product cards side by side, the second missing three fields that the first has.
이러한 검사는 또한 절충점(trade-offs)을 명확하게 만듭니다. 때로는 API 응답만으로 충분하고, 때로는 누락된 필드가 추가 요청을 정당화하며, 때로는 제가 필요한 추가 세부 정보가 제품의 하위 집합(subset of products)에 대해서만 필요할 수도 있습니다. 에이전트가 예시를 검색하고 차이점을 조사하게 하는 것은 그러한 결정을 내릴 더 나은 기반을 제공합니다.
저는 이 과정을 저만의 크롤링 전략 스킬(crawl strategy skill)로 기록해 왔으며, 여러분도 진행하면서 자신만의 것을 구축하시기를 권장합니다. 사이트에서 어떤 확인 과정이 유용하다는 것이 입증될 때마다 추가하세요. 사이트맵을 찾고, 대체 데이터 소스를 조사하며, 샘플을 검색하고, 접근 방식을 추천하기 전에 필드 커버리지를 비교하는 식입니다. 이는 한 조사 경험을 다음 조사에 이어가게 하며, 에이전트에게 반복 가능한 프로세스를 제공하면서도 사용자가 원하는 사이트와 데이터에 적응할 수 있게 합니다. 또한 첫 시도가 실패하거나 샘플에서 예상치 못한 것이 발견되었을 때 가정을 재검토하기가 더 쉬워집니다.
제가 원하는 결과물은 실행 가능한 크롤링 계획입니다. 즉, 관련 레코드를 어떻게 발견할지, 어떤 요청(request)을 해야 할지, 그 요청들이 어떤 필드들을 반환하는지, 그리고 추가적인 확인이나 요청이 필요한 부분이 어디인지를 파악하는 것입니다. 이를 바탕으로 저는 해당 작업에 적합한 Scrapy spider나 다른 스크레이퍼를 구축할 수 있으며, 조사가 같은 대화 내에서 이루어졌기 때문에 에이전트는 이미 그 결정들 뒤에 숨겨진 맥락(context)을 가지고 있습니다. 만약 제가 작업을 다른 곳으로 옮긴다면, 전략과 요구 사항을 문서로 작성해 달라고 요청할 수 있습니다.
바로 이 지점에서 MCP가 제 워크플로우에 가장 자연스럽게 들어맞습니다. 저는 데이터를 대규모로 수집하는 코드(code)를 확정하기 전에 사이트를 탐색하고, 샘플링하며, 이해하는 데 MCP를 사용합니다. MCP가 스파이더 자체를 작성해 주지는 않습니다. 왜냐하면 parse() 메서드와 페이지네이션(pagination)은 여전히 제가 구축해야 할 부분이기 때문입니다. 그리고 MCP가 대체하는 것은 이전에 수동으로 하던 작업들, 즉 브라우저에서 사이트를 열고 무엇이 작동하지 않는지 만져보거나 필요한 필드를 위해 원시 HTML을 읽는 과정 등입니다.
직접 사용해 보려면, 원하는 사이트와 필드부터 시작한 다음, 에이전트에게 이용 가능한 경로를 조사하고, 샘플을 반환하며, 추천된 접근 방식이 무엇을 놓칠 수 있는지 확인하도록 요청하세요. 설정 지침은 Zyte MCP 문서에 있습니다.
원래는 Zyte 블로그에 게시되었습니다.
