Ruby on Rails 82번째 소식

이번 소식에서는 Rails와 AI, 그리고 개발자로서 일하는 감각을 다시 생각해보게 만드는 이야기들을 모아봤어요.

12년 된 코드베이스에서도 놀라운 테스트 속도를 유지하는 Basecamp 5 이야기부터, AI 도구와 함께 오랫동안 미뤄왔던 Rails 업그레이드를 단숨에 끝낸 경험, 그리고 AI를 “현실적으로” 활용하기 위한 문서 중심 워크플로우까지 살펴봤어요. 여기에 더해, Ruby를 만든 마츠모토 유키히로의 인터뷰를 통해 일이 항상 즐겁지는 않아도, 왜 계속 이 일을 할 수 있는지에 대한 깊은 통찰도 함께 담았어요.

AI가 점점 개발의 일상으로 들어오는 지금,
이번 뉴스레터가 어떻게 만들 것인가, 어떻게 일할 것인가, 어디에서 즐거움을 찾을 것인가를 차분히 돌아보는 계기가 되었으면 해요.

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

새로운 소식

Basecamp 5 개발 현황과 테스트 성능에 대한 이야기

12년 된 코드베이스에서도 여전히 빠른 Basecamp 5

David Heinemeier Hansson가 Basecamp 5 개발 상황을 공유했어요.
Basecamp 5는 Basecamp 3과 4와 동일한 구조(chassis)를 기반으로 하고 있고, 그 결과 코드베이스의 역사가 무려 12년에 이르러요.

그럼에도 불구하고 성능은 매우 인상적이에요.
로컬 16코어 AMD 리눅스 환경에서 전체 테스트 스위트를 45초 만에 실행할 수 있다고 밝혔어요. 오래된 코드베이스라도 잘 관리하면 충분히 빠르고 효율적으로 유지할 수 있다는 점을 강조한 사례예요.

👉 원문: https://x.com/dhh/status/2016449600257720742?s=20

Basecamp 5 테스트가 이렇게 빠른 이유

이어진 공유에서 테스트 속도를 이렇게까지 끌어올릴 수 있었던 방법도 설명했어요. 핵심은 바닐라 Rails 접근 방식이에요.

• 멀티코어를 활용한 Minitest 병렬 실행

• Fixtures 사용

• RSpec과 Factory 사용을 피함

즉, Rails 기본 도구를 최대한 활용하고, 복잡성과 오버헤드를 늘리는 선택지를 의도적으로 배제했다는 점이 포인트예요. 테스트 속도와 단순함을 동시에 잡기 위한 실용적인 판단으로 볼 수 있어요.

👉 원문: https://x.com/dhh/status/2016453756808818911?s=20

전체적으로 이번 공유는 장수하는 Rails 애플리케이션을 어떻게 유지하고, 테스트 성능을 어떻게 관리할 수 있는지에 대한 Basecamp 팀의 철학과 경험을 잘 보여줘요.

Claude Code로 오래된 Rails 앱을 Rails 8.1로 마이그레이션한 경험

몇 년 미뤄왔던 작업을 단 2일 만에 끝내다

Peter Cooper가 주말 동안 아주 오래된 Rails 6 애플리케이션을 Rails 8.1 기준에 맞게 전면 업그레이드한 경험을 공유했어요.
Rails 8의 최신 기능들을 모두 적용하고, 기존에 사용하던 jQuery를 제거한 뒤 Stimulus와 Turbo로 전환하는 작업까지 포함된 마이그레이션이었어요.

이 작업은 원래 수년 동안 미뤄두고 있던 일이었지만, Claude Code와 함께 작업하면서 이틀 만에 마무리할 수 있었다고 해요. 과정 중에 많은 “논쟁(?)”이 오갔지만, 결과적으로는 원하는 수준까지 잘 완성해냈다고 전했어요.

AI 도구가 레거시 마이그레이션의 장벽을 낮추다

