Selenium 크롤링을 해보며 느낀 점

Selenium의 장점

1. 실제 브라우저를 실행 시켜서 돌아가기 때문에, 웹페이지에 구현된 정적인 페이지뿐만 아니라, 동적인 페이지까지 긁어낼 수 있다. 그래서 느리다.
2. 디버깅 시, 브라우저에서 눈으로 확인하기 때문에 크롤링 과정을 확인할 수 있다.
3. 유용한 메소드들이 많다.

Selenium의 단점

1. 느리다.
2. 너무 느리다.
3. 진짜로 느리다.

만약 자신의 컴퓨터 성능이 그리 좋지 못하다면, Selenium 크롤링 테스트를 하면서 화딱지가 날지도 모른다. 실제 브라우저를 가동하다보니 그만큼 리소스를 잡아먹고, 에디터 리소스와 이것저것 생각하다보면 자연스럽게 

import requests

라며 코드를 바꾸고 있을지도 모른다. 

 

앞으로 크롤링은 이렇게

Only Selenium은 확실히 아니다. 분명히 아니다. requests 모듈과 Selenium을 적절히 섞어서 개발해야겠다는 생각이 들었다. 그래서 다음과 같은 결론을 지었다.

Selenium은 최소화하고, reuqests를 사용하되, 웹서버에 부하가 걸리지 않을 만한 인터벌을 줘야한다.

물론, 나는 개발 초보이고 이 결론이 정답인지는 모르겠다. 그런데, 웹서버의 가혹한 차단과 이해할 수 없는 태그구조를 경험하면서 내린 결론이기 때문에 어느정도는 맞는이야기가 아닐까 조심스레 예상해본다.

 

데이터 처리에 유의합시다

수많은 데이터를 긁어오는 것은 좋은데, 이 친구들을 어떻게 처리할 지 고민도 안하고 무작정 일단 긁어온다면, 데이터를 삭제하고 다시 크롤링하는 나를 발견할 수 있다. CSV로 저장할 것인지, CSV Parameter나 Wrapper는 어떻게 설정할 것인지, 설정한 Parameter나 Wrapper가 데이터에 영향을 주지는 않는지..

SQL이 됐던, Elasticsearch가 됐던 간에 데이터 전처리는 충분히 고민해야만 하는 문제라는 생각이 들었다.

 

최선입니까?

크롤링은 가장 먼저, 웹페이지의 구조를 분석을 해야한다. 가령, 특정 제품 카테고리의 제품들을 크롤링한다고 하면,

<div class="product-list">
	<span class="product">
    	<h1>Super Notebook</h1>
        <a href="/product?itemNum=1>View Product</a>
    </span>
	<span class="product">
    	<h1>Super Notebook</h1>
        <a href="/product?itemNum=1>View Product</a>
    </span>
	<span class="product">
    	<h1>Super Notebook</h1>
        <a href="/product?itemNum=1>View Product</a>
    </span>
...<중략>
</div>

대충 이러한 형식의 태그 구조가 많다. 제품 목록을 감싸는 div와 그 안에 각 제품의 영역으로 구분된 span이나 div 등.. 당연히 이러한 태그들은 class 속성이 존재하고, 이를 그대로 이용하면 완벽한 크롤링이 될 것이다.

<div class="product-list">
	<span class="product">
    	<h1>Super Notebook</h1>
        <a href="/product?itemNum=1>View Product</a>
    </span>
	<span class="product">
    	<h1>Sponsored Notebook</h1>
        <a href="/product?itemNum=2>View Product</a>
    </span>
	<span class="product-spon">
    	<h1>Super Notebook</h1>
        <a href="/product?itemNum=3>View Product</a>
    </span>
...<중략>
</div>

무엇이 다를까? 두 번째 span을 확인해보면 sponsored 제품이다.. 만약 해당 제품의 링크가 전혀 다른 페이지로 리다이렉트 한다면 별다른 예외처리가 되지 않은 이상 크롤러는 멈출 것이다. 혹은 우연히 같은 구조를 갖는 페이지라고 해도 크롤러의 목적에서 벗어나는 크롤링이 될 수 있다. (광고제품은 제품 리스트의 정렬과 같은 필터를 따르지 않고 위치가 강제되어있는 경우가 많다.)

그래도 이렇게 태그 구조를 지켜주는 광고는 양반이다.

<!-- 제품 1 상세페이지 -->
<fieldset>
  <h3 class="specTitle">Model</h3>
  <legend style="display:none;">|</legend>
    <dl>
      <dt>Brand</dt>
      <dd>GIGABYTE</dd>
    </dl>
    <dl>
      <dt>Model</dt>
      <dd>Aero 15X v8-BK4</dd>
    </dl>
</fieldset>
<!-- 제품 2 상세페이지 -->
<fieldset>
  <h3 class="specTitle">Model</h3>
</fieldset>

제품 1 상세페이지

위 HTML은 2가지 제품의 상세페이지에 대한 내용이다. 주석으로 구분되어 있는데,

fieldset - dl - dt,dd 

와 같은 순서로 들어가면 해당 제품의 브랜드와 모델 정보를 긁어올 수 있다. 당연히, 모든 제품이 1번과 같은 HTML로 되어있을 거라고 생각하며 크롤러를 돌려놓고 한숨 푹자고 일어나서 모니터를 보면 한숨이 절로 나온다. 2번 HTML의 경우 제품의 스펙이 전혀 적혀있지 않은 상태이다. 여러 서드파티에서 제품을 등록하는 사이트 특성상 모든 제조사에서 성실히 웹사이트의 규칙을 준수하지 않는다.(?) 그러므로 예외처리가 매우 중요하겠다.

신중하게 세밀하게 구석구석

웹사이트를 분석해야만 크롤러가 삽질하는 상황을 막을 수 있다. 오랜만의 포스팅이었는데, 약간 한풀이 느낌이기도하다. 돌아오는 포스팅은 requests를 이용한 크롤링에 대해서 써보려고 한다. 물론 언제 쓴다고는 아직 이야기 안했다. 여기까지!