루비의 바이마르 시대를 살아가며

AI 요약

RailsWorld 기조연설에서 DHH가 Rails와 Ruby에 무관심한 듯한 태도를 보인 일을 두고, 글쓴이는 생태계가 쇠퇴한다고만 볼 필요는 없다고 말합니다. 오히려 LLM이 구현 부담을 낮추면서 그동안 Ruby에서 해결하기 어려웠던 문제를 직접 다루는 움직임이 나타났다는 주장입니다. 글쓴이는 이를 구질서가 흔들리던 바이마르 공화국 시기의 예술·기술적 활기에 빗댑니다. 역사적 비극이 아니라, 기존 질서의 관심과 감독이 약해진 틈에서 새로운 작업이 나왔다는 측면을 가리킵니다.

LLM이 바꾼 구현 부담

글쓴이는 모든 코드를 손으로 작성하는 방식이 지속 가능하지 않다는 점을 인정합니다. 하지만 LLM이 코드를 한 번에 완성해 준다는 데 초점을 맞추지 않습니다. 분야 지식을 가진 개발자가 구현 과정의 반복 작업을 줄이고, 더 크고 복잡한 라이브러리를 만들고 다듬어 다른 사람과 공유하는 데 가치가 있다고 봅니다. 결과물을 한 번에 완성하기보다, 원하는 설계를 알고 여러 차례 반복해 품질과 성능을 높여야 한다고 덧붙입니다.

Ruby에서 달라진 라이브러리 상황

PDF 생성은 Ruby의 오래된 불편 중 하나였습니다. 글쓴이가 제시한 기존 선택지는 Chromium을 실행하는 Gotenberg나 Ferrum, 수동 배치 작업이 많은 Prawn, 빌드와 의존성 관리가 까다로운 wkhtmltopdf였습니다. 최근에는 서로 다른 방식의 라이브러리 두 개가 등장했다고 설명합니다. sghtmltopdf는 WebKit 대신 Servo 기반 Rust 레이아웃 엔진을 사용하고 CSS 일부를 지원합니다. 글쓴이는 Ferrum에서 옮기는 데 약 한 시간이 걸렸으며, 6쪽짜리 송장을 표와 벡터 그래픽을 포함해 생성하는 데 수십 밀리초가 걸렸다고 말합니다. stationery는 Phlex 스타일의 뷰 컴포넌트와 레이아웃 요소를 사용해 PDF를 텍스트 출력처럼 다룹니다. 글쓴이는 두 라이브러리 모두 성능과 사용성 면에서 쓸 만하다고 평가합니다.

PDF 외에도 Qt 바인딩 개발이 다시 진행 중이고, Shoes를 되살린 Scarpe, 정기적으로 업데이트되는 RMagick, 작업 중인 GD 바인딩을 언급합니다. ETL에서 쓰는 Parquet도 예로 듭니다. 글쓴이는 며칠 만에 스트리밍과 압축, Parquet 암호화를 지원하는 Ruby 라이브러리 herringbone을 만들었다고 합니다. 예전에는 이런 작업이 수개월 걸렸을 것이라며, LLM을 활용해 저수준 비트 인코딩에 드는 시간을 줄이고 API 설계와 개선에 집중했다고 설명합니다.

새 라이브러리와 성능 개선

글쓴이는 gRPC와 Protobuf도 Ruby에서 다루기 까다로운 영역으로 꼽습니다. 기존 구현에는 스레드 중단, fork 호환성, Protobuf 호환성 문제가 있고, 공식 Ruby Protobuf gem은 네이티브 코드와 별도 컴파일러에 의존한다고 지적합니다. 이를 다음 개선 대상으로 삼고 싶다고 밝힙니다. 성능 개선 사례로는 Sam Ruby의 Roundhouse 교차 컴파일러와 Tobi가 Rails 대신 순수 Ruby, Falcon, Ractors, SQLite를 사용해 Campfire를 다시 만든 작업을 소개합니다. 후자는 HTML 결과를 바꾸지 않으면서 페이지를 15~27배 빠르게 제공했다고 전합니다.

