Ruby on Rails 85번째 소식

이번 주 소식은 유독 “전환점”이라는 단어가 잘 어울리는 이슈들이 많았어요. RubyConf 2026 티켓 오픈 소식부터, Rails + AI 흐름이 본격화되는 SF Ruby Meetup 이야기, 37signals의 Upright 공개, Matz의 의사 결정이 드러난 Dev Meeting, Ruby on Whales 2026 업데이트, 그리고 RuboCop의 MCP 서버 실험까지.

공통적으로 느껴지는 메시지는 하나였어요.
Ruby와 Rails가 AI 시대에 맞춰 다시 한 번 재정렬되고 있다는 점이에요.

Rails는 “Convention over Configuration”이라는 20년짜리 철학이 AI와 만나면서 오히려 더 강해지고 있고, RuboCop은 LLM 에이전트와 직접 연결되는 방향으로 확장되고 있어요. 개발 환경은 Docker + Dip + LLM 격리 전략으로 표준화되고 있고, 커뮤니티는 여전히 Supporter 티켓과 장학 프로그램으로 다음 세대를 준비하고 있어요. 기술, 도구, 커뮤니티가 동시에 움직이고 있는 느낌이에요.

그리고 개인적인 소식도 하나 전하고 싶어요.

저는 이번 주말에 토론토로 주재원 출국을 앞두고 있어요.
다음 주부터는 Rails 대장이라고 불리는 Shopify가 있는 도시, 그리고 제가 한국의 Rails 대장이라고 생각하는 Karrot(당근마켓)이 자리 잡고 있는 그 도시에서 인사를 드리게 됐어요.

Rails 생태계의 한가운데에 조금 더 가까이 가서, 그 현장의 공기와 속도를 직접 느끼며 이 소식지를 이어가보려고 해요. 한국에서 바라보던 Rails와, 북미에서 체감하는 Rails가 어떻게 다를지도 궁금하고요.

앞으로 몇 주간은 이사와 정착으로 조금 정신이 없을 수 있지만,
이 뉴스레터만큼은 계속해서 Rails의 흐름을 기록하는 공간으로 가져가고 싶어요.

이번 호도 천천히 읽어보시고,
여러분이 느끼는 “지금 Rails는 어디로 가고 있는가”도 함께 생각해보면 좋겠어요.

토론토에서 다시 인사드릴게요 🇨🇦

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

새로운 소식

RubyConf 2026 티켓 오픈 – 커뮤니티를 후원하는 방식

Ruby Central이 주최하는 RubyConf 2026 티켓이 공식 오픈됐어요. 이번에는 일반 티켓보다 Supporter와 VIP 티켓이 먼저 공개됐어요.

Supporter 티켓은 단순한 참가권이 아니라, Ruby 커뮤니티의 다양성과 접근성을 넓히기 위한 Scholars & Guides 프로그램과 학생 지원 기금을 후원하는 역할을 해요. RubyConf가 여전히 커뮤니티 중심으로 운영되고 있다는 점을 보여주는 구조라고 볼 수 있어요.

VIP 티켓에는 키노트 VIP 좌석, 연사와의 Meet & Greet 등 프리미엄 혜택이 포함돼 있어요. 네트워킹과 깊이 있는 교류를 기대하는 분들께는 매력적인 선택지가 될 수 있어요.

일반 참가자를 위한 Early Bird GA 티켓은 곧 오픈 예정이라고 해요. 참석을 고민하고 있다면 일정과 공지 업데이트를 미리 확인해두는 게 좋겠어요.

RubyConf는 단순한 기술 컨퍼런스를 넘어, Ruby 생태계를 유지하고 확장하는 역할을 해왔어요. 이번 티켓 전략 역시 “참가”와 “후원”을 연결하면서 커뮤니티의 지속 가능성을 강조하고 있어요.

*Rails + AI, 지금이 전환점이에요 – SF Ruby Meetup&

Irina Nazarova가 다가오는 SF Ruby Meetup(2월 25일) 소식을 전하며, 지금 Rails 생태계에서 벌어지고 있는 흥미로운 흐름을 공유했어요.

최근 Garry Tan(YC 대표)은 “Rails + Claude Code는 지금 엄청난 기회”라고 언급하며, 몇 주 만에 8만 5천 줄 규모의 앱을 직접 만들었다고 밝혔어요. 이 발언은 단순한 홍보가 아니라, 실제로 AI와 Rails 조합이 얼마나 빠르게 제품을 만들 수 있는지를 보여주는 사례로 받아들여지고 있어요.

