moli 딥다이브
— 웹의 구조를 읽고, 화면은 필요할 때만 그린다

1프로젝트 한줄 요약

moli는 AI 에이전트가 웹페이지를 읽고 조작하도록 만든, 화면 없는 독립형 브라우저입니다. HTML을 가져오는 데서 끝나지 않고 JavaScript를 실행하고 DOM을 갱신하며, 쿠키·스토리지·네트워크 요청과 자동화 명령을 처리합니다. Chromium 프로세스를 감싼 래퍼가 아니라, V8·html5ever·Stylo 같은 부품을 조립한 별도의 브라우저 커널입니다.

moli의 핵심은 브라우저 기능을 없애는 것이 아니라, 요청에 필요하지 않은 레이아웃과 페인트 작업을 미루는 데 있습니다. 페이지 제목이나 본문을 읽는 작업과 스크린샷을 찍는 작업을 같은 비용으로 취급하지 않습니다.

한 프로그램에 들어 있는 두 가지 사용 경로

아래는 README와 CLI 정의에 따른 사용 예시입니다. moli 실행 파일이 설치된 환경에서 사용할 수 있으며, 스크린샷은 리디렉션으로 PNG 파일에 저장합니다.

# 본문을 Markdown으로 추출한다.
moli fetch --dump markdown --wait-until done https://example.com

# 모델이 읽기 쉬운 시맨틱 텍스트 트리를 얻는다.
moli fetch --dump semantic_tree_text --wait-selector body https://example.com

# 시각 출력에는 --layout을 명시한다.
moli fetch --layout --dump screenshot https://example.com > page.png

# 기존 자동화 클라이언트가 연결할 서버를 연다.
moli serve --layout

2왜 주목받는가

2-1. 자동화의 결과물이 꼭 이미지일 필요는 없다

상품명 수집, 문서 요약용 본문 추출, 폼 입력 확인에는 페이지의 구조와 실행 결과가 중요합니다. moli는 이런 작업에 Markdown과 시맨틱 트리를 직접 제공하고, 필요하면 같은 런타임에서 좌표와 스크린샷도 제공합니다. 기능을 두 제품으로 나누지 않고 비용이 큰 단계를 옵션으로 만든 점이 관심을 끌 만합니다.

이는 설계와 사용 사례에서 도출한 해석입니다. TrendShift Monthly #9는 2026-10-23 기준 순위이며, 스타 수는 같은 날짜 GitHub 기준입니다. 순위와 스타 수만으로 특정 기능이 인기의 원인이라고 단정할 수는 없습니다.

2-2. 기존 자동화 도구와 연결하는 세 가지 언어

CLI 외에 CDP, WebDriver Classic, WebDriver BiDi를 한 서버에서 제공합니다. 소스의 build_router()에는 CDP 탐색용 /json/version, CDP WebSocket 경로, WebDriver의 /session 경로가 함께 등록되어 있습니다. 프로토콜 지원은 클라이언트를 새로 만들 필요를 줄입니다.

2-3. 경쟁 도구와 비교할 때 보는 세 가지 축

2-4. README 수치는 어떤 실험의 결과인가

다음은 README.md의 192개 공개 URL 크롤링 실험을 옮긴 것입니다. 프로젝트 측은 JavaScript 실행 뒤 의미 있는 본문이 나와야 성공으로 계산했다고 설명합니다. 아래 표는 프로젝트 측 측정 결과이며, 측정 환경과 성공 판정 조건을 함께 봐야 합니다.

성능 비교에서는 “몇 배 빠르다”보다, 같은 입력에서 무엇을 성공으로 세고 어떤 작업을 생략했는지를 먼저 봐야 합니다. 위 표에서 moli와 Chrome의 시간 중앙값은 같습니다. 가벼운 메모리 사용이 모든 페이지의 더 빠른 완료를 뜻하지는 않습니다.

3기술 스택 전체 지도

루트 Cargo.toml에는 91개 workspace 멤버가 있습니다. 실행 파일은 moli이고, DOM·파서·네트워크·레이아웃·저장소가 작은 Rust crate로 분리되어 있습니다. 여기서 백엔드는 일반 웹 서비스의 업무 서버가 아니라 브라우저 커널과 자동화 서버를 뜻합니다.

