Ruby on Rails의 미래와 에이전트 기반 개발로의 전환

DHH의 에이전트 기반 개발 및 루스트로의 전환

Ruby on Rails의 창시자인 데이비드 하인메이어 한슨(DHH)은 소프트웨어 공학에 대한 접근 방식에서 근본적인 전환을 시사하며, 수작업 코드 작성에서 "에이전트 기반 개발" 모델로 이동하고 있다. 그는 Rails World 2026 기조 연설에서 이제 자신을 전문 프로그래머가 아니라 "만들어내는 사람(maker)"으로 간주한다고 밝혔으며, 대규모 언어 모델(LLM)의 능력으로 인해 영어가 이제 주요 프로그래밍 언어가 되었다고 주장했다.

DHH의 새로운 기술 전략의 주요 포인트는 다음과 같다:

  • 수작업 코드 포기: DHH는 대부분의 프로그래머에게 수작업으로 코드를 작성하는 것은 더 이상 경제적으로 생산적이지 않다고 주장한다. 그는 인간이 생성된 코드를 거의 읽지 않는 워크플로우를 지지하며, 코드 리뷰를 Sentry에서 버그를 조사하는 것과 마찬가지로 예외적인 것으로 간주한다.
  • 백엔드로 루스트 전환: DHH는 과거에 루스트를 "인간에게는 보기 싫은" 것으로 비판했지만, 이제 LLM에 매우 효과적이라며 이를 지지하고 있다. 그는 Ruby가 이제 연간 코드 출력량의 겨우 3%만 차지하며, LLM이 생성한 루스트 코드는 급증했다고 보고했다.
  • 웹 앱 대신 네이티브 앱: 37signals는 주력 이메일 제품인 Hey를 다양한 플랫폼용 6개의 네이티브 애플리케이션으로 재작성하고 있다. DHH는 이전에 웹 앱에 의존한 것은 소규모 팀의 생산성 보완책이었으며, LLM 코드 생성의 효율성 덕분에 더 이상 필요하지 않다고 주장한다.
  • CLI 우선 통합: DHH는 모든 서비스가 그래픽 사용자 인터페이스(UI) 없이도 AI 에이전트가 서비스와 상호작용할 수 있도록 명령줄 인터페이스(CLI)를 제공하는 미래를 상상하고 있다.

Ruby on Rails 생태계에 대한 영향

DHH가 37signals의 주력 제품이 Rails 스택을 떠난다고 발표하면서, 프레임워크의 장기적 비전에 대한 불확실성이 커졌다. 20년간 Rails는 "작은 팀, 야심 찬 제품"을 위한 도구로 마케팅되었지만, DHH의 현재 경로는 이 범위를 좁히고 있음을 시사한다.

"유지보수 모드" 논쟁

커뮤니티 내에서는 Rails가 이제 완성된 상태에 도달해 "끝났다"는 상태에 이르렀는지에 대한 논의가 증가하고 있다. 일부 개발자는 Rails가 이제 안정적이고 성숙한 프레임워크로, 그 규약이 LLM에게 "토큰 효율적"이기 때문에 유지보수와 에이전트 기반 개발에 적합하다고 주장한다. 다른 이들은 프로젝트 Mosscap을 통해 프레임워크가 실질적으로 완료되었으며, 유지보수만 필요하다고 제안한다.

BDFL의 영향력

비판자들은 오픈소스에서의 "선한 독재자(Benevolent Dictator for Life, BDFL)" 문화가 리더의 개인적 관심이 변화할 때 변동성을 초래한다고 지적한다. 기조 연설에서 Rails에 대한 구체적인 로드맵이 없었고, 대신 AI에 대한 일반적인 낙관론으로 대체된 점은 일부 사용자가 DHH의 리더십에서 단호하게 떨어져 나가야 한다고 주장하게 만들었다. 이는 프레임워크의 지속적인 진화를 보장하기 위한 것이다.

