--- title: "별이 10만 개인데 아무도 안 쓴다 — browser-use의 신화와 실제" date: 2026-10-10 model: qwen3.6-plus author_type: human category: reviews summary: "browser-use는 브라우저를 AI에게 넘기는 방식의 대표주자다. 펀딩과 스타에 비해 사용자들은 폼 채우기 실패·과금·환불 불응을 기록한다. Playwright와의 역할 분담, 모델 의존성, 게이트웨이 라우팅까지 정리했다." tags: browser-use, 브라우저 에이전트, Playwright, CDP, 자동화, 스크래핑, 사용자 리뷰, 실사용자 리뷰, AI 에이전트 --- ## 별이 10만 개인데 아무도 안 쓴다 — browser-use의 신화와 실제 r/LocalLLaMA의 질문: "browser-use를 프로덕션에서 정말 쓰는 사람 있나?" 본문의 실패 수치: "호스팅 버전으로 간단한 온라인 폼 채우기가 **9단계 연속 실패**, 5분 소요, 진행 0. 반면 Anthropic Computer Use는 같은 작업을 2~3분에 매번 성공." r/AI_Agents의 더 거친 제목: "PSA: Browser-Use는 사기다. 돈 낭비하지 마라." 구독으로 데이터 추출을 샀으나 "모든 작업 실패, 작업당 15분+ $5+, 데이터 0, 환불 불응, 팀 응답 없음." 이 글은 "browser-use가 좋나 나쁘나"가 아니라 **언제 좋고 언제 무너지는가**를 정리한다. --- ### 1. 무엇이 스타를 만드나 browser-use의 아이디어는 단순하다. **스크립트 대신 목표를 준다.** Playwright가 미리 쓴 결정론적 스크립트를 실행한다면, browser-use는 AI에게 "이 폼을 채워 제출하라"고 말하고 탐색을 맡긴다. 강점은 구조적이다. 사이트가 자주 바뀌거나, 예상 밖 상태가 나오거나, 인증·다중 사이트·다중 단계가 얽힌 작업. "개발·유지 시간이 원시 실행 속도보다 중요할 때." --- ### 2. 무엇이 스타를 갉아먹나 **모델 의존성.** 스레드의 첫 반론: "어떤 모델을, 어떤 엔진으로 서빙하나?" browser-use는 하우스 모델이 없다. 약한 모델을 넣으면 약한 에이전트가 된다. Cline·Goose의 규칙이 반복된다. **설치·문서.** "설명대로 로컬 설치도 못 했다. Docker 없이, 문서도 별로 좋지 않다." "기본 URL 열기에서 무한 루프." 프로토타입 시연과 프로덕션 사이의 간극이 기록된다. **비용·속도.** 호스팅 버전 사용자의 "작업당 15분, $5, 데이터 0." 오픈소스를 돌리더라도 모델 비용·재시도 비용은 사용자 몫이다. **응대.** "환불 없음, 팀 응답 없음." 펀딩과 마케팅에 비해 고객 지원이 따라오지 못했다는 인식이 커뮤니티에 남았다. --- ### 3. Playwright와의 관계 — 경쟁이 아니라 층 2026년 비교(AMA 포함)가 합의한 분류. | 사용처 | 선택 | | --- | --- | | 흐름이 미리 정의 가능, 속도·결정론 중요 | Playwright(스크립트) | | 흐름이 개방적, 사이트가 바뀌고 예외가 많음 | browser-use(에이전트) | | 코딩 에이전트가 CDP로 직접 브라우저 코드 작성 | 제3의 경로가 등장 중 | 한마디로 **스크립트는 유지보수, 에이전트는 적응**이다. browser-use의 사용자 기록은 "적응이 필요한가"를 먼저 묻지 않고 쓰면 실패하는 구조를 보여준다. **게이트웨이.** 다단계 브라우저 작업이 시작되자마자 모델 계층이 인프라 문제로 변한다. 십자가 비싼 모델이 모든 단계에 필요한가, 재시도·반복 컨텍스트, 로컬/클라우드 전환, 제공사 하드웨이링 회피. 게이트웨이 라우팅이 도입 배경이다. --- ### 4. 결론 — 별을 읽는 법 browser-use에 대한 사용자 기록은 두 문장으로 정리된다. **스타와 펀딩은 "브라우저를 AI에게"라는 방향의 정당성을 설명한다.** 그 방향 자체는 Playwright 스크립트의 한계를 정확히 겨냥한다. **반면 프로덕션 성공률·응대·비용 통제는 아직 "좋은 모델 + 좁은 작업 범위 + 대안 툴과의 층 분리"라는 조건부다.** Anthropic Computer Use나 스크립트 기반 대안이 더 잘 맞는 작업이 실재한다. browser-use를 쓸 계획이라면: ① 강한 모델, ② 폭넓은 재시도 예산, ③ Playwright 스크립트와의 역할 분담, ④ 호스팅 vs 오픈소스의 비용 비교. 이 네 가지를 먼저 적어 두라. 관련 글: [Playwright MCP 사용자 리뷰](/reviews/2026-10-10-playwright-mcp-user-reviews/) · [OpenHands 사용자 리뷰](/reviews/2026-10-10-openhands-user-reviews/) · [browser-use 에이전트 허브 항목](/agents/browser-use/) --- ### 출처 - 프로덕션 의문: [Does anyone actually use Browser Use in production? (r/LocalLLaMA)](https://www.reddit.com/r/LocalLLaMA/comments/1kivcl0/) - 과금·응대 불만: [PSA: Browser-Use is a Scam (r/AI_Agents, 2025-07)](https://www.reddit.com/r/AI_Agents/comments/1lvebvp/) - 기본 작업 실패: [browser-use sucks (r/AI_Agents, 2025-01)](https://www.reddit.com/r/AI_Agents/comments/1hzt9tt/) - Playwright 비교: [Browser Use vs Playwright in 2026 (r/WebScrapingInsider)](https://www.reddit.com/r/WebScrapingInsider/comments/1vhrp89/) - 게이트웨이 논의: [using browser-use with an LLM gateway (r/AI_Agents, 2026-06)](https://www.reddit.com/r/AI_Agents/comments/1tz60tj/)