Ruby on Rails 75번째 소식

지금 이 소식은 캐나다 토론토에서 쓰고 있어요. 시차와 추위를 견디면서도 Rails와 웹 생태계를 이끄는 회사들이 모여 있는 도시 한가운데에서 작성하는 소식들이 좀 더 가까이 느껴지기도 해요. 그런 의미에서 이번 호는 “실전에서 검증되고, 앞으로를 준비하는 Rails 생태계” 라는 키워드로 꾸려봤어요.

먼저 37signals가 새로 공개한 칸반 툴 Fizzy를 시작으로, SaaS와 오픈소스를 한 번에 가져가는 새로운 모델, 그리고 라이선스·아키텍처·CSS·웹훅까지 깊게 들여다볼 거예요. 이어서 Rails/Ruby 리더 80여 명에게 물어본 Rails의 미래, AI, 그리고 모놀리스의 지속 가능성도 함께 정리했어요. 마지막으로는 rails new snowdevil에서 블랙 프라이데이 하루 62억 달러 매출까지 성장한 Shopify 이야기로, Rails가 현실 세계에서 얼마나 멀리 갈 수 있는지 함께 살펴보려고 해요.

🎧 10분 요약 오디오로 들어보시겠어요? → YouTube로 듣기

새로운 소식

Fizzy: 37signals가 공개한 새 칸반 이슈·아이디어 트래킹 툴

Fizzy는 Trello, Jira, Asana, GitHub Issues처럼 한때 사랑받던 이슈·아이디어 트래킹 도구들이 점점 느리고 복잡한 “기업용 괴물(bloatware)”로 변해버린 상황을 비판하며, “칸반은 원래 이렇게 써야 한다”는 관점으로 다시 설계한 새로운 칸반 툴이에요. 카드와 컬럼 기반 구조에 인간적인 기본값, 화려하고 경쾌한 인터페이스를 더해 기존 도구들의 복잡함과 답답함을 리셋하겠다는 목표를 갖고 있어요.

Basecamp 팀은 여전히 큰·복잡한 프로젝트는 Basecamp로 관리하지만, 최근에는 버그·이슈·아이디어 트래킹 같은 작은 프로젝트나 팟캐스트·영상 제작처럼 가벼운 워크플로에는 Fizzy를 더 자주 사용하고 있다고 밝혔어요. 단순하고 빠른 칸반 보드를 원하는 팀을 위한 도구라는 포지셔닝이 분명해요.

요금 모델도 매우 단순해요. 모든 사용자는 최대 1,000개의 카드까지 무료로 쓸 수 있고, 그 이후에는 월 20달러만 내면 카드·사용자 모두 무제한으로 쓸 수 있어요. 티어·플랜 구분 없이 “청바지에 붙은 가격표처럼” 가격 하나만 제시하는 방식이에요.

또한 Fizzy는 완전 오픈 소스로 공개되어 있어요. 37signals가 운영하는 SaaS 버전을 그대로 써도 되고, GitHub에서 소스를 가져가 직접 호스팅하며 원하는 대로 커스터마이징할 수도 있어요. Kamal을 이용한 자체 서버 배포용 설정과 가이드도 제공하며, 좋은 아이디어가 있다면 PR로 기여해 전체 제품을 함께 발전시키자는 메시지를 담고 있어요.

• 제품 소개/런칭 글: INTRODUCING FIZZY 전체 글 보기

• 오픈 소스 코드: GitHub – basecamp/fizzy GitHub

• 라이브 서비스: fizzy.do

Fizzy, SaaS + 오픈소스의 새 모델이 된 Rails 앱

Fizzy를 둘러싸고 DHH, Jason Fried, 여러 Rails 개발자들이 라이선스부터 아키텍처, CSS, 웹훅, 배포 방식까지 꽤 많은 이야기를 풀어냈어요. 흩어져 있던 내용을 한 번에 정리하면 이렇게 볼 수 있어요.

