tauri build: 진짜 무슨 일이 나나

"tauri build는 한 명령을 입은 두 일이야: 릴리스 바이너리 컴파일, 그다음 사람들이 진짜 더블클릭할 설치 파일로 감싸기."

두 단계

tauri build를 돌리면 먼저 beforeBuildCommand를 실행해 정적 프론트엔드를 만들고, Rust 코어를 release 모드(최적화, 컴파일 느림, 작고 빠르게 돌아)로 컴파일하고, 프론트엔드를 바이너리에 박고, 마지막으로 번들러한테 넘겨 OS 네이티브 설치 포맷을 만들어. 결과는 이메일로 보내는 헐거운 실행파일이 아냐 — src-tauri/target/release/bundle/ 아래 제대로 된 설치 파일이야.

릴리스는 다른 짐승이야

tauri dev에서 잰 건 다 debug 빌드였어. 릴리스는 진짜 최적화를 적용해: 바이너리가 극적으로 줄고 더 빨라져, 거기가 Tauri의 '작은 앱' 명성이 실제로 사는 곳이야. 뒷면은 컴파일 시간 — clean 릴리스 빌드는 몇 분 걸려. 이래서 사람들이 CI에서 Rust target/ 디렉터리를 캐싱하고, 크기/성능을 dev가 아니라 릴리스 출력으로만 판단해.

쓰게 될 빌드 손잡이

플래그 둘이 일찍 중요해. --no-bundle은 설치 파일 안 만들고 바이너리만 컴파일해 — 패키징된 출력이 안 필요한 CI '빌드 되나?' 체크에 완벽해. --bundles <format>은 설정된 전부 대신 어떤 설치 포맷을 만들지 제한해(예: dmg만). 그리고 --debug는 풀 릴리스 최적화 없이 테스트용으로 뭔가 패키징할 때 debug 빌드를 번들해.

Code

빌드 명령과 유용한 플래그·bash

# 풀 릴리스: 최적화 바이너리 + 설정된 모든 설치 파일.
npm run tauri build

# CI '컴파일 되나?' 체크 — 설치 파일 건너뛰기.
npm run tauri build -- --no-bundle

# 특정 설치 포맷만 빌드.
npm run tauri build -- --bundles dmg

# DEBUG 빌드 패키징 (테스트용, 릴리스 아님).
npm run tauri build -- --debug

출시 가능 출력이 떨어지는 곳·text

src-tauri/target/release/
├─ my-app                       # 생 최적화 바이너리
└─ bundle/
    ├─ macos/My App.app         # macOS 앱 번들
    ├─ dmg/My App_1.0.0_*.dmg   # macOS 설치 파일
    ├─ msi/ , nsis/             # (Windows에서) 설치 파일
    └─ deb/ , appimage/         # (Linux에서) 설치 파일

Exercise

앱에 tauri build를 돌리고, --bundles <네-OS-포맷>(macOS는 dmg, Windows는 nsis, Linux는 deb)으로 다시 돌려 bundle/에 뭐가 나타나는지 비교해. 그다음 --no-bundle을 돌려 패키징 단계 없이 얼마나 빠른지 봐. 이제 build의 각 단계가 뭘 들고 뭘 만드는지 알아.

Hint

풀 빌드는 설정된 모든 설치 파일을 만들고; --bundles가 좁히고; --no-bundle은 설치 파일을 통째로 건너뛰어(제일 빠름). 생 바이너리는 target/release/에, 설치 파일은 target/release/bundle/<format>/에.