이번 공유의 핵심은 레거시 Rails 프로젝트 마이그레이션의 심리적·기술적 부담을 AI 도구가 크게 줄여줬다는 점이에요.
오래된 코드, 프레임워크 버전 차이, 프론트엔드 스택 교체처럼 까다로운 작업도, 충분한 상호작용을 전제로 하면 현실적인 시간 안에 끝낼 수 있다는 사례로 볼 수 있어요.

👉 원문: https://x.com/cooperx86/status/2016523155343278571?s=20

AI로 Rails 코드를 실제로 작성하는 방법에 대한 실전 가이드

과장된 AI 코딩 담론에서 벗어나 현실적인 워크플로우를 제시하다

Mario Alberto Chávez가 How I actually use AI to write Ruby on Rails code 라는 새 글을 공개했어요.
이 글은 소셜 미디어에 넘쳐나는 “AI로 몇 시간 만에 서비스 복제” 같은 과장된 이야기 대신, 현실적인 기대치를 바탕으로 AI를 Rails 개발에 활용하는 구체적인 방법을 다뤄요.

Mario는 단순 프롬프트만으로 완성도 높은 기능이 나오지 않는다면 그건 도구의 문제가 아니라 맥락(context)이 부족하기 때문이라고 짚어요. 그래서 핵심은 “AI에게 올바른 맥락을 어떻게 제공하느냐”에 있어요.

👉 원문: https://mariochavez.io/desarrollo/2026/01/26/how-i-actually-use-ai-to-write-ruby-on-rails-code/

브라운필드 Rails 애플리케이션에서 AI를 쓰는 방법

기존의 대형 Rails 애플리케이션(브라운필드)에서는 레이어드 문서화 전략을 사용해요.

• Layer 1: 기술적 기반 문서
  앱 구조, 사용 중인 gem, 데이터베이스, Rails 외 프레임워크 등 순수 기술 아키텍처만 정리해요.

• Layer 2: 패턴 문서화
  모델, 컨트롤러, UI, 테스트 등에서 실제로 쓰이고 있는 패턴을 대표 파일을 기반으로 일반화해요.

• Layer 3: 기능 가이드
  특정 기능 하나를 UI부터 DB까지 종합적으로 설명하는 문서를 먼저 만들어요.

• Layer 4: 구현 스펙
  기대하는 결과와 작업 범위를 명확히 한 상세 스펙을 작성해요.

이 과정을 거치면 AI가 대체로 올바른 방향의 코드를 생성하지만, 복잡도가 높아지는 지점이 생겨요. 이때 패턴 준수 여부와 복잡도를 리뷰·단순화하는 단계를 반드시 거친다고 설명해요. 이 리뷰 단계가 없으면 이른바 “AI slop”가 쌓이기 쉽다고 해요.

그린필드 Rails 애플리케이션에서는 문서부터 시작해요

새 프로젝트(그린필드)에서는 코드보다 문서가 먼저예요.

• MVP 문서: 만들 앱과 기술 스택을 설명하고, AI가 유사 서비스와 기능 우선순위를 제안하도록 해요.

• 브랜드 디자인 문서: 이름, 색상, 톤을 정의해 UI와 카피 일관성을 유지해요.

• 시각적 목업이 포함된 구현 스펙: HTML/CSS/JS로 목표 UI를 명확히 보여줘요.

구현 단계에서는 Claude Code를 사용해 스펙 기반으로 작업을 진행하고, 세션이 끝날 때마다 코드 복잡도를 줄이는 전용 리뷰 프로세스를 실행해요. 이렇게 성장한 프로젝트도 결국 브라운필드와 동일한 문서 구조로 관리하게 된다고 해요.

결론: AI 시대에 더 중요한 건 커뮤니케이션 능력

Mario는 AI가 개발자를 대체한다고 보지 않아요. 대신 더 빠르게 코드를 전달할 수 있게 해주는 도구라고 봐요.
이 과정에서 중요한 건 타이핑 속도가 아니라, 명확한 문서화와 의사소통 능력이에요.

