몇 달에 한 번씩 팀 Slack에는 늘 같은 질문이 올라옵니다. "이건 그냥 Scrapy 스파이더로 짜면 안 되나요?" 그리고 그때마다 제 대답은 묻는 사람과 무엇을 하려는지에 따라 완전히 달라집니다. 사실 이게 이 글의 전부라고 해도 과언은 아니지만, 그래도 제 몫을 하려면 왜 그런지 제대로 설명해야겠죠.
저는 SaaS와 자동화 분야에서 거의 10년을 보냈습니다. 먼저 Automation Anywhere에서, 기업들이 웹사이트에서 데이터를 복붙하는 마지막 단계만 빼고는 모든 걸 자동화하는 모습을 지켜봤고, 지금은 Thunderbit을 만들고 있습니다. Thunderbit은 바로 그 "웹사이트에서 복사해서 붙여넣기"를 없애기 위해 존재하는 제품이죠. 반면 Scrapy는 "에이전틱 AI"라는 말이 아직 식사 자리에서 튀어나오던 시절보다 훨씬 전부터 인터넷의 데이터 파이프라인을 조용히 떠받쳐 왔습니다. 둘을 비교하는 일은 굳이 승자를 가리는 Thunderbit vs Scrapy 구도가 아닙니다. 오히려 스위스 아미 나이프와 공구가 완비된 정밀 기계 공장을 비교하는 데 가깝습니다. 둘 다 잘라낸 금속 조각 하나는 만들어내지만, 그 과정도, 필요한 숙련도도, 끝나고 치워야 할 난장판도 완전히 다르니까요.
한눈에 보는 답
세부로 들어가기 전에 짧게 말하자면: Thunderbit은 관리형 에이전틱 웹 스크래퍼입니다. 페이지를 열고 한 번 클릭하면 브라우저, 웹 앱, Open API, MCP 서버, 또는 CLI 어디에서든 구조를 알아서 파악합니다. Scrapy는 성숙한 오픈소스 Python 프레임워크입니다. 스파이더를 직접 작성하고, 셀렉터를 정의하고, 파이프라인을 만들고, 데이터에 손대는 모든 코드 한 줄까지 직접 책임집니다.
둘 중 어느 하나가 보편적으로 "더 낫다"고 말할 수는 없습니다. 서로 다른 문제를 푸는 서로 다른 사람들을 위해 만들어졌기 때문이죠. 솔직히 말해, 경쟁 글들이 이 차이를 하나의 판정으로 뭉개버리는 게 이 글을 제대로 써야겠다고 마음먹은 이유 중 하나이기도 합니다.
빠른 비교
처음 이걸 찾을 때 존재했으면 좋았을 표를 아래에 담았습니다. 제가 본 거의 모든 "Thunderbit vs Scrapy" 글은 이 둘을 Scrapy vs BeautifulSoup 같은 더 큰 비교 글 안에 묻어버리거나, 얇고 별점도 없는 디렉터리 위젯 수준에 그쳤습니다. 그래서 제대로 만들었습니다.
| 항목 | Scrapy | Thunderbit |
|---|---|---|
| 정체 | 오픈소스 Python 프레임워크(스파이더, 파이프라인, 미들웨어, 비동기 엔진) | 에이전틱 노코드 웹 스크래퍼 — 브라우저 확장, 웹 앱, Open API, MCP 서버, CLI |
| 시작 방법 | Python 환경 설치, 스파이더 작성, 셀렉터 정의, 파이프라인 설정 | 대상 페이지를 열고 One Click Extract 클릭 — 지원되고 권한이 있는 페이지에서는 추출이 자동 시작됨(Run Now는 선택 사항) |
| 필요한 숙련도 | Python, XPath/CSS 셀렉터, 비동기 개념 | 브라우저 워크플로우는 코딩 불필요; API/CLI/MCP는 일반적인 개발자 설정 필요 |
| JS/동적 콘텐츠 | scrapy-playwright 또는 Selenium 계열 연동 필요 | 사용자가 브라우저에서 이미 렌더링한 페이지를 기반으로 동작하며, 지원되는 로그인 세션도 포함할 수 있음 — 모든 사이트에서 보장되지는 않음 |
| 봇 차단 대응 | 수동 미들웨어(프록시 로테이션, 차단 감지), 우회 보장 없음 | 지원되고 권한이 있는 페이지에서 관리형 렌더링 제공, 역시 모든 경우 우회가 보장되지는 않음 |
| 대규모/반복 작업 | 대규모, 스크립트 기반, 예약 크롤링에 적합 | 플랜/사용 환경이 지원하는 범위에서 예약 가능; 타깃형 또는 중간 규모 작업에 더 적합 |
| 내보내기 | 커스텀 코딩(JSON, CSV, DB, 파이프라인) | Excel, Google Sheets, Airtable, Notion 같은 지원 대상 및 다운로드 형식으로 내보내기 가능 |
| 유지보수 | 레이아웃이 바뀌면 스파이더가 깨짐; 수정에 개발 시간 필요 | AI 보조 추출이 일부 레이아웃 변경에 적응하지만, 구조가 크게 바뀌면 역시 영향받을 수 있음 |
| 비용 구조 | 무료/오픈소스 + 개발 시간 + 호스팅 + 프록시 비용 | 구독/크레딧 기반 — 금액은 가격 페이지에서 확인 권장 |
Thunderbit은 무엇인가?
Thunderbit은 꽤 짜증나는 사실에서 출발했습니다. 웹에서 데이터를 필요로 하는 대부분의 사람들은 개발자가 아니고, 웹을 스크래핑하는 대부분의 도구는 사용자가 개발자라고 가정한다는 점이었죠. 그 간극이 사실상 우리가 존재하는 이유입니다.
브라우저에서 사용하는 핵심 흐름은 가장 좋은 의미에서 일부러 단순합니다. 원하는 페이지를 열고 One Click Extract를 누르면 에이전트가 나머지를 처리합니다. 페이지를 읽고, 무엇을 추출할 수 있는지 파악하고(상품 목록, 채용 공고, 연락처 정보, 화면에 보이는 무엇이든), 필드를 자동으로 준비합니다. 바로 시작하고 싶다면 Run Now 버튼을 누르면 되지만, 그냥 커피를 마시며 기다리고 있어도 추출은 알아서 시작됩니다. 셀렉터도, 스키마 작성도, "요소 검사"를 뒤지는 고고학도 필요 없습니다.
한 번 클릭하는 브라우저 흐름을 넘어서, Thunderbit은 만들고 있는 것에 따라 여러 방식으로 확장됩니다.
- Chrome Extension은 "지금 보고 있는 이 페이지의 데이터를 바로 가져오고 싶다"는 상황에 맞습니다.
- Web App은 코드를 건드리고 싶지 않은 비즈니스 사용자를 위한 클라우드 기반 반복 수집에 적합합니다.
- Open API는 백엔드와 애플리케이션 워크플로우용 Distill 및 구조화 Extract 엔드포인트를 제공합니다.
- MCP Server는 Claude, Cursor, Windsurf 안의 AI 에이전트가 Thunderbit을 직접 도구처럼 호출할 수 있게 합니다.
- CLI는 터미널에서 일하는 개발자와 코딩 에이전트를 위한 것입니다.
또한 호환되는 사이트에서는 페이지네이션과 하위 페이지 보강도 처리하고, 정규식 대신 자연어 지시문으로 필드를 다듬을 수 있습니다. 그렇다고 지구상의 모든 웹사이트에서 무조건 완벽하게 동작한다는 뜻은 아닙니다. 이 점은 뒤에서 솔직하게 짚겠습니다. 다만 세일즈 오퍼레이션 담당자나 부동산 분석가가 코드 에디터를 열지 않고도 쓸 수 있게 설계되었다는 점은 분명합니다.
2026년의 Scrapy는 어떤가?
Scrapy는 먼지 쌓인 레거시 도구가 아닙니다. 공식 Scrapy 사이트에는 현재 안정 버전이 2.17.0으로 표시되어 있고, 프로젝트는 계속 업데이트되고 있습니다. 최신 릴리스에서는 다운로드 핸들러 경로에 HTTP/2와 SOCKS 프록시 지원까지 추가됐습니다. 이건 "AI가 옛 프레임워크를 죽였다"는 이야기가 아닙니다. Scrapy는 여전히 아주 살아 있고, 솔직히 말해 지금도 제 역할을 아주 잘합니다.
핵심적으로 Scrapy는 비동기 크롤링 엔진을 중심으로 만든 Python 프레임워크입니다. Spider 클래스를 작성하고 시작 URL(또는 시작 메서드)을 정의하면, Scrapy가 콜백 함수가 응답을 처리하는 Request를 발송합니다. 그 다음에는 CSS나 XPath 셀렉터(혹은 옛 방식이 편하다면 정규식)로 데이터를 뽑아 Item으로 묶고, 파이프라인을 통해 정제, 검증, 저장합니다. 공식 개요 문서가 이 전체 흐름을 차근차근 설명해 주며, 익숙해지고 나면 정말 우아한 시스템입니다.
이런 학습 비용을 치르고 얻는 것은 진짜 통제력입니다. 쿠키와 세션, 인증 흐름, 캐싱, robots.txt 준수, 크롤링 깊이 제한, 그리고 서버 관리자에게 IP가 차단되지 않도록 돕는 AutoThrottle까지 다룰 수 있죠. 프록시 로테이션, 커스텀 다운로드 핸들러, 모니터링 훅, 그리고 최근에는 Playwright 기반 렌더링용 애드온과 스파이더 보일러플레이트를 자동 생성해 주는 AI 코딩 에이전트용 보조 도구까지, 방대한 미들웨어와 확장 생태계도 갖추고 있습니다.
한 가지 정확히 짚고 넘어갈 점이 있습니다. Scrapy의 핵심 엔진은 브라우저가 아니라 HTTP 크롤러입니다. JavaScript를 스스로 렌더링하지 않습니다. 그 기능이 필요하다면 scrapy-playwright, Selenium 스타일 미들웨어, 혹은 외부 렌더링 서비스를 붙여야 합니다. 이것이 꼭 결함은 아닙니다. 오히려 코어 프레임워크를 가볍고 빠르게 유지하기 위한 의도적 설계입니다. 다만 "JS가 많은 사이트를 처리하는 것"은 기본 동작이 아니라 프로젝트 판단이라는 뜻이기도 합니다.
핵심 차이: 관리형 에이전틱 워크플로우 vs 코드 소유 프레임워크
첫 데이터셋까지 걸리는 시간
스톱워치 숫자를 제가 지어내지는 않겠습니다. Scrapy의 "학습 곡선이 가파르다"는 말을 실제 근거 없이 주장하는 글을 너무 많이 봤거든요. 대신 실제 단계 수만 세어봅시다.
예를 들어 상품 목록 페이지를 스크래핑할 때 Scrapy 흐름:
- Python 가상환경을 만들고 Scrapy를 설치합니다.
- 템플릿에서 스파이더를 생성합니다.
- 페이지 HTML을 확인하고 각 필드에 대한 XPath/CSS 셀렉터를 작성합니다.
- 정제와 내보내기를 위한 Item 파이프라인을 설정합니다.
- 스파이더를 실행하고, 셀렉터 불일치를 디버깅한 뒤 다시 실행합니다.
같은 작업을 Thunderbit로 할 때:
- 브라우저에서 페이지를 엽니다.
- One Click Extract를 클릭합니다.
- 에이전트가 추출 가능한 필드를 찾아 실행을 시작합니다(또는 Run Now를 누릅니다).
Python 환경을 붙여야 하는 다섯 단계와, 환경 설정이 전혀 없는 세 단계의 차이입니다. 물론 단계 수만이 전부는 아닙니다. Scrapy의 다섯 단계는 무엇이 어떻게 일어나는지 훨씬 세밀하게 통제할 수 있게 해주니까요. 하지만 목표가 말 그대로 "오늘 이 표를 스프레드시트에 넣는 것"이라면, 이 단계 차이가 핵심입니다.
제어력과 확장성
이 부분에서는 Scrapy가 확실히 우위에 있고, 그걸 아니라고 하면 오히려 부정직하겠죠. 소스 코드를 직접 소유하기 때문에 커스텀 재시도 로직, 독특한 페이지네이션 패턴, 다단계 인증 흐름, 기존 데이터 웨어하우스와의 연동 등 원하는 것을 무엇이든 만들 수 있습니다. Thunderbit의 에이전틱 방식은 "코드 없이 구조화된 데이터를 빠르게 얻기"에 최적화되어 있어서, 본질적으로 모든 레버를 노출하기보다 일부 결정을 대신 내려줍니다. 비즈니스용 추출 작업의 80%에는 이 선택이 아주 훌륭합니다. 하지만 나머지 20%, 즉 정말 특이하고 맞춤화된 크롤링 로직에는 마음대로 굽힐 수 있는 프레임워크가 필요합니다.
유지보수와 운영 책임
스파이더는 깨집니다. 이건 Scrapy를 깎아내리는 말이 아닙니다. 에이전틱이든 수작업이든 모든 스크래퍼는 결국 대상으로 삼은 웹사이트의 영향권에 있습니다. 하지만 Scrapy 스파이더가 사이트의 HTML 개편 때문에 깨지면, 팀 누군가는 이를 알아차리고, 원인을 진단하고, 수정해야 합니다. 그건 매번 실제 개발 시간입니다.
Thunderbit의 AI 보조 추출은 하드코딩된 셀렉터 경로를 맞추는 대신 페이지 구조를 추론하기 때문에, 일부 레이아웃 변경에는 자동으로 적응할 수 있습니다. 그렇다고 해서 면역이라는 뜻은 아닙니다. 구조 변화가 충분히 크면 여전히 영향을 받을 수 있습니다. 차이는 누가 적응하느냐에 더 가깝습니다. 알고리즘이 최선의 추측을 시도하느냐, 아니면 개발자가 밤 11시에 XPath를 직접 다시 쓰느냐의 차이죠.
실제 활용 시나리오
단발성 디렉터리나 상품 표
레스토랑 목록, 상품 가격, 또는 이벤트 정보를 단일 페이지나 짧은 페이지 묶음에서 가져와야 한다면, Scrapy 프로젝트를 새로 여는 건 과하게 큰 일입니다. 한 번 쓰고 다시 손대지 않을 스파이더를 만드는 셈이니까요. 이런 경우는 Thunderbit의 브라우저 확장에 딱 맞습니다. 열고, 클릭하고, 추출하고, Google Sheets로 내보내면 끝입니다.
비즈니스 규칙이 많은 대규모 커스텀 크롤링
이제 12개 도메인에 걸친 5만 개의 상품 페이지를 크롤링하고, 커스텀 중복 제거 로직을 적용한 뒤, 모든 데이터를 독자적인 가격 모델에 넣어야 한다고 가정해 봅시다. 이건 Scrapy의 홈그라운드입니다. 파이프라인 아키텍처, 동시성 제어, 미들웨어 생태계 — 이 모든 것이 바로 이런 규모와 복잡도의 작업을 위해 존재합니다.
JavaScript가 많은 동적 사이트
이 부분에서는 둘 다 도움이 필요하지만, 필요한 방식이 다릅니다. Scrapy는 scrapy-playwright 같은 명시적 렌더링 통합을 붙여야 하므로, 추가 의존성과 유지보수 범위가 생깁니다. Thunderbit의 브라우저 확장은 이미 브라우저에서 렌더링된 페이지를 기반으로 동작하며, 일부 지원되는 로그인 세션도 포함할 수 있어 많은 설정을 건너뛸 수 있습니다. 하지만 분명히 해두자면, 공격적인 봇 차단 시스템이나 특이한 동적 콘텐츠 패턴에 대해 어느 쪽도 반드시 이긴다고 장담할 수는 없습니다. 그 반대를 말하는 사람은 대개 뭔가를 팔고 있는 겁니다.
AI 에이전트 또는 애플리케이션 연동
Claude나 Cursor에서 AI 에이전트 워크플로우를 만들고, 추론 루프의 일부로 실시간 웹 데이터를 가져오게 하려면, 커스텀 Scrapy 연동 코드를 붙이는 작업은 꽤 큰 일입니다. Thunderbit의 MCP Server는 바로 이 목적을 위해 만들어졌습니다. 에이전트가 도구처럼 직접 호출할 수 있도록 추출 기능을 노출합니다.
정확도, 확장성, 유지보수
Scrapy의 정확도는 좋은 의미에서 결정적입니다. 잘 작성된 셀렉터는 HTML이 바뀌기 전까지 매번 정확히 지정한 필드만 가져옵니다. 이런 예측 가능성은 무엇이 실패했는지 정확히 알아야 하는 프로덕션 파이프라인에서 정말 중요합니다.
Thunderbit의 에이전틱 탐지는 방식이 다릅니다. 사람처럼 페이지를 해석하고, 무엇이 가격이고 무엇이 제목인지, 무엇이 설명인지 판단합니다. 속도와 유연성 면에서는 놀랍도록 유용하지만, 정확도 모델은 다릅니다. "셀렉터가 말하는 그대로 항상 정확"이라기보다 "대체로 맞고, 가끔 살짝 손봐주면 되는" 쪽에 가깝죠. AI 기반 추출이 완벽하다고 가장하는 것보다, 이런 거래 조건을 솔직히 말하는 편이 낫다고 생각합니다.
순수 처리량만 놓고 보면 Scrapy의 비동기 엔진은 대량의 요청을 효율적으로 쏟아붓도록 설계되어 있습니다. 이건 정말 Scrapy의 설계 DNA의 일부입니다. Thunderbit은 밤새 100만 페이지를 긁는 것보다, 빠르게 깔끔한 구조화 결과를 얻는 중간 규모의 타깃 작업에 더 맞춰져 있습니다. 정말 대규모 크롤링을 계획하고 있다면, 어느 도구가 필요한 만큼 확장되는지 가정만 하지 말고 현재 플랜 한도를 확인하세요.
둘 모두에 해당하는 마지막 한 가지도 있습니다. 허가된 사용이 중요합니다. 어떤 도구를 쓰든 robots.txt, 사이트 약관, 적용 가능한 법률을 존중하는 일은 선택 사항이 아닙니다. 책임 있게 하는 일의 일부일 뿐입니다.
가격, 라이선스, 총비용
사람들이 자주 빠지는 함정이 하나 있습니다. "무료"와 "비용이 없다"를 같은 뜻으로 보는 것입니다. Scrapy는 라이선스 비용이 없습니다. 오픈소스가 맞습니다. 하지만 "무료" 소프트웨어도 돌릴 장소는 필요하고, 그 장소에는 비용이 듭니다. 호스팅, 대량 작업을 위한 프록시 서비스, JS 렌더링이 필요할 때의 브라우저 자동화 도구, 스파이더가 조용히 죽었을 때 알아차릴 모니터링, 그리고 가장 큰 비용인 이를 만들고, 테스트하고, 깨졌을 때 고치는 개발자 시간까지 말이죠.
Thunderbit은 구독/크레딧 모델로 운영되며, 여기서 제가 숫자를 말하기보다 공식 가격 페이지를 보시라고 권합니다. 가격 구조는 바뀔 수 있고, 최신 조건을 직접 확인하는 편이 좋으니까요. 그 구독이 사주는 것은, 적어도 지원되는 워크플로우에서는, 그 많은 설정과 유지보수 부담을 없애주는 일입니다.
진짜 질문은 "어느 쪽이 종이 위 비용이 더 낮은가"가 아닙니다. "우리 팀에 더 많은 통화는 무엇인가 — 개발자 시간인가, 구독 예산인가"입니다. 여유 있는 5인 데이터 엔지니어 팀이라면 이미 보유한 역량을 감안했을 때 Scrapy의 총비용이 더 낮을 수 있습니다. 반면 엔지니어가 한 명도 없는 3인 운영팀은, "무료" 프레임워크 때문에 계약자 비용과 세 주의 지연을 치르고서야 겨우 한 줄의 데이터를 보게 될 수도 있습니다.
Thunderbit을 선택해야 하는 사람
Thunderbit은 기술자가 아닌 운영 담당자 — 세일즈, 마케팅, 이커머스, 부동산, 채용 — 에게 가장 잘 맞습니다. 바로 지금 구조화된 데이터가 필요하고, 그걸 얻기 위해 엔지니어링 티켓을 넣고 싶지 않은 경우죠. 또 Open API와 CLI가 추출 로직을 처음부터 만들지 않도록 도와주기 때문에, 프로그래밍 방식의 접근만 필요로 하는 개발자에게도 좋은 선택입니다. 리드 생성, 이커머스 모니터링, 채용 조사용 LinkedIn 스크래핑 같은 워크플로우라면 대체로 이쪽이 더 빠릅니다.
Scrapy를 선택해야 하는 사람
사내에 Python 개발자가 있고, 몇 년 동안 살아남아야 하는 크롤링 인프라를 만들고 있으며, 요청 로직, 재시도 동작, 데이터 파이프라인을 완전히 통제해야 한다면 Scrapy가 맞습니다. 또한 컴플라이언스나 아키텍처 요구사항 때문에 코드가 완전히 자체 소유여야 할 때, 즉 감사 가능하고 자체 호스팅 가능하며 외부 의존성이 없어야 할 때도 더 적합합니다.
팀이 둘 다 쓸 수 있나?
많은 팀이 실제로 그렇게 하고 있고, 저는 그게 회피성 답변이라고 생각하지 않습니다. 개발자는 장기적으로 존재해야 하는 크롤링 인프라용으로 견고하고 대규모에 강한 Scrapy 스파이더를 운영하고, 나머지 조직은 Thunderbit을 ad hoc 조사, 일회성 데이터 추출, 그리고 본격적인 엔지니어링 스프린트를 붙이기엔 아까운 탐색 작업에 활용할 수 있습니다. 두 도구 사이에 공식 통합은 없습니다. 이 점은 분명히 해두겠습니다. 하지만 운영 측면에서 보면, 어떤 작업에 어떤 도구가 맞느냐에 따라 나란히 사용하는 데 아무런 제약이 없습니다.
결론
이걸 한 가지 직관적인 질문으로 줄인다면 이렇습니다. 당신이 최적화하는 것은 통제력인가, 속도인가? Scrapy는 설정 시간과 유지보수 비용을 치르는 대신 완전한 통제력을 줍니다. Thunderbit은 일부 유연성을 포기하는 대신 속도와 접근성을 제공합니다. 어느 쪽도 객관적으로 정답은 아닙니다. 스크래핑을 하는 사람이 Python을 아는지, 아니면 세일즈 파이프라인을 아는지에 달려 있으니까요. AI 기반 추출이 전통적인 방식과 비교해 일반적으로 어떤 위치에 있는지 더 보고 싶다면, AI 웹 스크래핑과 코딩 없이 웹 스크래핑하기에서 더 넓은 흐름을 함께 살펴볼 수 있습니다.
FAQ
Scrapy는 무료인가요? 공식 Scrapy 사이트 기준으로 Scrapy 프레임워크 자체는 오픈소스이며 라이선스 비용이 없습니다. 실제 비용은 호스팅, 프록시, JS 지원이 필요할 때의 렌더링 도구, 그리고 스파이더를 만들고 유지보수하는 개발자 시간에서 발생합니다.
Scrapy가 JavaScript를 직접 렌더링하나요? 아니요. Scrapy의 핵심은 브라우저가 아니라 HTTP 크롤러이므로 기본적으로 JavaScript를 실행하지 않습니다. JS가 많은 사이트를 스크래핑해야 할 때는 보통 scrapy-playwright나 Selenium 스타일 미들웨어를 추가합니다. 이는 공식 Scrapy 문서에도 나와 있습니다.
Thunderbit은 API와 MCP 접근을 지원하나요? 네. Thunderbit은 프로그래밍용으로 Distill 및 구조화 Extract 엔드포인트가 포함된 Open API를 제공하며, Claude나 Cursor 같은 도구의 AI 에이전트가 Thunderbit을 직접 호출할 수 있는 MCP Server도 제공합니다.
비즈니스 사용자가 쓰기에 더 빠른 쪽은 무엇인가요? 설계상 Thunderbit입니다. 브라우저 확장의 One Click Extract 흐름은 페이지를 분석한 뒤 자동으로 추출을 시작하며, 셀렉터나 스키마 설정이 필요 없습니다. Python을 설치하고 스파이더를 작성하는 것보다 훨씬 짧은 경로입니다.
깊이 맞춤화된 크롤링에는 무엇이 더 좋나요? Scrapy입니다. 미들웨어, 파이프라인 아키텍처, 전체 소스 코드 접근 덕분에 개발자는 매우 구체적인 크롤링 로직, 대규모 예약 작업, 에이전틱 도구가 대체하도록 만들어지지 않은 맞춤형 데이터 파이프라인을 구현할 수 있습니다.
