▲

Rust에서 Ruby로

 (xlii.space)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Rust 웹앱 크레이트를 Ruby on Rails로 옮겨보는 개인 프로젝트 실험이며, 대상은 Tera와 Axum 기반 14,943줄 코드임
  • 기존 Rust 구성은 Playwright E2E, 격리 DB 네임스페이스, 모킹 서비스, 내부 API 크레이트까지 필요해 테스트 비용이 큼
  • LLM 비교에서 Rails는 총점 710으로 Rust/Axum/Diesel의 480보다 높고, 개발 속도와 단위 테스트 용이성이 강점으로 평가됨
  • Local Qwen3.6 원샷 변환은 약 30분 걸렸고 Ruby 코드는 3,322줄로 줄었지만, 아직 실행 검증은 안 됨
  • Rails는 기본 기능과 간결한 테스트가 장점이며, Ruby의 타입 안정성 부족은 Sorbet이나 에이전트 기반 타입 추가로 보완 가능함

전환 실험의 배경

  • 개인 프로젝트의 일부인 Rust 웹앱 크레이트가 Ruby on Rails 전환 대상으로 선택됨
    • 전체 프로젝트는 약 3만 줄 규모이고, 전환 대상 크레이트는 Tera와 Axum으로 작성된 웹앱에 가까움
    • 전환 대상 Rust 코드는 총 14,943줄이며, 컴파일에는 약 10초가 걸림
    • 코드 자체는 크지 않지만 의존성이 많이 따라붙는 구조임
  • 기존 Rust 구성은 테스트 비용이 높음
    • E2E 테스트에는 Playwright 설정이 필요함
    • 모킹이 어려워 격리된 데이터베이스 네임스페이스와 모킹 서비스가 필요함
    • Playwright가 헤드리스 모드에서 앱과 상호작용하도록 별도 내부 API 크레이트도 필요함
  • Ruby와 Ruby on Rails는 간결한 대안으로 검토됨
    • Ruby는 타입이 없어 안정성이 Rust보다 떨어질 수 있음
    • Sorbet을 쓰면 Ruby에서도 타입 안정성을 일부 보완할 수 있음
  • 여러 LLM 인스턴스로 복잡도, 안정성, 테스트 용이성 등을 비교한 결과 Rails 점수가 더 높게 나옴
    • Rust/Axum/Diesel 합계는 480, Rails는 710, Rails + Sorbet은 695로 계산됨
    • Rails는 개인 개발자 적합성 90, 개발 속도 90, 단위 테스트 용이성 90으로 높게 평가됨
    • Rust/Axum/Diesel은 안전성 95, 성능 95로 높지만 단위 테스트 용이성 20, 통합 테스트 용이성 30으로 낮게 평가됨
    • 단순 합계 기준으로 Rails 앱이 1.47배 더 나은 결과를 낼 수 있다고 판단됨

변환 결과와 검토 포인트

  • Local Qwen3.6으로 비교적 작은 프로젝트를 원샷 변환함
    • 변환에는 약 30분이 걸림
    • 아직 실행해보지 않아 실제 작동 여부는 확인되지 않음
  • 가장 큰 변화는 코드 줄 수 감소임
    • Rust 파일 총 줄 수: 14,943줄
    • Ruby 파일 총 줄 수: 3,322줄
    • 줄 수가 77% 감소했고, Ruby 1줄당 Rust 약 4.49줄에 해당함
  • 변환된 Ruby 코드는 훑어본 범위에서 깨끗하고 관용적으로 보임
    • 버그 가능성은 남아 있음
    • 이후 더 면밀히 검토할 예정임
  • 추가 검토 포인트는 타입 보완, Rails의 기본 기능, 테스트 단순화임
    • 에이전트를 이용해 타입을 추가하면 타입 안정성 문제를 완화할 수 있음
    • Ruby/Rails는 “batteries + kitchen sink included”에 가깝고, 3GiB 규모의 컴파일된 의존성보다 낫다고 평가됨
    • 테스트는 훨씬 쉬워질 것으로 기대됨
  • Ruby 테스트 예시는 VCR.use_cassette("llm_call")로 LLM 호출을 감싸고 결과 크기를 검증하는 짧은 형태임 
      VCR.use_cassette("llm_call") do
    result = LlmClient.match(entry, data_list)
    expect(result.results.size).to eq(data_list.size)
  end
  • Rust 테스트 예시는 모킹 제공자를 직접 구현해야 하는 더 긴 형태임
    • Arc<RwLock<Vec<Response>>>, AtomicUsize, async_trait, tokio::test 등을 사용함
    • 응답 목록과 호출 횟수를 관리하는 MockProvider를 만들고, Provider 트레이트의 match를 구현한 뒤 테스트에서 결과와 호출 횟수를 검증함
  • 개인 프로젝트이기 때문에 과감한 선택이 가능하며, Rust에서 Ruby로의 전환은 앞으로 면밀히 검토될 예정임

함께 보면 좋은 글 β