gem 이름 증가 통계

글쓴이는 ClickHouse가 제공하는 RubyGems 데이터를 분석했습니다. 다운로드 수나 버전 수가 아니라 지난 12개월 동안 처음 등록된 gem 이름을 직전 12개월과 비교했습니다. 오타를 노린 삭제 gem과 소수 계정이 대량으로 올린 gem 계열을 제외한 결과, 2025년 10월까지 1년 동안 약 4,600개였던 신규 이름이 그다음 1년에는 약 8,900개로 늘었습니다. 약 1.9배입니다. 월간 수치는 2025년 내내 400~500개 수준이었지만 2026년 3월부터 800~1,600개로 뛰었다고 설명합니다. 누가 더 많이 만들었는지는 이 데이터만으로 알 수 없지만, 필요한 도구를 직접 만들고 공개하는 사례가 늘었다는 것이 글쓴이의 해석입니다. 그는 Ruby 생태계가 허락을 기다리기보다 당장 불편한 문제를 해결해야 한다고 주장합니다.

Lobsters 반응

• @kristoff — 저는 그가 더는 사랑하지 않는 장난감과 공동체를 그냥 두고 떠날 수도 있었다고 진심으로 생각합니다. 독설 섞인 폭탄 발언으로 박수를 더 모으기보다 말입니다. 떠나기 전에 불을 지른 건 Ruby/Rails에서 밀어내야 한다고 주장한 사람들에게 답하려는 행동이었을 가능성이 큽니다. Ruby 공동체에 가장 건강한 일은 아마 이 사람에 관한 이야기를 그만하는 것이겠지만, 그게 쉽지 않다는 점은 이해합니다.
• @gspr — LLM이 계속 남을 것이고 모든 줄을 손으로 입력하는 방식은 더는 지속 가능하지 않다는 말이 분명하다고요? 프로그래밍의 병목이 입력 작업인 사람들은 대체 누구입니까? 손가락이 발목을 잡을 정도라면 제 머리보다 몇 배는 뛰어난 두뇌를 가진 사람들이겠군요!
  • @k749gtnc9l3w — 병목이 그것 하나뿐인 건 아니지만, 비교적 충분히 생각해 둔 프로그램 설계가 있어도 시도하지 못할 때가 있습니다. 구현하면서 생각해야 하는 부분도 있고, 너무 뻔해서 지루한 보조 작업도 있습니다. 의지력을 쓸 더 나은 곳이 늘 있다 보니 그런 일을 질질 끌게 됩니다. LLM이 그런 부분을 제대로 만들지는 못할 겁니다. 특히 체크포인트를 남길 수 없는 작업 흐름을 배우는 데 시간을 쓰기 싫어서, 저는 64GiB 메모리와 시스템 메모리 속도 안에서 돌려야 합니다. 그래도 글쓰기보다 디버깅이 덜 지루할 때가 있습니다. 함께 만들 사람을 찾는 일도 생각해 봤습니다. 저는 특이한 걸 원합니다. 직접 만들어서 계속 쓰는 특이한 것들이 있는데, 시험 삼아 써 보고 기능을 요청할 사람을 찾으려다 실패했습니다. 누군가가 원하는 것과 비슷하다고는 하지만요. 몇몇 사람은 자기 작업 흐름에서 차악으로 다른 특이한 것들을 받아들였습니다. 이제 LLM에 생성시킨 것은 반쯤 표절이라고 생각합니다. 그 때문에 쓸지 말지는, 이미 여기저기서 특이한 조각을 주워 맞추고 어설프게 바꿔 썼는지, 독창성을 주장하는지에 따라 달라질지도 모릅니다. 많은 비즈니스 환경에는 실제 업무 로직을 둘러싼 뻔한 보조 코드가 잔뜩 있습니다. 상대 시스템과 통합해야 하는데 그쪽은 제대로도, 안정적으로도, 예측 가능하게도 동작하지 않으니 보조 코드도 제대로 만들기 어렵습니다.
