웹 스크래핑에 관한 빌드 대 바이 논쟁은 대부분 잘못된 질문에서 시작된다. 질문은 “우리가 스크래퍼를 만들 수 있는가?”가 아니다. 물론 만들 수 있다. 오후 시간과 몇 줄의 코드만 있으면 대부분의 페이지에서 데이터를 가져올 수 있고, 데모는 훌륭하게 작동할 것이다. 진짜 질문은 스크래핑 인프라를 규모 있게, 안정적으로, 대상이 적극적으로 저항하는 상황에서 매달 계속 운영하는 것이 팀에게 좋은 투자인가 하는 것이다. 이는 완전히 다른 질문이며, 데모는 이에 대해 아무것도 말해주지 않는다.
이 글은 이 질문에 정직하게 답하기 위한 결정 프레임워크다: 직접 구축하는 데 실제로 드는 비용은 무엇인지, 구매할 때 실제로 포기하게 되는 것은 무엇인지, 그리고 거의 아무도 직접 만들어서는 안 되는 단 하나의 계층은 무엇인지.
스크래퍼는 빙산의 일각이다
페이지를 가져와서 몇 개의 필드를 추출하는 스크립트는 전체 작업의 아마 10퍼센트 정도에 불과하다. 직접 구축하기로 결정하는 팀들은 거의 항상 이 10퍼센트만 가격을 매기고 나머지에 놀란다. 나머지 90퍼센트는 그 주변의 인프라이며, 스크래퍼와 달리 대부분은 결코 관심을 끊을 수 없다:
- 프록시 관리 — 여러 지역에 걸친 대규모 IP 풀을 확보하고, 로테이션하고, 로드 밸런싱하며, 성능이 저하되면 교체하는 작업.
- 안티봇 군비 경쟁 — 지난달에 통했던 회피 기법이 이번 달에는 통하지 않는다. 방어 기술이 지속적으로 진화하기 때문이며, 대상 자체가 계속 움직이는 목표물이다. 이는 끝낼 수 있는 작업이 아니다.
- 차단 및 콘텐츠 검증 —
200 OK가 실제로는 차단 페이지이거나 오염된 데이터이지 진짜 콘텐츠가 아님을 파악하고, 지능적으로 재시도하는 것. - 오케스트레이션과 확장 — 스케줄링, 동시성 제어, 우아한 실패 처리, 그리고 대상을 과도하게 두드리지 않으면서 워커 무리를 운영하는 작업.
- 모니터링, 재시도, 데이터 품질 — 성공률 대시보드, 백오프 로직, 그리고 나쁜 데이터가 조용히 데이터 웨어하우스에 도달하지 않도록 하는 검증 계층.
이 중 어느 것도 특별히 특이한 것은 아니지만, 모두 지속적인 작업이다. 스크래퍼를 만드는 것은 프로젝트다. 스크래핑 인프라를 운영하는 것은 제품이다. 판매할 생각도 없었던 제품이며, 실제 본업을 해야 할 엔지니어들이 그 일에 매달리게 된다.
구매할 때 포기하게 되는 것
구매의 논리는 정반대다: 다른 누군가가 그 러닝머신을 대신 돌려준다. 관리형 스크래핑 도구와 서비스는 안티봇 군비 경쟁을 흡수하고, 배관을 계속 작동시키며, 몇 분기가 아니라 며칠 만에 데이터에 도달하게 해준다. 하지만 트레이드오프 역시 실재한다. 데이터가 정확히 어떻게, 언제 수집되는지에 대한 통제력이 줄어들고, 볼륨이 커질수록 늘어나는 단위 비용을 떠안게 되며, 벤더의 로드맵과 가동 시간에 의존하게 되고, 데이터 품질을 처음부터 끝까지 직접 소유하는 대신 신뢰하고 검증해야 한다.
어느 쪽도 공짜가 아니다. 정직한 비교는 “저렴한 직접 구축 대 비싼 벤더”가 아니라 “엔지니어의 시간과 관심 대 벤더의 청구서와 통제력 상실”이다.
결정 프레임워크
세부 사항을 걷어내면 몇 가지 질문으로 귀결된다.
다음과 같은 경우 구축 쪽으로 기운다:
- 스크래핑이 제품이나 경쟁 우위의 핵심이지, 부수적인 입력값이 아닐 때. 수집 자체가 곧 비즈니스라면, 소유하는 것이 전략적이다.
- 대상이 특이하거나, 복잡하거나, 너무 많아서 기성 도구가 잘 맞지 않을 때.
- 물량이 크고 예측 가능해서, 소유의 단위 경제성이 요청당 가격을 능가할 때.
- 데이터의 신선도, 형태, 타이밍에 대한 완전한 통제가 필요할 때.
- 한 번 만드는 것이 아니라 실제로 유지 관리할 엔지니어링 여력이 있을 때.
다음과 같은 경우 구매 쪽으로 기운다:
- 스크래핑이 목적을 위한 수단일 뿐, 판매하는 다른 것에 들어가는 피드일 뿐 그 자체가 제품이 아닐 때.
- 대상이 표준적이고 이미 많이 다뤄진 것들일 때.
- 지금 당장 데이터가 필요하고, 장기적인 단위 비용보다 가치 실현 시간이 더 중요할 때.
- 팀의 시간이 실제 차별화 요소에 쓰일 때 더 가치 있을 때.
- 물량이 들쭉날쭉하거나 불확실해서, 피크에 대비해 인력을 두기보다 사용한 만큼 지불하고 싶을 때.
답변 대부분이 한쪽으로 쏠린다면 답은 나온 것이다. 대부분의 팀은 나뉘어 있음을 발견하는데, 이는 명시적으로 프레이밍되지 않은 선택지를 가리킨다.
거의 모두가 실제로 원하는 중간 경로
빌드 대 바이는 잘못된 이분법이다. 진짜 결정은 어떤 계층을 직접 만들고 어떤 계층을 빌릴 것인가이다. 스크래핑 스택은 하나의 단일한 것이 아니기 때문이다. 지속 가능한 원칙은 이렇다: 차별화된 것은 직접 만들고, 상품화되고 적대적인 것은 빌려라.
스크래핑 로직과 데이터 파이프라인, 특정 대상을 위한 파싱 규칙, 데이터셋의 형태, 그것이 제품에 흘러들어가는 방식, 이런 것들은 당신의 것이다. 그것이 당신의 지식이 담긴 곳이며, 소유할 가치가 있다. 하지만 모두에게 동일하고 자체 일정에 따라 저항하는 부분들, 특히 IP 계층은 빌리는 것이 최선인 상품이다. 이를 처음부터 만드는 것은 훨씬 낮은 비용에, 유지보수 부담 없이 살 수 있는 것을 재발명하기 위해 돈을 쓰는 셈이다.
거의 결코 직접 만들지 말아야 할 단 하나의 계층
이 글에서 하나만 가져간다면: 프록시 계층은 직접 만들지 말라.
레지덴셜 IP 네트워크는 스프린트 하나로 붙일 수 있는 컴포넌트가 아니다. 크고 깨끗하며 지리적으로 다양한 풀을 확보하고, 평판을 높게 유지하며, 주소가 소진됨에 따라 계속 유지 관리하는 것은 그 자체로 완전히 별개의 사업이며, 당신의 사업과는 아무 관련이 없는 사업이다. 그 위의 모든 것을 직접 만들지 구매할지와 상관없이, 프록시 계층은 빌려야 하는 부분이다. 이것이 중간 경로의 가장 명확한 예시다: 상품화되어 있고, 적대적이며, 소유할 가치가 거의 없을 만큼 전문화되어 있다.
이 지점에서 총소유비용 계산이 사람들을 놀라게 만들기도 한다. 팀들이 “직접 구축”의 비용을 집계할 때, 서버 청구서를 떠올린다. 실제 비용은 러닝머신 위에서 소비되는 엔지니어 시간이다. 빌린 계층이라면 처리했을 안티봇 회피와 프록시 배관 유지에 쓰이는 급여다. 인프라는 저렴하다. 그것을 계속 살아 있게 유지하는 사람들은 저렴하지 않으며, 대역폭 청구서와 달리 그들의 시간은 최적화한다고 해서 줄어들지 않는다.
결론
질문은 애초에 빌드 대 바이가 아니었다. 어떤 계층을 만들고 어떤 계층을 빌릴 것인가였다. 당신 것인 부분, 즉 로직, 데이터 모델, 제품에 공급되는 파이프라인은 직접 만들라. 그것이 당신의 차별화이며 어떤 벤더도 그것을 더 잘 만들어주지 못하기 때문이다. 상품화되고 적대적인 부분은 빌려라. 프록시 계층부터 시작해서 말이다. 그것들을 소유하는 것은 원하지도 않았던 두 번째 사업과, 당신의 로드맵과 경쟁하는 유지보수 러닝머신을 사는 것이기 때문이다.
어느 쪽으로 나누든, 두 경로가 공유하는 기반은 깨끗하고 안정적인 IP 풀이다. 그것이 제대로 갖춰야 할 계층이자 빌려야 할 계층이다. 저희의 레지덴셜 프록시는 나머지 모든 것을 직접 만들든 구매하든 그것이 의존하는 지역 커버리지와 풀 품질을 제공하며, GB당 가격 정책은 자체 네트워크를 운영하기 위해 인력을 두는 대신 실제로 수집한 만큼만 지불하게 해준다.