흩어져있는 정보를 취합하고 서비스하기 위해 크롤링은 아주 좋은 기술이다.
만
흩어져 있다고 덮어놓고 크롤링하다간 큰 코 다친다..
사이트들의 루트디렉토리에 있는 robots.txt 를 보면
이 사이트에 대해 크롤링을 해도 되는 지를 알 수 있다.
방법.
사이트명에 /robots.txt 를 확인한다.
ex) //www.naver.com/robots.txt
다음과 같은 페이지가 뜬다.
내용은 다음과 같다.
네이버는 모든 봇으로부터 사이트 전체에 대해 크롤링을 허용하지 않는다.
웃대
디씨
오유
ㅋㅋ
//www.robotstxt.org/
에서 더 자세한 내용을 확인할 수 있다.
하여튼간 Disallow 라고 명시되어있는 디렉토리 및 파일에 대해 크롤링하여 상업목적의 서비스를 할 경우 위험할 수 있음
//www.bizwatch.co.kr/pages/view.php?uid=33680
대법원 "웹사이트 무단 크롤링은 불법"
잡코리아, 사람인 상대 9년 소송전서 승소
크롤링(데이터 수집) 법적 기준 정립
We’ve updated our privacy policy so that we are compliant with changing global privacy regulations and to provide you with insight into the limited ways in which we use your data.
You can read the details below. By accepting, you agree to the updated privacy policy.
Thank you!
View updated privacy policy
We've encountered a problem, please try again.
🚨 주의: 이 포스트는 민감한 내용을 포함하고 있습니다. 욕설이 등장하므로 주의 해 주세요.
🤬 주의 : 욕설 레벨 2에 해당하는 문서입니다. 다소 불쾌 할 수 있습니다.
😠 무슨 말 할거냐?
거창한 이야기는 아니다. 인터넷에 존재하는 웹 크롤러 또는 웹 프론티어라고 불리우는 것들을 만드는 방법들을 읽고 생긴 답답함을 이곳에 조금 털어 놓으려고 한다.
인터넷에 '크롤러 만들기'를 쳤다하면 90% 확률로 파이썬으로 크롤러는 만드는 방법에 대해 잘 쓰여진 블로그가 수십개씩 검색 결과로 우수수 떨어지고 그 대부분이 Scrapy또는 셀레니움, BeautifulSoup4 등 을 사용해서 특정 웹 사이트의 페이지를 긁어내는 코드를 소개하고 있다.
대게 '어디 어디 페이지를 긁어서 변경 사항을 감지하고 Telegram 알림까지 연동 해 봅시다!' 정도이다. 그러나 이것들은 크롤러라고 보기엔 어렵다. 대부분의 블로그들이 '나만의 웹 크롤러 만들기' 따위의 제목으로 시작해서 심지어 코드들은 죄다 서로 빼다 닮았고 틀린 코드도 서로 붙여 넣으면서 크롤러를 만들어 보라고 독려하고 있다. 가장 큰 문제점 두 가지만 꼽아 보겠다.
🤔 웹 페이지 몇 개 긁는 걸 '크롤러'라고 할 수 없다.
웹 크롤러를 단순한 인터넷 장난감 정도로 생각하는 사람들이 많다. 나만의 코드로 나만의 알림 로봇을 제작하고 소개하는 정도에 그치는 블로그 글들이 너무나도 많기 때문이다. '크롤러' 또는 '웹 프론티어'라고 불리는 것은 오랫동안 연구된 주제고 어떻게 하면 www의 수천 수백만개의 웹 페이지들을 잘 수집 할 수 있을까에 대한 고민이다.
내가 웹 컨텐츠 크롤링으로 박사 학위라도 받은 것도 아니라 감히 말하는 개인에 불과하지만 무분별하게 그저 그런 코드를 적당히 블로그에 올려두고 크롤러라고 소개하는 행위는 참을 수 없었다. 아래는 구글에서 크롤링을 검색 했을 때 나오는 크롤러의 기본과 개념에 대한 설명이다. 가장 심각하게 잘못된 개념을 전파하는 게시글들을 모았다.
크롤링(crawling) 이해 및 기본, 크롤링(crawling) 이란? - Web상에 존재하는 Contents를 수집하는 작업 (프로그래밍으로 자동화 가능) - HTML 페이지를 가져와서, HTML/CSS등을 파싱하고, 필요한 데이터만 추출하는 기법 - Open API(Rest API)를 제공하는 서비스에 Open API를 호출해서, 받은 데이터 중 필요한 데이터만 추출하는 기법 - Selenium등 브라우저를 프로그래밍으로 조작해서, 필요한 데이터만 추출하는 기법Web crawling ? - web crawling : 자동적으로 화면에 있는 data를 가져오는 것 (실시간 연동, 자동으로 업데이트 됨) - web scrapping : 자동화 X / scrapping 하는 시점에서의 데이터만 갖고오기! => 두 가지 모두 웹 사이트를 분석해 원하는 데이터를 추출하는 과정이다.크롤러의 개념에 대해서 제대로 설명하지 못했고 완전히 틀린 수준의 문장도 보인다. 크롤링은 결코 Open API를 제공하는 서비스를 사용해서 만드는 것이 아니다. API가 없어서 크롤러를 못 만든다면 과연 SW 엔지니어라고 할 수 있는가? 정말 크롤러란 셀레니움이랑 Open API를 사용해서 만드는 것이라고? 크롤러는 웹 사이트를 분석해 원하는 데이터를 추출하는 과정도 아니다.
또 크롤러는 '셀레니움을 써서 데이터를 추출 하는 것'이라고 보기에도 어렵다.셀레니움이 없으면 어쩔 건가? API가 없으면 어쩔 건가? 곧 바로 BeautifulSoup4를 사용해서 CSS 셀렉팅을 하는 코드를 올려 놓아서 실망했다.
각종 블로그에 소개된 크롤러들은 그냥 한 번 실행하면 끝나는 http request 정도에 불과하다. 그 때 그 순간에만 동작하고 target 웹 페이지의 DOM이 조금만 변경되어도 힘을 못 쓰는 병신 코드로 전락하고 마는 것이다. 그도 그럴것이 대부분 개발자 도구를 열고 CSS selector를 복사하라고 써 놓기 때문이다.
특히 '네이버 뉴스 크롤링' 또는 '다음 뉴스 크롤링' 등으로 검색해서 나오는 결과들은 그 중 최악이며 네이버나 다음의 페이지 구조는 주기적으로 바뀌므로 '웹 크롤러 만들기 2020년 최신' 따위의 블로그 글이 설치는 이유가 바로 이것이다.
🤔 그럼 CSS selector를 안 쓰고 대체 오또케 본문 데이터를 긁죠?!!
라고 생각 하는 개발자가 있다면 지금 당장 대가리 박고 대학교로가서 알고리즘 수업을 다시 듣고 오길 바란다. CSS selector는 대충 생각해도 전혀 우아한 방법이 아니다. 📎 DOM based content extraction via text density 에서는 어떻게 웹페이지의 본문 DOM을 찾을 수 있는지 소개해 주고 있다.
🏗 웹 크롤러 아키텍쳐
다음은 간단한 '웹 크롤러'의 구조를 보여주고 있다.
🧭 Fetcher, Parser, Frontier
일단 Fetcher와 Parser, Frontier 세가지가 보인다. 과정을 이해하기 위해서는 먼저 Frontier부터 시작하면 좋다. 이 디지몬 Frontier가 먼저 탐색할 URL을 Fetcher에게 넘겨 주면 Fetcher는 해당 페이지의 html 내용을 가져와서 Parser에게 넘겨 준다. Parser에서는 다른 하이퍼링크를 찾는다. 보통 html의 a태그나 url로 보임직 하는 것들이다. 여기서 찾은 이 URL들을 다시 또 Fetcher가 방문하게 되는데 이 때 방문 했던 곳을 또 방문 하면 무한 loop가 되므로 Dup URL Elim에서 이미 방문한 URL과 중복 URL들을 제거한 채로 디지몬 Frontier에게 전달 해 준다.
잠깐만! 구구절절하게 써 놓긴 했지만 이 모든 과정은 사실 우리가 알고리즘에서 배웠던 DFS나 BFS와 완벽하게 같은 과정이 아닌가?. 더 이상 방문 페이지가 없을 때 까지 URL을 계속해서 탐색하는 것이다. 극단적으로 말해서 크롤러는 월드 와일드 웹, www을 대상으로 DFS또는 BFS를 하는 것 뿐이다. 그렇지만 웹 세상은 워낙 넓어서 탐색을 하는 도중에도 새로운 URL이 생기고 또 페이지 내용이 수정 된다. 이런 과정을 어떻게하면 최적화 할 수 있을까?라는 고민 역시 크롤러 연구의 한 부분이다.
👁 Content Seen
방문한 페이지의 '본문 내용'이 이미 전에 다른 곳에서 본 내용인지 아닌지 판단하는 부분이다. Doc FP's라고 적힌것은 Document Finger Prints를 줄인 것인데 FP란 어떤 Document의 내용을 구분 할 수 있는 고유한 Hash 값이라고 생각하면 좋다. 이 부분 하나만 하더라도 공부할 내용이 정말 많고 방대해서 여기서는 설명하지 않고 넘어가려고 한다. FP를 만드는 방법 역시 여러가지고 FP로 어떻게 '중복 문서'를 걸러 낼까? 고민하는 것도 하나의 분야다. 한국어로 정리가 되어 있는 링크를 아래에 적어 둔다. 영어로 알아보고 싶다면 'Near Duplicated Document Detection'라는 키워드로 검색 해 보자.
📎 문서 단위로 유사 중복을 판별하는 방법
또 실제 운영 되는 크롤러는 DNS 서버까지 따로 두기도 하기에 그림 상 DNS라는 것도 보이지만 DNS는 또 하나의 큰 주제이므로 이 글에서 다루지는 않겠다.
⌛️ History
내가 혼자 망상에 사로잡혀서 "이건 예술적이지 않아! 이건 크롤러가 아냐!"라고 외치는게 아니라 1999년에 우리 멋쟁이 Marc Najork라는 사람이 어떻게 확장성 있는 웹 크롤러를 만들 수 있는지 유명한 논문을 출간 했다. 이 논문의 서론을 보면 재밌는 말이 등장 한다.
"'확장성 있는 웹 크롤러'는 웹 서비스에서 매우 중요한 컴포넌트인데 그 크롤러 디자인에 대해선 잘 정립 되어 있지 않다."
Scalable Web crawlers are an important component of many Web services, but their design is not well‐documented in the literature📎 Mercator: A scalable, extensible Web crawler, 1999
그로부터 10년 뒤, Marc Najork는 MS 연구소에 들어가서 아래와 같은 논문을 또 썼다. 서론에 이런 글이 써 져 있다.
"웹 크롤러란? seed URL을 주면 관련된 URL을 찾아 내고, 그 URL들에서 또 다른 하이퍼 링크를 찾아내고 계속해서 이 과정을 반복하며 하이퍼 링크들을 다운로드하는 프로그램이다."
A web crawler is a program that, given one or more seed URLs, downloads the web pages associated with these URLs, extracts any hyperlinks contained in them, and recursively continues to download the web pages identified by these hyperlinks.📎 Web Crawler Architecture, MARC NAJORK
Microsoft Research, 2009
🤮 논문? 요즘은 Youtube가 대세지 누가 '글'을 시간 들여서 읽나? 그렇다면 Marc Najork가 MS 인턴으로 나무 하면서 했던 발표 영상을 보자. 발표를 듣는 사람이 5명 정도 밖에 없어 매우 조촐 해 보인다. 어떻게 수백만개의 페이지를 크롤링 하도록 최적화 할 수 있는지 기초 컨셉을 알 수 있다.
📎 Atrax, a distributed web crawler
웹 크롤링은 태초에 www가 생겼을 때 부터 아주 오랫동안 고민되고 연구 해 온 주제이다.📎 Web Crawler: A Review라는 논문의 2.1에 있는 The History of Web Crawler를 읽어 보는 것을 추천한다. 재밌는 내용들이 많다.
"앞으로 블로그에 크롤러 만드는 법을 쓸거 같으면 적어도 이 정도는 알고 써라 이 머저리들아"라고 말하고 싶은건 절대 아니다. 내가 하고 싶은 말의 요점은 어중이 떠중이 코드 몇 줄 써놓고 '크롤러'등으로 소개하는 꼴을 보니 아주 신물이 난다는 것이다.
"마케터도 코딩 배우는 시대!", "시작하자! 니도 코딩 해야한다!" 따위의 좆같은 문구가 판을 치면서 개발자로 변신하라고 광고를 해 대고 1회용 코드 갖다 박아 놓고 '크롤러 만들기', '데이터 수집 강의'로 돈을 받아 먹는게 현실이다.
🤖 robots.txt 윤리에 대한 설명이 없음.
너도 나도 다 같이 웹 페이지를 긁어서 슬랙, 텔레그램 알림 연동까지 해서 재밌게 놀아보자는 말은 신나게 하는데 robots.txt 룰에 대해서 설명하는 블로그는 여지껏 거의 본적이 없다. 웹 페이지라고 해서 아무렇게나 긁어서는 안되고 robot.txt에 작성된 룰에 따라 수집을 해도 되는 페이지가 있고 수집을 해선 안되는 페이지가 있다. 궁금하면 긁으려는 페이지 루트 도메인에서 /robots.txt에 들어가 보도록 하자. 뭔 짓거릴 해도 되고 뭔 짓거릴 해선 안되는지 간곡히 부탁하는 내용이 쓰여져 있다.
//www.google.com/robots.txt
각 사이트 별로 루트 경로의 robots.txt에 로봇룰이 적혀 있으며 '크롤러'를 만든다면 이 룰을 따라 주는 것이 윤리적이라 할 수 있다. 크롤러를 만드는 방법에 대해서 소개한다면 적어도 이 로봇룰에 대해선 설명 해 줘야 한다.
구글은 robots.txt를 검색엔진 크롤러에서 사이트에 요청할 수 있거나 요청할 수 없는 페이지 또는 파일을 크롤러에 지시하는 파일이라고 정의하고 있다. 번역 과정을 거치면서 자연스러운 한국어가 아니라 다소 이해하기 어려운데 나름 쉽게 번역 해 보면 크롤러가 요청을 해도 되거나, 해선 안되는 경로를 적어 둔 곳 정도가 될 것 같다. 그 외에도 robots.txt에는 몇 초 간격으로 요청을 보내도 되는지 등 다양한 내용을 적을 수 있다.
⚠️ 불법 크롤링
크롤링으로 수집한 데이터로 이익을 취하면 문제가 될 수 있다. 경쟁 업체 데이터를 크롤링해서 실형 떨어진 개발자도 있다. 좆되지 않게 조심해라. 아래 사례는 단순히 DOM 파싱해서 가져가는 정도가 아니라 아예 API endpoint를 조진게 문제긴 하다.
📰 法 “여기어때, 야놀자 정보 무단수집 맞다”...前 대표 ‘유죄’
그러나 지금까지도 내가 구글에 '크롤러 만들기'로 검색했을 때 robots.txt에 대해 설명하는 글은 상위에서 단 하나도 찾아 볼 수 없다. 19년도에 인터넷 표준화 기구의 메모에 robots.txt가 사실상 웹 크롤링의 표준이 되어가고 있다고 쓰여져 있다. 이것도 구글이 제출한 문서긴 한데 재밌게 읽어 볼만 하다. 📎 Robots Exclusion Protocol
웹 크롤러를 만들 수 있는 오픈 소스들은 자기네 프레임워크의 기능 중 하나로 'robot.txt를 준수합니다.'라고 소개하고 있다. 이 오픈 소스 크롤러를 사용하면 robot.txt를 준수할 수 있게 된다고 광고하는 셈이다. 이 부분에 대해서 우리도 한 번 생각 해 볼 필요가 있다. 📎 gocolly라는 웹 크롤러 오픈소스의 기능 소개에는 robots.txt support라고 적어 둔 부분을 주목하자
또 Pinterest의 경우 자사의 크롤러가 어떻게 동작하는지, 어떤 User Agent를 갖고있고 어떤 IP 대역을 사용하는지 공개하고 있다. 이 와중에 국내 블로그, 커뮤니티의 어떤 글도 크롤러의 robots.txt에 대해 설명하지 않고 있다는 점은 반드시 짚고 넘어 가야 할 문제다.
📎 Pinterest crawler
👺 "그래서 어쩌자고"
크롤러가 아니라 뭐 다른 이름을 갖다 붙이기라도 하잔 말이냐? 그런 대안 없다. 개발자들의 전형적인 말 중 하나인데 "문제를 지적하려면 대안을 갖고 오세요"다. 회사 생활을 하면 '진짜 다방면으로 훌륭한 해결책'을 마련하지 않으면 회의에서 찍소리도 하지 않는 것이 규범이다.
내가 무슨 크롤링 학계에서 저명한 박사나 교수도 아니고 용어 가지고 거들먹 거릴 순 없다. 내가 하고픈 말은 단지 '크롤러'는 상당히 오랫동안 연구된 주제고 언제까지고 scrapy나 쓰면서 '2019 다음 뉴스 크롤링', '2020 다음 뉴스 크롤링'... 같은 글에 평생 의존 할 수는 없다는 것과 잘못된 크롤러의 개념이 인터넷 곳곳에 퍼지는 걸 막자는 것이다.
'크롤러란 셀레니움으로 페이지 긁는것'으로 잘못된 개념이 인터넷에 떠돌아 다니는걸 SW 개발자로서 입 닫고 지켜보기엔 나는 너무나도 지독한 공대생이다.
A crawler’s purpose is to follow links to reach numerous pages and analyze their meta data and content.
Scraping is possible out of the web. For example you can retrieve some information from a database. Scraping is pulling data from the web or a database.
📘 더 읽어 볼 거리
📎 웹 크롤러
그렇다고 크롤러 관련해서 설명한 글이 전혀 없는 건 아니다. 잘 설명 했다고 생각하는 글이다.
📎 로봇 메타 태그, data-nosnippet 및 X-Robots-Tag 사양
구글의 웹 크롤러가 나의 블로그나 콘텐츠를 수집하지 못하도록 제한 하는 방법에 대해서 설명 하고 있다.
robots.txt의 연장선이다.
📎 Marc Najork, Research Engineering Director in Google Research
글 중간에 소개 했던 멋쟁이 Marc Najork는 이제 구글 리서치에서 근무하고 있다. 검색과 크롤링에 관심이 있다면 아주 재미있게 읽을 수 있는 논문들이 많다. 내 병신 같은 글 보다 이 박사의 Abstraction 한 문단이 여러분에게 훨씬 값지고 인생에 도움이 되니까 꼭 봐라. 요즘은 랭킹을 연구하는 모양이다.
📎 Google 검색의 원리 | 크롤링 및
색인 생성
시간 없고 빨리 IR과 크롤러의 개념 둘 다 이해하고 싶은 사람에게 강력 추천하는 글이다. 구글에서 설명해주는 검색의 원리이다. 검색 프로세스 전체를 쭉 둘러 보기에 시야가 확 넓어 질 것이다.
😡 "뭐 제대로 설명 한 것도 없는데 논문 링크만 냅다 박아 놓으면 땡이냐?"
미안하게 생각합니다. 나도 여깄는거 다 보진 않았고 요즘도 읽어가는 중이라 기회가 되면 정리를 해 보려고 합니다... 진짜 관심 있는 사람 있으면 댓글로 뭐라도 남기면 수요를 봐서 글을 쓰겠습니다.