당신은 Rails를 잘 못 쓰고 있어요

• Rails 8과 Vite 통합을 둘러싼 두 개발자의 대화를 통해, 불필요하게 복잡해진 현대 웹 개발 환경을 풍자함
• 한명은 Vite, React, Babel, Tailwind, Docker, Husky 등 수많은 도구를 추가하며 ‘모던’ 스택이라 주장
• 반면 다른 사람은 아무 설정 없이 기본 Rails만으로 즉시 실행되는 앱을 보여주며 단순함의 효용을 드러냄
• 복잡한 툴 체인에 의존하는 현 상황을 비꼬며, ‘그냥 Rails를 써라’ 는 메시지를 강조하며 단순함의 미덕을 되돌아보게 함
• Rails의 본래 목적이었던 생산성과 일관성, 개발의 즐거움이 잊혀지고 있음을 지적

“Just F#$%^& use Rails”

---

원문 대화 번역

Kevin: 야, Rails 8용 Vite 써봤어? 엄청 빨라.

John: 들어는 봤어. 빌드 도구잖아? Rails에 이미 그런 거 있었던 거 아니야?

Kevin: 있었지. 근데 Vite는 좀 더 현대적이야. Node랑 npm 설치하고 몇 개 스크립트 설정해야 하지만, 그럴 가치가 있어.

John: 잠깐, Rails가 이제 Node가 필요해?

Kevin: 응, React 쓰려면 그렇지. 요즘 다 React 쓰잖아.

John: Rails에 그런 거 있지 않았나?

Kevin: 있었는데, 이제는 React Refresh랑 같이 Vite 써야 해. 그러면 컴포넌트가 즉시 새로고침돼. TypeScript 쓰려면 그 설정도 해줘야 하고.

John: 듣기만 해도 복잡하네.

Kevin: 아니야, 별거 아냐. Babel 설치하고 .babelrc 설정하고, vite-plugin-ruby 추가하고, 스타일은 PostCSS 써야지.

John: PostCSS?

Kevin: 그래. 그리고 당연히 Tailwind도 써야지 — 농담 아니고 CSS 한땀한땀 직접 쓰고 싶지는 않을거 아냐.

John: 당연하지.

Kevin: 그다음엔 ESLint랑 Prettier로 코드 정리하고, 커밋 전에 Husky로 훅도 걸면 완벽해.

John: 그럼 Vite, React, Babel, PostCSS, Tailwind, ESLint, Prettier, Husky. 그게 다야?

Kevin: 거의 다야. 서버 사이드 렌더링까지 하려면 Next.js나 Remix 써야지.

John: 잠깐, 우리 아직 Rails 얘기하는 거 맞지?

Kevin: 맞아. 요즘은 하이브리드 스택이 대세잖아! JS 프레임워크 없이 반응형 컴포넌트 쓰고 싶으면 StimulusReflex나 Hotwire도 괜찮아.

John: StimulusReflex? 마블 캐릭터 이름 같은데.

Kevin: 하하, 진짜야. 실시간 업데이트용이야. 근데 ActionCable 설정해야 하고, Redis도 필요해.

John: Redis?

Kevin: 그래, pub/sub 레이어가 필요하거든. 걱정 마, Docker 컨테이너 하나 더 띄우면 돼.

John: Docker도 써야 해?

Kevin: 그럼. 의존성 분리하려면 필수지. 완전한 환경 재현하려면 Docker Compose랑 Fly.io 배포, GitHub Actions로 파이프라인도 돌려야지.

John: 그거... 꽤 복잡한데.

Kevin: 그냥 현대적인 웹 개발이야, 친구. 단순하지. 너는 뭐 해?

John: 그냥 만져 보고 있어.

(John이 명령어 하나를 실행한다. 앱이 즉시 부팅된다. 폼도 동작하고, 로딩도 빠르고, 탐색도 번개처럼 빠르다.)

Kevin: 와, 꽤 복잡해 보이는데. 스택 뭐 써?

John: 그냥(Vanilla) Rails.

Just F#$%^& use Rails.

[labeldock]

저는 모두다 사랑하는 도구입니다. 두 도구는 생태계와 목적이 교차 되는 부분이 있는 것이지 완전히 같은 도구가 아니라 난이도를 기준으로 평가가 되면 안됩니다. vite로 작성하면 스크립트를 광범위하고 정교하게 짤 수 있고. Stimulus나 Hotwire는 스크립트 개발을 최소화 하는데 더 적합하죠.

