이번 호에서는 Rails World 2026 공식 일정 발표부터, Rails 8에서 드디어 네이티브로 지원되기 시작한 Composite Primary Keys, DDD 관점에서 다시 짚어보는 Service Object의 역할, 그리고 실제 코드로 드러난 37signals/DHH 스타일 가이드까지 함께 정리했어요.
여기에 더해, Rails 문서를 직접 개선할 수 있는 가이드 PR 소식과 Rails 마이그레이션 이후 20년 가까이 성장해온 Cookpad의 사례도 담았어요.
Rails가 “이론”이 아니라 오래 살아남는 선택이 될 수 있는 이유를 다시 느끼게 해주는 이야기들이에요.
설계, 코드 스타일, 프레임워크의 진화, 그리고 실제 비즈니스 사례까지 Rails를 쓰는 입장에서 한 번쯤 생각해볼 만한 주제들로 골라봤어요.
🎧 10분 요약 오디오로 들어보시겠어요? → YouTube로 듣기
새로운 소식
Rails World 2026 핵심 요약
Rails 팀이 Rails World 2026의 주요 일정을 공식 발표했습니다. 2026년 컨퍼런스 계획을 세우고 있다면 참고할 만한 정보들이 공개됐어요.
일정 & 장소
-
일정: 2026년 9월 23일(수) ~ 24일(목)
-
장소: 미국 텍사스 오스틴, Palmer Event Center
-
CFP: 2026년 Q2 (봄~초여름) 오픈 예정
티켓 정보
-
참가 인원: 최대 1,200명 (역대 최대 규모)
-
판매 시점: 2026년 Q2
-
티켓 종류:
-
Corporate Ticket: 기업/L&D 예산용, 사전 판매
-
General Admission: Rails Foundation이 보조하는 일반 티켓
-
-
가격: 미국에서 열리는 첫 Rails World인 만큼 이전보다 소폭 인상 가능성은 있으나, 개인 부담 참가자를 위해 최대한 가격을 낮출 계획
-
비자용 초청장: 기존과 동일하게 제공 예정
Rails at Scale Summit
-
일정: 9월 22일(화) — Rails World 전날
-
형태: 별도 티켓 / 초청 기반(지원 + 선발) 행사
-
주제: 대규모 트래픽·고성능 Rails 시스템을 운영하는 엔지니어 중심의 심층 토론
-
Summit 전용 CFP도 별도로 진행 예정
스폰서십
-
스폰서 모집 시작
-
다양한 패키지 제공 (부스 운영 없이 참여 가능한 옵션도 포함)
-
스폰서는 티켓을 미리 확보할 수 있다는 장점
-
관심 있는 경우: sponsors@rubyonrails.org
Rails World가 처음으로 미국에서 열리는 해라는 점에서 의미가 크고, 규모·접근성·콘텐츠 면에서 모두 한 단계 확장된 컨퍼런스가 될 것으로 보입니다.
오스틴에서의 Rails World, 벌써부터 기대되네요.
원문: Rails World 2026 Update – Here’s what we know
Rails 8, 네이티브 Composite Primary Keys 지원해요
saeloun.com에서 Rails 8에 추가된 Composite Primary Keys(CPK) 기능을 정리한 글을 공개했어요.
그동안 Rails가 전제로 삼아왔던 “하나의 테이블 = 하나의 id” 라는 가정에서 벗어나는 중요한 변화예요.
Rails 8부터는 외부 gem 없이도 여러 컬럼을 하나의 identity로 인식할 수 있고, find, to_param, 라우팅까지 전반적인 흐름이 자연스럽게 동작해요.
User.find(["acme", "john_doe"])
# /users/acme:john_doe이제 멀티테넌트 SaaS나 tenant_id + user_id, invoice_id + line_number처럼 도메인 기반 식별자를 사용하는 구조를 Rails 기본 기능만으로 표현할 수 있어요.
물론 모든 문제가 해결되는 건 아니에요.
polymorphic association이나 아주 복잡한 CPK 구조까지 지원하려는 시도는 아니고, Rails 팀은 “완전한 CPK 프레임워크”보다는 네이티브 identity 기반을 제공하는 데 초점을 맞추고 있어요.
특히 눈여겨볼 점은, 기존에 많이 사용되던 composite_primary_keys gem이 아직 Rails 8을 지원하지 않는 상황에서 2~3개 컬럼으로 구성된 단순한 CPK를 사용하는 팀이라면 네이티브 전환을 검토해볼 시점이라는 점이에요.
원문: Rails Native Composite Primary Keys: A Complete Evolution from Rails 3 to Rails 8
DDD에서 말하는 두 가지 Service Object
Jorge Manrubia가 DDD 관점에서의 Service Object 두 가지 유형을 정리했어요.
Rails 커뮤니티에서 흔히 쓰이는 “서비스 객체” 개념과는 꽤 다른 이야기라 흥미로워요.
DDD에서는 서비스 객체를 이렇게 구분해요.
-
Application Layer Service
도메인 모델을 직접 실행하지 않고, 여러 객체를 조율하고 인프라 작업(예: 저장)을 연결하는 역할이에요.
중요한 점은 비즈니스 로직을 가지면 안 된다는 거예요.
-
Domain Layer Service
특정 엔티티에 속하지 않지만, 분명히 도메인 개념인 로직을 표현하는 객체예요.
엔티티와 마찬가지로 도메인 모델의 일부로 취급돼요.
Jorge는 Active Record를 사용하는 Rails 환경에서는 Application Layer Service가 사실상 컨트롤러와 역할이 겹친다고 설명해요.
그래서 이런 서비스 객체는 쓰지 않고, 대신 Domain Layer Service만 사용한다고 해요.
예를 들어 Signup, ActivitySpikeDetector 같은 객체들은 “서비스”라는 이름을 붙이지 않을 뿐, 도메인 객체로 자연스럽게 다루고 있어요.
그가 지적하는 문제는, Rails 커뮤니티에서 종종 비즈니스 로직을 전부 Application Service에 몰아넣으라는 조언이 퍼지고 있다는 점이에요.
이건 DDD의 의도를 왜곡한 접근이고, 오랫동안 문제점이 지적돼 왔다고 해요.
마지막으로 Jorge는 이렇게 말해요. “Rails에서 컨트롤러가 모델을 호출하면 안 된다는 이야기는 사실이 아니다.”
우리는 실제로 그렇게 하고 있고, 그게 문제도 아니다라고요.
출처: Jorge Manrubia (@jorgemanru)
37signals/DHH 스타일을 코드로 정리한 GUIDE.md 공개됐어요
Marc Köhlbrugge가 GUIDE.md – The Unofficial 37signals/DHH Rails Style Guide를 공유했어요.
이 가이드는 37signals의 오픈소스 프로젝트 Fizzy 코드베이스를 분석해 만들어졌어요.
그동안 37signals는 “vanilla Rails”, “의견 있는 설계”를 꾸준히 이야기해왔지만, Basecamp나 HEY 같은 실제 프로덕션 코드는 공개된 적이 거의 없었어요.
Fizzy는 처음으로 공개된 37signals 스타일의 실제 Rails 앱이라는 점에서 의미가 커요.
이 GUIDE.md는 Claude Code가 Fizzy 전체 코드—routes, controllers, models, views, JavaScript, CSS, 테스트, 설정까지—를 분석해서 어떤 패턴을 쓰는지뿐 아니라, 왜 그렇게 쓰는지를 정리한 문서예요.
가이드에는 다음 내용들이 담겨 있어요.
-
실제 코드에서 추출한 Rails 패턴 (파일 위치 포함)
-
“이렇게 하세요 / 이렇게는 하지 마세요” 식의 명확한 가이드
-
의도적으로 없는 것들 (오히려 철학이 더 잘 드러나요)
-
그대로 가져다 쓸 수 있는 코드 예제
블로그 글이나 컨퍼런스 발표가 아니라, 실제 운영되는 코드에서 드러난 DHH/37signals식 Rails 철학을 보고 싶다면
한 번쯤 꼭 읽어볼 만한 자료예요.
출처: GUIDE.md – Unofficial 37signals/DHH Rails Style Guide (Marc Köhlbrugge)
Rails 가이드 문서 업데이트 PR, 커뮤니티 리뷰가 열렸어요
Rails 팀이 새로운 문서 개선 PR 두 개를 공개하고 커뮤니티 리뷰를 요청했어요.
이번에 대상이 된 가이드는 Rails에서 특히 많이 참고되는 핵심 영역들이에요.
-
Active Record Query Interface
-
Active Storage
두 PR 모두 Rails 가이드 문서를 더 명확하고 최신 상태로 다듬는 작업으로, 실제 사용 경험을 바탕으로 한 피드백이나 리뷰 참여도 환영하고 있어요.
Rails 문서는 커뮤니티 기여로 계속 개선되고 있는 만큼, 조금의 시간만 있다면 PR을 살펴보고 의견을 남기는 것도 좋은 참여 방법이에요.
PR 링크
Rails 마이그레이션으로 성장한 Cookpad 이야기
Rails 팀이 Cookpad의 Rails 마이그레이션 사례를 소개하는 새로운 케이스 스터디를 공유했어요.
지역 레시피 사이트였던 Cookpad가 전 세계 1억 명 이상의 홈쿡을 사용하는 글로벌 플랫폼으로 성장한 과정이에요.
Cookpad는 1997년 ColdFusion으로 시작했지만, 개발 속도와 유지보수 한계에 부딪히면서 2007년에 Ruby on Rails로 전환했어요.
Rails 경험이 없는 상태에서의 선택이었지만, convention-over-configuration 접근 방식 덕분에 빠른 실험과 반복이 가능해졌다고 해요.
Rails 전환 이후 Cookpad는
-
70개국 이상, 35개 이상의 언어로 서비스 확장하고
-
린한 팀으로도 빠르게 기능을 출시하며
-
2009년 도쿄 증권거래소에 상장까지 이뤄냈어요.
현재도 Cookpad는 Rails 모놀리스 중심 구조를 유지하면서, 검색·결제 등 필요한 부분만 서비스로 분리해 운영하고 있어요.
Rails 기반 백엔드 하나로 웹과 iOS·Android 앱 API를 함께 제공하는 구조예요.
또한 I18n, Active Record, 테스트 문화, Hotwire 같은 Rails의 기본 도구들이 대규모 트래픽과 글로벌 확장을 안정적으로 뒷받침하고 있다고 해요.
특히 인상적인 점은 Cookpad가 Rails를 단순히 사용하는 데 그치지 않고, Rails Core 멤버를 직접 고용하고 오픈소스 도구를 공개하며 Rails 생태계에 지속적으로 기여해왔다는 점이에요.
20년 가까운 시간이 지난 지금도, Rails는 Cookpad의 핵심 인프라로서 여전히 역할을 하고 있어요.
전체 사례 읽기: How Rails Helps Cookpad Serve 100M+ Home Cooks