Rails for Everything - 모든 것을 위한 Rails의 강력함

• Rails 8은 소규모 프로젝트 및 1인 개발자에게 매우 유용함
• 최신 시작 가이드로 프로덕션 수준의 앱을 손쉽게 구축할 수 있음
• SQLite의 개선으로 추가 서버 없이 강력한 데이터베이스 환경 조성이 가능함
• 기본 제공 연속 통합(CI)과 인증 생성기로 개발 효율성과 보안 강화가 이루어짐
• Kamal을 통한 간편한 배포 방식으로 빠르고 안전하게 서비스를 운영할 수 있음

---

개요

• Rails 8의 활용 경험을 바탕으로, 소규모 프로젝트나 개인 개발자를 위한 탁월한 웹 프레임워크임
• 빠른 구축, 효율적인 배포, 내장된 모듈 등을 통해 경쟁 프레임워크 대비 생산성 측면의 장점이 두드러짐

최신 가이드의 우수성

• 최신 Getting Started with Rails 가이드는 입문자도 프로덕션 앱을 만들어볼 수 있도록 구성되어 있음
• Ruby 설치 과정에 여전히 복잡함이 있지만, 가이드의 안내만 따르면 인증, 캐싱, 리치 텍스트, 연속 통합, 데이터베이스가 모두 적용된 견고한 서비스 구축 가능임
• 단순한 ‘Hello World’가 아닌, 실제 서비스 수준의 기본기와 기능 제공이 강점임
• Rails에 익숙하지 않은 초심자에게 최적의 출발점이 됨

SQLite 하나면 충분함

• SQLite는 기본적으로 뛰어난 툴이나, 그간 프로덕션용으로 쓰기엔 손쉬운 구성이 어려웠던 점이 있었음
• 이전에는 추가 젬 설치 등 별도 작업이 필요했으나, Rails 8에서는 별도 작업 없이도 생산 환경에서 안정적으로 사용 가능함
• PostgreSQL이나 별도 서버를 띄우지 않아도 되고, solid cache를 활용하면 redis 서버도 필요하지 않음
• Rails와 SQLite만으로 서비스 구동이 가능하며, 구축 및 운영의 단순성과 비용 효율성을 극대화할 수 있음

손쉬운 연속 통합(CI)

• 초기 커밋 후 연속 통합(CI) 실패 알림이 도착할 정도로, Rails 8에서 기본 연동된 CI 설정이 제공됨
• 별도 작업 없이 GitHub Actions와 연동되고, 매달 2,000분의 무료 실행 시간을 제공받을 수 있음
• 1인 개발자 입장에서는 상당히 넉넉한 시간임

인증 생성기의 도입

• 기존 Devise 같은 인증 젬(Gem)은 강력하지만 구성의 복잡성 때문에 초보자에게는 다소 어렵게 느껴졌음
• Rails 8에서는 간단한 인증 생성기가 추가되어, 콘솔에서 기존 사용자만 추가하면 쉽게 로그인 플로우 구현 가능함
• 생성된 코드는 간단하고 읽기 쉬워서 초보자도 이해하기에 수월함

Kamal을 이용한 간편하고 빠른 배포

• 배포 과정을 Kamal이 책임져, deploy.yml 파일 일부만 수정하고 안내대로 따르면 즉시 SSL 환경에서 앱을 가동할 수 있음
• GitHub Pages에 SSL을 연결하는 것보다 더 빠른 웹앱 배포 경험임
• 연속 통합(CI)과 쉬운 배포의 결합은 Rails 8의 장점 중 특히 두드러지는 부분임
• 입문 가이드만 따라가도 최신 베스트 프랙티스에 맞춘 개발 경험을 가능하게 해줌

결론

• Rails는 여전히 강력하며 진화하는 프레임워크임
• 올해 새로운 프로젝트를 고민한다면 Rails 8로 개발에 도전해볼 만한 가치가 있음

[aer0700]

요즘 sqlite 글이 많이 보이더니, 이젠 sqlite가 전부 다, 까지 왔네요
고전의 재유행이라고 해야할까요

[GN⁺]

Hacker News 의견

• 요즘 Spring Boot, Micronaut 스택으로 앱을 만들면서 React 프론트엔드까지 써보고 있음. Rails의 omakase(모든 기본 제공) 방식이 정말 고마워짐. 백엔드에서 오는 폼 유효성 검사나 flash 메시지 같은 단순한 기능조차 프레임워크가 직접 해결해주지 않아서 직접 구현하거나 써드파티를 찾아야 함. Rails는 웹앱의 90%가 겪는 문제를 미리 해결해줌. 완벽하다고 할 수 없겠지만, 대부분의 경우 기본 제공만으로 충분하고 필요하면 언제든 대체할 수 있음
  • Spring Boot는 폼 유효성 검증이 거의 기본으로 제공되며, 어노테이션 사용으로 바로 가능함
