Hanami Rails 비교 2026, Ruby 웹 서비스 비용·운영·보안 기준

Hanami Rails 비교와 Ruby 웹 서비스 운영 선택을 검토하는 개발팀 책상 장면 — Hanami와 Rails 선택은 문법 취향보다 도메인 경계, 보안 기본값, 유지보수 비용을 숫자로 남기는 결정이다.

Hanami Rails 비교를 검색하는 팀은 보통 Ruby를 버릴지 남길지가 아니라, 이미 커진 Rails 코드베이스를 계속 끌고 갈지 더 작은 경계로 나눌지를 묻고 있다.

Rails는 풀스택 기본값과 인력 시장이 강하고, Hanami는 명시적인 비즈니스 로직과 슬라이스 구조를 앞세워 커진 앱의 경계를 다시 잡으려 한다.

결론부터 말하면 신규 핵심 서비스는 Rails가 여전히 안전한 기본값이고, 도메인 경계가 무너진 내부 도구나 백오피스 일부는 Hanami 파일럿으로 검증할 만하다.

다만 Hanami를 Rails 대체재로 바로 선언하면 안 된다.

공식 문서와 실제 팀 역량을 기준으로 설치 전제, 데이터 접근 방식, 보안 책임, 배포 관측, 업그레이드 일정을 같은 표에 놓고 비교해야 한다.

핵심 요약

Rails는 공식 사이트 기준 풀스택 웹 앱에 필요한 모델, 컨트롤러, 뷰, 라우팅, 비동기 작업, 파일 업로드, 보안 보호 기능을 넓게 묶어 제공한다.
Hanami는 공식 문서 기준 Ruby 3.1 이상을 전제로 하고, relation, repo, struct, operation, slice로 책임을 작게 분리하는 설계를 강조한다.
비용 판단은 프레임워크 라이선스보다 온보딩 시간, 업그레이드 기간, 테스트 보강, 운영 관측, 보안 리뷰 시간을 합산해야 한다.
파일럿은 전체 Rails 교체가 아니라 내부 관리자 기능, billing read model, API slice처럼 실패해도 되돌릴 수 있는 범위에서 시작해야 한다.

이 글이 필요한 사람

Rails 모놀리스가 커져서 도메인 경계와 테스트 시간이 병목이 된 백엔드 리드
Ruby 팀을 유지하면서 새 내부 서비스나 관리자 도구의 프레임워크를 다시 고르려는 CTO
Hanami 소개 글을 보고도 운영 비용과 보안 기본값을 어떻게 비교해야 할지 애매한 개발팀
Rails 업그레이드와 프레임워크 전환 중 어느 쪽이 더 싼지 예산표로 설명해야 하는 팀장
웹 애플리케이션 보안과 공급망 점검을 프레임워크 선택 회의에 넣고 싶은 보안 담당자

먼저 결론: Hanami는 Rails 대체제가 아니라 경계 재설계 후보로 본다

Hanami 공식 설명은 관심사 분리, 명시적인 비즈니스 로직, 모듈식 아키텍처를 통해 큰 Ruby 앱을 유지보수하기 쉽게 만드는 프레임워크라고 말한다.

Rails 공식 사이트는 풀스택 프레임워크로서 데이터 모델, 라우팅, 템플릿, 비동기 작업, 저장소, 보안 보호 기능을 한 묶음으로 제공한다고 설명한다.

두 설명을 나란히 놓으면 답은 단순하다.

팀이 빠르게 채용하고 기능을 넓게 만들어야 하면 Rails가 유리하다.

이미 Rails 안에서 결제, 정산, 관리자, 검색, 알림 경계가 뒤섞였고 새 기능은 독립적인 업무 흐름이면 Hanami가 검토 대상이 된다.

이 조건이면 Hanami 파일럿을 한다.

새 서비스가 작은 도메인 하나를 담당하고, HTTP 처리와 비즈니스 흐름을 분리해야 하며, 팀 안에 Ruby 구조 설계를 끌고 갈 사람이 있어야 한다.

이 경우는 보류한다.

팀에 Ruby 시니어가 1명뿐이거나, 인증·결제·관리자·메일·파일 업로드를 빠르게 묶어야 하거나, 채용 시장에서 Rails 경험이 더 중요한 상황이면 전환 비용이 커진다.