1. O'Saasy 라이선스: “MIT + SaaS 예외”

DHH는 Fizzy가 O'Saasy License로 공개됐다고 밝혔어요. 한마디로 말하면 MIT 라이선스에 “원 라이선서가 SaaS로 수익을 낼 권리”를 명시적으로 보존한 버전이에요.

• 코드는 자유롭게 사용·수정·호스팅할 수 있지만, 상업적 SaaS로 그대로 경쟁하려는 경우에는 제약이 걸리는 구조예요.

• “Feel free to use!”라고 밝힌 만큼, 자체 호스팅·커스텀·기여에는 열린 태도예요.

2. ONCE에서 “SaaS + OSS”로: Jason Fried가 말하는 전략 변화

Jason Fried는 Fizzy를 계기로 ONCE 모델을 접고 새로운 이중 모델로 넘어간다고 설명해요.

• ONCE 회고

  • 2023년 9월, “한 번 사고 소유하는 소프트웨어”라는 개념으로 ONCE를 발표했어요.

  • Campfire(그룹 채팅, $399 1회 결제)와 Writebook(온라인 출판 도구, 무료) 두 제품을 ONCE로 출시했고, 지금은 둘 다 무료 + 오픈소스(MIT)로 풀렸어요.

• 새 모델: SaaS + 오픈소스의 결합

  • 앞으로의 방향은 **“우리가 호스팅·지원해 주는 유료 SaaS” + “누구나 자가 호스팅 가능한 무료 오픈소스”**의 2트랙 모델이에요.

  • Wordpress, Ghost, Plausible, GitLab과 같은 모델을 직접 언급하면서, 여기에 합류하겠다고 선언해요.

• Fizzy는 이 새로운 모델의 1호 제품

  • (1) Basecamp가 호스팅하는 전통적인 SaaS 버전

  • (2) 스스로 설치·수정·포크 가능한 오픈소스 버전

  • 두 가지를 처음부터 동시에 제공하고, 커뮤니티 PR로 함께 키우겠다는 전략을 내세워요.

3. SaaS와 코어 분리: fizzy vs fizzy-saas

DHH는 Fizzy가 두 레포로 나뉘어 있다고 설명해요.

• 누구나 돌릴 수 있는 코어 코드베이스(fizzy)

• 37signals가 운영하는 호스팅 SaaS용 설정(fizzy-saas)
  코어만으로도 완전한 앱을 돌릴 수 있고, fizzy-saas는 내부용 젬에 의존해서 그대로는 실행 못 하더라도 **“우리가 SaaS 셋업을 어떻게 나눴는지”**를 학습용으로 볼 수 있게 공개했어요.

4. 데이터 모델까지 공개: Fizzy ERD 다이어그램

Vladimir Dementyev는 37signals가 Fizzy의 ERD(엔터티 관계 다이어그램) 를 railserd.com에 공유했다고 소개해요.

• ERD를 벽에 붙여두고 볼 만하다고 할 정도로, 계정·보드·컬럼·카드·이벤트들이 어떻게 얽혀 있는지 시각적으로 잘 드러난 자료예요.

• Rails ERD 도구(railserd)를 만든 개발자와, ERD를 공개한 37signals 양쪽을 함께 언급하며, 데이터 모델 공개 자체가 좋은 학습 자료가 된다고 강조해요.

5. 테스트 Suite: “2,500 assertion을 4초 안에”

DHH는 Fizzy의 테스트 Suite 가 거의 2,500개의 assertion을 4초 안에 돌린다고 자랑해요.

• 비결로 “바닐라 Rails fixtures + parallel test runners” 조합을 꼽아요.

• 빠르기만 한 게 아니라, 그 자체로 “아름답다”고 표현할 정도로 단순한 도구를 끝까지 밀어붙인 테스트 전략을 보여줘요.

• 예시로 cards_controller_test.rb를 가리키며, 컨트롤러 테스트를 어떻게 정리하는지 참고하라고 링크를 남겼어요.

