Kotlin에서 Rust로: 고성능 캐싱 서비스 마이그레이션이 주는 교훈
고성능 서비스를 운영하다 보면 언젠가 "이 언어가 우리 시스템의 한계인가?"라는 질문을 마주하게 된다. Ruth Linehan이 공유한 사례는 바로 그 질문에 답한 실전 경험이다. Kotlin으로 운영 중이던 캐싱 서비스를 Rust로 마이그레이션하면서, 팀 내에 퍼져 있던 선입견들이 하나씩 깨졌다고 설명한다. "Rust는 개발 속도가 느리다", "엔지니어링 오버헤드가 너무 크다"는 우려가 대표적이었다.
실제 마이그레이션 결과는 예상과 달랐다. Rust의 컴파일 타임 안전성이 오히려 개발자 피드백 루프를 단축시켰다는 점이 핵심이다. 런타임에서야 드러나는 버그들이 컴파일 단계에서 차단되면서, 운영 중 발생하는 장애 대응 비용이 줄었고 코드에 대한 신뢰도가 높아졌다.
빌림 검사기(Borrow Checker)의 실무적 의미
Java나 Kotlin 개발자에게 Rust의 빌림 검사기는 처음에 큰 장벽으로 느껴진다. 하지만 이 메커니즘이 강제하는 것은 결국 명시적인 소유권과 생명주기 관리다. 멀티스레드 캐싱 서비스처럼 동시성이 핵심인 시스템에서, 데이터 레이스나 use-after-free 같은 버그는 재현조차 어렵다. Rust는 이런 문제를 컴파일 타임에 원천 차단한다.
// 컴파일 타임에 데이터 레이스를 방지하는 예시
use std::sync::{Arc, Mutex};
let cache = Arc::new(Mutex::new(std::collections::HashMap::new()));
let cache_clone = Arc::clone(&cache);
std::thread::spawn(move || {
let mut map = cache_clone.lock().unwrap();
map.insert("key", "value");
});
JVM 생태계에서는 synchronized나 ConcurrentHashMap을 올바르게 사용하는 것이 전적으로 개발자의 책임이다. Rust에서는 잘못된 동시성 접근 자체가 컴파일을 통과하지 못한다. 4년차 이상의 개발자라면 이 차이가 실제 운영 장애 빈도에 얼마나 큰 영향을 주는지 직관적으로 이해할 수 있을 것이다.
Criterion과 Flamegraph로 동시성 코드 튜닝하기
성능 최적화는 측정 없이 시작해서는 안 된다. 이 사례에서 활용한 두 가지 도구가 주목할 만하다.
- Criterion: Rust 생태계의 표준 벤치마킹 라이브러리로, 통계적으로 안정적인 측정값을 제공한다. 단순히 실행 시간을 찍는 것이 아니라 반복 측정을 통해 노이즈를 걸러낸다.
- Flamegraph: CPU 사용 시간을 스택 트레이스 기반으로 시각화한다. 동시성 코드에서 어느 코드 경로가 병목인지 직관적으로 파악할 수 있다.
# Cargo.toml에 Criterion 추가
[dev-dependencies]
criterion = { version = "0.5", features = ["html_reports"] }
Java 백엔드에서 JMH나 async-profiler를 사용해본 경험이 있다면 이 조합의 역할을 쉽게 매핑할 수 있다. 중요한 것은 도구 자체가 아니라, 측정 → 병목 식별 → 튜닝 → 재측정이라는 사이클을 체계적으로 돌리는 습관이다.
정리
- Rust의 컴파일 타임 안전성은 런타임 버그 대응 비용을 줄여 오히려 개발 속도에 긍정적인 영향을 줄 수 있다.
- 빌림 검사기는 동시성 코드에서 데이터 레이스를 원천 차단하며, 고성능 캐싱 서비스처럼 동시성이 중요한 시스템에서 특히 가치가 크다.
- Criterion + Flamegraph 조합으로 성능 병목을 정량적·시각적으로 식별하는 체계적인 프로파일링 루프를 구축할 수 있다.