이번 주는 Ruby 생태계 곳곳에서 재미있는 소식이 한꺼번에 쏟아진 한 주였어요! Ruby DX의 미래 이야기부터 Smalltalk 철학으로 바라본 루프, 일본과 미국 커뮤니티의 열기, DHH의 일하는 방식, Gusto의 아키텍처 사례, Turbo 논쟁까지
각각 완전히 다른 주제 같지만 모두 “Ruby는 어떻게 더 나아지고 있을까?” 라는 공통된 질문으로 이어지더라고요.
Ruby는 언어·도구·커뮤니티 할 것 없이 계속 재밌게 진화하고 있고, 세계 곳곳에서 그 흐름을 이끌고 있는 사람들도 참 다양한 것 같아요. 이번 소식에서는 그런 변화의 조각들을 한자리에 모아봤어요.
🎧 10분 요약 오디오로 들어보시겠어요? → YouTube로 듣기
새로운 소식
Ruby DX – 과거와 미래 (RubyPrize @ RubyWorldConf)
Stan Lo가 RubyWorldConf에서 진행한 Ruby DX – Past & Future 발표 슬라이드가 공개되었어요. 짧은 15분 발표지만 Ruby 3.0 이후 지금까지 Ruby DX가 어떻게 발전해왔는지, 그리고 AI 시대에 Ruby 개발 도구들이 어떤 방향으로 나아가야 하는지 명확하게 정리한 내용이 인상적이에요.
발표 슬라이드는 다음과 같은 구성으로 되어 있어요.
-
Ruby DX의 지난 4~5년 발전
Prism·Herb 출시, IRB/Reline/RDoc 현대화, Steep 1.0, rbs-inline, Ruby LSP 등
“공유 인프라”를 중심으로 도구 생태계가 빠르게 성장한 흐름을 정리합니다.
-
AI 시대의 개발 경험
Cursor·Copilot·Claude Code 등 AI 코딩 도구를 전제로,
Ruby가 AI에게 더 잘 ‘읽히기’ 위해 필요한 요소, 특히 타입 정보 와 코드 인텔리전스 를 소개합니다.
-
Universal Indexer의 필요성
Prism이라는 통일된 파서 위에서 Ruby LSP, Steep, Sorbet 등이 각각 인덱싱 로직을 중복 구현하고 있는 현실을 짚으며,
**Ruby 생태계 전체가 공유할 ‘Universal Indexer’**가 곧 등장할 것이라는 티저를 공개합니다.
발표 마지막에는 “More and Better Tools for both Humans and AI”라는 메시지처럼,
앞으로 Ruby DX가 인간 개발자뿐 아니라 AI 도구에도 최적화된 방향으로 확장될 것임을 예고하고 있어요.
Ruby 루프를 Smalltalk로 이해하기
왜 Rubyists는 for 루프를 쓰지 않을까?
최근 글 “Some Smalltalk about Ruby Loops” 에서는 Ruby의 반복문 철학을 Smalltalk의 영향과 함께 흥미롭게 풀어내고 있어요. 핵심은 다음과 같아요.
Ruby의 반복은 “구문(syntax)” 이 아니라 객체에게 메시지를 보내는 방식이다.
Smalltalk이란?
Smalltalk은 1970년대에 탄생한 순수 객체지향 언어로,
“모든 것은 객체이며, 모든 동작은 객체들 간의 메시지 교환”이라는 사상을 중심에 둔 언어입니다.
Ruby는 Matz가 이 Smalltalk의 철학을 강하게 참고하여 만들었다고 해요.
Smalltalk의 특징:
-
for 같은 구문이 없다
-
반복, 조건, 데이터 처리가 모두 메시지 전달 형태
-
배열, 숫자 같은 기본 요소조차 “메시지를 받는 객체”
Ruby가 .each, .times, .select 같은 호출을 루프로 사용하도록 유도하는 이유가 바로 여기에 있다고 해요.
Ruby에서 for 가 어색한 이유
Ruby에는 for 문이 존재하지만, Ruby 철학과는 잘 맞지 않아요.
-
for는 문법적 반복문(syntax)
-
.each나 .times는 객체에 메시지를 보내 반복을 요청하는 방식
-
블록 기반 반복과 달리 for는 지역 변수를 스코프 밖으로 새게 하는 등 부작용도 있음
Rubyist가 “루프를 돌리는 대신, 객체에게 반복을 요청하라”고 말하는 이유가 여기에 있습니다.
메시지 전달 방식의 장점
Smalltalk → Ruby로 이어진 메시지 기반 반복은 다음과 같은 장점을 줘요.
-
객체가 스스로 어떻게 반복될지 결정
-
숫자나 배열, 심지어 사용자가 만든 객체도 반복 프로토콜을 가질 수 있음
-
반복이 문법이 아니라 객체의 인터페이스로 일관성 있게 확장됨
-
Enumerable 같은 프로토콜 기반 설계로 다양한 반복 기능 자동 제공
결론: Ruby 루프는 “프로토콜”이다
Ruby에서 반복은 단순한 흐름 제어가 아니라 객체 간 협력 방식이에요.
그래서 Rubyist들은 10.times나 items.each 같은 형태를 자연스럽게 사용하고,
이를 통해 Smalltalk의 유산—Protocol over Syntax(문법보다 프로토콜)—을 이어가요.
Ruby 루프를 이해하는 가장 좋은 한 줄 설명은 다음과 같아요:
Ruby에서 반복은 ‘루프’가 아니라, 객체에 ‘메시지를 보내는 것’이다.
SF RubyConf — 숫자로 돌아본 커뮤니티의 에너지
SF RubyConf가 행사를 마무리하며 전체 규모를 공유했는데, 이번 컨퍼런스가 얼마나 커뮤니티 중심으로 운영됐는지 숫자만 봐도 실감이 납니다.
약 450명의 참가자가 현장을 가득 채웠고,
60명의 스피커가 발표·워크숍·데모로 프로그램을 이끌었습니다.
여기에 30여 개 스폰서가 커뮤니티 성장을 지원했고,
무려 70명(50명 자원봉사자 + 20명 조직팀) 이 행사 운영을 책임졌습니다.
Ruby 생태계를 움직이는 힘이 어디에 있는지 다시 확인할 수 있었던 행사였어요.
Pay Yourself First — DHH의 일하는 방식
DHH가 최근 글에서 “Pay yourself first”라는 메시지를 전했어요.
끝없이 쌓이는 이메일·미팅·업데이트에 하루를 다 써버리는 대신,
가장 먼저 ‘나에게 의미 있는 일’을 하는 습관이 필요하다는 이야기예요.
DHH는 자신도 매일 수많은 요청에 둘러싸여 있지만,
그럼에도 “프로그래밍, 실험, 호기심을 채우는 일”을 우선한다고 말해요.
이 시간이야말로 창의력과 동기, 실력을 유지하게 해주는 원천이기 때문이죠.
그는 이를 “특권”이라 표현하면서도,
이 특권은 스스로 만들어가는 것이라고 강조해요.
작은 호기심을 좇는 순간부터 실력이 쌓이고,
실력은 더 큰 자율성과 기회를 가져오는 선순환을 만든다는 의미라고 해요.
일은 끝이 없다.
내 우선순위는 내가 먼저 챙기지 않으면 영원히 오지 않는다.
DHH식 생산성 조언이지만,
지속 가능한 개발자 삶에 꽤 실용적인 메시지 같아요.
왜 개발 속도는 시간이 지날수록 느려질까?
Kent Beck은 소프트웨어 개발이 초반엔 빠르다가 어느 순간 갑자기 느려지는 이유를 ‘시간’ 때문이 아니라 옵션(optionality)의 감소 때문이라고 설명해요.
기능을 추가할 때마다 코드베이스가 복잡해지고, 하위 호환성 유지나 기존 구조와의 충돌 같은 제약이 생기면서 앞으로 선택할 수 있는 길(옵션) 이 점점 사라진다는 것이죠.
처음엔 기능이 없지만 모든 선택지가 열려 있고,
나중엔 기능은 많지만 움직일 수 있는 공간이 거의 없는 상태가 됩니다.
그래서 초반 기능 개발 속도는 급격히 떨어지고, 어느 시점 이후엔 “왜 이렇게 안 나가?” 싶은 지점에 도달한다고 해요.
Kent Beck은 이 문제를 해결하기 위해 기능 → 옵션 회복 → 기능의 리듬을 제안해요.
-
기능을 하나 구현한 뒤
-
다음 기능을 더 쉽게 만들기 위해 구조를 정돈하고(=tidying)
-
선택지를 회복하는 사이클
이 ‘숨 고르기’ 과정이 없다면 프로젝트는 결국 옵션 소진 상태에 도달해 전체 개발 속도가 멈춰 버린다는 거죠.
그가 반복해서 BPlusTree, BPlusTree2… 같은 프로젝트를 새로 시작했던 이유도 여기에 있어요.
“이번엔 다르게 될 것이라 생각했지만, 결국 옵션을 다 태워버렸기 때문.”
결론은 간단해요.
기능만 만들지 말고, 기능을 만들 공간을 계속 회복하라.
기능이 늘어날수록 “정돈의 시간”이 더 중요해진다.
Ruby Around The World — 일본 편 공개
Rhiannon Payne이 새롭게 시작한 유튜브 시리즈 Ruby Around The World의 첫 영상이 공개됐어요. 이번 에피소드에서는 Kaigi on Rails 조직자 Okura Masafumi와 함께, 일본 Ruby 생태계의 독특한 면모를 깊이 있게 들여다봅니다.
영상의 핵심은 한 문장으로 요약할 수 있어요:
“일본은 Ruby의 심장이지만, Rails와는 조금 거리가 있다.”
영상에서는 Matsue에서 열린 Ruby World Conference 현장을 중심으로 일본 Ruby 커뮤니티의 분위기와 구조를 살펴보는데요:
-
매우 일본 중심적 구성 — 발표 대부분이 일본어, 영어 세션은 극소수
-
커뮤니티 밀도와 에너지 — 언어 장벽이 있어도 교류만큼은 그 어떤 지역보다 활발
-
Rails와의 거리감 — Ruby는 강하지만 Rails 중심 커뮤니티는 상대적으로 작음
-
Matsue라는 도시의 매력 — 지역 문화, 사케, 행사 분위기가 어우러지는 ‘로컬 중심’ 생태계
Ruby를 사랑하는 나라의 고유한 개발 문화가 어떻게 형성되는지,
그리고 세계 Ruby 커뮤니티와 일본 커뮤니티가 어떻게 더 잘 연결될 수 있을지를 흥미롭게 보여주는 영상이에요.
영상 보기: Japan is the Heart of Ruby, But Feels Far From Rails
Ruby Around The World: https://rubyaroundtheworld.com
X 포스트: https://x.com/rhiannon_io/status/1990805093558726925
Gusto의 Rails Biolith — 두 개의 모놀리스로 운영하는 대규모 Rails
Gusto가 올해 발표에서 자사의 독특한 아키텍처인 Rails Biolith를 소개했어요.
하나의 거대한 모놀리스를 쪼개거나 마이크로서비스로 전면 전환하는 대신, Gusto는 두 개의 독립된 Rails 모놀리스로 운영하는 방식을 선택하고 있어요.
한쪽은 일반 제품 기능, 다른 한쪽은 HIPAA 규제가 필요한 Benefits 도메인으로 구성되어 있고, 팀 규모가 커지면서 자연스럽게 강화된 경계 덕분에 확장성과 보안을 모두 챙길 수 있었다고 해요.
최근에는 메인 모놀리스에서 Time 제품군(스케줄링·휴가·시간 추적) 을 점진적으로 분리 중이며, Packwerk를 활용해 서비스 경계를 명확히 하고, GraphQL로 두 시스템 간 통신을 단순화하는 등 대규모 Rails 조직이 겪는 문제들을 현실적으로 풀어가는 경험을 공유했어요.
모놀리스냐 마이크로서비스냐 같은 이분법이 아니라, 도메인 경계를 의도적으로 나누고 점진적으로 모듈화해가는 방식이라는 점이 특히 인상적이었어요.
📺 영상: https://www.youtube.com/watch?v=5Bh4DVrJx3E
📝 요약: https://secondb.ai/summary/8678/
Turbo, 정말 “비유지보수 상태”일까? — Jorge Manrubia의 생각
최근 Turbo가 “유지보수되지 않는다”는 논쟁이 있었는데, 37signals의 Jorge Manrubia가 이에 대한 개인적인 생각을 정리했어요.
핵심은 의외로 단순합니다:
-
Turbo는 잘 작동하고, 실제 제품에서도 안정적으로 쓰이고 있다.
새로운 제품(Fizzy)까지 Turbo 전 기능을 광범위하게 사용 중이며, 해결해야 할 버그도 거의 없다고 합니다.
-
유지보수도 되고 있다.
올해만 42개의 PR이 머지, 4개의 릴리스, 마지막 릴리스는 불과 몇 주 전.
이미 머지되어 릴리스만 기다리는 커밋도 여럿 있다고 해요.
-
더 많은 기능 = 더 나은 라이브러리라는 환상은 없다.
Turbo는 이미 복잡한 API 표면을 가진 큰 라이브러리이고,
여기저기서 나오는 요구를 모두 받아들이면 금방 혼란스러워질 수 있다고 강조합니다.
지금은 확장보다 정리·단순화가 더 중요하다는 의견.
-
프런트엔드 세계는 취향의 바다
어떤 기능이 “좋아 보이는 것”과 실제로 Turbo의 철학·호환성에 부합하는 것은 전혀 다른 문제.
“대부분의 사용자에게 대부분의 상황에서 좋은가?”가 기준이며,
그렇지 않다면 쉽게 API를 추가하길 원치 않는다고.
-
큰 API + 많은 사용자 = 작은 변경도 리스크가 크다
그래서 병합 속도가 느린 것은 당연한 트레이드오프이며,
“PR이 바로 안 머지된다 = 유지보수가 안 된다”의 의미는 아니라는 점을 지적합니다.
마지막으로 그는 이렇게 말했어요.
불만을 말하는 것도 자유지만,
정말 불만이 크다면 포크해서 직접 보여주는 것도 자유다.
그게 실제로는 훨씬 어렵기 때문에 더 배울 점이 많을 것이다.
Turbo의 방향성에 대한 37signals 쪽의 솔직한 관점이 잘 드러나는 글이었어요.
스레드 전체 보기: https://x.com/jorgemanru/status/1990140017625514440