직접 플러그인 쓰기 (맛보기)

"'이거 플러그인으로 만들어야 하나?'의 답은 대개 아니오야 — 모듈이면 돼. 더 큰 망치를 꺼내기 전에 그 차이를 알아둬."

플러그인으로 안 만들어도 될 때

네 앱 하나만 쓰는 기능이면 플러그인일 필요가 없어. Rust 모듈(commands.rs, storage.rs)에 두고 command를 평소처럼 등록해 — 그게 더 단순하고, 절차도 적고, 건강한 Tauri 코어의 모습 그대로거든(Cinder가 코어를 쪼개둔 방식이 이거야). 플러그인은 패키징 부담을 얹어. 돌려받는 게 있을 때만 그 값을 치러.

플러그인이 제값 하는 때

플러그인을 써야 할 때는 이래. 기능을 여러 앱에 걸쳐 다시 쓰고 싶을 때, 남들이 쓰게 배포할 때, 아니면 통일된 API 뒤에 네이티브 모바일 코드(Swift나 Kotlin)를 싣고 싶을 때. 플러그인은 Rust command랑 JS API랑 permission 정의랑, 필요하면 모바일 네이티브 코드까지 설치 가능한 하나로 묶어 — 지금까지 써온 공식 플러그인이랑 똑같은 모양이야. '이거 다음 앱에도 넣고 싶다'가 참이 되는 순간, 플러그인이 맞는 그릇이야.

플러그인의 모양

속을 들여다보면 플러그인은 이름이랑 자기 command용 invoke 핸들러랑 permission 세트를 가진 tauri::plugin::Builder야. CLI가 tauri plugin new(나 create 명령)로 구조 전체를 만들어줘 — Rust 크레이트랑 JS 패키지랑 permission 뼈대까지. command는 앱 command 짜듯 채우면 되고 — 그걸 옮겨 다닐 수 있고 허락을 거쳐야 하는 것으로 만들어주는 게 플러그인 껍데기야.

Code

최소한의 플러그인 뼈대·rust

use tauri::{plugin::{Builder, TauriPlugin}, Runtime};

#[tauri::command]
fn do_thing() -> String { "from the plugin".into() }

// 플러그인은 자기 command를 묶는 이름 있는 Builder야.
pub fn init<R: Runtime>() -> TauriPlugin<R> {
    Builder::new("my-plugin")
        .invoke_handler(tauri::generate_handler![do_thing])
        .build()
}

// 앱은 공식 플러그인처럼 그대로 써:
//   .plugin(my_plugin::init())

구조는 CLI한테 만들게 시켜·bash

# 전체 플러그인 스캐폴딩 (Rust 크레이트 + JS 패키지 + permissions).
npm create tauri-plugin my-plugin
# 또는, 프로젝트 안에서:
npm run tauri plugin new my-plugin

Exercise

결정하고 근거를 대봐. 기능 세 개(예를 들면 '내 앱의 노트 저장', '다시 쓸 수 있는 QR 코드 생성기', '모바일 전용 네이티브 API 래퍼')를 각각 '모듈'이나 '플러그인'으로 이름 붙이고 이유를 한 문장씩 적어. 그다음 원하면 tauri plugin new를 돌려 만들어진 구조를 읽고 플러그인이 실제로 뭘 묶는지 봐. 모듈이냐 플러그인이냐를 가르는 판단이 진짜 레슨이야.

Hint

앱 전용 저장은 모듈. 앱을 넘나드는 생성기는 플러그인. 모바일 네이티브 API 래퍼도 플러그인(플러그인이 Swift나 Kotlin을 싣는 방식이거든). '다른 앱이나 다른 개발자가 이걸 쓸까?'가 결정을 가르는 질문이야.