🤗 ** 이 글은 비개발자가 공부해도 좋은 내용이라 생각해요.**

🙆🏻‍♀️ ** 이 글은 욕설이 없는 안전한 글입니다.**

⚠️ ** 이 글은 아직 작성 중인 글이라 내용이 바뀔 수도 있습니다.**

🥚 무슨 글일까?

웹 크롤러에 관한 자료를 찾아 보려고 했다. 그러나 구글 검색 결과는 잘못된 크롤러 개념 설명에 점령 당한 상태였다. 그런 글들은 대부분 빠르게 해당 웹 페이지를 스크래핑해서 원하는 DOM을 가져오는 것을 크롤러 또는 크롤링이라고 소개하고 있었다. 그러나 실제로 해당 블로그 글이 말하는대로 크롤러를 만들면 운영에 많은 문제점이 생긴다.

잘못된 크롤러 개념글이 흐르는걸 두고 보기엔 너무 답답해서 📎 **크롤러 좀 그만 만들어라**라는 글을 썼었다. '크롤러'라고 검색하면 이 글이 구글 검색 결과 첫 페이지에 나와 있어 깜짝 놀랄 때도 있다. 대부분 크롤러를 만들기 위해 '크롤러'를 구글에 검색 했을 텐데 "크롤러 좀 그만 만들어라"라는 제목의 글이 떡하니 상단에 보이니 사람들이 당황할 것 같다. 하지만 잘못 설명된 크롤러 관련 블로그들이 검색 결과에서 대부분 사라져 조금은 뿌듯하다.

이번 글에서는 웹 크롤러란 무엇이고 웹 크롤링을 하면서 마주하는 문제들을 어떻게 해결하는지, 이 분야의 논문들과 함께 최대한 🍉 수박 겉핧기 식으로 둘러보려고 한다. 인터넷는 수많은 '크롤링' 관련 글이 있지만 그 실제 구조나 개념에 대해서는 자세하고 명확하게 정리 된 한글 문서는 아직 찾아 볼 수 없었다.

웹 크롤러란 인터넷 서비스를 하는데 있어서 아주 중요한 소프트웨어지만 공개된 자료가 많지 않았다. IT 기업들의 핵심 기술에 해당하는 크롤러는 바깥 세상에 모습을 잘 드러내지 않았고 이런 상태가 90년대 후반까지 지속 됐지만 2000년대 초반에 이르러서는 📃 Mercator: A scalable, extensible Web crawler 와 같은 논문이 발표되면서 조금씩 웹 크롤러의 아키텍쳐 기반이 정의되기 시작했다.

☹️ 저 논문이 뭔데요

Mercator는 Marc Najork이 MicroSoft에서 인턴 시절 만든 분산 웹 크롤러다. 크롤링 관련 공부를 하거나 논문을 찾다보면 구글 리서치 소속의 Marc Najork라는 사람을 자주 만나게 된다. 또 헥토르 가르시아 몰리나와 조정후 교수를 만날 수 있는데 👨🏼‍🏫 **헥토르 가르시아 몰리나 교수**는 세르게이 브린이 구글을 창업 할 당시의 지도 교수였다. 즉, 크롤러 논문을 보다 보면 이들의 연결고리가 어느정도 보인다. 언급한 세사람 모두 검색, 크롤링과 매우 밀접한 관련이 있는 사람들이다.

본격적으로 글을 쓰기에 앞서 웹 크롤러를 만들면서 가장 의문이 드는것들을 정리 해보자면 이렇다.

✍🏻 어떻게 페이지의 본문 텍스트를 얻을 수 있을까?

수많은 블로그들이 css selector를 사용해서 원하는 텍스트와 정보를 가져오는데 쓰고 있다. css selector로 DOM을 직접 가져오면 정확하게 텍스트를 가져올 수 있지만 서비스의 UI가 조금만 변경돼도 크롤러는 엉뚱한 데이터를 갖고 올 것이다. 그렇다면 페이지 구조가 자주 바뀌어도 본문 텍스트를 가져올 수 있는 방법이 있을까?

🥝 몇 초마다 재방문해야 freshness를 유지 할 수 있을까?

페이지는 업데이트 된다. 예를들어, 어떤 벨로그 포스트를 크롤링하여 수집하였지만 나중에 그 포스트는 작성자가 삭제하거나 수정 할 수도 있다. 따라서 크롤러가 방문 했던 URL을 언젠가 또 방문해서 변경사항을 반영할 필요가 있는데 이렇게 페이지의 신선도(freshness)를 유지 해 주어야만 할 것이다.

간단하게 생각해서 한 시간 마다, 또는 며칠에 한 번씩 재방문 하도록 할 수 있겠지만 자주 업데이트 되는 페이지가 있는가 하면 오랫동안 그대로인 페이지도 있을것이다. 어떻게 하면 효율적으로 수정이 이뤄진 페이지만 재방문 할 수 있을까?

🪐 어떻게 크롤러를 Scalable하게 만들 수 있을까?

Scalable은 개발자들한테 정말 마법 같은 단어다. 회사에서 미팅하는데 엔지니어들이 뭔가 불만 가득한 표정이면 "이건 Scalable 합니다!"라고 하면 모두 침흘리면서 고개를 끄덕일거다. 그만큼 중요하기도하고 때로는 지나치게 기술 중심에 빠지게 하는 단어다.

www에서 생산되는 페이지는 그야말로 폭발적이다. 단 한 대의 크롤러로 전 세계의 모든 페이지를 수집 할 수가 없는데 당연하게도 여러대의 크롤러가 협업하면서 움직여야 한다.

