#Rust.
글
/ 총 8편일일 퍼즐 ID에 생성기 버전이 필요한 이유
DailySudoku의 일일 퍼즐은 날짜에서 seed를 만들어 보드를 생성해요. 생성 방식이 바뀌면 같은 날짜에서 다른 보드가 나올 수 있는데, 날짜만 담은 ID로는 그 차이를 적을 수 없어요. 현재 구조와, ID에 날짜 정책과 생성기 버전을 넣자는 제안을 기록해요.
Rust 공유 코어 7편: 테스트와 CI를 층별로 나누기
Rust 테스트가 통과해도 iOS 링크, Android 릴리스의 ABI, Web 배포 빌드의 Wasm 로딩은 따로 깨질 수 있어요. 도메인 검사는 Rust에 모으고, 클라이언트는 변환과 연결만 검사하고, CI는 산출물을 새로 만들어 확인하는 구성을 정리해요.
Rust 공유 코어 6편: Web에서 Wasm 패키지로 쓰기
모바일에서 쓰는 Rust 규칙을 Web에서도 쓰려면 WebAssembly로 컴파일해서 패키지로 내놓아요. Rust와 Web이 맡을 일의 구분, Next.js에서 초기화할 자리와 상태, 액션 단위의 호출 계약, 타입 변환을 확인하는 fixture를 정리해요.
Rust 공유 코어 5편: Android에 .so로 넣을 때 확인할 것
Kotlin 바인딩을 생성했다고 Android 통합이 끝난 것은 아니에요. ABI별 .so를 배치하는 방법, Gradle 빌드에 Rust 컴파일을 잇는 방법, 16 KB 페이지 조건과 release 배포물에서 확인할 항목을 Android 문서를 바탕으로 정리해요.
Rust 공유 코어 4편: iOS에 XCFramework로 전달하기
Rust 테스트가 통과해도 iOS 앱에서 링크가 된다는 보장은 없어요. 기기용과 시뮬레이터용 정적 라이브러리를 XCFramework로 묶고, Swift Package로 전달하고, 로컬과 CI가 같은 순서로 빌드하게 만드는 방법을 문서 기준으로 정리해요.
Rust 공유 코어 3편: UniFFI 생성 코드는 adapter 뒤에
UniFFI는 Rust의 함수와 타입에서 Swift와 Kotlin 호출 코드를 만들어 줘요. 무엇을 공개하고 생성된 타입을 어디까지 쓸지는 앱이 정해야 해요. 생성 코드를 adapter 뒤에 두는 구조와 플랫폼별로 챙길 것, 생성 파일의 관리 방식을 정리해요.
Rust 공유 코어 2편: 경계를 넘는 API를 크게 잡기
Rust 엔진을 Swift, Kotlin, TypeScript에서 부를 때에는 내부에 알맞은 타입과 바깥에서 다루기 쉬운 타입이 달라요. 셀 단위의 작은 함수보다 액션 단위의 큰 함수를 내놓고, DTO와 오류와 버전을 계약으로 관리하는 설계를 정리해요.
Rust 공유 코어 1편: 무엇을 공유하고 어디서 끊을지
iOS, Android, Web을 함께 만들면 같은 규칙을 세 번 구현하게 돼요. Rust로 공유할 범위를 결과가 같아야 하는 도메인 규칙으로 좁히고, 코어와 바인딩과 앱의 세 층으로 나누는 설계를 스도쿠를 예로 설명해요.