6. 데이터·스토리지 설계: UUIDv7, MySQL + SQLite, Active Record Search

DHH는 Fizzy의 동작 방식을 몇 가지 포인트로 정리해요.

• UUIDv7 기본 키 + Base36 표현

  • 프라이머리 키로 UUIDv7을 쓰고, Base36 문자열로 노출해요.

  • 시간 순으로 정렬 가능하고, 사람이 복사·붙여넣기 하기에도 적당한 길이의 ID를 얻으려는 선택이에요.

• MySQL + SQLite 이중 지원

  • SaaS 버전은 MySQL, 온프레미스 버전은 SQLite를 사용해요.

  • SQLite 파일을 통째로 주고받는 방식으로 SaaS ↔ 자가 호스팅 간 import/export를 구현할 계획을 언급해요.

• Active Record Search 작업 시작

  • SQLite와 MySQL(Trilogy)을 모두 지원하는 풀텍스트 검색 레이어를 Active Record Search로 만들고 있다고 밝혀요.

  • Fizzy의 검색 기능을 통해, 이후 Rails에도 이 기능을 업스트림할 계획을 내비쳐요.

7. 멀티테넌시와 아키텍처 패턴: 계정 slug, 백그라운드 잡, 도메인 모델

Alex Shapalov와 Drifting Ruby, BeautifulRuby의 콘텐츠를 합치면 Fizzy의 멀티테넌시와 도메인 설계가 또렷하게 보여요.

• Account slug 기반 멀티테넌시

  • /{account_slug} 형태의 URL에서 숫자 계정 ID를 꺼내는 Rack 미들웨어(AccountSlug::Extractor) 를 사용해요.

  • 이 미들웨어가 SCRIPT_NAME, PATH_INFO를 재작성하고 Current.with_account로 래핑해서, 앱 전체가 사실상 /{account}/… 아래에 마운트된 것처럼 동작해요.

  • 컨트롤러는 멀티테넌시를 크게 의식하지 않고 평범한 Rails 컨트롤러처럼 작성할 수 있어요.

• Account-aware 백그라운드 잡

  • Active Job을 확장해서, 잡을 enqueue할 때 Current.account를 함께 직렬화하고, 실행 시 다시 복원해요.

  • 덕분에 “잘못된 테넌트에서 잡이 돌아가는” 사고를 막을 수 있어요.

• Rich Domain Model + 컨트롤러 분리

  • 별도의 service 객체 대신, Card 같은 모델 안에 도메인 로직을 풍부하게 담는 스타일을 쓰고 있어요.

  • 단순 CRUD 이외의 액션(예: 카드 닫기)은 ClosuresController 같은 별도 컨트롤러로 분리해서 책임을 명확히 해요.

8. Hotwire & Turbo: 라이브 업데이트와 “유지보수되는 Turbo”

Jorge Manrubia는 Fizzy에서 Turbo를 “풀 코스로” 쓰고 있다고 강조해요.

• Fizzy의 활동 타임라인과 보드 perma 화면은 Turbo만으로 실시간 업데이트되며, 페이지 새로고침 없이 상태가 반영돼요.

• 동시에, 최근 논쟁이었던 “Turbo가 안 유지보수된다”는 주장에 대해:

  • Turbo는 여전히 잘 작동하고, Fizzy를 포함한 여러 신규 제품에서 광범위하게 사용 중이라고 말해요.

  • 올해만 수십 개의 PR과 여러 번의 릴리스를 했고, 성급한 기능 추가보다 단순화·정리에 더 관심이 있다고 밝혀요.

  • 너무 많은 사람의 요구를 모두 만족시키려다 API가 엉망이 되는 걸 경계하면서, “정말 대부분에게 이득이 되는 제안만 받아들이자” 는 입장을 내놓아요.

9. 바닐라 CSS 철학: 빌드 툴 없이 만드는 현대 UI

