AI 에이전트로 브라우저 자동화하기: Browser Use 설치부터 Cloud까지

Browser Use를 사용하면 애플리케이션 안에서 자동화를 관리하면서 웹사이트 작업을 AI 에이전트에 맡길 수 있습니다. 오픈소스 라이브러리는 Python 3.11 이상이 필요하며, Browser Use Cloud에서는 브라우저만 호스팅하거나 에이전트 전체를 실행할 수 있습니다. 변경 사항을 제출할 권한을 주기 전에, 포털의 기록 조회처럼 결과를 직접 확인할 수 있는 작업부터 시작하는 편이 좋습니다.

2026년 11월 2일 Browser Use GitHub README와 본문에 링크한 공식 문서를 기준으로 확인했습니다. 아래 실행 예시는 해당 문서를 바탕으로 구성했으며, 직접 수행한 성능 테스트는 아닙니다.

Browser Use로 AI 에이전트는 웹에서 무엇을 할 수 있나요?

Browser Use는 언어 모델과 브라우저를 연결합니다. 덕분에 애플리케이션에서 클릭 순서를 하나하나 지정하는 대신 달성할 목표를 전달할 수 있습니다. 공급업체 포털에서 기록을 찾거나, 대시보드를 읽거나, 앞선 답변에 따라 다음 화면이 달라지는 양식을 탐색하는 작업에 적합합니다. 오픈소스 라이브러리가 제공하는 에이전트는 목표를 향해 행동을 선택하고 실행하는 과정을 반복하는 소프트웨어입니다. 라이브러리 README

언어 모델을 운전자, Browser Use를 운전자에게 제어 수단과 피드백을 제공하는 장치, 브라우저를 차량이라고 생각하면 이해하기 쉽습니다. 다만 도로에 해당하는 웹사이트는 여전히 다른 주체가 운영합니다. 운전 실력이 뛰어나도 막힌 길을 열 수는 없고, 배송을 맡았다는 이유로 관계없는 물건을 구매할 권한까지 생기지는 않습니다.

작동 과정은 다음과 같습니다.

1. 관찰: 상호작용할 수 있는 요소를 포함해 현재 페이지의 상태를 수집합니다. Browser Use는 모델에 스크린샷도 제공할 수 있습니다.
2. 판단: 대규모 언어 모델, 즉 LLM이 작업 목표와 현재 상태를 바탕으로 다음 행동을 선택합니다.
3. 실행: 브라우저가 페이지를 이동하거나, 클릭하거나, 텍스트를 입력하는 등 사용 가능한 동작을 수행합니다.
4. 다시 관찰: 바뀐 페이지 상태를 바탕으로 다음 행동을 판단합니다. 에이전트가 멈추거나 설정된 제한에 걸릴 때까지 이 과정을 반복합니다.

페이지 요소를 트리 구조로 표현한 DOM은 에이전트가 조작할 수 있는 컨트롤을 파악하는 데 쓰이고, 스크린샷은 시각적 맥락을 더합니다. Browser Use 문서는 DOM 처리와 비전 기능 설정을 모두 다루므로, 모델이 화면 이미지만 보고 작동한다고 설명하면 정확하지 않습니다. 브라우저 제어 설정, 에이전트 설정

조달 업무 보조 서비스를 만드는 창업자라면 “이 주문의 배송 상태를 찾아라”가 유용한 작업이 될 수 있습니다. 성공 여부는 올바른 주문과 배송 상태를 찾았는지, 이를 뒷받침하는 원본 기록이 있는지로 판단해야 합니다. 에이전트가 그럴듯한 문단을 작성했다고 해서 검증이 끝난 것은 아닙니다.

Browser Use 오픈소스: 설치에 필요한 구성 요소

기본 구성은 browser-use Python 패키지, 제어할 브라우저, 지원 모델에 대한 접근 권한입니다. 라이브러리는 MIT 라이선스로 배포됩니다. README에는 Python 3.11 이상이 필요하다고 명시되어 있고, 빠른 시작 가이드는 Python 3.12를 사용합니다. 자체 프로세스에서 에이전트를 실행하면서 로컬 또는 원격 브라우저를 선택할 수 있습니다. README와 설치 안내