3-1. 백엔드: Rust 위에 얹힌 브라우저 부품

실제로 V8은 vendor/v8-152.2.0으로, Stylo는 Git 리비전 2fe93b2로, Taffy는 0a33787로 대체됩니다. Parley도 a18cfc3 포크를 씁니다. 따라서 “이 버전의 공식 문서만 보면 똑같이 재현된다”는 가정은 피해야 합니다.

3-2. 프론트엔드: 제품 화면 대신 호환성 시험 페이지

moli-frontend-smoke/package.json에는 React·Vue·Angular가 함께 있습니다. 이들은 moli 관리 화면의 프레임워크가 아니라, moli가 실제 프레임워크 페이지를 제대로 실행하는지 확인하는 입력입니다. README는 독립 페이지 1,020개의 DOM 시간선을 Chromium과 대조한다고 설명합니다. 시각적 일치 시험과는 구분합니다.

3-3. 인프라·빌드: 재현 가능한 버전과 회귀 비교

.github/workflows/ci.yml은 Rust 1.96.1 컨테이너에서 포맷·Clippy 검사를 하고, nextest, CDP, WebDriver, 프론트엔드 차등 시험, 연속 탐색 시험 등을 별도 작업으로 나눕니다. 성능 비교의 base/head 실행 순서를 번갈아 정하는 코드도 있어, 항상 먼저 실행한 쪽만 유리해지는 영향을 줄이려 합니다.

.github/workflows/release.yml은 Linux·macOS·Windows의 x86_64와 aarch64를 대상으로 패키지를 만듭니다. scripts/release.py는 빌드·심볼 제거·버전 확인·압축을 담당합니다. 저장소에는 Dockerfile이 없으며, CI에서는 Rust 컨테이너 이미지를 사용합니다.

# 루트 Cargo.toml의 release 설정 발췌
[profile.release]
panic = "abort"
strip = false
codegen-units = 1

strip = false와 릴리스 스크립트의 심볼 제거는 모순이 아닙니다. Cargo 컴파일 단계와 배포 패키징 단계가 다릅니다. panic = "abort"는 panic 시 프로세스를 종료하는 정책이며, 모든 실패를 Rust의 Result 오류처럼 복구할 수 있다는 뜻이 아닙니다.

의존성 목록을 읽을 때는 “무엇을 쓰는가”와 함께, 제품 실행·시험·배포 중 어느 단계에 쓰는지를 구분해야 합니다.

4아키텍처 심화 분석

아래 구조도는 모듈의 책임을 요약한 그림입니다. 모든 화살표가 하나의 직접 함수 호출을 뜻하지는 않습니다. 특히 서버와 렌더러 사이에는 채널·명령·응답·이벤트를 중재하는 스케줄러가 있습니다.

사용자 / AI 에이전트
  |
  +-- CLI: fetch ---------------------------+
  |     moli/src/ (CLI · 설정 · 실행 진입)     |
  |                                         v
  +-- Playwright / Puppeteer / Selenium   moli-core
        |                                공개 API · 탐색 · Page
        v                                     |
   moli-protocol-server                       |
   Axum HTTP / WebSocket                      |
        |                                     |
   CDP / WebDriver Classic / BiDi              |
        |                                     |
   공통 AutomationCommand + 스케줄러 ---------+
                                              v
                        moli-renderer-v8
                        소유자 실행 영역 · V8 · 이벤트 / 작업 큐
                         |          |                 |
                         v          v                 v
                    moli-parser   네이티브 DOM      moli-fetch
                    html5ever     + Stylo CSS       / moli-curl
                         |          ^                 |
                         +----------+                 +-- 웹 서버
                                    |
                +-------------------+--------------------+
                |                                        |
          구조를 읽는 요청                         시각 정보를 요구하는 요청
          HTML / Markdown                          --layout: OnDemand
          시맨틱 트리 / DOM 조회                         |
                |                                        v
          출력 직렬화                         moli-layout: Taffy + Parley
                                                |                 |
                                      FrozenLayoutTree      일시 PaintSnapshot
                                      최신 기하 정보         moli-paint
                                                                |
                                                          PNG / PDF 등

