Ruby on Rails 78번째 소식

2025년의 마지막 날, 한 해를 정리하며 뉴스레터를 보내요.

올해 Ruby와 Rails를 둘러싼 흐름을 돌아보면, 유난히 **“조용하지만 단단한 변화”**가 많았던 한 해였던 것 같아요.

Ruby 4.0이 30주년이라는 상징적인 타이밍에 공개됐고, Rails는 화려한 신기능보다는 보안·운영·개발 경험 같은 매일 쓰는 부분들을 꾸준히 다듬어 왔어요.

SF Ruby Conf 2025에서도 같은 메시지가 반복해서 들렸어요.

사람과 커뮤니티, 실용성, 그리고 지금 당장 제품을 만드는 데 도움이 되는 기술이에요.

ERB를 버리지 않고도 더 나은 DX를 만들자는 이야기, AI 시대에도 Ruby가 “제품을 만드는 언어”로 충분히 경쟁력이 있다는 이야기, 오픈 소스가 오래 살아남기 위해 필요한 현실적인 비즈니스 모델에 대한 고민까지

올해의 Ruby 커뮤니티는 유행보다 지속성을 선택한 느낌이었어요.

이번 소식에서는

Ruby 4.0 릴리스의 핵심 포인트
SF Ruby Conf 2025에서 나온 주요 메시지들
“This Year in Rails”로 정리한 2025년 Rails의 변화
그리고 M&A 이후에도 Rails 모놀리스가 왜 여전히 유효한 선택인지에 대한 생각

을 함께 정리했어요.

한 해 동안 뉴스레터 읽어주셔서 정말 감사했고, 다가오는 2026년에도 Ruby와 Rails를 중심으로 실제로 도움이 되는 이야기를 계속 전해볼게요.

🎧 10분 요약 오디오로 들어보시겠어요? → YouTube로 듣기

새로운 소식

Ruby 4.0이 출시됐어요!

2025년 12월 25일, Ruby 4.0.0이 공식 출시됐어요.

Ruby가 탄생한 지 30주년을 맞아 공개된 메이저 버전인 만큼, 눈에 띄는 실험적 시도와 기반 개선들이 함께 담겼어요.

이번 릴리스는 “갑작스러운 파괴적 변화”보다는, 앞으로의 10년을 준비하는 정비에 가까운 인상을 줘요.

Ruby Box — 코드 격리를 위한 새로운 실험

가장 흥미로운 변화 중 하나는 Ruby Box예요.

클래스, 모듈, 전역 상태, 로드된 라이브러리를 격리된 공간에서 실행할 수 있는 실험적 기능이에요.

이걸 통해

전역 상태를 오염시키는 테스트
서로 다른 버전의 라이브러리를 동시에 로드
병렬 실행 시 안전한 실행 컨텍스트

같은 시나리오가 가능해질 수 있어요.

아직 실험 단계지만, Ruby가 “안전한 격리”라는 주제에 본격적으로 발을 들였다는 점에서 의미가 크다고 생각해요.

ZJIT — 새로운 JIT 컴파일러의 등장

Ruby 4에는 ZJIT이라는 새로운 JIT 컴파일러도 추가됐어요.

기존 YJIT과는 다른, 보다 전통적인 SSA 기반 구조를 채택했고 Rust로 작성된 것이 특징이에요.

당장 프로덕션에서는 여전히 YJIT이 권장되지만, ZJIT은 앞으로 Ruby 성능 개선의 확장 가능한 실험장 역할을 할 가능성이 커 보여요.

Ractor 개선 — 병렬성의 현실화

병렬 실행 모델인 Ractor도 한 단계 정리됐어요.

메시지 전달을 위한 Ractor::Port가 추가되고, 내부 구조가 단순화되면서 실제 사용 가능성도 조금씩 높아지고 있어요.

“아직 어렵다”는 인식에서, “언젠가는 쓸 수 있겠다”는 방향으로 한 걸음 더 간 느낌이에요.

언어 & 표준 라이브러리 소소한 개선

*nil의 동작이 더 직관적으로 바뀌었고
논리 연산자를 줄 맨 앞에서 시작할 수 있게 됐어요
Array#rfind 같은 실용적인 메서드가 추가됐고
에러 메시지에 호출 위치 + 정의 위치가 함께 표시돼 디버깅 경험도 좋아졌어요.

Rails 앱을 바로 깨뜨릴 만한 변화는 거의 없지만, 코드를 더 읽기 좋고 예측 가능하게 만드는 개선들이 눈에 띄어요.

“대격변”보다는 “기반 다지기”

Ruby 4.0은 문법 혁명보다는,

격리
병렬성
성능 실험

같은 장기 과제에 대한 명확한 방향성을 보여주는 릴리스예요.

Rails 개발자 입장에서도 “지금 당장 뭘 바꿔야 한다”기보다는, 앞으로 Ruby가 어디로 가려는지 감각을 잡기 좋은 버전이라고 느껴져요.