여기서 “로컬”은 프로세스나 브라우저가 실행되는 위치를 뜻합니다. 원격 모델 API를 선택하면 관찰한 정보는 여전히 해당 모델 서비스로 전송됩니다. 브라우저가 로컬에서 실행된다고 시스템 전체가 로컬로 동작하는 것은 아닙니다.

어떤 모델을 연결할 수 있나요?

Browser Use는 여러 제공업체의 어댑터를 지원하므로 자체 모델만 사용할 필요는 없습니다.

• Browser Use BU2: ChatBrowserUse(model="bu-2-0")를 사용하며, 키는 BROWSER_USE_API_KEY로 설정합니다.
• OpenAI 모델: ChatOpenAI를 사용하며, 키는 OPENAI_API_KEY로 설정합니다.
• Anthropic Claude 모델: ChatAnthropic을 사용하며, 키는 ANTHROPIC_API_KEY로 설정합니다.
• Google Gemini 모델: ChatGoogle을 사용하며, 키는 GOOGLE_API_KEY로 설정합니다.
• Ollama를 통한 로컬 모델: ChatOllama로 로컬 모델 서비스에 연결합니다.

지원 모델 문서에는 DeepSeek, Mistral, Microsoft Azure OpenAI, Amazon Web Services Bedrock, OpenRouter 연동도 나와 있습니다. 오래된 예시의 모델 ID를 추천으로 받아들이기보다는 해당 제공업체에서 현재 어떤 모델을 사용할 수 있는지 확인해야 합니다.

어댑터가 있다는 사실이 품질을 보장하지는 않습니다. 같은 문서에서는 일부 Qwen 모델이 잘못된 액션 스키마, 즉 에이전트가 실행할 수 없는 형식의 지시를 생성한다고 경고하며, 현재 해당 연동에는 qwen-vl-max를 권장합니다. 모델에 맡기는 범위를 넓히기 전에 실제 사용할 페이지와 필요한 출력으로 평가해야 합니다.

Browser Use Web UI는 별도 프로젝트입니다

Browser Use Web UI는 에이전트와 상호작용할 수 있는 Gradio 기반 웹 인터페이스를 제공하는 별도 프로젝트입니다. 설치 방법과 의존성도 따로 관리합니다. 애플리케이션에 통합하려면 Python 라이브러리의 최신 문서부터 확인하고, Web UI 저장소의 설치 절차를 호스팅 서비스 SDK와 혼용하지 않아야 합니다.

Browser Use Cloud로 AI 브라우저 운영을 맡기면 무엇이 달라지나요?

Browser Use Cloud에는 브라우저 인프라만 맡기거나, 에이전트 전체를 맡기거나, 둘 다 맡길 수 있습니다. 선택에 따라 직접 운영해야 하는 코드의 범위가 달라집니다. 현재 Cloud 빠른 시작 가이드는 이를 명확하게 구분합니다.

자체 에이전트에서 Browser(use_cloud=True)를 설정하면 Browser Use가 호스팅하는 브라우저를 사용하며, 이때 BROWSER_USE_API_KEY가 필요합니다. 관리형 브라우저는 스텔스 기능, 프록시, 실시간 미리보기를 제공합니다. README에는 CAPTCHA 처리도 설명되어 있지만, 결과는 사이트와 CAPTCHA 유형에 따라 달라진다고 명시합니다. Cloud 브라우저 가이드, README

문서에 나온 인프라 연결 방식은 원격 제어에 CDP, 즉 Chrome DevTools Protocol을 사용합니다. 따라서 브라우저를 호스팅 서비스에 맡겨도 제어 코드는 계속 직접 실행할 수 있습니다.