공식 설치 전제와 첫 파일럿 범위

Hanami v3.0 Getting Started 문서는 Hanami 앱 생성에 Ruby 3.1 이상과 Node.js를 요구하고, gem install hanami 뒤 hanami new로 앱을 만든다고 안내한다.

Rails 설치 가이드는 Rails 8 설치 흐름에서 Ruby를 확인하고 gem install rails 후 rails --version으로 설치를 검증하는 절차를 제시한다.

Rails 업그레이드 가이드는 Rails 8 계열이 Ruby 3.2.0 이상을 요구한다고 설명한다.

이 차이는 사소한 버전 표기가 아니다.

프로덕션 OS 이미지, CI 러너, 로컬 개발 환경, 보안 스캐너가 어떤 Ruby 버전을 지원하는지 먼저 맞춰야 하기 때문이다.

항목	Hanami 기준	Rails 기준	운영 판단
Ruby 전제	공식 Getting Started 기준 Ruby 3.1 이상	Rails 8.0·8.1 업그레이드 가이드 기준 Ruby 3.2.0 이상	런타임 이미지와 CI 러너 버전을 먼저 고정한다
앱 생성	gem install hanami, hanami new, bundle exec hanami dev	gem install rails, rails --version, Getting Started 흐름	파일럿 저장소에서 생성·부팅·테스트 시간을 기록한다
구조 기본값	relation, repo, struct, operation, slice를 명시적으로 나눈다	Active Record, Action Controller, Action View 등 풀스택 구성요소가 넓게 붙는다	팀이 명시성을 원하는지 기본 묶음을 원하는지 정한다
전환 난이도	기존 Rails 코드를 바로 옮기기보다 새 경계를 세우는 편이 안전하다	기존 Rails 앱은 같은 생태계에서 점진 업그레이드가 쉽다	빅뱅 전환은 금지하고 범위형 파일럿만 허용한다

비용 구조: 무료 프레임워크라도 전환 비용은 무료가 아니다

Hanami와 Rails는 모두 공개 저장소와 공식 문서로 개발되는 Ruby 프레임워크지만, 기업 의사결정의 비용은 라이선스 가격표 하나로 끝나지 않는다.

공식 가격표가 없는 오픈소스 프레임워크라도 테스트 보강, 업그레이드, 배포, 관측, 보안 리뷰, 채용 난이도는 실제 예산으로 돌아온다.

Rails 유지보수 정책은 minor release의 bug fix 기간을 1년, security fix 기간을 2년으로 설명한다.

같은 문서 기준 Rails 8.1.x는 bug fix가 2026년 10월 10일까지, security fix가 2027년 10월 10일까지 지원된다.

Rails 8.0.x는 bug fix가 2026년 5월 7일까지, security fix가 2026년 11월 7일까지 지원된다고 명시돼 있다.

비용 항목	공식 숫자·근거	Hanami Rails 비교에서 보는 방식	파일럿 기준
런타임 전제	Hanami Ruby 3.1 이상, Rails 8 계열 Ruby 3.2.0 이상	CI 이미지와 서버 런타임 변경 범위를 비용으로 본다	개발·스테이징·운영 3개 환경에서 부팅을 확인한다
Rails 유지보수 기간	bug fix 1년, security fix 2년 정책	기존 Rails 버전이 지원 종료에 가까우면 전환보다 업그레이드가 먼저다	지원 종료 6개월 전에는 업그레이드 티켓을 연다
Rails 현재 지원 예시	8.1.x security fix 2027년 10월 10일까지, 8.0.x security fix 2026년 11월 7일까지	새 프레임워크 논의 전에 현 버전의 보안 창을 확인한다	월 1회 dependency와 framework advisory를 확인한다
파일럿 인력	팀 내부 기준 2명 이상 reviewer와 1명 security reviewer가 필요하다	프레임워크 선택 회의가 아니라 리뷰 병목 비용을 측정한다	4주 동안 review cycle 24시간 초과 횟수를 기록한다
테스트 보강	파일럿 기준 test coverage floor 70%를 둔다	레거시 기능 이식보다 실패 경로 테스트를 우선한다	핵심 endpoint 3개와 rollback 1회를 검증한다