• @zem — 정말 좋습니다. Claude가 프로덕션 코드를 쓸 만큼 나아진 뒤 계속 생각해 온 점과도 맞닿아 있습니다. LLM의 진짜 가치는 누구나 자기 작업용 코드를 한 번에 만들게 하는 데 있지 않습니다. 이제 분야 전문가가 더 크고 복잡한 라이브러리를 쉽게 만들어 배포할 수 있고, 다른 사람이 같은 작업을 반복하지 않아도 모두가 혜택을 누리는 데 있습니다.
  • @nertzy — 저에게 흥미로운 점은 좋아하는 도구를 연결하는 작은 프로젝트를 여럿 만들고 공개하는 데 도움이 됐다는 것입니다. 특정 테스트 라이브러리용 Tree-sitter 확장이나 편집기 플러그인 같은 것들입니다. 저는 Rust를 전혀 모르지만, 좋은 타입 시스템과 자원을 정리하는 시스템 설계는 잘 압니다. Zed의 터미널 도구가 에이전트에서 호출되는 방식을 보고 파일 핸들 누수를 없애는 Pull Request도 기여했습니다. 새 언어의 문법과 관용구를 익혀야 하는 진입 장벽 없이 객체 설계 개선에 기여할 수 있는 일입니다. Ruby나 JS, C++, Java, C#으로 써야 했다면 쉽게 했을 텐데, 마침 Rust로 작성된 일이었습니다. 이제 Rust로도 쉽게 쓸 수 있고, AI가 혼자 도달한 수준보다 높은 설계를 반복해서 이끌어 낸 제 판단도 여전히 가치가 있었습니다.
• @noirscape — 반가운 이야기입니다. Ruby는 사용하기 편하고 즐거운 언어입니다. 다만 Ruby 생태계가 엉망이거나 성능 문제 때문에 언어 자체를 나쁘게 보이게 했습니다. LLM이 Ruby의 약점을 개선하는 데 도움이 된다면 좋은 일입니다. Python 라이브러리가 C 바인딩을 제공하는 것보다 나은 결과를 내리라고 기대합니다. 동영상 변환에서는 ffmpeg-python을 쓰는 대신 동영상 바이너리를 CLI 하위 프로세스로 실행하는 편이 낫습니다. Python 생태계가 상당히 잘 갖춰졌는데도 그렇습니다. Ruby 공동체가 문서와 유지보수에 사람을 계속 참여시키고, 나치가 들어오지 못하게 하길 바랍니다. 요즘 Ruby 이야기에 후자가 자꾸 등장하는 점은 안타깝습니다.
  • @weaksauce — Ruby 생태계가 엉망이어서 언어 자체를 나쁘게 보이게 했다는 말은 15~20년 전에는 맞았을지 모르지만, 2.x가 나온 뒤 성능은 크게 좋아졌고 Python보다 좋거나 비슷해졌습니다. Twitter가 엄청나게 커졌는데도 규모 확장 방법을 제대로 몰랐던 일이 실패의 원인이었습니다. 생태계도 마찬가지입니다. Bundler는 의존성을 잘 관리하는 훌륭한 도구입니다. Bundler가 없던 시절은 거칠었을지도 모릅니다. Ruby는 역사상 꽤 오랫동안 Python보다 앞서 있었고, 널리 호평받는 Rust의 Cargo에도 영감을 줬습니다.
• @eduard — Ruby에서 흔히 겪는 골칫거리 중 하나가 PDF 생성이라는 대목이 놀랍습니다. Go로 생계를 꾸리고 Elixir를 취미로 쓰는 사람으로서, 웹 앱에서 흔한 기능이 Ruby 생태계에서는 그렇게 번거로웠다는 사실이 정말 놀랍습니다.
  • @weaksauce — HexaPDF라는 선택지가 있었고 지금도 있습니다. 평판이 아주 좋습니다. 무료만큼 싸지는 않지만, 사업에 쓰지 않는다면 무료로 사용할 수 있습니다. 사업에 쓴다면 서버 한 대당 연 680달러를 저자에게 내거나 앱을 오픈소스로 공개하면 됩니다.

원문: Julik / 번역·요약: Trawling