시스템 디자인

웹 스크래핑: 성공하면 혁명 실패하면 반역 아입니까!

양날의 검과 같은 웹 스크래핑의 모든 것을 소개합니다

2024.08.24 | 조회 387 |
0
|

데브필 DevPill

Top 1% 개발자로 거듭나는 성공 처방전

Introduction

"API가 없으면? 그냥 스크래핑하면 되지!"

개발자라면 누구나 한 번쯤 이런 생각을 해봤을 겁니다. 웹 스크래핑. 많은 개발자들이 알고 있지만, 공개적으로 이야기하기를 꺼리는 주제입니다. 필요한 데이터는 있는데 공식적인 방법으로는 접근할 수 없을 때, 웹 스크래핑은 마치 개발자의 비밀 병기 같은 존재죠.

하지만 최근 ChatGPT를 비롯한 AI 기술의 폭발적인 성장으로, 웹 스크래핑은 더 이상 개발자들만의 비밀 도구가 아닙니다. AI 모델 학습에서부터 실시간 정보 수집까지, 그 활용 범위가 기하급수적으로 넓어지고 있습니다.

동시에 법적, 윤리적 논란도 커지고 있습니다. "이렇게 수집한 데이터, 정말 합법적일까?", "다른 회사의 서비스를 크롤링해도 되는 걸까?" 많은 개발자들이 이런 고민을 안고 있죠.

오늘은 12년간 스타트업을 운영하며 웹 스크래핑의 명과 암을 모두 경험한 CTO의 솔직한 이야기를 들어봅니다. 그가 공개하는 웹 스크래핑의 놀라운 활용 사례들, 그리고 이를 둘러싼 기술적, 윤리적 도전과제들까지.

 이 글을 통해 여러분은 단순한 데이터 수집을 넘어, 웹 스크래핑을 전략적 도구로 활용하는 방법을 배우게 될 것입니다. 동시에 개발자로서 지켜야 할 윤리적 가이드라인에 대해서도 진지하게 고민해보는 시간이 될 것입니다.


제가 이전에 대표로 있던 스타트업인 Wanderio에 대해 소개할 때, API가 없는 교통 공급업체들을 통합해야 했던 것을 포함해 우리가 겪었던 가장 큰 도전 과제들에 대해 설명하곤 했습니다. 그 당시 이를 극복하기 위해 우리는 종종 웹 스크래핑(web scraping, 역: 웹사이트의 모든 데이터를 다 긁어오는 크롤링과 달리 특정 데이터를 추출하는 것을 스크래핑이라 칭함)에 의존했고, 실제로 많은 스크래핑을 수행했는데요. 시간이 지나면서 우리의 스크래핑 기술은 더 많은 곳에서, 그리고 예상치 못한 상황에서 유용하게 쓰였죠.

예를 들자면:

  • 일부 공급업체의 API가 정확히 99.99% 가용성을 보장하지 않아서, API가 다운됐을 때 대체 방법으로 스크래핑을 사용하기도 했습니다(웹사이트는 종종 계속 작동했기 때문이죠).
  • 어떤 때는 공급 업체의 API가 불완전해 일부 작업은 스크래핑을 통해서만 가능했습니다.
  • 일부 데이터는 퍼블릭 웹사이트에서만 사용 가능했습니다(예: 공항 지리 데이터). 우리는 이를 웹에서 추출했죠.

 

이러한 경험 덕분에 웹 데이터를 제대로 추출(스크래핑)하는 것이 기술 전략에 있어 중요한 도구라고 믿습니다.

그럼에도 불구하고, 이 분야가 크게 오해받고 있다고 느낍니다. 다른 기술 리더들과 스크래핑에 대해 이야기할 때, 우려되는 점을 주로 세 가지 정도 발견하는데요:

  • 🎯 사용 사례 — 사람들은 스크래핑을 어디에 사용해야 할지 모릅니다.
  • 🔌 구현 — 웹 데이터 추출은 지나치게 복잡하고 취약한 것으로 인식됩니다.
  • ❤️ 법적 및 윤리적 우려 — 스크래핑은 다소 불명확한 평판을 가지고 있습니다.

