Ruby on Rails로의 전환 결정은 처음에는 엔지니어링 팀 내에서 큰 반발을 샀습니다. 많은 개발자들이 Ruby on Rails를 ‘오래된 기술’로 여겼기 때문입니다. 하지만 CTO의 확고한 의지로 프로젝트는 강행되었고, Flexcar는 전체 플랫폼의 약 90%를 3개월 내에 재구축하겠다는 매우 공격적인 목표를 설정했습니다. 비록 목표했던 3개월은 달성하지 못했지만, 4개월 만에 4명의 핵심 엔지니어(Dan Dunkers 포함)가 새로운 Ruby on Rails 플랫폼의 80%를 구축하는 데 성공했습니다. 출시 과정은 RailsConf 기간 중 진행되었는데, 컨퍼런스 기조연설에서 Flexcar의 전환 스토리가 언급되면서 ‘이젝트 버튼’을 누를 기회를 잃고 예정대로 라이브 전환을 진행하게 되었습니다. 데이터 마이그레이션은 예상보다 훨씬 길어져 2~3시간이 아닌 약 16시간이 소요되었지만, 결국 성공적으로 완료되었습니다.
초기 출시 후 약 6~8주 동안은 예상대로 수많은 프로덕션 버그를 수정하고 미처 구현하지 못한 기능을 보완하는 데 시간을 할애해야 했습니다. 이 기간 동안 고객 관리팀의 전화량이 5~6배 증가하는 등 내부적인 어려움도 겪었습니다. 그러나 이러한 초기 진통을 겪은 후, Flexcar는 훨씬 더 안정적인 시스템을 갖추게 되었습니다.
Ruby on Rails로의 전환은 Flexcar에 여러 가지 중요한 이점을 가져다주었습니다. 첫째, 개발 속도와 생산성이 획기적으로 향상되었습니다. 기존 Java 환경에서는 분기당 10~15개의 프로젝트를 수행하던 것이, Ruby on Rails에서는 훨씬 적은 인원으로도 분기당 25~30개의 프로젝트를 완료할 수 있게 되었습니다. 이는 마이크로서비스 간의 복잡한 의존성 문제를 해결하고, 전체 시스템을 개발자 노트북에서 실행할 수 있게 되면서 얻은 결과입니다. 또한, 새로운 기능을 몇 주 단위로 빠르게 시도하고 검증할 수 있게 되면서 제품 기획팀의 아이디어를 즉시 구현할 수 있는 민첩성을 확보했습니다. 실제로 이러한 속도 향상은 Flexcar의 회원 성장률을 두 배로 끌어올리는 데 기여했습니다.
둘째, 팀 구조와 협업 방식에 긍정적인 변화가 있었습니다. 기존 5~8명 규모의 팀에서 2~3명 규모의 소규모 팀으로 전환하면서, 팀원 간의 교차 학습과 멘토링이 활발해졌습니다. 시스템의 특정 부분에 대한 ‘왕국’과 같은 개념이 사라지고, 모든 엔지니어가 코드베이스의 어떤 부분이라도 살펴보고 변경할 수 있게 되면서 지식 공유가 촉진되었습니다.
셋째, 코드베이스의 품질이 크게 개선되었습니다. 단순히 기존 Java 코드를 Rails로 옮기는 대신, 대부분의 시스템을 처음부터 다시 구축하면서 아키텍처를 재고하고 더 깔끔하고 효율적인 코드베이스를 만들 수 있었습니다. 고객 대면 애플리케이션에는 React 프론트엔드를 유지하고 React Native를 모바일 경험에 활용했으며, 이는 Ruby on Rails 백엔드와 완벽하게 조화롭게 작동했습니다. 특히 프론트엔드 개발자들이 빠르게 풀스택 개발자로 성장할 수 있었던 점은 큰 장점으로 작용했습니다. 내부 툴링의 경우, 초기에는 ERB, Turbo, Stimulus를 사용했으나 최근에는 React와 Inertia.js를 도입하여 통일된 프론트엔드 스택을 구축하고 고객 대면용으로 개발된 React 컴포넌트를 재사용하여 내부 툴의 사용자 경험을 개선하고 있습니다.
넷째, AI 도구의 적극적인 활용이 생산성 향상에 크게 기여했습니다. 초기에는 ChatGPT를 사용했으나, 부정확한 정보(환각)로 인해 시간을 낭비하는 경우가 있었습니다. 그러나 Cursor(현재 Cloud Code)와 같은 AI 코딩 도구의 도입은 ‘획기적인 변화’였습니다. Cursor는 특히 Ruby on Rails에 익숙하지 않은 개발자들에게 보일러플레이트 코드 작성, PR 리뷰, 테스트 작성 등을 지원하며 생산성을 극대화했습니다. 강연자는 Cursor 덕분에 프론트엔드 개발자임에도 불구하고 Rails 백엔드 코드를 작성할 수 있게 되었다고 언급하며, AI가 개발자의 성장과 학습을 가속화하는 중요한 도구임을 강조했습니다.
물론, 전환 과정에서 몇 가지 어려움도 있었습니다. MiniTest와 RSpec 선택의 문제, 비동기 작업(Jobs) 처리 및 우선순위 설정의 어려움, N+1 쿼리 문제(Sentry를 통해 파악 및 개선 중), 그리고 React 프론트엔드와 Rails 백엔드 간의 인증(Devise) 연동 문제가 대표적입니다. 그럼에도 불구하고, 이러한 문제점들이 시스템 성능에 치명적인 영향을 미치지는 않았으며, 꾸준히 개선해나가고 있습니다.