초보자는 “프로토콜 서버가 HTTP를 받는다”와 “브라우저가 웹사이트로 HTTP를 보낸다”를 구분해야 합니다. 앞의 서버는 자동화 명령의 입구이고, 뒤의 moli-fetch·moli-curl은 페이지 리소스를 가져오는 출구입니다.

4-1. 패턴 ① 원본 상태 하나와 필요할 때 만드는 투영

원본은 네이티브 DOM과 Stylo 스타일 상태입니다. 레이아웃은 이 원본에서 만든 별도의 계산 결과입니다. moli-renderer-v8/src/layout_renderer/mod.rs의 build_native_layout_pass()는 DOM을 읽는 어댑터와 스타일 해석기를 조립해 레이아웃 백엔드에 전달합니다.

moli-layout/src/layout_tree/pass_result.rs의 LayoutPassResult에는 고정된 트리, 진단, 시간 측정값, 선택적인 페인트 스냅샷이 들어 있습니다. 하지만 장기간 보관 경계로 넘어가는 것은 FrozenLayoutTree입니다. 현재 문서의 글꼴 서비스 같은 부가 상태까지 모두 없어진다는 뜻은 아닙니다.

moli-renderer-v8/src/native_bridge/context_host/layout_snapshot.rs의 LatestLayoutTreeCache는 여러 버전의 트리를 쌓아 두지 않고 최신 성공 결과 하나를 담습니다. publish()의 핵심은 단순한 교체입니다.

// LatestLayoutTreeCache::publish() 본문 발췌
self.latest = Some(LatestFrozenLayout {
    document,
    tree: Box::new(tree),
});

여기서 Box는 트리를 힙에 보관하고 소유권을 넘기는 Rust 자료형입니다. 새 결과로 대입되면 이전 값은 소유권 규칙에 따라 정리됩니다. “캐시를 무제한 늘리지 않는다”는 정책이 자료구조에서 드러납니다.

이 지점에서는 주석보다 구현을 끝까지 읽는 연습이 유익합니다. LayoutPolicy::OnDemand의 짧은 주석은 출력 중심으로 설명하지만, 실제 ensure_initial_layout()에는 최초 기하 조회가 레이아웃을 만드는 경로가 있습니다. README의 “최초 기하 요청” 설명은 이 구현과 맞습니다.

스크린캐스트도 화면을 계속 그려 보관하는 구조가 아닙니다. moli-protocol-server/src/cdp_scheduler.rs의 PageScreencastSchedule은 known_visual_state를 기억하고, 렌더러의 visual_state_token()은 문서·DOM·스타일·리소스 등의 세대 정보를 조합합니다. README에 따르면 변화가 없는 폴링은 프레임 생성을 생략합니다. 토큰 자체는 그림 데이터가 아닙니다.

4-2. 패턴 ② 프로토콜 어댑터와 타입이 있는 공통 명령

외부 클라이언트마다 명령 형식이 다르더라도 브라우저의 “탐색”, “평가”, “스크린샷” 동작까지 각각 세 번 만들 필요는 없습니다. moli-protocol/src/automation.rs의 AutomationCommand는 Navigate, EvaluateScript, CaptureScreenshot 같은 공통 명령을 열거합니다.

// AutomationCommand의 일부만 남긴 학습용 발췌
pub enum AutomationCommand {
    Navigate(DevToolsNavigateCommand),
    EvaluateScript(DevToolsEvaluateScriptCommand),
    CaptureScreenshot(DevToolsCaptureScreenshotCommand),
    PrintToPdf(DevToolsPrintToPdfCommand),
}

각 변형은 해당 명령의 자료형을 함께 운반합니다. 문자열 하나에 매개변수를 뒤섞는 대신 컴파일러가 명령 종류와 데이터의 조합을 확인하도록 한 것입니다. 실제 enum에는 훨씬 많은 명령이 있습니다.