Scalable한 대규모 병렬 크롤러를 만드는 영역으로 넘어가는데는 사실 좀 더 깊고 어려운 고민들을 해야한다. 다행히 Scalable 크롤러 관련해서는 Parallel Cralwer라는 대표적이고 유명한 논문이 있다.

이번 글에서는 이와 같은 고민들을 최대한 다뤄 볼 예정이다.

🐤 왜 크롤링하나

크롤링은 왜 하는걸까? 숱한 온라인 강의에서는 크롤링이라는 용어를 '데이터를 수집'과 같은 의미로 앵무새 처럼 반복한다. 그래서 사람들이 '크롤링'은 단순히 데이터를 모으는 행위로 많이들 오해하는 걸 많이 봤다. 그러나 웹 크롤러는 보다 복잡한 일을 해내야만 하는 소프트웨어다.

웹 크롤링을 왜 하는지 알기 위해서는 먼저 크롤러가 정보 검색(IR, Information Retreival)과 매우 밀접한 관계가 있다는 걸 알아야 한다. 그냥 검색이라고 하면 되지 왜 어렵게 정보 검색이라는 용어를 쓰냐고 묻는다면 이 분야 교수님들이 이 용어를 선호하기 때문이다. 흔히 우리가 구글에 키워드를 집어 넣는 것은 검색(Search)이라고 하고 학구적인 용어로는 정보 검색이라고 한다. 이 정보 검색에 대해 설명하려면 포스팅 한 개를 모두 써도 설명 하지 못할 정도로 방대한 양을 다뤄야 한다. 그래서 이번 글에서는 정보 검색이나 검색 엔진에 대한 자세한 배경 설명 보다는 검색(Search) 서비스를 위주로 이야기 하려고 한다.

👓 그래도 검색 알려 주세요

Search는 아무래도 일반 사용자들의 서비스 의미에 가깝고 기술적으로는 Information Retrival이라는 멋진 말을 쓴다. 검색에 대해서 더 관심이 생긴다면 아래 강의를 보면 좋다. 또 이와 관련한 글을 이만큼 쓸 자신이 없다. ㅋㅋ. IR 관련해서 공부한다면 매우 정석적으로 등장하는 스탠포드의 유명한 강의다. 국내에 한글 번역본도 판매 중이긴한데 비싸다.

📕 CS 276: Information Retrieval and Web Search

🕵🏻‍♂️ 검색 서비스와 웹 크롤러

웹 크롤러는 검색 서비스에서 매우 중요한 역할을 담당하고 있다. Google, Yandex, DuckDuckGo 같은 거대 검색 서비스들은 웹 사이트에서 좋은 정보를 정확히 찾아 내서 사용자에게 제공해야한다. 그러면 당연히 웹에서 생성되는 수 많은 페이지들을 수집해야하고 정리해 두어야 한다. 우리가 구글링이라고 말하는 검색 서비스도 마찬가지다. 구글은 GoogleBot이라는 크롤러를 가지고 있다. Pinterest 같은 서비스도 이미지만을 집중적으로 수집하는 크롤러를 가지고 있다.

"Web crawlers are an essential component to search engines."

📄 _An Analysis on Search Engines: Techniques and Tools, R. Rubini1, Dr. R. Manicka Chezian _

크롤러는 그런 대규모 검색 서비스를 하는 곳에서나 쓰이는 기술이지 우리 같은 작은(?) 개발자들이야 그냥 📎 **BeautifulSoup**나 **📎 Selenium**을 잘 쓰면서 원하는 정보만 일시적으로 스크래핑 하면 땡 아닐까? 실제로 직장이나 학교에서 맞닥뜨리는 요구사항은 어느 몇 페이지의 정보만 지속적으로 갖고 와야하는 일회성 작업들인 경우가 많다. 이와 관련해서는 이 글의 마지막 쯤에 있는 **😮 너무 복잡해요**에서 다루려고 한다.

🐔 웹 크롤러란 무엇인가?

그렇다면 인터넷 강의에서 말하는 웹 크롤러들 말고 진짜 웹 크롤러란 무엇일까? 크롤러란 기본적으로 웹 사이트를 탐험하고 페이지를 수집하는 시스템이라고 할 수 있다. 내가 복잡하게 설명 할 것도 없이 구글 블로그에 크롤러란 무엇인지 잘 설명된 글이 있다.

📃 검색의 원리

"구글은 ‘구글봇’이라고 하는 일련의 컴퓨터 프로그램이 있습니다. 구글봇은 매일 끊임없이 웹상에 존재하는 수십만 개의 페이지를 ‘방문’합니다. 이 과정을 ‘크롤링(crawling)’이라고 하는데 모두 정교한 알고리듬으로 짜여 있습니다. 다시 말해 어떤 사이트를 크롤할 지, 얼마나 자주 할지 또 각 사이트에서 얼마나 많은 페이지를 방문할 것인가에 대한 프로그램이 짜여 있습니다."

📎 저작권 및 웹 검색에 관한 구글의 정책

크롤러가 동작하는 방식은 우리가 방구석에서 시간 떼울 때 하는 '웹 서핑'과 과정이 같다. 크롤러는 첫 페이지에서 다른 사이트나 경로로 이동 할 수 있는 link들을 찾아 낸 다음 하나씩 차례로 방문한다.

웹 크롤러는 결국 전세계의 웹 사이트를 BFS, DFS하는 어플리케이션이라고 할 수 있다. 그러나 그냥 평범한 그래프 탐색 알고리즘으로 개발 할 수 있지만은 않다. www가 가진 특성 때문에 웹 크롤링에는 고도로 발달된 알고리즘과 시스템 디자인이 필요한데 아래에서 왜 웹 크롤링이 만만치 않은지 살펴보도록 하자.

