레일즈의 실제 이야기: 20년간의 설계와 결정

Ruby on Rails: 20년간의 설계와 결정

Ruby의 선택 배경

• 문제 인식: DHH는 2003-2004년 PHP와 Java(XML 헬)의 비효율성에 한계를 느꼈습니다.
• Ruby 채택: Martin Fowler와 Dave Thomas의 영향으로, 개발자 행복을 최우선하는 Ruby를 Basecamp 프로젝트에 선택했습니다.

Rails의 탄생 및 철학

• 프레임워크 추출: Ruby로 Basecamp 개발 시 툴링이 없어 DHH가 직접 구축했고, 이 경험을 공유하고자 Rails를 추출하여 오픈 소스화했습니다.
• 핵심 철학: “최소한의 놀라움”과 “더 큰 미소”를 지향하며, array.42 같은 기능으로 개발자 편의성을 강조합니다.

Rails의 주요 설계 원칙

• 명칭: “Rails”는 미리 정의된 의견을 가진 “가드레일”을 의미하며, 도메인 문제로 “Ruby on Rails”가 되었습니다.
• 컨벤션 오버 컨피규레이션 (CoC): XML 헬의 대안으로, 프레임워크가 지능적인 기본값을 제공합니다 (예: User 클래스 -> users 테이블).
• DRY (Don’t Repeat Yourself): “The Pragmatic Programmer”에서 영감을 받아 지식의 단일 표현을 강조합니다.
• MVC 패턴: 당시 확립된 패턴으로, CoC와 일치하여 코드 구성의 반복적인 결정을 제거했습니다.
• Active Record ORM: Martin Fowler의 패턴에서 유래, 객체가 DB 작업에 적극 참여함을 강조하며 Active와 Action 접두사로 컴포넌트를 구분합니다.
• Omakase (おまかせ) 접근: DHH의 시간 제약 속 “적은 노력으로 많은 것을 얻는” 정신으로, Rails는 “배터리 포함” 접근 방식을 취한 선구적 프레임워크입니다.
• RESTful 아키텍처: Rails 2.0에 도입되어 단순성, 일관성, 발견 용이성, 도메인 모델링 및 API 개발 용이성을 제공합니다.

Rails의 발전과 주요 기능

• 모듈성 및 MERB 병합: Rails 3.0은 MERB 병합을 통해 모듈성을 강화하고 성능을 개선했습니다.
• Strong Parameters: 2012년 Mass Assignment 보안 취약점 해결을 위해 도입, 허용된 파라미터만 명시적으로 처리하여 보안을 강화했습니다.
• Bundler: 초기 Gem 의존성 관리의 복잡성을 해결, 애플리케이션별 의존성 해결 및 Gemfile 관리를 가능하게 하여 개발 환경을 크게 개선했습니다.