함께 읽어보면 좋은 링크

SF Ruby Conf 2025 발표 영상 공개됐어요

Evil Martians 가 올해 가장 의미 있었던 순간으로 꼽은 이벤트가 바로 SF Ruby Conf 예요.

다양한 Ruby 커뮤니티 구성원들과 함께한 이 컨퍼런스를 직접 호스팅했고, 정말 많은 훌륭한 발표자들의 이야기를 들을 수 있었다고 해요.

그리고 컨퍼런스 발표 영상 중 첫 30개 세션을 모은 유튜브 플레이리스트가 공개됐어요.

이번 플레이리스트에는

실무 중심의 Ruby / Rails 사례
프론트엔드, 퍼포먼스, 테스트, DX
팀과 제품, 커리어에 대한 이야기까지

폭넓은 주제의 발표들이 담겨 있어요.

현장에 가지 못했더라도, 지금 Ruby 커뮤니티에서 어떤 이야기들이 오가고 있는지 한 번에 따라잡기 딱 좋은 자료예요.

플레이리스트: https://www.youtube.com/playlist?list=PLAgBW0XUpyOUOs3E0QnDrJRIqCJCueq5F

SF Ruby Conf 2025, 이렇게 시작됐어요

위에서 소개한 SF Ruby Conf 2025는 Evil Martians가 호스팅한 행사로, 오프닝 무대에는 Irina Nazarova와 Brittany Martin Springer가 올랐어요.

오프닝 메시지는 명확했어요.

이 컨퍼런스는 기술보다 먼저 사람과 커뮤니티를 이야기했어요.

Irina는 수십 명의 조직위원회·자원봉사자·발표자에게 감사를 전하며, SF Ruby Conf가 루비 커뮤니티 전체가 함께 만든 행사라는 점을 강조했어요.

여러 기업 후원 사례를 통해서도 Ruby on Rails가 여전히 비즈니스에서 선택받는 기술이라는 메시지가 자연스럽게 드러났어요.

이번 컨퍼런스의 목적도 아주 실용적이었어요.
더 많은 팀과 스타트업이 새로운 제품을 만들 때 Ruby on Rails를 선택하게 하는 것이에요.
이를 위해 배우고, 부족한 지점을 찾고, 오픈 소스로 함께 채워가자는 제안이 이어졌어요.

Brittany는 다시 코드로 돌아온 개인적인 경험을 나누며, 루비는 여전히 현실의 문제를 해결하는 ‘기반 언어’ 라고 말했어요.

이번 행사의 핵심 키워드는 단 하나, Practicality(실용주의) 였어요.

SF Ruby Conf 2025는 이렇게 “이야기보다 실행”, “유행보다 지속성”을 강조하며 문을 열었어요.

영상 요약: https://secondb.ai/summary/11636/

Herb → ReActionView (SF Ruby Conf 2025)

Marco Roth는 Rails 뷰 레이어의 미래를 이렇게 정리했어요.

ERB를 버리지 않고도, React·TypeScript 수준의 개발자 경험을 만들 수 있다.

핵심은 두 가지예요.

Herb: HTML 구조를 이해하는 ERB 파서

→ LSP·Linter·Formatter를 제공해 실시간 에러, 자동 포맷, 즉각적인 피드백을 가능하게 해요.

ReActionView: Herb를 Rails에 자연스럽게 통합하는 뷰 레이어

→ 기존 ERB를 그대로 쓰면서도 더 나은 디버깅과 생산성을 제공해요.

Marco가 전한 메시지는, 프런트엔드 복잡성 때문에 Rails를 떠날 필요는 없고, 문제는 언어가 아니라 ‘툴링과 피드백’ 이라는 거예요.

영상 요약: https://secondb.ai/summary/11637/

RubyLLM — Ruby로 만드는 AI 제품 (SF Ruby Conf 2025)

Carmine Paolino는 LLM 시대의 핵심을 이렇게 정리했어요.
이제 AI 개발의 중심은 모델이 아니라 ‘제품’이다.

RubyLLM은 Rails 개발자가 복잡한 프레임워크 없이 LLM API를 활용해 실제 쓰이는 AI 기능을 빠르게 만들 수 있게 해주는 라이브러리예요.

핵심 메시지는 분명했어요.

복잡한 에이전트 프레임워크는 필요 없어요
Claude, GPT, Gemini 등 어떤 모델이든 같은 인터페이스로 다뤄요
기본은 단순하게, 필요할 때만 설정을 늘리는 Rails식 접근이에요

Rails와의 통합도 강력해서, 제너레이터만으로 채팅·메시지·툴 호출 구조를 만들고 Hotwire로 JS 거의 없이 실시간 AI UI를 구현할 수 있어요.

또 하나 인상적이었던 점은 성능 전략이에요.
LLM 호출은 I/O 작업이기 때문에 Fiber + Async로 “1인 개발자 + 1대 서버” 구조에서도 충분한 확장성을 노려요.

