Scrapling: 스스로 복구하는 웹 스크레이퍼
BBetter Stack
Computing/SoftwareSmall Business/StartupsInternet Technology
Transcript
00:00:00이것은 웹 스크래핑의 가장 큰 골칫거리를 해결하려는 파이썬 스크래퍼, Scrapling입니다.
00:00:05오늘 잘 작동하던 스크래퍼가 사이트가 바뀌는 순간 바로 고장 나버리죠. 클래스 이름 하나 바뀌거나,
00:00:10div 하나 이동하거나, 봇 탐지라도 걸리면 데이터 파이프라인은 바로 중단됩니다. Scrapling의 핵심은
00:00:17스크래퍼가 무너지는 대신 스스로 적응할 수 있다는 것입니다. 깃허브에서 53,000개 이상의 스타를 받았고,
00:00:22적응형 파싱, 스텔스 페칭, 대규모 크롤링 워크플로우를 지원합니다.
00:00:27실제로 가장 중요한 질문 하나를 테스트해 보려 합니다.
00:00:30셀렉터를 수정하지 않고도 웹사이트 변경에서 살아남을 수 있을까요? 지금 확인해 보겠습니다.
00:00:40자, Scrapling이란 무엇일까요? Scrapling은 적응형 올인원 파이썬 웹 스크래핑 프레임워크입니다.
00:00:46자가 치유 파서, 스텔스 페처, 자바스크립트가 필요한 경우 브라우저 기반 페칭,
00:00:51그리고 대규모 크롤링을 위한 스파이더 프레임워크를 모두 제공합니다. 한 번의 설치, 하나의 API로 가능하죠. 즉, 더 적게 고장 나고
00:00:57더 많은 유용한 데이터를 얻을 수 있습니다. 이제 정말 중요한 부분을 살펴보죠.
00:01:03워크플로우를 효율적으로 만드는 코딩 도구에 관심이 있다면 구독해 주세요. 새로운 영상이 계속 올라옵니다.
00:01:08여기 기본적인 설정을 준비했습니다. Scrapling은 이미 설치했으니 빠르게 넘어가죠.
00:01:13임포트 한 번과 호출 한 번이면 페이지를 가져올 수 있습니다. 상단에는 변화하는 HTML을 만들어 두었습니다.
00:01:21하나는 일반적인 시작 사이트고, 다른 하나는 내용은 같지만 CSS 셀렉터만 바꿨습니다.
00:01:27상품명과 가격을 가져오고 싶다고 해보죠. 보통은 CSS 셀렉터를 사용해서 가져올 겁니다.
00:01:34page CSS에 셀렉터를 넣고, auto-save를 true로 설정합니다. 이렇게 하면
00:01:40정상적으로 작동해서 데이터 딕셔너리를 돌려줍니다. 평범해 보이죠. 두 개의 셀렉터와 딕셔너리,
00:01:46그냥 넘어가도 될 것 같습니다. 하지만 바로 이 점이 문제입니다. 일반적인 스크래퍼는
00:01:52페이지가 바뀌기 전까지만 잘 작동하니까요. 사이트가 밤사이에 예고 없이 바뀐다면 어떨까요? 리디자인을 하거나,
00:01:58스크래핑을 방해하기 위해 무언가 바꾼다면요. 예를 들어 제품 제목이 'item heading'이 되고 가격이
00:02:04'pricing value'로 바뀐다면요. 데이터는 똑같지만 전체 DOM 구조가 변해버리죠. 예전 셀렉터는
00:02:11이제 쓸모없어집니다. 대부분의 스크래퍼는 여기서 멈추죠. 하지만 이제 적응형 모드를 켤 수 있습니다.
00:02:18autosave는 true인 상태에서 adaptive를 true로 바꾸기만 하면 됩니다. 이제 제품 제목을
00:02:26adaptive 모드로 가져올 수 있습니다. 똑같은 데이터죠. 셀렉터를 다시 작성할 필요 없이
00:02:34페이지 구조가 바뀌어도 상관없습니다. 이것이 핵심 아이디어입니다. autosave가 true일 때,
00:02:40Scrapling은 요소에 대한 단서들을 기록합니다. 태그, 속성,
00:02:44부모 및 자식 요소, 주변 텍스트, DOM 위치 및 구조적 형태 등을 기록하죠. 그래서
00:02:50클래스 이름이 바뀌어도 Scrapling은 많은 단서를 가지고 있습니다. 사이트 전체가 그대로일 필요는 없습니다.
00:02:56요소를 다시 인식할 만큼의 구조적 신호만 있으면 됩니다. 바로 이 부분이
00:03:01중요합니다. 실제 스크래퍼가 고장 나는 이유는 전체 리디자인 때문이 아닙니다. 클래스 이름이 바뀌거나,
00:03:06새로운 래퍼가 추가되거나, 레이아웃이 살짝 변하는 등 아주 사소한 이유 때문이죠. 적응형 매칭은 바로 그런 상황을 위한 것입니다.
00:03:13Scrapling에는 정말 중요한 세 가지 핵심 기능이 있습니다. 첫 번째는 방금 보신 적응형 파서입니다.
00:03:18두 번째는 상황에 맞는 다중 페처입니다. plain HTTP 페처는 단순한 웹 페이지에 빠르고,
00:03:25스텔스 페처는 봇 탐지를 우회할 수 있습니다. 다이내믹 페처는 자바스크립트가 많은 사이트를 위해 실제
00:03:32브라우저를 구동합니다. API는 하나로 유지하면서 페처만 바꾸면 됩니다. 세 번째는 스파이더 프레임워크인데,
00:03:39간단한 스크립트가 실제 크롤러로 발전할 때 유용합니다. 비동기 크롤링, 일시 정지 및 재개, 프록시 로테이션, 스트리밍 등을
00:03:46모두 지원합니다. 나중에 추가해야 할 기능들이 이미 다 포함되어 있죠. Scrapling은 단순한
00:03:53파서가 아닙니다. Requests, BeautifulSoup, Playwright, 재시도 로직, 프록시 헬퍼 등을
00:04:00하나의 워크플로우로 대체합니다. Scrapling이 BeautifulSoup이 쓸모없다거나
00:04:06Playwright나 Scrapy가 죽었다고 말하는 건 아닙니다. BeautifulSoup과 Requests는 여전히 단순한 페이지에는 최고입니다. 쉽고,
00:04:13읽기 편하며 모두에게 익숙하니까요. 하지만 스텔스 기능이 없고,
00:04:20적응형 셀렉터도 없으며, 자바스크립트도 렌더링 하지 않습니다. 대규모 작업에서는
00:04:26병목 현상이 생길 수 있죠. Scrapy는 강력합니다. 본격적인 크롤링
00:04:31인프라를 구축한다면 Scrapy는 여전히 존중받아야 하지만, 설정, 파이프라인, 미들웨어,
00:04:36확장 등 설정할 게 너무 많습니다. Playwright와 Selenium은 실제 브라우저가 필요할 때 훌륭합니다.
00:04:42어떤 페이지는 자바스크립트가 꼭 필요하죠. 하지만 브라우저는 무겁습니다. Raw HTTP보다
00:04:48느리고 메모리도 많이 차지하죠. 게다가 셀렉터 고장 문제를 해결해주지 않습니다. 페이지를 띄울 뿐,
00:04:54데이터의 의미는 이해하지 못하니까요. 그래서 Scrapling을 사용하면,
00:05:01상황에 따라 빠른 페칭, 스텔스 기능, 브라우저 렌더링, 그리고 적응형 파싱을 조합해서 사용할 수 있습니다.
00:05:06이렇게 하면 프론트엔드 변경에 모든 작업이 망가지지 않죠. 물론 Scrapling도 완벽하진 않습니다.
00:05:12데이터 DOM 수준의 보호나, 고급 핑거프린팅,
00:05:17강력한 레이트 리밋에 대응하려면 여전히 좋은 프록시가 필요합니다. Scrapling이
00:05:23도움은 되지만 완벽한 은신을 보장하진 않습니다. 다이내믹 페칭은 브라우저 설정이 복잡해질 수 있는데,
00:05:29자바스크립트 렌더링을 사용할 때의 트레이드오프입니다. 마지막으로 생각해 볼 점이 있습니다.
00:05:34실제 스크래핑 업무를 하거나, 특히 데이터 파이프라인,
00:05:41RAG 작업, AI 에이전트 등 타겟 사이트가 바뀌어도 계속 실행되어야 하는 시스템을 만든다면 Scrapling은 시도해 볼 가치가 있습니다.
00:05:47가장 큰 이유는 스크래핑을 가능하게 해줘서가 아닙니다. 이미 그런 툴은 많으니까요.
00:05:53가장 큰 이유는 유지보수 비용을 줄여준다는 것입니다. 물론 아주 작은 스크립트라면
00:05:59Requests와 BeautifulSoup으로도 충분할 겁니다.
00:06:04이런 코딩 도구에 관심이 있다면 BetterStack 채널을 구독해 주세요. 다음 영상에서 뵙겠습니다.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video