팀들이 실제로 대규모로 실행할 첫 번째 브라우저 에이전트 (browser-agent) 워크플로우는 데모보다 훨씬 작습니다

브라우저 에이전트 (browser-agent) 데모가 신뢰성 문제를 가지고 있다는 것을 저는 처음으로 누군가가 "업무를 변화시키고 있다"라고 설명하는 동안, 에이전트가 대시보드를 클릭하며 4분 동안 시간을 보내는 것을 보았을 때 깨달았습니다.

그것이 인상적인 것인지 아니면 고장 난 것인지 아무도 알 수 없었습니다.

그것이 바로 문제입니다.

팀들이 실제로 처음 배포할 브라우저 에이전트 (browser-agent) 워크플로우는 거대한 자율적 직원 (autonomous-employee)에 대한 환상이 아닙니다. 그것들은 아주 작고, 지루하며, 확인 가능한 잡무들입니다.

다음과 같은 것들을 생각해 보세요:

McDonald’s 영수증의 QR 코드를 스캔합니다.
설문조사를 엽니다.
양식을 작성합니다.
Telegram으로 쿠폰 코드를 반환합니다.

이것이 진짜 데모입니다.

쿠폰 코드가 존재하거나 존재하지 않거나 둘 중 하나입니다.

개발자들에게는 긴 추론 과정 (reasoning trace)보다 이것이 더 중요합니다.

그리고 일단 그것을 깨닫고 나면, 두 번째 사실이 빠르게 분명해집니다. 사람들이 실제로 프로덕션 (production) 환경에서 실행하는 첫 번째 브라우저 에이전트 (browser-agent)들은 토큰 기반 과금 (token-metered pricing)을 즉시 짜증 나게 만드는 것들이기도 하다는 점입니다.

내가 본 최고의 브라우저 에이전트 데모는 무료 버거입니다

OpenClaw 토론을 살펴보던 중, r/openclaw에서 누군가가 자신의 가장 시각적으로 인상적인 라이브 데모를 설명한 스레드를 발견했습니다:

"내 Claw로 했던 것 중 시각적으로 가장 인상적이었던 것은 무엇일까요? McDonald’s 영수증 뒷면에 있는 QR 코드를 스캔하게 해서 설문조사를 작성하고 무료 버거를 받게 하는 것이었습니다."

그것은 시중에 떠도는 대부분의 "AI 직원 (AI employee)" 관련 내용보다 훨씬 더 나은 데모입니다.

왜일까요?

그것은 브라우저 에이전트 (browser-agent) 데모에 필요한 3가지 속성을 갖추고 있기 때문입니다:

작업이 제한적입니다 (bounded).
결과가 즉시 확인 가능합니다 (instantly checkable).
실패 모드 (failure mode)가 명확합니다.

만약 에이전트가 양식에서 막히면, 모두가 그것을 보게 됩니다.

만약 성공하면, 모두가 그것을 알게 됩니다.

벤치마크 차트 (benchmark chart)는 필요 없습니다.

같은 스레드의 다른 댓글 작성자는 기본적으로 더 넓은 교훈을 얻었습니다:

"재미있는 사례네요. 대부분의 게으른 구경꾼들에게는 이것이 '와우'를 만들어낼 것입니다. 관점을 넓혀보면, 어떤 QR 코드 가입/할인 코드 프로세스에 대해서도 데모를 할 수 있습니다. 이것을 'QR 지니 (QR Genie)'라고 부르면 군중은 열광할 것입니다."

이것은 사실 패스트푸드에 관한 것이 아닙니다.

검증하기 쉬운 브라우저 작업을 선택하는 것에 관한 것입니다.

'와우' 모먼트는 추론 과정 (reasoning trace)이 아닙니다

많은 AI 데모들은 여전히 숨겨진 사고 과정 (hidden thinking)이 인상적인 부분이라고 가정합니다.

브라우저 자동화 (browser automation)의 경우, 이는 정반대입니다.

브라우저는 잔인할 정도로 정직합니다.

OpenClaw가 잘못된 버튼을 클릭하면, 당신은 그것을 보게 됩니다.
OpenAI Operator가 CAPTCHA에 걸리면, 당신은 그것을 보게 됩니다.
Selector (선택자)가 변경되어 Browser-use 워크플로우가 루프에 빠지면, 당신은 그것을 보게 됩니다.