에이전트 전체를 호스팅 서비스에서 실행할 때 사용하는 패키지는 browser-use가 아니라 **browser-use-sdk**입니다. 현재 Cloud 예시는 API V4와 Python의 from browser_use_sdk.v4 import BrowserUse 구문을 사용합니다. 프로그램은 로컬에서 Agent 루프를 실행하는 대신 작업을 제출하고 결과를 가져옵니다. 호스팅형 에이전트 빠른 시작 가이드

개발자에게는 배포 방식의 선택입니다. 운영자에게 남는 책임은 어느 쪽이든 같습니다. 에이전트가 접근할 수 있는 범위와 작업 완료로 인정할 근거를 정해야 합니다.

웹 자동화에 Browser Use 대신 다른 도구가 더 적합한 경우

직접 관리해야 할 계층이 어디인지부터 정해야 합니다. 작업이 웹사이트 안에서 이루어지고, 모델을 선택할 수 있는 브라우저 에이전트 루프를 패키지로 가져다 쓰고 싶다면 Browser Use가 좋은 출발점입니다. 반면 특정 액션 인터페이스를 중심으로 시스템을 만들거나 웹페이지 밖의 작업까지 처리해야 한다면 컴퓨터 사용 API가 적합합니다.

OpenAI는 OpenAI가 호스팅하는 브라우저를 제공하는 별도의 Agents API도 제공합니다. 따라서 컴퓨터 사용 기능을 쓰려면 언제나 브라우저를 직접 호스팅해야 한다는 기준은 더 이상 적절하지 않습니다. Browserbase 역시 브라우저 인프라 외에 에이전트 제품을 제공합니다.

Browser Use와 Browserbase 중 하나만 선택해야 하는 것도 아닙니다. Browser Use는 cdp_url을 받을 수 있고, Browserbase는 CDP 연결 URL을 제공합니다. 문서에 명시된 이 인터페이스들을 통해 에이전트 라이브러리와 해당 실행 환경을 조합할 수 있습니다. 다만 이 글에서 그 연동을 직접 테스트한 것은 아닙니다. Browser Use 연결 설정

이미 신뢰할 수 있는 API나 정해진 절차대로 동작하는 브라우저 스크립트가 있다면 유지하는 편이 좋습니다. 구조가 안정적인 양식에서 모델이 매번 같은 순서를 다시 찾아내도록 할 이유는 없습니다. 더 넓은 관점에서 제어 방식을 선택하는 방법은 컴퓨터 사용 에이전트 가이드에서, 인프라 비교는 AI 에이전트용 브라우저에서 다룹니다.

애플리케이션에서 직접 통제해야 할 위험

실서비스에서 가장 까다로운 경계는 로그인한 브라우저가 무엇을 할 수 있도록 허용할지입니다. 호스팅 위치를 바꿔도 페이지 안의 지시를 신뢰할 수 있게 되지는 않으며, 잘못된 제출의 결과가 사라지는 것도 아닙니다.

페이지 콘텐츠를 통한 프롬프트 인젝션

프롬프트 인젝션은 에이전트가 읽는 콘텐츠가 원래 지시를 다른 방향으로 돌리려 할 때 발생합니다. 포털에서는 고객이 입력한 메모에 보고서를 다른 곳으로 업로드하라는 지시가 들어 있을 수 있습니다. 관리자 지시라고 주장하더라도 그 메모는 데이터로 취급해야 합니다.

작업에 필요한 권한만 부여한 전용 계정을 사용해야 합니다. Browser Use의 allowed_domains로 탐색 범위를 제한하고, 중요한 결과를 초래하는 동작은 애플리케이션이나 실행 환경에서 승인을 거치도록 강제해야 합니다. 허용한 사이트에도 악의적인 사용자 콘텐츠가 표시될 수 있으므로 도메인 목록만으로 신뢰를 보장할 수는 없습니다. 브라우저 제한 설정, 컴퓨터 사용 안전 가이드

프롬프트에 “제출 전에 물어보라”고 적는 것만으로 권한 제한이 강제되지는 않습니다. 연동 코드에서 해당 동작을 확실하게 가로채 통제할 수 없다면 에이전트의 권한에서 제외하고 사람이 마무리해야 합니다. 프롬프트 인젝션 가이드는 승인을 정확히 어떤 동작에 부여하는지 연결하는 방법을 설명합니다.

