Browserbase와 Stagehand: AI 에이전트 브라우저 자동화가 깨지는 지점부터 보자

AI 에이전트가 웹에서 버튼을 누르고, 로그인하고, 데이터를 뽑아야 한다면 단순한 API 호출만으로는 금방 한계가 옵니다. 문제는 “브라우저를 열 수 있느냐”가 아니라, 셀렉터 변경, CAPTCHA, 세션 끊김, 원격 실행 환경까지 버티며 계속 돌아가느냐입니다.

이 지점에서 Browserbase와 Stagehand가 의미를 가집니다. Browserbase는 AI 에이전트에게 원격 브라우저 세션을 제공하는 플랫폼이고, Stagehand는 그 브라우저를 자연어와 코드가 섞인 방식으로 조작하게 해주는 SDK입니다. 다만 모든 스크래핑과 자동화에 무조건 Browserbase를 붙여야 한다는 뜻은 아닙니다. 제대로 쓰려면 먼저 “이 작업에 정말 브라우저가 필요한가”를 분리해야 합니다.

 

원격 브라우저 세션 안에서 AI 에이전트가 웹 페이지를 조작하고, 깨지는 셀렉터 대신 구조화된 데이터가 나오는 모습을 표현한 이미지

 

먼저 결론부터: Browserbase는 스크래퍼가 아니라 실행 환경에 가깝다

Browserbase를 단순히 “AI 웹 스크래핑 도구”라고 보면 절반만 이해한 것입니다. 핵심은 스크래핑보다 넓습니다. 에이전트가 실제 브라우저 안에서 페이지를 열고, 클릭하고, 입력하고, 로그인 상태를 유지하고, 결과를 구조화해서 가져오는 실행 환경에 가깝습니다.

공식 문서 기준으로도 Browserbase는 원격 브라우저 세션, MCP 연동, Stagehand SDK, identity 계층을 함께 다루는 플랫폼에 가깝습니다. Stagehand는 그 위에서 act, extract, observe, agent 같은 단위를 통해 자연어 기반 브라우저 자동화를 구성합니다. 기본 개념은 Browserbase 공식 소개와 Stagehand 공식 문서에서 현재 용어를 확인할 수 있습니다.

실전에서는 이렇게 나누는 편이 좋습니다.

 

상황	더 자연스러운 선택
정적 HTML이나 API 응답만 읽으면 된다	직접 HTTP 요청 + 파서
DOM 구조가 안정적이고 반복 테스트가 목적이다	Playwright 또는 Selenium
버튼 클릭, 로그인, 검색, 동적 UI, 추출이 섞인다	Stagehand
원격 서버, 다중 세션, 리플레이, CAPTCHA/인증 마찰까지 고려해야 한다	Browserbase + Stagehand

 

즉 Browserbase는 “셀렉터 몇 개를 더 쉽게 찾는 도구”가 아닙니다. 브라우저 자동화를 운영 가능한 단위로 만들기 위한 인프라에 가깝습니다.

 

브라우저 자동화 작업을 직접 요청, Playwright/Selenium, Stagehand, Browserbase 중 어디로 나눌지 보여주는 선택 흐름도

 

 

왜 기존 Playwright/Selenium 자동화는 운영에서 빨리 깨질까

Playwright와 Selenium이 나쁘다는 뜻은 아닙니다. 안정적인 테스트 자동화, 명확한 DOM, 예측 가능한 버튼과 입력창이 있는 환경에서는 여전히 강력합니다. 문제는 실제 웹 자동화 대상이 그렇게 얌전하지 않다는 데 있습니다.

처음에는 간단합니다.

await page.click("button[type=submit]")
await page.fill("#search", "keyword")

 

그런데 운영에 들어가면 이런 일이 생깁니다.

• 버튼 클래스가 빌드마다 바뀝니다.
• React 컴포넌트 구조가 바뀌면서 CSS selector가 깨집니다.
• aria-label은 있지만 지역, 언어, 로그인 상태에 따라 값이 달라집니다.
• 가격, 기간, 댓글 수처럼 추출한 값은 정규표현식으로 다시 정리해야 합니다.
• 어느 날부터 CAPTCHA가 뜨고, 어느 날부터 IP가 막힙니다.
• 로컬에서는 되는데 VPS나 컨테이너에서는 브라우저 실행부터 귀찮아집니다.

 

여기서 진짜 비용은 코드 줄 수가 아닙니다. 실패했을 때 “왜 실패했는지”를 추적하는 비용입니다. 클릭이 안 된 것인지, 요소가 늦게 뜬 것인지, 로그인 상태가 풀린 것인지, 차단 페이지로 간 것인지, 모델이 잘못 판단한 것인지가 로그만 보고는 잘 안 보입니다.

