들어가며

최근 50개+ MVP를 만든 빌더 Harshil Tomar의 “상위 1% 빌더가 되기 위한 18가지 규칙”이 화제다. 인증은 Clerk, UI는 shadcn, 배포는 Vercel, 상태 관리는 Zustand — 하나하나 옳은 말이다.

그런데 이 18개 규칙을 읽으면서 한 가지 생각이 떠나지 않았다.

Rails 8은 rails new 한 줄로 이 중 14개를 이미 해결한다.

18가지 규칙의 핵심은 “바퀴를 재발명하지 마라”다. 그런데 Next.js 생태계에서 바퀴를 안 재발명하려면 Clerk + shadcn + Stripe + tRPC + Zustand + Vercel + Prisma + UploadThing + Sentry + PostHog를 각각 찾아서, 각각 설정하고, 각각의 문서를 읽어야 한다.

Rails는 다르다. 프레임워크 하나가 전부 들고 온다.

그리고 이 차이가 바이브 코딩 시대에 결정적이다.

바이브 코딩이란

Andrej Karpathy가 2025년 2월에 던진 용어다.

“완전히 분위기에 몸을 맡기고, 지수적 성장을 받아들이고, 코드가 작동하는지조차 잊어버리는 것.”

AI에게 의도를 말하면 AI가 코드를 쓴다. 사람은 방향만 잡는다. 이 방식이 작동하려면 하나의 조건이 있다.

AI가 예측 가능한 패턴으로 코드를 생성할 수 있어야 한다.

여기서 Rails 8이 빛난다.

1. Convention over Configuration — AI가 가장 좋아하는 원칙

바이브 코딩의 최대 병목은 코드 생성이 아니다. 결정이다.

Next.js로 프로젝트를 시작하면 AI에게 이런 걸 일일이 알려줘야 한다:

  • 폴더 구조를 어떻게 잡을지 (app router? pages router?)
  • 상태 관리를 뭘로 할지 (Zustand? Jotai? Redux?)
  • API를 어떻게 설계할지 (tRPC? REST? GraphQL?)
  • 스타일링을 어떻게 할지 (CSS Modules? Tailwind? styled-components?)
  • 데이터 페칭을 어떻게 할지 (SWR? React Query? Server Components?)

Rails에서는 이 결정이 이미 되어 있다.

rails new my-app

이 한 줄이 끝나면:

  • 폴더 구조: app/controllers, app/models, app/views — 정해져 있다
  • API: RESTful 라우팅 — resources :posts면 7개 엔드포인트가 자동 생성
  • ORM: ActiveRecord — 테이블명은 복수형, 모델은 단수형
  • 뷰: ERB 템플릿 — 레이아웃, 파셜, 헬퍼 전부 규칙이 있다
  • 테스트: 테스트 디렉토리와 헬퍼가 미리 잡혀 있다

AI에게 “유저 CRUD 만들어”라고 말하면, Rails를 아는 AI는 100% 예측 가능한 코드를 생성한다. 물어볼 게 없기 때문이다.

Convention이 많을수록 AI의 결정 부담이 줄어든다. 결정 부담이 줄수록 생성 품질이 올라간다. 이게 바이브 코딩에서 Rails가 가진 구조적 우위다.

2. rails new = 18가지 규칙 중 14개 해결

원문의 18가지 규칙을 Rails 8이 어떻게 흡수하는지 하나씩 본다.

규칙 1: 인증을 직접 만들지 마라

Rails 8은 has_secure_password + generates_token_for를 내장한다. DHH가 직접 만든 인증 생성기가 있다. gem 하나 없이 회원가입, 로그인, 세션 관리, 비밀번호 리셋이 완성된다. Clerk 설정하는 시간에 이미 끝나 있다.

규칙 2: UI는 Tailwind + 컴포넌트 라이브러리

