안녕하세요 개발자 여러분 👋

지난 몇 달 동안 AI 에이전트 (AI agents)는 매우 빠르게 진화해 왔습니다. 우리는 더 이상 질문에 답하는 단순한 챗봇 (chatbots)을 만드는 데 그치지 않습니다. 오늘날의 에이전트는 웹사이트를 브라우징하고, 워크플로우 (workflows)를 실행하며, 대시보드 (dashboards)를 모니터링하고, SaaS 플랫폼과 상호작용하며, 이전에는 수동 작업이 필요했던 작업들을 수행합니다.

최근 BrowserAct가 Product Hunt에서 1위를 차지했으며, 이는 즉시 제 관심을 끌었습니다. 제품들은 출시 기간 동안 종종 주목을 받지만, 1위 자리에 오른다는 것은 보통 사람들이 단순히 또 다른 기능 출시가 아니라 실제 문제가 해결되는 것을 목격했음을 의미합니다.

그것이 저를 궁금하게 만들었습니다.

왜 개발자들과 AI 빌더들이 BrowserAct에 주목하고 있을까요? 이것이 단순히 또 다른 브라우저 자동화 (browser automation) 도구일까요, 아니면 무언가 다른 점이 있는 걸까요?

문서와 기능 목록을 읽는 대신, 저는 직접 테스트하여 이것이 어떤 문제를 해결하려고 하는지 이해하기로 했습니다.

이 글에서는 BrowserAct가 무엇인지, 해결하려는 문제가 무엇인지, 로컬에 설치하는 방법, 그리고 실제 워크플로우를 사용한 몇 가지 실습 예제를 살펴보겠습니다.

BrowserAct란 무엇인가?

BrowserAct는 특히 _AI 에이전트 (AI agents)_를 위해 구축된 브라우저 자동화 CLI (browser automation CLI)입니다.

전통적인 브라우저 자동화 (browser automation) 도구들은 대개 페이지를 열고, 버튼을 클릭하며, 웹사이트에서 정보를 추출하는 데 집중합니다. 이는 단순한 작업에는 효과적이지만, AI 에이전트 (AI agents)는 종종 기본적인 자동화 이상의 것을 요구합니다. 실제 웹사이트에는 인증 흐름 (authentication flows), 동적 렌더링 (dynamic rendering), 브라우저 핑거프린트 확인 (browser fingerprint checks), 세션 관리 (session management), 그리고 인간의 개입이 필요해지는 상황들이 포함되어 있습니다.

BrowserAct는 브라우저를 단순한 임시 브라우저 창이 아닌, 에이전트를 위한 실행 환경 (execution environment)으로 취급함으로써 이러한 과제들을 해결하고자 시도합니다.

주요 기능은 다음과 같습니다:

• 브라우저 세션 지속성 (Browser session persistence)
• 브라우저 신원 격리 (Browser identity isolation)
• 인간 핸드오프 지원 (Human handoff support)
• 병렬 브라우저 세션 (Parallel browser sessions)
• 탐지 방지 브라우저 환경 (Anti-detection browser environments)
• 재사용 가능한 워크플로우 및 기술 (Reusable workflows and skills)

BrowserAct는 어떤 문제를 해결하려고 하는가?

AI 에이전트를 구축하고 테스트하면서, 저는 많은 워크플로우가 언어 모델 (language model) 때문에 실패하는 것이 아니라는 점을 발견했습니다.

모델은 보통 자신이 무엇을 해야 하는지 알고 있습니다.

문제는 워크플로우가 브라우저로 진입할 때 시작됩니다.

예를 들어, 경쟁사의 가격을 모니터링하는 AI 에이전트를 생각해 보십시오. 이론적으로 이 작업은 매우 간단해 보입니다. 웹사이트를 열고, 정보를 추출하고, 보고서를 생성한 뒤, 결과물을 전송하는 것입니다.

하지만 현실은 대개 다릅니다.

