browser-use는 최근 2년 사이 가장 화제가 된 브라우저 에이전트 라이브러리 중 하나입니다. 한 문장으로 작업을 맡기면 스스로 브라우저를 열고, 페이지를 읽고, 버튼을 누르고, 양식을 채워 결과를 돌려줍니다. 자동화의 종점처럼 들리지만, 실제로 써 보면 단계마다 요금이 붙는 똑똑한 인턴에 가깝습니다. 일을 하긴 하지만, 함정을 하나씩 다 밟아 봅니다.
공식 저장소 정보
프로젝트는 GitHub에 있으며 조직명은 browser-use, 저장소명도 browser-use, MIT 라이선스, Python으로 작성됐고 스타 수는 10만을 넘었습니다. 밑단에서는 Playwright로 실제 브라우저를 구동하고, 에이전트 루프가 페이지를 이해해 다음 동작을 결정합니다. OpenAI, Anthropic, Google 등 여러 회사의 모델을 연결할 수 있고 로컬 모델도 쓸 수 있습니다. 운영 측은 유료 클라우드 브라우저 서비스도 제공하지만, 이는 이 오픈소스 라이브러리와 별개이며 라이브러리 자체의 자체 호스팅은 무료입니다.
작동 방식이 곧 요금 구조입니다
한 단계는 이렇게 돕니다. 현재 페이지 구조를 텍스트로 만들어 대규모 모델에 건네고, 모델이 어디를 누르고 무엇을 입력할지 판단한 뒤 실행하고, 새 페이지를 봅니다. 몇 개 사이트에서 가격을 비교해 표를 채우는 단순해 보이는 일도 스무에서 서른 단계를 금방 소모합니다. 즉 모델 호출이 스무에서 서른 번입니다. 플래그십 모델에서는 작업 한 번의 요금이 예상보다 한 자릿수 비싸질 수 있고, 저렴한 모델로 바꾸면 판단 실수가 늘어 단계 수가 부풀어 결국 비슷하게 비싸집니다. 절약의 정공법은 실제 작업으로 1회 비용을 재 본 뒤 규모를 정하는 것입니다.
배포 비용: 설치는 쉽고 유지가 어렵습니다
로컬 설치 문턱은 높지 않습니다. Python 환경에 Playwright와 브라우저 본체만 있으면 돌아갑니다. 처음에는 다운로드 용량과 의존성 수고가 중심입니다. 어려운 것은 지속 운영입니다. 서버의 헤드리스 브라우저는 글꼴, 팝업, 시간 초과, 메모리 회수를 처리해야 하고, 사이트 개편 한 번에 어제 되던 작업이 깨질 수 있어, 누군가 계속 보고 고쳐야 합니다. 일회성 스크립트라면 문제없지만, 운영 시스템으로 쓴다면 서비스를 운영하듯 사람을 배치해야 합니다.
네 가지 실제 함정
첫째, 로그인 벽과 인증입니다. 로그인, 문자 인증, 사람 확인이 필요한 사이트에서는 자주 멈춥니다. 내 실제 브라우저의 로그인 상태를 재사용하면 일부는 피할 수 있지만, 계정을 자동화 프로그램에 노출하는 셈이라 위험은 본인 부담입니다. 둘째, 웹페이지의 프롬프트 주입입니다. 페이지의 글자는 모델의 맥락이 되므로, 악의적인 페이지가 잘못된 클릭이나 정보 유출을 유도할 수 있습니다. 결제와 계정 조작 작업은 특히 격리가 필요합니다. 셋째, 성공률의 불안정성입니다. 같은 작업이 오늘 성공하고 내일 실패하는 일이 드물지 않아, 주문이나 신청처럼 되돌릴 수 없는 일을 무인으로 돌리는 데는 맞지 않습니다. 넷째, 속도입니다. 단계마다 모델 응답을 기다리므로 작업 하나에 몇 분은 흔하고, 대량으로 돌리면 시간과 API 요금이 함께 늘어납니다.
어울리는 일은 흐름이 계속 바뀌어 스크립트로 고정할 수 없는 웹 잡무입니다. 경쟁사 점검, 양식 옮기기, 페이지 내용을 구조화 데이터로 만드는 일처럼 옆에서 결과를 확인할 사람이 있는 경우입니다. 흐름이 고정된 일이라면 Playwright 스크립트를 직접 쓰거나 기존 RPA를 쓰는 편이 싸고 안정적입니다.