Rob Zolkos는 Campfire, Writebook, Fizzy를 관통하는 “Vanilla CSS only” 전략을 깊이 있게 분석해요.

• Sass, PostCSS, Tailwind 없이도

  • 14,000줄 가까운 CSS, 100개가 넘는 파일을 모두 순수 CSS로 관리해요.

  • _reset.css, base.css, colors.css, utilities.css 정도의 평평한 구조로, 복잡한 빌드 파이프라인 없이 운영해요.

• 현대 CSS 기능 총동원

  • OKLCH 색상, color-mix(), :has(), @layer, container queries, @starting-style, View Transitions API 등 최신 기능을 적극 활용해요.

  • 수평 간격에 ch, 수직 간격에 rem을 쓰고, 미디어 쿼리도 min-width: Xch처럼 콘텐츠 기반 브레이크포인트로 잡아요.

• 유틸리티 클래스는 “첨가물”로만 사용

  • 핵심은 .btn, .card 같은 시맨틱 클래스에 두고, .flex, .gap 같은 유틸리티는 예외 상황에만 살짝 얹는 방식이에요.

• 결론은, “현대 CSS만으로도 충분히 강력하고, 많은 팀이 굳이 빌드 툴 없이도 갈 수 있다” 는 메시지예요. Fizzy는 그 생생한 실전 예시 중 하나예요.

10. Fizzy Webhooks: 통합·자동화의 핵심 표면

Rob Zolkos의 또 다른 글은 Fizzy의 웹훅 시스템을 거의 스펙 문서 수준으로 풀어줘요.

• 역할

  • Fizzy에서 발생하는 다양한 이벤트를 HTTP POST로 외부 시스템에 쏘아줄 수 있어요.

  • 채팅, 인시던트 관리, 리포팅, 대시보드 등과 쉽게 통합할 수 있는 구조예요.

• 이벤트 예시

  • card_published, card_closed, card_triaged, card_board_changed, comment_created 등 카드 라이프사이클 전반을 다루는 이벤트들이 있어요.

• 활용 아이디어

  • 팀 지표 대시보드, 개인별 Slack/Teams 다이제스트, 이탈 감지(자꾸 triage로 돌아오는 카드), 인시던트 전용 보드 뷰, SLA 위반 알림, 회의용 주간 요약 메일 등 여러 패턴을 제시해요.

• 보안 & 페이로드 특징

  • 모든 웹훅 요청은 HMAC-SHA256 서명이 달려 오고, X-Webhook-Signature 헤더로 검증해요.

  • 카드 본문은 포함되지 않고 제목만 오며, ID는 모두 문자열 형식이에요.

  • 컬럼 정보는 실제로 컬럼 이동이 있을 때만 포함되는 등, 페이로드가 꽤 알뜰하게 설계돼 있어요.

11. 코드 읽기·배포 학습 자료: BeautifulRuby & Drifting Ruby

두 개의 영상이 Fizzy를 “읽고 돌려보며 배우는 Rails 교재” 처럼 활용하고 있어요.

• BeautifulRuby의 코드 워크스루

  • GitHub 레포 구조, Magic Link 인증, RESTful 라우팅, ActiveModel 기반 서비스 객체, Hotwire 사용 패턴, 보안 이슈 후보(마법 링크 난수 생성)까지 폭넓게 짚어요.

• Drifting Ruby – Cool Things in Fizzy

  • Kamal + Comal을 사용한 배포, 프로덕션 브랜치 전략, Rails Credentials/비밀 키 관리, Docker 기반 셋업 과정을 보여줘요.

  • 멀티테넌시, ActiveJob 확장, Entropy(자동 카드 정리), Rich Domain Model, Rails 내부 컴포넌트(ActionText/ActiveStorage)까지 account-aware로 확장하는 패턴도 다뤄요.

Fizzy는 “실제 운용 가능한 SaaS 제품이면서, Rails 8 + Hotwire + Solid 스택의 레퍼런스 앱” 역할까지 하고 있는 셈이에요.