웹사이트에서 인증을 요구할 수 있습니다. 콘텐츠가 동적으로 렌더링될 수 있습니다. 세션 상태가 만료될 수 있습니다. 보안 확인이 예기치 않게 나타날 수 있습니다. 브라우저 핑거프린트가 추가적인 본인 확인을 유도할 수도 있습니다.

이 시점에서 문제는 더 이상 지능의 문제가 아닙니다.

문제는 실행 (execution)의 문제가 됩니다.

BrowserAct는 바로 그 문제를 중심으로 설계된 것으로 보입니다.

BrowserAct 시작하기

BrowserAct를 시작하는 방법은 간단하며, 커맨드 라인 (command-line) 워크플로우와 AI 에이전트 환경 모두에 자연스럽게 통합될 수 있습니다.

사용 계획에 따라 두 가지 일반적인 설치 방식이 있습니다.

1. AI 에이전트를 통한 설치 (에이전트 워크플로우에 권장)

AI 코딩 에이전트(AI coding agent)나 스킬(skills) 및 도구 통합(tool integrations)을 지원하는 환경을 사용 중이라면, BrowserAct를 스킬로서 직접 설치할 수 있습니다.

npx skills add browser-act/skills --skill browser-act

이를 통해 에이전트는 더 큰 워크플로우(workflows) 내부에서 BrowserAct의 기능을 직접 호출할 수 있습니다. 매번 맞춤형 브라우저 자동화 로직을 작성하는 대신, 에이전트는 브라우저 상호작용이 필요할 때마다 BrowserAct를 사용할 수 있습니다.

예를 들어, 에이전트는 다음과 같은 작업을 수행할 수 있습니다:

• 웹사이트 열기
• 페이지 간 이동
• 로그인 흐름(login flows) 처리
• 양식(forms) 채우기
• 구조화된 콘텐츠 추출
• 브라우저 기반 워크플로우 지속

이 방식은 BrowserAct가 독립적인 브라우저 도구가 아닌, 더 넓은 AI 시스템의 일부가 될 때 유용합니다.

2. BrowserAct CLI 직접 설치

터미널에서 직접 작업하는 것을 선호한다면, BrowserAct는 CLI 설치 옵션도 제공합니다.

uv tool install browser-act-cli --python 3.12

설치 후, 로컬 환경을 인증하십시오:

browser-act auth login

browser-act auth poll

API 키를 직접 설정할 수도 있습니다:

browser-act auth set YOUR_API_KEY

인증이 완료되면, BrowserAct는 로컬에서 브라우저 워크플로우를 실행할 준비가 됩니다.

고급 워크플로우로 바로 뛰어들기보다는, 설치가 올바르게 작동하는지 확인하고 기본적인 명령 흐름을 이해하고 싶었습니다.

가장 먼저 확인한 것은 시스템에서 사용 가능한 브라우저 프로필(browser profiles)이었습니다.

browser-act browser list-profiles

출력 결과에는 BrowserAct가 실행 중에 사용할 수 있는 사용 가능한 브라우저 프로필 목록이 표시됩니다. 이러한 프로필은 격리된 브라우저 환경을 생성하거나, 세션 간 상태를 유지하거나, 기존 로그인 컨텍스트(login contexts)를 재사용할 때 유용합니다.

다음으로, 기존의 Chrome 프로필을 사용하여 브라우저를 생성했습니다.

browser create \
-- type chrome \
-- source-profile \
...

BrowserAct는 쿠키(cookies) 및 로컬 스토리지(local storage) 데이터와 같이 사용 가능한 브라우저 상태를 자동으로 가져옵니다.

브라우저 환경이 준비되었으므로, 간단한 콘텐츠 추출(content extraction) 워크플로우를 테스트해 보고 싶었습니다.

첫 번째 테스트: 웹사이트 콘텐츠 추출

첫 번째 테스트를 위해, 간단한 웹사이트에 BrowserAct의 stealth-extract 명령어를 사용했습니다.

browser-act stealth-extract https://example.com --content-type markdown