rails new --css tailwind면 Tailwind가 바로 붙는다. 빌드 스텝 없이. shadcn이 해결하는 “예쁜 기본 컴포넌트” 문제는 ERB 파셜 + Stimulus 컨트롤러 조합으로 해결한다. React 컴포넌트보다 단순하다 — HTML이니까.

규칙 4: API 오버엔지니어링 하지 마라

Rails의 기본이 Boring REST다. resources :posts를 routes.rb에 한 줄 쓰면 index, show, new, create, edit, update, destroy — 7개 액션이 생긴다. tRPC가 해결하는 “타입 안전한 API” 문제를 Rails는 “API가 필요 없는 구조”로 해결한다. 서버에서 HTML을 렌더하니까.

규칙 5: 상태 관리를 심플하게

Hotwire(Turbo + Stimulus)는 클라이언트 상태 관리를 제거한다. Zustand조차 필요 없다. 서버가 HTML을 보내면 끝이다. Turbo Frame은 페이지 일부만 교체하고, Turbo Stream은 실시간 업데이트를 서버에서 푸시한다. 클라이언트에 상태가 없으니 상태 관리 라이브러리가 필요 없다.

규칙 6: 배포 자동화

Kamal 2는 Rails 8의 공식 배포 도구다. kamal deploy 한 줄이면 Docker 빌드 → 이미지 푸시 → 제로 다운타임 롤링 배포가 완료된다. Vercel처럼 특정 플랫폼에 종속되지 않는다. $5 VPS 아무 데나 배포 가능하다.

규칙 7: ORM을 써라

ActiveRecord는 Ruby on Rails의 ORM이자, 아마 세상에서 가장 성숙한 ORM이다. 마이그레이션, 유효성 검사, 관계 설정, 쿼리 인터페이스 — 20년간 검증됐다. Prisma가 추구하는 “개발자 친화적 DB 인터랙션”을 Rails는 2004년부터 하고 있었다.

규칙 8: 파일 업로드를 직접 만들지 마라

Active Storage는 Rails 내장이다. has_one_attached :avatar면 끝. S3, GCS, Azure, R2 — 어댑터만 바꾸면 스토리지를 자유롭게 교체한다. UploadThing이 SaaS로 제공하는 걸 Rails는 프레임워크에 내장했다.

규칙 9: API 키 관리

Rails의 credentials.yml.enc는 암호화된 시크릿 저장소다. EDITOR=vim rails credentials:edit로 편집하고, master.key만 안전하게 관리하면 된다. .env 파일 + .gitignore 조합보다 구조적으로 안전하다.

규칙 14: 문서를 첫날에 써라

Rails의 convention 자체가 문서다. routes.rb를 열면 앱의 전체 URL 구조가 보인다. schema.rb를 열면 DB 구조가 보인다. 모델 파일을 열면 관계와 유효성 검사가 보인다. 별도 문서를 쓰지 않아도 코드가 자기 설명적이다.

규칙 15: 폴더 구조를 정리해라

Rails가 강제한다. 선택의 여지가 없다. 컨트롤러는 app/controllers, 모델은 app/models, 뷰는 app/views. 10년 전 Rails 프로젝트를 열어도 파일이 어디 있는지 안다. Next.js 프로젝트 10개를 열면 폴더 구조가 10개 다 다르다.

규칙 16: 리얼타임을 직접 만들지 마라

Action Cable + Solid Cable. WebSocket이 DB 기반으로 내장되어 있다. Pusher나 Partykit 같은 외부 서비스가 필요 없다. ActionCable.server.broadcast면 실시간 업데이트가 간다.

규칙 17: 기술 부채를 관리해라

Rails의 convention을 따르면 기술 부채가 구조적으로 줄어든다. 모든 프로젝트가 같은 구조니까. “이 프로젝트는 어떻게 생겼지?”라는 질문 자체가 사라진다.

3. No Build — AI가 실수할 여지를 제거한다