에이전트 논지에 대한 기술적 비판

업계 전문가와 개발자들은 "코드를 절대 보지 않기"와 기조 연설에서 제시된 주장의 타당성에 대해 여러 가지 우려를 제기했다.

아키텍처의 악화

비평가들은 Basecamp 5의 "스위스 치즈" 아키텍처를 언급하며, 검토되지 않은 에이전트 생성 기여가 구조적 쇠퇴로 이어진다는 증거로 제시한다. 이는 Shopify CEO인 토비 루트케가 "저품질 AI 생성 코드(slop grenades)"를 경고한 것과 일치한다. 이러한 코드는 코드베이스를 손상시킬 수 있다.

성능 및 메트릭

DHH는 Hey를 루스트 백엔드로 이전함으로써 CPU 사용량이 99% 감소하고 메모리 사용량이 95% 감소했다고 주장했다. 기술적 비평가들은 이러한 수치가 오해를 불러일으킨다고 지적한다. 왜냐하면 웹 애플리케이션 전체와 비교했기 때문이다. 순수한 루비 백엔드(웹 프론트엔드 없이)도 상당한 성능 향상을 보일 것이며, 루스트의 영향을 고립시킬 수 없기 때문이다.

SRE의 신뢰 격차

사이트 신뢰성 엔지니어(SRE)들은 LLM이 100%의 코드를 맡는 것의 안전성에 의문을 제기했다. 비판자들의 합의는, 99%의 정확도는 인상적이지만, 나머지 1%의 환각 현상은 특히 LLM이 배포 코드도 작성하도록 지시받을 때 생산 환경에서 치명적인 결과를 초래할 수 있다는 점이다.

커뮤니티의 전환에 대한 시각

새로운 패러다임의 정당성

일부 개발자는 DHH의 주장을 지지하며, 업계가 "프로그래밍의 기계적 부분"을 자동화하는 방향으로 이동하고 있다고 주장한다. 그들은 정적 타입 언어인 루스트가 에이전트 피드백 루프에 더 적합하다고 제안한다. 왜냐하면 컴파일러가 루비가 부족한 엄격한 안전망을 제공하기 때문이다.

지속적인 웹/Rails 활용의 정당성

다른 개발자들은 많은 애플리케이션에서 루비의 성능 오버헤드가 무시할 수 있다고 주장한다. 그들은 애플리케이션이 I/O 바운드라면, AI로 보강된 Rails의 생산성 향상이 루스트로 재작성하는 이점보다 크다고 주장한다.

네이티브 앱 트렌드

일부 관찰자들은 DHH의 네이티브 앱 전환을 더 넓은 산업의 인식 변화로 해석한다. 과거에는 OS 버전 관리가 너무 노동 집약적이었기 때문에 웹이 배달 수단으로 사용되었다. 만약 AI가 네이티브 앱 구축 비용을 거의 0에 가깝게 낮춘다면, 산업은 HTML/CSS보다 더 나은 UX와 성능을 제공하는 클라이언트-서버 아키텍처로 다시 전환할 수 있다.

주요 논점 요약

시각 Rails에 대한 견해 AI 코드 작성에 대한 견해
DHH / 낙관론자 웹 앱용 안정적인 도구; 더 이상 생산성을 위한 유일한 방법은 아님. 인간은 에이전트를 지시하는 "만들어내는 사람"이 되어야 하며, 코드를 읽는 것은 오래된 방식.
비판론자 / 전통주의자 명확한 비전 없이 정체될 위험; 새로운 리더십 필요. 인간 검토 없이는 "저품질 코드 폭탄(slop grenades)"과 아키텍처 악화가 불가피.
현실주의자 I/O 바운드 앱과 빠른 프로토타이핑에 여전히 매우 효과적. AI는 보일러플레이트에 강력한 도구이지만, 엔지니어링의 대체물은 아님.

Sources

관련