지난 한 주 루비/레일즈 생태계를 한 문장으로 요약하면 “발견은 더 쉽게, 실행은 더 가볍게, 운영은 더 안전하게”였어요. Planet Ruby와 Ruby Community처럼 커뮤니티의 글과 사람을 한 곳에 모아 흐름을 읽기 쉽게 만드는 시도가 등장했고, Evil Martians의 TutorialKit.rb는 ruby.wasm 기반으로 설치 없이 브라우저에서 Ruby/Rails 튜토리얼을 ‘그대로 실행’하게 해주면서 학습/온보딩의 장벽을 크게 낮췄습니다.
운영 관점에서도 흥미로운 소식이 많았어요. 37signals의 Tenanted 접근처럼 “실수할 여지를 구조적으로 없애는” 멀티테넌시 설계가 다시 주목받고 있고, Delayed Job에서 Solid Queue로 옮겨 스케일링 병목을 풀어낸 실전 사례는 “Rails 기본 스택을 제대로 쓰면 운영이 더 단단해진다”는 걸 잘 보여줍니다.
마지막으로 AI 시대의 개발 감각도 계속 업데이트 중입니다. RubyLLM::Evals처럼 스프레드시트를 벗어나 Rails 안에서 프롬프트/모델을 평가하고 비용·지연·정확도를 스냅샷으로 비교하려는 흐름, 그리고 Rails 8의 내장 인증 생성기처럼 ‘기본값’을 넓혀가는 Rails의 방향성까지 함께 담았어요.
🎧 10분 요약 오디오로 들어보시겠어요? → YouTube로 듣기
새로운 소식
Planet Ruby 등장: 30일치 루비 블로그를 한 페이지에 모아주는 ‘LLM 필터링 피드’
Planet Ruby가 새로 나왔어요. Ruby Weekly의 Peter Cooper가 만든 사이트로, 루비 커뮤니티의 주요 블로그 글을 모아서 최근 30일 포스트를 한 페이지에서 매일 볼 수 있어요. 피드 목록은 feeds.opml로 관리하고, GitHub Actions가 30분마다 크롤링한 뒤 정적 페이지를 빌드해서 GitHub Pages로 배포해요. 재미있는 점은 새 글을 LLM(OpenRouter) 으로 한 번 더 걸러서 루비/레일즈와 무관한 글은 제외하고, 제목과 요약도 “살짝” 다듬어준다는 거예요(루비스트들이 가끔 올리는 식사일기까지 필터링해요 😄). 게다가 stdlib만 사용해서 의존성이 0이고 Gemfile도 없어요. 가볍게 운영되는 레퍼런스로도 꽤 좋아 보여요.
TutorialKit.rb 공개: 설치 없이 브라우저에서 Ruby/Rails 튜토리얼을 돌리는 ruby.wasm 툴킷
Evil Martians가 TutorialKit.rb를 공개했어요. ruby.wasm + WebAssembly/WebContainers를 활용해서 설치 없이 브라우저 안에서 돌아가는 Ruby/Rails 인터랙티브 튜토리얼을 만들 수 있는 툴킷이에요. 2025년 Ruby Association Grant 지원 프로젝트의 중간 보고 성격이기도 하고요. 파일 시스템/터미널 동기화, Ruby·YAML 하이라이팅, 무거운 Wasm 모듈을 위한 브라우저 캐싱 같은 “튜토리얼 UX”에 필요한 기능들을 JS 기반 TutorialKit에서 확장해 Ruby 환경에 맞췄다고 해요. 파일 하나(약 80MB)에 런타임+의존성을 통째로 넣는 방식부터, tarball로 분리 배포하는 방식까지 젬 번들링 전략도 비교·실험 중이고, 앞으로는 브라우저에서 HTTP 호출(프록시/CORS 포함) 지원을 넣어 LLM 같은 외부 API를 쓰는 튜토리얼도 가능하게 하려는 계획이에요. 지금도 npx create-tutorialkit-rb로 시작할 수 있고, 데모로 Action Policy 튜토리얼을 공개해 실제로 “브라우저 안에서 Rails 앱+터미널+DB+서버”가 돌아가는 경험을 보여줘요.
Ruby Community 런칭: Ruby 4.0.1 + Rails 8.2(alpha)로 만든 루비 개발자 커뮤니티 허브
Yuri Sidorov가 Ruby Community(rubycommunity.org) 를 공개했어요. 전 세계 Ruby 개발자 프로필을 모아 보여주고, 커뮤니티 맵과 함께 트렌딩 프로젝트/포스트/스타/기여자 같은 섹션으로 “요즘 누가/무엇이 뜨는지”를 빠르게 훑어볼 수 있는 허브예요. 또한 “Why Ruby?” 같은 홍보/아티클 성격의 콘텐츠는 별도 도메인(whyruby.info)으로 연결돼서 커뮤니티와 어드보커시를 함께 묶는 구성이에요. 무엇보다 이 사이트 자체가 Ruby 4.0.1 + Rails 8.2.0.alpha로 만들어졌고, 프로젝트가 오픈소스로 운영된다고 밝혀서 ‘Solid Stack 시대의 Rails 8.x 실전 예시’로 구경하는 재미도 있어요.
테넌트별 DB 연결로 데이터 유출을 막는 법: 37signals의 Tenanted 접근
Rails에서 멀티테넌시는 결국 **“다른 고객 데이터가 섞이지 않게 하는 것”**이 핵심인데요, 보통처럼 하나의 DB에 테넌트 키(account_id)를 붙여 관리하면 쿼리 한 줄 누락만으로도 운영에서 데이터가 새는 사고가 날 수 있어요. Mike Dalessio는 이런 “인적 오류”를 구조적으로 없애기 위해, 37signals가 테넌트별로 DB 연결 자체를 분리하는 방향을 고민해 왔다고 설명해요.
그 과정에서 나온 아이디어가 테넌트마다 SQLite 파일을 하나씩 두는 방식이에요. 파일 기반이라 빠르고, 복사/삭제/이동 같은 운영이 쉬워서 SaaS 배포 패러다임을 바꿀 수 있다는 거죠. 다만 전 세계 데이터센터로 확장하면 “쓰기 마스터 1개” 모델과 라우팅/장애조치 문제가 얽혀서 쉽지 않고, 그래서 현실적인 제약도 함께 공유해요.
이 실험의 핵심 결과물이 오픈소스 Active Record Tenanted gem이에요. SQLite뿐 아니라 MySQL/PostgreSQL로 확장 중이고, GDPR처럼 지역별 데이터 분리 같은 요구에도 도움이 되도록 설계됐어요. 특히 뷰 캐시나 Active Storage 같은 영역까지 테넌트 컨텍스트를 자동으로 묶어주고, 런타임에서 **“다른 테넌트 객체를 건드리면 즉시 예외”**를 내는 안전장치로 “잘못 쓰기 어렵게” 만들어 둔 게 인상적이에요.
데모에서는 Writebook을 예로 들어, 몇 줄 설정으로 서브도메인 기반 테넌트 접속을 붙이고 요청 시 미들웨어에서 테넌트를 감지해 해당 SQLite 파일로 즉시 연결하는 흐름을 보여줘요. 앞으로는 37signals의 ONCE 제품군에 적용해 실전 데이터를 쌓고, 장기적으로는 이 접근을 Rails 공식 기능으로 업스트림하는 게 목표라고 해요.
(원문 요약 링크: https://secondb.ai/summary/16514/?tab=my)
스프레드시트 대신 Rails 안에서 프롬프트를 평가해요: RubyLLM::Evals 공개
LLM 기능을 만들다 보면 “어떤 모델/프롬프트 조합이 비용 대비 성능이 좋은지”를 고르는 일이 생각보다 너무 어려워요. Sinaptia 팀은 그동안 스프레드시트로 평가를 관리했지만, 파일이 복제되고 포맷이 제각각이 되면서 비교/회귀 체크/코드 동기화가 무너지기 쉽다고 정리했어요.
그래서 RubyLLM::Evals라는 Rails 엔진을 만들어, 앱 내부에서 프롬프트(모델/프로바이더/시스템 지시문/템플릿/툴/스키마) 와 샘플(평가 케이스) 을 묶어 테스트하고, 실행 결과를 정확도·비용·지연시간과 함께 스냅샷으로 저장해 비교할 수 있게 했어요. 특히 요약/분류처럼 정답이 애매한 작업을 위해 LLM-as-a-judge를 “1급 평가 타입”으로 둔 점이 실용적이에요.
또 샘플을 프로덕션 데이터에서 바로 뽑아(예: Active Storage 파일 첨부) 작은 큐레이션 세트로 빠르게 반복 개선하고, 만족스러우면 그 설정을 그대로 운영 코드에서 실행할 수 있게 설계했어요. “프롬프트는 끝나지 않는다”는 전제에서, Evals(개선) + Monitoring(관측) 으로 드리프트/비용 폭증을 지속적으로 잡자는 메시지도 인상적이에요.
(원문 링크: https://sinaptia.dev/posts/evaluating-llm-prompts-in-rails)
Rails 8 내장 인증 생성기(rails g authentication) — Devise를 대체한다기보다 “기본값”이 바뀌는 신호
Rails 8에서 공식 인증 생성기가 들어오면서, “인증은 늘 Devise로 시작”이었던 팀들도 선택지가 넓어졌어요. 이 글은 생성기가 실제로 무엇을 만들고, Devise가 여전히 필요한 경우가 언제인지를 현실적으로 정리해줍니다. https://rubystacknews.com/2026/02/16/rails-8-authentication-why-the-new-built-in-generator-matters-and-what-it-means-for-devise/
rails generate authentication
rails db:migrate이렇게 **기본 인증 시스템(모델/컨트롤러/뷰/마이그레이션)**을 한 번에 세팅해줘요.
생성되는 구성은 대략 이런 느낌이에요.
-
User(bcrypt 기반), Session(세션 레코드를 DB에 저장), Current(CurrentAttributes)
-
Sessions/Passwords 컨트롤러(로그인·로그아웃·비밀번호 리셋) + 기본 폼 뷰
-
세션 레코드를 DB에 두고, signed cookie 토큰으로 세션을 복원하는 방식(감사/세션 무효화 등 운영 제어가 쉬움)
-
대신 회원가입(sign up)은 의도적으로 포함하지 않음 → 온보딩은 앱 성격에 맞게 직접 구현
그리고 중요한 결론: Devise는 여전히 “복잡한 인증 요구사항(확인 메일, MFA, OAuth 등)”이 있는 프로젝트에서 강력하고, 내장 생성기는 작고 유지보수 가능한 기본 인증이 필요할 때 특히 잘 맞는 쪽이에요.
Delayed Job → Solid Queue: 10년짜리 Rails 앱이 “선형 스케일링”을 얻은 마이그레이션 사례
Kaigi on Rails 2025 발표를 바탕으로, 실제 운영 중인 10년짜리 Rails 앱이 Delayed Job에서 Solid Queue로 갈아타며 병목을 해소한 사례 정리가 나왔어요. (이론이 아니라 “현장 운영” 관점이라 특히 좋아요.)
핵심은 단순해요:
-
Delayed Job은 DB row lock 기반이라 워커를 늘려도 경쟁/대기 때문에 처리량이 잘 안 늘어나는 구간이 생기기 쉽고
-
Solid Queue는 SKIP LOCKED 같은 전략으로 워커들이 서로를 덜 막게 만들어 throughput이 더 예측 가능해진다는 것.
– Delayed Job 스타일(단순화)
SELECT * FROM jobs WHERE processed = ‘no’ FOR UPDATE LIMIT 1;
– Solid Queue 스타일(단순화)
SELECT * FROM jobs_table FOR UPDATE SKIP LOCKED LIMIT 1;위 차이가 “워커 늘렸는데 왜 안 빨라지지?” 같은 운영 이슈를 설명해줍니다.
그리고 제일 실무적인 포인트: Solid Queue는 기본 모니터링이 약하니, 큐 상태/대기시간/처리량 같은 메트릭을 직접 만들었다는 부분이에요. “전환”보다 “관측”이 운영의 승부처라는 얘기라고 보여요.