이것이 바로 아주 작은 브라우저 잡무들이 거대하고 모호한 워크플로우보다 훨씬 더 강력하게 다가오는 이유입니다.

청중은 자신의 눈으로 직접 결과물을 검증할 수 있습니다.

또한 이것이 바로 작은 데모들이 팀들이 운영화 (operationalize)할 수 있을 만큼 신뢰를 얻는 첫 번째 대상이 되는 이유이기도 합니다.

OpenAI는 이미 우리에게 이 사실을 말해주었습니다

OpenAI가 2025년 1월 23일에 Operator를 출시했을 때, 그들은 "운영 팀을 대체하십시오"라는 말로 시작하지 않았습니다.

예시는 다음과 같았습니다:

양식 작성하기 (filling out forms)
식료품 주문하기 (ordering groceries)
밈 (memes) 만들기

그리고 OpenAI는 사용자가 어느 시점에서든 개입할 수 있다는 점을 강조했습니다.

이는 매우 강력한 신호입니다.

만약 OpenAI가 완전한 자율성 (total-autonomy)이라는 환상을 팔고 싶었다면, 그럴 기회는 얼마든지 있었습니다. 대신 그들은 Operator를 감독 하에 있는 브라우저 보조 도구 (supervised browser assistance)로 프레임화했습니다.

나중에 2025년 7월 17일, OpenAI는 해당 게시물을 업데이트하여 Operator가 에이전트 모드 (agent mode)로서 ChatGPT에 통합되고 있다고 밝혔습니다. 사실상 같은 메시지입니다: 먼저 유용한 브라우저 비서가 되고, 나중에 마법 같은 로봇 직원이 된다는 것입니다.

벤치마크 수치들도 같은 방향을 가리킵니다:

OSWorld에서 38.1%
WebArena에서 58.1%
WebVoyager에서 87%

흥미롭습니까? 네.

하지만 이것이 회사 전체를 자율 브라우저 에이전트 (autonomous browser agents)에게 넘겨도 된다는 초록불일까요? 전혀 아닙니다.

Anthropic은 대부분의 벤더보다 더 정직했습니다

Anthropic의 2024년 10월 computer-use 발표에서는 이 기능을 실험적 (experimental)이라고 불렀으며, 번거롭고 오류가 발생하기 쉬울 수 있다고 언급했습니다.

좋습니다. 더 많은 기업이 그렇게 말해야 합니다.

왜냐하면 브라우저 자동화는 텍스트 전용 에이전트 (text-only agents)가 그렇지 않은 방식으로 매우 복잡하기 때문입니다.

그럼에도 불구하고, 역량의 한계 (capability ceiling)는 실재합니다. Anthropic은 Asana, Canva, DoorDash, Replit, 그리고 The Browser Company와 같은 파트너들을 언급했습니다. 또한 다음과 같은 성과를 보고했습니다:

SWE-bench Verified: 33.4% -> 49.0%
TAU-bench retail: 62.6% -> 69.2%
TAU-bench airline: 36.0% -> 46.0%

따라서 그렇습니다, 이러한 시스템들은 쿠폰 교환 이상의 일을 할 수 있습니다.

하지만 작은 데모들이 중요한 이유는 현재 무엇이 작동하는지에 대해 정직하기 때문입니다.

OpenClaw의 문제는 능력이 아닙니다. 가독성(legibility)입니다.

저는 OpenClaw를 매우 좋아합니다.

아이디어는 강력합니다: WhatsApp, Telegram, Slack, Discord, Signal, iMessage 및 기타 채널에서 거주할 수 있으며, 상태 유지 세션(stateful sessions), 메모리, 도구(tools), 그리고 모델 불가지론적 라우팅(model-agnostic routing)을 갖춘 로컬 우선 제어 평면(local-first control plane)입니다.

그것은 강력합니다.

또한 매우 방대합니다.

또 다른 r/openclaw 스레드에서 한 사용자는 이 제품이 너무 개방적이기 때문에 축복이자 저주라고 묘사했습니다.

그 말이 맞는 것 같습니다.

백지 상태의 제품(Blank-canvas products)은 숙련된 빌더들에게는 강력하지만, 그 외의 모든 이들에게는 혼란스럽습니다.

개발자들에게는 단순히 능력만 필요한 것이 아닙니다. 그들에게는 첫 번째 승리(first win)가 필요합니다.

그리고 브라우저 에이전트(browser agents)의 경우, 가장 좋은 첫 번째 승리는 부정할 수 없는 결과를 내는 아주 작은 자동화입니다.

