Skip to main content
브라우저 자동화 관련 글은 대부분 한 번에 하나의 도구를 설명합니다. 그러나 더 유용한 질문은 전체 생태계가 어떤 모습인지, 런타임에는 어떤 종류가 있고 각각 어떤 작업에 적합한지, 스크래핑용 런타임을 선택할 때 실제로 중요한 기준이 무엇인지입니다. 가장 결정적인 기준은 언어나 브라우저 엔진이 아니라 런타임이 기본적으로 헤드리스로 실행되는지, 아니면 헤디드 방식으로 설계되었는지입니다. 생태계의 거의 모든 도구는 헤드리스 쪽에 있고, Octoparse가 대표하는 통합 스크래핑 플랫폼은 헤디드 쪽에 있습니다. 런타임이 어느 쪽에 속하는지 알면 사양표보다 실제 사이트에서 어떻게 작동할지 더 잘 이해할 수 있습니다.

한눈에 보기

굵게 표시된 행은 스크래핑 전용 런타임을 갖춘 헤디드 중심 설계의 Octoparse입니다. ParseHub도 헤디드 범주에 속하지만 Octoparse가 더 널리 도입된 대표 사례입니다.

오픈 소스 자동화 라이브러리

대부분의 코드 기반 스크래핑은 여기서 시작합니다. Puppeteer는 Node에서 Chromium을 구동하며 빠르고 현대적이지만 Chrome만 지원합니다. Puppeteer의 후속 도구로 자주 소개되는 Playwright는 Node, Python, Java, .NET에서 Chromium, Firefox, WebKit을 지원합니다. 현재 새 프로젝트를 시작한다면 Chrome만 필요한 특별한 이유가 없는 한 대체로 더 나은 기본 선택입니다. Selenium은 오래된 강자입니다. 더 느리고 무겁지만 WebDriver 프로토콜을 통해 거의 모든 브라우저와 통신하며, Safari, 구형 Edge 또는 모바일 브라우저 바인딩이 필요한 프로젝트에서는 여전히 중요합니다. 이 세 도구 밖에서는 언어와 생태계에 따라 선택지가 나뉩니다. Splash는 Lua로 스크립팅하며 Scrapy 파이프라인 안에 들어가는 JS 렌더링 서비스입니다. WebdriverIO는 테스트 러너와 유사한 방식으로 WebDriver/CDP 기반 API를 Node 중심 프로젝트에 제공합니다. Go에서는 chromedpRod가 실용적인 선택지이며, 편의성 때문에 Rod를 선호하는 경우가 많습니다. Pyppeteer는 Python을 벗어나지 않으면서 Puppeteer 방식의 API를 원하는 팀을 위한 Python 포트입니다. HtmlUnit은 Chromium 바이너리를 사용하지 않는 순수 Java 브라우저 구현체라는 점에서 특이하며, JS 엔진 충실도보다 JVM 생태계가 중요할 때 유용합니다. 이 도구들은 모두 기본적으로 헤드리스로 실행됩니다. 헤디드로도 실행할 수 있지만 디스플레이 또는 Xvfb 같은 가상 디스플레이가 필요하고 공개된 대부분의 스크립트는 이를 사용하지 않습니다. 일반적인 작동 방식은 화면에 표시하지 않는 것입니다.

스텔스 및 탐지 방지 변형

대상 사이트가 런타임을 핑거프린팅하면 일반 Puppeteer나 Selenium은 navigator.webdriver, 누락된 플러그인, 헤드리스 Chrome User-Agent, 캔버스/WebGL 이상 징후 때문에 빠르게 탐지됩니다. 스텔스 변형은 이러한 유출을 패치합니다. puppeteer-extra-stealth는 가장 잘 알려진 도구로, 일반적인 헤드리스 핑거프린트를 회피하는 기능 묶음을 제공하는 Puppeteer 플러그인입니다. undetected-chromedriver는 Selenium 기반 Chrome에서 같은 역할을 하며 Python 안티봇 분야에서 널리 쓰입니다. nodriver는 같은 개발자가 만든 최신 드라이버리스 CDP 접근 방식으로, 네트워크 계층부터 자연스러운 브라우저 세션처럼 보이도록 설계되었습니다. Patchright는 Playwright를 이미 사용하는 팀을 위해 유사한 스텔스 패치를 기본 포함한 Playwright 포크입니다. 이 도구들은 헤드리스/헤디드 작동 방식을 바꾸지 않으며 여전히 기본적으로 헤드리스입니다. 헤드리스와 “실제” 브라우저 사이의 간극을 줄이지만, 지속적으로 업데이트되는 탐지 계층에 맞서 방어하는 방식입니다.

클라우드 브라우저 API

브라우저를 직접 호스팅하는 대신 HTTP 엔드포인트를 호출하여 렌더링된 페이지나 제어 가능한 세션을 받습니다. Browserless는 가장 확립된 서비스로, 관리형 클라우드 또는 자체 호스팅 방식으로 사용할 수 있으며 Puppeteer/Playwright의 드롭인 엔드포인트 역할을 합니다. BrowserbaseSteel.dev는 AI 에이전트를 지향하는 최신 서비스이며 Steel은 OSS 친화적입니다. Bright Data Scraping BrowserZyte API는 브라우저 실행에 안티봇 처리와 차단 해제 인프라를 결합합니다. 비용은 더 들지만 어려운 대상에서 성공률이 높습니다. ScrapingBeeScrapingAnt는 소규모 팀을 위한 간단한 “이 URL 렌더링” API입니다. Apify는 자체 플랫폼으로, Browser Actors가 클라우드 호스팅 Chromium과 Apify의 큐 및 스토리지를 결합합니다. 이 서비스는 모두 디스플레이가 연결되지 않은 서버에서 브라우저를 실행합니다. 이 범주에서는 헤드리스만이 경제적으로 타당한 모드입니다. 사용자는 브라우저가 무엇을 하는지 볼 수 없고 반환 결과만 확인할 수 있습니다.

