Obscura란 무엇인가? AI 에이전트를 위한 Rust 기반 헤드리스 브라우저

Obscura는 2026년 4월 GitHub에 출시되었으며, 5개월 만에 24,624개의 스타를 모았습니다. Cloudflare의 엔지니어링 팀은 이를 자체 에이전트 브라우저의 시작점으로 언급했으며, 이 프로젝트는 이미 관리형 버전을 광고하고 있습니다. 실제로 Obscura가 무엇을 하는지, 제가 직접 실행했을 때 수치가 어땠는지, 그리고 어떤 상황에서 헤드리스 Chrome을 진정으로 대체하는지에 대해 설명합니다.

핵심 요약

• Obscura는 Apache-2.0 라이선스로 작성된 Rust 기반의 헤드리스 브라우저 엔진입니다. V8에서 JavaScript를 실행하고 Chrome DevTools Protocol을 사용합니다.
• Playwright와 Puppeteer는 코드 변경 없이 연결됩니다. connectOverCDP를 obscura serve가 열어주는 포트에 지정하기만 하면 됩니다.
• 재현 가능한 장점은 메모리입니다. 제 테스트에서는 동일한 페이지에 대해 헤드리스 Chromium이 532 MB를 사용한 반면, Obscura는 약 38 MB를 사용했습니다.
• 속도상의 이점은 페이지에 따라 다릅니다. 정적 HTML에서는 명확하지만, 네트워크 지연 시간이 지배적인 실제 웹사이트에서는 그 차이가 없습니다.
• 버전 0.2.0 (2026년 8월) 이후로는 Chromium 없이 렌더링 및 캡처가 가능해졌지만, 아직 Chromium과 완전히 일치하지는 않으며, 저는 이 점을 첫 페이지에서 확인했습니다.

Obscura란 무엇이며 어떤 문제를 해결하는가