오랜 논쟁거리였지만, 이제는 이 모든 것에 대한 확실한 답변이 있습니다. 사용 사례는 풍부하고, 책임감 있는 스크래핑이 존재하며, 구현은 불과 몇 년 전보다 10배는 쉬워졌습니다.

기술 분야에서 스크래핑의 역할은 점진적으로 성장했습니다. 그러다 특정 시점에 갑자기 크게 성장했는데요, 맞습니다. 바로 AI(LLM)가 등장한 순간이죠.

LLM(대규모 언어 모델)은 두 가지 측면에서 웹 데이터에 크게 의존하기 때문에 스크래핑이 적절한지에 대한 논의를 다시 불붙였습니다. 바로 아래 두 가지인데요:

  • 모델 훈련 — 모델들은 웹 데이터로 광범위하게 훈련됩니다.
  • 에이전트 행동 — 모델들이 사용자 질문에 답하고 (가능하면) 행동을 취하기 위해 실시간 네비게이션을 수행해야 합니다.

그래서 오늘의 글은 웹 데이터 수집에 대한 오해를 풀어내고, 이를 팀에 어떻게 활용할 수 있는지, 그리고 활용해야 하는지 탐색하고자 하는 엔지니어링 리더의 관점에서 접근합니다.

우리는 위의 세 가지 고려 사항을 다루면서 업계의 실제 사례와 데이터, 그리고 제 자신의 경험을 함께 풀어보려고 해요.

오늘 글의 목차는 아래와 같습니다:

  • 🎯 웹 데이터를 어디에 사용할 수 있는가? — 가장 인기 있는 (때로는 놀라운) 사용 사례들을 살펴봅니다.
  • 🔌 웹 데이터를 어떻게 수집하는가? — 주요 네 가지 방법과 이를 구현하는 최선의 옵션들을 알아봅니다.
  • ❤️ 어떻게 책임감 있게 스크래핑을 할 수 있는가? — 규제 프레임워크와 이에 대한 개인적인 도덕적 나침반을 소개합니다.

자, 시작해 봅시다!

🎯 웹 데이터를 어디에 사용할 수 있을까?

제 경험상, 웹 데이터의 사용 사례는 크게 두 가지 카테고리로 나눌 수 있는데요:

  • ➡️ 직접적 — 제품의 가치 제안과 직접 연결된 특정 용도.
  • ⬅️ 간접적 — 2차적 이점, 더 일반적이고 널리 적용 가능한 용도.

직접적 사용 사례는 웹 데이터를 집계, 요약, 검토하고 일반적으로 변환함으로써 가치를 창출하는 제품을 위한 것입니다.

이러한 사례는 많이 있습니다. 다음과 같은 것들을 생각해 보세요:

  • 여행 분야의 검색 엔진 — Skyscanner나 Kayak 같은 서비스.
  • 전자상거래 집계 서비스 — Google 쇼핑과 비슷한 서비스.
  • SEO 도구 — Ahrefs나 Semrush 같은 서비스.
  • 브랜드 모니터링 도구 — Mention이나 Brandwatch 같은 서비스.

이들은 모두 특정 목적을 위한 사용 사례입니다. 여러분의 제품을 살펴보고 웹 데이터를 통해 더 많은 가치를 제공할 수 있는지 고민해 보면 비슷한 전략을 찾을 수 있습니다.

또한 많은 회사에 적용되는 일반적인 사례 역시 있습니다. 다음은 제가 가장 좋아하는 예시들인데요:

1) 보안 🔒

위협 인텔리전스 피드(사이버 보안에서 위협 정보를 제공하는 데이터 스트림. 예시 리스트)와 웹상의 업계 뉴스를 활용하여 새로운 보안 위험을 감지할 수 있습니다.