🧗🏻‍♀️ 크롤러의 도전과제

웹 크롤러를 운영하는 것은 생각보다 어려운 일이다. 끊임없이 작동해야하는 성능 문제도 있지만 가장 중요하다고 할 수 있는 robots.txt 같은 사회적 이슈도 있다. 수백 수천 개의 웹 사이트들을 탐험하면서 웹 서버와 상호작용하기 때문에 크롤러는 박살 나기 매우 쉬운 어플리케이션이다.

🚜 **크롤러, 🎒프론티어, 🕷스파이더? **

크롤러는 여러가지 이름을 갖고 있다. 어떤 논문에서는 Web Spider라고하고 어떤 논문에서는 URL Frontier라고 쓰기도 한다. 2000 중반대에 들어서는 거의 Web Crawler로 굳어진 것 같다. 다만 Scraper라는 용어는 Cralwer와는 달리 특정 목적을 위해 몇몇 사이트를 수집하는 개념으로 언급 되고 있다.

🌏 웅장한 www의 크기

크롤러를 만들기 어려운 이유는 크게 두가지를 꼽을 수 있다.

웹은 끊임 없이 팽창하고 있다. 하루에 새로운 페이지가 수십만개씩 생긴다.
웹은 계속해서 변한다. 수백만개의 페이지가 수정된다.

인터넷 세계는 정말 크다. 크롤러 혼자서 이 모든 페이지를 다 탐색하기엔 너무나도 넓다. 크롤러가 한 페이지를 열심히 읽는 동안 다른 페이지에서는 수정이 일어난다. 열심히 다른 페이지를 또 탐색하러가면 어디서는 문서가 삭제 되고 어디서는 또 새로운 문서가 생겨난다. 이런 야생과 같은 인터넷 환경에서 크롤러는 모든 페이지를 빠짐 없이 방문해야하고 페이지가 수정되면 update도 해 주어야 한다. 확장성(Scalability)는 크롤러뿐만이 아니라 다른 분야에서도 마찬가지로 겪는 문제다.

📝 페이지 퀄리티

크롤러가 아주 빨라서 전체 웹을 잘 탐색하고 있다고 하자. 모든 페이지가 고품질은 아니고 그 중에는 광고도 있고 그냥 한 줄 짜리 포스팅도 있을것이다. 크롤러의 임무는 좋은 포스팅은 빨리 획득하고 스팸 포스팅은 최대한 피하는 것이다.

검색 서비스는 좋은 키워드나 이미지를 가진 포스트에 높은 점수를 준다. 점수가 높아진 포스트는 관련 검색 결과에서 높은 우선 순위를 갖게 되는데 바로 이 점을 노리고 검색 결과 상단에 노출되려고 랭킹 알고리즘을 알아내 어뷰징하려고 애를 쓰는 사람들이 있다. 네이버 블로그, 티스토리 등의 스팸 게시글 아래에는 관련 없는 온갖 키워드들이 태그로 달려 있는 것을 많이 본 적이 있을텐데 모두 검색 엔진과 크롤러를 어뷰징하기 위한 것이다.

검색 마케팅은 아주 큰 비즈니스이고 네이버나 카카오가 랭킹 알고리즘 정책을 변경하는 즉시 외부 검색 마케팅 업체에서 귀신 같이 알아내고 다시 스팸 포스팅을 최상단에 올려 놓곤 한다. 이런 사실을 유출하는 사람이 사내에 있다는 강한 의심이 들지만 주제를 벗어나므로 여기까지만 생각하자. 중요한건 검색 결과에서 상위를 차지하기 위한 전쟁이 벌어지고 있다는 것이다. 그만큼 크롤러는 '진짜' 포스팅을 잘 찾아낼 필요가 있다.

스팸 포스팅이 너무 많다는 생각은 누구나 겪어 봤을 텐데 네이버 영희맘의 블로그에서 수많은 이모티콘들 덕지덕지 사이에서 뭔가를 찾아 내거나, 설명 하나 알자고 Youtube 영상을 20분씩 본 경험들이 있을 것이다. 웹 크롤링과 검색 분야의 최고라고 알려진 구글도 저품질 컨텐츠를 완벽하게 제거 할 순 없었다. 구글은 전세계 검색 결과의 92%를 차지하고 있지만 검색 결과중 66%는 클릭 당해보지도 못한다.

📎 In 2020, Two Thirds of Google Searches Ended Without a Click
📎 Search Engine Market Share Worldwide

검색 엔진의 랭킹 알고리즘의 입맛에 잘 맞게 블로그 포스팅이나 회사 홈페이지를 정리 하면 검색 결과에서 상위에 노출될 확률이 높다. 이런 과정을 검색엔진 최적화(SEO)라고 하는데 컨텐츠가 랭킹 알고리즘으로부터 높은 점수를 얻게 하는 것이 목표다. 각 검색 서비스마다 어떻게 하면 SEO를 잘 할 수 있는지 가이드라인을 제시하고 있다. 구글은 SEO 성공 사례들을 소개중인데 이 중에는 한국의 사례인 '사람인'이 어떻게 방문자를 늘렸는지 소개하는 부분도 있다.

📎 검색엔진 최적화 우수사례 및 성공사례 | Google 검색 센터

네이버의 경우 원래 '웹마스터 도구'라고 했었는데 '네이버 서치 어드바이저'로 이름을 변경 하고 본격적으로 검색 서비스로의 역할을 해내려고 애쓰고 있다.

📎 ** 검색엔진 최적화(SEO), 아직도 한국에서 안먹힐까? **

🤖 robots.txt