이 흐름은 이미 지난해 Vladimir Dementyev가 SF Ruby Conference 키노트에서 예고했어요. 그는 Rails가 이제 ‘vibe coder’—AI 도구를 활용해 빠르게 만들어내는 빌더들—를 포용해야 한다고 말했어요. 당시에는 다소 도전적인 주장처럼 들렸지만, 두 달 만에 현실이 됐다는 평가예요.

왜 하필 Rails일까요?

20년간 쌓인 Convention over Configuration 철학 덕분이에요. LLM은 “의견이 강한 프레임워크”에서 더 잘 작동해요. 구조가 명확할수록 AI가 예측하기 쉽고, 코드 생성 품질도 좋아져요. 오히려 Rails의 전통적인 강점이 AI 시대에 복리(compound advantage)처럼 작용하고 있다는 분석이에요.

Irina 역시 Evil Martians 내부 운영 시스템(기획, HR, 재무)을 Rails + SQLite + Claude Code 조합으로 2주 만에 만들었다고 밝혔어요. 한 사람이, 실사용하는 프로덕션 앱을, 본업과 병행하며 만들었다는 점이 상징적이에요.

생태계도 빠르게 움직이고 있어요. Rails 8.1에는 AI 친화적 기능이 추가됐고, RubyLLM 생태계도 확장 중이에요. 게다가 SF Ruby Jobs 보드에는 최대 30만 달러 연봉의 포지션까지 올라와 있다고 해요. 시장 온도도 분명히 올라가고 있어요.

원문 보기: https://x.com/inazarova/status/2025280846677377278?s=20

37signals, 오픈소스 모니터링 시스템 ‘Upright’ 공개했어요

37signals가 새로운 제품 Upright를 공개했어요. Basecamp, HEY 등 자사 서비스를 모니터링하기 위해 내부에서 사용하던 Synthetic Monitoring 시스템을 오픈소스로 전환한 거예요. 라이선스는 MIT라서 상업적 사용에도 제약이 거의 없어요.

Upright는 전 세계 여러 VPS 노드에서 헬스 체크를 실행하고, 문제가 생기면 Prometheus 메트릭을 통해 AlertManager로 알림을 보내는 구조예요. 단순한 HTTP 체크뿐 아니라, Playwright 기반의 실제 브라우저 시나리오 테스트까지 지원해요. 로그인 후 특정 화면을 확인하는 E2E 흐름을 자동으로 점검하고, 실패 시 영상까지 남겨준다는 점이 인상적이에요. SMTP 상태 점검이나 traceroute 기반 네트워크 경로 추적도 지원해서, 단순 업타임 모니터링을 넘어선 구성을 갖추고 있어요.

기술 스택은 매우 Rails스러워요. Upright는 Rails Engine 형태로 제공되고, SQLite, Solid Queue, Kamal, Prometheus, AlertManager, OpenTelemetry 조합으로 구성돼요. rails new 후 gem을 추가하고 generator를 실행하면 기본 설정이 자동으로 만들어져요. 실제 운영 사례로는 DigitalOcean과 Hetzner VPS를 활용해 월 약 110달러 수준으로 5개 글로벌 노드를 운영 중이라고 해요. 최소 구성은 월 20달러 이하도 가능하다고 밝혔어요.

이번 공개는 단순한 도구 배포를 넘어, “Rails만으로도 글로벌 프로덕션 인프라를 충분히 운영할 수 있다”는 메시지를 던지고 있어요. 최근 Rails 8과 Kamal, Solid Queue 중심으로 자체 운영 스택이 강화되고 있는 흐름과도 맞닿아 있어요. 외부 SaaS에 의존하지 않고, 우리가 소유하고 확장할 수 있는 모니터링 시스템을 Rails로 구축할 수 있다는 점에서 상징적인 릴리스라고 볼 수 있어요.

원문 보기: https://dev.37signals.com/introducing-upright/

Ruby Dev Meeting 결과 정리 – Matz의 판단이 보인 회의

지난 2월 12일 진행된 Ruby 개발자 미팅 회의록이 공개됐어요. 이번 회의에서는 여러 기능 제안과 버그, 표준 라이브러리 정리에 대한 논의가 있었는데요, 특히 인상적인 점은 Ruby 창시자 **Yukihiro Matsumoto(Matz)**의 의사 결정 스타일이 곳곳에서 드러났다는 점이에요.

