GN⁺: Ruby on Rails가 여전히 중요한 이유 - Next.js 세상에서 오래된 도구가 살아남는 법
(contraption.co)- 최근 필자는 할아버지의 오래된 바이닐 레코드를 발견하였고, 이전 시대의 이 매체가 여전히 문제없이 재생되는 것을 보고 놀라웠음
- 바이닐은 음악 배포에 큰 변화를 가져왔으며, 인쇄와 공유를 가능하게 하여 현재까지도 표준으로 남아있음
- 오디오 공유 방법은 진화했지만, 초기 방식은 여전히 기능을 유지하고 있음
- 복잡해지는 세상 속에서 많은 사람들이 단순함, 안정성, 지속성을 제공하는 바이닐로 돌아가고 있음
- 웹 기술의 끊임없는 변화 속에서, 오래된 웹사이트도 여전히 잘 작동한다는 것을 잊기 쉬움
- 1990년대의 단순한 텍스트 웹사이트도 현대 브라우저에서 당시와 동일하게 로드됨
- 웹사이트는 시간이 지나면서 CSS를 통한 스타일링, JavaScript를 통한 상호작용, 웹소켓을 통한 실시간 업데이트 등 추가 기능을 얻었음
- 그러나 그 기반은 여전히 페이지, 폼, 세션에 기반을 두고 있음
- Ruby on Rails는 20년 전, 인터랙티브하고 데이터베이스 기반의 웹 애플리케이션을 구축하기 위한 통합 접근 방식으로 등장하였음
- Airbnb, Shopify, Github, Instacart, Gusto, Square 등 수많은 성공적인 기업의 기반이 되었으며, 현재 수조 달러 규모의 비즈니스가 Ruby on Rails 위에서 운영되고 있음
- 효과적인 도구는 추상을 통해 복잡한 작업을 단순화함
- 자동차를 예로 들면, 운전은 한때 연료 시스템, 타이밍, 클러치 메커닉에 대한 이해를 필요로 했지만, 이제 대부분의 운전자는 자신의 차량에 몇 개의 기어가 있는지조차 모름
- Ruby on Rails는 로그인 세션, CSRF 보호, 데이터베이스 ORM 등 웹 개발의 모범 사례를 접근하기 쉬운 도구 모음으로 패키징하였음
- 이러한 추상화는 개발자가 기술적인 세부 사항보다 제품 구축에 집중할 수 있도록 함
- 오늘날 대부분의 개발자는 로그인 쿠키의 내용을 알지 못하지만, 그것이 애플리케이션을 구동하고 있음
- Rails는 웹의 기본 요소에 충실하여 성공을 거두었음
- 페이지, 입력 필드, 폼과 같은 HTML 기본 요소를 사용함
- 백엔드 중심의 프레임워크로서, 데이터 검증, 처리, 저장에 집중하여 폼 생성이 간단함
- JavaScript는 Rails의 초기 성공 이후 두각을 나타내었음
- 지난 10년간의 웹 개발 발전은 기본적으로 웹사이트에 아이폰 앱의 기능을 부여하였으며, 여전히 웹사이트로 남아있음
- Next.js는 이제 스타트업을 구축하기 위한 가장 일반적인 도구로 사용되고 있음
- 프론트엔드 중심의 프레임워크로서, 동적 로딩 상태, 서버 사이드 렌더링, 복잡한 컴포넌트 빌딩을 가능하게 함
- 또 다른 수조 달러 규모의 기업들이 Next.js 위에서 구축되고 있으며, 이러한 웹 앱은 Ruby on Rails로 구축된 것보다 더 빠르고 정교함
- Next.js와 그 기반 기술인 React는 현대 웹 혁신의 많은 부분을 주도하고 있음
- 기본적으로 Spotify, Netflix, Facebook, Stripe와 같은 주류 소비자 제품은 모두 이 스택 위에서 실행됨
- 이는 개발자가 웹 표준의 한계를 넘어 빠르고 맞춤화된 상호작용 제품을 만들 수 있도록 함
- Next.js의 빠른 채택 속에서도, Rails는 여전히 관련성을 유지하고 있음
- 독립 프로젝트에서부터 AI 기업에 이르기까지 새로운 프로젝트들이 여전히 Rails를 선택하고 있음
- 사실, Next.js와 같은 새로운 JavaScript 웹 프레임워크의 물결은 웹 앱 구축을 더 어렵게 만들었음
- 이러한 도구는 개발자에게 동적 데이터 렌더링과 실시간 상호작용과 같은 더 많은 기능을 제공하지만, 그 대가로 추상화 수준이 낮아짐
- Next.js는 실제로 네이티브 아이폰 앱과 경쟁함
- 이전에는 정교한 사용자 경험을 위해 스타트업이 아이폰 앱을 필요로 했으며, 아이폰 앱 구축은 종종 여러 전문 개발자를 필요로 하는 복잡한 과정이었음
- Next.js는 웹사이트가 아이폰 앱 품질에 접근할 수 있도록 하였음
- 오늘날 가장 정교한 제품 중 일부인 Linear와 ChatGPT는 Next.js 애플리케이션으로 출시되었으며, 모바일 앱을 부차적인 우선순위로 다루었음.
- Rails는 출시 이후 20년 동안 진화하여 JavaScript 상호작용, 백엔드 작업 관리, 로딩 상태, 실시간 애플리케이션 도구 등을 추가하였음
- 모바일 앱 개발도 지원함. 애플리케이션 패턴이 진화함에 따라, Rails는 HTML 기반의 기반을 유지하면서 이러한 패턴을 프레임워크 기능으로 통합하였음
- 대부분의 웹 애플리케이션은 여전히 페이지상의 폼으로 구성되어 있음
- 구인 게시판, 벤더 시스템, 전자상거래 스토어 등이 이에 해당함
- Next.js는 이를 구축할 수 있지만, Rails에 비해 추가적인 개발 시간이 필요함
- 최첨단 프레임워크를 사용하는 것은 빈번한 업데이트, 새로운 라이브러리, 예상치 못한 문제를 통해 불안정을 초래함
- Next.js 애플리케이션은 종종 Vercel, Resend, Temporal과 같은 다수의 서드파티 서비스에 의존하여 플랫폼 위험을 증가시킴
- 개발자들은 오늘날에도 Rails를 선택하는데, 이는 20년이 지난 지금도 웹 애플리케이션을 구축하는 가장 단순하고 추상화된 방법이기 때문임
- 솔로 개발자들은 독립적으로 동적이고 실시간 웹 애플리케이션을 만들 수 있으며, 엔터프라이즈 팀은 철저한 테스트를 지원하는 여러 모델과 접근 제어를 가진 애플리케이션을 구축할 수 있음
- Rails는 작은 팀이 더 빠르게 작업하면서 개발 및 유지보수 비용을 줄일 수 있도록 도와줌
- 필자는 두 프레임워크 모두를 사용한 경험이 있음
- 벤처 자금을 받은 AI 스타트업인 Find AI를 Rails로 구축하였음
- 검색 엔진으로서, 복잡한 백엔드 작업을 간단한 프론트엔드 요구와 함께 처리하는 Rails의 능력으로부터 이점을 얻었음
- 현재는 대규모 데이터셋을 탐색하고 관리하기 위한 Chroma Cloud를 작업 중이며, Next.js는 고급 상호작용과 데이터 로딩 요구를 충족시킴
- Rails는 현재의 AI 기반 애플리케이션 물결 속에서 노화의 흔적을 보이기 시작함
- LLM(대형 언어 모델) 텍스트 스트리밍, Ruby의 병렬 처리, AI 코딩 도구를 위한 강력한 타입 지원 등의 영역에서 어려움을 겪고 있음.
- 그럼에도 불구하고, 여전히 효과적인 도구로 남아있음
- 바이닐은 음악의 접근성을 넓히며 산업을 변화시켰음
- 시간이 지나면서 음질은 향상되었지만, 초기 형식은 여전히 가치를 지님
- The Köln Concert는 비트레이트와 관계없이 여전히 인기가 있음
- 기술 세계에서도 마찬가지로, Linear와 같은 정교한 제품을 즐길 수 있는 동시에, Craigslist의 90년대 스타일 웹사이트가 여전히 더 많은 수익을 창출할 수 있음.
- 결국, 사용자들은 제품의 구현 방식보다 그 유용성에 더 신경 씀
- 외형적인 정교함은 사라질 수 있지만, 유용성은 지속됨
GitHub이 Rails로 개발된 것은 금시초문인데요. Gitlab이 Rails로 개발된 것은 맞는데...Gitlab 이 Rails를 잘 써서 기억에 오래 남긴 하네요.
GitHub 초기에 Rails 커뮤니티를 중심으로 네트워크를 구축했어요.
https://read.first1000.co/p/-github
좀 다른건이지만, Ruby on Rails의 보안 이슈 (Mass Assignment Vulnerability)를 Egor Homakov가 지적한 건이 있었는데. 이게 개발자가 조심하면 피할 수 있는 문제여서 이걸 패치해야하는지 안해야하는지 이야기가 있었습니다. (RTFM 같이 말할 수 있으니까요)
이걸 리포팅한 Egor Homakov가 선택한 방법은 당시에도 레일즈로 운영되고, 심지어 레일즈가 호스팅되던 GitHub을 공격하는거였습니다. 실제로 성공했고요.
그래서 가장 큰 Rails앱도 이 사례에서 자유롭지 않음을 보여주었고요.
개발자를 믿을지 (수동 메모리관리 ) vs 믿지않을지 (GC등) 에서의 선택이었다고 생각하지만, 저는 RTFM 같은 답변이나, 보안에서는 "알고서 잘 할것"을 경계할때 종종 생각 나더라고요
Hacker News 의견
-
수백 명의 사람들이 이 기사를 읽고 있는 지금, 여러분은 제 책상 위에 있는 Mac Mini를 통해 접근하고 있는 것임
-
웹 앱 중에서 CRUD 폼만 있는 것을 좋아함. 모든 문제에 적용되지는 않지만, 현실 세계와 상호작용하는 많은 문제 영역에서 잘 작동함. "약속이 있는지 확인하려면 약속 목록을 확인하세요" 같은 방식임
- 반면, 통합 캘린더나 대시보드에 혼합된 "앱" 패턴도 유용함. Rails에서도 모두 구축 가능함. 그러나 CRUD 앱의 단순함이 매력적임
- 어떤 스타일로든 원하는 기술로 구축할 수 있지만, Rails는 "1 모델 = 1 개념 = 1 REST 엔티티"를 선호하는 것 같음
- Next.js와 같은 라이브러리는 "1 작업/뷰 = 혼합된 개념 = 1 특정 화면"을 선호하는 것 같음
-
Ruby/Rails 커뮤니티가 이상한 이유는 절반은 조용히 작업을 하고, 나머지 절반은 Rails가 죽지 않았음을 주기적으로 확인시켜야 하는 것 같음
- 모든 것이 AI를 필요로 하는 것은 아님
-
Rails가 AI 응용 프로그램의 물결 속에서 나이를 드러내고 있음. LLM 텍스트 스트리밍, 병렬 처리에서 어려움을 겪고 있음
- 내 경험으로는 Hotwire와 함께 매우 쉽게 작동했음. 수천 명의 사용자가 있는 Rails 앱에서 문제 없이 스트리밍 에이전트 채팅 인터페이스를 운영 중임
-
Django + gevent를 추천함. Python 타입 시스템을 사용하며, 스트리밍 및 IO 바운드 병렬 처리에 적합함. CPU 바운드 병렬 처리에는 적합하지 않지만, 웹 애플리케이션에서는 덜 중요함
-
Ruby, Django, D 언어로 RoR 같은 메타 웹 프레임워크를 구축하고 유지할 수 있음
- Go와 Rust는 놀라운 언어지만, 왜 Rails 같은 프레임워크를 만들지 못하는지 궁금함. 시간이 지나면 가능할지, 아니면 근본적인 문제가 있는지 궁금함
-
RoR은 강력함. 하지만 모든 것이 너무 빠르게 변화하고 있어, 최신 기술을 따라가지 않으면 뒤처질 것 같은 느낌이 있음
-
AI 코딩 도구에 강한 타입이 부족하다는 비판을 들었지만, 내 경험상 LLM은 Rails 코드베이스에서 잘 작동함
- Rails는 강력한 관습을 가지고 있어, 타입 정보가 없어도 LLM이 잘 학습할 수 있음. Rails의 핵심은 시간이 지나도 크게 변하지 않았음
-
Django를 사용 중이며, 모든 것이 새롭게 느껴짐. htmx + alpine.js를 사용해 HTML을 전송하고 있으며, JSON REST API에서 벗어나 생산성이 크게 향상됨
-
RoR은 훌륭함. Ruby는 그 이상으로 성장해야 함
- Django 앱을 Python 3로 재작성할지 RoR로 재작성할지 선택해야 했을 때, 후자를 선택한 회사에서 일했음. Django에 들어온 많은 아이디어가 RoR에서 시작되었음
- Python이 있는 다른 영역에서도 혁신이 필요함. 과학 컴퓨팅, 머신러닝/AI, 데이터 분석 등에서 Ruby가 Rails처럼 채택될 필요가 있음
-
2010년대에 관습이 설정보다 우선하는 접근 방식이 인기를 끌었음
- Angular, EmberJS, Django, Rails가 매우 인기가 있었음
- 현대 스택은 React/NextJS와 같은 맞춤형 백엔드로 이동함
- NextJS가 React에 가장 적합한 "관습이 설정보다 우선"하는 접근 방식인지 궁금함