Browserbase의 장점은 이 실패를 관찰 가능한 사건으로 바꿔준다는 데 있습니다. 세션을 실시간으로 보고, 실행 기록을 리플레이하고, 네트워크와 페이지 이동을 따라가면서 자동화가 어디서 틀어졌는지 확인할 수 있습니다.

 

 

MCP로 붙일 때와 SDK로 직접 짤 때는 목적이 다르다

Browserbase를 쓰는 첫 번째 방법은 MCP 서버를 통해 Claude Code 같은 MCP 클라이언트에 브라우저를 붙이는 것입니다. 공식 Browserbase MCP 문서는 MCP 클라이언트가 Stagehand 기반 브라우저를 자연어 명령으로 조작할 수 있다고 설명합니다.

이 방식은 빠르게 능력을 붙일 때 좋습니다.

• Claude Code에서 웹 페이지를 직접 열어보게 하고 싶다.
• 로컬 브라우저가 없는 원격 환경에서 에이전트가 웹을 조작해야 한다.
• 일회성 조사, 검색, 클릭, 추출 작업을 에이전트에게 맡기고 싶다.
• 자동화 과정을 사람이 live view로 확인하고 싶다.

 

예를 들어 에이전트에게 “YouTube에서 특정 채널을 검색하고 최신 영상을 찾아줘”라고 시키면, Browserbase가 원격 브라우저 세션을 만들고 에이전트가 실제 페이지를 탐색합니다. 사용자는 그 과정을 실시간으로 보거나 끝난 뒤 리플레이로 확인할 수 있습니다.

반면 SDK 방식은 목적이 다릅니다. 제품 기능, 정기 작업, 데이터 파이프라인, 반복 가능한 스크립트라면 MCP보다 Stagehand SDK로 명확히 짜는 편이 낫습니다.

MCP는 “에이전트에게 브라우저 능력을 주는 방법”에 가깝고, SDK는 “브라우저 자동화를 내 코드의 일부로 만드는 방법”에 가깝습니다. 이 차이를 놓치면 실험용 흐름을 그대로 운영 자동화로 밀어 넣게 됩니다.

Claude Code와 MCP 설정 흐름 자체가 처음이라면 Claude Code 잘 쓰는 법: 2026년 생산성 높이는 설정, 플러그인, MCP 서버 가이드가 먼저 도움이 됩니다. Browserbase가 아니더라도 MCP로 외부 도구를 붙이는 감각은 비슷합니다.

비슷한 문제를 다른 스택으로 풀어보는 관점이 필요하다면 실시간 웹 데이터를 자동으로 가져오는 AI 웹봇 만들기도 같이 볼 만합니다. Browserbase와 Bright Data는 세부 접근이 다르지만, “에이전트가 웹을 직접 다루게 한다”는 문제의식은 이어집니다.

 

 

Stagehand는 자연어만 쓰는 도구가 아니다

Stagehand를 처음 보면 “그냥 자연어로 브라우저 조작하는 도구 아닌가?”라고 생각하기 쉽습니다. 하지만 실제 강점은 자연어와 코드의 경계를 사용자가 정할 수 있다는 점입니다.

공식 Stagehand 문서 기준 핵심 단위는 크게 네 가지입니다.

 

단위	역할	실전에서 쓰는 순간
act	페이지에서 특정 행동 수행	“검색창에 입력”, “로그인 버튼 클릭”
extract	구조화된 데이터 추출	“상위 5개 글의 제목, 점수, 작성자 추출”
observe	현재 페이지에서 가능한 액션 탐색	“1위 글의 댓글 링크가 어디인지 찾기”
agent	여러 단계의 작업을 자율적으로 수행	“Google Flights에서 조건 입력 후 결과까지 도달”

 

여기서 중요한 것은 전부 AI에게 맡기지 않는다는 점입니다. 예를 들어 Hacker News에서 상위 글을 가져오는 작업이라면 흐름을 이렇게 나눌 수 있습니다.

1. 코드로 대상 페이지에 이동합니다.
2. extract로 상위 5개 글을 정해진 스키마에 맞춰 뽑습니다.
3. observe로 1위 글의 댓글 링크를 찾습니다.
4. act로 그 링크를 클릭합니다.
5. 다시 extract로 최상단 댓글을 가져옵니다.

 

이 구조는 단순한 “AI에게 알아서 해줘”보다 훨씬 낫습니다. 모델이 판단해야 할 부분과 코드가 보장해야 할 부분이 나뉘기 때문입니다. 데이터 형식도 스키마로 묶으면 나중에 result.data처럼 다루기 쉬워집니다.

 

 

Google Flights 같은 페이지에서 차이가 크게 난다