moli-protocol-server/src/protocol_server/mod.rs의 build_router()는 외부 경로를 등록하고, moli-protocol-server/src/cdp_scheduler/adapter_scheduler.rs의 ProtocolAdapterScheduler는 어댑터의 실행을 중재합니다. 내부 명령과 외부 응답 표현을 나누면, 프로토콜이 늘어날 때 엔진의 핵심 동작을 공유할 수 있습니다.

4-3. 패턴 ③ 상태 소유자에게 메시지를 보내고 실행 순서를 통제

moli-renderer-v8/src/render_runtime.rs의 RenderRuntimeOwner::spawn()은 render_runtime이라는 스레드와 current-thread Tokio 런타임을 만들고, 채널에서 렌더러 명령을 받습니다. 아무 스레드나 V8과 문서를 직접 바꾸게 두지 않고, 소유자의 실행 영역으로 일을 보냅니다.

moli-local-executor/src/executor.rs의 JsLocalExecutor::run()도 같은 관점을 보여 줍니다. 이미 같은 실행 영역 안이면 바로 진행하고, 아니면 owner_lane.lock().await로 잠근 뒤 영역을 표시합니다. 이 실행기는 진입을 직렬화하는 도구이며, 그것만으로 모든 작업을 특정 OS 스레드에 옮기는 기능이라고 해석하면 안 됩니다.

외부 작업 A ---+
외부 작업 B ---+--> 명령 채널 --> 상태 소유자 --> V8 / DOM 변경
네트워크 완료 -+                       |
                                      +--> 이벤트 · 명령 결과

같은 상태의 동시 변경을 줄이고,
“누가 먼저 바꾸고 무엇을 먼저 내보냈는가”를 한 지점에서 조정한다.

서버 쪽 moli-protocol-server/src/cdp_scheduler/actor.rs는 진행 중 명령, 뒤로 미뤄진 응답, 백그라운드 이벤트를 함께 관리합니다. queue_ready_background_inputs_before_runtime_response()는 JavaScript 실행 중 준비된 이벤트를 Runtime 응답보다 앞에 두되, 유한한 묶음을 만들어 응답이 끝없이 밀리지 않도록 합니다.

moli-owner-queue/src/owner_task_source.rs의 enqueue_local()은 뒤에, enqueue_parser_boundary_local()은 앞에 작업을 넣습니다. 따라서 큐가 있다고 “모든 작업이 엄격한 선입선출”이라고 단정할 수 없습니다. 예외적인 우선순위도 실행 계약입니다.

4-4. 패턴 ④ 파싱을 한 번에 끝내지 않는 상태 기계

HTML을 읽는 동안 스크립트가 DOM을 바꾸거나 추가 입력을 만들 수 있습니다. moli-parser/src/stream.rs의 pump_parser_step()은 입력을 진행시키고, 내부 RawParserStep은 스크립트·차단 스타일시트·사용자 정의 요소·입력 소진 등을 서로 다른 상태로 표현합니다.

// stream.rs의 내부 상태 enum 발췌
enum RawParserStep {
    OwnerInterrupted,
    Script(NativeNodeId),
    CustomElementConstruction,
    BlockingStylesheet(NativeNodeId),
    InputDrained,
}

ParserScriptPreparation::into_handoff()는 준비한 스크립트를 BlockingClassic, AsyncPostParse, NonAsyncPostParse, ImportMap 등의 실행 인계 형태로 바꿉니다. 파서는 “무엇을 발견했는가”를 알려 주고 실행 계층이 이어받습니다.

moli-parser/src/html.rs의 HtmlParser는 scripting 상태를 명시적으로 받습니다. 이 설정은 파싱 규칙에 영향을 주며, 파서가 JavaScript를 직접 실행한다는 의미는 아닙니다. “문법을 읽는 일”과 “읽은 작업을 실행하는 일”을 분리하는 사례입니다.

큰 시스템의 아키텍처는 폴더 이름보다, 상태의 주인과 계산 결과를 보관하는 경계를 따라갈 때 더 잘 보입니다.

5디렉토리 구조 해부