먼저, 오랫동안 보류돼 왔던 메서드 시그니처 trailing comma 허용이 최종 승인됐어요. 몇 년간 큰 진전이 없던 이 이슈에 대해 Matz는 “설득됐다(I was persuaded)”라고 명확히 말하며 방향을 바꿨어요. 다만 def foo(&block,)처럼 문법적으로 어색하거나 의미적으로 혼란을 줄 수 있는 경우는 제한했어요. 완전 개방이 아니라, Ruby스러운 균형을 유지하는 선택이었어요.

autoload_relative 역시 승인됐어요. 과거 autoload 제거 논의가 있었던 만큼 조심스러운 주제였지만, Rails 진영과 Zeitwerk 측의 실제 사용 사례가 제시되자 Matz는 “이제 받아들이겠다”고 결론 내렸어요. 철학적 일관성보다 현실적 사용성과 커뮤니티 요구를 반영한 결정으로 보여요.

새로운 디렉터리 스캔 API인 Dir.scan도 흥미로운 사례예요. 이름에 대해 “looks good”이라고 비교적 빠르게 동의했지만, 반환 타입 심볼 네이밍이나 ".", ".." 제외 여부 같은 디테일은 꼼꼼히 짚었어요. 자동 lstat 변환 역시 승인했지만, 비활성화 옵션은 “실제 사용 사례가 나오면 다시 보자”며 유보했어요. 즉, 먼저 단순하게 도입하고, 필요하면 확장하겠다는 접근이에요.

반대로, Module#undef_const처럼 철학적으로 애매하다고 느낀 제안에는 “use case와 proposal 사이에 간극이 있다”고 언급하며 즉시 승인하지 않았어요. ensure 블록에서 반환값을 직접 받는 문법 제안도 거절했어요. 기존 Ruby 문법의 간결함과 예측 가능성을 해칠 수 있다고 판단한 것으로 보여요.

전체적으로 보면 이번 회의에서 Matz의 판단 기준은 꽤 명확해 보여요:

• 실제 사용 사례가 충분한가?

• Ruby의 문법적 일관성을 해치지 않는가?

• 복잡성을 불필요하게 늘리지 않는가?

• 필요하다면 “작게 도입하고, 나중에 확장”할 수 있는가?

대규모 혁신보다는, 작지만 실용적인 개선을 신중하게 받아들이는 모습이에요. 설득되면 방향을 바꾸지만, 철학적으로 어긋난다고 느끼면 선을 긋는 균형감이 여전히 중심에 있어요.

이번 회의는 기능 추가 목록 그 자체보다, Ruby가 어떻게 의사 결정을 하는지 보여준 자리였다고 해도 과장이 아니에요.

회의록 보기: https://github.com/ruby/dev-meeting-log/blob/master/2026/DevMeeting-2026-02-12.md

Ruby on Whales 2026: Rails 개발 환경을 “표준화”하는 가장 현실적인 Docker 세팅

Evil Martians가 Ruby on Whales라는 이름으로 정리해온 Rails용 Docker 개발 환경 가이드를 2026 버전으로 크게 업데이트했어요. 핵심 메시지는 단순해요. 팀 개발에서 가장 큰 비용 중 하나가 “내 컴퓨터에서는 되는데요(works on my machine)”와 온보딩 난이도라면, 재현 가능한 개발 환경이 곧 생산성이라는 거예요. 그래서 Docker 기반으로 Ruby/Rails 개발 런타임을 표준화하고, DB·Redis 같은 의존 서비스까지 함께 묶어 “한 번에 올리는” 구성을 제안해요. 

이 글이 특히 실전적인 이유는 Docker Compose를 그대로 개발자가 매일 쓰기엔 DX가 너무 불편하다는 점을 정면으로 인정하기 때문이에요. 대신 Evil Martians는 Compose 위에 얇게 감싸는 래퍼 도구인 Dip을 중심에 둬서, dip rails s, dip rspec, dip psql처럼 “로컬에서 하던 개발 명령”의 감각을 유지하게 만들어요. 결국 Ruby on Whales의 3요소는 Dockerfile + compose.yml + dip.yml로 정리돼요. 

