엔지니어 팀의 Slack 대화를 좀 오래 지켜봤다면, 이 질문이 보통 어떻게 튀어나오는지 바로 감이 올 겁니다. 누군가 “최고의 웹 스크래퍼” 목록 글 링크를 툭 던지면, 엔지니어 셋이 거의 동시에 “여기엔 Colly가 없네”라고 받아치곤 하죠. 이건 우연이 아닙니다. 제가 지금 “Thunderbit vs Colly”로 상위 노출되는 글 네 개를 직접 확인해봤는데, 전부 Thunderbit를 Crawl4AI, Browse AI, rtrvr.ai, Chat4Data 같은 다른 노코드 도구들과만 비교하고 있더군요. Colly는 단 한 번도 나오지 않았습니다.
그런데 이건 꽤 이상한 일입니다. Colly는 r/golang은 물론이고, 빠르고 코드로 제어하는 크롤러가 필요한 Go 개발 조직에서도 꽤 두터운 팬층을 갖고 있으니까요. 그래서 이 글은 정말로 그 질문에 답하려고 쓴 글입니다. Colly라는 이름만 슬쩍 붙인 “AI 도구 비교” 재탕이 아닙니다.
빠른 답변
회의 사이에 대충 훑어보는 분들을 위해 먼저 한 줄로 정리하면: Thunderbit는 클릭만 하면 바로 쓰는 관리형 에이전트형 웹 스크래퍼입니다. 셀렉터도, 코드도 필요 없고, 브라우저 또는 클라우드에서 돌아가며, 개발자가 프로그램 방식으로 접근할 수 있도록 Web App, Open API, MCP Server, CLI도 제공합니다. 반면 Colly는 오픈소스 Go 프레임워크로, 크롤러 로직을 직접 작성하고, 직접 소유하고, 동시성도 손수 튜닝합니다.
엄밀히 말해 둘은 전통적인 의미의 경쟁 제품이라고 보기 어렵습니다. 하나는 제품이고, 다른 하나는 라이브러리니까요. 이 둘을 굳이 정면 비교할 의미가 있는 건, 지금 당신이 서 있는 갈림길에서 어떤 선택이 실제 상황에 더 맞는지 판단할 때입니다. 바로 그 판단을 돕는 게 이 글의 목적입니다.
한눈에 보기
| 항목 | Thunderbit | Colly |
|---|---|---|
| 주요 사용자 | 비즈니스 사용자, 운영팀, 속도가 필요한 개발자 | Go 개발자 |
| 설정 방식 | 페이지에서 One Click Extract 클릭 | go get github.com/gocolly/colly 후 Go 코드 작성 |
| 첫 결과까지 걸리는 시간 | 몇 초~몇 분, 에이전트가 자동 실행 | 콜백을 얼마나 빨리 작성하느냐에 따라 다름 |
| 필요한 언어 | 브라우저 사용 시 없음 | Go |
| 크롤링 방식 | 에이전트가 페이지를 분석, 페이지네이션/하위 페이지 대응 가능 | 수동 Collector + OnHTML/OnResponse 콜백 |
| 렌더링 | 관리형 브라우저/클라우드 실행 경로 | 주로 HTTP/HTML, JS 비중이 큰 사이트는 추가 도구 필요 |
| 추출 규칙 | 에이전트가 필드를 제안, 사용자가 세부 조정 가능 | 개발자가 CSS 셀렉터를 직접 작성 |
| 동시성 | 플랫폼이 관리 | goroutine으로 완전 수동 제어 |
| 저장/내보내기 | 스프레드시트, 시트 및 기타 지원 대상로 내보내기 | 개발자가 직접 구축(파일, DB, Redis 등) |
| 배포 | 브라우저 확장, Web App, API, MCP, CLI | 자체 호스팅 Go 바이너리/스크립트 |
| 유지보수 | 추출 로직은 관리형이지만 사이트 호환성에 영향 받음 | 사이트 변경 시 개발자가 셀렉터 수정 |
| 라이선스/비용 | 크레딧 기반 플랜(pricing에서 최신 요금 확인) | Apache-2.0, 무료 — 하지만 인프라/개발 시간은 별도 |
Thunderbit란 무엇인가?
Thunderbit의 기본 작업 흐름은 정말로 “한 번 클릭”입니다. 접근 권한이 있는 페이지를 열고 One Click Extract를 누르면, 에이전트가 페이지를 읽고 무엇을 가져올 만한지 판단한 뒤 추출할 필드를 제안합니다. Run Now 버튼도 있지만, 사실상 안심용에 가깝습니다. 따로 건드리지 않아도 추출이 바로 시작되니까요. 에이전트가 지원하는 페이지라면 셀렉터를 짤 필요도, 스키마를 미리 설계할 필요도 없습니다.
그다음에는 에이전트가 완벽하게 맞히지 못한 필드를 손볼 수 있고, 호환되는 사이트에서는 페이지네이션을 따라가거나 하위 페이지를 파고들어 보강 정보까지 수집합니다. 예를 들어 목록에 있는 각 상품 페이지에서 추가 상세 정보를 긁어오는 식이죠. 데이터를 확보한 뒤에는 Excel, Google Sheets, 그리고 몇 가지 다른 지원 대상로 내보낼 수 있습니다.
하지만 브라우저 확장은 시작점일 뿐입니다. 개발자라면 자신의 코드에서 추출을 호출할 수 있는 Open API, Claude·Cursor·Windsurf 같은 도구 안에서 호출 가능한 기능으로 추출을 붙일 수 있는 MCP Server, 그리고 터미널과 코딩 에이전트 워크플로우를 위한 CLI도 사용할 수 있습니다. 이걸 굳이 강조하는 이유는, 많은 “노코드 vs 코드” 프레임이 Thunderbit를 그저 비즈니스 사용자용 도구처럼만 다루는데, 이제는 그 설명이 정확하지 않기 때문입니다.
Colly란 무엇인가?
Colly는 한마디로 Go 라이브러리입니다. 대시보드도, 호스팅 서비스도, 무엇을 스크랩할지 대신 판단해주는 AI 계층도 없습니다. Go 코드를 작성하고, Collector를 만든 다음, OnHTML과 OnResponse 같은 콜백을 붙여 페이지를 만났을 때 무엇을 할지 직접 정의합니다.
대략 이런 느낌입니다:
c := colly.NewCollector()
c.OnHTML("a[href]", func(e *colly.HTMLElement) {
link := e.Attr("href")
c.Visit(e.Request.AbsoluteURL(link))
})
c.OnResponse(func(r *colly.Response) {
fmt.Println("Visited", r.Request.URL)
})
c.Visit("https://example.com")
핵심 사고방식은 이렇습니다. 무엇을 찾을지 정하고, 찾았을 때 무엇을 할지 정한 뒤, collector가 크롤링하게 두는 겁니다. 내부적으로는 동기, 비동기, 병렬 크롤링, 도메인별 속도 제한, 쿠키/세션 자동 처리, 요청 캐싱, robots.txt 준수, 프록시 순환, Redis를 포함한 플러그형 저장소 백엔드 같은 기능을 제공합니다.
한 가지는 분명히 짚고 넘어가야 합니다. Colly는 기본적으로 HTTP/HTML 프레임워크입니다. Playwright처럼 전체 브라우저를 띄우는 방식은 아닙니다. 대상 사이트가 JavaScript 렌더링에 크게 의존한다면, 보통은 해당 페이지가 호출하는 내부 JSON API를 찾아내거나, 별도의 브라우저 자동화 도구와 함께 써야 합니다. 이건 Colly의 단점이라기보다, 완전한 에이전트형 브라우저 인식 제품과는 설계 철학이 다르다고 보는 편이 맞습니다.
핵심 차이: 관리형 에이전트 추출 vs Go 코드 프레임워크
첫 테이블까지 걸리는 시간
차이가 제일 크게 드러나는 지점입니다. Thunderbit에서는 “첫 결과까지의 시간”이 버튼을 누르고 에이전트가 페이지를 읽는 동안 기다리는 정도입니다. 페이지가 복잡하지 않다면 몇 초, 길어도 몇 분이면 끝납니다. 반면 Colly에서는 collector 작성, 알맞은 셀렉터 찾기(보통 개발자 도구를 켜고 시행착오를 겪게 됩니다), 페이지네이션 로직 직접 구현, 그리고 실제 실행까지 전부 포함됩니다. 일회성 작업이라도, Go를 꽤 잘 다루는 사람에게도 적잖은 시간 비용이 듭니다.
성능과 제어력
순수한 제어력은 Colly가 확실히 앞섭니다. 로직을 직접 짜기 때문에, 몇 개의 goroutine을 동시에 돌릴지, 속도 제한을 얼마나 세게 걸지, 무엇을 캐시할지, 에러를 어떻게 재시도할지를 전부 직접 결정할 수 있습니다. 프로젝트 공식 문서에는 적절한 정적 대상에서 단일 코어 기준 초당 1,000건 이상의 요청도 언급되어 있습니다. 이건 Thunderbit와의 통제된 비교라기보다 Colly 자체 벤치마크 주장이라는 점을 분명히 하고 싶습니다. 그래도 여기서 읽히는 메시지는 명확합니다. HTTP 친화적인 대상이라면, 손으로 잘 튜닝한 Go 동시성은 따라잡기 쉽지 않습니다.
Thunderbit는 이런 세밀한 제어를 대신 관리형 실행으로 바꿉니다. goroutine 풀을 조정하는 대신, 플랫폼의 브라우저와 클라우드 실행 경로를 활용하는 방식이고, 플랜이 지원하면 예약 추출도 쓸 수 있습니다. 인프라를 직접 떠안고 싶지 않다면 이게 딱 맞고, 반대로 당신의 일이 크롤러 처리량을 끝까지 짜내는 것이라면 맞지 않을 수 있습니다.
배포와 유지보수 책임
사실 이 부분을 충분히 이야기하는 사람이 별로 없습니다. Colly는 Apache-2.0 라이선스라 라이브러리 자체 비용은 없습니다. 하지만 누군가는 여전히 직접 작성하고, 호스팅하고, 모니터링하고, 가장 중요한 부분으로 대상 사이트의 HTML이 바뀔 때마다 고쳐야 합니다. 셀렉터는 조용히 깨집니다. “이 사이트가 상품 페이지를 리디자인했네요” 같은 알림은 오지 않습니다. 개발자가 파이프라인이 멈췄거나 쓰레기 데이터를 내보내기 시작한 걸 알아차린 뒤, 직접 패치해야 합니다.
Thunderbit에서는 추출 로직이 플랫폼에서 관리되며, 에이전트형 페이지 분석이 지원되고 권한이 있는 페이지의 레이아웃 변화에 맞춰 적응하도록 설계되어 있습니다. 그렇다고 여기서 방심하면 안 됩니다. 이게 모든 사이트에 대한 무조건적 보장을 뜻하는 건 아닙니다. 강한 봇 차단이 걸린 페이지, 접근 권한이 없는 로그인 벽 뒤 콘텐츠, 또는 에이전트가 잘 처리하지 못하는 사이트는 여전히 한계가 있습니다. 솔직히 말하면 이렇습니다. Colly에서는 문제가 생기면 늘 사용자가 직접 해결해야 합니다. Thunderbit에서는 부담이 덜하지만 “덜하다”가 “없다”는 뜻은 아닙니다. 대상 페이지가 Thunderbit가 잘 지원하는 유형이어야 성공합니다.
실제 사용 시나리오
일회성 디렉터리/상품 추출
예를 들어, 오늘 안에 경쟁사 카탈로그 페이지에서 상품 표 200개를 뽑아야 하는데 개발자는 아니거나, 개발자이긴 하지만 더 급한 일이 있다면 어떨까요? 이건 Thunderbit가 가장 잘하는 분야입니다. 클릭하고, 에이전트가 필드를 제안하게 하고, 필요하면 수정한 뒤, Sheets로 내보내면 됩니다. 단발성 추출을 위해 Colly 스크립트를 새로 짜는 건 기술적으로는 가능하지만, 분재 다듬으려고 전기톱을 드는 느낌에 가깝습니다.
고처리량 맞춤형 Go 크롤러
반대로 생각해봅시다. 하루에 수천 개 URL을 조회하는 모니터링 파이프라인을 만들고 있고, 이미 Go 스택이 있으며, 재시도 로직, Redis를 통한 분산 저장, 차단을 피하기 위해 조정된 도메인별 속도 제한까지 정확하게 제어해야 한다면요? 이건 딱 Colly의 영역입니다. 구독료도 없고, 로직은 전부 내 것이며, 관리형 제품이 노출하도록 설계되지 않은 방식으로도 자신의 트래픽 패턴에 맞게 최적화할 수 있습니다.
JavaScript 비중이 높은 대상
대상이 클라이언트 사이드에서 대부분을 렌더링하는 강한 JS 기반 사이트라면, Colly만으로는 해결책이 아닐 가능성이 큽니다. 내부 JSON API를 찾아내거나 별도의 브라우저 자동화 계층을 붙여야 할 수 있습니다. Thunderbit는 이런 유형의 페이지를 염두에 둔 관리형 브라우저/클라우드 실행 경로를 제공합니다. 다만 다시 한 번 말하지만, 특정 대상에서 정말 잘 작동하는지는 직접 테스트해봐야 합니다.
API 또는 AI 에이전트 연동
Claude나 Cursor에서 실행되는 AI 에이전트가 더 큰 워크플로우의 일부로 구조화된 데이터를 가져와야 하는 내부 도구를 만든다고 해봅시다. 이럴 때 Thunderbit의 MCP Server는 꽤 유용합니다. 추출을 에이전트 워크플로우 안에서 호출 가능한 도구로 노출해주기 때문입니다. 반면 Colly는 독립 라이브러리라서, AI 에이전트가 도구처럼 바로 호출할 수 있는 형태는 아닙니다.
신뢰성, 규모, 유지보수
사람들이 자주 헷갈리는 두 가지를 분리해보겠습니다. 하나는 순수 처리량이고, 다른 하나는 실제 웹사이트에서의 총 성공률입니다. Colly는 정적이고 HTTP 친화적인 페이지에서 빠르게 움직일 수 있습니다. 그게 바로 설계 목적이니까요. 하지만 “빠르다”가 “세 달 뒤에도 계속 잘 돌아간다”는 뜻은 아닙니다. 대상 사이트가 리디자인을 배포하면, 당신이 작성한 셀렉터는 한꺼번에 낡을 수 있습니다. 그리고 데이터 파이프라인이 조용히 null을 뱉기 시작할 때까지 아무도 모를 수도 있습니다.
Thunderbit의 에이전트형 접근은 셀렉터를 직접 유지보수하지 않아도 된다는 장점이 있습니다. 다만 Thunderbit 자체 마케팅을 포함해, 봇 차단이 강하거나 권한이 없는 인증 뒤 콘텐츠가 있는 모든 사이트에서 보편적 신뢰성을 보장하는 듯한 표현에는 저도 동의하기 어렵습니다. 어떤 도구를 평가하든 진짜로 물어봐야 할 질문은 “깨졌을 때 누가 고치고, 얼마나 걸리느냐”입니다. “첫날 얼마나 빠르냐”만이 아닙니다.
가격, 라이선스, 총소유비용
Colly는 Apache 2.0 오픈소스입니다. 라이브러리 자체는 무료입니다. 하지만 총소유비용에는 크롤러를 작성하고 디버그하는 개발자 시간, 실행 인프라 비용, IP 순환이 필요하다면 프록시 비용, 그리고 대상 사이트가 바뀔 때마다 셀렉터를 고치는 지속적인 시간이 들어갑니다. Go에 익숙한 팀이라면 대규모에서 진짜로 저렴할 수 있습니다. 반대로 그런 역량이 없는 팀이라면, “무료”는 금세 “숨겨진 비용이 큰 것”으로 바뀝니다.
Thunderbit는 크레딧 기반 플랜으로 운영됩니다. 요금제와 크레딧 정책은 바뀔 수 있으니, pricing 페이지에서 최신 정보를 확인하는 게 좋습니다. 여기서는 숫자를 외워두기보다 공식 출처를 보는 편이 낫습니다. 대신 사용자는 지원되는 페이지에서 손이 덜 가는 운영을 얻는 대가로 비용을 지불하는 셈이지, 모든 곳에서 유지보수가 아예 필요 없는 건 아닙니다.
정직하게 판단하려면, 자신의 상황에 맞게 대략적인 표를 만들어보세요. 설정 시간, 인프라/프록시 비용, 지속적인 수정 시간, 구독 비용. 당신 팀의 실제 역량과 업무량 기준으로 어떤 쪽이 그 표에서 이기는지가 답입니다. “오픈소스가 더 싸다”는 일반론보다 훨씬 중요합니다.
누가 Thunderbit를 선택해야 하나?
비즈니스 사용자, 운영 담당자, 성장팀 구성원처럼 지금 당장 구조화된 데이터가 필요하고 코드는 건드리고 싶지 않다면, Thunderbit의 브라우저 확장이 가장 자연스러운 선택입니다. API, CLI, 또는 MCP를 통한 AI 에이전트 워크플로우 안에서 추출을 빌딩 블록처럼 쓰고 싶은 개발자에게도 Thunderbit는 잘 맞습니다. 다만 진입 방식이 클릭형이 아닐 뿐입니다.
누가 Colly를 선택해야 하나?
Go 개발자이거나 팀이 Go 중심이고, 모든 요청·모든 재시도·모든 프록시 순환을 직접 통제하는 맞춤형 고처리량 크롤러가 필요하다면, Colly는 그 일을 위해 만들어졌습니다. 구독 의존성 없이 코드를 완전히 소유하고 싶고, 유지보수할 엔지니어링 여력이 있다면 이게 맞는 선택입니다.
두 도구를 함께 쓸 수 있을까?
솔직히 말해, 가능합니다. 그리고 저는 이게 회피성 답변이라고 생각하지 않습니다. 엔지니어링 팀이 핵심 데이터 파이프라인용으로는 오래가고 대규모로 확장되는 Colly 크롤러를 운영하고, 영업·운영·마케팅팀은 스크립트를 작성하고 유지할 정도는 아닌 임시 추출 작업에 Thunderbit를 쓰는 경우는 꽤 흔합니다. 여기서 둘 사이의 “공식 통합” 같은 걸 제가 억지로 만들어내진 않겠습니다. 제가 아는 한 그런 건 없으니까요. 다만 구조적으로 보면, 같은 조직 안에서 두 도구가 서로 다른 문제를 해결하며 공존하는 데는 아무런 장애가 없습니다.
결론
누가 일하는지, 그리고 무엇을 최적화하려는지를 기준으로 선택하세요. Go 역량이 있고, 맞춤 로직이 필요하며, 전적인 제어를 얻는 대신 유지보수를 책임지고 싶고 구독료도 피하고 싶다면 Colly가 맞습니다. 반대로 데이터를 빨리 확보하고 싶고, 코드 작성·유지보수를 원하지 않으며, 낮은 수준의 제어를 일부 포기하더라도 관리형 경험을 원한다면—API나 AI 에이전트 연동 옵션까지 포함해서—Thunderbit가 더 잘 맞습니다. 둘 중 어느 쪽도 추상적으로는 “더 좋다”고 말할 수 없습니다. 서로 다른 사람의 서로 다른 문제를 풀기 위해 만들어졌기 때문입니다.
FAQ
Colly는 무료인가요?
네. Colly는 Apache 2.0 라이선스의 오픈소스라 라이브러리 자체 비용은 없습니다. 실제 비용은 개발 시간, 호스팅, 필요할 경우 프록시, 그리고 대상 사이트가 바뀔 때 발생하는 지속적인 유지보수에서 생깁니다.
Colly는 JavaScript를 렌더링하나요?
기본적으로는 아닙니다. Colly는 주로 HTTP/HTML 프레임워크이기 때문에, JavaScript 비중이 큰 사이트는 보통 페이지가 호출하는 내부 JSON API를 찾거나, 별도의 브라우저 자동화 도구와 함께 사용해야 합니다.
Thunderbit는 개발자를 위한 API와 MCP 접근을 지원하나요?
네. Thunderbit는 프로그램 방식 추출을 위한 Open API와, Claude·Cursor·Windsurf 같은 호환 AI 에이전트 워크플로우 안에서 추출을 호출 가능한 도구로 노출하는 MCP Server를 제공합니다.
시작하기 더 쉬운 쪽은 어느 쪽인가요?
설계상 Thunderbit입니다. 브라우저 확장의 One Click Extract 흐름을 쓰면 코드 없이 몇 초~몇 분 안에 결과를 얻을 수 있습니다. Colly는 첫 결과를 보기 전에 Go 코드를 작성하고 테스트해야 합니다.
크롤링 자체에 대한 저수준 제어는 어느 쪽이 더 강한가요?
단연 Colly입니다. goroutine으로 동시성을 조절하고, 요청 속도 제한, 캐싱, 프록시 순환, 저장 백엔드를 코드에서 직접 제어할 수 있습니다. 이런 수준의 튜닝은 Thunderbit 같은 관리형 제품이 설계상 노출하지 않는 영역입니다.
