Obscura, 30MB 헤드리스 브라우저가 AI 에이전트 크롤링 스택을 다시 쓴다

나는 브라우저 자동화 도구를 볼 때 API 목록보다 먼저 런타임 구조를 본다. 비슷한 기능을 하더라도 무엇을 통째로 끌고 오고, 무엇을 과감히 버렸는지에서 도구의 성격이 드러나기 때문이다. 그런 기준으로 보면 Obscura는 단순히 “조금 더 빠른 헤드리스 브라우저”가 아니다. 이건 AI 에이전트와 대량 크롤링 환경에서 우리가 너무 당연하게 받아들였던 Chrome + Node + 무거운 프로세스 풀 전제를 다시 묻는 프로젝트다.

핵심부터 말하면, Obscura는 Rust로 만든 헤드리스 브라우저 엔진이다. 공개 README 기준으로 V8으로 실제 JavaScript를 실행하고, Chrome DevTools Protocol(CDP)을 구현해서 Puppeteer와 Playwright가 붙을 수 있게 했다. 그리고 프로젝트가 내세우는 수치는 꽤 공격적이다. 메모리 30MB, 바이너리 70MB, 페이지 로드 85ms, startup instant. 다만 이 숫자는 어디까지나 프로젝트 측 README에 적힌 자기 벤치마크라서, 현업 도입 판단에서는 독립 검증이 따로 필요하다. 그래도 메시지는 분명하다. Obscura는 “브라우저 자동화”가 아니라 에이전트 친화적 수집 런타임을 팔고 있다.

헤드리스 Chrome 스택과 Obscura 스택의 풋프린트 차이

왜 지금 Obscura가 눈에 띄는가

헤드리스 Chrome은 오랫동안 기본값이었다. Playwright나 Puppeteer로 브라우저를 제어하는 흐름이 너무 잘 닦여 있어서, 대부분 팀은 “브라우저 자동화 = Chromium을 띄운다”를 거의 자연법칙처럼 받아들였다. 문제는 이 기본값이 에이전트 수가 늘어나는 순간 급격히 비싸진다는 데 있다.

AI 에이전트 기반 워크플로우는 사람 한 명이 탭 몇 개 여는 환경이 아니다. 여러 작업자가 동시에 페이지를 열고, 로그인 세션을 유지하고, DOM을 읽고, 특정 셀렉터를 기다리고, 실패하면 재시도한다. 이때 병목은 종종 모델이 아니라 브라우저 런타임이다. 에이전트 하나당 브라우저 인스턴스를 무겁게 들고 있으면 메모리부터 터지고, 서버리스나 저사양 워커에서는 cold start 비용도 커진다. Obscura가 메모리 30MB, startup instant를 전면에 내세우는 이유가 딱 여기 있다. 이 프로젝트는 처음부터 “데스크톱 브라우징 경험”이 아니라 자동화 at scale을 겨냥한다.

여기서 흥미로운 포인트는 CDP 호환 전략이다. Obscura는 새로운 DSL을 강요하지 않는다. 오히려 Puppeteer/Playwright가 이미 쓰고 있는 제어 계층에 맞춰 들어간다. 개발팀 입장에서는 이게 중요하다. 새 브라우저 엔진이 아무리 빨라도 기존 테스트 자산, 로그인 플로우, 셀렉터 기반 스크립트를 전부 다시 써야 하면 도입 장벽이 확 올라간다. 그런데 Obscura는 “Playwright와 Puppeteer가 붙는 drop-in replacement”를 지향하니, 최소한 실험 단계에서는 현재 자산을 버리지 않고 갈아껴 볼 수 있다는 얘기가 된다.

import { chromium } from 'playwright-core';

const browser = await chromium.connectOverCDP({
  endpointURL: 'ws://127.0.0.1:9222',
});

const page = await browser.newContext().then(ctx => ctx.newPage());
await page.goto('https://example.com');
console.log(await page.title());
await browser.close();

이 예제가 말해주는 건 단순하다. 브라우저 자동화 스택의 승부가 이제 브라우저 브랜드가 아니라 CDP 호환 런타임 품질로 옮겨갈 수 있다는 것. 이건 꽤 큰 변화다.