./                            저장소 루트
├── Cargo.toml · Cargo.lock   workspace 구성 · 의존성 선택 결과
├── rust-toolchain            Rust 1.96.1
├── moli/src/                 실행 파일 · CLI · 설정 · 출력
├── moli-core/src/            공개 API · Page · 탐색 · 저장 파티션
├── moli-protocol-server/src/ HTTP / WebSocket · 스케줄러 · 종료 관리
├── moli-protocol/src/        공통 자동화 명령 · CDP 도메인 · 연결 상태
├── moli-protocol-cdp/        CDP용 형식·메타데이터 등
├── moli-protocol-webdriver-classic/  Classic 변환 계층
├── moli-protocol-webdriver-bidi/     BiDi 변환 계층
├── moli-renderer-v8/src/     V8 · 웹 API · 문서/작업 수명 · 렌더링 연결
├── moli-dom/ · moli-parser/  네이티브 문서 · 스트리밍 파싱
├── moli-fetch/ · moli-curl/  요청 정책 · 전송 · 연결 관리
├── moli-layout/              기하·텍스트 배치 · FrozenLayoutTree
├── moli-paint/               CPU 페인트 · 시각 출력
├── moli-html2md/             DOM 기반 Markdown 변환
├── moli-owner-queue/         소유자 작업 큐·깨우기
├── moli-local-executor/      JavaScript 실행 영역의 진입 제어
├── moli-storage-service/     저장 서비스
├── moli-browser-profile/     프로필 경로·잠금·지속성 경계
├── moli-cdp-smoke/           Python·Node CDP 통합 시험
├── moli-webdriver-smoke/     WebDriver 통합 시험
├── moli-frontend-smoke/      프레임워크 페이지·DOM 차등 시험
├── moli-benchmark/           성능·크롤링 비교 도구
├── moli-playground/          예제·WebMCP 등
├── tools/wptrunner-moli/     WPT 연동 도구
├── scripts/                 릴리스·개발 보조 코드
├── skills/                  에이전트 사용 안내
├── vendor/                  V8 등 저장소에 포함한 외부 코드
├── licenses/                제삼자 고지
└── .github/workflows/       CI · 릴리스 · 회귀 비교

위 트리는 학습에 필요한 경로를 추린 것입니다. 쿠키·DNS·CSP·WebCrypto·IndexedDB·OPFS 등은 별도 crate로 더 나뉩니다. moli/는 실행 파일 crate입니다. 본문의 moli/src/main.rs 같은 경로는 저장소 루트 기준입니다.

5-1. 코드 규모와 집계 범위

아래는 커밋 95094dd의 확장자별 파일 수와 물리적 줄 수입니다. 아래 표는 .git/과 vendor/를 제외하고, 빈 줄·주석·테스트·시험 HTML·생성 코드까지 포함합니다. “개발자가 직접 쓴 구현 줄 수”나 SLOC 도구의 유효 코드 줄 수는 아닙니다.

집계 조건을 바꾸면 숫자도 바뀝니다. vendor/를 포함한 Rust는 4,614개 파일·2,345,264줄입니다. 외부 코드를 포함한 수치와 제외한 수치를 섞어 읽지 마세요.

5-2. 어디에 읽는 시간을 쓸까

이 표에도 각 영역의 테스트 등이 포함되어 있습니다. 큰 폴더를 읽을수록 많이 배운다는 순위는 아닙니다. 처음에는 CLI의 플래그 하나를 골라 설정·내부형·동작·테스트의 네 지점을 연결하는 편이 이해하기 쉽습니다.

6학습 포인트 (기술별)

6-1. Rust: enum으로 잘못된 조합 줄이기

AutomationCommand와 파서의 상태형에서는 종류마다 필요한 값을 해당 자료형에 담습니다. kind = "screenshot"인데 스크린샷용 인자가 없는 상태를 표현하기 어렵게 만듭니다. 처음에는 enum·match·Option·Result 순서로 읽으면 추적하기 쉽습니다.

작은 실습: 자신의 메모 앱에 Command::Create·Command::Read· Command::Delete를 만들고, 필요한 값은 각 변형에만 담습니다. 문자열과 많은 선택적 인자로 표현한 버전과 비교해 보세요.

