“Colly”를 검색하면 늘 가장 먼저 따라붙는 형용사는 하나입니다. 바로 “빠르다”는 말이죠. 컴파일되니까 빠르고, 브라우저가 끼어들지 않으니까 빠르다고들 합니다. 그런데 정작 그 속도가 어느 정도인지는 거의 아무도 숫자로 말하지 않더군요.
그래서 저는 그 말을 그대로 믿지 않기로 했습니다. 작은 테스트용 사이트를 띄운 뒤 Colly를 붙여 보고, 라이브러리가 실제로 무엇을 하는지 확인했습니다. 실페이지에서의 추출 정확도는 어떤지, 500 에러를 어떻게 처리하는지, 깊이 제한 크롤링은 어디까지 가는지 직접 봤습니다. 먼저 결론부터 말하면: 정적 추출은 전부 정확히 맞아떨어졌고, 500 응답은 있어야 할 곳으로 정확히 들어갔으며, 브라우저 없이 단일 정적 바이너리로 돌린 깊이 제한 크롤링은 17개 페이지까지 도달했습니다. 다만 “빠르다”는 찬사에서 보통 빠지는 부분, 즉 자바스크립트로 렌더링되는 페이지는 결과가 깔끔하게 0이었습니다.
Colly는 실제로 무엇이고, 무엇이 아닌가
Colly는 스스로를 “Golang을 위한 우아한 스크래퍼 및 크롤러 프레임워크”라고 소개합니다. 이 한 줄은 생각보다 많은 것을 말해 줍니다. Colly는 Go 라이브러리입니다. gocolly/colly는 2026-07-09 기준 약 25.4k stars를 보유하고 있고, Apache-2.0 라이선스로 배포됩니다. URL 하나를 넣으면 바로 쓰는 CLI 도구가 아닙니다. Go 코드를 작성하고, 패키지를 import한 뒤, 몇 개의 콜백을 연결하고, 결과를 하나의 실행 파일로 컴파일해야 합니다.
이 도구의 사고방식은 이벤트 중심입니다. 이 점이 요청-파싱 방식에 익숙한 사람들을 자주 헷갈리게 합니다. 응답을 한 줄씩 훑으면서 필드를 뽑아내는 식이 아닙니다. Collector에 핸들러를 붙여 두고, 페이지를 따라가면서 라이브러리가 그 핸들러를 호출하게 합니다. OnHTML은 일치하는 CSS 셀렉터가 나타날 때마다 추출 코드를 실행합니다. OnResponse는 원시 응답 본문을 건네주는데, 페이로드가 HTML이 아니라 JSON일 때 특히 중요합니다. OnError는 실패한 요청을 잡아냅니다. 크롤링도 같은 방식으로 동작합니다. 링크 핸들러 안에서 발견한 URL에 Visit()를 호출하면 Colly가 이를 큐에 넣고, MaxDepth가 어디까지 돌아다닐지 결정합니다. 콜백, 방문 큐, 깊이 제한, 정적 컴파일. 인터프리터도 없고, 런타임도 없고, 메모리에서 헤드리스 Chrome이 돌아갈 일도 없습니다.
콜백 모델, 그리고 추출 경험을 바꾸는 이유
콜백이야말로 이 도구의 성격 그 자체이므로, 조금 천천히 볼 만합니다. 제가 실행한 모든 테스트는 사실상 이 세 가지 콜백으로 돌아갔습니다.
OnHTML(selector, handler)는 가장 자주 쓰게 될 함수입니다. .product나 article p 같은 셀렉터에 등록해 두면, Colly가 DOM을 파싱하는 동안 매칭되는 요소마다 핸들러를 호출합니다. 구조화된 추출은 여기서 이루어집니다. 루프를 직접 짜는 대신, 무엇을 원하는지만 선언하면 되니 읽기에도 좋습니다.
OnResponse(handler)는 한 단계 아래에서 원시 바이트를 그대로 넘겨줍니다. 대상이 마크업이 아니라 JSON을 반환할 때는 DOM을 건드릴 필요가 없습니다. 본문을 직접 unmarshal 하면 됩니다. 제 테스트에서 Colly가 HTML 한 조각도 파싱하지 않고 JSON API를 처리할 수 있었던 이유가 바로 이 콜백 하나 때문입니다.
OnError(handler)는 새벽 3시에 스크래퍼가 죽고 나서야 다들 떠올리는 콜백입니다. 요청이 실패하면 호출되고, 응답을 함께 넘겨줘서 상태 코드를 읽고 다음 동작을 정할 수 있습니다. 실패를 조용히 삼켜 버리는 크롤러는 차라리 크게 실패하는 쪽보다 더 나쁩니다. Colly는 둘 다 하지 않습니다. 그리고 무인 상태로 돌아가는 작업에서 이 차이는 생각보다 훨씬 중요합니다.
여기에 운영 측면에서 중요한 기능이 두 가지 더 있습니다. MaxDepth는 크롤 범위를 제한해서, 링크를 따라가는 컬렉터가 웹 전체를 배회하지 않고 두 단계에서 멈추게 해 줍니다. 그리고 빌드 결과물은 하나의 정적 Go 바이너리입니다. 한 번 컴파일하면 런타임 의존성 없는 파일 하나가 생기고, 서버나 CI 작업에 그대로 올려 실행할 수 있습니다. 새 환경에서 Python virtualenv 때문에 반나절을 날려 본 적이 있다면, 이 배포 방식은 부차적인 장식이 아니라 분명한 장점으로 느껴질 겁니다.
설치 — 아무도 말해주지 않는 Go 툴체인 이야기
의존성 이야기는 짧지만, 실제로 걸리는 부분이 하나 있습니다. 그래서 설치 전에 먼저 짚고 넘어가겠습니다. 제가 테스트한 머신에는 Go가 전혀 설치되어 있지 않았고, Colly는 Go 라이브러리이므로 첫 단계는 툴체인을 깔아두는 것이었습니다. 저는 Homebrew로 Go 1.26.5를 설치했습니다. 팀이 이미 Go를 쓰고 있지 않다면, 바로 이 부분이 진짜 허들입니다. 라이브러리 자체가 아니라, 그 앞에 필요한 언어 환경 말이죠.
Go만 있으면 Colly 설치는 깔끔합니다. go get github.com/gocolly/colly/v2는 별다른 문제 없이 v2.3.0으로 해결됐고, 브라우저도, 헤드리스 실행도, 그 외의 부가 장치도 필요하지 않았습니다. 마지막에는 컴파일된 바이너리만 남습니다. 파서 하나 설치해 놓고, 첫 fetch에서 누락된 추가 패키지 연쇄 때문에 무너지는 Python 스크래퍼들과 비교하면 놀랄 만큼 밋밋합니다. 그리고 여기서는 밋밋한 게 칭찬입니다.
하나 정확히 짚고 갈 점이 있습니다. 나중에 직접 파보면 분명 헷갈릴 부분이라서요. Go proxy에 올라온 최신 모듈은 v2.3.0이고 2025년 12월에 공개됐습니다. 반면 GitHub Releases 페이지에서 보이는 최신 태그 릴리스는 v2.2.0으로 2025년 3월 버전입니다. 제가 테스트한 코드, 즉 v2.3.0은 저장소의 Releases 페이지보다 앞선 상태입니다. 이건 Go modules와 GitHub 태그가 시간이 지나며 어긋나는 특성 때문이지, 무언가 잘못됐다는 신호가 아닙니다. go get과 Releases 페이지에서 서로 다른 숫자를 보여줘도 놀라지 마세요.
실전 테스트 — “빠르다”의 숫자 뒤에 있는 것
Colly는 Go의 httptest 기반 자체 테스트 서버와 두 개의 공개 데모 사이트에 돌려봤습니다. 그래서 결과는 제가 들려주는 이야기가 아니라 재현 가능한 동작입니다. 결과는 아래와 같습니다.
| 테스트 | 대상 | 결과 |
|---|---|---|
| 정적 카탈로그 + 페이지네이션 | 로컬 피처 사이트 | 제품 12/12개, 리콜 1.0 |
| 기사 추출 | 로컬 피처 사이트 | 제목 + 문단 3/3개 |
| 동적 JSON API | 로컬 피처 사이트 | OnResponse로 항목 8/8개, 리콜 1.0 |
| HTTP 500 처리 | 로컬 피처 사이트 | OnError로 전달, 상태 500 |
크롤 그래프(MaxDepth 2) | 로컬 피처 사이트 | 17개 페이지 |
| Books to Scrape | 공개 데모 | 제품 20개 |
| 동적 페이지(자바스크립트 없음) | 로컬 피처 사이트 | 카드 0개(예상된 결과) |
| Quotes JS(렌더링 없음) | 공개 데모 | 0개(예상된 결과) |
위에서 아래로 읽어 보면 그림이 깔끔하게 맞물립니다. 정적 추출은 완벽했습니다. 카탈로그에서 제품 12개를 모두 뽑았고, 기사에서는 문단 3개를 전부 가져왔습니다. 모든 건 OnHTML 셀렉터로 처리됐습니다. JSON API 테스트에서는 HTML 파서를 아예 열지도 않았습니다. OnResponse가 본문을 넘겨줬고, 제가 직접 unmarshal 했으며, 8개 항목이 전부 돌아왔습니다. 500 테스트는 제가 가장 중시한 항목입니다. 크롤러를 밤새 돌려도 되는지 아닌지를 가르는 경계선이기 때문입니다. Colly는 실패를 OnError로 보내고, 상태를 명확히 드러냈습니다. 크래시도 없었고, 조용한 누락도 없었습니다. 공개 Books to Scrape 데모에서는 별도 처리 없이 제품 20개를 가져왔습니다.
크롤링 결과가 사실상 이 글의 헤드라인입니다. 표현을 조심해서 하겠습니다. MaxDepth(2)를 적용한 컬렉터가 링크를 따라가며 절대 URL로 해석한 결과, 제 피처 그래프에서 17개 페이지에 도달했습니다. 이게 “빠른 Go 크롤러”라는 말을 감정이 아니라 실제 페이지 수로 고정시킨 결과입니다. 다만 문장을 정확히 읽어야 합니다. 여기서 17개 페이지는 깊이 2 크롤의 결과입니다. 그 깊이 숫자는 제 테스트 하니스가 자체적으로 세어낸 것으로, 실행 구성을 설명하는 값입니다. Colly가 내부적으로 “정확히 depth 2까지만, 그 이상은 절대 안 됨”을 계약처럼 보장한다고 주장하는 것은 아닙니다. 검증 가능한 사실은 이겁니다. 깊이를 2로 제한했을 때, 크롤은 그래프를 따라 17개 페이지에 도달했습니다.
이제 한계입니다. 보통 “엄청 빠르다”는 글들이 여기서 조용해지죠. Colly는 자바스크립트를 실행하지 않습니다. 자바스크립트로 렌더링되는 피처에 돌렸더니 0개의 카드가 나왔고, 공개 Quotes to Scrape JS 페이지에 적용했을 때도 역시 0이었습니다. 이건 버그가 아니고, 단점이라고만 볼 것도 아닙니다. Colly는 HTTP 크롤러입니다. HTML을 내려받아 파싱할 뿐, 클라이언트 사이드 스크립트를 실행하기 위해 브라우저를 띄우지 않습니다. Scrapy 같은 HTTP 우선 크롤러들과 마찬가지로, 원하는 콘텐츠가 자바스크립트 실행 이후에만 나타난다면 Colly는 매번 빈 결과를 돌려줍니다. 아무리 빠르다고 해도 그 경계선은 바뀌지 않습니다. 렌더러를 붙이거나, 애초에 브라우저 렌더링이 내장된 도구를 써야 합니다.
또 하나 분명히 해두겠습니다. 제 결과를 증거 이상으로 확대 해석하지 않도록, 제가 하지 않은 테스트도 명확히 말하겠습니다. 비동기 컬렉터, 속도 제한과 예절(polititeness) 설정, 프록시 로테이션, 큐 및 저장 백엔드까지는 건드리지 않았습니다. Colly에는 그런 기능이 있습니다. 저는 추출과 크롤링의 핵심만 돌렸습니다. 저장소 README는 단일 코어에서 초당 천 건이 넘는 처리량을 언급하지만, 그건 프로젝트 자체의 수치입니다. 제가 측정한 것은 페이지 수와 리콜이지 처리량이 아닙니다. 따라서 제가 말하는 “빠르다”는 제가 실제로 계측한 컴파일된 Go 기반 추출 경로를 뜻하지, Scrapy와 정면 비교한 속도 벤치마크를 뜻하는 건 아닙니다.
장점과 단점
장점:
- 정적 추출에서 완전한 리콜을 보여줌 —
OnHTML로 카탈로그 제품 12/12개, 기사 문단 3/3개 추출 OnResponse로 JSON을 깔끔하게 처리, DOM 파싱 불필요 — API 항목 8/8개- 실패 라우팅이 정확함 — 500 응답이 크래시 없이
OnError로 전달되고 상태가 노출됨 - 단일 컬렉터로 깊이 제한 크롤이 17개 페이지까지 도달
- 하나의 정적 Go 바이너리, 런타임 의존성 0개 — 배포와 운영 측면에서 매우 깔끔함
- 관대한 Apache-2.0 라이선스
단점:
- 자바스크립트 실행 불가 — 클라이언트 렌더링 콘텐츠는 결과가 그대로 0
- Go 툴체인이 필요함; 이미 Go를 쓰는 팀이 아니라면 설정 비용이 먼저 듦
- 최신 모듈(
v2.3.0)이 최신 GitHub 릴리스(v2.2.0)보다 앞서 있어 Releases 페이지만 보는 사람은 헷갈릴 수 있음 - 결과물은 직접 작성한 코드에 달려 있음 — Scrapy처럼 데이터셋이나 피드 내보내기를 기본 제공하지 않음
- 비동기, 속도 제한, 프록시, 큐 백엔드는 존재하지만 이번 테스트에서는 검증하지 않음; 여기서 말하는 “빠르다”는 내가 측정한 추출 경로 기준이지, 정면 속도 비교 수치는 아님
Colly가 잘 맞는 사람, 그리고 피해야 할 사람
Colly는 이미 Go를 쓰고 있고, HTML 또는 JSON 기반 사이트를 빠르게 크롤링하려는 사람에게 잘 맞습니다. “깔끔한 배포”를 바이너리 하나 복사해서 실행하는 것으로 정의한다면 — 인터프리터도, virtualenv도, 의존성 복불복도 없이 — 이 도구는 바로 그런 성향을 위해 만들어졌다고 해도 좋습니다. 구조를 다루는 OnHTML, 원시 페이로드용 OnResponse, 그리고 평소에는 놓치기 쉬운 실패를 잡아주는 OnError 덕분에 콜백 모델은 금방 값어치를 합니다. CI에서 주기적으로 돌리는 정적 또는 API 기반 대상이라면, 아주 훌륭하고 부담 없는 선택입니다.
반대로 대상이 자바스크립트에 의존한다면, 최소한 다른 도구를 하나 더 붙이거나 아예 피하는 편이 낫습니다. 제가 돌려본 모든 클라이언트 렌더링 페이지에서 Colly는 0을 반환했으며, 그건 설정으로 바꿀 수 있는 문제가 아니라 설계 자체의 한계입니다. 팀이 Go를 쓰지 않아서 몇 개 사이트를 긁기 위해 굳이 툴체인을 새로 세우고 싶지 않다면, 그것도 피해야 할 이유입니다. 언어 자체를 유지보수하는 책임이 따라오기 때문입니다. 그리고 코드로 직접 파싱하기보다 구조화된 데이터를 바로 받아보고 싶다면, Colly의 콜백 구조는 결국 그 부담을 사용자 쪽에 남깁니다.
대안 — 관리형 AI 스크래핑 API는 어디에 맞는가
Colly는 무료 오픈소스 라이브러리이고, 직접 컴파일해서 직접 실행합니다. Go 코드, 콜백, 크롤 로직, 그리고 실행 머신까지 전부 본인이 책임집니다. 대신 요청당 비용은 없고 운영도 전부 내부에서 해결할 수 있습니다. Go를 쓰는 조직이라면 충분히 납득 가능한 선택이고, 단일 바이너리 배포는 정말 편합니다.
하지만 딱 멈추는 지점이 두 군데 있고, 그 두 지점은 다른 도구와 비교할 가치가 있습니다. 첫째, 자바스크립트입니다. Colly는 이를 렌더링하지 못하므로, 브라우저를 덧붙이지 않는 이상 클라이언트 사이드 콘텐츠는 대상이 아닙니다. 둘째, 구조화입니다. Colly는 콜백만 제공하고, 깔끔한 출력 형태를 만드는 일은 전부 사용자 코드 몫입니다. 관리형 AI 스크래핑 API는 이 두 문제를 다르게 풀어줍니다. Thunderbit의 개발자 스택은 JS 렌더링을 처리하고, 구조화된 데이터를 서버 측에서 반환합니다. POST /distill은 페이지를 깔끔한 LLM 친화 Markdown으로 바꿔 주며, 동적 콘텐츠와 안티봇 처리는 알아서 맡습니다. POST /extract는 사용자가 정의한 JSON Schema를 기준으로 구조화된 JSON을 반환하고, 페이지에 브라우저 렌더링이 필요하면 renderMode를 올릴 수 있습니다. AI 에이전트와 코딩 어시스턴트를 위한 Thunderbit MCP 서버도 있고, thunderbit_suggest_fields는 무료라서 본격적으로 쓰기 전에 페이지가 무엇을 드러내는지 미리 확인할 수 있습니다. 터미널, CI, 크론 작업용으로는 npx @thunderbit/thunderbit-cli CLI를 사용할 수 있습니다.
이 선택의 핵심은 뭐가 더 낫고 나쁘냐가 아닙니다. 일을 어디서 처리하느냐의 차이입니다. Colly를 쓰면 렌더링(없음), 파싱, 유지보수를 전부 자신의 컴파일된 바이너리 안에 묶어 두는 대신, 호출당 비용 없이 운영할 수 있고 사이트 구조가 바뀌면 직접 대응해야 합니다. 관리형 API를 쓰면 JS 렌더링, 안티봇, 구조화된 출력은 넘겨주고, 그 편의를 위해 호출당 비용을 지불합니다. 작고, Go 네이티브이고, HTML 또는 JSON 기반이며, 내가 책임지고 유지할 수 있는 대상이라면? Colly의 제어력과 속도가 확실히 이깁니다. 자바스크립트가 많은 페이지이거나, 콜백을 하나 더 쓰느니 스키마 형태의 JSON을 바로 받고 싶다면? 그 경우는 관리형 경로가 맞습니다. 더 넓은 지형도가 궁금하다면 최고의 웹 스크래핑 도구와 최고의 웹 스크래핑 GitHub 프로젝트 정리 글에서 Colly 같은 라이브러리가 브라우저 기반 및 관리형 옵션 사이 어디에 놓이는지 확인할 수 있습니다.
결론
Colly를 써야 할까요? 네, 단 당신이 Go를 쓰고 HTML이나 JSON을 빠르게 크롤링한다는 전제라면 그렇습니다. 이 도구는 “빠른 크롤러”라는 평판이 약속하는 일을 실제로 해내고, 이제 그 평판 뒤에는 숫자도 붙어 있습니다. 정적 추출은 완전한 리콜을 보였고, OnResponse로 JSON도 깔끔하게 처리했으며, 500은 OnError로 정확히 들어갔습니다. 깊이 2 크롤은 17개 페이지에 도달했습니다. 그리고 모든 것이 런타임 의존성 없는 하나의 정적 바이너리로 컴파일되니, 이 카테고리에서 배포 경험은 손꼽히게 편합니다.
다만 주장 범위는 정확히 보셔야 합니다. Colly는 자바스크립트를 전혀 렌더링하지 않습니다. 제 테스트에서 클라이언트 사이드 페이지는 모두 0이었고, 이건 놓친 설정이 아니라 영구적인 한계입니다. Go 툴체인도 필요하므로, Go를 쓰지 않는 팀은 초기 설정 비용을 치러야 합니다. 설치하는 모듈(v2.3.0)은 최신 태그 릴리스(v2.2.0)보다 앞서 있으니, 페이지 간 숫자가 다르다고 당황할 필요는 없습니다. 그리고 여기서 말하는 “빠르다”는 제가 계측한 추출 경로를 뜻할 뿐, 아직 돌려보지 않은 처리량 벤치마크를 뜻하는 건 아닙니다. 이 선을 정확히 이해한다면, Colly는 빠르고 믿을 수 있으며 실제로 배포 가능한 Go 크롤러입니다. 그리고 자바스크립트를 실행시키려는 요구만 내려놓는 순간, 그 평판은 충분히 납득됩니다.
웹 데이터 추출을 위해 Thunderbit 사용해보기 Get Started Free
자주 묻는 질문
Colly는 정말 빠른가요? 숫자로 증명할 수 있나요? 제가 측정한 핵심 경로 기준으로는 분명히 빠릅니다. 컴파일된 Go로 돌아가고, 정적 추출은 12/12개 제품을 모두 잡아냈으며, JSON도 깔끔하게 처리했고, 깊이 2 크롤은 17개 페이지에 도달했습니다. 모두 하나의 정적 바이너리로 구현됐습니다. 다만 Scrapy와의 처리량 벤치마크는 실행하지 않았으므로, “빠르다”는 표현은 정면 속도 비교가 아니라 제가 측정한 추출 동작으로 이해하는 것이 맞습니다.
Colly로 자바스크립트 렌더링 페이지를 스크래핑할 수 있나요? 아니요. Colly는 HTTP 크롤러라서 HTML은 내려받아 파싱하지만 브라우저를 실행하지는 않습니다. 자바스크립트로 렌더링되는 피처는 카드 0개가 나왔고, 공개 Quotes JS 페이지도 역시 0개였습니다. 클라이언트 사이드 콘텐츠가 필요하다면 Colly에 렌더러를 붙이거나, 브라우저 렌더링이 내장된 도구를 써야 합니다.
Colly를 쓰려면 Go를 알아야 하나요?
네. Colly는 독립 실행형 CLI가 아니라 Go 라이브러리입니다. import한 뒤 OnHTML, OnResponse, OnError 같은 콜백을 등록하고 컴파일해야 합니다. 제가 테스트한 머신에는 Go가 없어서, 먼저 툴체인(1.26.5)을 설치해야 했습니다. 팀이 이미 Go를 쓰고 있지 않다면, 이 환경 구성이 실제 비용입니다.
왜 설치한 버전이 Colly의 최신 GitHub 릴리스와 맞지 않나요?
Go 모듈과 GitHub 릴리스 태그가 서로 어긋나 있기 때문입니다. Go proxy의 최신 모듈은 v2.3.0(2025년 12월)이고, GitHub의 최신 태그 릴리스는 v2.2.0(2025년 3월)입니다. 제가 테스트한 것은 v2.3.0입니다. 모듈과 태그가 따로 움직이는 특성일 뿐, 설치가 깨졌다는 뜻은 아닙니다.
Colly는 상업적 용도로 무료인가요? 네, Apache-2.0 라이선스라서 관대하고 상업적으로도 부담이 적습니다. 다만 사용 전에 항상 repo에서 현재 라이선스를 직접 확인하는 것이 좋습니다.