어쩌면 크롤링에서 가장 중요한 부분이 될 수도 있는 것이 robots.txt 준수인데 제대로 소개 된 글은 아직 만나 본 적이 없다. 크롤러 관련 검색을 해 보면 코드를 어떻게 짜는지 급급해 이 robots.txt의 설명은 아예 없거나 모르는 경우가 많았다.

크롤러는 얌전하게 페이지만 긁고 떠나야지 필요 이상으로 웹 서버에 과도한 HTTP 요청을 보내선 안된다. 만약 여러대로 구성된 크롤러들이 동시에 한 웹 사이트, 서버를 방문한다면 DDoS 공격이나 다를바 없다. 사이트가 마비 될거고 운영자가 고소하면 사이버 수사대에서 날 체포할지도 모른다.

또 방문해서 데이터를 함부로 가져가지 말라고 명시 해 둔 경로에 크롤러는 방문 해서는 안된다. 이 rule을 써 둔 곳이 바로 robots.txt인데 각 사이트의 루트 도메인에서 robots.txt를 조회 해 볼 수 있다. 🤖 **네이버 뉴스 페이지의 robots.txt**를 살펴보면 아래와 같다.

User-agent: Yeti
Allow: /main/imagemontage
Disallow: /
User-agent: *
Disallow: /

네이버 뉴스 페이지에서 확인 할 수 있듯이 Disallow / 가 있는 이상 크롤러는 뉴스 페이지를 탐색 할 수 없다. 바로 이 로봇 룰 때문에 구글에서는 네이버 뉴스가 검색 결과로 뜨지 않는다. 모든 경로를 방문하지 말라고 명시 해 두었기 때문이다.

User-agent: *, 즉 모든 사용자, 크롤러는 / 영역을 방문해서는 안된다. 사실 **지금까지 온갖 블로그에서 소개한 네이버 뉴스 크롤러들은 robots.txt를 준수하지 않은 것이다. **

그러나 네이버 뉴스 페이지를 방문 할 수 있도록 허용된 User-agent가 하나 있는데 Yeti는 네이버를 크롤링 할 수 있다. Yeti는 네이버에서 개발한 크롤러다.

네이버는 Yeti라는 크롤러 전에 NaverBot이라는 크롤러는 과거 일본 시장 진출을 시도 했다가 욕먹고 사라진 이력이 있다. NaverBot은 일본 위키피디아에 '악성 봇'으로 등록되는 오명을 갖게 됐다. 한국에서 네이버는 상당히 성공한 검색 서비스이지만 일본에서 네이버의 크롤러는 robots.txt를 준수하지 못했다는 이유로 꽤 많은 욕을 먹었었다.

📖 NaverBot

"일본에서는 국제 기준에 대한 대응이 미비하다는 일부 Web 사이트 관리자들의 지적으로 액세스를 거부한 경우도 있었다. 이에 대해 네이버 측은 공식 코멘트를 내고 있지는 않지만, 후속 크롤러 (YetiBot)는 당시 지적 된 다음과 같은 문제가 모두 해결되어있다."

"日本では、国際基準への対応不備などの問題が一部のWebサイト管理者らに指摘され、アクセスを拒否するサイトも見られた。これに対して、ネイバー側は公式のコメントを出してはいないが、後継のクローラー（YetiBot）では当時指摘された以下のような問題はすべて解決されている。"

📖 https://ja.wikipedia.org/wiki/NaverBot 🇯🇵

네이버의 일본 진출은 이것으로 세번째다. 일본에 서비스를 출시하기에 앞서 먼저 크롤러를 보내서 일본의 웹 페이지를 탐색 할 필요가 있었겠지만 robots.txt를 준수하지 않아 부정적인 시선을 사고 말았다.

📰 이해진의 3번째 도전…"네이버 검색 일본 진출 이번엔 꼭 성공"(종합)
📰 네이버, 3·1절에 일본 진출 선언…이해진 세번째 도전 성공할까

비슷하게 중국의 바이두의 크롤러 로봇도 이와 관련해 문제를 일으킨 적이 있다. 크롤러는 기술적 성능도 중요하지만 이런 사회적 이슈는 더 중요한 어플리케이션이다. 반면 구글의 경우 자신들의 로봇과 크롤러에 대해서 상세히 설명 해 두었다.

📄 기술 표준

"웹 퍼블리셔의 의견을 존중할 수 있는 이유는 구글이 ‘인터넷 검색엔진 배제표준’(Robots Exclusion Protocol)과 NOARCHIVE 메타 태그를 준수하기 때문입니다. 구글보다 앞서 잘 정립된 기술에는 검색엔진에 사이트의 어떤 부분이 검색 가능하고, 어떤 부분은 검색결과에 나타나야 할지를 구별하는 기능이 있습니다."

📎 저작권 및 웹 검색에 관한 구글의 정책

이렇듯 robots.txt는 내가 블로그를 운영하거나 서비스를 개발 할 때 어떤 정보를 중점적으로 노출하고 어떤 것은 크롤링되지 않게 할 것인지 결정할 수 있는 중요한 개념이다. SEO에도 영향을 많이 끼치는데 스타트업의 대표나 개발자들 조차도 이 부분이 미비한 경우를 많이 봤다. robots.txt를 Disallow: /라고 작성 해 둬서 구글에서 자사 서비스명을 검색해도 결과가 나오지 않아 고민 하고 있었다. 모든 크롤러를 Disallow 해 뒀으니 당연한 결과였지만 아무도 이유는 몰랐다.

🤔 "User-Agent 쯤이야 쉽게 바꿀 수 있잖아요?"