Next.js 프로젝트에서 AI가 코드를 생성하면 이런 일이 벌어진다:

빌드 실패 → Webpack 설정 확인 → 로더 추가 → 버전 충돌 →
package.json 수정 → node_modules 삭제 → 재설치 → 또 다른 에러

Rails 8의 No Build 철학은 이 전체 루프를 제거한다.

  • Import Maps: npm install 없이 CDN에서 JS 라이브러리를 바로 가져온다
  • Propshaft: 에셋을 그냥 복사한다. 변환, 번들링, 트리 쉐이킹 없다

AI가 Stimulus 컨트롤러를 하나 추가하면? 파일 하나 만들면 끝이다. 빌드 스텝이 없으니 빌드 에러도 없다. 바이브 코딩에서 가장 짜증나는 순간 — “코드는 맞는데 빌드가 깨진다” — 이 자체가 발생하지 않는다.

4. Solid Trifecta — 외부 서비스 의존성 제거

Next.js 프로젝트의 전형적인 인프라:

앱 서버 (Vercel) + DB (Supabase) + 캐시 (Upstash Redis) +
큐 (Inngest) + WebSocket (Pusher) + 파일 (UploadThing)

6개 서비스. 6개의 대시보드. 6개의 API 키. 6개의 장애 포인트.

Rails 8 + Solid Trifecta:

앱 서버 (Kamal) + DB (PostgreSQL)

끝이다. 캐시, 큐, WebSocket 전부 같은 PostgreSQL DB를 쓴다.

AI에게 “백그라운드 잡 추가해”라고 말하면, Redis 설정을 안내하는 대신 app/jobs/my_job.rb 파일 하나를 만든다. 외부 서비스 설정이 필요 없으니 AI가 설정을 잘못할 여지도 없다.

5. One Person Framework — 바이브 코딩의 이상적 파트너

DHH가 Rails 8을 “One Person Framework”라 부르는 이유가 있다. 혼자서 SaaS 전체를 빌드하고 배포할 수 있는 프레임워크.

바이브 코딩에서 이것은 사람 1명 + AI 에이전트로 번역된다.

사람:  "유저가 글을 쓰고, 댓글을 달 수 있는 블로그 만들어"
AI:    scaffold 생성 → 모델 관계 설정 → 뷰 작성 → Tailwind 스타일링
사람:  "배포해"
AI:    kamal deploy

이게 가능한 이유는 Rails가 풀스택이기 때문이다. 프론트엔드 프레임워크 + 백엔드 API + 배포 도구를 따로 선택할 필요가 없다. 하나의 프레임워크가 하나의 언어(Ruby)로 전부 처리한다.

AI가 알아야 할 것: Ruby + Rails convention. 이것만 알면 인증부터 배포까지 전부 된다.

Next.js로 같은 걸 하려면? React + TypeScript + Node.js + Prisma + tRPC + Tailwind + NextAuth + Vercel CLI — AI가 알아야 할 기술 스택이 3배로 늘어난다. 스택이 넓어질수록 AI의 환각 확률도 높아진다.

6. Boring REST — 예측 가능성이 품질이다

바이브 코딩에서 AI가 생성한 코드의 품질은 예측 가능성에 비례한다.

Rails의 RESTful 라우팅은 지루할 정도로 예측 가능하다:

# config/routes.rb
resources :posts do
  resources :comments
end

이 두 줄로 AI는 정확히 어떤 컨트롤러, 어떤 액션, 어떤 URL이 필요한지 안다. 창의적인 API 설계가 아니라, 20년간 검증된 패턴을 따르는 것이다.

GraphQL은 유연하지만 AI가 스키마를 잘못 설계할 수 있다. tRPC는 타입 안전하지만 프로시저 구조를 잘못 잡을 수 있다. REST는 틀릴 여지가 적다. 리소스가 있으면 CRUD가 있다. 그게 끝이다.

지루함이 바이브 코딩에서는 미덕이다.

