BrowserAct의 stealth browser는 Playwright의 기본 headless 실행을 봇으로 감지한 봇 탐지 체크를 통과했습니다. 두 스크립트 모두 동일한 로그인 흐름을 완료했음에도 불구하고 말이죠. 이러한 대조는 자동화 방지 조치가 되어 있는 사이트와 상호작용해야 할 때 왜 에이전트 기반(agent-based) 접근 방식이 더 안전할 수 있는지를 보여줍니다.

이 테스트가 중요한 이유

자동화 도구는 테스트, 데이터 수집 및 계정 관리를 가능하게 합니다. 대부분의 개발자는 Playwright와 같은 셀렉터 기반(selector-driven) 프레임워크를 선호하는데, 이는 "이 CSS 셀렉터를 가진 버튼을 클릭하라"와 같이 정밀한 명령을 작성하고 결과를 빠르게 확인할 수 있기 때문입니다. 하지만 현대의 사이트들은 headless browser를 탐지하는 스크립트를 내장하고 있습니다. 일반적인 user-agent 문자열, webdriver 속성, 또는 인간과 유사한 상호작용 패턴의 부재 등이 그 예입니다. 이러한 신호가 포착되면 사이트는 요청을 차단하거나 CAPTCHA를 띄워 스크립트의 기능을 사실상 무력화합니다.

에이전트 브라우저는 미리 작성된 셀렉터에 의존하지 않고 인간 사용자를 모방하려고 시도합니다. 이들은 페이지를 실행 가능한 요소들의 집합으로 취급하며, CSS 경로 대신 내부 인덱스의 위치를 기준으로 요소를 선택합니다. 이번 테스트에서는 JavaScript로 렌더링되는 로그인 페이지와 의도적으로 봇을 체크하는 사이트에서 두 가지 접근 방식을 비교했습니다.

실험 내용

저는 동일한 단계를 수행하는 두 개의 스크립트를 작성했습니다: 로그인 페이지 로드, 자격 증명 입력, 제출, 그리고 인벤토리 페이지 도달. 한 스크립트는 Playwright를 기본 headless 모드로 사용했고, 다른 하나는 봇 탐지를 유발하는 핑거프린트를 숨겨주는 BrowserAct의 stealth browser를 사용했습니다.

두 스크립트 모두 샌드박스 사이트에서 인증에 성공하여, 도구와 관계없이 핵심 로그인 흐름이 작동함을 증명했습니다. 차이점은 스크립트가 JSON 플래그 isBot을 반환하는 전용 봇 탐지 페이지를 방문했을 때 나타났습니다. Playwright는 isBot: true를 보고하며 5개의 개별 탐지 체크에 걸렸습니다. 반면 BrowserAct는 isBot: false를 반환하여, 페이지가 이를 일반적인 인간 방문자로 취급했음을 보여주었습니다.

저는 그 차이의 원인을 두 가지 기술적 세부 사항에서 찾아냈습니다. Playwright의 기본 설정은 일반적인 user-agent 문자열을 전송하고 webdriver 플래그를 노출하는데, 이는 탐지 스크립트가 찾아내기 매우 쉽습니다. BrowserAct의 stealth 모드는 user-agent를 재작성하고, webdriver 속성을 제거하며, 핑거프린트를 일반적인 데스크톱 브라우저와 일치시킵니다.

내부 작동 방식의 차이점

항목 Playwright (기본값) BrowserAct (stealth)
상호작용 모델 셀렉터 기반, 결정론적(deterministic) 에이전트 기반, 인덱스 기반
사전 작성된 셀렉터 필요 여부 필수; 스크립트가 정확한 DOM 구조를 알아야 함 불필요; 에이전트가 런타임에 실행 가능한 요소를 발견함
레이아웃 변경 대응 셀렉터가 변경되면 작동 중단 요소 위치가 인덱스 목록 내에 유지되는 한 계속 작동
봇 탐지 노출 정도 user-agent 및 webdriver가 그대로 노출됨 핑거프린트가 의도적으로 마스킹됨
일반적인 사용 사례 내부 사이트, 안정적인 UI, 빠른 테스트 사이클 자동화 방지 조치가 있는 공개 사이트, 끊임없이 변하는 페이지

이 표는 실질적인 트레이드오프(trade-offs)를 보여줍니다. Playwright는 사이트를 직접 제어할 수 있고 안정적인 요소 식별자를 보장할 수 있을 때 빛을 발합니다. 에이전트 브라우저는 페이지 구조를 예측할 수 없거나 사이트가 스크립트를 적극적으로 차단하려 할 때 유용합니다.

수혜자와 위험군

자신의 애플리케이션을 위한 회귀 테스트(regression suites)를 구축하는 개발자는 Playwright를 계속 사용함으로써 비용을 낮게 유지하고 테스트 속도를 높일 수 있습니다. Playwright의 결정론적인 특성은 실패 원인을 코드 회귀로 직접 지목하며, 추가적인 stealth 레이어가 필요 없어 복잡성이 줄어듭니다.

반대로, 데이터를 스크래핑하거나, 계정 생성을 자동화하거나, 경쟁사 사이트를 모니터링하는 팀은 대상 페이지가 빈번하게 변경되거나 공격적인 봇 탐지 기능이 포함되어 있어 종종 난관에 부딪힙니다. 이러한 시나리오에서 에이전트 브라우저는 즉각적인 "당신은 봇입니다"라는 막다른 길을 피하고 필요한 데이터에 계속 접근할 수 있게 해줍니다.

"작동했다"는 결과 뒤에 숨겨진 비용

저는 성공적인 종료 코드(exit code)가 자동화가 의도한 대로 동작했음을 보장하지 않는다는 점을 경고하고자 합니다. Playwright 실행 시 스크립트는 에러 없이 종료되었지만, 페이지는 여전히 해당 요청을 봇으로 간주했습니다. 그 결과는 '숨겨진 실패'였습니다. 인간에게만 제공되는 콘텐츠에 의존하는 후속 단계들이 예상했던 데이터를 전혀 받지 못하게 된 것입니다.

이러한 침묵의 실패(silent failures)를 찾아내려면, 매 실행 후 스크롤 위치, 문서 높이, 네트워크 호출과 같은 페이지 증거를 검사하십시오. DOM이 사람이 보는 것과 다르게 보이거나, 네트워크 트래픽에 인증 챌린지로의 예기치 않은 리다이렉트가 포함되어 있다면 자동화가 목표를 달성하지 못했을 가능성이 높습니다.

결론

사이트를 직접 소유하고 있고 안정적인 셀렉터를 사용하여 스크립트를 작성할 수 있다면, Playwright가 여전히 실용적인 선택입니다. 빠르고 저렴하며 CI 파이프라인에 통합하기 쉽기 때문입니다. 반면, 알 수 없는 레이아웃, 공격적인 자동화 방지 방어 기제, 또는 빈번한 UI 변경에 직면했다면 BrowserAct와 같은 에이전트 브라우저가 더 탄력적인 대안을 제공합니다. 실행 결과가 성공했다고 해서 맹목적으로 믿지 마십시오. 페이지가 사람처럼 동작했는지 확인하고, 대상 사이트의 리스크 프로필에 맞는 도구를 선택하십시오.