여러분의 비즈니스에 따라 이를 통해 많은 것을 예측, 예방, 또는 완화할 수 있는데요. 예시로는 기술적 취약점, 피싱 시도, 데이터 유출, 정보 도난 등이 있습니다.

예를 들어, 금융 기관들은 다크웹 포럼에서 도난된 신용카드 번호에 대한 언급을 모니터링하여 선제적으로 고객에게 알리고 사기를 예방할 수 있습니다.

2) 시장 및 경쟁사 인사이트 📈

웹 데이터는 당연히 여러분의 시장과 경쟁사에 대한 정보의 보고입니다. 일부 비즈니스에서는 이것이 큰 영향을 미치지 않지만, 다른 곳에서는 매우 중요합니다.

전자상거래 스토어를 생각해 보세요:

  • 🏷️ 동적 가격 책정(Dynamic pricing) — 경쟁사 웹사이트, 제품 페이지, 딜 사이트에서 데이터를 가져와 자동으로 가격 결정에 반영할 수 있습니다.
  • 🚀 제품 출시 추적(Track product launches) — 여러분과 관련된 새로운 제품 발표를 지속적으로 확인할 수 있습니다(예: 여러분이 판매할 수 있는 새로운 아이템).
  • 😊 고객 감성 분석(Analyze customer sentiment) — 다양한 플랫폼에서 고객 리뷰와 평점을 수집하고 분석하여 시장 트렌드를 이해할 수 있습니다.

3) 브랜드 건강 및 고객 지원 🩺 

소셜 미디어 분석, 온라인 리뷰 및 평점을 통해 브랜드의 건강 상태를 모니터링하고 브랜드 인식에 대한 인사이트를 얻을 수 있습니다. 같은 접근 방식을 사용하여 문제를 감지하고 선제적인 고객 지원을 제공할 수 있죠. 예를 들어, 많은 통신사들이 이 방법을 사용하여 네트워크 문제를 발견합니다.

4) AI 모델 구축 🤖 

마지막으로, AI는 메타 사용 사례로 두드러집니다. 웹 데이터를 사용하여 기본 모델을 미세 조정하거나 위에서 언급한 사용 사례를 포함한 다양한 용도로 RAG(Retrieval-Augmented Generation) 시스템을 만들 수 있습니다.

 

🔌 웹 데이터를 어떻게 수집하는가 

웹 데이터를 추출하는 방법은 구매에서 직접 구축까지 다양한 스펙트럼이 있습니다. 주요 네 가지 방법을 살펴보고 각각의 장단점과 이상적인 사용 사례에 대해 논의해 보겠습니다:

1) 사전 준비된 데이터셋 🗃️ 

여러 회사들이 다양한 주제에 대해 미리 수집된 데이터셋을 제공합니다. Bright Data, Oxylabs, Webz 등이 그 예입니다.

이러한 데이터셋은 비싸지만 매우 풍부하며 정기적으로 새로운 정보로 갱신됩니다. 예를 들어, 약 5만 달러로 다음과 같은 데이터를 구매할 수 있습니다:

  • 💼 5억 개의 LinkedIn 프로필 레코드 — 대규모 아웃리치 캠페인을 위한 데이터.
  • 🛒 2억 7천만 개의 Amazon 제품 레코드 — 전자상거래 시장 분석, 가격 책정 정보, 트렌드 예측을 위한 데이터.
  • 🏠 1억 3천만 개의 Zillow 매물 목록 — 부동산 트렌드와 투자 기회를 발견하기 위한 데이터.

이 접근 방식의 주요 장점은 당연히 편의성입니다: 직접 수집할 필요 없이 정제되고 구조화된 데이터를 얻을 수 있습니다

단점은 1) 비용, 2) 실시간 데이터가 아님, 3) 인기 있는 웹사이트에 대해서만 사용 가능하다는 점입니다.

2) 웹사이트를 감싸는 서드파티 API 🕷️ 

데이터셋을 구매할 수 있는 것처럼, Amazon이나 Google 같은 인기 웹사이트를 래핑하는 API에 대한 액세스 권한을 구매할 수도 있습니다.

