크롤링 대상의 사이트가 변경되면 어떻게 대처하면 좋을까 ?

개요

 

나름 여러 종류의 크롤러를 만들어왔다. 지금까지 만들어 본 크롤링 경험은 다음과 같다.

• 육군 전자 인터넷 편지 사이트의 취약점을 활용한 크롤링
  • 지금은 패치되었는지 모르겠지만, 당시엔 육군 전자 인터넷 편지에 IDOR 취약점이 있었다. 해당 사이트는 비밀번호가 걸려 있었지만, 요청 정보를 잘 조합해 URL에 직접 접근하면 비밀번호 없이도 인터넷 편지를 열어볼 수 있었다.
• SmileEdu라는 익명 기반 질문 사이트 크롤링
  • 대학생일 시절에 익명 기반 질문 사이트를 통해 질문을 받던 강의가 있었다. 익명 기반이라 누가 어떤 질문을 했는지 알 수 없었는데, 질문 내용으로 추가 점수를 준다는 교수님의 말에 “누가 어떤 질문을 했는지 알아낼 수 있을까?” 싶어 만들었던 크롤러다.
• Naver Band의 이미지 크롤링 및 자동 업로드
  • 공공 일자리 지원 사업에 참여했을 당시, 현장 답사자분들이 지역 상가 정보를 촬영해 네이버 밴드에 올리면 이를 시청 홈페이지에 수동으로 업로드하는 아르바이트가 있었다. 이 과정을 자동화하기 위해 만들었던 크롤러다.
• A3 Security 유지보수 스크립트 개편
  • 학교 선배가 현장 실습 중인 회사에서 업무 자동화 도구가 제대로 동작하지 않는다고 하여, 요구사항에 맞게 수정해드렸다.
• tradingview.com의 차트 데이터 크롤링
  • 신입 개발자 시절에 만들었던 크롤러다. WebSocket으로 송수신되는 데이터 형식을 분석해 차트 데이터를 수집했다. 인상 깊었던 점은 최신 데이터는 갱신이 가능하지만 과거 데이터는 수동으로 갱신해야만 패킷이 발생했다는 점이다. 당시 사수의 조언으로 스레드를 활용해 해결할 수 있었다.
• Google API를 사용하지 않는 Youtube 영상 정보 크롤링
  • 자주 듣는 유튜버의 커버곡을 다운로드해서 들으려고 했는데, 관련 서비스를 찾지 못했다. 그래서 직접 영상을 다운로드하고 mp3로 변환해 휴대폰에 넣어 다니려고 만들었던 크롤러다.
• 패션 콘텐츠 사이트 크롤링 (아이즈매거진, 패션친구, 패션인사이트, 하퍼스바자코리아, kmodes, krazmag, The kazemag, unnielook, voguekorea, yesstyle)
  • 23년 11월쯤 시작한 사이드 프로젝트에서 구현했던 크롤러다. 여러 패션 콘텐츠 사이트를 대상으로 했고 이때 새롭게 알게 된 테크닉도 많았다.
• 네이버, 카카오, 라인, 쿠팡, 배민 등 주요 테크 기업 채용공고 크롤링
  • 최근 사이드 프로젝트에서 선제적으로 데이터 수집이 필요해 구현했던 크롤러다.

 

기억나는 정도만 적어봤는데, 간단한 HTML Parsing부터 동적 데이터 변화 감지까지 꽤 다양한 범위를 다뤄온 듯하다. 이에 대한 생각을 정리할 겸 이 글을 적는다.

 

중심 주제는 제목에서 말했듯 "크롤링 대상 사이트의 구조가 변경되면 어떻게 대응하면 좋을까”이다.

 

 

크롤링 개발 시작하기

크롤링 개발의 시작점은 보통 간단한 HTTP Request 요청이다. 이를 통해 얻은 HTML 콘텐츠를 기반으로 수집 대상 데이터의 경로를 분석한 뒤, 원하는 형태로 추출 가능한지 시험해본다.

 

이 방식은 크롤링을 처음 시작할 때 사용하는 전형적인 예제다. 나 역시 이렇게 시작했다. 정적 데이터 로딩이므로 사이트 구조 변경 감지를 고민할 필요가 없기에, 생각보다 공수가 적게 든다.

 