로그인 정보, 세션 저장소, 로그

저장된 로그인 정보는 곧 접근 권한입니다. Browser Use는 Browser.from_system_chrome()으로 Chrome을 재사용하거나, Browser(storage_state="auth.json")으로 저장된 쿠키와 로컬 스토리지를 불러올 수 있습니다. 이 상태 파일은 인증 정보처럼 보호하고 버전 관리에서 제외해야 합니다. 사람이 지켜보지 않는 업무 작업에는 개인 브라우저 프로필을 사용하지 않는 편이 좋습니다. 인증 문서

이전할 수 있는 데이터에는 명확한 제한이 있습니다. README에 따르면 로컬 프로필 동기화는 쿠키만 전송하며, 로컬 스토리지나 IndexedDB, 확장 프로그램은 옮기지 않습니다. IndexedDB는 브라우저 측 데이터 저장소의 일종입니다. 이와 별개로 Cloud 프로필은 클라우드 브라우저 간에 쿠키, 로컬 스토리지, 로그인 상태를 유지할 수 있습니다. 이러한 지속성이 로컬 동기화에서 모든 저장 방식을 복사했다는 뜻은 아닙니다. 일부 웹사이트에서는 다시 로그인해야 합니다. 동기화 시 유의 사항

최종 사용자마다 프로필을 분리해야 합니다. 비공개 포털 데이터를 처리하기 전에는 어떤 정보가 모델 입력, 스크린샷, 저장된 대화 기록에 담기는지도 검토해야 합니다. Browser Use는 스크린샷과 대화 저장 설정을 제공하므로 의도에 맞게 구성해야 합니다. 에이전트 설정

요청 제한과 결과가 불확실한 재시도

클라우드 브라우저를 실행할 슬롯이 있다고 대상 사이트에 무제한으로 접근할 수 있는 것은 아닙니다. 모델 서비스의 제한, Browser Use Cloud의 수용량과 요청 제한, 대상 웹사이트 자체의 속도 제한이나 인증 과제를 각각 고려해야 합니다.

대상 사이트별 동시 작업 수를 제한하고, 사이트가 대기를 요구하면 재시도 간격을 늘리며, 차단된 시도가 반복되면 중단해야 합니다. Cloud API 오류가 발생했을 때는 수용량 문제인지 요청 빈도 문제인지 구분하고, 응답에 포함된 재시도 안내를 따라야 합니다. Cloud 제한 사항

특히 클라이언트에서 타임아웃이 발생했다는 이유만으로 같은 내용을 다시 제출해서는 안 됩니다. 먼저 기존 실행과 대상 시스템의 기록을 확인해야 합니다. 작업이 이미 실행된 뒤에도 타임아웃 때문에 결과를 알 수 없는 상태가 될 수 있습니다.

Browser Use 공식 문서로 시작하는 첫 실행

공개 페이지에서 읽기 전용 작업부터 시작합니다. 로그인이나 업무상 거래를 건드리지 않고도 패키지, 브라우저, 모델이 연결되는지 확인할 수 있습니다. 아래 명령은 오픈소스 빠른 시작 가이드를 따릅니다. 예시에는 해당 가이드의 Python 3.12 환경을 사용하고, README에 나온 대로 BU2 모델을 명시적으로 지정합니다.

Browser-Use Python 환경 설정

1. 1

   패키지와 브라우저 설치

   Python과 pip를 사용할 수 있는 macOS 또는 Linux 환경에서 새 프로젝트 디렉터리에 Bash 셸을 엽니다.

   pip install uv
   uv venv --python 3.12
   source .venv/bin/activate
   uv pip install browser-use
   uvx browser-use install

   마지막 명령은 브라우저를 설치합니다. Windows에서는 source 대신 빠른 시작 가이드에 나온 환경 활성화 명령을 사용합니다.

