Ruby on Rails의 탄생 배경: ‘Why’ 스토리
-
Why Ruby? 2003년-2004년 당시, DHH(David Heinemeier Hansson)는 37signals에서 PHP와 Java 기반 프로젝트를 진행하며 각각의 고질적인 문제점(Java의 XML 설정 복잡성, PHP의 구조 부재로 인한 유지보수 어려움)에 직면했습니다. 그는 Martin Fowler와 Dave Thomas 같은 영향력 있는 사상가들이 Ruby를 활용하여 개념을 설명하는 것을 보고 Ruby에 관심을 갖게 되었습니다. Basecamp 프로젝트 개발 시 언어 선택의 자유가 주어지자, DHH는 자신이 존경하는 이들이 Ruby를 선택하는 것을 보고 깊은 인상을 받아 Ruby를 시도했습니다. 그는 Ruby를 ‘프로그램 자체를 위해 프로그래밍하는’ 경험을 제공하는 예외적인 언어라고 평하며, Python과의 비교를 통해 Ruby가 개발자의 행복(programmer happiness)을 우선시하는 인간 중심적 설계를 지향함을 강조했습니다.
-
Why Rails? Ruby로 Basecamp 웹 애플리케이션을 개발하면서 DHH는 Ruby 생태계에 웹 개발 도구가 부족함을 깨닫고 직접 필요한 도구들을 구축했습니다. Ruby를 통한 개발 경험이 이전의 Java나 PHP보다 훨씬 즐거웠기에, 그는 이 경험을 다른 개발자들과 공유하고자 Basecamp에서 Ruby on Rails 프레임워크를 추출하여 오픈소스로 공개했습니다. 이는 Ruby 개발자들이 전문적인 웹 애플리케이션을 구축할 수 있도록 지원하며 Ruby의 활용을 촉진했습니다. Rails Doctrine에서 언급된 ‘Ruby는 최소한의 놀라움 원칙, Rails는 DHH의 더 큰 미소 원칙으로 설계되었다’는 문구는 프레임워크의 개발자 친화적인 철학을 잘 보여줍니다.
array.42와 같은 독특한 메서드(실제로는array.first부터array.fifth까지 존재하며,array.42는 개발자 커뮤니티의 논쟁에 대한 유머러스한 응답으로 추가됨)와 과거의 동적 파인더(dynamic finders)는 이러한 철학을 반영합니다. -
Why the name Ruby on Rails? ‘Rails’라는 이름은 Ruby를 웹 개발에 사용하되, 기차가 레일을 따라 부드럽게 달리듯 미리 정의된 의견과 선택을 제공하는 ‘가드레일’ 역할을 한다는 의미를 내포했습니다. 그러나 실제로는 ‘rails.com’이나 ‘rails.org’와 같은 이상적인 도메인 이름을 확보할 수 없어 ‘rubyonrails.com’을 사용하게 된 비하인드 스토리가 있습니다.
-
Why Convention over Configuration (CoC)? Rails의 가장 핵심적인 원칙인 CoC는 2003-2004년 Java 개발자들이 겪었던 ‘XML 지옥’의 직접적인 해독제로 탄생했습니다. 당시 XML 설정 파일은 때로 전체 애플리케이션 코드보다 방대했습니다. Rails는 프레임워크가 지능적인 가정을 통해 합리적인 기본값을 제공함으로써, 개발자가 모든 사소한 세부 사항을 명시적으로 정의할 필요 없이 핵심 비즈니스 로직에 집중할 수 있도록 했습니다. 이는 ‘명시적인 것이 암시적인 것보다 낫다’는 당시의 지배적인 개발 철학에 정면으로 도전하는 것이었습니다.
-
Why DRY (Don’t Repeat Yourself)? 이 원칙은 Dave Thomas의 저서 “The Pragmatic Programmer”에서 영감을 받았으며, ‘모든 지식은 단일하고 명확하며 권위 있는 표현을 가져야 한다’는 사상을 따릅니다. 다만, 과도한 DRY는 오히려 불필요한 복잡성을 야기할 수 있다는 주의사항도 함께 언급됩니다.
-
Why MVC (Model-View-Controller)? MVC는 2003-2004년 당시 이미 잘 정립된 디자인 패턴이었으며, Rails의 CoC 철학과 완벽하게 부합했습니다. 이는 코드 구성 방식에 대한 반복적인 결정의 필요성을 제거하여 개발 효율성을 높였습니다.
-
Why Active Record ORM? Active Record 패턴은 Martin Fowler의 책에서 유래했습니다. ‘Active’라는 이름은 객체가 단순히 수동적인 데이터 컨테이너가 아니라, 데이터베이스 작업을 직접 수행하며 그 생명 주기에 적극적으로 참여한다는 의미를 강조합니다. 이는 Rails의 명명 규칙(‘Active’ 접두사는 데이터 또는 유틸리티 관련 구성 요소, ‘Action’ 접두사는 사용자 상호 작용 또는 웹 특정 프로세스 처리 구성 요소)에도 영향을 미쳤습니다.
-
Why Omakase (오마카세)? Rails는 요리사에게 모든 것을 맡기는 ‘오마카세’ 접근 방식을 취했습니다. DHH가 Basecamp 개발에 주당 10시간만 할애할 수 있었던 제약 속에서 ‘적은 것으로 많은 것을 얻으려는’ 정신에서 비롯되었습니다. 이는 Rails가 ‘처음부터 빌드된’ 것이 아니라 기존 애플리케이션에서 ‘추출된’ 독특한 탄생 배경을 가졌음을 의미하며, ‘배터리 포함(batteries-included)’ 접근 방식을 취한 최초의 프레임워크 중 하나였습니다.
-
Why REST (Representational State Transfer)? Rails 2.0부터 REST는 프레임워크의 중요한 아키텍처로 채택되었습니다. 단순성, 일관성, 발견 용이성(일관된 URL 패턴), 더 나은 도메인 모델링(CRUD 원칙의 중요성), 그리고 API 개발 용이성 등이 REST를 채택한 주요 이유입니다.
기타 주요 스토리
-
Modularity and the MERB Merger: 2009년-2010년 MERB 프레임워크와의 합병을 통해 Rails 3부터 모듈화가 크게 강화되었습니다. 이전에는 Rails 전체를 사용해야 했지만, 합병 이후에는 Rails의 여러 구성 요소를 독립적으로 사용할 수 있게 되어 유연성과 확장성이 향상되었습니다. 이는 또한 성능 개선에도 기여했습니다.
-
Strong Parameters: 2012년 Mass Assignment 취약점(사용자가 임의의 파라미터를 통해 민감한 데이터를 수정할 수 있는 보안 문제)이 발견되면서,
params.permit(:allowed_param)과 같이 허용된 파라미터만 명시적으로 지정하는 Strong Parameters 기능이 도입되어 애플리케이션의 보안이 크게 강화되었습니다. -
Days Before Bundler: Bundler 이전에는
environment.rb와config.gems파일을 통해 Gem 의존성을 수동으로 관리했습니다. 이는 특히 여러 Rails 애플리케이션이 공존할 때 의존성 충돌과 관리의 어려움을 초래하는 ‘지옥’과 같았습니다. Bundler는Gemfile과Gemfile.lock을 통해 애플리케이션별로 격리된 의존성 관리를 가능하게 하여 이 문제를 해결했습니다.