이 글은 LLM API 가격표가 아니므로 입력 토큰, 출력 토큰, USD 토큰 단가가 아니라 Ruby 프레임워크 라이선스, 유지보수 기간, 인력 시간, 런타임 인프라 단위를 본다.

원화 예산으로 바꿀 때는 내부 인건비, 클라우드 사용량, 장애 비용, 채용 리드타임을 조직 단가로 대입해야 한다.

아키텍처 비교: Rails의 넓은 기본값과 Hanami의 작은 경계

Rails의 장점은 많은 결정을 프레임워크 기본값으로 흡수한다는 점이다.

Active Record, Action Controller, Action View, Action Job, Active Storage 같은 구성요소가 같은 관례 안에서 움직이므로 새 팀원이 읽을 표면이 익숙하다.

Hanami의 장점은 같은 Ruby 안에서 책임을 더 좁게 끊는다는 점이다.

Hanami 데이터베이스 문서는 relation이 데이터 접근 패턴을 정의하고 repo가 비즈니스 로직과 데이터 질의 사이의 공용 인터페이스가 된다고 설명한다.

Operations 문서는 비즈니스 흐름을 Success와 Failure 결과로 나누고, 실패하면 이후 단계를 멈추는 선형 절차로 구성한다고 설명한다.

비교 축	Rails가 유리한 조건	Hanami가 유리한 조건	주의할 질문
초기 생산성	CRUD, 인증, 파일 업로드, 메일, 백오피스를 빠르게 묶어야 한다	작은 도메인 기능을 명시적으로 설계하고 테스트해야 한다	빠른 출시가 목표인지 장기 경계가 목표인지 정했는가
도메인 경계	한 제품 안에서 공통 모델과 화면 흐름을 공유한다	billing, admin, search처럼 경계가 분명한 subdomain을 나눈다	모델 공유가 장점인지 사고 원인인지 확인했는가
데이터 접근	Active Record의 모델 중심 질의가 팀 표준이다	relation과 repo로 질의 계층을 분리하고 싶다	쿼리 변경이 서비스 계층까지 번지는지 측정했는가
온보딩	채용 시장과 사내 경험이 Rails에 몰려 있다	시니어가 구조 교육과 리뷰를 맡을 수 있다	새 프레임워크 학습 시간을 비용표에 넣었는가
운영 관측	기존 Rails 관측, job, middleware 표준이 있다	작은 서비스별 부팅과 실패 경로를 새로 정의할 수 있다	로그, metric, error tracking을 누가 붙이는가

보안 기준: 프레임워크 선택은 OWASP 체크리스트와 함께 본다

Rails 보안 가이드는 프레임워크 자체보다 이를 쓰는 사람, 개발 방식, 백엔드 저장소, 웹 서버, 애플리케이션 전체 계층이 보안을 결정한다고 설명한다.

OWASP Top Ten은 웹 애플리케이션 보안 위험을 줄이기 위한 개발 조직의 공통 기준으로 쓰인다.

따라서 Hanami Rails 비교에서 보안 질문은 “어느 쪽이 더 안전한가”가 아니다.

질문은 “우리 팀이 인증, 세션, 권한, 입력 검증, 로그 마스킹, 의존성 업데이트를 어느 프레임워크에서 더 확실히 운영할 수 있는가”여야 한다.

보안 항목	Rails에서 확인할 것	Hanami에서 확인할 것	증적
인증·세션	Rails 8 인증 generator와 세션 모델을 쓸지 외부 IdP를 붙일지 결정한다	Hanami action과 operation 사이에서 인증 상태 전달 경계를 정한다	SSO 설계서와 세션 만료 테스트
입력 검증	controller params, model validation, strong parameter 경계를 기록한다	action params와 operation validation 실패 경로를 분리한다	실패 케이스 request spec
민감정보 로그	Rails filter_parameters와 error tracker 마스킹을 확인한다	logger provider와 slice별 logging 규칙을 확인한다	마스킹 샘플 로그
의존성	Gemfile, bundler audit, Dependabot, SBOM 생성을 표준화한다	Hanami 구성 gem과 dry-rb 계열 의존성 owner를 지정한다	월간 dependency review 기록
권한 경계	모놀리스 내부 admin 권한이 과도하게 넓지 않은지 본다	slice별 접근 정책과 route 노출 범위를 문서화한다	권한 매트릭스와 penetration test 메모

