728x90
mount_to_body와 hydrate_body는 Rust의 웹 프레임워크인 Leptos에서 웹 애플리케이션을 브라우저의 DOM(<body>)에 연결하는 방식의 차이를 나타냅니다.
두 함수의 핵심 차이점은 HTML을 새로 만드느냐, 기존 HTML에 동적 기능만 수혈하느냐입니다.
한눈에 보는 비교 테이블
구분mount_to_bodyhydrate_body
| 주요 렌더링 방식 | CSR (클라이언트 사이드 렌더링) 전용 | SSR (서버 사이드 렌더링) 연계 필수 |
| 초기 DOM 상태 | 빈 <body> 상태에서 시작 | 서버가 미리 그려 보낸 HTML이 존재 |
| DOM 처리 방식 | 기존 내용을 지우고 요소를 새로 생성 | 기존 HTML 구조를 유지하며 이벤트 리스너만 연결 |
| 속도 및 SEO | 초기 로딩이 느리고 SEO에 불리함 | 초기 로딩(FCP)이 빠르고 SEO에 유리함 |
1. mount_to_body (CSR 방식)
브라우저가 자바스크립트(WASM)를 실행하는 시점에 아무것도 없는 빈 화면에 DOM 요소를 처음부터 끝까지 직접 생성하여 집어넣습니다.
- 동작: 브라우저의 <body> 태그 내부를 전부 비우거나 덮어쓰고, Rust 코드로 작성된 뷰(View) 구조를 새로 그립니다.
- 용도: 서버 없이 웹 브라우저에서만 완전히 독립적으로 돌아가는 싱글 페이지 애플리케이션(SPA)을 만들 때 사용합니다.
- 단점: 대규모 앱의 경우 WASM 파일이 다운로드되고 실행될 때까지 사용자가 빈 화면(또는 정적 로딩 화면)을 보아야 합니다.
rust
// main.rs (CSR 전용 앱의 진입점)
fn main() {
// <body> 태그에 App 컴포넌트를 처음부터 새로 빌드하여 부착합니다.
leptos::mount::mount_to_body(App);
}
코드를 사용할 때는 주의가 필요합니다.
2. hydrate_body (SSR + Hydration 방식)
서버가 미리 만들어 보낸 정적 HTML 위에 자바스크립트(WASM)의 동적 기능(상태 관리, 이벤트 리스너 등)을 '수분 공급(Hydration)'하듯 결합합니다.
- 동작: 브라우저는 서버로부터 이미 완성된 HTML을 받아 화면에 즉시 보여줍니다 (빠른 초기 로딩). 그 후 뒤늦게 실행된 WASM이 기존의 HTML 구조와 자신의 컴포넌트 구조를 매칭해가며 클릭 이벤트 같은 인터랙션 기능만 연결합니다. [1, 2]
- 용도: 서버 사이드 렌더링(SSR)을 사용하는 풀스택 Leptos 웹 앱의 클라이언트 측 진입점에서 사용합니다. [1, 2]
- 장점: 사용자가 첫 화면을 마주하는 속도가 매우 빠르고, 검색엔진 봇이 완성된 HTML 코드를 읽을 수 있어 SEO(검색엔진 최적화)에 매우 유리합니다.
rust
// lib.rs (WASM 클라이언트 빌드용 진입점)
#[cfg(feature = "hydrate")]
#[wasm_bindgen::prelude::wasm_bindgen]
pub fn hydrate() {
// 서버가 만든 HTML 구조를 그대로 둔 채, 동적 데이터와 이벤트만 연결합니다.
leptos::mount::hydrate_body(App);
}
코드를 사용할 때는 주의가 필요합니다.
요약
- 완전히 브라우저 안에서만 처음부터 요소를 다 그려내고 싶다면 mount_to_body를 사용하세요.
- 서버에서 HTML을 받아오고 인터랙션 기능만 활성화하는 풀스택 앱을 구현 중이라면 hydrate_body를 사용해야 합니다.
728x90
'컴퓨터 활용(한글, 오피스 등) > 기타' 카테고리의 다른 글
| vim | 코드 가독성, Gruvbox (0) | 2026.08.12 |
|---|---|
| Dockerfile 동작 원리 (0) | 2026.08.12 |
| 윈도우 | 사용 중 포트 확인 및 사용 중 서비스명 찾기 (0) | 2026.08.12 |
| AI/LLM API 호출 코드 temperature: 0.7 의미 (0) | 2026.08.12 |
| 리눅스 명령어 모음 (0) | 2026.08.12 |