▲

2026년에 다시 Rails로 돌아오다

 (markround.com)
1P by GN⁺ 8시간전 | ★ favorite | 댓글 2개
  • 밴드의 세트리스트 관리 앱(setlist.rocks) 을 만들며 오랜만에 Ruby on Rails 개발의 즐거움을 재발견함
  • 최신 Rails 8은 전통적인 MVC 구조를 유지하면서도 Hotwire(Stimulus·Turbo) 기반의 “no-build” 프런트엔드, Solid Cache/Queue/Cable 등으로 현대화됨
  • SQLite가 기본 설정만으로도 실서비스에 적합할 만큼 최적화되었고, Kamal 배포 도구로 컨테이너 기반 무중단 배포가 간단해짐
  • Rails의 “관례보다 설정” 철학과 풍부한 gem 생태계 덕분에 아이디어에서 프로토타입까지 빠르게 구현 가능함
  • Ruby와 Rails의 인기는 예전보다 줄었지만, 여전히 성숙하고 일관된 OSS 프레임워크로서 개발의 즐거움을 제공함

사이드 프로젝트와 Rails로의 회귀

  • 밴드의 세트리스트와 곡 노트를 관리하기 위해 웹앱을 직접 개발, 기존 스프레드시트나 채팅보다 효율적인 방식 추구
  • 개발 과정에서 Rails의 단순함과 생산성을 다시 체감, 최근의 복잡한 웹 생태계에 비해 “순수한 개발의 즐거움”을 느꼈다고 언급
  • Ruby는 여전히 자연스러운 문법과 표현력으로 사고를 코드로 옮기기 쉬운 언어로 평가됨
  • Stack Overflow 2025 조사에 따르면 Ruby와 Rails의 인기는 하락했지만, 개인 프로젝트에서는 여전히 선호

Rails 8의 변화와 프런트엔드

  • Rails 8은 기존 MVC 구조를 유지하면서도 Hotwire(Stimulus·Turbo) 기반의 프런트엔드 통합 제공
    • Turbo는 링크 클릭·폼 제출을 가로채 SPA 수준의 반응성을 제공
    • Stimulus는 필요한 부분에만 JS 동작을 추가해 최소한의 자바스크립트 작성으로 인터랙티브 UI 구현 가능
  • Importmap 도입으로 Webpack, npm 없이 JS 라이브러리를 CDN에서 직접 불러올 수 있음
  • AI 도구를 활용해 UI를 생성했지만, 창작과 코드의 예술성 사이에서 고민을 드러냄

개발 워크플로와 생산성

  • Rails의 “관례보다 설정” 철학으로 모델·라우팅·컨트롤러·뷰를 빠르게 구성 가능
    • 예시로 Tag 모델 생성, RESTful 라우팅 자동화, JSON 응답 처리 과정을 시연
  • ERB 템플릿과 라이브 리로드로 빠른 프로토타이핑 가능
  • 풍부한 gem 생태계로 CSV, PDF 등 다양한 기능을 손쉽게 통합 가능

백엔드 개선: Solid* 시리즈와 SQLite

  • Solid Cache/Queue/Cable이 Rails 8에 기본 포함되어 Redis 없이 캐시·잡큐·웹소켓 처리 가능
    • Solid Cache는 DB 기반 캐싱으로 RAM 절약 및 단순화
    • Solid Queue는 DB 기반 백그라운드 작업 관리, SOLID_QUEUE_IN_PUMA=1 설정만으로 실행
    • Solid Cable은 DB 기반 Action Cable 어댑터로 실시간 기능 지원
  • SQLite는 database.yml의 pragmas: 설정으로 WAL 모드, NORMAL 동기화 등 최적화가 기본 적용
    • 별도 DB 서버 없이도 소규모 프로덕션 환경에서 실용적 사용 가능

배포 자동화와 Kamal

  • 과거 Capistrano·Ansible 기반 배포의 복잡함을 언급하며, Kamal을 Rails 8의 기본 배포 도구로 소개
    • 컨테이너 빌드→푸시→서버 배포→헬스체크→무중단 전환 과정을 자동화
    • kamal-proxy가 트래픽 전환과 SSL 처리를 담당
    • .kamal/secrets 파일로 환경 변수 기반 보안 비밀 관리 지원
  • GitLab CI와 연동해 git push만으로 배포가 가능, 과거 Heroku의 단순함을 재현

인증과 기타 기능

  • Rails 8은 내장 인증 생성기(auth generator) 를 제공해 Devise보다 단순한 인증 시스템 구축 가능
  • Devise는 여전히 풍부한 기능과 문서로 유용하지만, Rails 기본 인증의 단순함도 매력으로 평가

Rails 생태계의 현재와 지속성

  • Ruby와 Rails의 인기는 감소했으나, Shopify·Basecamp·SoundCloud·GitHub 등 주요 서비스가 여전히 사용
  • 많은 gem이 유지보수 단계에 있지만, Rails는 매년 꾸준한 릴리스 주기를 유지
  • “새로운 개발자층 유입은 줄었지만, 여전히 즐겁게 개발할 수 있는 프레임워크”로 평가