실무 시나리오 1: 내부 관리자 도구를 새로 만드는 팀

매출 정산, 쿠폰 승인, CS 조회 같은 내부 도구는 빠른 CRUD와 권한 관리가 함께 필요하다.

기존 조직이 Rails에 익숙하고 admin 기능을 빠르게 붙여야 한다면 Rails가 더 안전한 선택이다.

이 조건이면 Rails를 고른다.

기존 SSO, Active Record 모델, job queue, 파일 첨부, 감사 로그가 Rails 표준으로 이미 묶여 있으면 새 프레임워크는 학습 비용만 늘릴 수 있다.

이 경우 Hanami는 보류한다.

관리자 도구의 핵심 위험이 도메인 경계가 아니라 권한 검수와 빠른 출시라면 Rails의 익숙한 관례가 더 값싸다.

실무 시나리오 2: 결제 도메인을 모놀리스에서 떼어내는 팀

결제 승인, 환불, 청구 상태는 HTTP endpoint보다 실패 경로와 트랜잭션 경계가 더 중요하다.

Hanami Operations는 성공과 실패를 명시적으로 다루는 service layer에 가깝기 때문에 이 영역에서 실험 가치가 있다.

이 조건이면 Hanami 파일럿을 한다.

결제 원장 원본은 기존 Rails에 남기고, 읽기 모델이나 사내 검수 흐름처럼 되돌릴 수 있는 일부 기능만 별도 앱으로 잘라낸다.

성공 기준은 “Hanami로 만들었다”가 아니라 실패 경로 테스트, 로그 마스킹, rollback 절차, review cycle 시간이 기존 Rails보다 나아졌는지다.

실무 시나리오 3: 채용과 인수인계가 약한 작은 회사

작은 회사에서는 좋은 구조보다 사람이 떠난 뒤 남는 운영 위험이 더 크다.

Rails 경험자는 상대적으로 찾기 쉽고, 문서와 사례가 많으며, 기존 도구 체인도 풍부하다.

이 경우는 Rails를 유지한다.

Hanami를 쓰더라도 핵심 매출 서비스가 아니라 내부 reporting, webhook 수집, 읽기 전용 API 같은 작은 경계부터 시작한다.

프레임워크 선택은 기술 취향이 아니라 6개월 뒤 누가 장애를 보는지에 대한 인력 계획이다.

도입 전 파일럿 순서

현재 Rails 앱의 버전, Ruby 버전, 지원 종료 날짜, 보안 advisory 대응 시간을 먼저 표로 만든다.
새 프레임워크가 필요한 기능을 한 문장으로 제한하고, 전체 교체나 대규모 rewrite라는 표현을 금지한다.
같은 요구사항으로 Rails spike와 Hanami spike를 각각 만들고 첫 endpoint, test, deploy, rollback 시간을 기록한다.
보안 reviewer가 인증, 세션, 입력 검증, 로그 마스킹, 의존성 스캔을 같은 체크리스트로 본다.
운영 reviewer가 health check, structured logging, error tracking, background job, database migration 경로를 확인한다.
4주 뒤 점수표로 결정하고, Hanami가 이겨도 기존 Rails 기능을 한 번에 옮기지 않는다.

이 순서에서 가장 중요한 금지어는 “나중에 붙이면 된다”다.

인증, 관측, rollback, dependency scanning이 파일럿에 없으면 생산성 비교도 의미가 없다.

운영 스켈레톤: 4주 파일럿 YAML

아래 YAML은 Hanami나 Rails 설정 파일이 아니라 프레임워크 선택 회의의 실패 조건을 고정하는 템플릿이다.

프레임워크 토론이 길어질수록 취향 논쟁으로 흐르기 쉬우므로, 처음부터 기간, 측정값, 중단 조건을 적어 둔다.

# ruby-framework-pilot.yaml
# 목적: Hanami Rails 비교를 취향 논쟁이 아니라 4주 파일럿 결과로 판단한다.
# 실제 서비스명, 팀명, 비용 한도, 보안 기준은 조직 정책에 맞게 바꾼다.

framework_pilot:
  owner: backend-platform-lead
  candidate_a: rails_existing_or_new
  candidate_b: hanami_slice_or_new_service
  pilot_scope: internal-admin-and-billing-read-model
  duration_weeks: 4
  decision_date: 2026-09-30

