셀레니움 선택의 근거와 모던 웹 환경에서의 크롤링
1. 크롤링 툴의 선택
크롤링 툴로는 보통 bs4(BeautifulSoup)나 셀레니움(Selenium)을 사용한다.
2. bs4의 한계와 현실
사용 가능한 범위의 축소 : 모던 웹 환경을 생각하면, bs4는 쓸 수 있는 범위가 많이 줄었다고 보면 된다.
정적 페이지에만 제한적 적용 : bs4는 정적인 페이지, 즉 사용자 인터랙션이 전혀 없는 페이지에서만 쓸 수 있다.구체적인 예시:
이런 경우가 아닌 페이지에서만 사용 가능하다.
bs4의 적합한 용도 : 이런 경우엔 그냥 서버에서 html 파일 하나 통째로 날려주니까, bs4로 태그 파싱만 해도 충분하다.
bs4는 요즘 웹페이지보다는 단순 HTML 문서 구조 분석할 때 더 적합하다고 할 수 있겠다.
3. 셀레니움 선택의 필연성
대상 사이트의 특성 : 서론이 좀 길었는데, 내가 다뤄야할 사이트들은 전부 정적 페이지가 아니었기 때문에 자연스럽게 셀레니움을 선택하게 됐다.
셀레니움의 핵심 특징 : 셀레니움은 실제 브라우저를 돌려서 렌더링된 DOM 상태를 가져온다.
4. SSR/CSR과 셀레니움의 관계
렌더링 방식의 차이 : 앞서 공부한 SSR/CSR 얘기를 다시 해보면, 렌더링 주체(서버냐 클라이언트냐)만 다를 뿐 결국은 똑같이 DOM Tree를 만들어서 화면에 뿌리는 거다.
셀레니움의 범용성
- SSR: 서버에서 미리 DOM을 만들어 보내주니까 보통 초기 로딩 속도가 빠른 편
- CSR: 브라우저가 JS 실행 다 끝내야 화면이 완성된다
셀레니움은 둘 다 문제없이 쓸 수 있다.
5. CSR 페이지에서의 안정성 확보
렌더링 완료 대기의 필요성
CSR 페이지의 경우는 렌더링 다 끝날 때까지 기다려야 하는데, 이럴 땐 expected_conditions (줄여서 EC라고도 많이 씀)을 써서 특정 요소가 나타날 때까지 명시적으로 대기하면 안정적으로 완성된 DOM을 가져올 수 있다.
DOM : 페이지를 구성하는 요소들을 트리(Tree) 구조 형태로 정리한 것. Document Object Model의 약자. HTML/XML 문서를 브라우저가 객체 형태(Tree)로 표현한 것.
예시 구조:
<html>
└── <body>
├── <div id="header">
└── <div id="content">
├── <p>
└── <a>
BS4 : BeautifulSoup4. 셀레니움과 함께 정적인 웹페이지 타겟(예: 뉴스 기사, HTML 타입 문서)을 빠르게 파싱할 때 쓰이는 모듈.