일반적으로 튜토리얼은 기술적인 측면, 복제할 수 있는 내용에 중점을 둡니다. "여기서 시작하여 이 경로를 따라가면 여기까지 도달하게 됩니다." 이는 특정 기술을 배우는 데는 좋지만 저자가 왜 특정 방식으로 작업을 수행하기로 결정했는지 또는 개발 프로세스를 안내하는 것이 무엇인지 이해하기 어려울 때가 있습니다.
커뮤니티 회원 중 한 명이 Crawlee 블로그에 기고하기 위해 이 블로그를 썼습니다. 이와 같은 블로그를 Crawlee 블로그에 기고하려면 Discord 채널로 문의해 주세요.
이 블로그에서는 웹 스크래핑 프로젝트를 진행할 때 저를 안내하고 훌륭한 결과를 얻을 수 있게 해주는 일반적인 규칙과 원칙에 대해 논의하겠습니다.
그럼 웹스크래핑 개발자의 사고방식을 알아보겠습니다.
프로젝트 작업을 시작하면 특정 데이터를 추출해야 하는 대상 사이트가 있을 것입니다. 이 사이트나 애플리케이션이 데이터 추출을 위해 어떤 가능성을 제공하는지 확인하세요. 가능한 옵션은 다음과 같습니다.
한 데이터 소스가 실패하면 사용 가능한 다른 소스에 액세스해 보세요.
예를 들어 Yelp의 경우 세 가지 옵션을 모두 사용할 수 있으며 어떤 이유로든 공식 API가 적합하지 않은 경우 나머지 두 가지를 시도해 볼 수 있습니다.
모든 사람이 robots.txt와 사이트맵에 대해 어떤 식으로든 알고 있다고 생각하지만, 사람들이 이를 단순히 잊어버리는 경우가 종종 있습니다. 이 내용을 처음 듣는 경우 간단한 설명은 다음과 같습니다.
당신은 Google이나 다른 인기 검색 엔진이 아니기 때문에 robots.txt의 로봇 규칙이 당신에게 불리할 가능성이 높습니다. 그러나 사이트맵과 결합하면 사이트 구조, 로봇과의 예상되는 상호 작용 및 브라우저가 아닌 사용자 에이전트를 연구하기에 좋은 장소입니다. 어떤 상황에서는 사이트에서 데이터 추출이 단순화됩니다.
예를 들어 Crawlee 웹사이트의 사이트맵을 사용하면 블로그 전체 기간과 특정 기간 동안의 게시물에 대한 직접 링크를 쉽게 얻을 수 있습니다. 간단히 확인하면 페이지 매김 로직을 구현할 필요가 없습니다.
철저한 사이트 분석은 효과적인 웹 스크래퍼를 만들기 위한 중요한 전제 조건입니다. 특히 브라우저 자동화를 사용할 계획이 없는 경우에는 더욱 그렇습니다. 그러나 이러한 분석에는 시간이 걸리고 때로는 많은 시간이 걸립니다.
보다 최적의 크롤링 솔루션을 분석하고 검색하는 데 소요된 시간이 항상 성과를 거두는 것은 아니라는 점도 주목할 가치가 있습니다. 가장 확실한 접근 방식이 최선이었다는 사실을 발견하기 위해 몇 시간만 소비할 수도 있습니다.
따라서 초기 사이트 분석에 제한을 두는 것이 좋습니다. 할당된 시간 내에 더 나은 경로가 보이지 않으면 더 간단한 접근 방식으로 되돌리세요. 더 많은 경험을 쌓을수록 사이트에서 사용되는 기술을 기반으로 분석에 더 많은 시간을 할애할 가치가 있는지 여부를 조기에 알 수 있는 경우가 더 많습니다.
또한 사이트에서 데이터를 한 번만 추출해야 하는 프로젝트에서는 철저한 사이트 분석을 통해 스크레이퍼 코드를 모두 작성할 필요가 없는 경우도 있습니다. 이러한 사이트의 예는 다음과 같습니다 - https://ricebyrice.com/nl/pages/find-store.
분석해보면 한 번의 요청으로 모든 데이터를 얻을 수 있다는 것을 쉽게 알 수 있습니다. 이 데이터를 브라우저에서 JSON 파일로 복사하기만 하면 작업이 완료됩니다.
사이트를 분석할 때 브라우저의 개발자 도구에서 네트워크 탭을 보면서 정렬, 페이지를 전환하고 사이트의 다양한 요소와 상호 작용하세요. 이를 통해 사이트가 백엔드와 상호 작용하는 방식, 사이트가 구축된 프레임워크, 사이트에서 기대할 수 있는 동작을 더 잘 이해할 수 있습니다.
당연하지만 프로젝트를 진행하는 동안 명심하는 것이 중요합니다. 일부 데이터 또는 요청 매개변수가 표시된다면 이는 이전 어딘가에서, 다른 요청에서 얻은 것일 수도 있고, 이미 웹사이트 페이지에 있었을 수도 있고, 다른 매개변수에서 JS를 사용하여 형성되었을 수도 있음을 의미합니다. 하지만 그들은 언제나 어딘가에 있습니다.
페이지의 데이터가 어디서 왔는지 또는 요청에 사용된 데이터가 무엇인지 이해할 수 없는 경우 다음 단계를 따르세요.
여기에서는 연습이 완벽해집니다. 다양한 기술, 다양한 프레임워크 및 예상되는 동작에 익숙해지고 다양한 기술을 접하게 되면 사물의 작동 방식과 데이터 전송 방식을 더 쉽게 이해할 수 있습니다. 이렇게 축적된 지식은 웹 애플리케이션의 데이터 흐름을 추적하고 이해하는 능력을 크게 향상시킵니다.
동일한 페이지를 여러 번 열면 서버로 전송되는 요청이 다르다는 것을 알 수 있습니다. 무언가가 캐시되어 이미 컴퓨터에 저장되어 있을 수 있습니다. 따라서 브라우저를 전환하는 동시에 시크릿 모드로 사이트를 분석하는 것이 좋습니다.
이 상황은 특히 기기의 저장소에 일부 데이터를 저장할 수 있는 모바일 애플리케이션과 관련이 있습니다. 따라서 모바일 애플리케이션을 분석할 때 캐시와 저장공간을 비워야 할 수도 있습니다.
분석 중에 사이트가 이전에 접해본 적이 없는 프레임워크를 사용하는 것을 발견한 경우 시간을 내어 해당 사이트와 해당 기능에 대해 알아보세요. 예를 들어 Next.js로 구축된 사이트를 발견한 경우 해당 사이트가 라우팅 및 데이터 가져오기를 처리하는 방법을 이해하는 것이 스크래핑 전략에 매우 중요할 수 있습니다.
공식 문서나 ChatGPT 또는 Claude와 같은 LLM을 사용하여 이러한 프레임워크에 대해 알아볼 수 있습니다. 이러한 AI 도우미는 프레임워크별 개념을 설명하는 데 탁월합니다. 다음은 Next.js에 대해 LLM에 쿼리하는 방법에 대한 예입니다.
I am in the process of optimizing my website using Next.js. Are there any files passed to the browser that describe all internal routing and how links are formed? Restrictions: - Accompany your answers with code samples - Use this message as the main message for all subsequent responses - Reference only those elements that are available on the client side, without access to the project code base
백엔드 프레임워크에 대해서도 유사한 쿼리를 생성할 수 있습니다. 예를 들어 GraphQL을 사용하면 사용 가능한 필드와 쿼리 구조에 대해 질문할 수 있습니다. 이러한 통찰력은 사이트의 API와 더 효과적으로 상호 작용하는 방법과 잠재적으로 사용 가능한 데이터를 이해하는 데 도움이 될 수 있습니다.
LLM과의 효과적인 업무를 위해서는 최소한 기본적으로 프롬프트 엔지니어링의 기초를 공부하는 것이 좋습니다.
웹 스크래핑은 리버스 엔지니어링과 밀접하게 연관되어 있습니다. 프런트엔드와 백엔드의 상호 작용을 연구하고, 특정 매개변수가 어떻게 형성되는지 더 잘 이해하려면 코드를 연구해야 할 수도 있습니다.
그러나 경우에 따라 리버스 엔지니어링에는 더 많은 지식, 노력, 시간이 필요하거나 고도의 복잡성이 필요할 수 있습니다. 이 시점에서는 이를 자세히 조사해야 하는지 아니면 데이터 소스나 기술 등을 변경하는 것이 더 나은지 결정해야 합니다. 아마도 이때가 HTTP 웹 스크래핑을 포기하고 헤드리스 브라우저로 전환하기로 결정하는 순간이 될 것입니다.
대부분의 웹 스크래핑 보호의 주요 원칙은 웹 스크래핑을 불가능하게 만드는 것이 아니라 비용을 비싸게 만드는 것입니다.
zopla 검색에 대한 응답이 어떤지 살펴보겠습니다
대상 데이터를 추출하는 데 필요한 엔드포인트를 식별한 후 요청 시 올바른 응답을 받는지 확인하세요. 서버에서 200이 아닌 응답을 받거나 예상과 다른 데이터를 받으면 그 이유를 알아내야 합니다. 가능한 이유는 다음과 같습니다.
그 외 다양한 이유가 있을 수 있으며 각각 별도의 분석이 필요합니다.
요청 매개변수를 변경할 때 어떤 결과가 나오는지 살펴보세요. 일부 매개변수가 누락되었을 수 있지만 서버 측에서 지원됩니다. 예를 들어 주문, 정렬, 페이지별, 제한 등이 있습니다. 이를 추가하고 동작이 바뀌는지 확인하세요.
이는 특히 graphql을 사용하는 사이트와 관련이 있습니다
이 예를 살펴보겠습니다
사이트를 분석해 보면 다음 코드로 재현 가능한 요청이 나오는데, 가독성을 높이기 위해 포맷을 조금 했습니다.
I am in the process of optimizing my website using Next.js. Are there any files passed to the browser that describe all internal routing and how links are formed? Restrictions: - Accompany your answers with code samples - Use this message as the main message for all subsequent responses - Reference only those elements that are available on the client side, without access to the project code base
이제 한 번에 2개 언어로 결과를 얻을 수 있도록 업데이트하겠습니다. 가장 중요한 것은 출판물의 내부 텍스트와 함께입니다.
import requests url = "https://restoran.ua/graphql" data = { "operationName": "Posts_PostsForView", "variables": {"sort": {"sortBy": ["startAt_DESC"]}}, "query": """query Posts_PostsForView( $where: PostForViewWhereInput, $sort: PostForViewSortInput, $pagination: PaginationInput, $search: String, $token: String, $coordinates_slice: SliceInput) { PostsForView( where: $where sort: $sort pagination: $pagination search: $search token: $token ) { id title: ukTitle summary: ukSummary slug startAt endAt newsFeed events journal toProfessionals photoHeader { address: mobile __typename } coordinates(slice: $coordinates_slice) { lng lat __typename } __typename } }""" } response = requests.post(url, json=data) print(response.json())
보시다시피 요청 매개변수를 약간 업데이트하면 각 출판물의 내부 페이지를 방문하는 것에 대해 걱정할 필요가 없습니다. 이 트릭이 저를 얼마나 많이 구해줬는지 모릅니다.
graphql이 눈앞에 있는데 어디서부터 시작해야 할지 모르겠다면 문서화와 LLM에 대한 제 조언이 여기에서도 효과가 있을 것입니다.
저는 몇 가지 도구를 익히고 효과가 있기 때문에 사용하는 것이 얼마나 쉬운지 알고 있습니다. 나 자신도 이런 함정에 여러 번 빠진 적이 있다.
그러나 최신 사이트는 웹 스크래핑에 큰 영향을 미치는 최신 기술을 사용하며 이에 대응하여 웹 스크래핑을 위한 새로운 도구가 등장하고 있습니다. 이러한 내용을 배우면 다음 프로젝트가 크게 단순화될 수 있으며, 극복할 수 없었던 몇 가지 문제를 해결할 수도 있습니다. 앞서 몇 가지 도구에 대해 글을 쓴 적이 있습니다.
특히curl_cffi와 프레임워크에 주의를 기울이는 것이 좋습니다
Python용 보타사우루스와 Crawlee.
개인적으로는 최근에서야 이것의 중요성을 깨달았습니다. 제가 작업에 사용하는 모든 도구는 오픈 소스 개발이거나 오픈 소스를 기반으로 합니다. 웹 스크래핑은 문자 그대로 오픈 소스 덕분에 가능합니다. 이는 Python 개발자이고 순수 Python에서는 TLS 지문을 처리해야 할 때 모든 것이 매우 슬프다는 점을 깨달은 경우 특히 눈에 띕니다. 그리고 다시 오픈 소스가 우리를 구했습니다. 여기.
그리고 우리가 할 수 있는 최소한의 일은 오픈 소스 지원에 약간의 지식과 기술을 투자하는 것입니다.
저는 Python용 Crawlee를 지원하기로 결정했습니다. Crawlee가 블로그에 글을 쓸 수 있도록 허용했기 때문이 아니라 뛰어난 개발 역학을 보여주고 웹 크롤러 개발자의 삶을 더 쉽게 만드는 것을 목표로 하기 때문입니다. 세션 관리, 차단 시 세션 회전, 비동기 작업의 동시성 관리(비동기 코드를 작성하는 경우 이것이 얼마나 어려운지 알 수 있음)와 같은 중요한 측면을 처리하고 숨김으로써 더 빠른 크롤러 개발이 가능합니다. 훨씬 더.
:::팁
지금까지의 블로그가 마음에 드셨다면 GitHub에서 Crawlee에게 별표를 주시는 것을 고려해 보세요. 그러면 더 많은 개발자에게 다가가고 도움을 주는 데 도움이 됩니다.
:::
그리고 당신은 어떤 선택을 하시겠습니까?
기사에 나온 내용 중 일부는 여러분에게 분명하다고 생각하고, 일부 내용은 스스로 따라하고 있지만, 여러분도 새로운 것을 배웠기를 바랍니다. 대부분이 새로운 것이라면 다음 프로젝트에서 이 규칙을 체크리스트로 사용해 보세요.
기사에 대해 기꺼이 논의하겠습니다. 여기나 기사에 자유롭게 댓글을 달거나 Discord의 Crawlee 개발자 커뮤니티에서 저에게 연락하세요.
Github, Linkedin, Apify, Upwork, Contra 등의 플랫폼에서도 저를 찾으실 수 있습니다.
많은 관심 부탁드립니다 :)
위 내용은 웹 스크래핑 전문가처럼 생각하는 방법에 대한 팁의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!