6-2. 소유권과 RAII: 후처리를 경로마다 쓰지 않기

moli-renderer-v8/src/native_bridge/context_host/layout.rs의 ActiveLayoutPass는 중복된 레이아웃 시작을 거부하고, Drop에서 실행 중 플래그를 되돌립니다. 중간에 ?로 반환하는 경로도 가드의 수명에 후처리를 묶을 수 있습니다. 다만 프로세스가 abort할 때까지 일반적인 Drop 실행을 보장하는 것은 아닙니다.

작은 실습: 중복 호출을 막는 작은 가드를 별도 프로젝트에서 만들고, 성공·조기 return·일반 오류에서 각각 플래그가 되돌아오는지 확인합니다.

6-3. 비동기: await가 있다고 모든 후처리가 끝난 것은 아니다

Tokio 채널은 일을 전달하는 수단입니다. 전송 성공·수락·실행 완료·외부 자원 해제는 서로 다른 사건일 수 있습니다. 커밋 95094dd의 wait_for_resources_bounded()는 탭 종료 통지 뒤에도 I/O 후처리가 남는 문제를 다룹니다.

작은 실습: Python의 asyncio.Queue로 “일 전달”·“처리”·“후처리”를 서로 다른 로그에 남기고, 고정 시간 sleep과 상태를 기다리는 방법을 비교합니다. 구현 언어가 달라도 비동기에서 관찰할 지점은 비슷합니다.

6-4. 브라우저: HTML 문자열과 살아 있는 문서 구분하기

최초 HTTP 응답은 입력입니다. 파싱 후 DOM, JavaScript 실행 후 DOM, 레이아웃, 출력 이미지는 서로 다른 관찰 대상입니다. moli-parser와 moli-dom, V8의 연결을 읽으면 같은 URL의 “내용”에도 여러 단계가 있음을 알 수 있습니다.

작은 실습: 나중에 제목을 변경하는 자작 페이지를 사용해 HTML 원본·DOM 텍스트·화면을 각각 기록합니다. “가져왔다”는 판단에 HTTP 200만으로 충분하지 않은 이유를 자기 말로 설명해 보세요.

6-5. 테스트: 최종 결과와 함께 중간 계약 살피기

moli-frontend-smoke/README.md는 문서 생성·마운트·갱신 후·안정 후의 체크포인트를 설명합니다. 일부 사례는 중간 프레임의 차이도 실패로 처리합니다. 최종 DOM이 같아도 중간 이벤트 순서나 내용은 다를 수 있기 때문입니다.

작은 실습: 자작 UI의 “읽는 중 → 결과 → 재시도”를 시간순 표로 정리하고, 마지막 화면만 비교하는 시험이 놓칠 버그 하나를 찾습니다. moli의 시험을 전부 실행할 필요는 없습니다.

6-6. 성능 설계: 캐시의 유무와 갱신 계약 함께 설명하기

최신 트리 하나를 남기는 설계는 메모리 사용과 재계산을 줄입니다. 동시에 DOM 변경 직후의 좌표가 오래된 값일 수도 있습니다. 캐시를 공부한다면 “무엇을 저장하는가”와 함께 “무엇이 갱신을 일으키는가”·“어떤 읽기가 오래된 값을 허용하는가”를 적어야 합니다.

이 저장소에서 배울 핵심은 동작·비용·정보의 최신성을 함께 설계하는 방법입니다.

7하드웨어 / 시스템 요구사항

확인한 README에는 모든 작업에 통용되는 최소 RAM·CPU·디스크 용량 표가 없습니다. 아래는 파일에서 확인한 조건과 학습 환경에 대한 제안을 구분한 것입니다. README의 메모리 측정값을 제품의 최소 메모리 요구량으로 바꾸어 제시하지 않습니다.

7-1. 읽기 중심과 시각 중심은 자원 계획이 다르다

Markdown 추출 위주라면 기본 Mock 경로부터 살펴볼 수 있습니다. 스크린샷·좌표 입력이 필요하면 --layout, 실제 이미지나 웹 글꼴까지 필요하면 해당 리소스 옵션을 추가합니다. --resource는 선택적 리소스 계열을 한꺼번에 허용하는 옵션이므로 기능과 네트워크 비용이 같이 달라집니다.

