Rust에서 Ruby로 돌아간 개발자의 솔직한 회고: 속도보다 중요한 것

"빠른 게 최고 아니야?"라는 통념에 던지는 질문

요즘 백엔드 개발 트렌드를 보면 Rust, Go 같은 컴파일 언어로 갈아타는 흐름이 강해요. 성능도 좋고, 메모리 안전성도 보장되고, 동시성 처리도 우아하니까요. 그런데 흥미롭게도 한 개발자가 이런 흐름과는 정반대 방향, 즉 Rust로 짠 프로젝트를 다시 Ruby로 돌려놓은 경험을 블로그에 정리해서 올렸어요. "퇴보" 아니냐고 생각하실 수도 있는데, 글을 읽어보면 단순한 언어 선호의 문제가 아니라 개인 프로젝트의 본질에 대한 깊은 고민이 담겨 있어요.

이 글의 저자는 처음에 자신만의 작은 사이드 프로젝트를 Rust로 시작했어요. 이유는 누구나 짐작하실 만한 거예요. 성능, 타입 안전성, 모던한 도구 체인, 그리고 무엇보다도 "진지한 개발자라면 응당 써야 할 것 같은" 분위기. 그런데 시간이 지나면서 작업 속도가 점점 느려지고, 새 기능을 추가하기보다 컴파일러와 씨름하는 시간이 더 길어지더라는 거예요.

Rust가 잘못한 건 아니에요

오해하시면 안 되는 게, 글쓴이는 Rust 자체를 비판하지 않아요. 오히려 "훌륭한 언어이고, 적합한 곳에서는 최고"라고 분명히 말해요. 다만 본인의 프로젝트, 즉 혼자 만들고 혼자 운영하는 작은 웹 서비스에는 Rust의 강점이 발휘될 무대 자체가 없었다는 거죠.

예를 들어 Rust의 소유권 시스템은 멀티스레드 환경에서 데이터 경쟁(data race)을 컴파일 타임에 잡아주는 게 핵심 가치인데, 사용자가 몇 명 안 되는 사이드 프로젝트에서는 그런 동시성 문제가 발생할 일이 거의 없어요. 또 Rust의 빌드 시간이 길다는 건 유명한데, 코드를 살짝 고치고 결과를 확인하기까지 몇십 초씩 기다리는 게 사이드 프로젝트의 "실험하는 재미"를 갉아먹더래요. 데이터베이스 스키마 한 줄 바꾸려고 Diesel ORM의 매크로와 한참 씨름하다 보면, 이게 코딩인지 컴파일러 어르고 달래기인지 헷갈릴 정도였다고 해요.

Ruby의 "즐거움"이라는 가치

반면 Ruby는 1995년에 마츠모토 유키히로(Matz)가 "프로그래머의 행복"을 최우선 가치로 두고 만든 언어예요. 문법이 자연어에 가깝고, Rails 같은 프레임워크는 "설정보다 관습(Convention over Configuration)"이라는 철학 아래에서 결정을 최소화해줘요. 글쓴이는 Rust에서 며칠 걸렸던 기능 하나를 Rails로 옮기니 두세 시간 만에 끝나더라고 회고해요.

구체적으로 어떤 차이가 있었을까요? Rust에서는 HTTP 라우팅, JSON 직렬화, DB 연결, 마이그레이션, 인증 같은 걸 각각 다른 크레이트(crate, Rust의 라이브러리 단위)를 골라서 조합해야 해요. axum, serde, sqlx, refinery, argon2 등등. 각 라이브러리가 잘 만들어져 있긴 하지만, 버전을 맞추고 서로 호환되게 설정하는 일이 만만치 않아요. Rails는 이 모든 게 박스에서 꺼내자마자 동작하는 상태로 묶여 있어요. rails new 명령어 한 줄이면 운영 환경에 배포 가능한 골격이 완성되거든요.

성능은 정말 중요한가

많은 분들이 "그래도 성능 차이가 너무 크지 않나?"라고 생각하실 텐데요, 글쓴이의 답은 흥미로워요. "내 서비스가 초당 만 건의 요청을 받는 것도 아닌데, 응답 시간이 5ms든 50ms든 사용자는 차이를 못 느낀다"는 거예요. 실제로 GitHub, Shopify, Airbnb 같은 거대 서비스도 오랫동안 Ruby/Rails로 운영해왔고, 트래픽이 정말 많아진 일부 핫스팟만 다른 언어로 다시 짜는 전략을 썼어요. 처음부터 모든 걸 Rust로 짤 필요는 없다는 거죠.

업계 전반의 "오버 엔지니어링" 반성

사실 이런 회고는 글쓴이 한 명만의 이야기가 아니에요. 최근 1~2년 사이에 "Boring Technology"를 옹호하는 글, "마이크로서비스 말고 모놀리스로 충분하다"는 주장, Basecamp의 DHH가 외친 "클라우드에서 자체 호스팅으로 회귀" 같은 흐름이 계속 나오고 있어요. 모두 같은 맥락이에요. 진짜 비즈니스 가치는 멋진 기술 스택이 아니라 빠르게 사용자에게 가치를 전달하는 것에서 나온다는 자각이죠.

한국 개발자에게 주는 시사점

한국 개발 업계에서도 비슷한 고민이 많이 보여요. 신규 채용 공고를 보면 Kafka, K8s, gRPC, MSA가 기본 요건처럼 적혀 있는데, 정작 트래픽이 그 정도 규모가 안 되는 회사도 적지 않거든요. 사이드 프로젝트나 1인 SaaS를 시작하시는 분이라면, 가장 익숙하고 가장 빨리 만들 수 있는 도구를 선택하는 게 정답일 가능성이 높아요. Django, Rails, Laravel 같은 풀스택 프레임워크는 여전히 1인 개발자에게 가장 강력한 무기예요.

물론 회사 업무에서 성능이 진짜 중요한 코어 시스템을 만든다면 Rust나 Go가 좋은 선택일 수 있어요. 중요한 건 "도구는 목적에 맞춰서"라는 당연한 원칙이에요. 트렌드를 따라가는 게 아니라, 내 상황에 맞는 도구를 고르는 안목이 결국 시간을 가장 많이 아껴줘요.