결론

  • Rails는 최신 트렌드와 거리를 두었지만, 개발의 즐거움과 단순함을 되찾게 해주는 도구로 강조
  • 인기보다는 만드는 즐거움과 창의성을 중시하며, “한 번 다시 Rails를 시도해보라”는 메시지로 마무리
▲
joyfui 3시간전  [-]

레일즈면 "관례보다 설정"이 아니라 "설정보다 관례"였던 걸로 기억하는데...

답변달기
▲
GN⁺ 8시간전  [-]
Hacker News 의견들

  • 나는 Rails를 정말 좋아하지만, 대규모 비정적 타입 코드베이스에서 일해본 뒤로는 개인 프로젝트 외에는 Rails로 돌아가기 힘들어짐
    타입이 없는 대형 코드베이스는 RubyMine 같은 강력한 IDE가 있어도 유지가 악몽 수준임
    요즘 Sorbet이 얼마나 발전했는지, 특히 RoR과의 궁합이 궁금함

    • 요즘은 Rust/Loco가 가장 흥미로운 프레임워크라고 생각함
      Rails의 철학을 잘 따르면서도 Rust 학습을 쉽게 만들어줌
    • IHP는 Haskell 기반의 Rails 영감을 받은 프레임워크로, 두 세계의 장점을 결합하려고 함
      주말에 시도해볼 만한 가치가 있음
    • 문제는 타입 부재만이 아니라, 런타임에 함수나 속성이 정의되는 구조 때문에 디버깅이 거의 불가능함
      실제 프로덕션 데이터를 로컬에 복제하거나 서버에 SSH 접속해 REPL로 상태를 살펴봐야 함
      IDE에서 디버깅하는 건 지옥 같은 경험이었음
      Ruby를 정말 사랑했지만, 실시간 디버깅을 겪은 뒤로는 힘들어짐
    • 대규모 비정적 코드베이스가 왜 그렇게 악몽 같은지 궁금함
    • 요즘은 에이전트형 코딩(agentic coding) 덕분에 언어나 프레임워크의 중요성이 점점 줄어듦
      이제는 Ruby나 Python을 굳이 선택할 이유가 없음
      Python은 ML 분야에서 잠시 더 버티겠지만, 결국 사라질 것 같음

  • 나도 이런 생각을 공개적으로 말해줘서 반가움
    요즘은 과도한 마이크로서비스 아키텍처에 지쳐 있음
    저녁에는 불필요한 구조 없이 문제를 단순히 해결하는 프로젝트를 만짐
    예전엔 PHP 구조를 많이 다뤘는데, Rails나 PHP 모두 결국 문제 해결 도구일 뿐임

    • 올해 초부터 새 프로젝트에 RoR을 사용 중인데, 정말 신선한 공기 같은 경험임
      예전 데스크톱 IDE 개발처럼 “상자 안에서” 모든 게 돌아가는 느낌임
      웹 개발의 복잡한 구성요소 관리에서 벗어나, 생산성 중심의 단순함을 되찾은 기분임
      게다가 TypeScript를 안 써도 돼서 너무 좋음. TypeScript는 장황하고 불필요한 보일러플레이트 덩어리라고 생각함
    • STOA가 무엇을 의미하는지 궁금함
    • “생각과 코드 사이의 번역이 최소화된다”는 말이 Ruby의 본질을 잘 표현한다고 느낌

  • 우리는 2007년부터 Rails 앱을 프로덕션에서 계속 운영 중임
    Rails의 장수 비결은 나이에 있는 게 아니라, 그 안정성과 실용성 때문임
    백엔드에서 JavaScript를 쓰면 효율이 높아진다는 주장은 이미 반박되었음
    대부분의 기술 스택 변화는 이력서 최적화나 트렌드 불안감 때문이지, 실제 엔지니어링 요구 때문이 아님
    Rails는 조용히 진짜 비즈니스를 계속 구동해왔음
    NPM의 310만 패키지가 RubyGems의 19만 개보다 더 많은 기능을 제공한다고 생각하는 사람은 없을 것임

    • 우리도 2011년부터 두 회사에서 Rails를 프로덕션에 사용 중임
      Inertia + Vue.js로 마이그레이션 중인데, 백엔드 변경은 거의 필요 없을 정도로 강력한 조합임
      생산성 향상 덕분에 채용 난이도도 상쇄됨
    • NPM의 패키지 수가 많다는 건 사용자 수가 많다는 뜻임
      사용자 수가 많을수록 생태계는 건강해짐
      하지만 RubyGems의 오래된 패키지들도 많으니 단순 비교는 어렵다고 생각함

  • RoR이나 Django의 “배터리 포함” 철학은 좋지만, 오래된 프로젝트 유지보수는 시간이 많이 듦
    5~6년 된 프로젝트를 업데이트하려면 의존성 관리가 큰 부담임
    그래서 요즘은 Go로 단순한 프레임워크를 쓰거나 아예 없이 개발하는 걸 선호함

    • 나는 30만 줄 이상의 Django 코드베이스를 관리 중인데, 직접 의존성은 32개뿐임
      꼭 필요한 라이브러리만 쓰면 유지가 쉬움
    • 문제는 지속적인 변경(churn) 같음
      보안 패치 외에 굳이 업데이트해야 할 이유가 뭔지 의문임
    • Laravel에서는 이런 문제를 거의 겪지 않음
      지난 1년 반 동안 5개의 메이저 버전을 올렸는데도 비교적 간단했음
    • 결국 의존성 관리 전략에 따라 유지보수 난이도가 달라짐
      초기에 신중하게 구성하면 오랫동안 손볼 일이 거의 없음
    • “배터리 포함”이 오히려 업그레이드를 어렵게 만드는지 궁금함. 나는 반대일 것 같다고 느낌

  • 업그레이드 경험이 과소평가된다고 생각함
    Next.js는 메이저 버전마다 구조가 완전히 바뀌지만, Rails는 점진적 폐기(deprecation) 주기가 느려서 훨씬 안정적임
    제품을 지속적으로 배포할 때는 최신 패러다임보다 인터페이스 안정성이 훨씬 중요함

    • Rails를 오래 운영해본 사람만이 이 점을 진정으로 이해함
      Next.js의 pages → app router 전환은 사실상 전체 리플랫폼 수준의 변화였음
      반면 Rails는 문서화된 업그레이드 경로와 예측 가능한 폐기 주기가 있음
      Ruby 버전 관리도 rbenv/asdf 덕분에 환경 불일치 문제를 거의 없앰
    • Next의 app router 전환은 구조적 대변혁이라, 이 시점에 TanStack Start 같은 덜 견해적인 대안을 고려할 만함

  • 나는 10년 넘게 Rails로 DevOps부터 1인 웹 개발자까지 해왔고, 다시 해도 같은 선택을 할 것임
    Rails는 모든 걸 갖춘 깔끔하고 생산적인 프레임워크임
    Stack Overflow 설문에서도 여전히 “다음 프로젝트에 쓰고 싶은 스택 Top 5” 안에 들었음

    • Rails의 “1인 프레임워크” 성격이 정말 매력적임
      인프라 구성까지 신경 쓸 필요가 거의 없고, 배포도 간단함
    • Rails로 실제 일하는 사람들은 굳이 설문에 참여하지 않을 수도 있음
      결국 중요한 건 남의 시선이 아니라 자신에게 맞는 도구를 쓰는 것임
    • Rails는 2004년에 출시되어 이제 20년이 넘은 프레임워크임
      Django보다 1년 먼저 나왔음
    • Stack Overflow 2025 설문에서는 Rails가 웹 프레임워크 “Admired vs Desired” 부문에서 10위를 기록함
      설문 링크

  • 예전엔 Ruby/Rails가 대부분의 문제의 최적 해법이라고 생각했는데, 지금도 여전히 그렇게 생각함

  • Rails는 안 써봤지만, 요즘의 웹 개발 환경의 혼란스러움에는 공감함
    그래서 나는 미래를 보고 Elixir와 Phoenix를 선택했음

    • 최근 며칠 사이에 Ruby로 프로젝트 한다고 하니 Elixir를 추천한 사람이 다섯 명이나 있었음
      다음 프로젝트에서는 꼭 시도해볼 생각임
      Elixir의 어떤 점이 그렇게 매력적인지, 처음 접할 때 주목할 포인트가 궁금함

  • 10년 전 스웨덴의 대형 방송사 스트리밍 프론트엔드를 Rails로 구축했음
    Heroku에서 100만 명 이상 동시 접속을 처리했는데, 정말 잘 작동했음
    이후에는 스트리밍 인프라, API, AI/ML 등 다른 분야로 옮겼지만, Rails가 실패해서가 아니라 문제의 성격이 달라졌기 때문임
    Rails는 데이터 모델과 비즈니스 로직 중심의 문제에 적합하고, 동시성이나 인프라 중심 문제에는 다른 언어가 더 맞음
    Ruby는 여전히 아름답고 표현력 있는 언어로 그리움이 큼

    • 나도 “문제에 맞는 도구를 선택한다”는 철학에 공감함
      하지만 좋아하는 언어에 대한 개인적 편향을 완전히 버리긴 어렵다고 느낌
      어떤 언어로 다음 프로젝트를 진행했는지 궁금함

  • 정적 타입 부재를 아쉬워하는 사람들에게는 Sorbet 같은 훌륭한 솔루션이 있음
    Ruby의 생산성과 정적 타입, LSP 통합을 함께 누릴 수 있음
    Shopify 덕분에 Rails에서도 Sorbet 지원이 잘 되어 있음
    나는 여전히 Rails로 일하고 싶을 정도로 이 생태계를 사랑함
    AI 도구의 발전 덕분에 이제는 상상력의 크기만이 한계라고 생각함

    • 요즘 AI 분야에서 가장 큰 화제는 OpenClaw임
      이를 기반으로 24시간 상점 모니터링 및 Slack 알림을 하는 이커머스 에이전트를 만들었음
      AI 관련 프로젝트를 한다면 selzee.com/openclaw를 꼭 확인해볼 만함
답변달기