이 글은 2024년 5월 23일에 업데이트되어 Rails와 Hanami 간의 모델 및 데이터 영속성(persistence) 차이를 더 명확하게 설명했습니다.
Ruby on Rails는 루비(Ruby) 생태계에서 가장 인기 있는 웹 프레임워크로, 프리랜서부터 대형 기업에 이르기까지 폭넓은 사용자층을 자랑합니다. 활발한 커뮤니티와 방대한 공식 문서 덕분에 간단한 애플리케이션부터 복잡한 웹 플랫폼까지 무엇이든 구축할 수 있습니다.
그러나 이제 Rails의 독주에 도전하는 강력한 경쟁자가 등장했습니다. 바로 Hanami입니다. Rails보다 뛰어난 성능과 유지보수성을 제공하도록 설계된 빠르고 모듈화된 루비 프레임워크입니다.
이 글에서는 성능, 기능, 테스트 등 다양한 측면에서 두 프레임워크의 장단점을 심층적으로 비교합니다. 고객용 웹 앱, 사내 도구, 대규모 확장형 API 중 무엇을 개발하려 하든, 이 글을 읽고 나면 다음 프로젝트에 어떤 프레임워크가 적합한지 훨씬 명확하게 판단할 수 있을 것입니다.
먼저 두 프레임워크를 간략히 소개하겠습니다.
Ruby on Rails란?
Ruby on Rails는 루비에서 가장 잘 알려진 웹 애플리케이션 개발 프레임워크로, '앱은 이렇게 만들어야 한다'는 일련의 전제를 통해 개발자 생산성을 극대화하는 것이 목표입니다. 흔히 "Rails다운 방식(the Rails way)"이라 불리는 철학입니다.
이러한 전제에는 개발자가 설정 작업에 시간을 낭비하지 않도록 하는 "관습 우선(convention over configuration)" 원칙과, 코드 반복을 피하는 DRY(Don't Repeat Yourself) 원칙이 포함됩니다. DRY 원칙은 동일한 코드를 계속 반복 작성하기보다 앱 기능을 단일하고 집중적인 형태로 표현함으로써 유지보수성과 코드 정합성을 높이도록 권장합니다.
Hanami란?
Rails가 루비 커뮤니티에서 널리 알려진 반면, Hanami는 상대적으로 덜 알려져 있습니다. Rails가 장악한 풀스택 웹 프레임워크 시장에 도전하는 비교적 신생 모던 루비 프레임워크입니다.
Hanami는 처음부터 작은 메모리 점유율과 높은 모듈성에 초점을 맞춰 설계되었으며, 이 덕분에 매우 빠르고 민첩한 프레임워크로 탄생했습니다.
물론 이 정도의 소개만으로는 어떤 프레임워크가 나에게 맞는지 판단하기 어렵습니다. 지금부터 두 프레임워크를 더 깊이 들여다보며, 그 첫걸음으로 구조와 아키텍처를 살펴보겠습니다.
Rails와 Hanami의 구조와 아키텍처
Rails와 Hanami는 둘 다 루비 프레임워크라는 점에서 유사하지만, 실제 설계 방식과 애플리케이션 아키텍처에서 큰 차이를 보입니다.
우선 Rails는 추상화(abstraction) 계층, 즉 앱을 구성하는 빌딩 블록의 수가 적고, 파일 하나하나가 개발이 진행될수록 커지는 경향이 있습니다. 반면 Hanami는 추상화를 한 단계 더 발전시켜, 파일 수는 많지만 각각의 크기는 작게 유지합니다.
아래 다이어그램이 이를 더 잘 보여줍니다. 먼저 Rails의 구조부터 확인해 보세요.
이제 Rails의 추상화 다이어그램을 Hanami의 다이어그램과 비교해 보겠습니다.
보시다시피 두 프레임워크 모두 일반적으로 MVC(Model-View-Controller) 구조를 따르지만, Hanami는 추상화를 한층 더 진전시켰습니다.
각 프레임워크가 조직화된 방식을 간략히 정리하면 다음과 같습니다.
- 라우팅(Routes) — 두 프레임워크 모두 앱의 엔드포인트를 정의하는 라우트 파일을 가집니다.
- 컨트롤러 vs 액션 — Rails는 하나 이상의 액션을 포함하는 컨트롤러를 사용하며, 컨트롤러가 라우트 요청을 받아 해당 액션으로 연결합니다. 반면 Hanami에는 컨트롤러가 없습니다. 대신 각각 독립된 클래스를 가진 자체 완결형(self-contained) 액션으로 바로 연결됩니다.
- 모델과 영속성 — Rails의 모델 계층은 데이터 유효성 검사와 데이터베이스 통신, 앱에서 필요한 쿼리 처리까지 담당하며, 영속성은 Ruby Object Mapper(ROM)가 관리합니다. 반면 Hanami의 모델 계층은 더 추상화되어 엔티티(entities)와 리포지토리(repositories)로 분리됩니다. 엔티티는 도메인 로직을 처리하며 데이터베이스에 종속되지 않고, 리포지토리(repo)가 데이터베이스와의 통신을 담당합니다. 또한 Hanami 2.0부터는 미리 구성된 영속성 계층 없이 출시되므로, 필요에 맞는 ORM(Object Relational Mapper)을 직접 선택하거나 아예 ORM 없이 개발할 수도 있습니다.
- 뷰 렌더링 — 영속성 계층과 마찬가지로 Rails의 뷰는 외부에 데이터를 렌더링하는 데 필요한 모든 것(HTML 구조, 뷰 헬퍼, 뷰 로직)을 한곳에 담는 경향이 있습니다. Hanami의 뷰 렌더링은 더 추상적입니다. 뷰(views)가 앱의 뷰 헬퍼를 활용해 템플릿(template)을 렌더링하고, 템플릿이 실제 HTML 구조를 담당하며, 파트(parts)가 프레젠테이션 로직을 처리합니다.
그렇다면 실제 앱 개발에서는 무엇을 의미할까요? 추상화 계층이 적은 Rails는 앱을 빠르게 시작하기 좋은 선택이며 초보자에게도 친숙합니다(뒤에서 자세히 다룹니다). Rails로 견고한 모놀리식(monolith) 앱을 만들 수 있지만, 규모가 커질수록 코드는 점점 복잡해집니다. 반면 Hanami의 복잡한 구조는 배우기 어렵게 느껴질 수 있지만, 대규모 확장이 가능한 애플리케이션을 만들 수 있게 해주고 훨씬 뛰어난 코드 정합성을 제공합니다.
다음으로 각 프레임워크의 생태계를 살펴보겠습니다.
생태계와 커뮤니티
앞서 언급했듯이 Rails는 Hanami보다 오래되었고, 그만큼 더 크고 성숙한 커뮤니티를 보유하고 있습니다.
생태계와 커뮤니티의 차이를 정리하면 다음과 같습니다.
- 문서화 — 무엇을 만들려 하든 Rails를 사용하면 훌륭하게 작성된 문서를 활용할 수 있습니다. 인증부터 데이터 영속성, 뷰 렌더링까지 앱 개발의 모든 과정을 안내받을 수 있고, 서드파티 튜토리얼도 거의 모든 주제를 망라합니다.
반면 Hanami 쪽은 상황이 다릅니다. 비교적 신생 프레임워크인 만큼 문서 기반이 상대적으로 제한적입니다. Hanami 팀은 공식 가이드를 인상적으로 잘 만들었지만, Rails의 방대한 문서량에는 미치지 못합니다.
- 커뮤니티 — 문서와 마찬가지로 Rails가 명확한 승자입니다. Rails가 훨씬 오래되어 가장 많이 채택되었으며, 초보자든 숙련자든 관련 서브레딧, Slack 그룹, Discord 등에서 활발한 Rails 커뮤니티를 찾을 수 있습니다. 반면 Hanami는 아직 성장 중이라 커뮤니티 규모가 훨씬 작습니다.
- 젬(Gems)과 라이브러리 — Hanami와 Rails 모두 루비 프레임워크이므로 Rails에서 작동하는 젬이 Hanami에서도 작동한다고 볼 수 있습니다. 기술적으로는 맞지만, 특수한 기능을 위한 젬과 라이브러리 기반은 Rails 쪽이 훨씬 탄탄한 편입니다.
그럼에도 Hanami는 추상화와 전문화에 집중한 덕분에 Rails 앱을 한 단계 끌어올릴 수 있는 매우 고급스러운 젬들을 보유하고 있습니다. 예를 들어 Hanami의 기본 dry-rb 젬들은 Rails 앱에서 활용하면 더 나은 코드 정합성과 추상화를 가져다줄 수 있습니다.
이어서 각 프레임워크의 학습 곡선과 산업 채택 현황을 비교해 보겠습니다.
사용 용이성, 채택률, 거버넌스, 학습 곡선
앞서 언급한 이유들 때문에 Ruby on Rails는 사용 용이성, 산업 채택률, 학습 곡선 면에서 Hanami를 손쉽게 앞섭니다.
- 학습 — 완전 초보자가 새로운 프로그래밍 언어를 배우려 한다면 가장 먼저 온라인 학습 자료를 찾아볼 것입니다. 앱 개발 과정을 처음부터 끝까지 다루는 학습 자료가 풍부한 프레임워크라면 다른 언어보다 먼저 선택하게 됩니다. Rails는 더 탄탄한 문서 기반을 갖추고 있어 초보자에게 Hanami보다 확실히 유리합니다. 게다가 Rails는 내부적으로 수많은 전제를 자동으로 처리해 주기 때문에(Hanami가 더 추상적인 방식을 제공하는 것과 대조적) 초보자가 시작하기 훨씬 수월합니다. Hanami의 추상화는 베테랑 Rails 개발자에게조차 부담스러울 수 있습니다.
- 산업 채택률 — Python, React, C# 같은 다른 인기 프레임워크의 채택률은 제외하고 루비 프레임워크만 놓고 보면, Rails가 Hanami를 압도합니다. Rails 홈페이지에는 이 프레임워크를 사용하는 저명한 기업들이 소개되어 있습니다. 반면 후발 주자인 Hanami는 아직 널리 채택되지 않았으며, 향후 상황이 변할지는 지켜볼 필요가 있습니다.
- 취업 전망 — 취업 시장에서도 Hanami 개발자보다 Rails 개발자 공고를 훨씬 더 많이 찾아볼 수 있습니다.
- 거버넌스 — 간과해서는 안 되는 중요한 요소로 거버넌스가 있습니다. 변화하는 환경은 오픈소스 프레임워크가 어떻게 진화할지 결정짓고, 핵심 팀원들은 프레임워크에 무엇을 넣을지, 어떻게 발전시킬지 등을 좌우할 막강한 영향력을 행사하는 경우가 많습니다.
좋은 예로 Rails 창시자 데이비드 하이네마이어 한슨(DHH)이 1월에 발표한 내용을 들 수 있습니다. 그는 앞으로 Rails가 풀스택 프로그레시브 웹 애플리케이션과 네이티브 알림에 대한 최상급 지원을 제공하도록 밀어붙이겠다고 밝혔습니다. 이 기능들이 추가되면 Rails는 모바일 개발자에게 매우 매력적인 선택지가 됩니다.
이에 대해 루비 생태계 외부의 개발자들과 한동안 Rails를 떠났던 개발자들까지, 많은 이들이 압도적으로 호응하며 DHH가 약속을 지켜준다면 기꺼이 프레임워크를 다시 사용하거나 배우겠다고 밝혔습니다. 이 사례는 프레임워크를 선택할 때 거버넌스가 얼마나 중요한 고려 요소인지 잘 보여줍니다.
이제 좀 더 기술적인 주제인 애플리케이션 성능을 살펴보겠습니다.
성능: Ruby on Rails vs Hanami
개발자라면 앱의 안정성, 응답성, 그리고 프로덕션 환경에 배포된 후 서버 자원을 얼마나 효율적으로 사용할지 걱정하게 됩니다. 이런 기본적인 고민은 프레임워크 선택에 큰 영향을 줍니다.
앱의 성능 테스트는 여러 방법으로 수행할 수 있으며, 그중 가장 인기 있는 도구가 Apache JMeter입니다. 여기서는 벤치마크 수치로 Hanami와 Rails를 비교해 보겠습니다.
아래는 각 프레임워크가 초당 처리할 수 있는 요청 수를 보여주는 간단한 벤치마크 결과입니다.
Hanami는 Rails를 완벽히 앞서며, Rails보다 약 3배 많은 요청을 처리할 수 있습니다.
다음 스크린샷은 각 프레임워크의 평균 지연 시간(latency)을 보여줍니다.
역시 Hanami가 승리하며, 평균 지연 시간이 Rails보다 약 3배 짧습니다.
번개처럼 빠른 루비 프레임워크를 찾고 있다면(예를 들어 빠르고 대규모 확장이 가능한 API를 개발해야 하는 경우), 루비 진영에서 Hanami보다 나은 선택을 찾기 어려울 것입니다.
테스트
코드 테스트 측면에서 두 프레임워크는 매우 비슷합니다. 둘 다 다재다능한 RSpec 라이브러리로 테스트할 수 있기 때문입니다.
Hanami 앱에서는 hanami-rspec 젬을 통해 RSpec이 포함되며, Rails 앱에서는 rspec-rails 젬을 설치해야 사용할 수 있습니다. 아래 예시는 새로 생성한 Hanami 앱에 기본 포함된 아주 간단한 테스트 스펙입니다.
$ bundle exec rspec spec/requests/root_spec.rb 명령으로 실행하면(기본 뷰 템플릿을 수정하지 않았다고 가정) 테스트가 통과됩니다.
Rails 쪽에서는 몇 가지를 직접 처리해야 합니다. 먼저 아래와 같이 Gemfile의 development/test 블록에 RSpec 젬을 추가한 후 bundle 명령을 실행합니다.
다음 단계는 bundle exec rails generate rspec:install 명령으로 RSpec 설치를 진행해 Rails 프로젝트에서 사용할 수 있도록 준비하는 것입니다.
마지막으로 테스트를 작성하고 실행하기 전에, Rails 앱의 테스트 데이터를 정의하기 위한 FactoryBot 젬을 추가로 설치해야 할 가능성이 높습니다.
테스트 스위트를 올바르게 구성하고 몇 가지 테스트를 정의했다면, Hanami에서와 마찬가지로 bundle exec rspec spec/models/user_spec.rb 명령으로 테스트를 실행할 수 있으며, 결과도 동일한 방식으로 확인할 수 있습니다.
마지막으로 배포 측면에서 두 프레임워크를 비교해 보겠습니다.
배포
요즘은 루비 앱을 프로덕션 환경에 배포할 수 있는 선택지가 매우 다양합니다.
우선 Heroku나 Fly 같은 PaaS(Platform-as-a-Service) 제공업체를 이용하면 매끄러운 배포 경험을 얻을 수 있습니다. 조금 더 DevOps에 도전하고 싶다면 VPS에 Docker를 설치하고 앱을 배포하는 방법도 있습니다.
어떤 방법을 선택하든 두 프레임워크의 배포 과정은 상대적으로 비슷할 것으로 기대할 수 있습니다. 유일한 주의점은 Hanami 앱 배포를 위한 상세한 문서와 튜토리얼이 부족하다는 점입니다.
앞서 언급했듯이 Hanami는 비교적 신생 프레임워크라 배포 과정과 발생할 수 있는 문제들을 다루는 방대한 문서가 아직 없습니다. 이 정도의 불편을 감수할 수 있다면 큰 문제 없이 진행할 수 있습니다.
마무리
이 글에서는 Ruby on Rails와 Hanami라는 두 루비 프레임워크를 기능, 아키텍처, 성능 등 다양한 측면에서 비교해 보았습니다. 결국 핵심 질문은 "어떤 프레임워크를 사용해야 하는가?"입니다. 이를 요약하면 다음과 같습니다.
- 루비 초보 개발자라면 Rails부터 시작하세요. 배우기 쉽고 학습 자료가 풍부합니다. 반면 숙련된 루비 개발자라면 Hanami 역량을 키우는 것이 좋습니다. 더 견고한 루비 애플리케이션을 개발하는 데 큰 도움이 됩니다.
- 빠른 앱을 개발해야 한다면, 예를 들어 여러 클라이언트에 서비스를 제공하는 API라면 Hanami의 작은 메모리 점유율, 번개 같은 응답 속도, 낮은 지연 시간이 훌륭한 선택이 됩니다. 반면 SaaS 아이디어 검증용 모놀리식 풀스택 앱을 만들어야 한다면 Rails가 확실히 더 빠르게 목표에 도달하게 해줍니다.
궁극적으로 어떤 프레임워크를 선택할지는 여러분의 몫입니다. 두 프레임워크 모두 익혀두는 것도 나쁘지 않은 전략입니다. 그렇게 하면 프로젝트의 요구 사항에 따라 최적의 프레임워크를 유연하게 선택할 수 있습니다.
즐거운 코딩 되세요!
P.S. Ruby Magic의 글을 발행 즉시 읽고 싶으시다면 Ruby Magic 뉴스레터를 구독하고 어떤 글도 놓치지 마세요!
P.P.S. AppSignal이 Rails와 Hanami 모두를 위한 통합 기능을 제공한다는 사실을 알고 계셨나요?