이는 종종 혼란스러운 제안일 수 있습니다. 처음에는 '왜 같은 서비스의 API 대신 래퍼를 사용해야 하지?'라고 생각할 수 있기 때문입니다.

답변은 서비스에 따라 다르지만, 검색 엔진(SERP) API를 예로 들어보겠습니다. 이는 아마도 기술 분야에서 가장 많이 래핑되는 API일 것입니다:

  • 📊 높은 한도 — 래핑된 SERP API는 일반적으로 직접 API 한도에 비해 데이터 접근에 대한 더 높은 임계값을 제공합니다. 단일 쿼리로 더 많은 데이터를 검색할 수 있어 광범위한 연구에 중요합니다.
  • 👔 맞춤형 — SERP API는 보통 특정 사용 사례에 맞춰져 있어 1) 사용하기 더 쉽고, 2) 기능이 더 풍부합니다. 예를 들어, Tavily는 LLM에 최적화된 매우 간소화된 API를 제공합니다; SEO를 위한 SERP API는 과거 순위, 검색 볼륨, 도메인 인사이트 등을 추가합니다.
  • 💪 복원력 — 일반적으로 IP 차단 및 CAPTCHA 문제에 대한 완화 방안이 있습니다.
  • 🌐 다중 공급자 — 마지막으로, 더 균형 잡힌 관점을 제공하기 위해 여러 검색 엔진의 결과를 제공할 수 있습니다.

3) 호스팅된 스크래핑 API / 도구 🖥️ 

더 많은 유연성이 필요하지만 모든 것을 처음부터 다시 만들고 싶지 않다면, 서비스로 제공되고 있는 많은 웹 스크래핑 서비스와 API가 존재합니다.

이러한 서비스는 모든 웹사이트에서 데이터를 스크랩할 수 있는 엔드포인트와 인프라를 제공합니다. 인기 있는 예로는 ScrapingBee, Scrapfly, 그리고 물론 Bright Data 자체가 있습니다.

특별히 언급할 만한 것으로 ParseHub가 있는데, 이는 노코드 스크래핑을 위한 데스크톱 앱입니다. 이는 결과를 클라우드에 저장할 수 있게 해주고 추출된 데이터에 프로그래밍 방식으로 접근할 수 있는 REST 엔드포인트를 제공합니다. 이는 조금 특이한 워크플로우지만 좋습니다!

이러한 서비스는 인프라를 대신 처리해주고 사용하기 쉬운 API를 제공하므로, 완전한 사내 구현과 비교했을 때 좋은 중간 단계입니다.

4) 처음부터 구현하기 🔧 

개발자들이 유료 스크래핑 서비스를 볼 때 항상 놀라는 것은 그 비용입니다.

위에서 언급한 서비스들의 기본 요금제 가격으로, 쉽게 100배 이상의 요청을 처리할 수 있는 서버를 임대할 수 있습니다.

문제는 스크래핑이 간단해 보이지만 실제로는 그렇지 않은 작업 중 하나라는 것입니다. 제 경험상 세 가지 주요 과제가 있습니다:

  • 🎭 동적 콘텐츠 — 현대의 JavaScript 중심 웹사이트는 스크래핑하기가 까다로울 수 있습니다. 모든 데이터에 접근하려면 페이지를 제대로 렌더링해야 합니다.
  • 🧩 CAPTCHA — 많은 웹사이트가 스크래핑을 좋아하지 않아 사람임을 증명하기 위해 CAPTCHA를 표시합니다.
  • 🚫 IP 차단 — 웹사이트가 여러분의 스크래핑을 감지하면 IP 주소를 차단할 수 있습니다.

이러한 문제들을 하나씩 해결할 수 있는 방법은 많지만, 항상 간단하지는 않습니다. 따라서 1) 웹 스크래핑이 여러분 비즈니스의 100% 핵심이 아니거나, 2) 관련된 중요한 IP를 구축하고 싶지 않거나, 3) 볼륨이 매우 높아 비용이 문제가 되지 않는 한, 모든 것을 처음부터 구현하는 것을 권장하지 않습니다.

