과거의 나...

크롤링에 대한 글을 쓴 일이 있다.

https://velog.io/@juunini/web-crawling

내 손으로 이렇게 썼다.

"마치 사람이 보는 것 처럼 천천히, 예의바르게 해라."

그 때는 많아봤자 하루에 100회정도만 크롤링 하면 됐다.
진짜 브라우저까지 가상으로 띄워서 할 것도 없었고 열심히 파내면 REST 만으로도 다 해결이 됐다.
그래서 "공손~하이, 댄디하게. 알긋나?" 할 수 있었다.

현재의 나

한 사이트를 하루에 100,000만번정도 크롤링 해야하는 일도 있다...
난 몰랐다. 이런 일이 있을 줄이야...

게다가 이젠 REST로 뚫을 수 없는 경우도 존재했다.
브라우저의 localStorage에 저장된 정보를 기반으로 뭔가 계산이 되는 부분도 있었고,
서버 내에서 다 처리되어 SSR로 보내오는데 도저히 뚫어낼 여지를 주지 않아서

어쩔 수 없이 가상의 브라우저를 띄워서 크롤링을 할 수 밖에 없었다.
될 때 까지 그냥 최대한 빨리 많이 띄워서 크롤링을 해야했다.

우리 팀이 하던 방식

selenium을 이용해서 하고있었다.
최대한 빨리 하기 위해 켤 수 있는만큼의 여러개를 실행시켜서 하는 방식을 하고있었는데,
점점 시간이 지나다보니 나는 이 방식이 좋지 않음을 느꼈다.

더 좋은 방법?

selenium도 그렇고, puppeteer도 그렇고 새 탭을 띄우는 기능을 제공한다.
그래서 여러개를 실행시키기보단 한개를 실행시켜 그 안에서 여러 탭을 띄우는것이 더 나을수도 있다.

내 맥북에서도 3개까지 띄우면 맥북이 더 이상 감당해내지 못하는 지경에 이르는데
탭으로 띄우면 조금 더 소화가 가능하다.
그래서 이쪽으로 개발을 해야지 하는 생각을 하고있다.

현실

쨋든 사용할 수 있는 모든 자원은 총 동원해서 최대한 빨리 많이 크롤링을 하고있다.
IP가 차단을 당할 수 있는 사이트의 경우엔 AWS ECS를 이용해 계속 새로운 인스턴스를 만들어 우회하는 방식도 우리 팀은 사용하고 있다.

왠만하면 해당 사이트랑 제휴를 맺어서 데이터를 제공받는 방식을 채택하려 하지만, 보내주는 데이터가 온전하지 않은 경우가 있기도 해서 그게 될 때 까진 계속 크롤링을 하기도 한다.

굉장히 양심의 가책을 느낀다.

느낀 점

뭔가 크롤링에 대한 기승전 이다가 결은 '그래서 튼튼한 서버를 구축해야 하는구나.' 라는 이상한 결론이 났다.

우리 회사가 커진다면 누군가가 우리를 크롤링 할 수도 있다.
우리도 그런 경우엔 선택을 할 수 있을 것이다.
차단을 하거나, 그냥 놔두거나, 데이터를 제공해주거나.

하지만 일단 서버가 튼튼해서 크롤링 좀 한다고 서비스가 망가지는 사태는 없어야겠다는 생각이 들었다.
크롤링하는 사이트들이 다 건재한데서 느끼는 점이다.