바이너리 줄이기

"Tauri는 Chromium을 안 보내서 큰 크기 전투를 이미 널 위해 이겼어. 나머지는 애초에 작은 바이너리를 미세 조정하는 거야."

제일 큰 승리는 이미 공짜야

관점을 유지해: Tauri 앱이 수백 MB가 아니라 메가 단위인 이유는 브라우저 엔진을 안 번들해서야. 그 구조적 결정이 95% 승리고, Tauri를 골라서 공짜로 얻었어. 아래는 다 이미 작은 바이너리에서 마지막 한 톨을 짜내는 거야 — 다듬어진 릴리스엔 할 가치 있지만, 메인 이벤트로 착각하지 마.

Cargo 릴리스 프로파일

남은 제일 큰 레버는 Cargo.toml의 Rust [profile.release]야. link-time 최적화 켜기(lto = true), codegen unit을 하나로 줄이기(컴파일 느림, 출력 작고/빠름), 심볼 스트립(strip = true), 크기 최적화(opt-level = "s"나 "z"), panic 시 abort(panic = "abort")를 합치면 바이너리를 의미 있게 줄여. 컴파일 시간을 더 날씬한 릴리스랑 거래해 — 릴리스는 드물게 빌드하니 괜찮아.

프론트엔드 잊지 마

번들된 웹 에셋도 앱 크기에 들어가. 웹 작업의 같은 프론트엔드 규율이 적용돼: Vite가 tree-shake하고 code-split하게 두고, 안 쓰는 의존성 떨구고, 이미지 압축하고, 앱이 쓰는 것만 내. 그리고 기본 거부 플러그인 습관 유지해 — 끌어오는 모든 플러그인이랑 기능이 바이너리에 더해지니, 보안 위해 유지한 날씬한 capabilities 파일이 크기 이득으로도 이중 역할을 해. 빡빡한 부여, 빡빡한 바이너리.

Code

릴리스 프로파일 튜닝·toml

# src-tauri/Cargo.toml — 릴리스 바이너리 짜내기.
[profile.release]
opt-level = "s"        # 크기 최적화 ("z"는 더 작음)
lto = true             # 크레이트 가로지르는 link-time 최적화
codegen-units = 1      # 컴파일 느림, 바이너리 작고 + 빠름
strip = true           # 디버그 심볼 제거
panic = "abort"        # 바이너리에 unwinding 기계 없음

Exercise

현재 릴리스 번들 크기를 기록하고, 위 [profile.release] 조정을 더해 재빌드해. 새 크기를 비교해. opt-level 's' vs 'z'를 시도하고 네 앱엔 뭐가 이기는지 적어. 그다음 프론트엔드 번들을 보고 떨굴 수 있는 안 쓰는 의존성 하나를 찾아. 설계상 이미 작은 바이너리에서 측정된 최적화를 연습하는 거야.

Hint

기준선 위해 릴리스부터 빌드, 프로파일 적용, 재빌드, 비교. 'z'는 크기를 더 빡세게 최적화하지만 런타임이 느릴 수 있어; 둘 다 재. 프론트엔드는 번들러의 analyze 출력이 뭐가 공간 먹는지 보여줘.