OpenClaw의 문제 해결(troubleshooting) 흐름조차 이것이 진지한 소프트웨어임을 말해줍니다:

openclaw status
openclaw status --all
openclaw gateway probe
...

그것은 괜찮습니다. 진지한 시스템에는 실제 진단 기능이 필요합니다.

하지만 이는 또한 스타터 워크플로우(starter workflows)가 매우 중요하다는 것을 의미합니다.

아주 작은 브라우저 잡무를 위한 최적의 스택은 무엇인가?

만약 당신의 목표가 믿을 만한 브라우저 에이전트 워크플로우라면, 저는 현재의 옵션들을 다음과 같이 나눌 것입니다:

도구	가장 뛰어난 점
OpenClaw	Telegram, Slack 또는 Discord에서의 진행 상황 업데이트가 경험의 일부가 되는 채팅 네이티브(chat-native) 데모에 최적
...

그 차이는 중요합니다.

만약 에이전트가 진행 상황을 설명하고 쿠폰 코드를 반환하는 라이브 Telegram 기반 데모를 원한다면, OpenClaw는 매우 가독성이 좋습니다.

만약 원격 브라우저 상호작용(remote browser interaction)에 대해 가장 잘 알려진 참조점을 원한다면, Operator가 여전히 명백한 비교 대상입니다.

만약 반복 가능한 프로그래밍 방식의 브라우저 작업(repeatable programmatic browser tasks)을 구축하고 싶다면, Browser-use가 현재 가장 실용적인 시작점입니다.

Browser-use는 올바른 분위기를 가지고 있습니다: 마법은 덜하고, 처리량(throughput)은 더 높게

제가 Browser-use에서 좋게 생각하는 점은, 이것이 지능을 과시하는 연극(intelligence theater)을 하는 것이 아니라 작업을 완료하려고 노력한다는 것입니다.

이 도구의 포지셔닝은 기본적으로 다음과 같습니다: 브라우저 작업, 속도, 지속성, 그리고 낮은 비용.

이것이 개발자들에게 적합한 태도입니다.

최소한의 예시는 매우 직관적입니다:

from browser_use import Agent, ChatBrowserUse
from dotenv import load_dotenv
import asyncio
...

그리고 SDK를 사용하면 다음과 같습니다:

from browser_use_sdk.v3 import AsyncBrowserUse
import asyncio

...

설치 과정 또한 간단합니다:

pip install browser-use browser-use-sdk python-dotenv
export BROWSER_USE_API_KEY=your_key

이것이 제가 브라우저 자동화 도구에 기대하는 에너지입니다.

"보라, AGI(인공 일반 지능)다"가 아니라,

그저 "여기 작업이 있고, 여기 API가 있으니, 시작하자"라는 식 말이죠.

실질적인 규칙: 확실한 증거가 있는 데모 작업

브라우저 에이전트(browser-agent) 워크플로우를 구축하고 있다면, 제가 발견한 가장 단순한 휴리스틱(heuristic)은 다음과 같습니다:

성공했을 때 결과물(artifact)이 생성되는 작업을 선택하세요.

좋은 예시:

쿠폰 코드
확인 페이지
예약 참조 번호(booking reference)
제출된 리베이트 ID
가시적인 성공 상태가 보이는 완료된 회원가입

나쁜 예시:

"내 워크플로우 관리하기"
"이 사이트 조사하기"
"고객 운영 업무 처리하기"
"이 비즈니스 프로세스를 처음부터 끝까지 실행하기"

이러한 더 큰 작업들은 결국 실현될 수도 있지만, 청중이 빠르게 검증할 수 없기 때문에 데모로서의 힘이 약합니다.

개발자(DEV) 독자분들을 위해 저는 이렇게 정의하고 싶습니다:

만약 성공 여부를 기계가 확인하거나 사람이 5초 이내에 확인할 수 없다면,
그것은 아마도 좋지 않은 첫 번째 브라우저 에이전트 워크플로우일 것입니다.

아주 작은 잡무는 결코 작지 않습니다. 그것은 쐐기(wedge)입니다.

당연한 반론은 쿠폰 흐름이나 리베이트 양식 같은 것들이 이 시스템이 궁극적으로 할 수 있는 일을 과소평가한다는 점일 것입니다.

맞는 말입니다.

하지만 신뢰도는 복리로 쌓입니다.