7. Scaffold — 바이브 코딩의 원조

사실 Rails는 바이브 코딩의 원조다.

rails generate scaffold Post title:string body:text published:boolean

이 한 줄이 생성하는 것:

  • 마이그레이션 파일 (DB 테이블 생성)
  • 모델 (유효성 검사, 관계 설정)
  • 컨트롤러 (7개 CRUD 액션)
  • 뷰 (index, show, new, edit — 4개 ERB 파일)
  • 라우트 설정
  • 테스트 파일

2004년에 DHH가 “15분 만에 블로그 만들기” 데모에서 보여준 게 이것이다. 20년 뒤, 우리는 이걸 “바이브 코딩”이라 부르고 있다.

차이가 있다면, 2004년에는 scaffold가 시작점이었고, 2026년에는 AI가 scaffold 너머까지 간다는 것이다. 하지만 원리는 같다 — 예측 가능한 패턴을 기반으로 코드를 자동 생성한다.

8. Omakase — “메뉴는 셰프에게 맡겨라”

Rails Doctrine의 세 번째 원칙: The Menu is Omakase.

오마카세 레스토랑에서 메뉴를 고르지 않는다. 셰프가 최선의 조합을 내놓는다. 손님은 먹기만 하면 된다.

Rails 8이 제시하는 오마카세:

  • 인증? has_secure_password
  • 캐시? Solid Cache
  • 큐? Solid Queue
  • WebSocket? Solid Cable
  • 배포? Kamal
  • CSS? Tailwind
  • JS? Import Maps + Stimulus

이 스택을 고르는 데 시간을 쓰지 않는다. Rails가 이미 골라놨다. 검증된 조합이다.

바이브 코딩에서 이 철학은 더 강력해진다. AI에게 “Rails 8 방식으로 해”라고 말하면 오마카세 전체가 적용된다. “Zustand 쓸까 Jotai 쓸까 Redux Toolkit 쓸까”를 AI에게 물어볼 필요가 없다. 선택지가 하나니까.

선택지가 줄수록 AI의 출력 품질이 올라간다. 이것이 오마카세와 바이브 코딩의 교차점이다.

결론: 왜 Rails 8인가

바이브 코딩의 18가지 규칙은 결국 하나의 원칙으로 수렴한다:

직접 만들지 말고, 검증된 도구를 갖다 쓰세요.

Next.js 생태계에서 이 원칙을 따르려면 10개 이상의 서비스를 직접 골라 조합해야 한다. Rails 8에서는 rails new가 그 10개를 한 번에 해결한다.

기준 Next.js + 18가지 규칙 Rails 8 Vanilla
결정 횟수 10+ (각 규칙마다 도구 선택) 0 (Convention)
외부 서비스 6+ (Vercel, Supabase, Upstash, …) 1 (PostgreSQL)
빌드 설정 Webpack/Turbopack + 설정 없음 (No Build)
AI가 알아야 할 것 React + TS + 10개 라이브러리 API Ruby + Rails Convention
배포 PaaS 종속 (Vercel) VPS 어디든 (Kamal)
비용 $20~100+/mo (서비스 합산) $5/mo (VPS 하나)

Rails 8 Vanilla는 바이브 코딩에 가장 적합한 프레임워크다.

바퀴를 재발명하지 말라는 규칙을 프레임워크 레벨에서 강제하기 때문이다. AI가 결정할 것이 적을수록, AI가 생성하는 코드의 품질이 높아진다. Rails의 20년 된 Convention이 2026년의 바이브 코딩에서 가장 강력한 무기가 된다.

DHH가 Rails를 만들 때 바이브 코딩을 상상하지 않았을 것이다. 하지만 “개발자의 행복을 최적화하라”는 첫 번째 원칙이, “AI의 예측 가능성을 최적화하라”와 정확히 같은 방향을 가리키고 있었다.

그게 Convention의 힘이다.