Obscura는 그래픽 인터페이스가 없는 브라우저 엔진으로, Rust로 처음부터 작성되었습니다. 이는 Chromium 포크나 WebKit 패치가 아닙니다. Obscura는 V8을 임베드하여 페이지의 JavaScript를 실행하고, 자체 DOM을 구축하며, Chrome DevTools Protocol을 노출하여 기존 자동화 도구들이 마치 Chrome인 것처럼 취급하게 만듭니다. 공식 문서는 다음과 같이 정의합니다: [

에이전트 무리가 수천 개의 동시 세션을 열 때, 모든 프로세스는 각 에이전트가 건드리지도 않은 컴포지터(compositor), 렌더링 스택(rendering stack) 및 수십 개의 서브시스템을 끌고 옵니다. 이 비용은 기가바이트 단위의 메모리와 초 단위의 시작 시간으로 지불됩니다. Obscura의 제안은 데이터를 읽는 데 필요한 부분만 유지하는 것입니다: JavaScript를 실행하고, DOM을 구축한 다음, 이를 반환하는 것입니다.

Cloudflare 연결 고리는 이 아이디어가 유효하다는 가장 강력한 신호입니다. Kitesurf 발표에서 Workers 기반 에이전트 브라우저에 대해 설명하면서 팀은 다음과 같이 작성했습니다: "우리는 AI 자동화를 위해 Rust로 작성된 헤드리스 엔진인 Obscura로부터 초기 영감을 얻었습니다. 이는 'Chrome도, Node.js도, 의존성도 없습니다.'". Cloudflare는 2026년 5월에 첫 번째 개념 증명으로 Obscura를 Workers로 포팅했으며, 그곳에서 제품을 구축했습니다. Kitesurf는 여전히 무료 베타의 Cloudflare 서비스이며, Obscura는 오늘 다운로드할 수 있는 엔진입니다.

작동 방식

이 바이너리는 세 가지 조각을 번들링합니다. 첫 번째는 Chrome이 사용하는 것과 동일한 JavaScript 엔진인 V8로, Rust 프로세스에 직접 임베드되어 있습니다. 두 번째는 현대 페이지가 필요로 하는 DOM 및 웹 API(web APIs)의 자체 구현입니다: fetch, XHR, observers, Shadow DOM, 사용자 정의 요소(custom elements), WebCrypto 등 나머지 부분들입니다. 세 번째는 CDP 서버로, Puppeteer 또는 Playwright 호출을 해당 DOM에 대한 작업으로 변환합니다.

2026년 8월 8일에 449개의 누적 커밋과 함께 출시된 버전 0.2.0 이후로는 네 번째 조각이 있습니다. 이는 Rust로 작성된 레이아웃 및 페인트 엔진(layout and paint engine)으로, Chromium을 시작하지 않고도 스크린샷, 화면 녹화(screencasting), PDF 내보내기(PDF export)를 가능하게 합니다. 8월 23일의 버전 0.2.1에서는 자식 iframe을 위한 전용 V8 realm이 추가되었습니다.

설치에는 Node.js나 Chrome이 필요하지 않습니다. 이 프로젝트는 Linux, macOS 및 Windows용 바이너리를 제공하며, 렌더링 유무와 스테일스 모드(stealth mode) 유무에 따른 변형과 함께, 45,789회의 풀을 기록한 Docker Hub의 공식 이미지도 제공합니다.

Stealth 모드는 별도의 빌드 변형(build variant)입니다. 프로젝트의 README에 따르면 이 모드는 세션마다 GPU, 화면, 캔버스, 오디오 및 배터리 지문(fingerprint)을 무작위화하고, navigator.webdriver를 정의하지 않으며, 3,520개의 추적 도메인(tracking domains)을 차단합니다. 이는 제3자가 제시한 수치가 아니라 프로젝트 자체의 수치입니다.

또한 이 모드는 어시스턴트가 직접 호출할 수 있는 14가지 브라우저 도구를 갖춘 임베디드 Model Context Protocol (MCP) 서버를 함께 제공합니다. 만약 이전에 자신만의 서버를 구축해 본 경험이 있다면, 완벽한 MCP 가이드에서 해당 프로토콜의 맥락을 확인할 수 있습니다.

직접 제 기계에서 실행했을 때 무슨 일이 일어났나

저는 2026년 9월 4일에 v0.2.1 버전의 aarch64-linux 변형을 다운로드하여 ARM64 Linux 컨테이너에서 실행했으며, 프로세스 트리 전체에 걸쳐 벽 시간(wall time)과 최대 상주 메모리(peak resident memory)를 측정했습니다. 이에 맞서 Playwright로 구동되는 헤드리스 Chromium을 동일한 URL과 동일한 네트워크 환경에서 테스트했습니다. 각 조합당 3회씩 테스트를 진행했습니다.

이 수치들을 솔직하게 읽어보면 두 가지 측면이 있습니다. 메모리 면에서의 이점은 엄청나며 확실합니다. 실제 페이지의 경우 대략 13배 적게 사용됩니다.

속도상의 이점은 페이지가 정적인 500바이트 파일인 상태를 벗어나자마자 사라집니다. Hacker News의 경우, Chromium이 오히려 약간 더 빨랐는데, 그 이유는 중앙값(median)을 지배하는 것이 엔진 자체가 아니라 네트워크이기 때문입니다. --wait 옵션을 0으로 설정해도 아무 변화가 없었습니다.

프로젝트 자체의 벤치마크 저장소 역시 더 많은 데이터를 통해 같은 결론에 도달했습니다. 총 98개의 실제 공개 페이지 코퍼스에서 Obscura는 94개 페이지를 렌더링한 반면, 헤드리스 Chrome은 85개 페이지를 렌더링했습니다. 중앙값 메모리는 Obscura가 64.2 MB로, Chrome의 201.2 MB보다 적었지만, 중앙값 지연 시간(latency)은 Obscura가 5.2초로, Chrome의 2.1초보다 길었습니다. 실제로 카드가 떨어지는 방식이 이렇습니다.

Playwright 호환성은 문자 그대로였습니다. 아무것도 건드리지 않고 obscura serve --port 9333을 실행하고 chromium.connectOverCDP('ws://127.0.0.1:9333')으로 연결했을 때, 내비게이션(navigation), page.title(), 그리고 page.evaluate() 모두 100밀리초 만에 응답했습니다.

그런 다음 Tailwind 기반의 WordPress 사이트 첫 페이지에서 새로운 렌더링 경로를 시도해 보았습니다. 캡처는 587밀리초가 걸렸고 유효한 PNG 이미지를 생성했지만, Chromium과는 명확히 다른 부분이 있었습니다.

Side-by-side comparison of the same page rendered by Obscura and by headless Chromium, where Obscura paints tooltips visible that the CSS declares with zero opacity.

가장 구체적인 차이점은 다음과 같습니다: 해당 테마는 내비게이션 바 레이블을 content: attr(data-tooltip)와 opacity: 0를 가진 ::after 가상 요소(pseudo-elements)로 선언하고, 이는 호버 시에만 보이도록 되어 있습니다. Obscura는 이 가상 요소를 그렸지만 투명도(opacity)를 무시했기 때문에 헤더가 겹치는 레이블들로 뒤덮여 나타났습니다. 검색 패널 역시 열린 상태로 렌더링되었고, 쿠키 알림은 누락되었습니다. 이는 프로젝트가 출시 노트에서 언급하는 바로 그 종류의 격차이며, 제가 첫 페이지에 넣어 테스트했을 때 발견한 것입니다.

헤드리스 Chrome 및 Lightpanda와의 비교

이 솔루션들에는 네 가지 계열이 있으며, 각각 다른 문제를 해결하기 때문에 이들을 구분할 가치가 있습니다. GitHub 기준 2026년 9월 4일.

Lightpanda는 AGPL-3.0을 사용하는데, 이는 네트워크를 통해 노출되는 모든 서비스에 전파됩니다. 반면 Obscura는 Apache-2.0을 사용하여 그렇지 않습니다. 만약 폐쇄된 제품에 임베드할 계획이라면, LICENSE 파일의 이 한 줄이 어떤 벤치마크보다 더 중요합니다.

Steel Browser와 Browserless는 Obscura와 경쟁하지 않습니다. 그들은 Chromium을 큐(queues), 세션 및 API로 감싸는 방식입니다. 이들은 비용당 세션(cost per session) 문제가 아니라, 작업(operations) 자체를 해결합니다. Browserless 역시 오픈 소스가 아니며, 비상업적 용도로만 무료입니다.

그 외에도 이미 브라우저를 구동하는 에이전트 생태계가 있습니다. 만약 여러분이 스스로 웹을 탐색하는 에이전트를 원한다면, Browser Use가 한 단계 높은 곳에서 작동합니다. 만약 깨끗한 웹 데이터를 원한다면, Firecrawl이 추출 작업을 대신 수행해 줍니다. Obscura는 이 모든 것의 아래에 위치하며, 엔진 대체재 역할을 합니다.

아직 잘 처리하지 못하는 부분들

렌더링 경로는 한 달도 채 되지 않은 역사를 가지고 있어 Chromium 수준에 도달하지 못했습니다. v0.2.0 노트에서 명확하게 언급했듯이, 긴 꼬리 CSS(long-tail CSS), 일부 웹 API, 네이티브 미디어 재생 및 GPU 컴포지터 효과 등은 여전히 다를 수 있습니다. 저의 테스트로도 첫 시도에 이 점을 확인했습니다. 또한 PDF 출력물 역시 라스터 기반이기 때문에 텍스트 선택이 불가능합니다.

규격 준수(Conformance)도 완전하지 않습니다. 벤치마크 저장소는 Web Platform Tests 코어 티어에서 83.3%의 서브테스트 통과율(382,891개 중 318,916개)을, 전체 스위트에서는 60.0%를 기록합니다. 이 60%는 숨겨진 결함이 아니라, 플랫폼의 전체 레이어를 의도적으로 구현하지 않은 결과이며, 프로젝트에서 이를 문서화하고 있습니다.

README의 수치는 오래되었습니다. README에는 70 MB 바이너리가 광고되어 있지만, 제가 다운로드한 렌더링이 적용된 ARM64 빌드는 압축 해제 시 100 MB가 필요하고, 작업자 프로세스(worker process)에만 추가로 92 MB가 더 필요합니다. Docker 이미지는 0.1.11 버전에서 53.2 MB였는데, 0.2.1 버전에서는 87.1 MB로 늘어났습니다. 이 모든 것이 심각한 문제는 아니지만, 표를 인용하기 전에 반드시 사용자의 플랫폼에서 직접 측정해 보십시오.

이 프로젝트는 비교적 새롭고 집중도가 높습니다. 2026년 4월 13일에 생성되었으며, GitHub API가 나열하는 20명의 기여자 중 단 한 명이 733개의 커밋을 담당했습니다. Stealth 모드는 자동화 신호를 줄여주지만, IP 평판이나 행동 패턴에 기반한 차단(block)을 막아주지는 못합니다. 그리고 관리형 버전인 Obscura Cloud는 아직 구매할 수 있는 제품이라기보다는 대기 목록 상태입니다.

언제 가치가 있고 언제 가치가 없는가

이것은 청구서가 메모리 비용일 때 가치가 있습니다. 데이터를 추출하기 위해 수백 또는 수천 개의 동시 세션(concurrent sessions)을 실행하는 경우, 세션당 500 MB에서 38 MB로 줄어드는 것은 어떤 코드 최적화도 따라잡을 수 없는 방식으로 머신 사이즈를 변경합니다. 또한 Node.js나 Chrome 없이 작은 이미지 안에 브라우저를 패키징하고 싶거나, 진정으로 깨끗하고 재현 가능한 세션이 필요할 때도 가치가 있습니다.

하지만 작업량이 몇십 페이지에 불과하고 이미 작동하는 경우에는 가치가 없습니다. 실제 사이트에서 페이지당 지연 시간(latency) 개선은 0이거나 마이너스이며, 성숙한 엔진을 5개월 된 엔진으로 교체하게 됩니다. 또한 시각적 충실도(visual fidelity)에 의존한다면 가치가 없습니다. 시각적 회귀 테스트(visual regression testing), 클라이언트 대상 캡처 등 픽셀 하나하나가 중요한 모든 것은 여전히 Chromium의 영역입니다. 그리고 문제가 차단되는 것이라면, 엔진이 해결책이 아닙니다. 프록시와 요청 간격 조절(request pacing)이 핵심입니다.

실질적인 조언을 드리자면: 기존의 헤드리스 Chrome과 나란히 실행해 보세요. obscura serve를 시작하고, 트래픽의 일정 비율을 이쪽으로 연결(connectOverCDP)한 다음, 일주일 동안 여러분이 목표로 하는 페이지에서 결과를 비교해 보세요. 환경 변수만 하나 변경하면 되므로 실험 비용이 저렴합니다. 만약 그 아래에 깔린 언어에 대해 궁금하다면, Axum 및 Tokio를 사용한 백엔드 작업용 Rust을 참고하면 왜 이러한 종류의 프로젝트가 이런 방식으로 작성되는지에 대한 배경 지식을 얻을 수 있습니다.

자주 묻는 질문 (FAQ)

Obscura가 Playwright나 Puppeteer를 대체하나요?

아닙니다. 상호 보완적입니다. Playwright와 Puppeteer는 자동화 스크립트를 작성하는 라이브러리이며, Obscura는 그 스크립트가 구동하는 브라우저 자체입니다. 기존의 Playwright 코드는 그대로 유지하고, 연결 대상만 라이브러리에 의해 실행되는 Chromium에서 CDP를 통해 수신 대기하는 obscura serve로 변경하면 됩니다.

폐쇄적인 상업 제품에 Obscura를 사용할 수 있나요?

네. 라이선스는 Apache-2.0이며, 이는 상업적 사용을 허가하고 독점 소프트웨어에 통합할 수 있게 하지만 코드를 공개해야 할 의무는 없습니다. 이것이 AGPL-3.0을 사용하여 임베드된 네트워크 서비스의 소스 코드 공개를 요구하는 Lightpanda와 가장 실질적인 차이점입니다.

Obscura가 신뢰할 수 있는 스크린샷에 충분한가요?