[roxie]

대부분의 내용이 프론트엔드 개발에 포커싱되어있는 것 같은데...

[GN⁺]

Hacker News 의견

• 이 글은 10년 넘게 다시 쓰여왔음
  소위 “복잡성”이라는 것은 각각 특정 문제를 해결하는 도구들의 목록일 뿐임
  도구 자체가 문제가 아님, 현대 웹 개발에 본질적인 복잡함이 있다는 점이 현실임
  ASP.NET이나 데스크톱 GUI 프레임워크 등에서도 비슷한 “숨겨진” 복잡성을 볼 수 있음
  예를 들어, Rails를 API 백엔드로 사용하고 프런트엔드는 React가 담당한다면 전통적인 Rails 모놀리식과는 완전히 다른 아키텍처가 됨
  Vite, React, Prettier 같은 도구 리스트는 완전히 다른 문제를 겨냥한 선택지임 (프런트엔드로 Rails를 쓰고 싶으면 그냥 Rails를 쓰면 됨, 중간 형태는 별로 좋아하지 않음)
  진짜 문제는 학습 방법임
  요즘 개발자들은 웹의 기본(HTML, CSS, 서버사이드 로직, 데이터베이스)을 익히기 전에 프레임워크부터 배우는 경우가 많음
  각 도구들은 나름의 이유로 존재함, 그리고 모두 현대 웹에 필요한 도구임
  “너무 많다”는 식으로 바라보는 건 업계 현실을 제대로 본 것이 아님

  • 복잡성은 웹 개발에 본질적인 게 아님
    오히려 지금은 더 적은 것으로 더 많은 일을 할 수 있게 됨
    Hotwire는 거의 바닐라 Rails처럼 작동하고, 웹소켓을 통해 실시간으로 콘텐츠가 업데이트되는 모던한 경험을 단 한 줄로 구성할 수 있음
    Rails에서 JS를 배포하는 일반적인 방법도 import maps 덕분에 매우 간단해졌음(별도의 빌드 단계 필요 없음)
    Tailwind도 매우 쉽게 추가 가능함
    배포조차 kamal로 훨씬 쉬워짐
    그러니 복잡함이 본질이라는 말은 동의하지 않음, 그리고 Hotwire는 복잡성을 낮추는 역할임
    학습은 “더 많이 배우는 것”이 아니라 “더 적은 것으로 더 많이 하는 것”을 배우는 방향이어야 함
    20가지 언어나 서버를 쓸 줄 아는 것보다 4가지로 3명의 팀으로 천 명을 앞서는 게 진짜 기술력임

  • 사람들이 도구의 존재 자체에 반대하는 게 아니라, 모두 다 그걸 반드시 써야 한다는 분위기에 반감을 느끼는 것 같음
    모든 튜토리얼, YouTube 영상 제목이 “꼭 써야 하는 MONGOOSE 스택!”처럼 나오니, 베이킹 블로그에 redis를 억지로 넣으려는 초보도 많아짐
    사실 대부분의 사이트는 특별한 스택 없이도 충분함
    하지만 그런 건 누구도 광고하지 않으니, 실제로 많은 주니어 개발자들은 이 사실을 모르고 있음
    기본 기술 학습을 우선시해야 한다는 데엔 동의하지만, 기업들이 각종 서비스를 홍보하는 틈에서 그 메시지를 전달하는 게 쉽지 않음

  • 나는 Rails는 꽤 초보지만 다른 언어 경험이 10년 정도 있음
    필요하다면 도구를 추가하는 건 괜찮음(실제로 필요한지는 논외)
    하지만, Rails는 본래 ORM에서 콘솔, 스캐폴딩 코드 생성까지 모두 포함된 거대한 만능 프레임워크임
    추가 도구가 필요하다면, 오히려 Rails 자체를 다시 고려해봐야 하는 것 아님?
    더 모듈형인 게 오히려 나을 수 있음
    “바닐라 Rails”라는 말이 경고 신호처럼 보임. 저렇게 덩치 큰 프레임워크를 어떻게 바닐라라고 부를 수 있는지 의문임

  • 이 글의 요지는, 처음부터 “모던 웹 애플리케이션”이 필요한지 스스로 고민하지 않고 그냥 바닐라 Rails로도 충분함을 모르는 경우가 많다는 것임
    바닐라 Rails의 기본 선택지를 스스로 이해하려는 노력이 부족함

  • “현대 웹 개발의 복잡성”을 언급하는 것은 단지 문제 상황을 묘사하는 것일 뿐이고, 필수 조건이 아님
    단순히 데이터베이스와 몇 개의 SQL 쿼리로 구성된 사이트에 npm 패키지 수천 개를 끌어다 쓴다면 뭔가 잘못하고 있는 것임

