결정론은 Rust 로

"같은 입력이 항상 같은 출력을 내야 하는 일이면 Rust 몫이야. 빠르고, 테스트가 되고, 절대 추측하지 않으니까."

EV v2 · 2026-09-18: 여기 있는 #[tauri::command] 샘플은 2026-07 빌드를 보여줘. 파일 IO 와 ruleset 적용이 IPC 너머의 Rust 함수였던 시절이야. v4 에선 네이티브 Swift 야 — 같은 순수 변환, 같은 단일 소유자 파일 규율이고, Rust 테스트가 있던 자리엔 (parity ledger 의 증거인) 테스트 스위트가 서 있어. Rust 가 핵심이었던 게 아냐. '결정론적 작업은 빠르고 재현 가능하고 테스트 가능한 집을 받을 자격이 있다' 가 핵심이었고, 그 문장은 편집이 필요 없었어.

Rust 코어에 사는 것

봉합선에서 결정론 쪽에 있는 건 전부 Rust 코어에 살아. 부활한 WordPress-tag 레이어인 export ruleset 적용, frontmatter 와 태그를 읽고 쓰기, 파일 읽고 쓰기. 변환들은 순수해. 문서에 ruleset 을 더하면 출력이 정확히 하나 나오고, 언제 돌려도 똑같아. 파일 IO 는 순수하진 않아. 읽기는 디스크에 뭐가 있느냐에 달렸고 쓰기는 디스크를 바꾸니까. 그래도 똑같이 결정론적이고 모델이 안 껴. 같은 디스크 상태에서 같은 호출이면 같은 일을 하거든. 모델도 없고 무작위성도 없고 '경우에 따라' 도 없지. 그 성질 덕분에 이쪽은 아무한테도 안 물어보고 돌려도 안전한 거고.

왜 결정론에 Rust 인가

Rust 가 결정론 레이어에 맞는 이유가 셋이야. 우선 빨라. 다만 빠르다고 UI 가 저절로 안 막히는 건 아냐. Tauri 에서 평범한 동기 커맨드는 메인 스레드에서 돌거든. 그래서 파일 작업은 async 로 선언한 커맨드에 둬야 Tauri 가 메인 스레드 밖에서 돌려줘. 그리고 안전하니까 네 파일을 건드리는 레이어가 메모리 버그로 파일을 망가뜨릴 일이 없어. 마지막으로 재현이 되고 테스트가 돼. 타입이 잡힌 입출력을 가진 순수 함수야말로, 절대 놀랄 일이 없어야 하는 앱 밑바닥에 딱 필요한 물건이거든. 판단 레이어는 확률적이어도 되지만 네 파일에 쓰는 레이어는 그러면 안 되고, Rust 가 그 규율을 강제해줘.

#[tauri::command]
fn apply_ruleset(doc: String, ruleset: Ruleset) -> Result<String, String> {
    // 순수 변환: 같은 doc 에 같은 ruleset 이면 항상 같은 출력.
    // 모델 호출도 무작위도 없어서 재현 가능하고 unit 테스트도 돼.
    Ok(ruleset.apply(&doc))
}

파일 IO 는 Rust 커맨드

.md 파일을 읽고 쓰는 일 자체가 결정론적 작업이라서, 프론트엔드가 직접 하지 않고 Tauri IPC 로 부르는 Rust 커맨드가 맡아. '결정론은 Rust' 라는 봉합선을 그대로 지키는 셈이고, webview 파일 API 를 쓸 때 딸려 오는 fs-scope 배관도 피할 수 있어. 프론트엔드는 Rust 코어한테 불러달라거나 저장해달라고 요청하고, 디스크를 실제로 건드리는 건 Rust 코어뿐이야. 파일 입출력의 주인이 하나뿐이라는 게 트랙 7 에서 다시 중요해져. 거기서 파일시스템을 진실의 원천으로 못 박거든.

Code

결정론적 변환을 Tauri 커맨드로·rust

// 결정론적 작업: 같은 입력이면 항상 같은 출력.
// Rust 에 살고 프론트엔드에서 Tauri IPC 로 부르지.
#[tauri::command]
fn apply_ruleset(doc: String, ruleset: Ruleset) -> Result<String, String> {
    // 모델도 무작위도 없는, 순수하고 unit 테스트 가능한 변환.
    Ok(ruleset.apply(&doc))
}

// 파일 IO: 순수하진 않지만(디스크를 읽고 바꿔) 결정론적이고 모델이 안 껴.
// async 로 선언해서 Tauri 가 메인 스레드 밖에서 돌려.
#[tauri::command]
async fn read_note(path: String) -> Result<String, String> {
    std::fs::read_to_string(&path).map_err(|e| e.to_string())
}

#[tauri::command]
async fn write_note(path: String, contents: String) -> Result<(), String> {
    std::fs::write(&path, contents).map_err(|e| e.to_string())
}

Exercise

결정론적 변환을 하나 골라봐. '선택 영역을 shortcode 로 감싸기' 나 'frontmatter 제거하기' 같은 것. 타입 시그니처를 써봐. 뭐가 들어가고 뭐가 나오는지. 그다음 그게 맞다는 걸 증명할 한 줄짜리 unit 테스트를 써. '이걸 더 따뜻하게' 같은 판단 작업으로는 둘 다 깔끔하게 안 나온다는 걸 확인해. 그게 바로 그런 일이 결정론적 코어에 안 속하는 이유야.

Hint

결정론적 함수는 (doc, args) -> output 같은 시그니처가 나오고 assert(fn(input) == expected) 같은 테스트를 쓸 수 있어. '톤에 따라 달라서' expected 를 하나로 못 적겠다면, 그 작업은 결정론이 아니라 판단이야.

Rust 코어에 사는 것

왜 결정론에 Rust 인가

파일 IO 는 Rust 커맨드

Code

External links

Exercise

Progress

댓글 0