레일스는 2005년 DHH의 “15분 만에 블로그 엔진 만들기” 데모로 웹 개발의 생산성을 혁신했습니다. 당시 자바(J2EE), PHP, CGI가 지배하던 시장에서 자동화와 단순함을 제공하며 “마법”으로 불렸습니다. 그러나 이러한 “마법”은 양면성을 가졌습니다.
레일스의 마법과 역효과
- 초기 생산성: PHP 웹 앱을 레일스로 재작성하며 하루 만에 회원가입 플로우를 구현하는 등 놀라운 생산성을 경험했습니다.
- 예상치 못한 문제: ActiveRecord를 상태 저장 서버에 사용하거나, 스레드를 부적절하게 사용하면서 데드락, 소켓/스레드/연결 누수, 추상화 누수 등의 심각한 문제가 발생했습니다. 이는 “15분 블로그 데모”와는 거리가 먼, 예측 불가능한 문제들의 연속이었습니다.
레일스에 대한 과도한 의존성
- 레일스는 저자를 더 나은 엔지니어로 만들었고, 루비는 인프라, 자동화 등 다목적으로 활용되며 최소한의 투자로 엄청난 가치를 창출했습니다.
- 그러나 모든 것에 루비를 사용하려는 경향(인프라 관리, 윈도우 클라이언트 코드 등)은 장기적으로 지속 불가능한 파괴를 초래했습니다. “훌륭한 망치가 있다면 모든 것이 못처럼 보인다”는 격언의 현실적 적용 사례였습니다.
레일스 테스트 문화와 유지보수 문제
- 레일스 커뮤니티는 TDD(Test-Driven Development)와 자동화된 테스트 커버리지 문화를 확산시키는 데 기여했습니다. 이는 기능 변경 시 안정성을 확보하고 빠른 반복 개발을 가능하게 했습니다.
- 테스트 스위트의 문제점:
- 점점 느려지는 테스트 속도와 최적화의 어려움.
- 데이터베이스 트랜잭션, 스레드, 외부 라이브러리 등 레일스의 “마법”으로 인한 테스트의 취약성(brittleness). 특정 테스트는 3번 중 1번만 성공하거나 특정 시간에만 작동하는 등 디버깅이 매우 어려웠습니다.
- 결국 코드는 “읽기 전용 코드”로 불릴 정도로 변경이 어려워졌고, 전체 코드베이스가 다른 언어로 재작성되는 상황에 이르렀습니다.
마법의 한계: 규모, 시간, ‘골든 패스’ 이탈
- 규모: 코드가 커질수록 복잡성은 기하급수적으로 증가하며, 테스트의 느림과 취약성은 감당할 수 없게 됩니다.
- 시간: 시간이 지날수록 “마법”은 기술 부채로 변모하며, 코드 유지보수 비용이 신규 개발 투자를 압도하게 됩니다.
- ‘골든 패스’ 이탈: 레일스가 의도한 “골든 패스”에서 벗어날수록 문제가 발생합니다. 예를 들어, ActiveRecord는 CRUD에는 뛰어나지만 대량 데이터 처리에는 약하며, “마법”은 디버깅이 필요할 때 오히려 방해가 됩니다.