통합 스크래핑 플랫폼

이 범주는 위의 모든 도구와 구조적으로 다릅니다. 코드에서 호출하는 라이브러리나 URL을 POST하는 API 대신, 브라우저가 내장된 시각적 워크플로 편집기를 제공합니다. 선택자를 작성하지 않고 페이지를 클릭하여 스크래퍼를 구축합니다. Octoparse가 가장 대표적인 예입니다. 두 개의 런타임을 실행합니다. 일상적인 작업에는 불필요한 기능을 제거하고 최적화한 Electron Chromium을 사용하고, 완전히 실제와 같은 브라우저가 필요한 사이트에는 Puppeteer로 구동하는 Chrome for Testing을 사용합니다. 중요한 점은 둘 다 헤디드 중심으로 설계되었다는 것입니다. 보이는 페이지 자체가 편집기이므로 브라우저 창이 표시됩니다. ParseHub도 유사한 방식으로 같은 범주에 속합니다. Web Scraper.io Chrome 확장 프로그램 같은 오래된 도구도 헤디드 계보를 공유합니다. 브라우저 확장 프로그램은 헤디드 Chrome 창 안에서만 작동할 수 있기 때문입니다. 헤디드가 설정 옵션이 아니라 기본값인 유일한 범주입니다. 이는 제약이 아니라 워크플로가 의존하는 설계 선택입니다.

헤드리스와 헤디드: 중요한 기준

헤드리스와 헤디드의 구분은 런타임 운영자가 누구인지와 연결됩니다. 개발자가 운영할 때는 헤드리스가 적합합니다. 코드를 작성하고 로그를 읽으며 디스플레이가 없는 서버로 확장합니다. 페이지를 프로그래밍 방식으로 설명하므로 볼 필요가 없습니다. 통합 플랫폼 위에 나열된 전체 생태계는 이 가정을 바탕으로 합니다. 페이지 자체가 인터페이스일 때는 헤디드가 적합합니다. 요소를 시각적으로 선택하고, 작업 실행을 지켜보고, 로그인이나 CAPTCHA에 개입하며, 로그 대신 화면을 보면서 디버깅합니다. 이것이 Octoparse의 방식이며 불필요한 기능을 제거한 Electron 런타임이 존재하는 이유이기도 합니다. 일반 탐색이 아닌 스크래핑용으로 제작된 기반 브라우저라면 헤디드가 반드시 무거운 것은 아닙니다. 여기서 두 가지 실용적인 결과가 나옵니다.
  • 봇 탐지. 보이는 창, 실제 렌더링, 실제 입력 이벤트를 갖춘 진짜 헤디드 브라우저는 안티봇 서비스가 찾는 신호를 더 적게 노출합니다. 헤드리스 도구는 스텔스 계층을 추가해야 하지만 헤디드 중심 플랫폼은 이러한 장점을 대부분 기본으로 얻습니다.
  • 운영자 역량. 헤드리스 도구는 스크립트, 프록시, CAPTCHA 해결 도구, 배포를 유지관리하는 엔지니어가 있다고 가정합니다. 헤디드 중심 플랫폼은 분석가, 운영, 성장 담당자처럼 데이터에 가까운 사람이 운영하고 플랫폼이 엔지니어링을 담당한다고 가정합니다.
헤디드 중심 설계가 기능 누락이 아니라 의도적인 선택인 이유를 자세히 알아보려면 헤디드 브라우저와 헤드리스 브라우저를 참조하세요.

선택 방법

대부분의 프로젝트에 적용되는 몇 가지 선택 기준은 다음과 같습니다.
  • 코드로 직접 스크래퍼를 작성하고 페이지 렌더링만 필요한가요? Playwright가 기본 선택입니다. Chrome만 필요하고 이미 Node를 사용한다면 Puppeteer를 선택하세요. 두 도구가 지원하지 않는 브라우저가 필요할 때만 Selenium을 선택하세요.
  • 코드 기반 스크래퍼인데 대상 사이트의 핑거프린팅이 강력한가요? 스텔스 변형(puppeteer-extra-stealth, undetected-chromedriver, nodriver)으로 전환하거나 안티봇 처리가 포함된 클라우드 API를 사용하세요.
  • 브라우저를 전혀 호스팅하고 싶지 않은가요? 일반 렌더링에는 Browserless / Browserbase / Steel, 차단 해제 기능까지 필요하면 Zyte API / Bright Data Scraping Browser 같은 클라우드 API를 선택하세요.
  • 코드를 전혀 작성하고 싶지 않은가요? 통합 플랫폼인 Octoparse(또는 ParseHub)를 선택하세요. 헤디드 중심 설계, 시각적 선택, 워크플로와 클라우드 추출이 결합된 런타임을 제공합니다.
  • 운영자가 엔지니어가 아니고 대상 사이트에 안티봇 방어가 있나요? 헤디드 중심 설계가 가장 유리한 경우입니다. 노출되는 탐지 신호가 적고 CAPTCHA가 나타나면 사람이 개입할 수 있습니다.
런타임 결정이 영구적인 경우는 드뭅니다. 많은 팀이 일회성 렌더링을 위해 클라우드 API로 시작하고, 반복 작업을 위해 스텔스 기능을 갖춘 코드 라이브러리로 옮긴 뒤, 엔지니어가 아닌 사람이 운영해야 할 때 통합 플랫폼을 선택합니다.