• 2007년부터 Rails 코드를 써왔음
  스택이 복잡해진 데는 그만한 이유가 있고, 본문의 기준대로 “제대로 한” 팀은 사실상 없음
  Omakase 프레임워크(Rails처럼 대부분을 정해주는 방식)의 문제점은 초기 선택뿐 아니라 이후의 선택도 계속 따라가야 하고, 팀 전체를 끌고 같이 가야 한다는 점임
  Rails는 강력하지만, 유지보수자들도 완벽하게 미래를 내다볼 순 없음
  그래서 지금 바닐라 Rails로 돌아간 앱은 거의 없음
  예전엔 Docker 이전에 Rails 배포가 정말 번거로웠음. rsync나 tarball 대신 Capistrano 같은 배포 시스템이 필요했음.
  Docker나 k8s도 편하지만, 옛날에 비하면 딱히 더 나쁜 건 아님

  • pre-Docker 시대 Rails 배포를 “rsync해서 tarball 풀기”로 기억한다면, 정말 엉망인 셋업이었음
    “옛날” Capistrano로 배포하는 게 훨씬 나았음

  • “rsync나 tarball로 여러 인스턴스에 푸는 것”이 구체적으로 뭐가 문제였는지 더 설명해줬으면 좋겠음
    듣기엔 그렇게까지 심각한 것도 아닌 것 같음

  • 그래서 나는 항상 Sinatra에 애착이 있음

• Rails가 제공하는 out-of-the-box 유틸리티를 JS 세계에서는 여전히 대체할 수 없다는 점이 아쉬움
  대부분의 JS 개발자들은 이 점을 잘 모름
  하지만 JS는 늘 바퀴를 새로 만드는 생태계임

  • JS는 모든 사람이 새로운 플랫폼을 만들 기회가 있다는 점이 큰 장점임
    여러 JS 플랫폼을 동시에 조합해도 그럭저럭 다 돌아가는 건 매우 확장 가능하고 해킹 가능하며, 전부 로컬에서 영구적으로 빌드해서 고정된 사이트를 만드는 것도 가능함
    하지만, 이런 자유에는 절제가 필요함
    언제든 새 프레임워크를 들여오고 싶은 동료를 막는 것은 팀의 몫이 됨

  • Ember.js는 Rails 진영의 큰 이름들이 만든 올인원 프레임워크(“배터리 내장”)임
    그렇지만 다른 프레임워크만큼 성공하지 못한 데에는 왜인지 이유가 있음

  • JS 생태계에도 AdonisJS처럼 모든 게 포함된 백엔드 프레임워크가 존재함
    다만 NodeJS 생태계는 Rails나 Django 같은 틀에 박힌 프레임워크의 반동으로 마이크로프레임워크에서 출발했음
    Express의 컨셉도 “빠르고 대충” 만들어서 쓴다는 것이었음

  • JS에도 Rails와 비슷한 풀스택 프레임워크가 여러 개 있음
    Sails라는 프레임워크도 있음
    JS는 Rails가 해결하는 문제와는 다른 문제를 풀고 있어서 프레임워크 생김새가 다를 수밖에 없음

  • Rails는 유틸리티가 많긴 한데, 장기적으로는 주기적으로 코드베이스도 업데이트해야 하고 Rails의 트렌드를 계속 따라가야 한다는 점이 피곤할 수 있음