그래도 이 방식을 선택하고 싶다면, 다음은 제 추천사항입니다. 기술 선택은 주로 스크래핑해야 할 웹사이트의 유형에 따라 다릅니다:

복잡하고 상호작용이 필요한 JavaScript가 많은 사이트에서 사용자 상호작용이 필요한 경우, Playwright를 추천합니다. Playwright는 주로 e2e 테스팅으로 알려져 있지만, 매우 유연하고 브라우저 동작을 쉽게 자동화할 수 있어 스크래핑 작업에 적합합니다.

반면에, JavaScript를 실행할 필요가 없는 더 간단하고 정적인 페이지를 다룬다면, Python의 Scrapy나 BeautifulSoup 같은 라이브러리가 더 간단한 선택이 될 것입니다.

❤️ 어떻게 스크래핑을 책임감 있게 할 것인가 

웹 스크래핑을 책임감 있게 할 수 있을까요? 간단한 답변은 '예'이지만, 사실 그리 간단하지는 않습니다.

이는 여전히 대부분 미개척 영역이므로, 현재의 규제 프레임워크와 제 개인적인 도덕적 나침반 모두를 살펴보겠습니다.

1) 규제 프레임워크 📜 

법적인 측면은 여전히 모호하고 해석의 여지가 있지만, 다음은 염두에 둘 수 있는 몇 가지 가이드라인입니다:

  • 😇 공정하고 변형적인 사용 — 미국과 같은 일부 관할권에서는, 1) 스크래핑된 데이터의 사용이 충분히 변형적이고(예: 연구, 논평, 비평을 위해) 2) 원 콘텐츠 소유자의 시장을 해치지 않는다면 공정 사용 원칙에 따라 스크래핑이 보호될 수 있습니다.
  • 📝 계약상 의무 — 많은 웹사이트의 이용 약관에서 명시적으로 스크래핑을 금지하고 있습니다. 이러한 약관을 위반하면 계약 위반으로 법적 조치를 받을 수 있습니다. 문제는 웹사이트가 이러한 계약을 언제 강제할 수 있는지가 항상 명확하지 않다는 것입니다. 실제로... 👇
  • 🌐 공개 웹페이지 — 일부 법원은 공개적으로 접근 가능한 데이터(예: 로그인 벽 뒤에 있지 않은 데이터)를 스크래핑하는 것은 무단 접근에 해당하지 않으며, 사용자가 명시적으로 동의하지 않았기 때문에(로그인했다면 동의했을 것처럼) 이용 약관을 강제할 수 없다고 판결했습니다.

또한 CAPTCHA와 IP 차단을 우회하는 것이 일반적으로 무단 접근으로 간주되지 않는다는 점도 주목할 만합니다:

법원은 추가적으로 [...] CAPTCHA와 같은 접근 제한을 우회하기 위해 자동화된 도구를 사용하는 것이 "암호로 보호된 웹사이트"에 접근하는 것과 같다는 주장에 동의하지 않았습니다.

그렇다면 이는 우리를 어디로 이끄나요?

2) 도덕적 나침반 🧭 

제 첫 번째 관찰은, 법적 프레임워크가 불확실하거나 모순될 때마다, 윤리적 고려사항을 무시하고 맹목적으로 의존할 수 없다는 것입니다. 실제로 이는 항상 사실이며, 규제가 불명확할 때만 그런 것은 아니지만, 이 경우에는 특히 그렇다고 주장할 수 있습니다.

물론, 이는 개인적인 입장입니다. 이것이 보편적으로 유효해야 한다고 주장할 의도는 없으며, (대부분의 경우🙃) 다르게 행동하는 사람들을 판단하지도 않을 것입니다.

우리는 규칙에 따라 게임을 하지만, 여전히 이 규칙의 경계가 무엇인지 결정할 수 있습니다. 어떤 사람들에게는 그것이 법이고, 어떤 사람들에게는 더 좁은 개인적 윤리이며, 또 다른 사람들에게는 법을 넘어서 "여기서 법을 어기면 어떤 위험이 있는가?"입니다.