12. Turbo와 함께 진화한 Fizzy의 개발 히스토리

Rob Zolkos의 Git 히스토리 분석 글은 Fizzy가 어떻게 지금 모습에 이르렀는지를 단계별로 보여줘요.

• 이름과 개념의 진화

  • Splat(튀는 정보 조각) → Bubble(버블) → Card(카드)

  • Project → Bucket → Collection → Board로 개념도 계속 바뀌다가, 결국 카드·컬럼·보드라는 익숙한 칸반 모델에 안착해요.

• DHH의 대규모 개입

  • Rails 8.0 rc 채택, HTTP 캐싱 추가, “anemic code” 제거를 중심으로 대대적인 리팩토링을 진행해요.

  • “설명도, 구현 캡슐화도 하지 않는 얇은 래퍼는 없애자”는 철학을 코드베이스 전반에 적용해요.

• 추가되었다가 사라진 기능들

  • Boost(버블을 부풀리고 날려보내는 액션), Fizzy Ask(Claude 기반 AI 어시스턴트), Custom Views, Workflows 등이 실험됐다가 제거돼요.

  • 대신 더 단순한 빠른 필터, 자유로운 컬럼 구성 등으로 회귀하는 흐름이 보이에요.

• 기술 스택 선택

  • Rails 8.x, Hotwire, Solid Queue/Cache, Kamal, UUIDv7, 멀티테넌시, MySQL + SQLite 이중 지원까지 오늘날 Rails “정석”이라 할 만한 구성을 한 앱 안에서 보여줘요.

13. activerecord-tenanted에 대한 작은 떡밥

Kyrylo Silin은 Fizzy 관련 대화 중 **“activerecord-tenanted 접근은 무슨 일이 있었냐”**는 질문을 받자,

• “조만간 그 이야기를 들려주겠다(Will tell that story soon)”고만 짧게 언급해요.
  지금의 Account slug + Current 기반 멀티테넌시로 오기까지, 예전에 쓰던 접근법에서 무슨 변화가 있었는지에 대한 이야기가 앞으로 더 나올 것으로 보이는 정도의 작은 예고편이에요.

이렇게 정리해 보면, Fizzy는 단순히 “새 칸반 앱”이 아니라:

• 새 비즈니스 모델(SaaS + OSS)

• Rails 8 + Hotwire + Solid + Kamal 스택의 종합 샘플

• 현대 CSS·웹훅·멀티테넌시·테스트 전략까지 담은 레퍼런스 코드베이스

로 동시에 읽히는 프로젝트예요. Rails와 웹 앱을 깊게 보고 싶은 사람에게는, 코드·글·영상까지 한 세트를 이뤄주는 아주 좋은 학습 재료가 되고 있어요.

Rails/Ruby 리더 80여 명이 말한 Rails, AI, 그리고 모놀리스의 미래

Reinteractive의 Errol Schmidt가 Rails/Ruby 커뮤니티의 임원·리더 약 80~90명을 대상으로 진행한 설문조사 결과를 영상으로 정리했어요. 이 설문은 일반 개발자가 아니라 CTO, IT 매니저 같은 의사결정권자를 집중적으로 인터뷰해, Rails 팀 운영, AI 도입, 인력 채용·유지 같은 “경영 관점의 Rails”를 들여다본 점이 특징이에요.

주요 내용은 이렇게 정리할 수 있어요:

• 왜 여전히 Rails인가?
  응답자들은 한목소리로 Rails의 가장 큰 강점을 _개발 속도_와 _빠른 반복_이라고 답했어요. 컨벤션 기반 구조 덕분에 큰 팀이 함께 일하기 쉽고, 새 사람이 프로젝트에 합류해도 빠르게 적응할 수 있다는 점이 강조돼요.