또 하나, 이번 2026 업데이트에서 눈에 띄는 포인트는 LLM 도구를 컨테이너 안에 가둬서 돌리는 전략이에요. 글에서는 “claude –dangerously-skip-permissions를 호스트에서 늘 켜두는 게 불편했다”는 문제의식에서 출발해서, dip claude 같은 커맨드로 AI 도구를 컨테이너 내부에서 실행하도록 구성해요. 이렇게 하면 AI가 접근 가능한 파일 범위를 볼륨 마운트로 통제할 수 있고, 프로젝트별 설정/크리덴셜도 Docker 볼륨로 분리할 수 있어서 “편의성과 안전”을 동시에 노려볼 수 있어요. 

도입 장벽도 낮추려고 인터랙티브 제너레이터(rails app:template / RailsBytes / rbytes)를 제공해요. 프로젝트 의존성을 분석해 .dockerdev 폴더와 각종 설정 파일을 만들어주고, 필요하면 마지막 마무리를 LLM에게 맡기는 “하이브리드 제너레이터” 아이디어도 소개해요. 바로 적용해보고 싶은 팀에는 좋은 출발점이 될 것 같아요. 

정리하면, Ruby on Whales는 “Docker로 개발 환경을 돌린다” 수준이 아니라, 팀 전체가 매일 쓰기 편한 개발 인터페이스(Dip)까지 포함해 표준화된 Rails 개발 경험을 만든다는 제안이에요. 그리고 이제는 그 표준화의 대상에 AI 개발 도구까지 포함시키려는 흐름이 확실히 보인다는 점이 이번 글의 가장 큰 업데이트처럼 느껴져요.

원문 보기: https://evilmartians.com/chronicles/ruby-on-whales-docker-for-ruby-rails-development

RuboCop, MCP 서버를 내장했어요 – LLM 시대를 향한 실험

Koichi ITO가 RuboCop에 built-in MCP 서버 모드(실험적)를 추가하는 PR을 머지했어요.

이번 변경의 핵심은 rubocop --mcp 옵션을 통해 RuboCop이 Model Context Protocol(MCP) 서버처럼 동작할 수 있게 된 점이에요. 기존에는 LLM 기반 코딩 에이전트(예: Claude Code)가 RuboCop을 CLI로 실행한 뒤 텍스트 출력을 파싱해야 했어요. 하지만 MCP 서버 모드를 사용하면, RuboCop을 “전용 툴”처럼 호출하고 정의된 스키마 기반으로 구조화된 결과를 받을 수 있어요. 즉, 사람이 읽기 좋은 출력이 아니라 기계가 소비하기 좋은 포맷으로 제공되는 거예요.

특히 흥미로운 점은 MCP 응답 형식으로 LSP(Diagnostic) 포맷을 활용했다는 거예요. LSP는 JSON-RPC 기반의 표준 스펙이라, 위치 정보(line/column 포함)를 안정적으로 전달할 수 있어요. 이는 에이전트가 결과를 재가공하거나 자동 수정(auto-correct)까지 연결하기에 적합해요. RuboCop의 “결정론적 분석” 결과를 LLM 워크플로우 안으로 자연스럽게 끌어오는 시도라고 볼 수 있어요.

현재 구현은 stdio 기반 전송만 지원하며, 검사와 자동 수정 도구부터 시작했어요. 다만 실험적 기능이라 토큰 사용량 증가나 cop 문서 로딩 시 컨텍스트 소비 문제 같은 이슈도 언급됐어요. 향후에는 리소스 분리나 구조 최적화가 필요할 가능성이 커 보여요.

이번 변화는 단순히 “RuboCop이 AI를 지원한다” 수준이 아니에요. Ruby 생태계의 대표적인 정적 분석 도구가 에이전트 네이티브 툴로 진화하려는 첫 단계라는 점이 더 중요해 보여요. LLM이 코드 작성 → RuboCop 검사 → 자동 수정 → 재검사로 이어지는 루프를 더 구조적으로 수행할 수 있게 되면서, 개발 워크플로우 자체가 바뀔 여지가 있어요.

아직은 출발점이에요. 하지만 Ruby 툴링이 MCP와 직접 연결되기 시작했다는 점에서, “AI 시대의 Ruby DX”가 본격적으로 탐색되기 시작했다고 볼 수 있겠어요.

PR 보기: https://github.com/rubocop/rubocop/pull/14911