entry_criteria:
  ruby_runtime:
    hanami_minimum: ruby_3_1_or_newer
    rails_8_minimum: ruby_3_2_0_or_newer
  team_capacity:
    senior_ruby_engineers: 2
    reviewer_pool: 3
    security_reviewer: 1
  production_blockers:
    - unsupported_authentication_flow
    - missing_observability_hook
    - dependency_without_owner

measurement:
  delivery:
    first_endpoint_target_days: 3
    test_coverage_floor_percent: 70
    review_cycle_limit_hours: 24
  operations:
    boot_time_recorded: true
    deploy_rollback_tested: true
    error_budget_policy_written: true
  security:
    session_policy_reviewed: true
    dependency_scan_clean: true
    owasp_top10_check_completed: true

stop_conditions:
  - no_clear_owner_for_operations
  - migration_requires_big_bang_rewrite
  - security_defaults_unclear_after_week_2
  - total_review_time_above_budget_for_2_weeks

검증 스크립트: 같은 질문으로 두 후보를 본다

프레임워크 비교는 데모 화면보다 반복 가능한 검증 질문이 중요하다.

아래 Ruby 스켈레톤은 실제 명령을 실행하는 자동화가 아니라 저장소별 전제 파일과 부팅 명령을 점검 목록으로 고정하는 예시다.

# framework_probe.rb
# 목적: Rails와 Hanami 후보를 같은 질문으로 점검하기 위한 검증 스켈레톤이다.
# 실제 저장소 경로, 테스트 명령, 배포 명령은 팀 표준에 맞게 바꾼다.

Probe = Struct.new(:name, :boot_command, :test_command, :required_files)

candidates = [
  Probe.new('rails', 'bin/rails runner "puts Rails.env"', 'bin/rails test', ['Gemfile', 'config/routes.rb']),
  Probe.new('hanami', 'bundle exec hanami console', 'bundle exec rspec', ['Gemfile', 'config/routes.rb'])
]

failures = []

candidates.each do |candidate|
  missing = candidate.required_files.reject { |path| File.exist?(path) }
  failures << "#{candidate.name}: missing #{missing.join(', ')}" unless missing.empty?
  puts "check #{candidate.name}: boot=#{candidate.boot_command}, test=#{candidate.test_command}"
end

if failures.any?
  abort failures.join('
')
end

puts 'framework probe checklist prepared'

실제 CI에 붙일 때는 각 저장소 루트에서 실행하고, 부팅 시간과 테스트 시간을 별도 로그로 수집한다.

민감한 환경 변수와 production credential은 스크립트에 넣지 말고 secret manager와 로컬 개발 전용 값으로 분리한다.

의사결정 루브릭: 점수는 낮아도 이유가 남아야 한다

최종 회의에서는 Rails를 좋아하는 사람과 Hanami를 좋아하는 사람이 아니라, 운영 책임자와 보안 책임자가 같은 표를 봐야 한다.

아래 의사코드는 실제 제품 점수를 단정하는 것이 아니라 팀이 어떤 기준을 가중치로 보는지 드러내기 위한 예시다.

# decision-rubric.rb
# 목적: 프레임워크 선택 회의를 점수표로 고정하기 위한 의사코드다.
# 숫자는 예시이며 팀의 실제 위험 선호도에 맞춰 가중치를 조정한다.

weights = {
  delivery_speed: 0.25,
  domain_boundary: 0.20,
  hiring_and_onboarding: 0.20,
  security_defaults: 0.20,
  upgrade_path: 0.15
}

scores = {
  rails:  { delivery_speed: 5, domain_boundary: 3, hiring_and_onboarding: 5, security_defaults: 4, upgrade_path: 4 },
  hanami: { delivery_speed: 3, domain_boundary: 5, hiring_and_onboarding: 3, security_defaults: 3, upgrade_path: 3 }
}

scores.each do |name, values|
  total = values.sum { |key, score| score * weights.fetch(key) }
  puts "#{name}: #{total.round(2)}"
end

점수표가 Hanami를 가리켜도 바로 전환하지 않는다.

먼저 한 slice 성격의 기능을 운영에 붙이고, 장애 대응과 인수인계 문서가 통과한 뒤 다음 범위를 정한다.