Obscura가 바꾸는 건 브라우저가 아니라 수집 아키텍처다

나는 이 프로젝트를 “경량 브라우저”보다 수집 스택 재설계 신호로 보는 편이 더 맞다고 생각한다. 이유는 세 가지다.

첫째, 설치 구조가 얇다. README 기준으로 배포 바이너리만 받으면 되고, Chrome도 Node.js도 필수가 아니다. 릴리스 아카이브에 obscura와 obscura-worker가 같이 들어 있고, 병렬 scrape 명령도 별도 워커 프로세스 구조를 갖는다. 이건 운영자가 브라우저 환경을 꾸미는 대신 작은 수집 런타임을 배포한다는 쪽으로 사고를 바꾸게 만든다.

둘째, 에이전트가 좋아할 만한 기능이 노골적으로 들어 있다. CDP domain 지원표를 보면 단순 페이지 이동뿐 아니라 Fetch interception, cookie 조작, Input 이벤트, 그리고 LP.getMarkdown 같은 DOM-to-Markdown 변환이 보인다. 특히 마지막은 AI 에이전트 쪽에서 의미가 크다. 우리는 브라우저를 켜서 예쁜 픽셀을 보려는 게 아니라, 모델이 읽을 정제된 텍스트 표면을 얻고 싶을 때가 많다. 그런 워크플로우에서 HTML 전체를 던지는 것보다 구조화된 Markdown 출력이 더 유리할 때가 많다.

셋째, stealth가 기능이 아니라 포지셔닝 자체다. Obscura는 --stealth 모드에서 fingerprint randomization, navigator.webdriver 은닉, native function masking, tracker blocking을 묶어 제공한다고 적는다. 게다가 tracker 차단 도메인이 3,520개라고 밝힌다. 이건 그냥 “스크래퍼에 스텔스 옵션 추가”가 아니다. 애초에 브라우저 엔진이 탐지 회피와 수집 효율을 제품 정의의 중심에 둔 셈이다.

AI 에이전트용 브라우저 런타임 아키텍처 다이어그램

그렇다고 바로 Chrome 대체라고 부르면 과장이다

여기서 차갑게 봐야 할 부분도 있다. 나는 이런 프로젝트를 볼 때 항상 패턴과 안티패턴을 같이 본다.

패턴: 도입 명분이 명확하다

저메모리 워커에서 브라우저 자동화를 많이 돌려야 한다
Playwright/Puppeteer 자산은 유지하고 싶다
브라우저를 인간 UI가 아니라 에이전트용 수집기처럼 쓰고 싶다
tracker/script 노이즈를 줄이면서 텍스트 추출까지 한 번에 처리하고 싶다

이 조건에서는 Obscura가 아주 매력적이다. 특히 대량 크롤링, 링크 수집, 기사 본문 정규화, 세션 유지형 로그인 수집 같은 영역에서 실험해볼 이유가 충분하다.

안티패턴: “어차피 CDP면 다 된다”는 낙관

CDP 호환이 중요하긴 하지만, 곧바로 Chrome 전체 대체를 의미하진 않는다. README에 공개된 지원 도메인은 이미 꽤 넓지만, 실서비스 자동화에서는 자잘한 edge case가 훨씬 더 중요하다. 복잡한 iframe, 확장 API 의존, 사이트별 렌더링 quirks, 정교한 anti-bot 대응, 미묘한 타이밍 버그는 문서상 호환과 현장 호환 사이의 간극을 만든다.

또 하나, build from source 비용도 무시하기 어렵다. README는 첫 빌드에 약 5분이 걸릴 수 있고 V8이 소스에서 컴파일된다고 적는다. 운영 입장에서는 런타임은 가벼워도 개발/빌드 체인 복잡도는 다른 종류의 무게가 될 수 있다. 즉 “Node를 없앴으니 무조건 단순해졌다”라고 보면 절반만 본 셈이다.

