Puppeteer는 헤드리스 Chrome을 스크립트로 조작하는 Node.js 라이브러리입니다. 탐색 코드를 직접 작성하고, 선택자를 조정하고, 대상 사이트가 리디자인될 때마다 스크립트를 손봐야 합니다.
ego (lite)는 스크립트 단계를 건너뜁니다. 에이전트가 로그인된 Chrome을 직접 읽고 스스로 JavaScript를 작성해, 작업 전체를 Puppeteer보다 3~4배 빠르게 끝냅니다.
한 번 쓰고 마는 스크래핑, 양식 작성, 테스트, 백오피스 업무는 늘 스크립트 자체가 비용이었습니다. 작성하고, 페이지가 바뀔 때마다 다시 고치는 일이었죠. ego (lite)는 오픈소스 ego-browser 셸을 통해 그 작업을 이미 쓰고 있는 에이전트(Claude Code, Codex, Cursor)에게 넘깁니다.
Puppeteer의 이슈 트래커에는 요소가 DOM에 분명히 있는데도 발생하는 waitForSelector 타임아웃 사례가 가득합니다. 내 코드 문제가 아니라 타이밍 버그라는 걸 증명하는 데만 오후 반나절을 쓰게 되죠.
ego (lite)는 기다리고 확인하는 절차를 건너뜁니다. 에이전트는 페이지가 로드되는 순간 압축된 Snapshot으로 읽어 곧바로 동작하며, 여러 단계를 한 턴의 JavaScript 호출로 묶어 처리합니다. 그 결과 작업 전체가 Puppeteer보다 3~4배 빠르게 끝납니다.
단일 스크립트를 넘어서려는 Puppeteer 개발자는 병렬 처리가 곧 자체 풀 운영이라는 걸 깨닫습니다. 실행 옵션, 브라우저 컨텍스트, 그리고 Chrome이 RAM을 다 먹어치우기 전에 동시성을 제한할 puppeteer-cluster 같은 큐 라이브러리까지 직접 관리해야 하죠.
ego (lite)에는 크기를 맞춰야 할 풀이 없습니다. 모든 작업은 하나의 브라우저 안에서 자기만의 Space를 갖고, 원하는 만큼 얼마든지 열 수 있으며, 각각 가져온 Chrome 프로필로 동작합니다. 지금 쓰고 있는 탭은 건드리지 않고, 어떤 Space든 언제든 지켜보거나 직접 이어받을 수 있습니다.
순수한 Puppeteer 스크립트는 토큰을 쓰지 않습니다. 모델을 아예 호출하지 않으니까요. 비용은 원조 Puppeteer MCP 참조 구현 같은 MCP 서버로 Puppeteer를 에이전트용으로 감싸는 순간 나타납니다. 감싸인 동작 하나하나가 별도의 도구 호출이 되어 모델로 컨텍스트를 다시 전송하기 때문이고, 접근성 스냅샷 도구가 없다 보니 스크린샷에 의존해 자기 작업을 확인해야 합니다.
ego (lite)의 에이전트는 여러 동작을 한 턴에 몇 줄의 JavaScript로 묶어 처리하고, 여기에 Snapshot 입력이 더해지면서 같은 작업이 전체적으로 훨씬 적은 토큰으로 끝납니다. 작업 단위로 측정했을 때 그렇습니다.
Puppeteer는 쿠키도 세션도 없는 텅 빈 Chrome을 새로 띄웁니다. 그래서 로그인 뒤에 있는 무언가를 다루려면 인증 흐름을 직접 스크립트로 짜야 하고, 낯선 브라우저라며 사이트가 캡차나 2FA를 던지지 않길 바라야 합니다. 이 빈 프로필 장벽이야말로 개발 환경에서는 되던 스크립트가 실제 사이트에서 실패하는 가장 흔한 이유입니다.
Chromium 기반의 ego (lite)는 Chrome 환경 전체를 한 번의 클릭으로 그대로 가져옵니다. 에이전트는 로그인, 쿠키, 확장 프로그램을 그대로 물려받기 때문에 막힐 일이 없습니다.
| 기능 | ego lite | Puppeteer |
|---|---|---|
| 작업이 이뤄지는 방식 | 작업을 설명하면 에이전트가 브라우저를 대신 조작 | Node.js 스크립트 작성 및 유지 관리 |
| 페이지 변경 대응 방식 | 에이전트가 Snapshot을 다시 읽고 적응 | 선택자가 깨지면 스크립트를 직접 손봐야 함 |
| 로그인이 필요한 사이트 (SSO, 2FA) | 실제 Chrome 프로필과 세션을 그대로 사용 | 빈 프로필. 로그인을 스크립트로 짜고 쿠키를 내보내야 함 |
| 설정 | 앱을 설치하고 에이전트에서 /ego-browser 실행 | Node 프로젝트, npm install, 실행 설정 |
| 병렬 작업 | Space가 하나의 브라우저 안에서 작업을 격리, 풀을 조정할 필요 없음 | 브라우저 풀, 컨텍스트, 메모리를 직접 관리 |
| AI 에이전트와 함께 동작 | 이를 위해 만들어짐: ego-browser로 Claude Code, Codex, Cursor 연동 | 기본 지원 아님. MCP 래퍼나 별도 연동 코드 필요 |
| 매일 쓰는 일상 브라우저 | 가능: 사람과 에이전트가 하나의 브라우저를 공유하되 Space는 분리 | 아니요, 헤드리스 자동화 도구 |
| CI 테스트 스위트에 최적 | 아니요: 커밋된 테스트 코드가 아닌 인터랙티브 에이전트 작업 | 가능: 결과가 일정하고 스크립트로 짤 수 있으며 CI 친화적 |
| 재사용 가능한 스킬 (출시 예정) | 성공한 실행을 재사용 가능한 스킬로 압축하며, 에이전트가 이를 반복할수록 복잡한 작업에서 최대 5배 빠름 (제한적 베타) | 내장된 대응 기능 없음 |
| 가격 | 무료, 구독 없음 | 무료, 오픈소스 |
Puppeteer 스크립트를 ego (lite)로 옮기는 게 아닙니다. 더 이상 스크립트를 쓰지 않는 거죠. 스크립트로 짰던 작업, 혹은 짜다가 포기한 작업을 그대로 에이전트에게 넘기면 됩니다.
ego (lite)를 다운로드하고 Chrome 프로필을 가져오세요. 스크립트가 끝내 뚫지 못했던 로그인까지 함께 따라옵니다.
에이전트에 붙여넣기
/ego-browser ego.app을 열고 콘솔 오류가 있는지 확인하세요
Claude Code, Codex, Cursor에서 /ego-browser를 실행하세요.
평소라면 스크립트로 짰을 작업, 예를 들어 목록 페이지 스크래핑이나 백오피스 양식 작성 같은 걸 골라 에이전트에게 한 문장으로 설명하세요.
스크립트가 진짜로 유리한 영역, 즉 결과가 일정한 CI 스위트와 대량의 예약 작업에는 Puppeteer를 그대로 쓰세요. ego (lite)는 매주 바뀌는 인터랙티브한 브라우저 작업을 맡습니다.
무료이며 Mac에서 실행되고, 클릭 한 번으로 Chrome 프로필을 가져옵니다. Claude Code, Codex, Cursor 등 코드를 작성하는 모든 CLI 에이전트와 함께 사용할 수 있습니다.
아직 고민 중이신가요? Puppeteer가 같은 분야의 다른 도구들과 어떻게 다른지 확인해 보세요.
Puppeteer는 Chrome 팀이 만든 Node.js 자동화 라이브러리로, DevTools Protocol과 WebDriver BiDi를 통해 Chrome과 Firefox를 제어합니다. 성숙하고 빠르고 무료이며, Chrome 전용 스크래퍼, PDF 생성, 헤드리스 테스트를 스크립트로 짜는 개발자들이 흔히 선택하는 도구입니다. 테스트 프레임워크 채택 전반에서는 Playwright가 앞서갔지만요. Puppeteer 자체의 이슈 트래커에는 탐색과 재연결 과정에서 발생하는 waitForSelector의 실제 불안정성이 기록돼 있고, 대규모로 운영하는 팀은 결국 브라우저 풀, 컨텍스트, 메모리를 직접 관리하게 됩니다. 그래도 CI에서 돌아가는, 손으로 다듬고 커밋한 자동화 코드에는 여전히 훌륭합니다. 아래 비교는 스크립트가 아니라 AI 에이전트가 브라우징을 맡을 때 벌어지는 일을 다룹니다.
AI 에이전트가 주도하는 브라우저 작업이라면 그렇습니다. 스크립트 계층을 완전히 없애고 로그인된 실제 Chrome에서 작업을 실행하니까요. 더 많은 스크립팅이 아니라 에이전트를 위해 만들어진 몇 안 되는 Puppeteer 대안 중 하나입니다. CI에서 돌아가는, 커밋된 결정론적 자동화 코드에는 여전히 Puppeteer가 더 나은 도구입니다. 많은 개발자가 둘 다 씁니다. 파이프라인에는 Puppeteer를, 스크립트로 짤 시간이 없던 모든 작업에는 ego (lite)를 쓰는 식이죠.
셋 다 스크립트를 우선으로 하는 자동화 라이브러리이며, playwright vs puppeteer나 puppeteer vs selenium의 선택은 대개 무엇을 테스트하는지와 어떤 언어를 쓰는지에 달려 있습니다. Node에서 Chrome만 다루면서 가벼운 DevTools 수준의 API를 원한다면 Puppeteer가 유리합니다. 새로운 테스트 스위트라면 대체로 Playwright가 앞섭니다. 멀티 브라우저 지원, 자동 대기, 더 강력한 테스트 러너를 갖췄기 때문이죠. Selenium vs Puppeteer는 더 팽팽한 대결이고, selenium과 puppeteer 중 어느 게 더 나은지는 순수한 성능보다 언어와 CI 환경에 좌우되는 경우가 많습니다. Selenium의 강점은 W3C WebDriver 표준과 가장 폭넓은 언어·구형 브라우저 지원이지만, 그만큼 보일러플레이트도 늘어납니다. ego (lite)는 이 논쟁 자체에 끼지 않습니다. 셋 중 누구도 아닌, AI 에이전트가 직접 브라우징하는 AI 에이전트 브라우저이기 때문입니다. 관련 비교는 ego (lite) vs Playwright, ego (lite) vs Selenium 페이지를 참고하세요.
Puppeteer를 감싼 MCP 래퍼는 에이전트에게 브라우저 접근권을 주지만, 동작 하나마다 모델과 도구 호출을 왕복해야 하고, 그 아래 브라우저는 여전히 빈 프로필입니다. ego (lite)는 동작을 JavaScript로 묶어 처리하고 실제 로그인 상태를 그대로 물려받기 때문에, 작업당 토큰 비용이 낮게 유지되고 래퍼가 뚫지 못하는 SSO 장벽에 부딪힐 일도 없습니다.
선택자는 페이지의 정확한 마크업, 즉 클래스명, DOM 순서, ARIA 구조에 묶여 있습니다. 대상 사이트의 리디자인, A/B 테스트, 프레임워크 업그레이드가 그 마크업을 바꾸면 waitForSelector 호출이 타임아웃을 내기 시작하는데, 종종 간헐적으로 발생합니다. 바로 이게 Puppeteer 자체의 트래커에 반복적으로 보고되는 종류의 불안정성입니다. ego (lite)의 에이전트는 고정된 선택자를 아예 붙들고 있지 않습니다. 매번 현재 페이지를 Snapshot으로 읽고 실제로 거기 있는 것을 근거로 판단하기 때문에, 리디자인은 스크립트를 깨뜨리는 사건이 아니라 다음 실행에서 알아서 적응할 대상이 됩니다.
아니요. Puppeteer를 단일 스크립트 이상으로 확장하려면 대개 풀(puppeteer-cluster, generic-pool, 또는 직접 만든 큐)을 세워서 Chrome의 메모리 사용량이 감당 안 되기 전에 동시성을 제한해야 합니다. ego (lite)의 Space는 이미 열어둔 하나의 브라우저 프로세스 안에서 돌아가기 때문에, 작업 다섯 개를 동시에 실행해도 다섯 개의 브라우저 인스턴스를 일일이 돌봐야 하는 게 아닙니다.
네. 코드를 작성하는 CLI 에이전트라면 MIT 라이선스의 ego-browser 셸을 통해 바로 연결됩니다. Claude Code, Codex, Cursor, Gemini CLI, OpenCode, 그리고 직접 만든 사내 에이전트까지 전부 가능합니다.
네. 무료이고 구독료도 없으며, ego-browser 셸은 오픈소스입니다.