• Stimulus와 Hotwire가 이제 “rails way(정석)”로 자리잡았음
  문서를 열심히 읽어봐도 여전히 너무 헷갈림
  왠지 계속 직접 JS 컴포넌트를 반복해서 새로 만드는 느낌임
  내 생각엔 Rails 8 + Inertia.js + React 조합이 오히려 “바퀴를 재발명”을 덜하게 만들어줌. 특히 shadcn 컴포넌트를 쓰면 더더욱

  • 이런 점에 동감함
    우리도 Hotwire 프론트엔드를 Inertia로 교체했는데, 진짜 천지차이임
    정말로 100% 혼자서 작은 프로젝트를 하지 않는 이상, Hotwire는 금방 팀 전원이 손댈 수 없는 난장판이 됨

  • 저는 오히려 Stimulus가 너무 마음에 들어서 Rails에서 Phoenix 앱으로 바로 옮겨 썼음
    근데 문제는 이 도구에 대한 오해라고 봄
    Stimulus는 React 대안이 아님
    수만 줄짜리 JS 앱에 익숙하다면 React가 맞을 수 있음
    하지만 서버사이드가 주인 앱에서 몇십 줄 JS로 UX를 다듬고 싶을 때 Stimulus가 딱임
    Phoenix에서는 정적 HTML과 동적 LiveViews 사이에 딱 맞게 끼어들 수 있는 미니멀한 솔루션임
    Stimulus로 SPA를 만들라고 한 사람은 아무도 없고, 그러면 분명 힘든 상황이 벌어질 거라고 생각함

  • Stimulus는 정말 작고, HTML hook이 있는 이벤트 시스템이라 Rails의 request lifecycle과 잘 어울림
    누가 Stimulus로 뭔가 대단히 복잡한 걸 성공적으로 만든 경험이 있는지 궁금함
    내 느낌에는 그렇게까지 하긴 너무 어렵더라고 느꼈음

  • 나도 Rails 팬보이라 할 만한데, Stimulus와 Hotwire의 현 상황이 아쉬움
    개념은 훌륭하고, 구현도 아마 좋을지도 모르겠음
    그런데 문서가 너무 끔찍하게 부족해서 시작부터 엄두가 안 나고, 프로젝트마다 “이걸로 시작하면 나중에 막다른 골목에 갇히는 건 아닐까” 답을 찾을 만한 정보가 없음

  • Stimulus는 Symfony와 같이 써서 작은 상호작용에 사용해봤는데, 작고 잘 설계된 API라 꽤 괜찮았음
    Turbo/Hotwire 전체는 아직 안 써봤고, 복잡하거나 상태가 필요한 페이지엔 보통 Vue를 씀

• 어차피 지금은 그린필드 프로젝트(처음부터 새로 구축하는 프로젝트)가 거의 사라졌다시피 함
  창업자 말고는 그린필드 자체가 드물고, 뭔가를 판다면 거의 99%가 Shopify 래퍼나 비슷한 걸로 처리함
  대기업에서도 그린필드는 각종 고려사항과 사내 프레임워크에 묶여있어서 “rails new”부터 시작하는 경우는 없음
  이런 논의는 별 의미가 없고, 비슷한 논쟁과 글이 지난 10년, 15~20년간 계속 반복되는 거라 지겹고 지루함
  새로운 글 말고, 새로운 걸 실제로 만들어줬으면 좋겠음

  • 완전 동감임
    Ruby/Rails로 10년간 일했고, 그나마 “최신” 코드베이스도 이미 5년 넘은 게 다였음
    솔직히 새 그린필드 Rails 앱을 만든 적 있긴 했지만 그것도 API 전용 마이크로서비스라 프론트엔드는 필요없었음
    규모 있는 회사에서는 Rails 프론트엔드 솔루션이 아예 무시됨
    Hotwire 쓸 줄 아는 엔지니어는 못 구해도 React나 Vue 개발자는 얼마든지 구할 수 있음
    Rails의 FE 스택도 자주 바뀌어서 따라가기 힘들고(예: CoffeeScript 시절 기억함), 제대로 된 문서도 거의 없고, 현실적으로 영향력도 없음
    그래서 이런 논의 자체가 실제 현실과는 동떨어져 있음

  • “그린필드 프로젝트는 창업자 말고는 남아 있지 않다”는 주장에 동의할 수 없음
    오래된 대기업 모놀리식이나 Fortune 500만 예로 들면 전체 평균에서 벗어난 극소수임
    오히려 “rails new”가 sane하고 바로 쓸 수 있게 default를 구성하는 정성이 대단하다고 생각함
    이런 접근은 Hello World와 너무 간단한 API 문서의 중간을 잘 메꿔줌
    Rails를 꼭 쓰지 않는다 해도, 이런 부분은 본받을 만함