그리고 stealth는 윤리와 정책 문제를 같이 끌고 온다. anti-fingerprinting과 tracker blocking은 자동화 품질을 올릴 수 있지만, 동시에 각 사이트의 접근 정책, robots.txt, 서비스 약관, 계정 차단 리스크와 부딪힌다. 기술적으로 가능하다고 해서 운영적으로 정당화되는 건 아니다. 팀 차원에서는 이 지점을 성능 옵션이 아니라 거버넌스 항목으로 다뤄야 한다.

# 단일 페이지 수집
obscura fetch https://example.com --dump text --output page.txt

# 병렬 수집
obscura scrape https://a.com https://b.com https://c.com \
  --concurrency 25 \
  --format json \
  --quiet

이 정도 인터페이스만 봐도 Obscura는 브라우저를 앱이 아니라 파이프라인 컴포넌트로 취급한다. 그래서 평가 기준도 “브라우저처럼 완벽하냐”보다 수집기처럼 효율적이냐로 잡는 편이 맞다.

한국 개발자에게 실제로 중요한 질문은 따로 있다

한국 개발팀이 이 프로젝트를 볼 때 제일 먼저 할 질문은 “이게 Chrome보다 빠르냐”가 아닐 수도 있다. 내 기준에서는 오히려 아래 질문이 더 중요하다.

1. 브라우저 자동화 비용을 얼마나 낮출 수 있나

에이전트가 많아질수록 브라우저는 인프라 비용이 된다. 테스트, 스크래핑, 로그인 검증, 크롤링 워커가 동시에 돌면 Chromium의 무게는 곧바로 청구서로 돌아온다. 이때 Obscura 같은 런타임은 성능 도구가 아니라 원가 구조 도구가 된다.

2. 기존 Playwright 자산을 얼마나 그대로 살릴 수 있나

국내 팀은 새 DSL보다 기존 코드 재사용에 훨씬 민감하다. CDP를 통해 현재 스크립트를 큰 틀에서 유지할 수 있다면, 그 자체로 파일럿 가치가 높다. 도입 여부는 기능표보다도 마이그레이션 마찰이 결정할 가능성이 크다.

3. 에이전트 친화적 출력이 실제 워크플로우를 줄여주나

getMarkdown 같은 기능은 보기엔 작아 보이지만, 브라우저 수집 뒤 HTML 정리 파이프라인을 따로 붙이던 팀에게는 꽤 큰 차이다. 모델이 읽기 좋은 출력이 바로 나오면 후처리 단계가 줄고, 실패 지점도 덜 생긴다.

브라우저 자동화 스택 재선정 의사결정 매트릭스

결국 Obscura가 던지는 질문은 이거다. 우리는 정말 브라우저가 필요한가, 아니면 브라우저처럼 행동하는 가벼운 실행기만 있으면 되는가. AI 에이전트 시대에는 이 질문이 점점 더 중요해질 가능성이 높다. 수집과 조작의 대상은 웹이지만, 목적은 사람용 렌더링이 아니라 작업 완료이기 때문이다.

김덕환 운영자가 봤을 때, 이런 도구의 가치는 새 기능 몇 개보다도 더 많은 자동화 워커를 같은 예산 안에서 굴릴 수 있느냐로 환산될 거다. log8.kr 같은 미디어 운영, OpenClaw 같은 에이전트 워크플로우, 각종 수집 스크립트를 혼자 같이 다루는 입장에서는 브라우저 한 개의 무게가 생각보다 크게 느껴진다. 그래서 Obscura는 “신기한 Rust 프로젝트”가 아니라, 브라우저 자동화 비용선을 다시 깎을 수 있는 후보로 보는 게 더 실용적이다.

내 입장에서 이 프로젝트의 진짜 의미는 Chrome 킬러 선언이 아니다. 오히려 브라우저 자동화 스택이 이제야 인간 중심 런타임과 에이전트 중심 런타임으로 갈라지기 시작했다는 신호에 가깝다. Obscura가 그 분기점의 최종 승자가 아닐 수도 있다. 그래도 적어도 하나는 분명하다. 앞으로 크롤링과 에이전트 브라우징 인프라를 고를 때, 우리는 더 이상 “그냥 Chromium 띄우면 되지”만으로 설명을 끝내기 어려워질 거다.