2. 2

   모델 인증 정보 설정

   빠른 시작 가이드에 연결된 대시보드에서 Browser Use API 키를 생성합니다. 같은 Bash 셸에서 키가 화면에 표시되지 않도록 입력합니다.

   read -rsp "Browser Use API key: " BROWSER_USE_API_KEY
   printf '\n'
   export BROWSER_USE_API_KEY

   이 키는 선택한 모델 서비스를 사용할 수 있게 합니다. 키를 설정한다고 브라우저가 자동으로 Cloud로 옮겨지는 것은 아닙니다.

3. 3

   간단한 읽기 전용 작업 실행

   다음 코드를 agent.py로 저장합니다.

   import asyncio
   from browser_use import Agent, ChatBrowserUse
   
   async def main():
       agent = Agent(
           task=(
               "Open https://example.com and report the page heading. "
               "Do not follow links or submit anything."
           ),
           llm=ChatBrowserUse(model="bu-2-0"),
       )
       history = await agent.run()
       print(history.final_result())
   
   if __name__ == "__main__":
       asyncio.run(main())

   이어서 실행합니다.

   python agent.py

   에이전트가 알려 준 제목이 실제 페이지의 제목과 일치하는지 직접 확인해야 합니다. 이처럼 위험이 없는 예시에서는 작업 지시만으로도 시작할 수 있지만, 실서비스의 제한은 프롬프트 바깥에서 강제해야 합니다.

실행에 실패하면 모델부터 바꾸지 말고 오류를 먼저 확인합니다. 브라우저 설치, 모델 인증, 웹사이트 접근은 서로 다른 실패 지점입니다. 정상 작동을 확인한 뒤에는 사용한 의존성 버전을 유지하고, 실제 대상 사이트의 테스트 계정으로 넘어갑니다.

Browser Use에 대한 기대 중 무엇이 과장됐나요?

에이전트 실행이 끝났다고 업무상 거래까지 완료되었다고 볼 수는 없습니다. Browser Use의 출력 문서는 이를 명확하게 구분합니다. is_done()은 에이전트가 완료 동작을 내보냈다는 뜻이고, is_successful()은 에이전트 자체의 평가입니다. 중요한 외부 결과는 여전히 대상 시스템에서 확인해야 합니다. 출력의 의미

주소를 변경했다면 저장된 주소를 확인합니다. 보고서를 다운로드했다면 파일과 보고 대상 기간을 확인합니다. 제출 작업이라면 대상 시스템의 확인 내역을 확보하고, 결과가 불확실할 때는 실제 처리 여부를 확인한 뒤 재시도해야 합니다.

“어떤 웹사이트에서든 작동한다”는 주장에도 같은 신중함이 필요합니다. 관리형 브라우저 기능은 접근 과정의 마찰을 줄일 수 있지만, 프로젝트 README는 모든 CAPTCHA를 피하거나 풀 수 있다고 약속하지 않습니다. 더 뛰어난 모델을 사용해도 사용자에게 없는 계정 권한이 생기지는 않습니다. 사람이 개입해야 하는 지점을 포함해 사이트의 실제 동작에 맞춰 설계해야 합니다.

지금 시작한다면: 좁은 범위의 포털 조회부터

기술 창업자에게 유용한 첫 파일럿은 정답이 명확하고 범위가 좁은 포털 조회 작업입니다. 별도의 테스트 계정을 사용하고, 접근을 허용할 페이지를 정한 뒤, 반환된 기록을 어떻게 검증할지 적어 둡니다. 완료된 실행뿐 아니라 실패도 기록해야 합니다.

실패 원인을 이해한 다음에야 양식 작성 준비로 범위를 넓힙니다. 애플리케이션에서 승인을 강제하고, 저장된 결과를 확인하며, 같은 동작을 중복 실행하지 않고 복구할 수 있을 때까지 제출은 사람이 맡아야 합니다. 지원되는 API나 안정적인 스크립트로 워크플로를 처리할 수 있다면 더 단순한 연동 방식을 유지합니다.

신뢰할 수 있는 AI 워크플로를 구축하는 실용적인 방법은 뉴스레터에서 받아볼 수 있습니다.