다음과 같은 워크플로우는:

QR 코드 읽기
사이트 열기
양식 채우기
마찰(friction) 극복하기
사용 가능한 결과물 반환

사용자에게 즉각적으로 세 가지 중요한 사실을 가르쳐 줍니다:

에이전트가 실제 세계의 입력을 처리할 수 있음
에이전트가 지저분한 브라우저 상태(browser state)를 헤쳐나갈 수 있음
에이전트가 지금 당장 유용한 무언가를 반환할 수 있음

사람들이 이 세 가지를 믿게 되면

만약 제가 오늘 소규모 브라우저 에이전트 (browser-agent) 워크플로우를 구축한다면, 스택을 다음과 같이 계층별로 구성할 것입니다:

계층 (Layer)	권장 방식
브라우저 에이전트 런타임 (Browser agent runtime)	SDK 우선의 반복 가능한 자동화를 위한 Browser-use, 또는 채팅 기반 오케스트레이션 (chat-native orchestration)이 제품의 일부라면 OpenClaw
...

이러한 조합은 대부분의 AI 데모가 갖지 못한 것을 제공합니다:

믿을 수 있는 워크플로우 (workflow)
프로그래밍 가능한 인터페이스 (programmable interface)
프로덕션 (production)으로 가는 경로
재시도 (retries) 시에도 이상해지지 않는 비용 모델 (cost model)

엔지니어들에게 실제로 보여줄 데모

목표가 개발자들의 관심을 끄는 것이라면, 저는 가장 거대한 워크플로우를 데모하지 않을 것입니다.

대신, 가장 부정할 수 없는 워크플로우를 데모할 것입니다.

저의 후보 목록은 다음과 같습니다:

쿠폰 코드를 반환하는 영수증 QR 설문조사
이메일 또는 SMS를 통한 프로모션 코드 사용
이미지 업로드를 포함한 간단한 리베이트 신청
성공 페이지가 명확히 보이는 예약 확인
완료 상태가 분명한 계정 가입 플로우

이 모든 것들은 동일한 장점을 가지고 있습니다:

청중이 당신의 설명을 믿을 필요가 없다는 것입니다.

그들은 스스로 결과를 확인할 수 있습니다.

이것이 브라우저 에이전트 시장이 계속해서 다시 배우고 있는 교훈입니다.

최고의 데모는 가장 어려워 보이는 것이 아닙니다.

반론의 여지가 가장 적은 것입니다.

Telegram에서 제공하는 무료 버거 쿠폰이 자율적 작업 (autonomous work)에 대한 10분짜리 연설보다 훨씬 강력합니다.

그리고 이를 깨닫고 나면, 나머지 시장의 움직임도 더 잘 이해됩니다:

OpenAI Operator의 사례가 이해됩니다.
Anthropic의 신중함이 이해됩니다.
OpenClaw가 더 명확한 스타터 워크플로우를 필요로 하는 것이 이해됩니다.
Browser-use가 프로덕션 (production)에 집중하는 것이 이해됩니다.

팀들이 실제로 대규모로 실행할 첫 번째 브라우저 에이전트 (browser-agent) 워크플로우는 원대한 목표 (moonshot)가 아닙니다.

그것은 단순한 잡무 (chore)입니다.

그리고 바로 그 점 때문에 효과가 있는 것입니다.

이러한 워크플로우를 구축하고 있다면

제 조언은 간단합니다:

범위가 제한된 브라우저 작업 (bounded browser task)으로 시작하세요.
성공을 명확하게 만드세요.
재시도 (retries) 로직을 조기에 계측 (instrument) 하세요.
셀렉터 (selectors)는 깨질 것이라고 가정하세요.
비용 모델 (cost model)을 수정하는 것을 너무 오래 미루지 마세요.

만약 여러분의 에이전트가 이미 OpenAI 호환 클라이언트 (OpenAI-compatible client)를 사용하고 있다면, 사용량이 많아지기 시작할 때 Standard Compute를 테스트해보는 것이 당연한 선택입니다. 토큰당 과금 (per-token billing) 방식보다는 월정액 요금제 (Flat monthly pricing)가 상시 가동되는 브라우저 자동화 (browser automation)에 훨씬 더 적합합니다.

이것은 기술 스택 (stack)에서 화려한 부분은 아닙니다.

하지만 데모 이후에도 워크플로우 (workflow)를 계속 실행할 수 있게 해주는 부분입니다.