Rust에서 Ruby로 — 14,943줄 코드 30분 변환 실험

Rust에서 Ruby로 — 14,943줄 코드 변환 실험

Rust에서 Ruby로 — 14,943줄 코드 30분 변환 실험

최근 개발자 커뮤니티에서 흥미로운 실험이 화제를 모으고 있다. Rust 웹앱 크레이트를 Ruby on Rails로 옮겨보는 개인 프로젝트가 그것이다. 대상이 된 코드는 Tera와 Axum 기반으로 작성된 14,943줄의 Rust였고, Local Qwen3.6 AI의 도움으로 약 30분이면 변환을 완료할 수 있었다.

실험의 배경

이 실험을 진행한 개발자의 프로젝트는 전체 약 3만 줄 규모다. 그중 전환 대상이 된 웹앱 크레이트는 Tera와 Axum으로 작성되어 있으며, 컴파일에는 약 10초가 걸린다. 코드 자체는 크지 않지만 의존성이 많이 따라붙는 구조였다.

기존 Rust 구성의 가장 큰 부담은 테스트 비용이었다. E2E 테스트에는 Playwright 설정이 필요했고, 모킹이 어려워 격리된 데이터베이스 네임스페이스와 모킹 서비스까지 필요했다. 심지어 Playwright가 헤드리스 모드에서 앱과 상호작용하도록 별도 내부 API 크레이트도 만들어야 했다.

이처럼 복잡한 테스트 환경은 소규모 개인 프로젝트에게는 과한 부담이었다. Ruby와 Ruby on Rails는 이러한 문제에 대한 간결한 대안으로 검토됐다.

LLM 기반 언어 비교 평가

개발자는 여러 LLM 인스턴스를 활용하여 복잡도, 안정성, 테스트 용이성 등을 종합적으로 비교했다.

평가 항목	Rails	Rust/Axum/Diesel
개인 개발자 적합성	90	45
개발 속도	90	50
단위 테스트 용이성	90	20
통합 테스트 용이성	80	30
안전성	65	95
성능	50	95
합계	710	480

결과는 명확했다. Rails는 총점 710으로 Rust/Axum/Diesel의 480보다 1.47배 높은 점수를 기록했다. Rails는 개인 개발자 적합성, 개발 속도, 단위 테스트 용이성에서 모두 90점을 기록하며 압도적이었다.

반면 Rust/Axum/Diesel은 안전성과 성능에서 각각 95점을 받으며 강점을 보여줬지만, 단위 테스트 용이성 20점, 통합 테스트 용이성 30점으로 실무에서 큰 벽에 부딪히는 것으로 나타났다.

변환 결과

Local Qwen3.6으로 원샷 변환을 진행한 결과는 충격적이었다. Rust 코드는 총 14,943줄이었는데, Ruby 코드로 변환 후 3,322줄로 줄었다. 이는 무려 77% 감소에 해당하며, Ruby 1줄당 Rust 약 4.49줄이 되는 셈이다.

변환에 소요된 시간은 약 30분이었다. 변환된 Ruby 코드를 훑어본 범위에서는 깨끗하고 관용적으로 보인다고 한다. 물론 버그 가능성은 남아있고, 아직 실행 검증은 되지 않은 상태다.

변환 후 Ruby 테스트는 놀라울 만큼 간결하다.

VCR.use_cassette("llm_call") doresult = LlmClient.match(entry, data_list)expect(result.results.size).to eq(data_list.size)end

반면 Rust 테스트는 모킹 제공자를 직접 구현해야 한다.

struct MockProvider {responses: Arc>>,call_count: AtomicUsize,}#[async_trait]impl Provider for MockProvider {async fn match(&self, entry: &Entry, data_list: &[Data]) -> Result> {// ... 구현 필요}}

Ruby의 타입 안정성 문제, 어떻게 해결하나

Ruby의 가장 큰 약점은 타입 안정성이 부족하다는 것이다. 이를 보완하기 위해 Sorbet이나 에이전트 기반 타입 추기를 활용할 수 있다. Rails + Sorbet 조합의 점수가 695로, 순수 Rails(710)보다와즈카니저카ㅉ타는 것도 흥미로운 결과다.

또한 Ruby/Rails는 "batteries included" 철학에 가까워, 3GiB 규모의 컴파일된 의존성보다 나은 선택이라는 평가도 나왔다.

커뮤니티의 반응

물론 이 실험에 대한 Hacker News 댓글들은 회의적이었다. 핵심 비판은이하기점이다.

첫째, 검증되지 않은 변환이라는 점이다. 작성자는 "실행되는지 보려고 Start도 눌러보지 않았지만 블로그 글은 썼다"는 반응을 받을 정도로 실제로 작동 여부를 확인하지 않았다.

둘째, LLM이 직접 변환을 수행한 것이 아니라 대리 수행을 시킨 것이라는 지적이다. 실제 변환을 직접 한 것도 아니고 깊이 생각한 것도 아닌데 굳이 읽을 이유가 없다는 것이다.

셋째, 향후 소프트웨어 개발의 방향성에 대한 우려다. 어느 댓글로는 "앞으로의 소프트웨어 개발이 이렇게 간다"는 우려가 나왔다. UML과 RUP 진영이 복수에 성공한 셈이라는 혹담까지 나왔다.

하지만 다른 한편으로는 트레이드오프를 충분히 조사했다는도 있었다. "생각을 안 했다'는 평가는 부당하다. 버튼 누르고 YOLO 한 게 아니다"라고 반박하는 댓글도 있었다.

이 실험이 시사하는 바

이 사례는 2026년 현재 AI-assisted 개발의 현실을 보여준다.

AI는 코드를 생성하지만, 그 품질을 검증하는 것은 여전히 인간의 몫이다. 30분 만에 77% 코드 감소라는 숫자만 보면 매력적이지만, 실행도 검증하지 않은 변환 결과를 신뢰할 수 있는지는 별개의 문제다.

언어와 프레임워크의 선택 기준이 변하고 있다. 전통적으로는 성능과 안전성이 가장 중요했지만, AI가 코드를 생성하는 시대에는 개발 속도와 테스트 용이성이 더 중요한 선택 기준이 될 수 있다.

Ruby on Rails의 철학이 다시 주목받고 있다. "충분히 좋음(Good Enough)"이라는 평가가 나온 만큼, 완벽함을 추구하기보다 빠르게 결과물을 만드는 것이 더 실용적이라는 관점이 힘을 받고 있다.

물론 아직 실행 검증이 되지 않은 이 실험이 실제로 동작하는지는 아무도 모른다. 그러나 그것이 이 실험에서 얻을 수 있는 가장 중요한 교훈일 것이다. AI가 만들어낸 코드는 반드시 인간이 검증해야 한다.

---

📚 출처

• Rust에서 Ruby로 — GeekNews 원문

• xlii.space 원문

---

📚 출처

• https://news.hada.io/topic?id=29968