출력 결과:

# Example Domain

This domain is for use in documentation examples without needing permission.
...

결과는 셀렉터(selectors)를 작성하거나, HTML을 파싱(parsing)하거나, 커스텀 스크래핑(scraping) 로직을 만들 필요 없이 깔끔한 마크다운(markdown) 형식으로 반환되었습니다.

다음으로, BrowserAct가 대화형 브라우저 세션(interactive browser session)을 어떻게 처리하는지 확인하고 싶었습니다.

두 번째 테스트: 브라우저 세션 열기

앞서 생성한 브라우저 프로필을 사용하여 브라우저 세션을 열었습니다.

browser-act \
--session first-test \
browser open \
...

출력 결과에는 활성 세션에 대한 세부 정보가 반환되었습니다:

session_name=first-test
browser_type=chrome
url=https://github.com/
...

이 시점에서 브라우저는 활성화되었으며 상호작용할 준비가 되었습니다.

페이지 상태 검사

BrowserAct의 흥미로운 점 중 하나는 가공되지 않은 HTML (raw HTML)을 직접 노출하지 않는다는 것입니다. 대신, 에이전트 (agent)가 작업할 수 있는 상호작용 가능한 요소들의 구조화된 뷰 (structured view)를 생성합니다.

browser-act \
--session first-test \
state

이를 통해 CSS 선택자 (CSS selectors)를 수동으로 생성하는 대신, 요소 참조 (element references)를 사용하여 상호작용을 수행할 수 있습니다.

이를 더 테스트하기 위해, 저는 검색 버튼을 클릭했습니다:

browser-act \
--session first-test \
click 6

이 시점에서 저는 브라우저 자동화 스크립트 (browser automation script)를 작성하지 않고도 다음과 같은 완전한 워크플로우 (workflow)를 완료했습니다:

브라우저 생성 (Create Browser) → 세션 열기 (Open Session) → 검사 (Inspect) → 입력 (Input) → 클릭 (Click) → 탐색 (Navigate)

세 번째 테스트: AI 에이전트와 함께 BrowserAct 사용하기

CLI를 통해 BrowserAct를 직접 테스트한 후, 실제 AI 에이전트 워크플로우 내에서 어떻게 작동하는지 확인하고 싶었습니다.

이 실험을 위해, 저는 에이전트 런타임 (agent runtime)으로 Codex를 사용했습니다.

BrowserAct의 장점 중 하나는 독립적인 도구로 존재할 필요가 없다는 것입니다. 브라우저 상호작용이 필요할 때마다 에이전트가 BrowserAct를 호출하도록 지시할 수 있습니다. 여기에는 웹사이트 열기, 버튼 클릭, 로그인 흐름 처리, 구조화된 콘텐츠 추출, 또는 동적 페이지 (dynamic pages)와의 상호작용 등이 포함됩니다.

이를 테스트하기 위해, 에이전트에게 BrowserAct를 설치하고 워크플로우의 일부로 사용하도록 요청했습니다.

제가 제공한 프롬프트 (prompt)는 다음과 같습니다:

Set up BrowserAct for me. 
Read the BrowserAct skill first: https://github.com/browser-act/skills/blob/main/browser-act/SKILL.md
Install or update the browser-act skill, then verify it works. 
...

지침을 받은 후, 에이전트(agent)는 워크플로(workflow)를 자동으로 실행하기 시작했습니다.

워크플로는 다음과 같은 모습이었습니다:

에이전트(Agent) 시작
        ↓
BrowserAct 스킬 설치
...

흥미로운 점은 에이전트가 정적인 지침(static instructions)에 의존하는 대신 BrowserAct를 도구(tool)로 사용하는 것을 지켜보는 것이었습니다. 브라우저 동작(browser actions)이 별도의 수동 단계가 아닌 실행 프로세스의 일부가 되었습니다.

확인을 받은 후, 에이전트는 작업을 성공적으로 완료하고 저장소(repository)에 스타(star)를 눌렀습니다.