# Rails for Everything - 모든 것을 위한 Rails의 강력함 > Clean Markdown view of GeekNews topic #18552. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=18552](https://news.hada.io/topic?id=18552) - GeekNews Markdown: [https://news.hada.io/topic/18552.md](https://news.hada.io/topic/18552.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-01-03T09:58:15+09:00 - Updated: 2025-01-03T09:58:15+09:00 - Original source: [literallythevoid.com](https://literallythevoid.com/blog/rails_for_everything.html) - Points: 7 - Comments: 2 ## Summary Rails 8은 단일 개발자가 작업하는 작은 프로젝트에 매우 적합하며, 최신 가이드를 통해 쉽게 애플리케이션을 구축하고 배포할 수 있습니다. SQLite의 프로덕션 적합성 향상과 기본 CI 구성 제공으로 개발자에게 편리함을 제공합니다. 또한, 새로운 인증 생성기와 Kamal을 통한 쉬운 배포 기능은 Rails 8의 강력한 장점으로, 모범 사례를 쉽게 따를 수 있게 합니다. ## Topic Body - **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로 개발**에 도전해볼 만한 가치가 있음 ## Comments ### Comment 33038 - Author: aer0700 - Created: 2025-01-06T12:30:52+09:00 - Points: 1 요즘 sqlite 글이 많이 보이더니, 이젠 sqlite가 전부 다, 까지 왔네요 고전의 재유행이라고 해야할까요 ### Comment 32913 - Author: neo - Created: 2025-01-03T09:58:15+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=42569236) * 요즘 **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이 필요한지 궁금함. 어떤 **차별점**이 있는지 알고 싶음