학습용으로는 동시에 한 페이지만 다루는 실험부터 시작하는 것을 제안합니다. 페이지 수·스크립트 부하·캡처 크기를 하나씩 늘리면서 RSS, CPU 시간, 열린 파일 수를 측정하면 출처 없는 “페이지당 고정 메모리” 가정보다 자신의 작업에 맞는 예산을 구할 수 있습니다.

7-2. “스레드 상한 4”는 프로세스 전체 상한이 아니다

moli/src/main.rs는 runtime_thread_budget을 받아 worker_threads()와 max_blocking_threads()를 각각 설정합니다. moli-protocol-server/src/runtime_thread_budget.rs의 계산은 사용 가능한 병렬 수와 4 중 작은 값입니다.

두 풀의 상한은 별도이고, 렌더러·V8·다른 작업의 스레드도 있습니다. 따라서 이 값을 보고 moli의 전체 스레드가 최대 네 개라고 해석하면 틀립니다. 렌더러의 moli-renderer-v8/src/tokio_blocking_budget.rs도 소유자 런타임의 blocking 풀에 별도 상한을 적용합니다.

7-3. 네트워크와 지속성의 기본 경계

moli-protocol-server/src/config.rs의 기본 바인딩은 127.0.0.1, 포트는 9222입니다. 서버 설정의 timeout은 10초이고 스크린캐스트 기본 간격은 1,000ms입니다. CLI fetch의 --timeout 기본값 25,000ms와는 대상·단위가 다릅니다.

ProtocolServer::new_with_initial_cookies()는 메모리 저장 파티션을 엽니다. CLI에는 --profile-dir, --http-cache-dir, --cookie-file 같은 지속성 경로가 따로 있습니다. 테스트에서 데이터를 남길지 여부도 기능 선택의 일부로 다뤄야 합니다.

8직접 해볼 수 있는 실습 과제

아래는 독자가 별도로 수행하는 과제입니다. 코드 수정 과제는 개인 학습용 복사본에서 진행하고, 동작 실습은 설치가 준비된 환경과 직접 만든 시험 페이지를 사용합니다.

moli fetch --dump markdown --wait-selector body https://example.com
moli fetch --dump semantic_tree_text --wait-selector body https://example.com

# 학습용 표본. 값은 테스트의 baseline 예에서 가져왔다.
baseline = {"fds": 24, "eventpoll": 7, "eventfd": 4, "threads": 20}
pending  = {"fds": 40, "eventpoll": 7, "eventfd": 4, "threads": 20}
settled  = {"fds": 24, "eventpoll": 7, "eventfd": 4, "threads": 20}

좋은 실습 결과물은 실행 성공 화면보다, 관찰한 결과를 소스의 조건문과 자료형으로 설명하는 기록입니다.

9관련 기술 심화 학습 로드맵

Rust와 브라우저 내부를 모두 처음 접한다면 전부 한 번에 읽지 않아도 됩니다. 아래는 주 3~5시간 정도를 가정한 학습 제안입니다. 이해가 덜 된 주차는 반복하고, 각 주차마다 남길 결과물을 하나로 정하면 다음 단계로 넘어갈 기준이 생깁니다.

9-1. 관심사별로 더 깊게 들어갈 갈림길

• 크롤링·데이터 추출: 요청·리디렉션·쿠키 → moli-fetch → 파서 → moli-html2md. 출력 품질과 대기 조건을 중심으로 읽습니다.
• 프론트엔드 호환성: DOM·이벤트 → microtask → 프레임워크 갱신 → 차등 시험. 화면의 최종 모양보다 중간 상태의 의미부터 봅니다.
• 렌더링·시각 출력: 계산 스타일 → 박스 트리 → 텍스트 배치 → 페인트. 동일 글꼴·뷰포트·리소스 조건을 먼저 고정합니다.
• 시스템 프로그래밍: 소유권·채널 → 취소·종료 → 파일 디스크립터·스레드 → 장기 실행 예산. 완료 신호와 회수 완료를 구분합니다.