Browserbase와 Stagehand가 특히 빛나는 곳은 Google Flights처럼 UI 흐름이 복잡한 페이지입니다. 출발지, 도착지, 왕복 여부, 출발일, 귀국일, 검색 버튼, 결과 로딩, 항공편 목록 추출이 모두 이어져야 합니다.

이걸 Playwright로 직접 짜면 일반적으로 아래 작업이 따라옵니다.

• 입력창의 정확한 role이나 label 찾기
• 날짜 선택기의 DOM 구조 추적
• 월 이동 버튼 처리
• 결과 로딩 대기
• 가격, 경유, 소요 시간 문자열 파싱
• 페이지 구조 변경에 대한 예외 처리

 

반면 Stagehand의 agent 방식은 “샌프란시스코에서 두바이까지 왕복 항공권을 이 날짜 조건으로 검색하고, 결과가 뜨면 멈춘 뒤 상위 3개 항공편을 추출하라”처럼 작업 목표를 주고, 마지막에 extract로 필요한 필드만 구조화할 수 있습니다.

여기서 판단 기준은 간단합니다. 클릭할 요소가 몇 개 없고 DOM이 안정적이면 셀렉터 방식이 더 빠릅니다. 하지만 날짜 선택, 조건 입력, 검색 결과 대기, 결과 추출처럼 사람의 브라우저 조작 흐름을 그대로 따라가야 한다면 agent 방식이 유지보수 비용을 줄일 가능성이 큽니다.

물론 이 방식도 마법은 아닙니다. 오래 걸릴 수 있고, 모델 비용이 들 수 있고, 잘못된 행동을 막기 위한 시스템 프롬프트와 step 제한이 필요합니다. 그래도 복잡한 UI에서 사람이 계속 셀렉터를 고치는 비용과 비교하면, 훨씬 현실적인 선택이 되는 순간이 있습니다.

 

 

Agent Identity는 “무조건 차단 우회”가 아니다

Browserbase를 소개할 때 가장 조심해야 할 부분이 Agent Identity와 CAPTCHA입니다. 흔히 “이걸 쓰면 차단을 뚫는다”처럼 말하기 쉬운데, 그렇게 이해하면 위험합니다.

Browserbase의 Agent Auth & Identity 문서는 자동화 브라우저가 합법적인 작업을 수행하더라도 봇 보호 시스템에 막히는 문제를 다룹니다. 핵심은 몰래 숨는 것이 아니라, 참여 provider와의 협력, Verified browser, Web Bot Auth, CAPTCHA 처리, credential/auth 관리 같은 계층을 통해 더 신뢰 가능한 자동화 환경을 만드는 쪽입니다.

실전에서는 이렇게 봐야 합니다.

• 사이트 약관과 정책은 여전히 확인해야 합니다.
• 로그인 정보와 2FA는 안전하게 관리해야 합니다.
• 참여 사이트와 플랜에 따라 쓸 수 있는 identity 기능이 다를 수 있습니다.
• CAPTCHA 자동 처리는 실패할 수 있고, 비표준 CAPTCHA에는 추가 설정이 필요할 수 있습니다.
• 대량 수집은 robots.txt, 서비스 약관, 법적 리스크를 함께 봐야 합니다.

 

즉 Agent Identity는 “우회 버튼”이 아니라 “정상적인 자동화가 불필요하게 막히지 않도록 신뢰를 제공하는 계층”에 가깝습니다.

 

 

언제 Browserbase를 쓰고, 언제 쓰지 말아야 할까

Browserbase를 도입할지 판단할 때는 기능 목록보다 실패 비용을 먼저 봐야 합니다.

Browserbase가 맞는 경우는 이런 쪽입니다.

• 에이전트가 실제 웹페이지를 클릭하고 입력해야 한다.
• 로그인 세션, 쿠키, 인증 상태 유지가 중요하다.
• 원격 서버나 컨테이너에서 브라우저를 안정적으로 돌려야 한다.
• 자동화가 실패했을 때 리플레이와 live view로 원인을 봐야 한다.
• 여러 브라우저 세션을 동시에 띄워야 한다.
• Playwright/Selenium 셀렉터 유지보수 비용이 이미 커졌다.
• AI 에이전트가 웹에서 직접 행동해야 하는 제품 기능을 만들고 있다.

 

반대로 굳이 쓰지 않아도 되는 경우도 분명합니다.

• 필요한 데이터가 이미 공개 API로 제공된다.
• HTML 응답 안에 데이터가 있고, 직접 요청이 안정적이다.
• 하루 한두 번 돌리는 개인용 스크립트다.
• 페이지 구조가 거의 바뀌지 않는다.
• 브라우저를 열 필요 없이 RSS, sitemap, JSON, CSV만 읽으면 된다.

 