• 귀엽긴 해도 한 Rails 앱이 발전하면서 bundler, webpacker, sprockets, Propshaft, importmaps, jsbundling 등으로 계속 이동해야 하는 현실을 말하지는 않음
  autoloader에서 zeitwerk, Turbo에서 Hotwire 등, 실제로는 이렇게 바뀐 부분이 정말 많음
  심지어 Rails 뉴스레터 광고만 봐도 “전문가들이 Rails 앱 업그레이드 돕는다”는 게 많음

  • 이런 점을 언급해줘서 다행임
    “그냥 바닐라 Rails 쓰자”라는 말 쉽지만, Rails의 지난 5년 동안 버전마다 JS 관리 방식이 완전히 달라졌음
    여전히 sprockets 의존하는 gem도 많아서 Rails 방식대로 해도 어쩔 수 없이 복잡한 JS 덩어리가 됨
    지금 진짜 혼란스러운 상태임. 언젠가는 나아질지도 모르지만, Rails의 책임도 분명히 큼

  • CoffeeScript도 빼먹지 말아야 함
    최근까지도 내가 일한 회사는 여전히 CoffeeScript 포팅을 미루는 중이었고, 새로운 코드는 Vue로 쓰고 있었음

• 30명 이상의 개발자가 다양한 전문분야로 동시에 참여하지 않는 프로젝트라면 굳이 프런트/백엔드 분리를 가져오는 복잡성은 필요 없었음을 직접 경험에서 배웠음
  프리랜서 시절에 1~2명 팀 규모에도 쓸데없이 과하게 설계해봤는데, 결국 요즘은 Django에 Tailwind만 약간 얹어서 씀

  • 올해 Django 개발자 채용을 했는데, 거의 모든 지원자가 얇은 API 백엔드를 Django로 만들고, 프런트엔드는 React로 크게 구성함(심지어 비즈니스 로직도 프런트에 몰아넣은 경우가 많음)
    이유를 물어봐도 거의 다 설명을 못함
    결국 서버사이드 렌더링만 쓴 몇 안 되는 지원자만 남기게 됨

  • 만약 정말 상호작용이 많은 프론트엔드가 필요하다면 어떻게 할지 고민해야 할 수도 있음

  • 나도 동의함
    대부분 업계에서는 초고도 확장성과 마이크로서비스가 필요한지, 그냥 모놀리식이랑 PostgreSQL로 충분한지에 대해 고객 입장에서 별 신경 안 씀

• 최신 기술만 쫓으면서 무한 확장을 목표로 세팅하는 사람이 많은 것 같음
  사실 Rails는 단순한 설계로도 매우 유용하고, “지루하다”, “재미없다”는 이유로 과설계를 하는 경우가 많음
  하지만 Rails는 정말 배터리 내장형이고, 오버엔지니어링 그만두면 그냥 잘 돌아감

  • 오랜만에 Rails로 복귀해서 10년 이상 된 프로젝트를 Rails 5에서 8로 올려야 해서 처음엔 힘들었지만, 그 뒤 새로 만드는 SaaS/CRUD 프로젝트는 Rails만 씀
    어느 순간 생산성이 제일 중요한 가치로 느껴지게 됨

• 지금이 더 복잡해졌을 뿐, 이런 개념 자체는 새로울 게 없음
  15년 전 Django 배울 때도 튜토리얼이 특정 버전의 Vagrant, VirtualBox, Chef 설치를 요구해서 거의 미치는 줄 알았음
  지금도 Django를 계속 좋아하고 쓰고 있지만, 그런 도구들은 굳이 신경 안 씀
  Django Rest Framework도 오히려 집중을 흐트러뜨리는 존재였음

• “웹 개발 툴링 피로도”는 매우 현실임

  • 10년 전에도 현실이었고, 이런 혼란은 보통 개발자들이 취미생활 취향을 직장에 끌어온 결과임
    덧붙이자면, 프론트엔드만 그런 건 아니고 DevOps 쪽도 상황이 비슷함

  • 그 결과, 관련 분야에 지원하려면 모든 도구를 다 알아야 하고 거기에 10년 경험, 다양한 백엔드와 SQL, Docker까지 다 요구하는 분위기가 됨

  • 전문적으로 한다면 한 번 셋업하고 끝이지만, 일회성 프로젝트나 웹 개발이 주 업무가 아니라면 분명 피곤한 게 맞음
    하지만 이런 식으로 피할 수도 있음
    나는 Fresh(https://fresh.deno.dev/)라는 프레임워크로 웹사이트를 만들었는데, 딱 이것만 있으면 충분했음
    일반적으로 Node/Webpack 조합보다 훨씬 단순했고, Typescript랑 TSX까지 사용할 수 있었음
    여러 명이 작업했다면 ESLint 같은 건 추가했을지 모르지만, 굳이 없어도 아주 쉽게 시작할 수 있었음