나는, 페이지 수나 속도 평판만으로는 알 수 없는 Colly의 동작을 확인하려고 검증용 고정 사이트를 만들었다. 확인하고 싶었던 건, 콜백이 기대한 레코드를 제대로 뽑아내는지, HTTP 에러를 알맞게 분류할 수 있는지, 깊이 제한이 걸린 그래프를 따라갈 수 있는지, 그리고 렌더링된 HTML 바깥에서 제공되는 콘텐츠까지 가져올 수 있는지였다. 이건 처리량 벤치마크가 아니라, 정확성과 경계 조건에 대한 리뷰다.
통제된 피처스에서는 기대한 정적 레코드를 전부 추출했고, 500 응답 1건은 OnError로 보냈으며, 설정한 깊이 제한 그래프에서는 17개의 URL을 순회했다. 반면, 요소가 JavaScript 실행 후에만 나타나는 2개 페이지에서는 타깃 요소가 0개였다. 직접 접근 가능한 JSON 엔드포인트는 브라우저 없이도 사용할 수 있었다. 이건 클라이언트 UI를 렌더링하는 경우와는 중요한 차이다.
Colly とは何か
Colly는 스스로를 “Golang용 세련된 스크래퍼 겸 크롤러 프레임워크”라고 설명하는데, 이 표현은 보기보다 의미가 깊다. 이는 Go 라이브러리로, GitHub 스타 수는 약 25,300개, 포크 수는 1,850개, 라이선스는 Apache-2.0이다. URL만 넣고 쓰는 CLI가 아니다. Go 코드 안에서 Colly를 import하고, 몇 개의 콜백을 등록한 뒤, 하나의 실행 파일로 컴파일한다.
생각하는 방식은 이벤트 드리븐이다. Collector에 핸들러를 차례로 붙인다. OnHTML은 CSS 셀렉터와 맞는 요소에서 추출을 실행하고, OnResponse는 원본 응답 본문을 넘겨주며, OnError는 요청 실패를 처리한다. 링크를 따라갈 때는 찾은 URL에 Visit()를 호출하고, MaxDepth로 순회 깊이를 제한한다. HTTP만 쓰는 경로라면 대상 호스트에 따로 Go 런타임이나 브라우저를 깔 필요는 없다. 다만 생성되는 바이너리가 완전히 정적이냐는 빌드 플래그와 CGO 사용 여부에 달려 있고, 이번 테스트에서는 거기까지는 기록하지 않았다.
主な機能と、その裏側の動き
먼저 이해해야 할 건 콜백 구조다. Colly가 일반적인 “요청하고 파싱하는” 스크립트와 다르게 느껴지는 건 이 구조 덕분이다. 이번 테스트는 전부 3개의 콜백으로 돌렸다.
OnHTML(selector, handler)는 핵심 기능이다. .product나 article p에 등록하면, Colly는 DOM을 파싱하면서 일치하는 요소마다 핸들러를 한 번씩 실행한다. 구조화 추출은 여기서 한다. 파싱 루프를 직접 짜는 대신 “무엇을 꺼낼지”만 지정하면 되니, 코드가 훨씬 깔끔해진다.
OnResponse(handler)는 그보다 한 단계 아래에 있고, 원본 바이트를 받는다. 대상이 HTML이 아니라 JSON을 돌려줄 때는 DOM을 아예 쓰지 않고, 본문을 직접 unmarshal 하면 된다. 내가 Colly로 JSON API를 깔끔하게 다룰 수 있던 것도 이 단일 콜백 덕분이었고, HTML 파싱은 전혀 필요 없었다.
OnError(handler)는 요청 실패를 처리하고, 호출 측에 응답 상태를 넘길 수 있다. 이번 테스트에서는 500 상태의 피처스 응답 1건이 등록된 콜백에 도달했다. 재시도, 타임아웃, DNS 실패, 연결 리셋, 콜백 panic, 지속 저장, 알림 전송은 테스트하지 않았다.
이 콜백들 위에는 두 가지 운영 기능이 있다. MaxDepth는 Colly의 깊이 의미 체계에 맞춰 링크 순회를 제한한다. 또 컴파일된 Go 실행 파일이라면 대상 호스트에 별도 언어 런타임을 넣을 필요가 없다. 이번 실행에서는 빌드 플래그나 CGO 상태를 기록하지 않았기 때문에, 생성된 바이너리가 전부 완전히 정적이라고 단정하지는 않는다.
セットアップ: 必要な Go ツールチェーン
의존성 이야기는 짧지만, 분명히 존재한다. 그래서 뭔가를 설치하기 전에 먼저 짚고 넘어간다. 이번 검증 머신에는 Go가 없었고, Colly는 Go 라이브러리다. 즉, 처음 한 일은 머신에 Go 툴체인을 깔는 것이었다(나는 Homebrew로 Go 1.26.5를 설치했다). 팀이 평소에 Go를 쓰지 않는다면, 여기서부터 마찰이 생긴다. Colly 자체보다도, 한 줄도 컴파일하기 전에 필요한 언어 환경 쪽이 더 큰 허들이다.
Go를 설치한 뒤에는 go get github.com/gocolly/colly/v2로 v2.3.0이 해결됐다. 검증한 경로에서는 브라우저도 headless Chrome도 필요하지 않았다.
다만 버전 표기는 조금 헷갈릴 수 있다. Go 모듈 쪽은 v2.3.0(2025년 12월 공개)으로 해결됐지만, GitHub Releases UI에서 보이는 최신 항목은 확인 시점 기준 v2.2.0(2025년 3월)이었다. 이건 모듈/리포지토리 버전 표기와 GitHub Release 항목의 차이이지, 모듈과 Git 태그의 차이는 아니다. 나는 v2.3.0을 검증했다.
実践: 抽出と運用境界
나는 Colly를 자기완결형 피처스 서버(Go의 httptest)와 2개의 공개 데모 사이트에 대해 실행했다. 현재 benchmark 디렉터리와 results/colly-test-summary.json에는 결과물이 있지만, 두 링크 모두 동작하는 브랜치를 가리킨다. 이 글에는 검증된 커밋, 정확한 명령어, 빌드 플래그, 피처스 seed가 없어서 아직 불변의 재현 절차라고 하긴 어렵다.
| 테스트 | 대상 | 결과 |
|---|---|---|
| 정적 카탈로그 + 페이지네이션 | 로컬 피처스 | 기대한 12/12 상품 추출 |
| 기사 추출 | 로컬 피처스 | 제목 + 3/3 문단 |
| 직접 JSON 응답 | 로컬 피처스 | OnResponse로 8/8 항목 획득 |
| HTTP 500 처리 | 로컬 피처스 | OnError로 분기, 상태 500 |
크롤 그래프(MaxDepth 2) | 로컬 피처스 | 17 페이지 |
| Books to Scrape | 공개 데모 | 20 상품 |
| 동적 페이지(JS 없음) | 로컬 피처스 | 카드 0개(예상대로) |
| Quotes JS(비렌더링) | 공개 데모 | 0개(예상대로) |
통제된 정적 피처스에서는 설정한 셀렉터 덕분에 기대한 12개 제품 레코드와 3개 문단 전부를 가져올 수 있었다. 직접 JSON 응답은 HTML 파서를 전혀 거치지 않았다. OnResponse가 본문을 넘겨줬고, 하네스 쪽에서 8개 항목 전부를 JSON 디코딩했다. 500 피처스 1건은 OnError에 도달했고, 상태도 보인 채로 크래시하지 않았지만, 그것만으로 무인 운영의 신뢰성이 증명되는 건 아니다. 공개 Books to Scrape 페이지에서는 셀렉터가 20개 상품을 반환해, 공개 사이트에서의 간단한 확인용으로 작동했다.
순회 쪽에서는 하네스의 seed-depth 규약에 따라 MaxDepth(2)를 설정했고, 피처스 그래프 안에서 17 URL을 방문했다. 이건 순회 범위의 결과이지 속도 결과가 아니다. 관찰한 트레이스는 임의의 그래프 전체에 대한 주장이라기보다, results/local_crawl_graph.json에 담긴 기록이다.
Colly는 JavaScript를 실행하지 않는다. JavaScript로 렌더링되는 피처스에서는 타깃 카드가 0개, 공개 Quotes to Scrape JS page에서도 타깃 인용문은 0개였다. 요소가 브라우저 실행 후에만 존재하고, 백엔드의 가져오기 대상도 사용할 수 없다면, HTTP 전용 경로로는 그걸 렌더링된 DOM으로 볼 수 없다. 렌더러를 붙이거나, 이번 JSON 피처스처럼 사용 가능한 백엔드 엔드포인트를 직접 호출해야 한다.
비동기 콜렉터, 레이트 제한이나 폴라이트니스 설정, 프록시 로테이션, 재시도, 큐나 스토리지 백엔드는 검증하지 않았다. 경과 시간, 처리량, 동시 실행 수, CPU, 메모리, 대상 지연시간, 비교용 베이스라인도 측정하지 않았다. 따라서 이 글은 속도나 무인 운영의 신뢰성에 대해 아무 말도 하지 않는다.
フィクスチャ結果の読み方
성공한 3개의 콘텐츠 경로는 각각 다른 계약을 시험한다. 카탈로그와 기사 케이스에서는 서버가 돌려준 HTML에 대한 CSS 셀렉션을 검증한다. 분모는 추출 전에 정의한 피처스 기대값, 즉 12개 상품 레코드와 3개 문단이다. 내가 이를 “기대 레코드 추출”이라고 표현한 건 의도적이다. 이번 실행에서는 애매한 일치, 중복 처리, 부분 필드 허용, 코퍼스 전체에서의 재현율 같은 정의는 하지 않았다. 그러니 이 결과를 일반적인 추출 정확도로 확장하면 안 된다.
JSON 케이스는 DOM 셀렉션을 우회한다. Colly는 OnResponse를 통해 응답 바이트를 받고, JSON 디코딩은 하네스가 한다. 그렇다고 해서 “Colly는 JavaScript를 렌더링하지 않는다”는 사실이 클라이언트 의존 사이트를 전부 배제한다는 뜻은 아니다. 클라이언트가 쓰는 데이터 소스에 직접 접근할 수 있고, 브라우저 밖에서도 재현 가능한 요청이라면 HTTP 크롤러로 충분한 경우가 있다. 인증, 생성된 시그니처, 브라우저 전용 상태, 안티봇 제어가 있으면 이야기가 달라지지만, 이번에는 그 어떤 것도 시험하지 않았다.
500 루트는 복구가 아니라 디스패치 확인이다. 등록된 OnError 콜백이 그 피처스 응답과 상태를 받았다는 뜻이다. 프로덕션 크롤러라면 재시도 가능한 코드, 백오프, 치명적 실패, 지속 저장, 알림에 대한 명확한 방침이 필요하다. 이번 테스트는 그런 판단 근거를 제공하지 않으며, “콜백이 발화했다”는 사실을 “잡을 무인으로 신뢰할 수 있다”는 뜻으로 읽으면 안 된다.
17 URL 그래프도 마찬가지로 제한적이다. 이건 이 피처스, 이 seed 규약, 그리고 MaxDepth(2)로 생성된 방문 집합을 확인한 것이다. 초당 페이지 수, 호스트 간 공정성, 메모리 증가, 순환 URL이나 중복 URL 형식에 대한 동작은 보여주지 않는다. 그런 확인에는 별도의 워크로드 테스트와 큐 테스트가 필요하다.
今回の実行に基づく選定チェックリスト
먼저, Colly가 실제로 받는 응답을 확인하라. 필요한 필드가 서버가 돌려주는 HTML 안에 있다면 OnHTML을 쓰고, 레코드를 받아들이기 전에 필드 수와 필수 키를 검증한다. 응답이 JSON이면 OnResponse로 본문을 처리하고 스키마를 검증한다. HTML이 단지 애플리케이션의 외피일 뿐이라면, 브라우저를 추가하기 전에 접근 가능한 백엔드 요청에 데이터가 들어 있는지 먼저 살펴보라.
| 응답에 들어 있는 것 | Colly 경로 | 수락 확인 |
|---|---|---|
| 서버가 돌려주는 HTML에 필요한 필드가 있음 | OnHTML 셀렉터 | 필수 키와 기대 레코드 수 |
| 직접 호출 가능한 JSON 페이로드가 있음 | OnResponse + JSON 디코딩 | 스키마와 필수 필드 검증 |
| 재현 가능한 요청으로 뒷받침되는 HTML 셸 | 백엔드 엔드포인트 호출 | 상태, 스키마, 완전성 |
| 브라우저 실행 후에만 생성되는 데이터 | 렌더러를 추가하거나 브라우저 크롤러 선택 | 대상별 준비 완료와 완전성 |
브라우저 실행이 필요하다면, Colly의 플래그로 렌더링을 켤 수 있다고 기대하지 말고, 별도 컴포넌트로 다뤄라. 브라우저는 준비 완료를 확인하고, 렌더링된 콘텐츠나 백엔드 응답을 노출한 뒤, 그 데이터를 나머지 파이프라인에 넘겨야 한다. 이번 리뷰에서는 그런 통합을 테스트하지 않았다.
프로덕션 도입에서는 Go 버전, 모듈 버전, 빌드 플래그, CGO 상태, 정확한 명령어, 피처스 seed, 리포지터리 커밋을 기록하라. 현재 공개 링크에는 그게 없어서, 검증 가능한 결과물과 지속 가능한 재현성 사이에 차이가 생긴다. 운영 면에서는 실패 매트릭스를 준비하고, 빠르고 믿을 만하다고 판단하기 전에 실제로 중요한 워크로드를 측정해야 한다.
長所と短所
장점:
OnHTML로 기대한 카탈로그 상품 12/12개와 기사 문단 3/3개를 추출할 수 있었다.OnResponse를 통한 JSON 처리가 깔끔했고, DOM 파싱이 필요 없었다. API 항목 8/8개.- 검증한 500 응답은
OnError에 도달했고, 상태도 확인할 수 있었다. - 깊이 제한 크롤링으로 단일 콜렉터에서 17페이지에 도달할 수 있었다.
- Go 실행 파일로 컴파일되기 때문에, 검증한 경로에서는 대상 쪽에 별도 Go 런타임이 필요 없었다.
- Apache-2.0의 느슨한 라이선스.
단점:
- JavaScript 실행 없음. 클라이언트 렌더링 콘텐츠는 0개였고, 그건 분명하다.
- Go 툴체인이 필요하다. Go가 익숙하지 않은 팀은 스크래퍼를 쓰기 전에 이 설정 비용을 감수해야 한다.
- 검증한 모듈(
v2.3.0)은 확인 시점의 GitHub Release 최신(v2.2.0)보다 앞서 있었다. - 출력은 자체 코드에 의존한다. Colly는 Scrapy처럼 내장 데이터셋/피드 익스포터를 제공하지 않는다.
- 비동기, 레이트 제한, 프록시, 큐 백엔드는 존재하지만 이번에는 검증하지 않았다. 처리량과 규모도 측정하지 않았다.
向いている人・向いていない人
이미 Go를 쓰고 있고, 대상이 서버 생성 HTML이나 직접 접근 가능한 JSON이라면 Colly는 잘 맞는다. 콜백 모델 덕분에 구조화 매칭, 원시 페이로드, 요청 실패가 분리된다. 컴파일된 실행 파일이므로 대상 머신에 별도 언어 환경을 깔지 않아도 된다는 점도 장점이다. 다만 완전 정적 링크인지 여부는 여기서 검증하지 않았다.
필요한 타깃 요소가 브라우저 실행 후에만 나타나고, 쓸 만한 백엔드 엔드포인트도 없다면 렌더러를 추가해야 한다. 직접 JSON 엔드포인트가 있다면 렌더링 없이도 가져올 수 있다. 그리고 Go 툴체인을 넣고 싶지 않은 팀이나, 추출 서비스 쪽에서 스키마 정리와 셀렉터 관리까지 맡기고 싶은 팀에는 Colly가 그다지 맞지 않는다.
代替案と、その中での Thunderbit の位置づけ
Colly는 직접 운영하는 오픈소스 소프트웨어다. 벤더 사용료는 없지만, 컴퓨트 자원, 대역폭, 프록시, 스토리지, 가시성, 그리고 엔지니어링 비용은 직접 부담해야 한다. 대상이 렌더링을 필요로 하면, 요청 동작, 파싱용 콜백, 크롤 로직, 브라우저 통합까지 스스로 갖춰야 한다.
매니지드 추출 서비스는 이런 책임의 일부를 벤더 쪽으로 넘긴다. 우리는 Thunderbit를 만들고 있지만, 이번 피처스에서는 테스트하지 않았기 때문에 여기서는 렌더링, 안티봇, 품질, 지연시간, 비용 비교를 하지 않았다. 여기서 말할 수 있는 차이는 “책임의 위치”다. Colly는 HTTP 응답과 콜백을 Go 프로세스 안에서 다룬다. 반면 매니지드 서비스는 가져오기와 스키마 정리를 건당 요금으로 맡아줄 수 있다.
관련 벤치마크 리뷰: 오픈소스 스크래퍼 완전 비교, Scrapy의 Python 크롤러 समीक्षा, Scrapling의 적응형 셀렉터 리뷰。
結論
Colly는 서버 생성 HTML이나 직접 JSON을 대상으로 하고, 자체 추출 코드를 갖고 있는 Go 팀에게 강력한 후보다. 이번 피처스가 보여준 건 기대 레코드 추출, 한 번의 경계 있는 크롤 트레이스, 그리고 한 번의 500 콜백이다. 속도, 규모, 무인 운영 신뢰성까지 보여주진 않았다. 브라우저로 렌더링되는 DOM은, 기반 데이터 엔드포인트를 직접 호출할 수 없는 한 별도 경로가 필요하다.
Web 데이터 추출에 Thunderbit 체험하기 Get Started Free
FAQ
이 리뷰에서 Colly의 속도를 측정했나요?
아니요. 측정한 건 기대 레코드 추출, 직접 JSON 처리, 1건의 에러 콜백, 그리고 피처스 크롤 그래프의 커버리지였다. 경과 시간, 처리량, 동시 실행 수, CPU, 메모리, 비교용 베이스라인은 측정하지 않았다.
Colly로 JavaScript 렌더링 페이지를 스크래핑할 수 있나요?
Colly는 페이지의 JavaScript를 실행하지 않는다. 그래서 검증한 HTTP 경로에서는 렌더링된 DOM에만 나타나는 타깃 요소를 가져올 수 없었다. 다만 JSON 피처스가 보여주듯, 접근 가능한 백엔드 JSON 엔드포인트는 직접 호출할 수 있다. 실행이 필수이고, 재현 가능한 백엔드 요청으로 데이터를 얻을 수 없다면 렌더러를 써라.
Colly를 쓰려면 Go를 알아야 하나요?
네. Colly는 독립형 CLI가 아니라 Go 라이브러리다. import하고, 콜백(OnHTML, OnResponse, OnError)을 등록한 뒤, 컴파일해야 한다. 이번 검증 머신에는 Go가 없어서 처음엔 Go 툴체인(1.26.5) 설치부터 시작했다. 팀이 이미 Go 세계에 있지 않다면, 이 환경 구축이 진짜 도입 비용이다.
설치한 버전이 왜 Colly의 최신 GitHub Release와 맞지 않나요?
Go 모듈은 v2.3.0(2025년 12월)으로 해결됐지만, 확인 시점에 보인 GitHub Release 최신은 v2.2.0(2025년 3월)이었다. 나는 v2.3.0을 검증했다. 이건 버전 표기의 차이일 뿐, 설치 실패의 증거는 아니다.
Colly는 상업용으로 써도 무료인가요?
네, Apache-2.0이라 상업용으로도 비교적 쓰기 좋은 라이선스다. 그래도 도입 전에 반드시 repo에서 최신 라이선스를 확인하라.
프로덕션에 넣기 전에는, 피처스 결과를 억지로 일반화하지 말고 운영 리스크에 맞는 테스트를 추가하라. 대표 대상에서 반복 크롤링 시간을 재고, CPU와 피크 메모리를 기록하고, 재시도 가능한 실패와 치명적 실패를 모두 시험하고, 동시 실행 시 폴라이트니스를 확인하라. 지속 저장이 중요하면 중복 처리와 큐 상태를 보면서 크롤을 멈췄다가 다시 시작해라. 배포의 간편함이 중요하면 컴파일러와 링커의 정확한 설정을 기록하고, 생성된 실행 파일의 런타임 의존성을 확인해라. 이런 확인은 이번 피처스가 보여준 내용을 바꾸지 않는다. 다만 그 라이브러리 구성이 특정 프로덕션 잡에 맞는지 판단하게 해줄 뿐이다.
