요즘 아침저녁으로 부쩍 쌀쌀해졌어요.
가을이 채 다 익기도 전에 겨울이 성큼 다가온 느낌이에요.
이번 주는 Rails와 Ruby 커뮤니티가 보여준 “꾸준한 진화와 현실적인 선택”의 이야기가 많았어요.
AI로 테스트 케이스를 생성하는 워크숍부터, Rails 8.1 Beta 1의 실무 중심 개선들, 그리고 RubyGems 저장소 이관처럼 생태계의 방향을 가다듬는 변화까지요.
“새로운 기술보다 중요한 건 지금의 팀과 문제를 이해하는 일” — 최근 논의된 모놀리식 vs 마이크로서비스 이야기, 그리고 Nate Berkopec이 전한 ‘단순함의 힘’이 그 메시지를 다시금 일깨워줬어요.
🎧 10분 요약 오디오로 들어보시겠어요? → YouTube로 듣기
새로운 소식
AI로 신뢰할 수 있는 테스트 케이스를 만드는 법 — Good Enough Testing 워크숍 오픈
이 뉴스레터의 전신인 ShortRuby의 발행자 Lucian Ghinda가 주최하는 Good Enough Testing 시리즈의 두 번째 워크숍, “Reliable Test Case Generation with AI” 가 새롭게 공개됐어요.
이 워크숍은 올해 EuRuKo에서 진행된 버전을 바탕으로 한 첫 공개 버전으로, 최대 12명만 참여할 수 있는 실습 중심 프로그램이에요. 참가비는 $100(약 14만 원대) 이며, 세션은
-
10월 30일 오후 4시(UTC) → 10월 31일 오전 1시(KST)
-
10월 31일 오후 4시(UTC) → 11월 1일 오전 1시(KST)
에 각각 진행돼요.
참가자는 다양한 LLM(대형 언어 모델) 을 활용해 코드 샘플과 실제 사례를 다루며, 효율적이고 체계적인 테스트 케이스를 자동 생성하는 프로세스를 함께 구축하게 돼요. 이론보다 실무에 가까운, 현실적인 접근 방식을 배울 수 있어요.
자세히 보기: Reliable Test Case Generation with AI
또한 AI를 활용한 접근에 관심이 없다면, 11월 7일 예정된 “Good Enough Testing” 워크숍도 있어요. 이 워크숍에서는 수학적 사고 기반의 테스트 설계 기법을 다루며, 테스트 수를 줄이면서도 동일한 문제나 비즈니스 규칙을 효과적으로 검증하는 방법을 배울 수 있어요.
둘러보기: Good Enough Testing Workshop (7th November)
Rails 8.1 Beta 1 공개 — Active Job Continuations, Local CI, Markdown Rendering 등 대거 추가
Ruby on Rails가 Rails 8.1 Beta 1을 발표했어요. 이번 버전은 지난 10개월 동안 500명 이상의 기여자가 참여한 2,500개 이상의 커밋으로 완성됐으며, Rails World 2025 첫날(9월 4일) 에 맞춰 공개됐어요.
이번 릴리스는 테스트, 배포, 로깅, 데이터 모델링 등 실무 환경에서 바로 체감할 수 있는 개선에 초점이 맞춰져 있어요.
주목할 핵심 기능
-
Active Job Continuations
긴 작업(Job)을 여러 단계(step)로 나누어 중단 시 마지막 단계부터 재시작할 수 있게 됐어요.
배포나 재시작 중에도 안전하게 잡을 이어서 실행할 수 있어, Kamal 같은 배포 툴과 궁합이 좋아요.
-
Local CI (로컬 지속적 통합 환경)
클라우드 대신 로컬 머신에서 테스트를 병렬 실행할 수 있게 하는 config/ci.rb DSL이 추가됐어요.
예를 들어 HEY의 30,000개 테스트가 로컬에서는 최대 2분대로 완료된다고 해요.
작은 팀이나 개인 프로젝트에서도 빠르고 효율적인 CI 환경을 구축할 수 있어요.
-
📝 Markdown Rendering
이제 컨트롤러에서 .md 포맷을 직접 렌더링할 수 있어요.
Markdown이 기본 언어로 자리 잡은 AI 및 문서 중심 워크플로우와의 통합이 훨씬 쉬워졌어요.
-
🚨 Deprecated Associations 지원
Active Record의 연관 관계를 deprecated: true로 표시해, 사용 시 경고(:warn), 예외(:raise), 알림(:notify)을 발생시킬 수 있어요.
점진적인 리팩터링을 지원하면서도 기존 코드를 안전하게 전환할 수 있어요.
그 외 주요 개선
-
Structured Event Reporting: 태그, 컨텍스트 기반의 구조화된 로깅 도입
-
Command-line Credentials Fetching: Kamal이 Rails credentials에서 직접 시크릿을 가져올 수 있도록 개선
이번 릴리스는 Rails가 “더 빠르고, 안전하고, 현명한 개발자 도구”로 진화하고 있음을 보여주는 버전이에요.
RubyGems 저장소, Ruby 코어팀으로 이관 — Ruby Central과 공동 관리 체제로 전환
루비 언어 창시자 Matz(마츠모토 유키히로)가 RubyGems 및 Bundler 저장소의 소유권을 Ruby Central에서 Ruby 코어팀으로 이관한다고 발표했어요.
이에 대해 Ruby Central도 즉각 공식 입장을 내며, 이번 변화가 루비 생태계의 안정성과 지속 가능한 성장을 위한 공동 결정임을 강조했어요.
왜 이관이 이루어졌나
RubyGems와 Bundler는 루비 생태계의 핵심 인프라로, 오랫동안 Ruby에 번들되어 배포되어 왔지만 GitHub의 Ruby 조직 밖에서 Ruby Central이 관리해왔어요.
Matz와 Ruby 코어팀은 “언어의 핵심 구성요소를 공식 조직 아래 두는 것이 장기적으로 루비 생태계의 일관성과 안정성을 확보하는 길”이라고 밝혔어요.
이로써 두 저장소의 공식 소유권은 Ruby 코어팀으로 이전되지만, 운영과 거버넌스는 Ruby Central과 공동으로 수행하는 체제로 전환돼요.
변하지 않는 점들
-
오픈소스 철학 유지:
RubyGems와 Bundler는 기존과 동일한 오픈소스 라이선스를 유지하며,
모든 기여자의 저작권과 지식재산권은 그대로 보존돼요.
-
커뮤니티 주도 개발 지속:
두 프로젝트는 앞으로도 커뮤니티 중심의 개발 구조를 유지하며,
Ruby Central과 Ruby 코어팀이 협력해 투명한 개발 프로세스를 이어갈 예정이에요.
-
Ruby Central의 역할 유지:
Ruby Central은 여전히 rubygems.org의 운영 주체로 남고,
보안 강화·성능 개선·개발자 경험 향상을 위한 투자와 지원을 계속할 계획이에요.
양측의 메시지
-
Matz (Ruby 코어팀):
“이 이관은 루비 생태계의 건강과 성장을 위한 결정이며, Ruby Central의 헌신에 깊이 감사한다.”
-
Ruby Central:
“소유권은 이전되었지만, 우리는 여전히 Ruby 코어팀과 함께 RubyGems와 Bundler를 관리하고 발전시킬 것이다. 이번 변화는 생태계의 미래를 위한 협력의 신호다.”
Ruby 커뮤니티는 이번 전환을 통해 공식성과 투명성을 높이면서도 커뮤니티 중심의 철학을 유지할 수 있을 것으로 기대하고 있어요.
“모놀리식 vs 마이크로서비스” 논쟁, 다시 보는 현실적인 선택의 기준
Yatish Mehta가 공유한 Rails 모놀리식 앱의 마이크로서비스 전환 실패 사례를 계기로, 전 세계 Ruby 커뮤니티에서 수많은 개발자들이 자신의 경험과 생각을 나눴어요.
이 논의는 단순히 “Rails vs Go”의 기술 논쟁이 아니라, 조직의 규모·문화·의사결정 구조가 아키텍처의 성공을 좌우한다는 근본적인 문제로 확장됐어요.
실패한 전환: “기술의 문제가 아니라, 조직의 문제였다”
Yatish가 소개한 회사의 사례는 전형적이었어요.
-
아마존 출신 리더십이 “팀마다 서비스를 소유해야 한다”는 모델을 도입
-
거대한 Rails 앱을 Go 마이크로서비스로 쪼개며 Kubernetes, gRPC 등 최신 기술을 전면 도입
-
그러나 문제의 본질은 코드 오너십과 도메인 설계 부재였음
결과적으로 5년이 지나도 70%의 기능은 여전히 Rails 모놀리식 위에서 동작,
미완성된 마이크로서비스와 함께 두 시스템을 동시에 유지해야 하는 비효율적인 구조가 남았어요.
이 사례 이후 여러 개발자들이 한목소리로 말했어요.
“문제는 언어나 프레임워크가 아니라, 조직 구조와 동기 부여의 문제다.”
“마이크로서비스는 성장 가정이 틀리면 바로 발목을 잡는다.”
공통된 교훈 ① — “지금의 팀을 위한 설계를 하라”
많은 개발자들은 마이크로서비스가 아닌 ‘조직 설계’의 문제라고 지적했어요.
“작은 팀은 모놀리식이 더 빠르다.
큰 팀은 자율성과 독립 배포가 필요할 때 마이크로서비스가 빛난다.”
즉, 마이크로서비스 전환은 조직이 병렬로 움직여야 할 만큼 충분히 크고, 도메인 경계가 명확하게 정의되어 있을 때만 의미가 있어요.
그렇지 않으면 “분산된 모놀리식(distributed monolith)”이 되어 오히려 유지보수 비용과 복잡성만 늘어나요.
공통된 교훈 ② — “리라이트는 혁명보다 진화로”
스타트업 SafariPortal은 이 논의 속에서 반대의 길을 보여줬어요.
React 프론트엔드를 완전히 버리지 않고,
-
기존 코드는 그대로 유지하면서
-
새로운 모듈만 Rails + Hotwire + Turbo로 개발
-
세션 공유와 배포 프로세스를 통합
이렇게 점진적으로 전환해 18개월 만에 4개 신규 모듈을 출시하고 매출과 사용자 수 모두 성장했어요.
“우리는 리라이트하지 않았다.
기능과 가치에 집중했다. 그것이 성공의 핵심이었다.”
이 사례는 ‘리라이트(rewrite)’보다 ‘점진적 진화(refactor & expand)’가 현실적인 해법임을 보여줘요.
공통된 교훈 ③ — “비즈니스 현실을 무시하면 기술도 무너진다”
다른 사례에서는 “돈은 문제가 아니다”라던 리더십이 결국 투자 유치에 실패하고 경험 많은 개발자들이 모두 회사를 떠났다고 해요.
“돈은 언제나 중요한 문제다.
기술 선택이 비즈니스 목표와 분리될 수 없다.”
결국 기술적 이상보다 현실적 제약 속에서 가치를 낼 수 있는 선택이 중요하다는 걸 상기시켜요.
공통된 교훈 ④ — “서비스 간 복잡성은 실제보다 훨씬 크다”
“한 API 요청이 내부적으로 12개의 서비스를 호출했다.
트레이싱과 디버깅은 악몽이었다.”
이는 마이크로서비스가 아니라 오케스트레이션(조율) 부재의 문제예요.
즉, 마이크로서비스는 도입 자체보다 운영·관찰·모니터링 체계가 훨씬 더 중요하다는 지적이에요.
최종 결론 — “필요한 곳에만, 준비된 팀에서만”
모든 사례가 공통적으로 남긴 메시지는 명확해요.
-
마이크로서비스는 만병통치약이 아니다.
-
작은 팀에겐 모놀리식이 오히려 더 빠르고,
-
리라이트보다 점진적 개선이 현실적이다.
-
기술 선택은 팀의 규모, 도메인 복잡도, 그리고 비즈니스 목표에 맞춰야 한다.
결국 중요한 건 “지금의 팀이 해결해야 하는 실제 문제”예요.
아키텍처는 미래의 이상이 아니라, 현재의 현실을 견디는 도구여야 해요.
Nate Berkopec — “좋은 코드는 단순함과 명확함에서 온다”
Ruby 성능 전문가 Nate Berkopec이 최근 트윗을 통해 좋은 코드의 기준, 테스트 프레임워크 선택, 스케일링 철학에 대한 생각을 공유했어요.
그의 메시지는 한 가지로 요약돼요 — 단순함이 곧 명확함이고, 명확함이 곧 품질이다.
“가장 잘 만들어진 Ruby 코드베이스는 단순하다”
Nate가 꼽은 최고의 오픈소스 Ruby 코드 품질 Top 3는 다음과 같아요.
-
Sidekiq
-
Minitest
-
Rails의 대부분 구성 요소들
그는 이 프로젝트들이 모두 Minitest 기반의 테스트 구조를 사용한다는 점을 강조하며,
“테스트가 명확하면 코드도 명확해진다.”
고 말했어요.
“RSpec보다 Minitest를 선택하는 이유”
“RSpec은 훌륭한 DSL이지만, 명확한 코드엔 명확한 사고가 필요하다.”
Nate는 Minitest의 전체 코드가 단 2,245줄로, 개발자가 프레임워크를 완전히 이해할 수 있는 점을 장점으로 들었어요.
복잡한 DSL보다 “테스트 도구가 사고 과정을 방해하지 않는 단순함”을 더 중요하게 보는 철학이에요.
“스케일링은 숫자가 아니라 경험의 문제”
Nate는 시스템 확장을 CPU 사용률 같은 이용률(utilization) 로 판단하는 접근을 비판했어요.
“80%가 괜찮은지 40%가 맞는지는 알 수 없다.
대신, 고객이 200ms의 지연을 받아들일 수 있는가를 보라.”
즉, 내부 지표보다 사용자 경험(Queue time, 응답 지연) 을 기준으로 인프라 결정을 내려야 한다는 현실적인 조언이에요.
Ruby다운 사고방식
Nate의 세 가지 메시지는 결국 Ruby 철학과 맞닿아 있어요.
-
단순함은 이해 가능성을 만든다.
-
명확한 테스트는 명확한 코드로 이어진다.
-
스케일링은 기술적 수치가 아니라 사용자 경험의 문제다.
그의 발언은 Ruby 생태계가 추구해온 “개발자 친화적이고 현실적인 기술 선택”의 가치를 다시 한 번 환기시켜줘요.
Rails 공식 튜토리얼 새로 공개 — “Wishlists” 기능으로 배우는 e-commerce 앱 확장
Ruby on Rails가 새로운 공식 튜토리얼 Wishlists 를 공개했어요.
이번 튜토리얼은 기존 e-commerce 데모 애플리케이션에 위시리스트 기능을 추가하는 방법을 다루며, 실무형 기능 개발 과정을 직접 따라 해볼 수 있도록 구성돼 있어요.
이 가이드를 통해 배울 수 있는 주요 내용은 다음과 같아요.
-
Counter cache로 위시리스트 항목 수 추적하기
-
친숙한 URL(Friendly URLs) 로 고객별 위시리스트 노출
-
Stimulus를 이용해 위시리스트 URL 복사 기능 구현
-
관리자(Admin) 필터링 및 제어 기능 추가
-
테스트 코드 작성으로 기능 전체 검증하기
튜토리얼은 Chris Oliver(@excid3) 가 작성했으며, 여러 Rails 커뮤니티 멤버들의 리뷰와 협업으로 완성됐어요.
Rails 공식 저장소의 관련 PR은 #55428에서 확인할 수 있어요.
저는 PR 리뷰 과정에서 코멘트를 추가했었는데, “suggestion” 코멘트를 깜빡해 co-author로 이름을 올리지 못해 아쉬웠던 기억이 있어요.