Transcript
00:00:00이것은 LightPanda입니다. AI 에이전트를 위해 처음부터 Zig로 작성된 헤드리스 브라우저죠. WebKit이나 Chromium을 사용하지 않아 헤드리스 Chrome보다 최대 9배 빠르고 메모리는 16배 적게 사용합니다.
00:00:12Chrome DevTools 프로토콜을 지원해서 Puppeteer나 Playwright와 함께 사용할 수 있지만, 픽셀을 렌더링하지 않으며 서비스 워커, IndexedDB, CORS 같은 일반적인 웹 API는 지원하지 않습니다.
00:00:22그렇다면 왜 OpenClaw나 Cells 에이전트 브라우저에서 사용되는 걸까요? 구독 버튼을 누르고 함께 알아봅시다.
00:00:30LightPanda는 2024년경 Pierre, Francis, Kate에 의해 출시되었습니다. Claude Code가 나오기도 전이고, ChatGPT가 인기를 얻기 시작할 무렵이었죠.
00:00:41처음에는 웹 스크래핑 및 자동화 도구로 시작했지만, AI 에이전트의 인기가 폭발하면서 AI 에이전트 분야에 집중했고 투자 유치에도 성공했습니다.
00:00:51그런데 이게 단순히 AI 열풍에 편승한 이름 바꾸기였을까요, 아니면 실제로 에이전트에게 유용한 도구일까요?
00:00:56Claude SDK와 커스텀 WebFetch 도구를 사용해 직접 에이전트를 만들어 테스트해 보려 합니다. Chrome과 LightPanda를 웹 브라우징 엔진으로 각각 사용해 보고, 무엇이 더 나은지 왜 그런지 비교해 보겠습니다.
00:01:09LightPanda는 MCP 서버와 자체 클라우드 서비스를 제공하지만, 가능한 한 로컬 환경에서 테스트를 진행하겠습니다.
00:01:16먼저 LightPanda를 사용하는 기본적인 예제를 살펴본 뒤, WebFetch 도구를 만드는 단계로 넘어가겠습니다.
00:01:22여기 Wikipedia에서 링크를 가져오는 간단한 스크립트가 있습니다.
00:01:27작동 방식은 이렇습니다. 먼저 LightPanda 서버를 생성한 뒤, Puppeteer를 사용하여 그 서버에 연결합니다.
00:01:32프로세스 소요 시간을 측정하는 코드가 있고, Wikipedia에 접속해서 참고 문헌 섹션의 모든 링크를 찾아 출력하도록 되어 있습니다.
00:01:40이해를 돕자면, 웹 브라우저 페이지 하단에 있는 참고 문헌 섹션입니다.
00:01:44보시다시피 첫 번째 참고 링크는 이 Device Atlas인데, 아래쪽 링크와 일치하죠.
00:01:50LightPanda는 344밀리초 만에 모든 링크를 찾았습니다.
00:01:53같은 작업을 Chrome으로 시도하면 392밀리초가 걸립니다.
00:01:58큰 차이는 없어 보이지만, 여러 페이지를 스크래핑해야 할 때는 상황이 급격히 달라집니다.
00:02:04자, 여기 비슷한 스크립트가 하나 있는데 결정적인 차이가 있습니다.
00:02:07Wikipedia 페이지 한 곳이 아니라, 100곳에서 링크를 가져오는 겁니다.
00:02:11정의를 확인해 보면, 웹 브라우저가 HTTPS, JavaScript, Mongo, Python 등 수많은 페이지에서 정보를 가져오는 것을 볼 수 있습니다.
00:02:19LightPanda로 시도하면 전체 작업이 18초 만에 끝납니다.
00:02:23Chrome으로 같은 작업을 시도하면 약 30초가 걸립니다.
00:02:26제가 실행했을 때 어떤 경우에는 60초가 걸리기도 했습니다.
00:02:29그럼 에이전트를 통해 실행할 때 성능 차이는 어떻게 나타나는지 보겠습니다.
00:02:32여기 Claude SDK를 사용한 아주 기본적인 에이전트가 있고, 그 옆에는 이 프롬프트를 실행하는 WebFetch 도구가 있습니다.
00:02:39JavaScript의 Array Map, Filter, Reduce의 차이점을 요약하고, MDN의 특정 링크에 접속해서 정보를 찾는 작업입니다.
00:02:48아래에 에이전트 루프가 있고, 여기 도구가 하나뿐이라 특정 도구가 사용되는지 확인하는 if 문이 있습니다.
00:02:54도구가 더 많아지면 처리 방식이 달라지겠지만요.
00:02:56그리고 도구 호출이 있을 때마다 실행되는 webfetch 함수가 있습니다.
00:03:00그 아래에는 브라우저 메모리 계산을 위한 메트릭과 함수가 있습니다.
00:03:04이 프로젝트는 Chrome DevTools 프로토콜을 사용해 LightPanda와 Chrome을 각각 사용하게 됩니다.
00:03:09포트에서 서버를 실행하고, 에이전트를 실행하기 전에 Puppeteer가 그 포트에 연결하도록 할 것입니다.
00:03:14LightPanda serve 명령으로 서버를 시작하고, 에이전트를 실행하면 MDN에서 세 개의 URL을 가져와 Claude에게 전달합니다.
00:03:22그러면 Claude는 Map, Filter, Reduce의 차이점에 대한 답변과 함께 메트릭을 반환해 줍니다.
00:03:29이제 Chrome으로 시도해 보겠습니다. LightPanda는 완전한 브라우저가 아니라서 Chrome과 같은 수준의 캐싱 기능이 없으므로, 공정함을 위해 Chrome의 기본 캐시도 제거하겠습니다.
00:03:38캐시를 제거하는 것이 공평하니까요.
00:03:40Chrome에서 동일한 작업을 실행해 보면, 마찬가지로 MDN에서 URL을 가져와 Claude로부터 답변을 받습니다.
00:03:46그런데 여기서 결과가 확연히 달라집니다.
00:03:48결과를 나란히 비교해 보면, 왼쪽은 LightPanda, 오른쪽은 Chrome입니다. 둘 다 세 번의 fetch를 수행했죠.
00:03:54하지만 LightPanda의 fetch 시간이 Chrome보다 훨씬 빠른 것을 볼 수 있습니다. 거의 두 배 가까이 빠릅니다.
00:03:59전체 실행 시간(Wall time)은 동일하지만요.
00:04:01하지만 여기를 보세요. LightPanda의 브라우저 메모리는 고작 66MB인데, Chrome은 829MB입니다.
00:04:07LightPanda가 10배 이상 적게 사용하죠. 에이전트 메모리도 LightPanda 쪽이 조금 더 작지만, 브라우저 엔진이 이 값에 큰 영향을 미치지는 않습니다.
00:04:17솔직히 말씀드리면, 헤드리스 브라우징에 더 이상 Chrome을 사용해서는 안 됩니다.
00:04:20왜 굳이 사용하겠어요? LightPanda는 Chrome보다 최대 21배 작고, 더 빠르며 메모리도 훨씬 적게 사용하는데 말이죠.
00:04:28하지만 LightPanda 대신 Chrome을 사용해야 하는 경우가 딱 하나 있습니다.
00:04:33질문을 JavaScript 관련 질문에서 '도쿄의 에어비앤비 숙소 5곳 찾아줘'로 바꾸면, Chrome은 예상대로 결과를 가져옵니다.
00:04:42하지만 LightPanda로 시도하면 에어비앤비 목록을 가져오지 못합니다.
00:04:47에어비앤비는 SPA(싱글 페이지 애플리케이션)인데, LightPanda도 JavaScript 실행을 위한 V8 엔진을 탑재하고는 있습니다.
00:04:54다만 이는 언어 수준의 실행을 위한 것이죠.
00:04:57async await, 클로저, 프로미스 같은 것들 말입니다.
00:05:00하지만 에어비앤비 같은 복잡한 싱글 페이지 애플리케이션의 경우, LightPanda는 렌더링하고 필요한 정보를 추출하는 데 어려움을 겪습니다.
00:05:07SPA를 제대로 렌더링하지 못한다는 점을 제외하면, (물론 나중에 개선될 수도 있겠지만요)
00:05:13LightPanda는 웹 검색이나 웹 패칭이 필요한 커스텀 에이전트에 추가하기에 아주 훌륭한 도구입니다.
00:05:20에이전트를 활용한 웹 브라우징 이야기가 나온 김에, 만약 실제로 실행 중인 Chrome 세션을 Claude Code가 안전하게 제어하고 싶다면,
00:05:27로그인 정보 등을 그대로 유지한 채 제어하는 방법을 다룬 이 원격 디버깅 및 Chrome MCP 서버 관련 영상을 확인해 보세요.