Google 전 CEO인 에릭 슈미트는 며칠 전 스탠포드 대학교 원탁회의에서 스타트업들이 IP를 훔치고 나중에 변호사들이 문제를 해결하도록 해야 한다고 주장했습니다.

전체 인용문:

저는 여러분이 불법적으로 모든 사람의 음악을 훔쳐야 한다고 주장하는 것이 아닙니다. 여러분이 실리콘 밸리 기업가라면, 여러분 모두가 되길 바랍니다만, 만약 그것이 성공한다면, 그때 가서 변호사들을 고용해 문제를 해결하면 됩니다, 맞죠?

하지만 아무도 여러분의 제품을 사용하지 않는다면, 모든 콘텐츠를 훔쳤다는 것은 중요하지 않습니다.

그리고 저를 인용하지 마세요.

(방금 인용했네요..ㅎ)

실리콘 밸리의 악당들은 제쳐두고, 스크래핑에 대해 저는 두 가지 질문을 스스로에게 합니다:

🏆 데이터 소유자에게 어떤 이점이 있는가?

🤝 데이터의 의도된 사용과 일치하는가?

앞으로 나아가려면 적어도 하나의 강력한 '예'가 필요합니다.

그래서 간단한 버전은 이렇습니다: 만약 의도된 용도와 크게 다른 방식으로 데이터를 사용한다면, 그것은 소유자에게 이점을 가져다주거나 - 최소한 해를 끼치지 않아야 합니다.

또한 몇 가지 (주관적인) 예시를 들어보겠습니다:

🟢 Wanderio — Wanderio는 책임감 있는 스크래핑의 좋은 예시였습니다(Obama가 자신에게 상을 주는 밈을 삽입하세요). Skyscanner나 Kayak처럼 스크래핑한 공급업체에 비즈니스를 가져다주었기 때문입니다.

🟡 Perplexity — AI 검색 엔진이 현재 운영되는 방식이 허용되어야 하는지에 대해 많은 논란이 있습니다. Perplexity는 출처를 인용하지만 원본 웹사이트를 방문할 필요성을 크게 줄입니다. 그래도 정보는 일관되게 사용되고 링크가 제공되므로, 제가 보기에는 여전히 괜찮습니다.

🔴 Midjourney — (그리고 DALL-E, Stable Diffusion 등) 개별 아티스트의 스타일을 모방할 수 있어 명백히 그들의 개인 사업에 해를 끼칩니다. 그들의 지적 재산권을 사용하고, 그들의 작업을 상품화하며, 그 위에서 이익을 얻습니다. 팬이 되기는 어렵습니다!

오늘은 여기까지입니다! 항상 그렇듯이, 질문이 있거나 여러분의 경험을 공유하고 싶다면 언제든 환영합니다. 다음에 만날 때까지, 행복하고 (윤리적인) 스크래핑 되세요! 👋


Top 1% 개발자로 거듭나는 확실한 처방전, 데브필입니다.

 

 

다가올 뉴스레터가 궁금하신가요?

지금 구독해서 새로운 레터를 받아보세요

이번 뉴스레터 어떠셨나요?

데브필 DevPill 님에게 ☕️ 커피와 ✉️ 쪽지를 보내보세요!

댓글

의견을 남겨주세요

확인
의견이 있으신가요? 제일 먼저 댓글을 달아보세요 !
© 2024 데브필 DevPill

Top 1% 개발자로 거듭나는 성공 처방전

뉴스레터 문의dev.redpill@gmail.com

자주 묻는 질문 서비스 소개서 오류 및 기능 관련 제보

서비스 이용 문의admin@team.maily.so

메일리 사업자 정보

메일리 (대표자: 이한결) | 사업자번호: 717-47-00705 | 서울 서초구 강남대로53길 8, 8층 11-7호

이용약관 | 개인정보처리방침 | 정기결제 이용약관