AI가 코드를 작성한다면, 개발자의 역할은
“무엇을 원하는지 명확히 정의하고, 올바른 맥락을 제공하며, 언제 개입해야 하는지 아는 것”으로 진화하고 있다는 메시지를 전해요.

DHH가 정리한 37signals 내부의 AI 에이전트 논의 정리

Rails와 AI 에이전트가 특히 잘 맞는 이유

David Heinemeier Hansson가 최근 AI 에이전트에 대한 생각과, 37signals 내부에서 진행한 논의 내용을 공유했어요.
그는 Convention over Configuration이 지난 20년 넘게 축적해 온 Rails 생태계 덕분에, 오늘날 AI가 Rails 코드에서 특히 좋은 성과를 내고 있다고 설명해요.

Rails는 보일러플레이트가 적고 구조가 예측 가능하기 때문에,

• AI 에이전트가 코드를 생성하기 쉽고

• 인간 개발자 역시 결과물을 빠르고 자신 있게 리뷰할 수 있다는 점을 강조해요.

👉 원문: https://x.com/dhh/status/2018574874675929544?s=20

37signals 내부 AI 세션에서 나온 핵심 인사이트

DHH는 37signals 내부에서 진행된 AI 관련 세션의 요점을 간단히 정리해 공유했어요. 아직 모두가 AI 에이전트를 다루는 방법을 완전히 알지는 못하지만, 몇 가지 패턴은 분명히 드러나고 있다고 해요.

주요 내용은 다음과 같아요.

• 지시 방식의 변화
  “이렇게 구현해” 같은 작업 중심 지시보다,
  “이 문제를 해결해”, “이걸 만들어” 같은 결과 중심 지시가 더 효과적이에요.

• 에이전트는 더 과감하게 실행돼야 해요
  모든 권한을 일일이 승인하며 관리하면 에이전트의 장점을 살릴 수 없어요.
  대신 시스템은 언제든지 복구 가능한, 즉 소모 가능한(disposable) 구조여야 해요.

• 과도한 사전 설계는 안티패턴
  사람과 마찬가지로, 에이전트도 실제로 돌아가는 걸 보면서 방향을 잡는 게 좋아요.
  탐색 → 실행 → 수정의 반복이 중요해요.

• Git 워크플로우의 중요성
  에이전트를 기다리는 시간은 과거의 “컴파일 기다리기”와 같아요.
  여러 작업을 병렬로 관리하는 습관이 필요해요.

• Basecamp에서의 에이전트 역할
  에이전트는 모든 세부 작업을 보고하는 존재가 아니라,
  높은 수준의 작업을 수행하고 요약해 전달하는 역할이 적합해요.

• 소프트웨어의 미래
  AI 에이전트 덕분에 소프트웨어는 다시 ‘맞춤형(bespoke)’ 시대로 돌아갈 가능성이 있어요.
  소프트웨어를 직접 사는 대신, “만들어 달라”고 요청하는 게 더 자연스러워질 수 있어요.

• AI를 외면하는 전략은 현실적이지 않아요
  보안과 위험에도 불구하고, 이미 많은 사람이 AI 도구를 실무에 사용하고 있어요.
  초기의 위험과 불편은 점차 완화되고, 결국 표준이 될 가능성이 크다고 봐요.

👉 원문: https://x.com/dhh/status/2018631575337095389?s=20

“지금은 초기 단계지만, 되돌아가진 않을 거예요”

DHH는 지금의 AI 열풍이 과장된 면도 있지만, 인터넷 초기와 마찬가지로 이미 되돌릴 수 없는 변화라고 말해요.
그래서 외면하기보다는, 실제 업무에 통합하고 배우면서 앞으로 나아가는 게 중요하다고 정리해요.

이번 공유는 Rails, Basecamp, 그리고 AI 에이전트가 만나는 지점에서 37signals가 어떤 방향을 보고 있는지를 잘 보여주는 기록이에요.

