tauri dev vs tauri build

"dev는 네 창을 살아 있는 서버 쪽으로 돌려놔. build는 전부를 바이너리 하나에 얼려붙이고. 지금 어느 쪽 세계인지 늘 알고 있어야 해."

명령 둘, 세계 둘

tauri dev는 손이 제일 자주 도는 자리야. beforeDevCommand를 돌려 프론트엔드 dev 서버를 띄우고, devUrl이 응답할 때까지 기다렸다가, Rust 코어를 debug 모드로 컴파일하고, 그 dev 서버를 가리키는 네이티브 창을 띄워. 프론트엔드엔 HMR이 붙고 Rust는 저장할 때마다 다시 컴파일돼. 컴포넌트를 고치면 화면이 바로 바뀌고, command를 고치면 Rust가 다시 빌드되고 앱이 다시 뜨지.

tauri build는 내보내는 길이야. beforeBuildCommand를 돌려 정적 프론트엔드를 만들고, Rust 코어를 release 모드(최적화가 붙고 컴파일은 더 느려)로 컴파일하고, frontendDist 파일을 바이너리 안에 박고, 그다음 번들러를 돌려 타깃별 설치 파일을 만들어. dev 서버는 아예 안 껴. 앱이 혼자서 온전해지는 거야.

debug랑 release는 진짜로 달라

tauri dev가 만드는 debug 바이너리는 크고 최적화가 안 돼 있어 — 빨리 돌려보기엔 좋고 내보내기엔 최악이지. tauri build가 만드는 release 바이너리는 최적화되고 심볼도 걷어내서, 컴파일이 오래 걸리는 대신 작고 빨라. 성능이든 바이너리 크기든 debug 빌드로 재지 마. release 출력으로 재.

결과물이 떨어지는 자리

tauri build가 끝나면 설치 파일이 src-tauri/target/release/bundle/ 아래 종류별로 정리돼서 나타나. Mac은 dmg/랑 macos/, Windows는 msi/랑 nsis/, Linux는 deb/랑 appimage/. 생 실행파일은 target/release/에 있는데, 사용자한테 건네는 건 bundle 폴더 쪽이야. 이건 ship 트랙에서 깊게 파.

Code

제일 자주 치게 될 두 명령·bash

# 이너 루프 — 빠른 반복, debug 빌드, dev 서버를 가리킴.
npm run tauri dev

# 출시 — release 빌드, 정적 프론트엔드 박힘, 설치 파일 생성.
npm run tauri build

# 설치 파일 번들 없이 빌드 (바이너리만), 예: CI 체크용:
npm run tauri build -- --no-bundle

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

내보낼 수 있는 결과물이 나타나는 자리·text

`tauri build` 후 (macOS 예시):

src-tauri/target/release/
├─ my-app                      # 생 release 바이너리
└─ bundle/
    ├─ macos/My App.app        # .app 번들
    └─ dmg/My App_1.0.0_*.dmg  # 출시할 설치 파일

Exercise

스캐폴딩한 앱에 tauri build를 돌려(처음엔 몇 분 걸려). src-tauri/target/release/bundle/ 아래 생긴 설치 파일을 찾아 크기를 적어. 그걸 dev로 돌렸을 때 나온 src-tauri/target/debug/ 바이너리 크기랑 비교해. 두 숫자를 다 적어 — 그 차이가 debug랑 release의 거리야.

Hint

macOS는 bundle/dmg/나 bundle/macos/를 봐. debug 바이너리는 target/debug/에 있어. release 결과물이 훨씬 작아야 하고, 내보내는 건 그쪽 하나뿐이야.