“빈 페이지” 문제
AJAX 크롤링은 크롤러 봇이 정적 HTML 대신 백그라운드 JavaScript 요청을 통해 로드된 데이터를 렌더링하거나, 기다리거나, 직접 캡처할 수 있도록 조정된 크롤링 프로세스입니다. 비동기 JavaScript 및 XML(AJAX)은 수십 년 동안 웹 개발 업계에서 사용되어 왔지만, 이제는 XML 형식보다는 JSON 형식으로 데이터를 가져오는 클라이언트 측 JavaScript로 발전했습니다.
웹페이지를 완벽하게 스크래핑하는 강력하고 효율적인 웹 스크래퍼를 구축했다고 가정해 봅시다. 하지만 다음 날 다시 확인해 보면 더 이상 작동하지 않을 수 있습니다. 이전에 수집했던 데이터 필드는 비어 있지만, 웹페이지를 열면 화면에는 그대로 표시됩니다. 스크래퍼가 가져온 HTML 구조를 확인해 봐도 데이터가 전혀 없습니다. 이러한 문제는 많은 사람들이 비동기 JavaScript 및 XML(AJAX) 크롤링에서 겪는 문제와 유사합니다.
이 시나리오는 사람들이 AJAX 크롤링 문제를 접하게 되는 일반적인 경로를 설명하지만, 개발자에게는 매우 중요합니다. 현대 개발은 모든 것을 가속화하는 것을 목표로 하며, 웹사이트의 99%가 JavaScript를 사용하기 때문에 이제 정적 및 동적 방식으로 모두 로드됩니다. 동적 로드 부분은 비동기적으로 처리되는데, 스크래퍼가 데이터를 가져올 때 누락되는 부분이 바로 이 부분입니다.
이 글에서는 Ajax 크롤링 관련 문제가 발생하는 이유와 시기, 그리고 여러 가지 해결 방법을 살펴보겠습니다.
이 글은 다음 주제를 다룹니다:
1. Ajax 크롤링이란 무엇인가
2. 기존 크롤러가 Ajax 페이지에서 실패하는 이유
3. 실제 Ajax 크롤링 작동 방식: 세 가지 핵심 모델
4. 코드 프리 Ajax 크롤링 대안
기존 크롤링과 AJAX 크롤링의 차이점
기존 크롤링 방식과 비교했을 때, Ajax 크롤링에는 몇 가지 핵심적인 차이점이 있습니다.
- 기존 방식의 크롤링 : 크롤러 봇이 HTTP 요청에서 정적 HTML 파일을 가져옵니다.
- Ajax 크롤링 : 초기 HTML 페이지 로드 후, XHR 또는 Fetch 요청을 통해 동적 콘텐츠를 정적 영역에 로드합니다. 이 과정은 좀 더 고급 기술이며, 크롤러가 브라우저 환경을 시뮬레이션하여 이러한 요청을 모방해야 합니다.
기존 크롤링 방식과 AJAX 크롤링 방식의 가장 큰 차이점은 페이지를 처리하는 방식에 있습니다. AJAX 크롤링은 전체 프로세스를 관찰하며(모든 콘텐츠가 로드될 때까지 기다림), 기존 크롤링 방식은 정적인 문서만 처리합니다. 따라서 최신 웹 크롤링 도구는 웹 페이지 개발 및 로드 방식의 변화에 맞춰야 합니다.
기존 크롤러가 AJAX 페이지에서 실패하는 이유
수동으로 구축된 크롤러는 파이썬의 requests 라이브러리를 사용하여 HTML 구조를 가져온 다음 파싱하지만, 우리가 추출하고자 하는 중요한 데이터 콘텐츠를 놓칩니다. 점점 더 많은 웹사이트가 AJAX 기술을 사용하여 전체 콘텐츠를 로드하므로 기존 크롤링 방식으로는 뼈대만 로드하게 됩니다.
웹사이트 콘텐츠는 브라우저 백엔드에서 JavaScript를 실행하여 현재 데이터를 가져올 때만 로드됩니다. 이 과정은 로딩 속도를 향상시키는 데 도움이 되지만, 기존 크롤러는 이러한 방식에 맞게 설계되지 않았습니다. 동적으로 로드되는 웹사이트에 기존 크롤러를 적용하면 다음과 같은 여러 문제가 발생할 수 있습니다.
- 빈 필드 : 브라우저에 표시되는 목록, 표 또는 제품 그리드가 가져온 HTML 페이지에서는 비어 있습니다.
- 페이지네이션 없음 : 일반적으로 ‘다음’ 페이지 버튼은 JavaScript에 의해 로드되므로 웹사이트의 첫 페이지에서만 크롤링이 발생합니다. 두번째 페이지부터는 인식 및 클릭이 안 되는 현상이 발생합니다.
- 로딩 지연 : 스크롤이 필요한 데이터는 정적 페이지에서 처음에 로드되지 않으므로 표시되지 않습니다.
requests 라이브러리는 네트워크 호출을 트리거하거나 DOM(문서 객체 모델)을 조작하는 스크립트를 실행하는 JavaScript 엔진을 갖추고 있지 않으므로 이러한 작업에는 적합하지 않습니다.
실제 AJAX 크롤링 작동 방식: 세 가지 핵심 모델
전통적인 크롤링 방식도 여전히 유용하지만, 동적 로딩 문제를 극복하고 다양한 AJAX 크롤링 기법을 활용하는 방법을 보여드리고자 합니다.
방법 1: 브라우저 렌더링(전체 시뮬레이션)
완전한 브라우저 복제는 그래픽 인터페이스가 없는 헤드리스 버전을 실행하여 페이지를 로드하고, JavaScript 요청을 실행하고, DOM이 준비될 때까지 기다립니다. 이 접근 방식을 사용하면 발생할 수 있는 모든 작업을 처리할 수 있는 브라우저를 갖추게 되어 안전성을 확보할 수 있습니다. 클릭, 스크롤, 로그인 등 브라우저와의 모든 상호 작용이 가능합니다.
이 브라우저는 헤드리스 모드로 실행되지만, 이 방법은 CPU/RAM 사용량이 매우 높습니다. 다른 자체 개발 크롤러와 마찬가지로, 적절한 조치를 취하지 않으면 봇 방지 시스템에 의해 차단될 수 있습니다.
방법 2: XHR/API 스니핑(직접적인 접근 방식)
XHR/API 스니핑을 이용한 백그라운드 네트워크 요청 분석은 브라우저와의 상호 작용을 건너뛰고 JavaScript를 사용하여 데이터를 직접 로드합니다. 이 방법은 필요한 구조화된 데이터를 제공하는 적절한 API 엔드포인트를 식별하고 직접 호출합니다.
이전 방식과 달리, 이 방법은 데이터 소스에 직접 접근하여 컴퓨팅 리소스를 적게 사용합니다. 소스에서 직접 데이터를 가져오면 필요에 따라 데이터 형태를 변형하고 추후 추가 처리에 활용할 수 있습니다. 하지만 이 접근 방식의 또 다른 단점은 적절한 인증 및 매개변수 구현을 포함하여 API 로직을 역설계하는 데 상당한 초기 기술적 노력이 필요하다는 점입니다.
패킷 스니핑을 위한 요청을 찾는 조사 과정은 브라우저의 요소 검사 기능에서 네트워크 탭을 사용하는 것을 포함하며, requests 라이브러리를 사용하여 프로그래밍 방식으로도 수행할 수 있습니다.
방법 3: 하이브리드 접근 방식
하이브리드 크롤링 방식은 앞서 설명한 두 가지 방법을 결합한 것입니다. 먼저 헤드리스 브라우저를 실행하여 데이터 API 엔드포인트와 세션 토큰을 찾은 다음, 대량 데이터 추출을 위해 XHR/API 요청을 직접 수행합니다. 이러한 방식으로 네트워크 탭을 디버깅하고 전체 워크플로를 역분석하는 수동 작업을 대체할 수 있습니다.
궁극적으로 크롤링의 두 가지 방식 모두 적절한 도구를 활용하여 리소스 사용과 시간 효율성을 향상시킵니다. 그러나 하이브리드 방식 역시 개발 노력과 기술적 지식이 상당 부분 요구되므로 완벽하지는 않습니다. 유지보수는 대부분의 프로젝트 실패 원인이며, 이 경우에도 마찬가지입니다.
파이썬을 이용한 AJAX 크롤링
웹 크롤러 개발에 있어 대부분의 개발자들이 선택하는 표준 프로그래밍 언어는 파이썬입니다. 파이썬은 생각할 수 있는 거의 모든 기능을 제공하는 라이브러리를 갖추고 있으며, AJAX 크롤링 또한 지원합니다.
파이썬으로 크롤러를 개발하는 데 가장 인기 있는 프레임워크로는 브라우저 자동화를 제공하는 Selenium , JavaScript(헤드리스) 기반의 Chrome/Chromium 브라우저 자동화를 제공하는 Puppeteer , 그리고 두 프로그래밍 언어를 모두 지원하는 Playwright가 있습니다.
Playwright를 사용한 일반적인 스크립트는 다음과 같습니다.
이 코드는 그래픽 사용자 인터페이스 없이 브라우저를 헤드리스 모드로 로드하고 원하는 웹페이지를 엽니다. 페이지 로드가 완료되면 특정 동적 요소들이 로드될 때까지 기다립니다. 콘텐츠가 제대로 로드되었는지 확인하기 위해 데이터 필드를 가져오기 전에 페이지 끝까지 스크롤할 수도 있습니다. 데이터가 완전히 로드되면 일반적으로 BeautifulSoup를 사용하여 HTML 구조를 파싱하고 포함된 모든 데이터를 통합합니다.
이 스크립트는 간단해 보이지만, 실제 운영 환경에서 사용되는 크롤링 도구와는 거리가 멉니다. 특히 필요한 크롤링 요소를 모두 찾고 페이지를 올바르게 로드하는 과정에서 초기 설정이 어려울 수 있습니다. 동적 콘텐츠는 끊임없이 변화하기 때문에 유지 관리가 매우 까다롭고 초기 개발에 드는 노력의 10배 이상을 요구합니다. 이처럼 포괄적인 크롤러를 개발하고 유지 관리하는 팀을 구성하는 대신, Octoparse와 같이 위의 모든 기능을 통합한 단일 전용 크롤링 도구를 사용하는 것이 훨씬 효율적입니다 .
파이썬 기반 AJAX 크롤링의 숨겨진 문제점
지금까지 파이썬 AJAX 크롤러를 개발할 때 발생하는 몇 가지 문제점을 언급했지만, 더 염두에 두어야 할 사항들이 몇 가지 더 있습니다.
- 변화에 대한 취약성 : 웹사이트는 끊임없이 변화하고 발전하기 때문에 AJAX 크롤러는 이러한 새로운 구조에 적응해야 하지만 결국 오류가 발생하여 데이터 손실로 이어질 수 있다는 문제점을 안고 있습니다.
- 속도 및 리소스 비용 : 크롤러에 가장 일반적으로 사용되는 헤드리스 브라우저는 특히 여러 인스턴스를 병렬로 사용할 경우 리소스 소모가 매우 큽니다.
- 봇 방지 탐지 : 최신 웹사이트는 자동화된 브라우저에서 발생하는 의심스러운 활동을 탐지하기 위해 고급 기술을 사용합니다. 마우스 움직임 분석, 프록시 사용 여부 확인, TLS 지문 분석 등 다양한 방법을 통해 크롤러가 차단될 수 있습니다.
- 유지보수 부담 : 네트워크 문제, 동적 콘텐츠 변경, 봇 방지 차단 등 여러 가지 문제로 인해 스크립트가 오류를 일으킬 수 있습니다. 이러한 경우 유지보수가 빈번하게 발생하고 많은 노력이 필요할 수 있습니다. 또한 간단한 업그레이드나 소프트웨어가 의존하는 다른 라이브러리를 업데이트하는 데에도 시간이 많이 소요됩니다.
- 확장성 병목 현상 : 대규모 프로젝트에서 여러 크롤러를 병렬로 실행해야 할 때 발생합니다.
코드 없는 AJAX 크롤링: 무엇이 달라질까요?
AJAX 크롤링의 이러한 발전은 모든 복잡성과 문제점을 추상화하여 사용자가 직접 처리할 필요가 없도록 하는 새로운 유형의 크롤러를 탄생시켰습니다. 바로 시각적이고, 코딩이 필요 없으며, 브라우저 기반의 크롤러입니다. 이러한 크롤러는 앞서 논의한 모든 문제를 기본적으로 처리하며, 사용자의 일상적인 작업 목록에서 유지 관리 부담을 덜어줍니다.
이제 전용 크롤링 도구가 이러한 기능은 물론 그 이상의 기능까지 지원하므로 JavaScript 요청 스니핑이나 헤드리스 브라우저에 대해 걱정할 필요가 없습니다. JavaScript 렌더링은 백그라운드에서 자동으로 처리되며, 브라우저와의 모든 상호 작용(클릭, 대기, 스크롤)은 기본적으로 지원됩니다.
AJAX 크롤링을 처리할 수 있는 크롤링 도구는 다음과 같습니다.
- Octoparse는 JavaScript 렌더링 및 AJAX로 로드된 콘텐츠 처리를 기본적으로 지원하는 포괄적인 노코드 솔루션으로, 모든 크롤링 요구 사항을 충족합니다
- ParseHub : AJAX 기술도 지원하는 데이터 마이닝 도구이지만, 기능이 단순하고 사용자 인터페이스가 구식입니다.
- Apify : 거의 모든 웹사이트에 적용 가능한 사전 제작된 템플릿을 제공하는 API 기반 접근 방식입니다. 크롤러(액터)를 사용하여 확장 가능한 맞춤형 솔루션을 구축할 수 있습니다.
경쟁이 치열한 AJAX 기반 크롤링 도구 시장에서 Octoparse는 제가 가장 선호하는 도구입니다. 저는 개인적으로 크롤링이나 스크래핑이 필요한 크고 작은 프로젝트 모두에 Octoparse를 사용해 왔습니다. 필요한 모든 작업을 맞춤 설정할 수 있고 Ajax 크롤링에 대한 적응성이 뛰어나기 때문에 별도의 유지 보수 없이도 지속적으로 데이터를 가져올 수 있습니다. 모든 도구는 저마다의 목적과 특화 분야가 있지만, Octoparse는 Ajax 기능을 활용하여 쉽고 간편하게 크롤링할 수 있도록 해줍니다.
웹 사이트 데이터를 바로 구조화된 엑셀, CSV, Google Sheets, 데이터베이스로 내보낼 수 있습니다.
자동 인식 기능으로 코딩 없이 간단하게 데이터를 스크래핑할 수 있습니다.
수백 개의 국내외 인기 웹 사이트 스크래핑 템플릿으로 간단하게 데이터를 추출할 수 있습니다.
IP 프록시와 고급 API 기능으로 어떤 웹 사이트나 막힘없이 스크래핑할 수 있습니다.
당신이 원하면 언제든 클라우드 서비스로 데이터 스크래핑을 예약할 수 있습니다.
AJAX 크롤링 문제에 대한 FAQ
- 어제까지는 정상적으로 작동했던 웹 스크래퍼가 지금은 빈 결과를 반환합니다. 이것은 항상 AJAX 관련 문제인가요?
아닙니다, 하지만 그럴 가능성이 매우 높습니다. 웹사이트의 99%가 자바스크립트를 사용하기 때문에 대부분의 오류는 웹사이트 구조가 동적으로 변경될 때 발생하며, 이것이 바로 문제의 원인일 수 있습니다. HTML 구조가 변경되고 스크래퍼가 더 이상 사용할 수 없는 데이터를 가져오려고 시도하면 오류가 발생합니다. 물론 이것이 유일한 원인은 아닙니다. 봇 방지 조치나 API 매개변수 변경 또한 원인이 될 수 있습니다.
- 웹페이지가 콘텐츠 로딩에 AJAX를 사용하는지 어떻게 빠르게 확인할 수 있을까요?
확인하려는 웹페이지를 직접 열고 마우스 우클릭한 다음 “페이지 소스 보기”를 선택하세요. 이 간단한 검사는 서버에서 전송된 원시적인 정적 HTML 구조만 보여줍니다. 가격이나 제품명과 같은 동적 데이터 필드를 확인하여 AJAX를 사용하는지 아니면 완전히 정적인지 확인할 수 있습니다.
웹사이트가 AJAX를 사용하여 콘텐츠를 로드하는지 확인하는 또 다른 방법은 “네트워크” 탭을 열고 페이지를 새로 고침하는 것입니다. 페이지를 스크롤하여 더 많은 콘텐츠를 로드할 때 JavaScript가 웹사이트 백엔드로 전송하는 XHR 또는 Fetch 요청만 필터링하여 확인하세요. 이러한 요청을 정확히 찾아낼 수 있다면 해당 웹사이트는 AJAX 호출을 사용하고 있는 것입니다.
- 브라우저 렌더링과 XHR 스니핑 중 어떤 방법이 더 나은가요?
두 방법 모두 서로 다른 사용 사례에 적합합니다. 리소스 문제가 발생하지 않는다면 브라우저 렌더링을 사용할 수 있습니다. 하지만 프로젝트 규모가 커짐에 따라 리소스 문제가 중요해지는 경우가 많으므로, 리소스 사용량이 적은 크롤링에는 XHR이 좋은 접근 방식입니다. XHR 스니핑은 API 호출을 역분석해야 하므로 시간이 걸리기 때문에 완벽한 방법은 아닙니다.
- 이 글에서는 파이썬의 유지보수 부담에 대해 언급하고 있는데, 구체적으로 어떤 부담을 말하는 건가요?
애플리케이션을 직접 개발하면 유지보수 책임은 개발자 본인에게 전적으로 있습니다. 경험 많은 소프트웨어 엔지니어들은 유지보수 작업이 초기 개발보다 10배는 더 힘들다고 말합니다. 라이브러리 업그레이드, 끊임없이 변화하는 동적 웹사이트, 크롤러에 새로운 기능 추가 등 업데이트가 끊이지 않습니다. 고급 기능을 개발하는 것 또한 쉬운 일이 아니며, 이러한 기능을 다루고 유지보수하는 것 역시 만만치 않은 작업입니다. 모니터링, 봇 방지 알고리즘, 오류 처리 등은 진화하는 소프트웨어에 필수적인 요소이며, 이를 구현하는 데에도 상당한 시간과 노력이 필요합니다.
- AJAX 크롤링을 위해 코드 없는 도구를 선택할 경우, 어떤 주요 제한 사항에 유의해야 할까요?
Octoparse와 같은 코드 없는 전용 크롤러는 AJAX 기술을 완벽하게 기본적으로 지원합니다. 특별한 제약 사항은 없지만 몇 가지 중요한 사항을 고려해야 합니다. 도구 비용은 프로젝트 규모에 따라 적절히 조정할 수 있으며, 전적으로 사용량에 따라 달라집니다. 도구와 그 기능을 사용할수록 점점 더 의존하게 될 것입니다.