이 단계에서 가장 중요한 점은 “수집 대상 데이터의 HTML 요소 경로를 어떻게 찾을 것인가?”이다. 처음엔 요령이 없어 HTML을 그대로 보며 하나하나 경로를 찾아냈지만, 이후 개발자 도구(F12)에서 Element Copy 기능을 활용할 수 있다는 걸 알게 된 뒤론 훨씬 수월해졌다.

 

 

정적 크롤링이어도 힘든 경우가 있다

정적 크롤링이라도 힘들어지는 경우가 있다. 대표적으로 사이트에 보안이 걸려 있는 경우다. 내가 겪었던 사례는 Cloudflare가 적용된 사이트였다. Cloudflare의 쿠키나 세션 동작 방식을 분석해 HTTP 요청에 넣어줘야 한다. 매번 신경 쓰기 어려운 부분인데, 이를 지원하는 라이브러리가 존재한다.

 

또 다른 경우는 User-Agent 필터링이다. 특정 User-Agent는 필터링 단계에서 차단되거나, 이를 기반으로 정상적으로 동작하지 않도록 구성된 경우가 있다. Http Request를 했는데 응답이 비정상적이라면 User-Agent를 확인해볼 필요가 있다.

 

동적 크롤링?

정적 크롤링에 익숙해지고 나니 동적 크롤링을 해야 하는 상황이 생겼다. 단순 HTTP Request로는 HTML 콘텐츠를 반환하지 않는 경우가 있기 때문이다. Selenium으로 해결할 수는 있지만, 여기서부터 새로운 문제가 시작된다.

 

동적 크롤링은 사용자의 행위를 모방한다. 브라우저를 열고, 사이트 주소를 입력하고, 요소에 값을 넣고, 버튼을 클릭하는 식이다. 이런 과정을 크롤러에 넣고 데이터가 잘 수집되는지 확인한다. 그러나 시간이 지나면 데이터가 더는 수집되지 않는 문제가 생긴다.

 

왜 데이터 수집이 안 되는가?

지난 경험으로 보면, 동적 크롤링의 한계는 HTML에 의존한다는 점이다. HTML 요소들은 언제든 바뀔 수 있는 마크업일 뿐이다. 그렇다면 HTML이 왜 바뀌는가? 답은 간단하다. 수집 대상 사이트가 개편되었기 때문이다.

 

사이트 개편이 일어나면 데이터 수집에도 차질이 생긴다. 수집하려던 데이터가 개편 이후에도 어딘가에 남아 있다면 다행이지만, 아예 제공하지 않게 되면 이는 설계 자체에 영향이 가는 심각한 문제다.

 

개편 이유는 다양하다. 단순 디자인 변경일 수도 있고, 레이아웃 구조 변경일 수도 있다. 본질적으로 생각해야 할 점은 바로 “대상 사이트는 얼마나 자주 변경되는가?”이다.

 

데이터 수집 최소화하기 + 네트워크 분석하기

위에서 말한 여러 문제들을 겪다 보니, 요즘은 데이터 수집 최소화와 네트워크 트래픽 분석을 기반으로 크롤러를 만든다.

 

데이터 최소화는 필요한 데이터의 속성을 정의해두고, “이 데이터가 지금 필요한가? 아니면 나중에 필요한가?”를 기준으로 점진적으로 수집 범위를 늘려가는 방식이다.

 

그럼에도 불구하고 변한다

이런 나름의 경험칙에도 불구하고, 변경될 건 결국 변경된다는 게 지금의 깨달음이다. 이는 소프트웨어 공학의 기본 원칙과도 연결된다.

 

“요구사항과 환경의 변화는 끊임없이 일어나며, 이를 관리·대응하는 것이 소프트웨어 공학의 핵심 과제”

 

그래서 크롤링을 만들 때는 유지보수 계획을 잘 세우는 것이 중요하다. 이는 개발자의 영역이라기보다 프로젝트 운영 전략에 가깝다.

 

물론 변경될 때마다 대응하는 것도 전략이 될 수 있다.

 

이 주제는 더 많은 경험을 통해 계속 고민해봐야 할 부분이라고 생각한다.