requests 라이브러리 같은 도구를 사용하는 기본 HTTP 스크래퍼는 거의 빈 페이지를 반환하곤 합니다. 원시 HTML은 가져오지만 실제로 원하는 데이터로 페이지를 채우는 JavaScript는 실행하지 않기 때문입니다.
이 문제를 해결하는 세 가지 접근 방식이 있으며, 적합한 방법은 사이트의 구축 방식에 따라 달라집니다. 적용할 수 있는 방법 중 비용이 가장 적은 방식을 선택해야 하므로 아래 순서대로 확인하세요.
접근 방식 1: 실제 브라우저에서 페이지 렌더링
보편적인 해결책은 사용자 브라우저와 똑같이 JavaScript를 실행하는 실제 브라우저 엔진을 구동하는 것입니다. 페이지가 로드되고, 스크립트가 실행되며, API 호출이 발생하고, 콘텐츠가 렌더링된 다음에야 스크래퍼가 완성된 DOM에서 데이터를 추출합니다. 이 방법은 모든 JavaScript 렌더링 사이트에서 작동하지만 비용이 더 큽니다. 페이지마다 브라우저 인스턴스를 실행하므로 실제 메모리와 CPU를 사용합니다. 어떤 브라우저 엔진을 실행할지도 별도의 선택 사항입니다. 라이브러리(Puppeteer, Playwright, Selenium), 클라우드 API, 헤디드와 헤드리스의 장단점이 각각 다릅니다. 전체 선택지는 브라우저 런타임 환경에서 확인할 수 있으며, 스크래핑에서 가장 중요한 헤디드와 헤드리스 브라우저 선택은 헤디드 브라우저와 헤드리스 브라우저에서 다룹니다. 규모가 커지면 런타임 오버헤드가 중요하므로 목적에 맞게 설계된 엔진은 일반 브라우저보다 페이지당 비용이 훨씬 적습니다.접근 방식 2: 기반 API 가로채기
JavaScript 렌더링 페이지가 콘텐츠를 무에서 만들어 내는 것은 아닙니다. XHR 또는fetch 요청을 통해 백엔드 API에서 콘텐츠를 가져옵니다. 이러한 엔드포인트를 찾을 수 있다면 브라우저를 전혀 렌더링하지 않고 직접 호출하여 깔끔한 구조의 JSON을 받을 수 있습니다. 전체 페이지를 렌더링하는 것보다 빠르고 가벼우며 안정적입니다. DOM을 기다릴 필요가 없고, 레이아웃 변경으로 선택자가 깨질 일도 없으며, 데이터가 이미 파싱된 상태로 도착합니다.
다만 이러한 API는 문서화되어 있지 않거나 인증이 필요하고, 속도 제한이 적용되며, 예고 없이 변경될 수 있습니다. 따라서 실제 브라우저에서 DevTools의 Network 패널을 연 채 페이지를 열고 콘텐츠가 로드될 때 발생하는 요청을 관찰한 다음, 원하는 데이터가 응답에 포함된 XHR / fetch 호출을 찾으세요. 호출을 찾으면 브라우저 밖에서 완전히 재현할 수 있는 경우가 많으며, 때로는 단일 curl 명령만으로도 가능합니다.
Octoparse는 이 기능을 시각적 편집기에 직접 통합했습니다. 내장 브라우저에서 DevTools와 같은 네트워크 패널을 제공하며, DOM 요소를 선택하듯 기반 API 응답을 선택할 수 있습니다. 가리키고 클릭하면 작업에서 페이지를 렌더링하는 대신 해당 엔드포인트를 사용합니다. 일반적인 “DevTools 열기, 호출 찾기, 헤더 복사, 요청 다시 만들기” 과정을 하나의 시각적 단계로 줄여 줍니다.
사용할 수만 있다면 이 접근 방식이 JavaScript 렌더링 페이지에 대한 가장 효과적인 해결책이며, 사람들이 생각하는 것보다 훨씬 자주 적용할 수 있습니다. 브라우저를 선택하기 전에 확인할 가치가 있습니다.
접근 방식 3: 서버 측 렌더링 감지
클라이언트 측 프레임워크를 사용하는 일부 사이트는 성능과 SEO를 위해 서버 측 렌더링(SSR)이나 정적 사이트 생성도 구현합니다. 이 경우 최초 HTML 응답에 실제로 전체 콘텐츠가 포함되어 있으므로 가벼운 HTTP 요청만으로 충분할 수 있습니다. 페이지 소스를 확인하세요(Cmd+U / Ctrl+U 사용. 라이브 DOM을 보여 주는 “검사”가 아님). 원시 HTML에 데이터가 이미 들어 있다면 브라우저 오버헤드를 완전히 피할 수 있습니다. 일부 사이트는 더 나아가 User-Agent에 따라 다른 콘텐츠를 제공하며, 예를 들어 검색 엔진 크롤러용 페이지를 미리 렌더링합니다. 요청의 User-Agent를 잘 알려진 검색 봇으로 설정하면 평소에는 JavaScript가 필요한 페이지의 서버 렌더링 버전에 접근할 수 있는 경우도 있습니다. 사이트 약관을 준수해야 한다는 일반적인 주의 사항을 지키면서 작동하는 경우에만 사용하세요.실제 브라우저가 필요할 때의 실용적인 팁
브라우저 렌더링을 사용하게 되면 실패 원인은 대체로 예측할 수 있습니다.- “load”가 아니라 올바른 요소를 기다리세요. 브라우저의 load 이벤트는 HTML과 에셋이 들어오면 발생하지만, 클라이언트에서 렌더링되는 콘텐츠는 아직 도착 중일 수 있습니다. 페이지가 “완료”되기를 기다리지 말고 필요한 특정 선택자나 텍스트가 나타나기를 기다리세요.
- 지연 로딩에 주의하세요. 화면 안으로 스크롤해야만 렌더링되는 콘텐츠는 스크래퍼가 스크롤하기 전까지 존재하지 않습니다. 대부분의 브라우저 자동화 라이브러리는 스크롤을 시뮬레이션할 수 있으며, 핵심은 스크롤이 필요하다는 사실을 파악하는 것입니다.
- 클라이언트 측 라우팅은 기존 스크래퍼에 문제를 일으킵니다. SPA에서는
/products에서/products/42로 이동할 때 새로운 HTTP 요청 없이 URL만 바뀔 수 있습니다.pageload이벤트를 감시하는 로직은 이 전환을 완전히 놓치므로 콘텐츠 변경을 기다려야 합니다. - 무한 스크롤과 “더 보기”에는 관찰이 아니라 상호작용이 필요합니다. 이러한 패턴을 더 자세히 알아보려면 페이지 넘기기 처리를 참조하세요.
가장 비용이 적은 접근 방식부터 시도
신뢰할 수 있는 전략은 다음 순서대로 확인하는 것입니다.- 페이지 소스를 확인합니다. 원시 HTML에 콘텐츠가 있다면 작업은 끝입니다. 단일 HTTP 요청이면 충분합니다.
- 네트워크 호출을 검사합니다. 페이지가 API에서 콘텐츠를 가져온다면 해당 API를 직접 호출하세요. 더 빠르고 가벼우며 안정적입니다.
- 실제 브라우저에서 렌더링합니다. 위 두 방법이 모두 적용되지 않을 때 페이지를 실행하세요. 운영 방식과 대상 사이트의 방어 체계에 맞는 런타임을 선택합니다.