Ruby on Rails #28번째 소식

안녕하세요 구독자님,

지난주에 이어 이번 주도 Ruby on Rails 업계는 비교적 조용한 모습입니다. ShortRuby 뉴스레터 역시 이렇다 할 특별한 공지 없이 3주째 휴간에 들어갔네요. 아마도 작년에 워낙 새로운 기능과 소식이 많았던 여파가 남아 있는 게 아닐까 싶어요.

하지만, 작년에 새로 나온 Rails 8 기능들을 활용해, 올해는 더 흥미로운 라이브러리나 솔루션이 등장할 수 있으니 기대해봐도 좋을 것 같아요. "어떤 팀이 어떻게 Rails 8 기능을 적용하고 있는지"나, "새로운 기능을 활용한 Gem"들이 하나둘 공개될 텐데, 곧 좋은 사례들이 나오면 공유해볼게요.

이번 주에는 2025년 첫 번째 This Week in Rails가 어땠는지 간단히 살펴보고, Rails 8의 Authentication 예제 영상 두 편, 그리고 37signals와 Gusto 테크 블로그에 올라온 주요 포인트들을 정리해봤어요.

새로운 소식

2025년 첫 번째 "This Week in Rails" 발행

Ruby on Rails 팀이 2025년 첫 번째 "This Week in Rails" 소식을 발표했어요. 이번 업데이트는 개발자들의 편의성과 안정성을 개선하는 데 초점을 맞추고 있어요.

스키마 덤퍼의 버전 포맷터 도입

이제 structure.sql 파일 내 버전 정보의 정렬 방식을 커스터마이징할 수 있어요. 기존에는 버전이 내림차순으로 정렬되어 대규모 팀에서 Merge Conflict가 발생할 수 있었어요. 이제 해시 값 등을 활용한 사용자 정의 정렬을 통해 이러한 충돌을 줄일 수 있어요.

rail_inspector의 파서 교체

Ruby 3.4의 기본 파서인 Prism이 안정화됨에 따라, rail_inspector에서 기존의 SyntaxTree를 Prism으로 교체했어요.

path_params 처리 개선

URL에 ?path_params=string과 같은 쿼리 파라미터가 포함될 경우, 이를 무시하여 오류를 방지하도록 개선됐어요.

to_time_preserves_timezone 설정 수정

초기화 파일에서

Rails.application.config.active_support.to_time_preserves_timezone = :zone

설정이 적용되지 않는 문제가 수정되어요.

자세한 내용은 공식 블로그에서 확인하세요!

How to Use Authentication in Ruby on Rails 8

이번에는 Ruby on Rails 8에서 제공하는 인증(Authentication) 기능을 빠르고 간편하게 익힐 수 있는 영상 두 편을 소개해드릴게요. 풀스택 엔지니어 Brian Casel이 본인의 유튜브 채널을 통해 실제 예제 코드와 함께 사용법을 차근차근 설명해주고 있어서, 처음 접하는 분들도 따라하기 좋아요.

첫 번째 영상에서는 Rails 8에서 기본적으로 제공되는 인증 기능을 사용하는 방법을 소개해요. 먼저, Rails 8에서 인증 기능을 설치하고, 기본적인 사용법을 설명하고 있어요. 로그인, 로그아웃, 세션 관리 등 기본적인 기능을 사용하는 방법을 예제를 통해 보여줘요.

두 번째 영상에서는 Rails 8에서 기본적으로 제공되는 인증 시스템을 사용하여 사용자 로그인 기능을 구현하는 방법을 설명해요. Rails 8의 인증 시스템은 기본적으로 로그인 기능만 제공하며, 사용자 등록 기능은 포함되어 있지 않아요. 따라서 사용자 등록 기능을 추가하고, 사용자 프로필 관리 기능을 구현하기 위해 필요한 단계들을 안내하고 있어요.

저는 개인 프로젝트에서 이 Authentication을 이용하려다가, 개발 리소스와 우선순위 때문에 Firebase 같은 클라우드 서비스를 먼저 선택했어요. 하지만 나중에 인증 기능을 완전히 내재화하고, 세부 로직을 직업 제어하고 싶다면 Rails 8의 내장 인증 기능이 큰 도움이 될 거라고 생각해요.

물론 아직 Rails 8 인증 기능이 제공하는 범위는 제한적이에요. 하지만 언젠가는 Rails 8에서 더 풍부한 인증 옵션을 제공해주면 좋겠다는 생각이 들어요. 실제 서비스를 개발하다 보면, 가입 인증보다 비즈니스 로직에 집중해야 할 일이 더 많으니까요.

37signals, Pure Storage 모니터링 방법 공개

