JavaScript가 많은 사이트에 관한 대부분의 조언은 첫 번째 판단에서 멈춘다. 이 페이지에 정말 브라우저가 필요한가? 이 질문은 중요하며, 스크래핑에 헤드리스 브라우저가 실제로 필요한 시점에서 자세히 다루었다. “JavaScript 사이트”라고 여겨지는 것들 중 상당수는 실제로는 필요하지 않은 것으로 드러난다.
이 가이드는 그 글이 끝난 지점에서 시작한다. 대상 사이트가 진짜로 렌더링을 필요로 한다고 확인했다고 가정하자. 이제 첫 번째 판단보다 비용과 당직 부담에 훨씬 더 큰 영향을 미치는 두 번째 판단이 남는다. 브라우저를 직접 운영할 것인가, 아니면 대신 브라우저를 실행해 주는 웹 스크래핑 API에 페이지를 보낼 것인가.
먼저, 페이지에 정말 렌더링이 필요한지 확인하라
어느 쪽이든 결정을 내리기 전에 빠르게 확인해 볼 사항이 있다. 렌더링은 항상 더 느리고 무거운 선택이기 때문이다.
원본과 렌더링된 페이지를 비교하라. 원시 HTML 응답을 열어 보라. 원하는 데이터가 그 안에 있다면 브라우저는 필요 없다.
내장된 상태 데이터를 확인하라. 많은 JavaScript 프레임워크는 초기 페이지 데이터를 script 태그 안에 JSON 형태로 담아 전송하며, 이를 통해 브라우저가 추가 요청 없이 페이지를 하이드레이션할 수 있게 한다. 원하는 데이터가 그 JSON 안에 있다면, 일반 HTTP 요청과 JSON 파싱만으로 충분하다.
네트워크 요청을 관찰하라. 페이지가 로드 후 JSON 엔드포인트에서 데이터를 가져온다면, 그 엔드포인트를 직접 요청하는 편이 페이지 전체를 렌더링하는 것보다 대개 더 저렴하다.
세 가지 방법 모두로도 데이터를 얻지 못하거나, 엔드포인트가 서명되어 있거나 불투명하거나 재현할 수 없는 방식으로 보호되어 있다면 렌더링이 필요하다. 계속 읽어 보라.
직접 브라우저를 운영한다는 것이 실제로 의미하는 것
노트북에서 헤드리스 브라우저 하나를 돌리는 것은 쉽다. 그러나 프로덕션에서 이를 여러 대 운영하는 것은 운영상의 문제이며, 프로토타입 단계에서는 드러나지 않기 때문에 비용을 과소평가하기 쉽다.
용량. 브라우저 인스턴스 하나하나가 메모리를 많이 소모하므로, 한 대의 머신에서 실행할 수 있는 수가 제한되고 동시성이 곧 인프라 비용으로 이어진다.
안정성. 브라우저는 적대적인 페이지에서 멈추거나, 메모리를 누수하거나, 충돌한다. 프로덕션 환경의 브라우저 집합에는 워치독, 재활용 메커니즘, 그리고 워커가 페이지 처리 도중 죽어도 견디는 큐가 필요하다.
유지 보수. 브라우저 버전, 자동화 라이브러리, 자동화 핑거프린트는 모두 계속 변화한다. 지난 분기까지 잘 작동하던 브라우저 집합이 코드 한 줄 바꾸지 않았는데도 실패하기 시작할 수 있다.
프록시. 렌더링된 트래픽에도 여전히 좋은 IP가 필요하며, 인증과 컨텍스트별 격리를 갖춰 브라우저에 올바르게 연결해야 한다. 이를 제대로 하는 것은 그 자체로 하나의 작업이다. Playwright에서 레지덴셜 프록시 사용하기를 참고하라.
차단과 챌린지. CAPTCHA와 안티봇 검사는 탐지, 처리, 재시도가 필요하며, 실패한 시도라 해도 그동안 소모한 브라우저 시간은 이미 써버린 것이다.
재시도와 대기. 동적 페이지가 언제 로딩을 마쳤는지, 그리고 아직 마치지 않았을 때 무엇을 해야 하는지는 사이트마다 직접 작성하고 유지해야 하는 로직이다.
이 중 어느 것도 특별히 이례적인 것은 아니다. 다만 아무도 고객에게 청구하지 않는 작업일 뿐이며, 새로운 대상이 추가될 때마다 늘어난다.
웹 스크래핑 API가 대신 처리해 주는 것
웹 스크래핑 API는 이 목록을 요청 파라미터로 바꾸어 준다. Shifter Web Scraping API의 경우:
- 렌더링.
render_js=1은 헤드리스 Chrome에서 페이지를 실행하며, 정적 요청과 동일하게 크레딧 1개로 과금된다. - 대기.
wait_for_css는 특정 선택자가 나타날 때까지 캡처를 보류하며,timeout은 페이지당 브라우저 시간의 상한을 지정한다. - 상호작용.
js_instructions는 캡처 전에scrollTo,click,wait단계를 연쇄적으로 실행하며, 쿠키 배너, 더 보기 버튼, 스크롤로 트리거되는 콘텐츠를 처리할 수 있다. - 구조화된 출력.
extract_rules는 CSS 선택자로부터 JSON을 반환하므로 파서를 따로 배포할 필요가 없다. - 재시도. 실패한 요청, CAPTCHA, 대상 사이트의 일시적 오류는 최대 3회까지 다른 프록시로 자동 재시도된다.
- 챌린지. 스텔스 모드가 기본으로 켜져 있으며, reCAPTCHA와 hCaptcha는 렌더링 요청 중에 실시간으로 처리된다.
- IP. Growth 플랜 이상은 글로벌 위치 지정이 가능한 레지덴셜 및 모바일 풀을 경유한다. Starter는 미국과 EU의 데이터센터 IP를 사용하며, 보호되지 않은 페이지 다수에는 이것으로 충분하다.
- 세션.
session_id는 다단계 흐름 전반에 걸쳐 쿠키, 브라우저 상태, 상류 IP를 유지하며, 10분간 유휴 상태이면 만료된다. - 과금. 성공한 응답당 크레딧 1개. 실패한 요청, 대상 사이트 오류, API 자체의 재시도는 과금되지 않는다.
동시성은 플랜별로 상한이 있으며, Starter는 20, Enterprise는 500이다. 상한을 초과하는 요청은 429를 반환한다. 전체 파라미터 레퍼런스는 JavaScript 렌더링에서 시작한다.
여전히 직접 브라우저를 운영하는 것이 맞는 경우
API가 언제나 답은 아니며, 어디서 그렇지 않은지 분명히 짚어 둘 필요가 있다.
긴 상호작용 세션. 브라우저가 오랫동안 사이트에 머물러야 하고, 세션의 유휴 시간 한도보다 긴 일시 정지가 필요한 흐름은 직접 운영하는 브라우저에 더 적합하다.
임의의 브라우저 로직. 페이지에 스크롤, 클릭, 대기를 넘어서는 커스텀 스크립트, 확장 기능, 상호작용이 필요하다면 직접 제어하는 브라우저가 더 유연하다.
자체 인프라가 요구 사항인 경우. 일부 작업은 계약상 또는 보안상의 이유로 특정 네트워크나 환경 안에서 실행되어야 한다.
매우 크고 매우 안정적인 물량. 좀처럼 변하지 않는 대상에 대해 충분히 큰 규모라면, 이를 운영할 엔지니어를 이미 보유하고 있다는 전제 하에 자체 인프라가 페이지당 비용을 더 낮출 수 있다.
테스트와 디버깅. 시각적 회귀 테스트, 단계별 디버깅, 사람이 직접 브라우저를 지켜봐야 하는 작업은 자체 머신에서 해야 한다.
대상별 판단표
선택은 회사 단위가 아니라 대상 단위로 내려야 한다. 성숙한 스크래핑 스택 대부분은 세 가지 경로를 모두 사용한다.
| 대상의 특징 | 최선의 경로 |
|---|---|
| 원시 HTML이나 내장 JSON에 데이터가 있음 | 일반 HTTP 요청 |
| 재현 가능한 JSON 엔드포인트에서 나오는 데이터 | 해당 엔드포인트로 일반 HTTP 요청 |
| 렌더링된 콘텐츠, 보호되지 않음, 저물량 | 둘 다 가능; API가 작업량이 적음 |
| 안티봇 검사 뒤의 렌더링된 콘텐츠 | 웹 스크래핑 API |
| 여러 시장에 걸친 렌더링된 콘텐츠 | 요청별 국가 지정이 가능한 웹 스크래핑 API |
| 장기 인증 세션 또는 커스텀 브라우저 로직 | 레지덴셜 프록시를 사용하는 자체 브라우저 |
| 사내 팀이 있는 거대하고 안정적인 물량 | 자체 브라우저, 총비용 기준으로 평가 |
사용 가능한 페이지당 비용으로 비교하라
이 판단에서 흔히 저지르는 실수는 API의 요청당 가격과 서버 비용을 비교하여 서버가 더 저렴하다고 결론짓는 것이다.
공정한 비교는 사용 가능한 페이지당 비용이다. 자체 브라우저 집합의 경우, 여기에는 유휴 상태이거나 충돌하는 브라우저의 컴퓨팅 비용, 실패한 시도에 소모된 프록시 대역폭, 그리고 유지 보수, 재시도, 챌린지 처리에 들인 엔지니어링 시간이 포함되며, 이를 실제로 올바른 데이터를 산출한 페이지 수로 나눈 값이다. 성공한 응답에 대해서만 과금하는 API의 경우, 실패는 과금되지 않으므로 크레딧당 가격이 실제 사용 가능한 페이지당 비용에 훨씬 더 가깝다. 다만 선택자가 바뀌어 빈 필드를 반환하는 것처럼 성공했지만 쓸모없는 페이지에 대한 비용은 여전히 지불하게 된다.
동일한 실제 대상 URL 샘플을 일주일 동안 양쪽 경로로 실행해 보고, 올바르고 완전한 데이터를 반환한 페이지 수를 세어 두 방식의 사용 가능한 페이지당 비용을 비교하라. 이 숫자가 어떤 기능 목록보다 빠르게 논쟁을 정리해 준다. API 요금제는 가격 페이지에 있다.
두 방식이 만나는 지점
이 선택은 한 사이트 안에서도 이분법적이지 않다. 흔하고 합리적인 패턴은, 렌더링이 필요 없는 페이지는 일반 HTTP로 처리하고, 렌더링이 필요하거나 보호된 페이지는 API로 보내며, 커스텀 로직이 필요한 소수의 흐름을 위해 소규모 브라우저 설정을 별도로 유지하는 것이다.
무한 스크롤과 더 보기 형태의 피드는 바로 이 경계에 걸쳐 있으며, 렌더링 안에서 이를 처리하는 기법은 무한 스크롤과 동적 페이지네이션 처리 방법에서 다룬다. API가 이 모든 것을 하나의 요청 뒤에서 어떻게 조합하는지는 웹 스크래핑 API는 어떻게 작동하는가에서 설명한다.
FAQ
API에서 렌더링은 더 비싼가?
지연 시간 면에서는 그렇다. 브라우저는 일반 요청보다 시간이 더 걸리기 때문이다. 크레딧 면에서는 아니다. 렌더링된 요청은 정적 요청과 동일하게 크레딧 1개로 과금된다.
API가 모든 안티봇 시스템을 처리할 수 있는가?
모든 경우, 항상 그런 것은 아니다. 대부분의 검사는 처리되며, 지속적으로 차단하는 대상은 지원팀이 조정할 수 있는 대상이다. 이에 의존하기 전에 실제 대상에서 자신의 성공률을 측정해 보라.
API를 사용하면 프록시가 여전히 필요한가?
별도의 프록시 설정은 필요 없다. API는 자체 풀을 통해 요청을 라우팅하며, Growth 플랜 이상에서는 레지덴셜 및 모바일 풀을 사용한다.
언제 API에서 자체 브라우저로 옮겨야 하는가?
API가 제공하지 않는 브라우저 동작이 필요할 때, 또는 실제 물량 기준으로 측정한 사용 가능한 페이지당 비용 비교가 이를 운영할 엔지니어링을 포함해 자체 인프라 쪽에 유리할 때다.
결론
사이트에 JavaScript 렌더링이 필요하다고 판단하는 것은 쉬운 절반이다. 어려운 절반은 누가 브라우저를 운영할지 결정하는 것이다. 자체 브라우저 집합은 유연성을 얻는 대신 용량, 안정성, 유지 보수, 프록시, 챌린지 처리에 비용을 치른다. API는 그 유연성을 파라미터, 재시도, 성공 시에만 과금되는 방식과 맞바꾼다.
페이지에 정말 렌더링이 필요한지 확인하고, 회사 단위가 아니라 대상 단위로 선택하며, 직접 구축할지 구매할지는 측정된 사용 가능한 페이지당 비용으로 결론지어라. 해당 제품은 Web Scraping API 페이지에 있다.