• Rails와 Django 둘 다 멋진 프레임워크라고 생각함. Python으로 미션 크리티컬한 앱들도 짰음. 하지만 대형 monolith 개발엔 Go로 넘어가고 싶은 욕심이 있음. Go의 타입 시스템과 동시성이 더 강력하다고 느끼기 때문임. 문제는 Go 진영이 Rails나 Django 같은 프레임워크 생태계를 만들어주지 못함. Go로 네트워킹 도구나 CLI 짤 땐 최고이지만, 빠르게 풀스택 웹앱 만들 땐 아직도 Rails나 Django를 선택함. 그래서 “Rails가 끝났다”는 소리는 실감하지 못하겠음
  • ogen 같은 툴 덕분에 OpenAPI 문서 하나로 정적 라우터, 요청/응답 검증, Prometheus 모니터링, OpenTelemetry 트레이싱 등 거의 대부분의 기능을 자동 생성할 수 있음. 클라이언트와 웹훅 코드 생성도 되고, 인증은 기능 하나만 추가하면 됨. sqlc와 SQLite의 pragma user_version까지 조합하면 타입세이프 DB코드와 마이그레이션도 쉬워짐. SQLite 추가도 그냥 main.go에 import 두 줄이면 끝남. Go 표준 템플릿만으로도 프론트엔드 텍스트처리 충분하고, embed로 정적 에셋도 바이너리에 쉽게 포함시킴. 직접 배포도 go build하고 바이너리 이동만 하면 끝이라 배포가 매우 간단해짐. 코드 생성 툴들 덕분에, Go 백엔드 개발이 아주 빠르고 간편해졌음
  • 나도 정적 타입 완비 스택을 원했는데, Go나 Rust보다는 명확하게 ASP.NET이 정답이었음. Microsoft 쪽에서 새로운 제품 (예: Aspire.NET) 홍보가 많지만, 오히려 .NET Core (C#, ASP.NET Minimal API/MVC, EF Core)가 진짜 배터리 내장이고 신뢰성도 높음. 약간 OOP와 DI 마인드적 전환이 있지만, 경험 많은 개발자에겐 큰 문제가 아님
  • Go 생태계의 문제는 반(反) 프레임워크 마인드뿐 아니라 반(反) 현대적 기능 마인드도 있음. Java, Kotlin, Scala, C#, F#, 등도 네트워크 툴이나 CLI 개발엔 좋음. 요즘은 Java AOT 역시 상업 라이선스 걱정 없고 .NET도 Windows에 묶여 있지 않음
  • Encore를 추천하고 싶음. 특히, PaaS 연동할 땐 (NextJS+Vercel 조합처럼) 아주 강력함. Go의 핵심 원칙과는 조금 다르겠지만, 소규모 팀이나 1인팀에겐 굉장히 좋은 선택임. 필요하면 BYOC로 직접 배포하거나 stdlib로 직접 API layer 떠도 환장 문제없음. 프론트엔드는 NextJS나 Remix/RR7이 필요하지만, TypeScript 클라이언트 SDK 자동 생성 덕분에 통합이 아주 쉬움. Encore는 Vercel PR 연동도 있어서 그 부분도 큰 강점임
  • Go에서 Django 같은 경험을 줄 수 있는 건 beego가 그나마 괜찮은 편임. 하지만 아직 성숙도가 부족해서 Django나 Rails급이라 하긴 이른 느낌임
  • 지금 Go로 하는 프로젝트가 있는데, 정말 깔끔한 코드에 만족감을 느낌. AI가 프레임워크 진입 장벽을 넘는 데 큰 도움 됨. 그래도 고객대상 서비스엔 rails, 내부 툴/데이터 작업엔 django가 더 직관적이라는 생각임
  • Ruby도 Sorbet를 쓰면 타입 체크가 가능하고, Fiber로 지원되는 concurrency 기능이 거의 완성 단계임. Falcon이란 새로운 웹서버가 Fiber로 구축되고 있음. 아직 Puma만큼은 아니지만, 곧 본격적인 사용이 가능해질 것임
  • Stanza 언어의 저자가 강력한 프레임워크(Rails 같은)를 위해선 언어 자체에 조건이 필요하다는 통찰이 담긴 글을 썼음. Go나 Java에 그만한 프레임워크가 없는 건 언어의 한계(혹은 프로그래머의 한계)가 복합적으로 작동한 결과임
  • Go는 애초에 그런(rails/django 같은) 풀스택 프레임워크 지향이 아니었음
  • Node/Express는 로컬 개발자용 피코서비스 수준에 적합하고, ASP.NET WebAPI/MVC가 내게는 이상적인 백엔드임
  • goravel dev도 한 번 사용해볼 만함
• Rails Guides를 처음부터 끝까지 따라하면 인증, 캐싱, 리치 텍스트, CI, DB까지 포함된 진짜 서비스를 바로 출시할 수 있음. 하지만 GitHub, Airbnb 같은 거대 서비스엔 적합해도, 초기 스타트업에선 Devise 인증, turbo, 테스트 등 추가/내장 기능들을 처음부터 전부 넣는 것은 오히려 시간낭비일 수 있음. turbo는 페이지 로드 빨라진다는 장점이 있지만, devise 기능과 충돌해서 되려 개발 시간이 늘기도 함. 공개 전 초기 아이디어 검증 단계라면, 뱅킹/의료앱이 아닌 한 테스트나 CI 등은 유보해도 큰 문제 없음. 디폴트 편향(있는 기능이라서 쓴다)에 속지 말고 필요없는 건 “지금은 안 쓸래”라고 자신 있게 거절하는 게 중요함
  • SaaS 앱을 구상한다면 Jumpstart Pro나 Bullet Train 같은 Rails 전문 템플릿으로 시작하는 게 몇 달치 개발 시간을 줄여줌. 원래 결제, 인증 등 기본 기능이 포함되어 있고, 이후 확장도 쉬움
  • 테스트에 대한 입장은 동의하지 않음. 어지간히 작은 앱도 테스트 코드가 있으면 오히려 시간이 절약됨. CI도 보통 스무 줄짜리 파일 하나면 끝나, 예전 프로젝트에서 복붙해서 씀
  • CI는 개발 속도를 단축시키는 요소임. 프로젝트 초기에 반드시 추가해두는 게 좋음
  • Flask/Express/Sinatra/Gradio/Hono 등에서 Rails로 전환하는 포인트가 언제인지 궁금함
• 최신 Rails가 예전보다 정말 블링블링해보여서 기쁨. Rails 2.3 때부터 12년 간 다양한 앱을 유지보수했는데, 지금 rails는 예전과 전혀 다른 진화형 포켓몬 느낌임. 어도 Rails Upgrade Guide가 워낙 잘 정리되어 있어서, 큰 리팩터링 없이 한 번에 잘 따라가며 업그레이드할 수 있었음. Backwards compatible하지는 않지만, 변화가 명확히 문서화된다는 게 큰 장점임. ActiveStorage 덕분에 파일첨부도 많은 발전이 있었고, Webpacker로 전환만 약간 고생했지만, Import Maps 기능 덕에 이제는 더 쉬워진 듯. 올해 8.1로 업그레이드할 계획임
  • 4년 전 예산 적은 고객을 위해 pay-cut까지 감수하며 오래된 Rails 앱 유지보수 택했음(Ruby 2.3 시절). 결과적으로 업그레이드나 기능 추가가 정말 쉬워서 크게 만족하고 있음
• 오픈소스 Rails 프로젝트를 혼자 개발해서 월 12만 명을 지원하고 있는데, 위 글의 주장에 크게 공감함. 한 가지 더 말하자면, ActiveStorage의 첨부파일 기능이 정말 훌륭함. 배포는 주로 Dokku를 썼지만, Kamal 써보는 게 기대됨. Rails는 계속 진화중이고, Ruby도 점점 더 빨라지고 있음
  • Dokku를 좋아한다면 Cloud Native Buildpacks 써봤는지 궁금함. 이걸로 바로 OCI 이미지 생성도 가능함
• Ruby를 배우기엔 웹 개발 비중이 크지 않아서, 주로 알고 있던건 Django가 전부임. 두 프레임워크를 비교해서 어떤 차이점이 있는지 궁금함
  • 두 생태계 모두 오랜 경험이 있음(최근엔 rails는 덜 했지만). Django는 python, rails는 ruby/gem에 엮여있어 ecosystem 영향이 중요함. Django admin CMS는 rails에 비해 확실히 강력하고, 많은 조직이 내부 CMS도 전부 django로 짬. rails는 엄청난 scaffolding CLI가 있어서 CRUD 기능 만들 땐 정말 빠름. Rails가 Django보다 더 추상화 수준이 높고, 구조나 아키텍처가 rails에서 거의 정해주기 때문에, Django에선 직접 고르는 게 훨씬 많음. DRY와 코드 중복 방지에 rails가 더 집착함. pythonic한 직관성을 중시하는 쪽은 rails의 magic을 부담스럽게 보기도 하고, rails 쪽은 python의 반복을 거칠게 느낄 수도 있음. 본질적으로 둘은 스타일이 다름
  • 내가 웹 앱(consumer facing product) 만든다면 rails를 먼저 집어들겠음. scaffolding과 시장 출하까지가 더 쉽다고 느껴짐(실제 대규모 서비스 경험은 없음). 내부 툴, 데이터 업무, 지리정보계라면 python/django가 더 나음
  • 가장 큰 차이는 python vs ruby임. python 생태계가 워낙 크고, Django에는 인증 및 내장 admin 기능 있음
  • 테스트 환경에서 rails 경험이 더 좋다고 생각함. rails는 CI 설정과 테스트 코드 자동 생성이 같이 제공됨
  • Django Admin은 경험적으로 ruby 쪽 대체제보다 누월씬 유연하고 사용하기 쉽다고 생각함. 반면 테스트와 라우팅은 Rails가 더 낫고 관례도 강함. 나는 ActiveRecord+arel이 Django ORM보다 더 마음에 듦. (개인적으론 ruby 코드 작성이 python보다 더 즐겁다고 느낌)
  • Ruby는 배우는 게 별로 어렵지 않고, rails는 Django보다 훨씬 더 많은 구조와 관례를 미리 제공함
• 많은 사람이 Rails에 대해 거의 연애감정 비슷한 애착을 가지는데, 나는 그 정도까진 못 느껴서 부러울 때가 있음. 어떤 언어나 프레임워크도 팬층이 있지만, Rails 쪽의 열기는 좀 더 특별함
  • Rails의 관례에 불편함을 느끼는 점도 많지만, JavaScript 백엔드에서 비슷한 생산성을 내려 해보면 거의 불가능하다고 느낌. 한편 거꾸로 rails 코드를 맡게 되면, 괜한 이유로 rails의 기본 기능(예: Active Job)을 재구현해놓은 케이스도 많이 봄. 관례를 따르는 게 언제나 더 효율적임
• SQLite를 production에 써보니 마이그레이션 문제로 결국 고생하게 되더라. 예를 들어, 기존 컬럼에 NOT NULL 제약 추가하려면 임시 테이블로 전체 테이블을 재작성해야 함
  • SQLite는 ADD CONSTRAINT 등도 없고, PL 언어나 간단한 stored proc도 지원되지 않아서 결국 계속 호스트 언어로 라운드트립 해줘야 하고, statically typed 언어에서 특히 번거로움
  • Postgres가 최고라고 생각해서 쉽게 놓지 못할 듯. 그래도 rails에서 sqlite3가 퍼스트 클래스 선택지로 들어간 건 긍정적 발전임
  • rails의 기본 권장사항은 sqlite가 redis 대체라는 의견도 있지만, 실제로는 작은 서비스 시작용일 뿐임. 후에 다른 DB로 이전할 거라면 sqlite로 시작하는 걸 권장하지 않음. 마이그레이션이 항상 고통스럽기 때문임
  • Rails에서는 ActiveRecord validation으로 대부분 관리 가능하지만, 근본적 제약 조건 반영엔 한계가 있음
• 루비 설치 가이드가 좀 복잡한 편임. 15년만에 jekyll 블로그 구성해보면서 gem 사용 등에서 고생 좀 했음. 내 잘못도 있긴 하지만, 조금 더 쉽게 다뤄지면 좋겠다고 느낌. 그럼에도 Ruby를 다시 해보고 싶어지는 계기가 됨
  • 셋업은 누구에게나 쉬워야 한다고 생각함. Jekyll은 빠르게 익혔는데, 이미 내 환경에 Ruby와 RubyGems가 있어서 그런 거였음
• sqlite만 쓸 거라면 litestack도 한 번 참고할 만함. 직접 써본 적은 없지만, 개인 프로젝트를 postgres에서 litestack으로 전환할 계획임. 벤치마크 성능이 굉장히 인상적임
  • Rails 8에서 sqlite가 크게 강화되었는데, 굳이 litestack이 필요한지 궁금함. 어떤 차별점이 있는지 알고 싶음