한 줄 요약: lightpanda-io/browser(Lightpanda)는 크로미엄·웹킷을 포크하지 않고 Zig로 처음부터 다시 쓴 헤드리스 브라우저입니다. 픽셀을 그리는 렌더링 엔진은 빼고, DOM·V8 자바스크립트·네트워크만 남겼습니다. 그 위에 CDP·WebDriver BiDi 서버, 네이티브 MCP 서버, LLM이 직접 브라우저를 모는 agent 모드, 그리고 그 세션을 토큰 없이 다시 돌리는 PandaScript까지 얹었습니다. 11월 1일 오늘 GitHub Trending 전체 9위(하루 +929 스타)에 올랐고, 오전 11시 55분(KST) API 기준 스타는 39,298개입니다. 이 글은 v1.0.2 바이너리를 박스에 직접 깔고 같은 Puppeteer 스크립트로 Chrome과 50페이지를 돌려 본 결과까지 정리했습니다.
1. 한눈에 보는 프로젝트
| 항목 | 내용 (2026-11-01 KST 확인) |
|---|---|
| 저장소 | lightpanda-io/browser (2023-02-07 생성, 운영사 Lightpanda/Selecy SAS) |
| 라이선스 | AGPL-3.0-only (LICENSING.md 명시), 기여 시 CLA 서명 필요 |
| 최신 릴리스 | 1.0.2 — 2026-10-23 18:01 KST 게시 (1.0.0은 10-02, 1.0.1은 10-15). main 브랜치 버전은 1.1.0-dev |
| 스타 / 포크 | 39,298 / 1,912 (오늘 트렌딩 +929) |
| 언어·의존성 | Zig 0.17.0, V8(자체 zig-v8 포크), html5ever(Rust FFI), libcurl 8.23, BoringSSL, nghttp2, SQLite, PCRE2 |
| 코드 규모 | src 아래 .zig 파일 687개, 약 29.6만 줄 (얕은 클론 기준 wc 측정) |
| 배포 형태 | 단일 정적 바이너리(x86_64·aarch64 Linux/macOS, 약 76MB), .deb, Docker(lightpanda/browser), Homebrew·AUR(nightly), Nix flake |
| 주장 수치 | README: AWS m5.large에서 실제 웹페이지 100개 기준 메모리 피크 123MB vs Chrome 2GB(약 16배), 실행 5초 vs 46초(약 9배) |
2. 왜 또 브라우저인가: 문제 정의
에이전트와 크롤러가 웹을 읽는 방법은 크게 두 가지였습니다. HTTP 요청 + HTML 파서는 가볍지만, React·Vue로 그리는 SPA나 XHR로 늦게 채워지는 페이지 앞에서는 빈 껍데기만 받습니다. 헤드리스 Chrome은 무엇이든 열지만, 탭마다 수백 MB씩 먹고 GPU 합성·페인트·확장 인프라처럼 서버에선 쓸모없는 기능까지 다 끌고 다닙니다. 수백~수천 인스턴스를 띄우는 순간 이것이 그대로 클라우드 비용이 됩니다.
Lightpanda의 답은 “JS는 진짜로 돌리되, 화면은 그리지 않는다”입니다. 사람이 볼 픽셀이 필요 없는 기계 사용자(에이전트·스크래퍼·테스트)에게 맞춘 브라우저라는 뜻입니다. 이 결정 하나에서 장점(메모리·기동 속도)과 한계(시각 기반 작업 불가, 웹 호환성 부채)가 같이 나옵니다.
3. 아키텍처: 다섯 개의 문, 하나의 코어
바이너리 하나에 서브커맨드 다섯 개가 들어 있고, 모두 같은 브라우저 코어(Session → Page → Frame)를 공유합니다.
| 진입점 | 프로토콜 | 주 사용처 | 박스 확인 |
|---|---|---|---|
fetch |
CLI 한 번 실행 | URL 하나(또는 여러 개, --json)를 열고 html·markdown·semantic_tree·structured_data·png·pdf로 덤프 |
example.com 0.12초, HN 0.28초 |
serve |
CDP WebSocket, --protocol webdriver로 BiDi |
기존 Puppeteer·Playwright 코드의 browserWSEndpoint만 바꿔 연결 |
puppeteer-core 25.16으로 50페이지 성공 |
mcp |
MCP JSON-RPC 2.0 (stdio 또는 HTTP --port) |
코딩 에이전트·LLM 앱에 브라우저 도구 제공. HTTP 모드는 Mcp-Session-Id로 세션 격리 |
도구 32개 노출 확인 |
agent |
내장 LLM 클라이언트 | Anthropic·OpenAI·Gemini·Vertex·Mistral·HF·OpenRouter·Vercel AI Gateway·Ollama·llama.cpp 등으로 자연어 조작 | API 키 없이 미실행(--no-llm REPL만 존재 확인) |
run |
PandaScript(.js) 실행 | agent 세션에서 /save한 스크립트를 LLM 없이 결정적으로 재생 |
campfire 데모 상품 추출 0.31초 |
저장소 구조로 본 책임 분리
| 디렉터리 | 역할 | 읽어 볼 포인트 |
|---|---|---|
src/browser/ |
Page·Frame·ScriptManager·EventManager, webapi/(Web API 구현 120여 항목), markdown.zig, clutter.zig, layout.zig |
clutter.zig는 readability.js의 grabArticle 방식(문단 점수 → 조상 선택 → 링크 밀도로 가지치기)을 DOM 변경 없이 “건너뛸 노드 집합”으로 구현 |
src/browser/js/ |
V8 바인딩, 스냅샷 | 기본은 기동 시 스냅샷 생성, -Dsnapshot_path로 바이너리에 내장 가능(#1279) |
src/network/ |
HttpClient(libcurl), Robots, IpFilter, UrlBlocklist, adblock, cache, RateLimiter, SingleFlight, WebBotAuth | 사설망 차단이 DNS 해석 이후 IP 기준으로 동작 → DNS 리바인딩 류 SSRF에 강한 쪽 |
src/server/ |
cdp/(domains: page·runtime·dom·fetch·network·accessibility·webmcp 등), bidi/ | LP.getPageStatus 같은 자체 CDP 도메인과 Chrome의 WebMCP 도메인 구현 |
src/mcp/, src/agent/, src/script/ |
MCP 서버·라우터, 내장 에이전트, PandaScript 런타임·Recorder·스킬 문서 | Recorder가 명시적 waitUntil이 없는 goto를 domcontentloaded로 다운그레이드해 기록하는 규칙 등 |
src/rust/ |
html5ever FFI, render | HTML 파싱만큼은 검증된 Servo 파서를 그대로 빌려 씀 |
src/telemetry/ |
사용 텔레메트리 | run·navigate·llm·tool·mcp_client 이벤트를 telemetry.lightpanda.io/v2로 전송, 환경변수로 끔 |
4. 핵심 설계 결정과 트레이드오프
| 결정 | 얻는 것 | 잃는 것 / 비용 |
|---|---|---|
| 포크 대신 처음부터 작성 (Zig) | 명시적 메모리 관리(Arena·RecyclingAllocator), 불필요한 서브시스템 0, 단일 바이너리 | 웹 호환성을 하나하나 쌓아야 함. 릴리스 노트마다 “:nth-child(An+B of S) 추가”, “getBoundingClientRect 뷰포트 기준으로 수정” 같은 항목이 이어지는 이유 |
| 렌더링 엔진 없음 | GPU·페인트·합성 비용 제거 → 기동 0.1초대, 프로세스 RSS 수십 MB | png/pdf는 “텍스트 전용 렌더링”. 캔버스·WebGL 기반 화면, 픽셀 비교 테스트, 비전 모델용 스크린샷 에이전트에는 부적합 |
| JS 엔진은 V8 그대로 | 최신 JS 문법·성능, 프레임워크 호환성 | 바이너리 크기(약 76MB)와 V8 빌드 복잡도. 소스 빌드 시 Zig 0.17 + Rust + clang 필요 |
| CDP 호환 | Puppeteer·Playwright 코드를 엔드포인트만 바꿔 재사용 | CDP 전 도메인 구현은 아님. 1.0.2에서도 Fetch.continueRequest interceptResponse, DOM.scrollIntoViewIfNeeded가 이제 막 들어옴 → 스크립트별 검증 필수 |
| MCP·agent를 같은 프로세스에 | 도구 호출이 IPC 없이 직접 연산, 세션별 격리(HTTP 모드) | 브라우저 보안 경계와 에이전트 경계가 한 프로세스에 겹침 → 프롬프트 인젝션 시 같은 권한 |
| UA에 “Mozilla” 금지 | 스스로를 봇으로 밝히는 정직한 클라이언트(Lightpanda/1.0), Web Bot Auth(Ed25519 서명) 지원 | UA로 브라우저를 판별하는 사이트에선 차단·다른 응답 가능. 우회용으로 쓰려는 사람에겐 의도적으로 불편 |
5. 에이전트 관점의 기능: MCP 32개 도구와 PandaScript
v1.0.2 바이너리의 lightpanda mcp에 initialize → tools/list를 보내 보니 서버 정보는 lightpanda 0.1.0, 프로토콜 2025-06-18, 도구는 32개였습니다. goto·search·markdown·html·screenshot·links·evaluate·extract·tree·nodeDetails·interactiveElements·structuredData·detectForms·click·fill·scroll·waitForSelector·waitForScript·waitForState·hover·press·selectOption·setChecked·findElement·consoleLogs·getUrl·getCookies·getEnv·save·session_new·session_list·session_close입니다. 참고로 README(main 브랜치)가 소개하는 run 도구는 1.0.2 바이너리 목록에는 없었습니다. 1.0.2 이후 main 브랜치에 추가된 기능이라, 쓰려면 nightly 빌드를 받거나 다음 릴리스를 기다려야 합니다.
눈여겨볼 점은 “LLM이 읽기 좋은 출력”을 브라우저가 직접 만든다는 것입니다. 박스에서 같은 페이지를 덤프 모드별로 비교했습니다.
| 페이지 | html | markdown | markdown + clutter 제거 | semantic_tree_text |
|---|---|---|---|---|
| news.ycombinator.com | 35,111 B | 19,726 B | 18,592 B | 10,708 B |
| Wikipedia “Zig (programming language)” | 437,336 B | 63,463 B | 42,513 B | 66,527 B |
위키백과처럼 무거운 문서는 html 대비 markdown이 약 1/7, clutter 제거 후에는 약 1/10입니다. 반대로 HN처럼 링크가 빽빽한 목록 페이지는 semantic_tree_text(역할·접근 가능한 이름·노드 ID)가 가장 작습니다. 읽기(요약·RAG)엔 markdown + clutter, 조작(클릭·입력)엔 semantic tree로 나눠 쓰는 것이 토큰 효율이 좋습니다. 또 main 브랜치에는 웹페이지가 navigator.modelContext로 도구를 등록하는 W3C 초안 WebMCP와 CDP WebMCP 도메인 구현도 들어와 있어, “사이트가 에이전트에게 직접 도구를 내미는” 흐름까지 대비하고 있습니다.
PandaScript는 이 프로젝트의 가장 실용적인 아이디어입니다. LLM이 탐색한 세션을 /save하면 new Page(), page.goto(), page.extract() 같은 원시 함수로 된 평범한 JS가 나옵니다. 이후엔 lightpanda run으로 모델 호출 0, 토큰 0으로 반복 실행합니다. “프로토타입은 LLM으로, 프로덕션은 스크립트로”라는 분업입니다. 다만 박스에서 바로 함정을 만났습니다.
// s.js — 기본값(load)으로 이동
const page = new Page();
await page.goto("https://demo-browser.lightpanda.io/campfire-commerce/");
return page.extract({ title: "h1", price: "h4", features: ["#product-features li"] });
// 결과: {"title":"Loading...","price":"","features":[]}
// s2.js — 대기 조건 명시
await page.goto({ url: "https://demo-browser.lightpanda.io/campfire-commerce/", waitUntil: "networkidle" });
// 결과: 제목 "Outdoor Odyssey Nomad Backpack 60 liters", 가격 "$244.99", 특징 4개 (0.31초, 최대 RSS 28MB)이 데모 상품 상세는 XHR로 늦게 채워집니다. 스크립트가 결정적이라는 말은 실행 경로가 결정적이라는 뜻이지, 페이지가 언제 준비되는지까지 알아서 맞춰 준다는 뜻이 아닙니다. 내장 스킬 문서도 동적 페이지에선 waitForState("networkidle")이나 waitForSelector를 쓰라고 권합니다.
6. 설치와 실행: 실제로 쓴 명령
# 1) 릴리스 바이너리 (glibc 2.35+ 필요, 박스는 Debian glibc 2.41)
curl -L -o lightpanda https://github.com/lightpanda-io/browser/releases/download/1.0.2/lightpanda-x86_64-linux
chmod +x lightpanda && ./lightpanda version # → 1.0.2
export LIGHTPANDA_DISABLE_TELEMETRY=true # 텔레메트리 끄기 (기본 ON)
# 2) 덤프
./lightpanda fetch --dump markdown --wait-until networkidle https://news.ycombinator.com/
./lightpanda fetch --dump markdown --strip-mode clutter https://en.wikipedia.org/wiki/Zig_(programming_language)
./lightpanda fetch --dump structured_data --json https://example.com
# 3) CDP 서버 (로컬 바인딩 권장) + Puppeteer
./lightpanda serve --host 127.0.0.1 --port 9222 --obey-robots
# puppeteer.connect({ browserWSEndpoint: "ws://127.0.0.1:9222" })
# 4) MCP (stdio) — 에이전트 설정
{ "mcpServers": { "lightpanda": { "command": "/path/to/lightpanda", "args": ["mcp"] } } }
# 여러 에이전트가 한 프로세스를 나눠 쓸 땐 HTTP 모드
./lightpanda mcp --port 9223 # POST http://127.0.0.1:9223/mcp
# 5) Docker
docker run -d --name lightpanda -p 127.0.0.1:9222:9222 lightpanda/browser:latestAlpine 같은 musl 배포판에서는 바이너리가 cannot execute: required file not found로 실패합니다(README 명시). 컨테이너 베이스는 x86_64면 debian:bookworm-slim 이상, arm64면 ubuntu:24.04나 debian:trixie-slim이 필요합니다.
7. 박스 스모크 테스트: Chrome과 같은 조건으로
환경은 8 vCPU·16GB 리눅스 VM, GPU 없음입니다. Lightpanda는 1.0.2 공식 바이너리, Chrome은 시스템 google-chrome(--headless=new)을 썼습니다. 둘 다 같은 puppeteer-core 25.16 스크립트로 접속해 데모 사이트(demo-browser.lightpanda.io/amiibo)의 링크를 따라 50페이지를 순차 방문했습니다. 각 페이지는 waitUntil: networkidle0로 기다린 뒤 제목과 모든 링크를 뽑았습니다. 메모리는 브라우저 프로세스 트리의 PSS 합계를 50ms 간격으로 샘플링한 최댓값이고, RSS 합계도 함께 기록했습니다.
| 측정 | Lightpanda 1.0.2 | Chrome headless | 비고 |
|---|---|---|---|
| 성공 페이지 / 수집 링크 | 50/50 · 596개 | 50/50 · 596개 | 첫 h1 3개(Sandy·Isabelle·Coach)까지 동일 |
| 벽시계 시간 (3회) | 40.3 / 40.8 / 41.3초 | 56.0 / 56.3 / 56.5초 | 약 1.4배 빠름 |
| 기동 직후 메모리 | PSS 11MB (RSS 13MB) | PSS 515~537MB (RSS 합 1.5~1.7GB) | Chrome RSS 합은 공유 페이지 중복 계산 → PSS가 공정 |
| 최대 메모리 | PSS 27MB (RSS 29MB) | PSS 704MB (RSS 합 2.1~2.2GB) | PSS 기준 약 26배 |
waitUntil: load로 바꾸면 |
1페이지, 링크 0개 | 1페이지, 링크 0개 | JS가 링크를 그리는 페이지 → load만으론 부족(두 엔진 공통) |
| CLI fetch 단건 | example.com 0.12초, amiibo 0.29초, HN 0.28초 · 최대 RSS 24~26MB | — | 프로세스 기동부터 종료까지 |
| MCP stdio | goto 1.05초 → markdown 0.03초 → structuredData 0.01초 | — | 도구 32개, goto 기본 대기는 load |
| 사설망 차단 | 플래그 없이 127.0.0.1:8765 → HTTP 200 / --block-private-networks → 차단(연결 실패) |
— | 기본값은 허용 |
해석: 시간 차이(약 1.4배)가 README의 9배보다 훨씬 작은 건 이상한 일이 아닙니다. 이 테스트는 페이지마다 “500ms 동안 통신 없음”을 기다리는 networkidle0을 걸었고, 이 고정 대기 50번(최소 25초)이 양쪽 모두에 깔립니다. 그래서 엔진 자체의 차이는 나머지 15초 대 31초 구간에서 드러납니다. 반대로 메모리 차이는 PSS 기준 약 26배로 README의 16배보다 컸습니다. 다만 README는 실제 웹페이지 100개를 m5.large에서 잰 값이고, 저는 가벼운 데모 페이지 50개를 1탭으로 잰 값이라 배수를 그대로 비교하면 안 됩니다. 실무적 결론은 하나입니다. 같은 RAM에 띄울 수 있는 동시 세션 수가 한 자릿수가 아니라 두 자릿수 배로 달라진다는 점입니다. 크롤링 비용은 대개 CPU가 아니라 메모리가 정합니다.
테스트하지 못한 것도 있습니다. 소스 빌드(make test, WPT, end2end)는 Zig 0.17과 V8 빌드 시간 때문에 생략했고, agent 모드는 LLM API 키 없이 실행하지 않았습니다. 로그인·결제 같은 복잡한 실서비스 플로우의 호환성도 이번 범위 밖입니다. 호환성은 공식 WPT 결과 대시보드(perf.lightpanda.io/wpt)에서 매일 공개됩니다.
8. 비슷한 도구와 비교
| 기준 | Lightpanda | 헤드리스 Chrome (+Puppeteer/Playwright) | HTTP 클라이언트 + 파서 (requests·BeautifulSoup·trafilatura 등) | jsdom (Node) |
|---|---|---|---|---|
| JS 실행 | V8, 실제 이벤트 루프·XHR·fetch | 완전 | 없음 | 있음(Node 위 DOM 시뮬레이션, 네트워크·리소스 로딩은 제한적) |
| 픽셀 렌더링·스크린샷 | 텍스트 전용 렌더 | 완전 | 없음 | 없음 |
| 메모리(박스 실측, 50페이지) | PSS 27MB | PSS 704MB | 수 MB~수십 MB | (미측정) |
| 기존 자동화 코드 재사용 | CDP·BiDi 엔드포인트 교체(호환 범위 확인 필요) | 기준점 | 재작성 필요 | 별도 API |
| 에이전트 친화 기능 | 네이티브 MCP 32도구, markdown·semantic tree 덤프, agent, PandaScript | 별도 MCP 서버·프레임워크 필요 | 직접 구현 | 직접 구현 |
| 웹 호환성 | 빠르게 개선 중, 사이트별 편차 | 사실상 표준 | JS 의존 페이지 불가 | 중간 |
| 봇 식별 | UA에 Mozilla 금지, Web Bot Auth 지원 | 일반 브라우저와 구분 어려움 | 임의 UA | 임의 UA |
| 라이선스 | AGPL-3.0-only | BSD 계열(Chromium)·Apache-2.0(Puppeteer/Playwright) | 대체로 MIT·BSD·Apache | MIT |
요약하면 Lightpanda는 Chrome을 대체한다기보다, “JS는 필요하지만 픽셀은 필요 없는” 구간을 분리해 싸게 처리하는 도구입니다. 실패하는 사이트만 Chrome으로 넘기는 2단 폴백 구성이 가장 현실적입니다.
9. 보안·운영·라이선스 주의점
| 항목 | 기본 동작 (v1.0.2) | 권장 설정 |
|---|---|---|
| 텔레메트리 | ON. 실행·내비게이션(TLS 여부·컨텍스트)·LLM·도구 호출 통계 등을 telemetry.lightpanda.io/v2로 전송, 설치 ID(iid) 파일 생성 | LIGHTPANDA_DISABLE_TELEMETRY=true를 서비스 유닛·컨테이너 env에 고정 |
| robots.txt | 준수하지 않음 | --obey-robots, 레이트 리밋·--http-max-host-open(기본 6) 유지 |
| 사설망 접근 | 허용 (박스에서 127.0.0.1 200 응답 확인) | 에이전트가 임의 URL을 여는 구조라면 --block-private-networks + --block-cidrs 필수. 클라우드 메타데이터(169.254.169.254) 탈취 방지 |
| CDP·MCP 포트 | serve·mcp 도움말에 인증·토큰 옵션 없음 | 127.0.0.1 바인딩, --unix-socket(0600), 외부 노출 시 리버스 프록시에서 인증 |
| 스크립트·evaluate | PandaScript 안의 evaluate는 페이지에서 임의 JS 실행 (help run의 경고) | 남이 준 .js는 셸 스크립트처럼 검토. 비밀값은 $LP_* 플레이스홀더로만 전달(프로세스 내부에서 치환) |
| 프롬프트 인젝션 | agent·MCP가 읽는 페이지 텍스트는 신뢰할 수 없음 | 쓰기 동작(click·fill·submit)은 허용 도메인 제한, 사람 승인 단계 분리 |
| 라이선스 | AGPL-3.0-only | 내부 도구로 쓰는 건 문제없지만, 수정본을 네트워크 서비스로 제공하면 소스 공개 의무. SaaS 내장 전 법무 검토 |
10. 누가 지금 도입하면 좋은가
| 상황 | 판단 | 이유 |
|---|---|---|
| JS 렌더링이 필요한 대량 크롤링·모니터링 | 적극 검토 | 세션당 메모리가 수십 MB 수준 → 동시성·비용 개선 폭이 큼. Chrome 폴백과 같이 운영 |
| 코딩 에이전트·RAG에 “웹 읽기” 도구 붙이기 | 적극 검토 | MCP 한 줄 설정, markdown·clutter·semantic tree 덤프로 토큰 절감 |
| 반복 업무 자동화(LLM으로 탐색 → 스크립트로 운영) | 파일럿 | PandaScript로 운영 비용 0토큰. 대기 조건·셀렉터 유지보수는 여전히 사람 몫 |
| E2E UI 테스트·시각 회귀·스크린샷 기반 에이전트 | 보류 | 픽셀 렌더링이 없음. Playwright + Chrome이 맞음 |
| 강한 봇 탐지 사이트 우회 목적 | 비권장 | 설계상 봇임을 밝히는 브라우저(UA 정책·Web Bot Auth). 목적 자체가 어긋남 |
| 수정본을 SaaS로 재배포할 계획 | 법무 검토 후 | AGPL 의무 |
마무리: “에이전트용 브라우저”라는 범주가 생기고 있다
Lightpanda의 진짜 의미는 “Chrome보다 빠르다”는 벤치마크가 아닙니다. 브라우저의 사용자가 사람에서 기계로 바뀌면 무엇을 빼고 무엇을 넣어야 하는가에 대한 하나의 완결된 답이라는 데 있습니다. 픽셀은 빼고, markdown·semantic tree·MCP·스크립트 재생은 넣었습니다. 1.0이 나온 지 한 달, 릴리스 노트는 아직 웹 호환성 패치로 빼곡하고 기본값도 개발자 편의 쪽으로 열려 있습니다. 그래서 오늘 기준 권장은 이렇습니다. 텔레메트리 끄고, 사설망 막고, 로컬에 바인딩한 다음, Chrome 폴백을 둔 채 크롤링·에이전트 읽기 경로부터 옮겨 보시길 권합니다. 같은 서버에 세션을 몇 배 더 올릴 수 있다는 건 박스에서 직접 확인했습니다.