• Rails의 미래를 좌우할 핵심: AI와 Hotwire
  과반수는 Rails의 미래가 “AI에 얼마나 잘 준비되어 있느냐”에 달려 있다고 봤어요. 이미 Ruby 커뮤니티에서는 AI 도구와의 통합을 위한 시도가 계속되고 있고, Hotwire를 활용한 웹·모바일 경험 구축도 중요한 화두로 떠오르고 있지만, 여전히 인지도와 활용도는 더 끌어올려야 한다는 평가예요.

• 가장 큰 리스크는 ‘인력 공백’
  응답자들은 좋은 Rails 개발자를 찾는 것보다 “뽑은 사람을 오랫동안 함께 가게 만드는 것”이 더 어렵다고 말해요. 특히 10년 이상 Rails를 써온 시니어들이 점점 은퇴 시기에 가까워지면서, 주니어·미드 레벨 개발자를 어떻게 Rails 생태계로 끌어들이고 키울지가 큰 과제로 등장했어요.

• AI 도구 활용은 이미 일상, 다만 ‘내부용’이 먼저
  대부분 회사가 Copilot, Claude 등 다양한 AI 도구 사용을 허용하고 있고, 코드 작성 비중도 앞으로 12개월 동안 _중간~높은 수준_까지 늘어날 것으로 기대하고 있어요. 보안은 내부 가이드라인으로 관리 가능한 수준이라고 느끼는 편이고, AI 기능은 먼저 _내부 도구_에 적용해 효율을 높이는 방향으로 도입하는 경향이 강해요.

• Rails 모놀리스는 여전히 비즈니스의 중심
  많은 회사에서 핵심 시스템은 여전히 Ruby on Rails 모놀리스로 유지되고 있어요. 여기서 완전 다른 스택으로의 “전면 재작성”을 고려하는 경우는 거의 없고, 대신 Rails와 Ruby 버전을 꾸준히 업그레이드하고, 필요한 기능만 추가하면서 장기적으로 운영하는 방식을 택하고 있어요. 설문에서 드러난 메시지는 명확해요: _Rails 모놀리스는 여전히 잘 작동하고 있고, 장기 투자 관점에서 효율적인 선택_이라는 인식이 강하다는 점이에요.

• 영상으로 보기: Survey Results with Ruby/Rails leaders (YouTube)

• 텍스트 요약 보기: secondb.ai 요약 페이지

“rails new snowdevil”에서 하루 매출 62억 달러까지 – 현실 세계에서 증명된 Rails의 스케일

Ruby on Rails를 만든 David Heinemeier Hansson은 Shopify의 블랙 프라이데이 성과를 언급하며, 단순한 rails new snowdevil로 시작한 스토어가 이제 하루에 62억 달러(6.2 billion)를 처리하는 수준까지 성장한 사실에 감탄을 표현했어요. “Hello World에서 이커머스의 왕좌까지(From Hello World to Ruling E-commerce)”라는 말로, Rails가 현실 세계에서 어디까지 확장될 수 있는지를 상징적으로 보여준다고 말해요.

이 감탄의 배경에는 Shopify CEO인 Tobi Lütke가 공유한 블랙 프라이데이 수치가 있어요. Shopify 플랫폼에서:

• 머천트들의 블랙 프라이데이 총 매출은 62억 달러, 전년 대비 25% 성장했어요.

• 엣지 레벨 트래픽은 분당 4억 8,900만 요청까지 치솟았고,

• 앱 서버는 분당 1억 1,700만 요청을 처리해 전년 대비 40% 증가했어요.

• 전체 이그레스(egress)는 2,370억 요청,

• 데이터베이스는 초당 5,300만 쿼리, 쓰기 기준으로도 초당 200만 쿼리를 넘겼어요.

• API는 피크 시 분당 3,100만 요청을 처리했어요.

DHH는 이 숫자들을 통해, Rails가 단순한 프로토타이핑 도구를 넘어, 전 세계 대규모 이커머스를 지탱하는 인프라로 충분히 버티고 성장할 수 있는 기술이라는 점을 강조하고 있어요.

• 트윗 보기: DHH의 원문 트윗