Http 요청 헤더에 있는 User-Agent는 손쉽게 수정 할 수 있다. 누구나 대충 크롤러 하나 만들어두고 'GoogleBot'인척 속일 수 있는 것이다. 그래서 크롤러를 운영하는 회사들은 크롤러의 IP 대역도 함께 공개 해 두고 있다. Pinterest의 경우엔 54.236.1.XXX IP 대역을 사용한다. 따라서 Reverse DNS 조회를 통해서 이 User-agent가 진짜 Pinterset 또는 Google-bot인지 알 수 있다.

📌 Pinterest 사용자 ID

Pinterest/0.2 (+https://www.pinterest.com/bot.html)
Mozilla/5.0 (호환, Pinterestbot/1.0, + https://www.pinterest.com/bot.html)
Mozilla/5.0 (Linux, Android 6.0.1, Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, Gecko 등) Chrome/41.0.2272.96 Mobile Safari/537.36 (호환, Pinterestbot/1.0, + https://www.pinterest.com/bot.html)

Pinterest IP는 동적이고 자주 변경되지만 항상 54.236.1.XXX 범위 내에 있습니다.

📎 Pinterest의 크롤러 소개

🚧 여기서 부터는 공사중 입니다.

올해 초 부터 계획을하고 준비해 왔던 포스트입니다. 이대로 있다가는 평생 글 출간 못하겠구나 싶어서 일단은 작성중인 상태로라도 임시로 올리기로 마음먹었습니다. 여기서 부터는 중간 중간에 문장이 어색하고 빵꾸가 나 있거나 아니면 아예 작성이 시작도 안 된 부분도 많습니다. 사람들의 독촉적 반응이 있으면 더 열심히 쓸 수 있을 것 같아서 비록 미완성이지만 일단 지르기로 했습니다.

🚰 Content Extraction

인터넷 강의에서 말하는대로 CSS Selector를 통해서 DOM에서 text를 추출하는 방법이 나쁜건 아니지만 조금만 UI가 변경 돼도 작동이 안 될 각오를 해야한다. 본문 추출 역시 웹 크롤링을 할 때 맞닥뜨리는 까다로운 문제다.

뉴스 기사를 읽기 위해 페이지를 로드하면 중요한 본문 내용보다 저질 광고와 관련 없는 다른 내용들이 더 많은 경우가 있다.

📄 DOM based content extraction via text density

DOM 트리를 구성 한 뒤에 Text를 포함하고 있는 DOM을 밀도(Density)라는 관점에서 바라보고 본문을 추출하는 방법을 소개하고 있다.

🚜 크롤러 아키텍쳐

🧭 Fetch

Fetch는 다음에 방문할 URL을 가져와서 페이지를 방문한다. 여기서 방문이란 Http 요청을 보내 Response Body를 가져오는 과정이라 할 수 있다. Body의 DOM 해석은 Parse 단계로 넘긴다.

어떤 논문들은 Fetch 부분을 Multi-Thread Downloader라는 다른 이름을 써서 소개하기도 하는데 이 글에서 Multi-Thread까지 다루기는 무리가 있다. 어디까지나 내 생각인데 멀티 스레딩 보다는 곧 설명할 Parallel Crawl을 이해 하는 것이 훨씬 낫다고 생각한다. Multi-Thread를 주제로 글을 쓴다면 velog 역사상 가장 긴 포스트를 써야 할거고 이 분야만 죽어라 공부하시는 분들도 있는데 내가 감히 쓸 수가 없다;

🔎 Parse

가져온 페이지 내의 다른 Hyperlink를 추출 해는 과정이라고 해서 다른 논문에서는 URL extraction이라고도 말한다. HTML 문서일 경우 주로 <a> 태그나 <link>가 좋을 것이다. DOM은 트리 구조로 이루어져 있다.

Parsing이 쉽지 않은 이유는 웹 페이지가 HTML 표준을 늘 지키고 있는건 아니기 때문이다. 브라우저들은 사이트가 HTML 표준을 안 지키거나 태그가 엉망친창이라도 사용자에게 최대한 제대로 UI를 보여주기 위해 노력하기 때문에 괜찮지만 DOM 데이터를 해석하는 입장에서는 태그 하나만 제대로 닫히지 않았거나 오타만 있어도 혼돈이다. 학교 과제나 코딩 테스트에서는 늘 정돈된 데이터를 접하지만 야생의 www는 알 수 없는 예외 상황들을 해결해야만 한다. 수백 단위로 중첩된 DOM 깊숙히 내려가야하고 UTF-8이 아닌 문자를 다뤄야하는 Encoding 문제를 만날 수도 있다. 특히 요즘에는 지금 이 글과 같이 이모지를 많이 쓰기 때문에 주의가 필요하다. 이모지는 UTF-8 4바이트로 표현이 되는데 MySQL의 UTF-8은 3바이트기 때문에 이모지로 쿼리를 날리는 시도를 하면 에러가 발생한다.

브라우저에서 파서가 어떻게 동작하는지 더 자세히 알고 싶다면 한국어로 잘 정리된 글이 있다. 📎 브라우저는 어떻게 동작하는가?

🗺 URL Frontier

디지몬 프론티어 ㅋㅋ.

지금까지 설명한 내용만으로 웹 크롤러 코드를 작성 해 본다면 대충 이렇지 않을까?

🗑 Dup URL Elim

이미 방문 했던 URL을 다시 방문하지 않도록 중복 URL을 제거하는 단계다.

아래 두 URL은 실제로 같은 URL이기 때문에 Query Parameter는 Ordering을 해 주어야 한다.

https://example.com?page=1&section=1
https://example.com?section=1&page=1

📄 Efficient URL caching for world wide web crawling

🍉 Freshness, ⏰ Revisiting

자꾸 딴 이야기해서 미안한데 어떤 논문에서는 이 부분을 Scheduler라고 하기도 한다. 자 아무튼, 크롤러가 한 번 페이지를 방문했다면 다음에 다시 이 페이지를 언제 방문 해야할까?

쇼핑 같은 오픈 마켓 플랫폼에서 판매자가 가격을 바꿨을 경우 크롤러는 최대한 빨리 변경된 가격을 UPDATE 할 필요가 있다. 사용자가 최저가 상품을 클릭했음에도 불구 막상 판매 페이지에서는 전혀 다른 가격이 표시되는 경험을 해 본적이 있을 것이다. 판매자가 가격을 바꿨지만 크롤러가 상품 페이지를 재방문(revisit)하지 않아 가격 UPDATE가 이뤄지지 않은 경우 이런 일이 벌어진다.

Page Freshness를 유지 하기 위해서는 어떻게 해야할까? 크롤러가 최대한 자주 HTTP 요청을 보낸다면 Freshness를 유지하기 쉽겠지만 웹 크롤러가 수억개의 상품 페이지에 계속해서 이런 요청을 보내는건 엄청난 비용이 든다. 앞서 네이버의 웹 크롤러 NaverBot의 사례에서도 살펴 봤지만 크롤러가 Freshness를 유지하기 위해서 집중적으로 몇몇 페이지를 여러차례 방문하는 것은 좋지 못한 결과를 가져왔었다. 그렇다면 어떻게 사이트에 최소한의 부하만 줌면서 웹 크롤링으로 데이터의 Freshness를 확보 할 수 있을까?

👮🏻‍♀️ Uniform

유니폼 스케줄링은 페이지의 성격이나 업데이트 주기에 관계 없이 일정 간격으로 페이지를 재방문하는 전략이다. 다른 스케줄링 알고리즘과의 성능 비교를 위해 등장한다.

ƛ Lambda Crawl

조정후 교수와 헥토르 가르시아 몰리나 교수가 📄 (2003) ACM Trans Database Syst 28:390–426 에서 제안 했던 최적화 모델을 좀 더 쉽게 쓸 수 있도록 발전 시킨 방식이다. '람다 크롤'이라고 소개하는 이 스케줄링 방식은 굉장히 높은 성능을 보여준다. 자주 변화 하는 페이지의 방문 간격을 점점 줄여나가지만 너무 많이 변화하면 오히려 점수를 깎아버리는 함수다.

Freshness를 유지하기위한 스케줄링 알고리즘은 크게 두 가지 중요한 것이 있다. 람다 크롤도 이 두가지를 가장 중요하게 보고 있다.

이 페이지가 얼마나 자주 바뀌는지
이 페이지를 유저들이 얼마나 찾는지

간단하게 말하자면 웹 크롤러는 중요한 페이지들은 최대한 Fresh하게 유지하면 되는 것이다.

논문을 보면 온통 수학 공식 투성이라서 쉽게 설명할 엄두가 안 나서 이 부분 나중에 완성해야겠다...

🏃🏻‍♀️ Machine Learning

이 부분이 빠질래야 빠질 수 없을 것이다. 2010년 이후 크롤러 분야에 있어서도 머신러닝을 적용 해본 논문들이 많이 등장했다. 페이지 변경 여부를 예측 모델링 하는 것은 그야말로 안성 맞춤이기 때문이다.

논문에서는 Multi-Aramed bandit을 사용했는데 덕분에 매우 높은 성능을 확보 할 수 있었다고한다. 특히 리소스가 적을때도 높은 성능을 보여줬다. 재방문(revisit) 문제를 해결하기 위해 머신 러닝을 적용하고 실험 한 논문이지만LambdaCrawl 방식이 꽤 높은 성능을 보여줘서 놀랐다고 한다.

머신러닝과 관련하여 이 포스트에서는 자세히 설명 할 수 없다. 이미 좋은 한국어 자료가 많으니 Multi-Armed Bandits이 대충 무엇인지 정도만 짚고 넘어가자.

💪🏻 Multi-Armed Bandits

"Multi-Armed Bandits은 카지노에서 어떤 슬롯머신에 투자를 해야 이익을 최대화할 수 있을지에 대한 문제를 풀기 위해 만들어진 알고리즘으로 알려져 있습니다. 쉽게 말하면 Multi-Armed Bandits은 사용자가 어느 슬롯머신의 손잡이를 당겨야 가장 높은 수익을 올릴 수 있을지를 결정할 수 있는 알고리즘입니다."

📎 Multi-Armed Bandits
📖 Multi-armed bandit - Wikipedia 🇺🇸

👁 Content Seen?

중복 문서를 잘 필터링하는 것도 크롤링 아키텍쳐에서 중요한 부분이다. 좋은 글이나 페이지는 여기저기 복사 되어서 퍼가기 마련이다. 인터넷에는 같은 내용의 문서들이 이곳 저곳에 퍼져있다. 크롤러는 자연스럽게 이 모든 페이지를 수집하게 될테고 만약 이 데이터를 그대로 검색 엔진에게 넘겨 준다면 사용자 검색 결과에서는 똑같은 내용의 문서들이 수십개씩 나올 것이다.

Near-Duplicate Document는 이런 고민을 해결하고자 하는 분야다. 두 문서가 비슷한 내용인지 아닌지 어떻게 알 수 있을까? String Compare를 사용한다면 단 하나의 공백이나 글자만 달라져도 두 문장은 전혀 다르다고 할 것이다.

"다람쥐 쳇바퀴에 타고파"
"다람쥐 쳇바퀴에 타고파."

사람이 보기에는 분명 같은 문장이고 내용지만 데이터적으로는 확실히 다른 문장이다. 첫 번째 문장의 길이는 12이고 두 번째 문장의 길이는 마침표가 붙어서 13이기 때문이다. 얼핏 생각해도 String Compare는 중복 문서를 필터링하는데 좋은 방법은 아니다.

문장이 얼마나 어떻게 다른지 측정하기 위해서 문장을 단어로 쪼갠 다음에 좀 더 자세히 파악 해 볼 필요가 있다. 예컨대 어떤 문장이 단어 A, B, C로 이루어 져 있다고 보고 이것을 유사도(Similarity)라고 부르도록 하자.

🃏 JACARD

자카드 유사도는 흔히 생각 해 볼 수 있는 간단한 방법이다. 그러나 이 방법을 쓰려면 문장을 어떻게 단어 단위로 분리 할지 결정해야한다. "~다", "데", "것"과 같이 너무 흔히 등장하는 요소들은 stop-word라고 하는데 이런것들을 우선 제거 해 주어야 한다. 더 나아가면 이것은 결국 한국어 형태소 분리 문제에 직면하게 된다.

📐 cos similarity

#️⃣ Sim Hashing

📃 Detecting Near-Duplicates for Web Crawling

Detecting Near-Duplicates for Web Crawling 논문 역시 700회가 넘도록 인용된 중요한 논문이다. 📃 **Similarity Estimation Techniques from Rounding Algorithms**에서는 문서 마다 고유한 Finger Print, 해시값을 생성하는 방법을 제시했다.

👨🏽‍💻 **Gurmeet Manku**는 현재 구글의 소프트웨어 엔지니어다. 크롤러나 정보검색 관련 해서는 역시 구글의 연구인력이 압도적이다.

대학생들의 졸업 논문, 에세이의 표절 여부를 가리는데 쓰이도 한다.

🧑🏻‍🎨 state-of-the-art

AI나 머신러닝을 공부하다 보면 높은 성능을 달성해서 완벽에 가까워진 모델에 SoA라고 한다. 사전에서는 대부분 '최첨단'이라고 많이 번역하고 거의 최고의 경지에 도달했다는 의미로 많이 쓰이는데 나는 이 용어는 '예술의 경지'라고 번역하는게 딱 알맞지 않나 생각한다.

👯‍♀️ Parallel Crawler

드넓은 www를 탐색하기 위해서는 여러대의 크롤러는 필수적이다.

Parallel Cralwer 역시 수백회 넘게 인용된 멋있는 논문이다.

robots.txt를 잘 지키는 크롤러가 한 대 있다고 가정하자. robots.txt에서 이 크롤러에게 최대 방문 주기를 10초로 설정했다면 크롤러는 24시간동안 이 사이트에서 최대 86400개의 페이지만 탐색 할 수 있게 된다.

Crawl-delay: 10

이런 상황 속에서 크롤러가 멀뚱 멀뚱 있는 동안 다른 사이트는 쉴 새 없이 바뀌고 있을 텐데 어떻게 하면 좋을까?

개발자들을 현혹하기 좋은 단어가 Sacalable, Scale Out이다. 쉽게 병렬 확장이 가능하다는 것은 비즈니스에서도 환영받는다.

패러랠 크롤링은 어떻게 여러대의 노드로 크롤링을 해야 할지 고민한 결과다. 역시 UCLA의 조정후 교수가 여러대의 노드를 사용한 크롤링에 획기적인 방법을 제안했다.

멀티 스레딩과 같은 동시 프로그래밍에서도 첫 번째 고민되는 문제는 '어떻게 작업을 분리할까?'이다. 크롤러의 경우 URL이 작업 단위가 될것이다.

👑 Master-Slave

그림에서 보시다시피 SPOF가 된다. 모든 크롤러가 작업 상황을 공유하고 있어야 하는데 Master Node가 사망하면 나머지 크롤러들의 작업도 멈출 수 밖에 없는 구조다.

🌋 SPOF (Single Point of Failur)

한국어로 직역하면 보통 '단일 실패 지점'이라고들 하는데 기술 용어 번역이 늘 그렇듯이 다정하지 못하다. '터지면 다 죽는 곳'라고 번역해야 더 쉽다. 예컨대 A 서버가 죽으면 서비스 전체가 다운된다고 할 때 A서버는 SPOF가 된다. 번역은 늘 어렵다.

⛰ Stand-alone

크롤러가 이제 독립 할 필요성을 느낀다. 마스터 노드가 없어도 크롤러가 '혼자서도 잘 해요'를 하려면 어떻게 해야할까?

Parallel Crawling 논문에서는 여러가지 모드를 소개한다. 세 가지 정도만 알아보도록 하자.

🔥 Firewall mode

Firewall mode는 가장 단순하고 이해하기 쉽다. Firewall mode는 각 크롤러가 inter-link를 전혀 신경쓰지 않는 방식으로 크롤링한다. C1 크롤러는 S1 사이트만 방문하고 C2 크롤러는 S2 사이트만 방문하는 방식이다. 즉 자기 담당 사이트를 벗어나는 링크, 도메인 밖으로 나가는 외부 링크는 무시하는 방식이다.

가장 구현하기 쉽지만 Firewall mode에서는 모든 페이지를 구석 구석 다 방문하지 못할 수도 있다. 어떤 페이지는 반드시 inter-link를 통해서만 접근 할 수 있기 때문이다. 예를들면 Figure 2에 나와있는 d와 e페이지가 그렇다. d페이지는 h 페이지를 통해서만 갈 수 있는데 Firewall mode에서 d페이지는 C2 크롤러 담당 사이트가 아니라서 방문하지 않기 때문이다.

이처럼 Firewall mode는 크롤러끼리 작업 공유를 위한 네트워크 통신을 하지 않아서 커뮤니케이션 비용이 확 줄어들지만 유실되는 페이지가 있을 수 있다는 단점이 있다. 이 모드로는 Figure 2에서는 d, h 페이지를 수집 할 수 없을 것이다.

🤼 Cross-over mode

⚖️ Exchange mode

Exchange mode는 URL을 크롤러끼리 교환하는 방법이다. 이 모드는 Firewall mode에서의 단점을 해결 할 수 있다.

C2 크롤러는 페이지를 방문하다가 d 페이지로 갈 수 있는 inter-link를 발견하게 될 텐데 이 링크는 C1 크롤러에게 던져 주는 것이다.

크롤러끼리 계속해서 URL을 교환해야 하기 때문에 가장 많은 네트워크 트래픽이 발생한다.

📉 URL exchange minimization

여러가지 방식을 살펴 봤고 Parallel Cralwer 논문은 URL Exchange의 성능이 가장 높다고 평가하고 있다. URL Exchange mode의 가장 큰 단점은 URL 교환이 자주 일어나는 만큼 네트워크 비용도 높아진다는 것이다. 그렇다면 URL 교환을 줄이기 위해서는 어떻게 해야할까?

🤙🏻 Batch communication

이 방법은 그냥 URL set을 크롤러끼리 한 번에 주고 받는 방법이다. 이름에서 알 수 있듯 배치 단위로 URL을 교환하기 때문에 네트워크 통신량이 비교적 적다는 장점이 있다.

🖨 Replication

😮 너무 복잡해요

검색 엔진 서비스를 하려는게 아닌이상 대부분의 상황에서는 크롤러를 만들기 보다는 웹 스크래퍼를 만드는 것으로 끝난다. 아래와 같은 상황을 생각 해 볼 수 있다.

정부 관련 사이트에서 엄청 많은 공시 정보를 가져와서 엑셀에 정리 해야 해요.
매일 기상청 사이트에서 업데이트 되는 날씨 정보를 가져와야 해요.
게시판에 새 글이 올라 왔는지 정기적으로 체크하고 알림이 와야해요.

위와 같은 그냥 일회성 작업들은 굳이 크롤러를 만들 필요는 없다. 이런 상황에서는 스크래퍼가 더 적합하다. 그러나 스크래퍼들을 '크롤러'라고 부르고 있는 실정이긴 하다.

✂️ 스크래핑

웹 사이트를 손 쉽게 스크랩 할 수 있도록 도와주는 툴은 많이 나와 있다. 👻 PhantomJS 라던가...

📎 토스가 현대카드를 연동하는 방법에 동의하지 않습니다 :: Outsider's Dev Story

토스나 뱅크 샐러드가 각 은행, 카드사를 스크래핑하여 유저 대신 로그인과 송금 등을 대행하는 경우가 그렇다. 기업과 기업간의 정보 스크래핑 전쟁은 지금도 이뤄지고 있다.

크롤러 스스로 윤리 규정을 만들고 지키도록 한 rule에 불과하지만 웹 컨텐츠를 만들어 내는 작가들, 크리에이터들에 대한 존중과 저작권에 대한 의식이 담겨 있다. 네이버의 크롤러가 robots.txt를 무시하면서 일본 웹 마스터들에게 거부당했던 사례를 생각 해 보면 크롤러는 결코 간단하게 웹 사이트를 수집하는 것에 그쳐선 안된다는 걸 알 수 있다.

구글의 경우 웹 퍼블리셔들의 컨텐츠를 존중해 왔다. 그렇게 인터넷의 성장에 크게 한 몫했지만 이제 구글은 개인정보 수집 문제로 많은 질문을 받고 있다. 이런 과정 속에서 등장한 것이 개인정보를 전혀 수집하지 않는 검색 서비스 📎 **DuckDuckGo**였다. 검색 서비스가 대체 왜 사용자의 쿠키와 활동을 수집해야하는지 이해 할 수 없다는 창업자 가브리엘 와인버그는 오직 검색에만 집중하기 위한 서비스를 만들었다.

🍗 마무리

크롤러의 개념을 정의하기 위해서 논문들 몇개를 가져다 놓고 최대한 겉만 핥아 보았다. 논문에서는 훨씬 더 자세히 설명하고 있고 알 수 있는 아이디어들도 많다.

하루가 멀다하고 새로운 용어와 기술들이 쏟아져나온다. 취업이나 기업의 비즈니스에서 폭발적인 인기를 누리는 새롭고 화려한 프론트 엔드 기술들이 많다. 반면 크롤러는 '데이터 수집'에 불과한 개념으로 알려져 있고 신입 이력서들을 보면 대부분 '날씨 정보 크롤링 해 봤습니다' 정도로 쓰이는 경우가 많은데 웹 크롤러는 컴퓨터 공학의 모든 기초 지식이 동원되는 아주 흥미로운 소프트웨어다. 이 글이 한국어로 된 웹 크롤링 관련 기술글로서 가치를 다 하고 앞으로 더 좋은 크롤러 관련 글들의 마중물이 됐으면 한다.

📘 더 읽어 볼 거리

모빈켈의 글

📎 https://velog.io/@mowinckel/웹-크롤링-I

👏🏻 KakaoPay로 서포트하기

다음 글 연재를 위해 지원하고 싶은 분들은 자유롭게 도네이션 해 주세요. 기부하신 돈은 모빈켈의 사리사욕을 채우기 위해 사용됩니다.

{
  "sponsors": [
    {
      "박*준": {
        "amount": 30000,
        "message": "글 항상 잘 보고 있습니다."
      }
    },
    {
      "박*희": {
        "amount": 2200,
        "message": "github.com/9j"
      }
    }
  ]
}

🚜 웹 크롤링과 아키텍쳐

댓글