Ruby 창시자 마츠모토 유키히로가 말하는 ‘일의 즐거움’

“일이 100% 즐거울 수는 없어요”

프로그래밍 언어 Ruby를 만든 마츠모토 유키히로가 젊은 엔지니어들이 자주 느끼는 고민, 즉 “일이 힘들어졌을 때 어떻게 받아들여야 하는가” 에 대해 자신의 생각을 나눴어요.

마츠모토는 “좋아하던 일도 직업이 되는 순간, 책임과 제약이 함께 따라오면서 즐거움이 줄어드는 건 아주 자연스러운 일”이라고 말해요.
납기, 복잡한 요구사항 조율, 행정적인 업무처럼 개발 외적인 요소들이 붙는 이상, 일이 항상 재미있을 수는 없다는 거예요. 심지어 본인도 청구서 작성 같은 업무는 싫다고 솔직하게 이야기해요.

하지만 그는 일에 재미없는 부분이 있다고 해서 그 일이 ‘나에게 맞지 않는다’는 뜻은 아니라고 분명히 선을 그어요. 대부분의 소프트웨어 개발자는 각자 참고 견뎌야 하는 지점을 안고 일하고 있다는 거예요.

관점의 전환: 남아 있는 ‘몇 퍼센트의 재미’

마츠모토가 강조하는 핵심은 시선의 전환이에요.
일의 전부가 즐겁지는 않더라도, 그 안에는 분명 아직 남아 있는 몇 퍼센트의 재미가 있다는 거예요. 그 작은 재미에 의식적으로 집중하고, “이건 재미있다”고 받아들이는 태도가 중요하다고 말해요.

Ruby를 만드는 사람이라서 가능한 이야기일까?

인터뷰어가 “자신이 좋아하는 언어를 만들고 있어서 가능한 이야기 아니냐”고 묻자, 마츠모토는 웃으며 그 점은 맞다고 인정해요.
하지만 동시에, 그는 Ruby 외에도 의뢰받아 진행하는 일반적인 클라이언트 개발 경험도 많이 해왔고, 그때도 여전히 즐겁게 개발했다고 말해요.

그 즐거움의 정체는 바로 ‘퍼즐을 푸는 재미’ 였다고 해요.

엔지니어링의 본질적인 재미는 ‘퍼즐’

버그를 추적하는 과정,
“머릿속에서는 이렇게 동작해야 하는데 실제로는 왜 다를까?”를 파고드는 과정은 퍼즐을 푸는 것과 같다고 설명해요.

원인이 밝혀지는 순간의 “아, 여기였구나!”라는 쾌감은
그 대상이 세계적인 프로그래밍 언어든, 평범한 업무 시스템이든 엔지니어링이라면 공통적으로 존재하는 재미라는 거예요.

그래서 그는 이렇게 조언해요.
일이 100% 즐겁지 않다는 사실을 전제로 하되, 그 안에 남아 있는 문제 해결의 재미와 스스로 결정할 수 있는 재량을 놓치지 말라고요.

AI 시대에도 즐거움은 사라지지 않아요

AI가 점점 더 정확한 코드를 작성하게 되면, 단순한 버그를 잡는 재미는 줄어들 수 있다고 마츠모토는 인정해요.
하지만 그 대신 사람은 더 상위의 질문에 집중할 수 있게 된다고 말해요.

• 어떤 소프트웨어를 만들어야 할지

• 어떤 해결책이 더 나은지

• 어떤 설계와 디자인이 사용자에게 더 좋은 경험을 줄지

이런 결정과 설계의 즐거움은 여전히 인간의 몫이라는 거예요.
AI는 제안을 할 수는 있지만, 최종적으로 선택하는 권한이 인간에게 남아 있는 한, 일의 재미도 함께 남아 있다는 메시지를 전해요.

👉 기사 전문:
「休日もコードを書け」は正義か？ Ruby父 まつもとゆきひろが肯定する“仕事と割り切る”エンジニアの在り方