최근 37signals에서 Pure Storage 스토리지 시스템을 어떻게 모니터링하고 있는지 블로그를 통해 공유했어요. 참고로 이 회사는 클라우드 전환의 마지막 단계로 10 페타바이트의 데이터를 AWS S3에서 물리 장비로 옮기는 작업을 진행 중이에요. 37signals는 고성능 스토리지를 안정적으로 운영하기 위해, 내부 환경에 맞춘 자동화된 모니터링 및 알림 체계를 구축했는데, 주요 포인트는 다음과 같아요.

메트릭 수집

Pure Storage에서 제공하는 API를 활용해 I/O, 성능 지표 등을 자동으로 수집하고, 스토리지 상태를 실시간으로 확인할 수 있도록 했어요.

오픈소스 도구 연동

수집한 데이터를 시각화하고 알림을 받을 수 있도록, Grafana나 Prometheus 같은 오픈소스 모니터링 툴과 통합했어요. 이를 통해 IOPS, 레이턴시, 용량 등을 쉽게 트래킹하고, 임계값을 초과하면 알림을 받도록 설정했어요.

운영 효율 개선

정확한 지표 기반으로 스토리지 상태를 파악하니, 장애 대응이 빨라지고 리소스 사용을 최적화할 수 있었다고 해요. 모니터링 시스템을 자동화해 개발팀이 좀 더 비즈니스 로직과 제품 개선에 집중할 수 있게 되었어요.

Ruby on Rails와 직접적인 관련은 없지만, 스토리지 시스템을 자체적으로 운영하거나, 효율적인 모니터링 프로세스를 찾고 있는 분들께 이 사례가 좋은 인사이트를 줄 수 있을 것 같아요. 자세한 설정 방법과 코드 예시는 블로그 원문을 참고해보세요!

Gradual Modularization: 모놀리스를 어떻게 쪼갤까?

2024년 4월 글이지만, Rails 프로젝트를 오래 운영 중인 분이라면 고민하게 될 부분에 대해 인상 깊은 글이라서 공유해요. (Gusto’s Gradual Modularization Destination)

Gusto 팀에서는 거대한 Rails 모놀리스를 여러 패키지(package)로 나누어 관리하고 있어요. 이 과정에서 “결국 이 패키지를 어디까지 분리·독립시킬 수 있을까?”라는 질문에 대한 답으로, 각 패키지를 애플리케이션 또는 라이브러리로 단계적으로 모듈화(Extractable)할 것을 제안해요.

애플리케이션 vs 라이브러리

애플리케이션(Application): 자체적으로 실행되며 목적을 수행하는 소프트웨어 (예: Rails 서버, Lambda 함수 등).

라이브러리(Library): 다른 애플리케이션에 포함되어 기능을 확장하는 소프트웨어 (예: Ruby gem).

모놀리스 내 각 패키지가 궁극적으로 애플리케이션이 될지, 라이브러리가 될지(또는 아직 결정이 안 됐는지)를 구분한 뒤, 이에 맞춰 패키지를 “추출 가능(Extractable)”하도록 만들자는 아이디어라고 할 수 있어요.

Extractable이란?

“추출 가능”이란, 해당 패키지를 모놀리식 코드베이스에서 떼어내어 독립된 레포지토리로 옮겼을 때도 제대로 동작할 수 있는 상태를 의미해요.

라이브러리 추출 예시

의존성이 없도록 정리하고, 독립 레포에서 테스트가 통과하도록 수정한 뒤
원래 코드베이스에서 해당 패키지를 삭제하고, 새 라이브러리(gem)로서 불러오면 완료.

애플리케이션 추출 예시

DB 연결, 외부 API, 내부 public API 등 여러 전제 조건을 분리해야 하므로 라이브러리보다 더 복잡해요
다만 기본적인 절차는 비슷하게 “코드 옮기기 → 테스트 통과시키기 → 원래 코드베이스와 상호 작용 정의하기” 과정을 거쳐요.

어디부터 시작해야 할까?

작은 패키지부터 시작해서 모놀리식에서 빼내 보는 것으로 경험치를 쌓을 수 있어요.
핵심 도메인 영역이나, 의존성이 적은 곳, 혹은 부수적인 기능 영역부터 시도해볼 수 있어요.
모든 패키지를 전부 한 번에 다 떼어내야 하는 것은 아니며, 각 패키지별로 “최종적으로 앱이 될 건지, 라이브러리가 될 건지” 방향을 잡고 점진적으로 진행해요.

“모놀리스를 다 쪼개서 마이크로서비스로 갈 거야”라는 거창한 목표 이전에, 단계적(Modular)으로 나눌 수 있는지부터 확인하자는 게 이 글의 핵심이에요. 결국 각 패키지가 애플리케이션이 될지, 라이브러리가 될지를 확정하고, 독립 실행이 가능한지(Extractable)를 검증해보는 과정을 통해 모놀리스를 서서히 탈피할 수 있다는 인사이트를 공유하고 있어요.