9-2. 소스를 읽을 때 매번 남길 세 문장

1. 입력: 이 함수는 무엇을 받으며, 호출 전에 어떤 조건이 필요할까?
2. 소유와 수명: 무엇을 새로 만들고, 누가 보관하며, 언제 버릴까?
3. 관찰: 오류·응답·이벤트 중 무엇으로 실행 결과를 확인할까?

이 세 문장이 명확하면 함수 이름을 많이 외우지 않아도 다음 파일을 고를 수 있습니다. 모르는 라이브러리는 공식 문서에서 그 자료형의 역할만 보충한 뒤 다시 호출 지점으로 돌아오는 방식이 좋습니다.

10핵심 키워드 사전

단어를 외우기보다 이 글의 예와 짝지어 보세요. 스냅샷은 LatestLayoutTreeCache, 어댑터는 AutomationCommand로의 변환, 상태 기계는 RawParserStep처럼 기억하면 됩니다.

11참고 링크

11-1. 공식 저장소·프로젝트 자료

• moli 공식 저장소 · 현재 개발 상황과 배포 입구
• 분석 커밋의 README · 제품 범위·비용 정책·프로젝트 측 벤치마크
• 분석 커밋의 한국어 README · 사용법을 한국어로 확인
• v1.1.19 릴리스 · 2026-10-23 GitHub 기준, 2026-10-21 공개
• TrendShift의 moli 페이지 · 월간 선정 맥락을 확인할 출발점
• Lexbench-Headless-Browser · README가 연결한 비교 시험 프로젝트

11-2. 본문에서 따라간 핵심 소스

아래 링크는 모두 커밋 95094dd 기준입니다. 같은 버전의 코드와 설정을 함께 살펴볼 수 있습니다.

• 루트 Cargo.toml · 91개 멤버·포크·빌드 정책
• Cargo.lock · 실제 선택된 버전
• main.rs · Tokio 런타임과 오류 처리
• cli.rs · 출력·대기·리소스·레이아웃 옵션
• config.rs · 옵션을 내부 정책으로 바꾸는 경계
• ProtocolServer와 build_router() · 프로토콜 입구·종료 예산
• AutomationCommand · 공유 내부 명령
• CDP 스케줄러 actor · 이벤트·응답 순서 조정
• RenderRuntimeOwner · 렌더러 소유자와 채널
• JsLocalExecutor · 실행 영역의 직렬 진입
• 스트리밍 파서 · 진행·중단·실행 인계 상태
• 레이아웃 초기화·게시 · 최초 기하 요청과 최신 트리
• LatestLayoutTreeCache · 한 슬롯의 스냅샷 보관
• 새 레이아웃 계산·소비 · 출력과 Print의 게시 차이
• 탭 수명·자원 회수 시험 · 최신 커밋의 구체적 문제
• 자원 회수 검사 자체의 테스트 · 일시 지연·지속 누수 구분
• 프레임워크 차등 시험 · DOM 시간선과 관찰 계약
• CI 설정 · 검사·회귀 비교·장기 탐색
• 릴리스 설정 · 플랫폼별 빌드 대상
• 라이선스 메타데이터 · Apache-2.0 OR MIT

11-3. 관련 기술의 공식 학습 자료

• The Rust Programming Language · 소유권·enum·오류 처리
• Tokio 공식 튜토리얼 · 태스크·채널·비동기 실행
• V8 공식 문서 · JavaScript 엔진과 임베딩 배경
• WHATWG HTML 파싱 명세 · 입력·파서·스크립트의 관계
• Chrome DevTools Protocol · 명령·이벤트·도메인
• W3C WebDriver · 세션과 명령의 의미
• W3C WebDriver BiDi · 양방향 자동화 규약
• Playwright의 CDP 연결 문서 · 엔진과 클라이언트의 연결
• Taffy 공식 저장소 · 박스 배치 라이브러리
• Parley 공식 저장소 · 텍스트 배치 라이브러리
• WPT 공식 안내 · 웹 동작 시험의 구성

현재 상태 (2026-10-23 확인)