웹 스크래핑을 더 큰 운영 시스템으로 봐야 하는 이유는 아마존 가격 스크레이핑 시스템 구축 방법에서도 같은 결로 설명할 수 있습니다. 한 번 가져오는 것보다 다음 주에도 믿을 수 있게 가져오는 것이 더 어렵습니다. Browserbase는 그중에서도 “브라우저가 꼭 필요한 구간”의 운영 부담을 줄이는 선택지입니다.

 

 

실제 도입 순서는 작게 시작하는 편이 낫다

처음부터 모든 자동화를 Browserbase로 옮길 필요는 없습니다. 가장 자주 깨지는 흐름 하나를 골라서 검증하는 편이 좋습니다.

추천 순서는 이렇습니다.

1. 직접 HTTP 요청으로 가능한 부분을 먼저 분리합니다.
2. 반드시 브라우저 조작이 필요한 페이지를 하나 고릅니다.
3. MCP로 에이전트가 실제로 그 흐름을 처리할 수 있는지 빠르게 확인합니다.
4. 반복 작업으로 가치가 있으면 Stagehand SDK로 옮깁니다.
5. extract 결과는 처음부터 스키마로 고정합니다.
6. 실패 시 리플레이를 보고 프롬프트, step 제한, fallback을 조정합니다.
7. 비용과 속도를 본 뒤 병렬 세션이나 캐싱을 검토합니다.

 

여기서 중요한 습관은 “AI가 알아서 잘하겠지”가 아니라 “AI가 판단할 범위를 좁히는 것”입니다. 추출 형식은 스키마로 제한하고, 이동 범위는 시스템 프롬프트로 제한하고, 위험한 클릭은 명시적으로 막아야 합니다.

 

 

비용보다 먼저 봐야 할 것은 디버깅 시간이다

Browserbase는 무료로 시작할 수 있지만, 사용량이 커지면 세션 시간, 브라우저 실행, 모델 호출, 프록시, identity 기능 같은 요소가 비용으로 이어질 수 있습니다. 현재 조건은 Browserbase 가격 페이지에서 직접 확인하는 것이 안전합니다.

다만 비용 판단을 브라우저 분당 가격만으로 하면 놓치는 게 많습니다. 실제 비교 대상은 다음입니다.

• Playwright 셀렉터를 고치느라 쓰는 개발 시간
• 실패 원인을 재현하느라 쓰는 디버깅 시간
• 차단, CAPTCHA, 세션 문제로 누락되는 데이터 비용
• 원격 브라우저 인프라를 직접 운영하는 비용
• 자동화가 실패했는데 성공처럼 보이는 데이터 품질 리스크

 

작은 개인 스크립트라면 Browserbase가 과할 수 있습니다. 하지만 에이전트가 실제 웹 업무를 반복해서 수행해야 하는 제품이라면, 브라우저 인프라와 관측성을 사는 편이 더 싸게 먹힐 수 있습니다.

 

 

마무리: 지금 깨지는 흐름 하나로 판단하자

Browserbase와 Stagehand를 도입할지 고민된다면 기능 목록부터 비교하지 않는 편이 낫습니다. 지금 가진 자동화 중 가장 자주 깨지는 흐름 하나를 고르세요. 그 흐름이 정적 데이터 수집이면 직접 요청과 파서가 낫고, 안정적인 UI 테스트라면 Playwright와 Selenium이 여전히 좋습니다.

하지만 로그인, 동적 UI, 클릭 흐름, 복잡한 추출, 원격 실행, 세션 리플레이, 다중 브라우저가 한꺼번에 필요해지는 순간에는 Browserbase와 Stagehand가 훨씬 설득력 있는 선택이 됩니다.

가장 좋은 도입법은 거창하지 않습니다. MCP로 가능성을 확인한 뒤, 반복 가치가 있으면 SDK로 제품화하는 것입니다. 이 순서만 지켜도 “AI가 웹을 알아서 돌아다닌다”는 막연한 기대보다 훨씬 실용적인 자동화에 가까워집니다.

 

 

FAQ

 

Browserbase를 쓰면 Playwright를 더 이상 안 써도 되나요?

아닙니다. Playwright는 여전히 안정적인 UI 테스트와 명확한 브라우저 제어에 좋습니다. Browserbase와 Stagehand는 동적 페이지, 원격 세션, AI 기반 추출, 리플레이 디버깅이 필요한 흐름에서 더 강합니다.

 

Browserbase는 웹사이트 차단을 모두 해결해 주나요?

아닙니다. Agent Identity와 CAPTCHA 처리 기능이 있지만, 사이트 정책과 약관을 지켜야 하고 기능 사용 가능 범위도 플랜과 대상 사이트에 따라 달라질 수 있습니다. “차단 우회”가 아니라 “신뢰 가능한 자동화 세션”으로 이해하는 편이 안전합니다.