이 발표의 결론은 AI 시대에 Ruby는 다시 강해질 수 있고, 그 이유는 ‘생산성과 제품 중심 개발’에 있다는 거예요.

영상 요약: https://secondb.ai/summary/11638/

Sidekiq, 오픈 소스와 비즈니스의 현실적인 미래

Mike Perham은 Sidekiq 13년 운영 경험을 바탕으로 오픈 소스를 어떻게 오래, 건강하게 유지할 수 있는지를 솔직하게 이야기했어요.

Sidekiq은 Redis 기반 멀티스레드 구조로 초당 수십만 개의 작업을 처리하는 Ruby 대표 백그라운드 잡 도구지만, 이 발표의 초점은 기술보다 지속 가능성이었어요.

핵심은 Open Core 모델이에요.
핵심 기능은 오픈 소스로 유지하고, Pro / Enterprise 기능은 유료 구독으로 제공해 VC 투자 없이도 1인 기업으로 장기 운영이 가능해졌어요.

또 하나 인상 깊었던 메시지는 이거예요.

“유지관리자는 영원하지 않다.”

Mike는 오픈 소스의 미래를 위해 투명한 거버넌스와 커뮤니티 중심 운영의 필요성을 강조했고, 그 실천으로 연 $100,000 규모의 Gem Fellowship을 발표했어요.
Ruby 오픈 소스 개발자에게 직접 자금을 지원하는 프로그램이에요.

이 발표는 이렇게 요약할 수 있어요.
오픈 소스는 열정만으로는 지속되지 않고, 명확한 비즈니스 모델과 커뮤니티 환원이 함께 가야 한다는 메시지였어요.

영상 요약: https://secondb.ai/summary/11639/

This Year in Rails — 2025 한 해 요약

2025년 Rails는 430명 기여자, 약 2,700 커밋, 14번 릴리스(Rails 8.1 포함) 로 꽉 찬 한 해였어요.
큰 방향은 분명했어요. 보안 강화 · 운영 현실화 · 개발 경험 개선이에요.

CI & 워크플로우: bin/ci 도입, devcontainer 스크립트 추가
보안: CSP nonce 자동화, CSRF 최신 헤더 활용, bundler-audit 기본 설정
설정 관리: Rails.app.creds로 ENV + credentials 통합
Active Job: 중단·재개 가능한 Continuations, 메일 bulk enqueue
DB & AR: 트랜잭션 격리 수준 지정, association deprecation, PG 가상 컬럼 지원
뷰 & 렌더링: markdown 지원 확대, 컬렉션 렌더링 block, 더 친절한 에러 출력

한 줄로 정리하면, Rails는 화려함보다 ‘매일 쓰기 좋은 프레임워크’로 더 단단해진 한 해였어요.

블로그 보기: https://world.hey.com/this.week.in.rails/this-year-in-rails-be7d24de

M&A 이후에도 살아남는 Rails 모놀리스

최근 잡코리아가 잡플래닛을 인수한다는 소식이 있었어요.

Rails 쪽에서 보면 은근히 생각해볼 지점이 많은데, 잡플래닛이 꽤 오랫동안 Ruby on Rails 기반으로 운영돼 온 서비스이기 때문이에요.

이런 경우 인수 이후에 흔히 떠올리는 “전면 리플랫폼”보다는, 이미 안정화된 Rails 모놀리스를 그대로 두고 검색·추천·AI 같은 고변화 영역만 외부 서비스로 분리하는 쪽이 훨씬 현실적인 선택이라고 생각해요. 실제로 Rails는 도메인 모델링, 권한 관리, 어드민, 리뷰·콘텐츠처럼 CRUD 중심 영역에서는 여전히 생산성과 안정성이 아주 강한 스택이기도 해요.

비슷한 사례는 해외에서도 여럿 볼 수 있어요. GitHub는 Rails 기반 서비스인 상태로 Microsoft에 인수됐지만, 핵심 웹 애플리케이션은 Rails를 유지한 채 인프라와 일부 서비스만 점진적으로 분리해 왔어요. Shopify 역시 Rails 모놀리스를 코어로 두고, 성능이나 확장성이 필요한 영역만 서비스화하는 전략을 오랫동안 유지해왔고요. 이 사례들의 공통점은 “Rails를 버리지 않았다”기보다, Rails가 가장 잘하는 역할에 집중시켰다는 점이에요.

잡플래닛 역시 비슷한 길을 가면 좋겠어요. Rails는 제품의 중심 도메인을 책임지고, AI 추천이나 데이터 분석처럼 빠르게 실험해야 하는 영역은 다른 스택과 느슨하게 결합하는 구조가 효율적이지 않을까요? 이번 인수를 통해서 Rails가 더 이상 “초기 MVP용 프레임워크”가 아니라, M&A 이후에도 충분히 살아남는 프로덕션 코어가 될 수 있음을 보여주길 바라봅니다.