▲
GN⁺   [-]
Hacker News 의견들

  • 믿기 힘든 얘기임. “기술적으로 긁고 싶은 가려운 부분이 있었고, 로컬 AI가 30분 만에 작업을 끝냈다. 실행되는지 보려고 Start도 눌러보지 않았지만, 블로그 글은 썼다…”라는 식으로 들림

    • 지금 첫 페이지 1위라는 건, 프로젝트가 실제로 동작하지 않아도 상관없다는 뜻임. 독자들도 글을 제대로 읽지 않았을 테니까
      물론 봇이 밀어 올린 게 아니라면
    • 2016년: 새 JavaScript 라이브러리를 봐주세요!
      2026년: 내가 쓰지 않은 작업물을 봐주세요!
      2036년: C라는 고대 라틴어로 200줄을 쓴 방법
    • “믿기 힘들다”기보다는, 2026년 기준으로는 꽤 평범한 일에 가까움
    • 다만 5시간 동안 검토는 했음. 그러니 ¯_(ツ)_/¯

  • 처음엔 흥미로운 글일 줄 알았는데, 변환에 LLM을 썼다는 대목에서 관심이 바로 사라짐. “이걸 하고 싶어서 부하에게 시켰고, 그 이야기를 들려주겠다”와 비슷함
    실제 변환을 직접 한 것도 아니고 깊이 생각한 것도 아닌데 굳이 읽을 이유가 없어 보임

    • 가장 큰 문제는 작성자가 검증조차 하지 않았다는 점임. 여러 모델을 조합한 대형 도구가 6시간 동안 변환을 돌린 뒤, 까다로운 계산이나 논리를 어떻게 처리했는지 수동으로 확인해 보면 스텁이나 하드코딩된 참 반환이 들어 있는 경우를 봤음
      그래서 스모크 테스트만 돌리면 성공한 것처럼 보일 수도 있음
    • 더 큰 문제는 앞으로의 소프트웨어 개발이 이렇게 간다는 점임
      장인적 프로그래밍을 제외하면 프로그래밍 언어 자체는 별로 중요하지 않게 됨
      LLM이 개선될수록 결국 명세를 어떤 종류의 언어로 생성할지만 정하는 문제가 될 것임
      UML과 RUP 진영이 복수에 성공한 셈임
    • 핵심은 코드를 직접 썼느냐가 아니라, 차이를 보고 아마도 최적은 아닐 선택을 했다는 데 있음
      다른 댓글에서도 말했듯이 꽤 광범위하게 검토했음. 큰 프로젝트는 아니라서 몇몇 매운 부분을 빼면 대부분 웹 앱임
      “생각을 안 했다”는 평가는 부당하다고 봄. 버튼 누르고 YOLO 한 게 아님
      트레이드오프와 결과를 조사했고, Rust 코드 조각과 Rails의 차이는 실제로 컸으며, Rust 앱의 테스트 가능성은 2개월 동안 고민한 주제였음
      LLM 애호가들이 말하듯이 맥락이 중요함 ;)

  • 어떤 언어와 프레임워크도 Ruby on Rails만큼 개발자 행복을 우선시하는지는 잘 모르겠음

    • Rails 프로젝트에서 일할 때만큼 불행했던 적이 거의 없음. 사이트에서 버그를 보고, 잘못 렌더링되는 뷰를 찾으려고 grep을 돌림. 해당 섹션을 렌더링하는 메서드 호출을 발견하고, 메서드 이름으로 다시 grep하면 결과가 0개임
      어딘가에서 합성되는 무언가라 어디에 있는지 알 수 없고, 결국 하던 일을 멈추고 한 시간 동안 문서를 읽게 됨. 하루 종일 Rails만 쓰는 사람에게는 괜찮겠지만, 설정보다 관례는 나에겐 거대한 안티패턴임
    • Elixir와 Phoenix에서도 비슷한 느낌을 받지만, method_missing이라는 발등 찍는 장치는 없음
    • 실리콘밸리 취향의 커뮤니티에서 매력적으로 보이지 않더라도, Java와 .NET 프레임워크로도 꽤 만족스럽게 일해 왔음
      행복이 항상 성능으로 이어지지는 않음. Twitter가 JVM과 Scala로 옮기기 전의 유명한 로고 사례가 떠오름
      Ruby on Rails가 명성을 얻었지만, 이미 Tcl 기반의 AOLServer와 Vignette에서도 비슷한 경험이 있었음
      포르투갈 스타트업에서도 자체 변형을 만들었고, 창업자들은 이후 OutSystems를 만들었음. 이는 웹사이트와 분산 시스템 개발을 위한 초기 그래픽 RAD 도구 중 하나였고, 저코드/노코드로 JVM 또는 CLR 인프라를 대상으로 했음
      그래도 이제 CRuby에 JIT가 기본으로 들어가는 모습을 보는 건 반가움
    • 기껏해야 단기적인 행복이고, 유지보수성·성능·신뢰성·확장성 등 다른 모든 아키텍처 특성을 대가로 치르는 것에 가까움

  • 이미 간결한 Ruby on Rails 코드를 더 극단으로 밀어붙이는 propel_rails라는 gem 묶음을 만들었음. API 컨트롤러와 concern 같은 최상위 클래스를 생성하고, 거기서 전체 RESTful 리소스(모델, 컨트롤러, 직렬화기, 단위 테스트와 E2E 테스트)를 보일러플레이트 0으로 만들어냄
    컨트롤러는 결국 API가 허용할 속성 목록만 담게 되는데, RESTful 액션은 자동 생성되기 때문임. 완전히 설명하기는 조금 어렵지만 Ruby의 메타프로그래밍 힘은 정말 놀라운 일을 쉽게 만들어줌

    • 이건 CRUD를 정제한 형태처럼 들림
      도메인 모델 기준으로 동작한다고 보면 될까?
    • rubygems에서는 찾을 수 있는데, 거기서 연결된 GitHub 링크는 404가 뜸

  • 비슷한 상황에 있음
    Go와 Rust를 좋아하고, 둘 다 장단점이 있는 훌륭한 언어임. 하지만 안타깝게도 둘 중 어느 것으로도 SaaS 앱을 만들지는 못했음. 네모난 말뚝을 둥근 구멍에 넣는 느낌이랄까
    내가 크게 틀렸을 수도 있지만, SaaS 도구에는 딸려 오는 장치가 많고 그걸 새로 발명하고 싶지는 않음
    RoR은 “충분히 좋음”. 원할 때 타입을 도입할 수 있고, 빠르게 만들 수 있으며, 도구도 괜찮은 편임
    첫 실무는 PHP였는데 함정이 너무 많았음. Ruby는 전자상거래 쪽으로 조금 더 기울어 있는 듯해서 흥미로웠고, Shopify에도 충분하다면 괜찮다고 봄

  • Rust에서 Ruby로 바꿔도 말이 되는 상황이라면, 처음에 Rust를 고른 것이 실수였던 셈임

    • 이 글을 아주 잘 요약한 말이고, 공유하기로 한 이유이기도 함

  • Ruby가 Rust보다 느리다고 생각하는 사람들은, Ruby가 이제 실제로는 Python보다 빠르고 Go나 Rust보다는 느리다는 걸 알면 놀랄 것임

    • 보통 속도보다 메모리 사용량이 더 중요했음. 대부분의 Ruby 애플리케이션은 Ruby가 아니라 데이터베이스 때문에 속도가 제한됨
      하지만 백그라운드 작업자가 여럿 있고 각각 2GB 이상 메모리를 먹기 시작하면 금방 누적됨
      프로덕션 Rust 서비스를 하나 작성했는데, 속도보다 더 인상적이었던 건 그 서비스가 30MB 메모리로 돌아갔다는 점임
    • Ruby가 Rust보다 느리다고 생각하는 사람이 왜 Python보다 빠르다는 사실에 놀라야 하는지 모르겠음. 둘이 무슨 관련이 있음?

  • 자극적인 얘기지만, 주변 평민들에게 900+ IQ를 과시하는 데는 좋을지 몰라도, 똑똑하고 재능 있는 개발자 중 많은 사람이 Rust를 별로 좋아하지 않음. 어떤 이들은 Rust 한 줄을 쓰느니 자기 프로그래밍 언어와 컴파일러를 직접 만들기를 택함
    Jonathan Blow의 Jai와 Ginger Bill의 Odin이 떠오름
    널리 쓰이는 아름다운 라이브러리와 프레임워크를 만든, 창의성과 깊이가 증명된 사람들도 더 많지만 여기서 공간을 낭비하고 싶진 않음
    다만 Rust에는 멋진 마초 클럽이자 끈끈한 형제단이 있음

    • Rust 커뮤니티는 “마초 클럽”과는 최대한 거리가 먼 편임

  • Claude는 Rails 앱에서 정말 잘 작동함. 이 글의 작성자도 짚었듯이 Ruby는 적은 코드로 많은 일을 하게 해주고, Rails는 설정보다 관례를 쓰기 때문에 Rails 앱은 더 간결해짐
    Claude가 Rails 앱을 잘 쓰는 이유에 대한 한 가지 가설은 토큰 효율성임
    예전에 프로젝트별 토큰 효율성을 측정하고 비교하려는 이 프로젝트를 봤는데, Rails가 꽤 좋은 결과를 보임
    https://felipemrvieira.github.io/SyntaxTax/dashboard/

  • 프로젝트 크기를 볼 때 가끔 놀람. 3만 줄 코드베이스가 작다고? 상한이 높다는 건 알지만, 3만 줄이면 엄청난 정보와 동작상의 미묘함을 담을 수 있음
    어쩌면 Go를 쓰는 백엔드/네트워크 쪽에 집중해 온 내 배경 때문일 수도 있음. 1만~1만5천 줄을 넘어서면 보통 코드베이스 전체 모델을 머릿속에 유지하기 어려워져서 꽤 부담스러웠음

    • 무엇을 만드느냐에 크게 달림. 프런트엔드가 여러 개인 SaaS 앱은 3만 줄에 쉽게 도달함
답변달기